GNOME Bugzilla – Bug 757009
hlsdemux: Fix switching between I-frame and normal playlists when seeking
Last modified: 2018-11-03 13:41:46 UTC
See commit message
Created attachment 313918 [details] [review] hlsdemux: Fix switching between I-frame and normal playlists when seeking The demuxer segment always contains the current SEEK segment at this point, so we can't use it to check the previous playback rate we used. Instead check if we selected the I-frame playlist or not to decide if we need to switch. This was broken during the port to adaptivedemux. Also switch to I-frame playlists for playback rates > 1.0, not just < -1.0.
Anything left to do here?
Yes, it breaks things worse on e.g. the Apple streams because there we can do trick modes currently when not using the I frame playlists. But if we actually use the I frame playlists, we will error out then :) Also I think this should take the seek flags into account and only go to the I frame playlists if the GST_SEEK_FLAG_TRICKMODE_KEY_UNITS flag is set. Also I would've liked some feedback from Thibault who touched this last, and Thiago :)
Created attachment 314226 [details] [review] hlsdemux: Fix switching between I-frame and normal playlists when seeking The demuxer segment always contains the current SEEK segment at this point, so we can't use it to check the previous playback rate we used. Instead check if we selected the I-frame playlist or not to decide if we need to switch. This was broken during the port to adaptivedemux. Also switch to I-frame playlists for playback rates > 1.0, not just < -1.0.
Created attachment 314227 [details] [review] hlsdemux: Fix switching between I-frame and normal playlists when seeking The demuxer segment always contains the current SEEK segment at this point, so we can't use it to check the previous playback rate we used. Instead check if we selected the I-frame playlist or not to decide if we need to switch. This was broken during the port to adaptivedemux. Also switch to I-frame playlists for playback rates > 1.0, not just < -1.0, but only ever switch to I-frame playlists if GST_SEEK_FLAG_TRICKMODE_KEY_UNITS is set.
Review of attachment 314227 [details] [review]: Any reason why we don't just activate the I-frames list based on the trickmode flag? Any use case where we want the decoder/demux to actually drop the non-i-frames buffers? Perhaps because the I-frame lists might not contain audio? If that is not a concern, the code looks fine.
(In reply to Thiago Sousa Santos from comment #6) > Review of attachment 314227 [details] [review] [review]: > > Any reason why we don't just activate the I-frames list based on the > trickmode flag? You mean GST_SEEK_FLAG_TRICKMODE vs GST_SEEK_FLAG_TRICKMODE_KEY_UNITS? The latter is currently used. I don't know, why? :) Also the main problem with all this is that I'm not aware of a single stream with I frame playlists that actually has useful TS fragments in there that can be decoded on their own. As such, enabling usage of I frame playlists generally causes a streaming error at this point. > Any use case where we want the decoder/demux to actually drop the > non-i-frames buffers? Perhaps because the I-frame lists might not contain > audio? I don't know, depends on the stream I'd say? Because of that we should keep it configurable in the seek event, but with which flags?
http://docs.unified-streaming.com/documentation/vod/player-urls.html The a-team trailer there has a valid I-frame playlist that we can handle. We should remember this URL for the future.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/316.