After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730068 - hlsdemux in adaptive scenario isn't gapless
hlsdemux in adaptive scenario isn't gapless
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-13 16:53 UTC by m][sko
Modified: 2017-07-12 15:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hlsdemux use same pipeline for playlist with same codecs (9.43 KB, patch)
2014-06-13 07:29 UTC, m][sko
none Details | Review

Description m][sko 2014-05-13 16:53:34 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
Comment 1 m][sko 2014-05-27 06:32:37 UTC
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 ?
Comment 2 Sebastian Dröge (slomo) 2014-05-27 06:56:37 UTC
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.
Comment 3 m][sko 2014-05-27 09:59:49 UTC
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
Comment 4 Sebastian Dröge (slomo) 2014-05-27 10:26:13 UTC
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.
Comment 5 m][sko 2014-05-27 11:03:31 UTC
But we can still add this feature for hls with known codecs?
Comment 6 Sebastian Dröge (slomo) 2014-05-27 11:07:38 UTC
Yes, that should be possible
Comment 7 m][sko 2014-06-13 07:29:20 UTC
Created attachment 278389 [details] [review]
hlsdemux use same pipeline for playlist with same codecs

hlsdemux use same pipeline for playlist with same codecs
Comment 8 m][sko 2014-06-16 21:47:22 UTC
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
Comment 9 m][sko 2014-06-16 21:53:53 UTC
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?
Comment 10 m][sko 2014-08-06 21:25:54 UTC
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
Comment 11 Andoni Morales 2014-12-13 02:56:31 UTC
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)
Comment 12 Sebastian Dröge (slomo) 2017-03-02 17:56:55 UTC
This should be handled better in playbin3, or would be possible to support better there at least.
Comment 13 Edward Hervey 2017-07-12 15:08:48 UTC
No news in 3 years. Latest testing with playbin3 show the problem mostly gone