GNOME Bugzilla – Bug 730068
hlsdemux in adaptive scenario isn't gapless
Last modified: 2017-07-12 15:08:48 UTC
hlsdemux in adaptive scenario isn't gapless gst-launch-1.0 playbin uri="http://playertest.longtailvideo.com/adaptive/bbbfull/bbbfull.m3u8" from mailing list http://gstreamer-devel.966125.n4.nabble.com/hlsdemux-adaptive-situation-isn-t-always-gapless-td4666921.html
Are we really need to create another another decoder parser,.. for every video quality? hls spec. has codec description and we can create another set only if audio/video codec really change. And in case we don't have this information we can keep feeding current video/audio decoders. Are there any specific reasons why we create another set of demuxe/parser/decoder ?
The reason is that the codecs or container might change, or even the topology might change (e.g. the number of streams). If we don't create a new group for that in decodebin, what will happen is that we get a not-negotiated flow return the next time something is pushed. Of course this is all a hack and the real solution would be to implement renegotiation inside decodebin. But that's not there yet.
I don't have problem that we create new container if codecs really changed But I have problem that we create new container if codecs don't changed(hlsdemux switch to different quality with lower/higher resolution but still same decoders). Because in most cases it is really same video/audio codecs
Yes, problem is that we can't know that in hlsdemux unless the container format, codec, etc is specified in the playlist... which it is usually not. Ideally we just need renegotiation support in decodebin which will magically fix all this.
But we can still add this feature for hls with known codecs?
Yes, that should be possible
Created attachment 278389 [details] [review] hlsdemux use same pipeline for playlist with same codecs hlsdemux use same pipeline for playlist with same codecs
test adaptive stream http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8 #EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=232370,CODECS="mp4a.40.2, avc1.4d4015" gear1/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=649879,CODECS="mp4a.40.2, avc1.4d401e" gear2/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=991714,CODECS="mp4a.40.2, avc1.4d401e" gear3/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1927833,CODECS="mp4a.40.2, avc1.4d401f" gear4/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=41457,CODECS="mp4a.40.2" gear0/prog_index.m3u8
But I still need something to notify tsdemux to 1.don't check continuity counter or or 2.dont set new segment http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mpegtsdemux/tsdemux.c#n1902 this is design problem any idea?
Any advice how to handle tsdemux problem? every time I start to feed tsdemux with segments of different bitrate tsdemux get wrong continuity counter => whole buffer is dump(this can by fixed) and worst problem is that new segment event is released and whole pipeline pause and if anybody can look at my patch for hlsdemux part
Another reason to recreate the demuxers is that the PID's for audio and video in mpegt-ts streams are not guaranteed to be the same for different bitrates, so that needs to be handled correctly in tsdemux too (at least this was not supported in tsdemux a few years ago)
This should be handled better in playbin3, or would be possible to support better there at least.
No news in 3 years. Latest testing with playbin3 show the problem mostly gone