Allow VideoStreamCopy for remote source fallback #5617
Conversation
During LiveTV playback, a fallback is usually needed because the first attempt would be try to direct play the remote url of that channel. If that failed we should still allow stream copy because the playback would still success in this case. The server side will enforce the most compatible format (h264+ts) and still do transcoding if that condition is not met.
There was a problem hiding this comment.
Having an extra try (for remux) doesn't hurt, but I have a strong feeling that we are trying to fix it from the wrong side.
This is what I tried for direct HLS (but it seemed to work without these changes).
My opinion, we need to probe the source before passing MediaSources to the StreamBuilder. Otherwise, it processes the raw source (until the next playback).
Not tested with STRM.
Co-authored-by: Dmitry Lyzo <56478732+dmitrylyzo@users.noreply.github.com>
The TranscodingSubProtocol is no longer nullable on the server side and direct playing media will have a value of http. Check container type when TranscodingSubProtocol is not HLS
Co-authored-by: Dmitry Lyzo <56478732+dmitrylyzo@users.noreply.github.com>
Co-authored-by: Dmitry Lyzo <56478732+dmitrylyzo@users.noreply.github.com>
|
|
This PR doesn't require any changes in server. I tested it on the |
Not all HLS streams need the server-side change. Actually, streams strictly obeys standard should not need any server side change. The server-side change is to add compatibility for TV Tuners that is lying about the stream info like bitrate so that the client requests a wrong bitrate and triggered transcoding. |
|
I mean, we can merge it without waiting for the server - these web changes are pretty universal. |
Yes you can. Nothing should break. |
|
I labelled it as "backend" due to this comment in the description:
I will remove that and get this merged since that isn't required. 👍 |
Allow VideoStreamCopy for remote source fallback Original-merge: 40e7dc9 Merged-by: thornbill <thornbill@users.noreply.github.com> Backported-by: Joshua M. Boniface <joshua@boniface.me>
Changes
During LiveTV playback, a fallback is usually needed because the first attempt would be try to direct play the remote url of that channel. If that failed we should still allow stream copy because the playback would still success in this case. The server side will enforce the most compatible format (h264+ts) and still do transcoding if that condition is not met.
Issues
Depends on jellyfin/jellyfin#11851 to guarantee the stream compatibility and actually doing remux for certain input videos