GNOME Bugzilla – Bug 731330
mpegtsdemux fixing PCR calculate_skew function
Last modified: 2018-05-06 11:00:57 UTC
hi I am trying to fix hlsdemux-er to don't generate some much elements for same video and audio codecs And I have this problem some hls segments (ts) if you switch quality don't have proper continuously increasing PCR calculate_skew: gstpcr 0:00:11.733333333, buftime 0:00:00.000000000, base 0:00:01.400000000, send_diff 0:00:10.333333333 calculate_skew: gstpcr 0:00:11.900000000, buftime 0:00:00.000000000, base 0:00:01.400000000, send_diff 0:00:10.500000000 next ts file calculate_skew: gstpcr 0:00:11.816666666, buftime 0:00:10.541667000, base 0:00:01.400000000, send_diff 0:00:00.000000000 it just happens :) http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mpegtsdemux/mpegtspacketizer.c#n1290 as pcr->last_pcrtime - gstpcrtime > PCR_GST_MAX_VALUE / 2 don't don't mach problem or pcr->last_pcrtime - gstpcrtime > 15 * GST_SECOND And I really don't understand what the hell this expressions fix? after all as in my situation pcr->last_pcrtime - gstpcrtime = 83333334 PCR_GST_MAX_VALUE / 2 = 47721858849962 15 * GST_SECOND = 15000000000 I think that this expressions should be contrariwise or I don't get point for this Any idea ???? my testing stream GST_DEBUG="*:3,tsdemux:0,hlsdemux:0,mpegtspacketizer:4" gst-launch-1.0 playbin uri="http://live.mdragon.org/gearmix3/bbbfulluny.m3u8" and log http://pastebin.com/h6eUDDMC
Note that those checks are inside a clause that already checks the PCR has decreased. By subtracting the new (smaller) value from the previous value, it first checks: Is the result very very large (ie, did the PCR wrap around back to 0), or did it jump backward by more than 15 seconds. So the calculations seem to be doing what they're intending. As per http://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-3.4.11 - if the stream timestamps or continuity counters are discontinuous between fragments, the EXT-X-DISCONTINUITY tag must be used. If that is done, GStreamer will generate a DISCONT flag and handle the timestamp jump properly.
Also note that other players than GStreamer (e.g. the one on iOS) are much more picky about the correct use of the EXT-X-DISCONTINUITY tag.
this isn't EXT-X-DISCONTINUITY problem If you playing one stream quality there isn't problem but problem show up if hls change to better/different quality with same video/audio codec but it isn't EXT-X-DISCONTINUITY segment My idea is to don't generate big part of pipeline for every quality in hls stream We should do this only for EXT-X-DISCONTINUITY segments. I want to feed same demuxer(tsdemux) with different qualities. But PCR isn't continuously increasing for some fragments in moment of change :( I model this situation with my single hls with various qualities (in one stream) and I found this PCR problem then I modifies hlsdemuxer to generate GST_BUFFER_FLAG_SET (buffer, GST_BUFFER_FLAG_DISCONT); for every first fragment buffer but tsdemuxer don't handle it right and playing stop log http://pastebin.com/WamtTNyG
After switching quality we currently always recreate the demuxer/decoder pipeline parts as we don't know if any codec or the topology changes. We talked about that in another bug already :) If you implement support for detecting the few cases where it is safe to continue using the existing pipeline, you will still need to make sure that the first buffer of the new playlist has the DISCONT flag set on it.
All in plan :) I plan to check audio/video codecs I also generate DISCONT for first buffer But still http://pastebin.com/WamtTNyG as http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/mpegtsdemux/mpegtspacketizer.c#n1290 pcr->last_pcrtime - gstpcrtime > PCR_GST_MAX_VALUE / 2 don't don't mach problem or pcr->last_pcrtime - gstpcrtime > 15 * GST_SECOND And I can't find any special use for buffers with DISCONT flag in mpegtspacketizer tsdemux any idea?
Created attachment 278023 [details] [review] generate DISCONT flag for every first buffer use my patch with my test stream GST_DEBUG="*:3,tsdemux:0,hlsdemux:5,mpegtspacketizer:4" gst-launch-1.0 playbin uri="http://live.mdragon.org/gearmix3/bbbfulluny.m3u8" stream(same aac and h264 with different bitrate and resolution) #EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXTINF:10.541667, bbbfull320x180-1.ts #EXTINF:10.208333, bbbfull640x360-2.ts #EXTINF:12.291667, bbbfull640x360-3.ts #EXT-X-ENDLIST
and this patch https://bug729364.bugzilla-attachments.gnome.org/attachment.cgi?id=277940
So what is the essence of this bug actually? It sounds more like a support issue for an experiment you're doing with hlsdemux. There's some discontinuity in the PCRs, and tsdemux doesn't pick up on that discontinuity, even with the DISCONT flag set for the first buffer of each new fragment?
Ideally tsdemux should use a different algorithm for such streams (timed, but not-really-live (as in not from udp or dvb)). If upstream tells us there's a discontinuity, we should act accordingly and pickup a new base time reference.
HLS has some for support advertisement so any fragment marked with DISCONT should work just fine
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!