GNOME Bugzilla – Bug 755047
mssdemux/dashdemux: live playback regression
Last modified: 2015-09-16 07:24:51 UTC
Since adaptivedemux commit d1c5669a384dfb7bc451eb68ba1dbfe11675a149 live smooth-streaming playback is broken, a corrupted video frame is rendered and the pipeline stalls.
Can you provide a sample stream or some more information? What are the segments and timestamps coming out of mssdemux?
The stream pending segment events have these timing infos: stream 0x740a2a98 segment start: 0:00:00.000000000 position: 0:00:00.000000000 time: 0:00:00.000000000 base: 0:00:00.000000000 stream 0x740a9518 segment start: 0:00:00.000000000 position: 0:00:00.000000000 time: 0:00:00.000000000 base: 0:00:00.000000000 Before the adaptivedemux change: stream 0x73f98aa8 segment start: 455:56:09.484400000 position: 455:56:09.484400000 time: 455:56:09.484400000 base: 0:00:00.000000000 stream 0x73f9a400 segment start: 455:56:09.484400000 position: 455:56:09.484400000 time: 455:56:09.484400000 base: 0:00:00.000000000
before: 0:00:00.956483281 1935 0x149cb80 INFO GST_EVENT gstevent.c:760:gst_event_new_segment: creating segment event time segment start=455:59:29.484400000, offset=0:00:00.000000000, stop=99:9 9:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=455:59:29.484400000, base=0:00:00.000000000, position 455:59:29.484400000, duration 99:99:99.999999999 0:00:00.956718281 1935 0x149cb80 DEBUG GST_EVENT gstevent.c:302:gst_event_new_custom: creating new event 0x73f045c0 segment 17934 0:00:00.956906718 1935 0x149cb80 INFO GST_EVENT gstevent.c:760:gst_event_new_segment: creating segment event time segment start=455:59:29.484400000, offset=0:00:00.000000000, stop=99:9 9:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=455:59:29.484400000, base=0:00:00.000000000, position 455:59:29.484400000, duration 99:99:99.999999999 after: 0:00:01.871956770 1974 0x19e8180 INFO GST_EVENT gstevent.c:760:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99: 99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999 0:00:01.872178853 1974 0x19e8180 DEBUG GST_EVENT gstevent.c:302:gst_event_new_custom: creating new event 0x740045e8 segment 17934 0:00:01.872352968 1974 0x19e8180 INFO GST_EVENT gstevent.c:760:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99: 99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999
Curious, can you also get me the timestamps (PTS is enough) that happen after the segment event? And also what qtdemux outputs (i.e. what it finds in the tfdt)?
Similar problem with this DASH live stream: http://bitlivedemo-a.akamaihd.net/mpds/stream.php?streamkey=bitcodin Not sure how we can get the PTS of beginning of the current segment that we would download. Would that be the availabilityStartTime or publishTime in the MPD?
This one is also unhappy: http://dash-live-streams.appspot.com/dash/manifest_e.mpd?drift=30
Or http://dash-live-streams.appspot.com/dash/manifest_h.mpd
(In reply to Sebastian Dröge (slomo) from comment #4) > Curious, can you also get me the timestamps (PTS is enough) that happen > after the segment event? And also what qtdemux outputs (i.e. what it finds > in the tfdt)? in both cases I see similar qtdemux logs: 0:00:01.333264739 2227 0x73f2a920 LOG qtdemux qtdemux.c:5040:gst_qtdemux_decorate_and_push_buffer:<qtdemux0> Pushing buffer with dts 456:21:01.484400000, pts 456:21:01.564400000, duration 0:00:00.040000000 on pad video_0 In adaptivedemux after setting the PTS of the buffer to push: 0:00:10.182807288 2831 0x71b02800 DEBUG adaptivedemux gstadaptivedemux.c:1462:gst_adaptive_demux_stream_push_buffer:<mssdemux0:video_00> buffer pts=99:99:99.999999999 The fragments don't seem to have a tfdt atom, I'll double-check.
Created attachment 311349 [details] adaptivedemux+qtdemux log
(In reply to Philippe Normand from comment #8) > (In reply to Sebastian Dröge (slomo) from comment #4) > > Curious, can you also get me the timestamps (PTS is enough) that happen > > after the segment event? And also what qtdemux outputs (i.e. what it finds > > in the tfdt)? > > in both cases I see similar qtdemux logs: > > 0:00:01.333264739 2227 0x73f2a920 LOG qtdemux > qtdemux.c:5040:gst_qtdemux_decorate_and_push_buffer:<qtdemux0> Pushing > buffer with dts 456:21:01.484400000, pts 456:21:01.564400000, duration > 0:00:00.040000000 on pad video_0 If it doesn't have any tfdt, where do those timestamps come from? You say below that adaptivedemux puts -1 on the buffers. Is 456:21:01.564400000 the value that is in the mss manifest? > In adaptivedemux after setting the PTS of the buffer to push: > > > 0:00:10.182807288 2831 0x71b02800 DEBUG adaptivedemux > gstadaptivedemux.c:1462:gst_adaptive_demux_stream_push_buffer:<mssdemux0: > video_00> buffer pts=99:99:99.999999999 Even for the first buffer of a segment?
(In reply to Sebastian Dröge (slomo) from comment #10) > (In reply to Philippe Normand from comment #8) > > (In reply to Sebastian Dröge (slomo) from comment #4) > > > Curious, can you also get me the timestamps (PTS is enough) that happen > > > after the segment event? And also what qtdemux outputs (i.e. what it finds > > > in the tfdt)? > > > > in both cases I see similar qtdemux logs: > > > > 0:00:01.333264739 2227 0x73f2a920 LOG qtdemux > > qtdemux.c:5040:gst_qtdemux_decorate_and_push_buffer:<qtdemux0> Pushing > > buffer with dts 456:21:01.484400000, pts 456:21:01.564400000, duration > > 0:00:00.040000000 on pad video_0 > > If it doesn't have any tfdt, where do those timestamps come from? You say > below that adaptivedemux puts -1 on the buffers. > > Sorry, the PTS is set correctly once before sending the segment event and afterwards it's invalid: 0:00:05.600407289 2997 0x71b02860 DEBUG adaptivedemux gstadaptivedemux.c:1462:gst_adaptive_demux_stream_push_buffer:<mssdemux0:video_00> buffer pts=457:32:15.484400000 0:00:05.600631977 2997 0x71b02860 DEBUG adaptivedemux gstadaptivedemux.c:1489:gst_adaptive_demux_stream_push_buffer:<mssdemux0:video_00> Sending pending seg: segment event: 0x73f045e8, time 0:00:05.601306768 2997 0x73f25920 LOG qtdemux qtdemux.c:1989:gst_qtdemux_handle_sink_event:<qtdemux0> handling stream-start event 0:00:05.601661873 2997 0x71b02860 DEBUG adaptivedemux gstadaptivedemux.c:1462:gst_adaptive_demux_stream_push_buffer:<mssdemux0:video_00> buffer pts=99:99:99.999999999 > Is 456:21:01.564400000 the value that is in the mss manifest? > Yes > > > In adaptivedemux after setting the PTS of the buffer to push: > > > > > > 0:00:10.182807288 2831 0x71b02800 DEBUG adaptivedemux > > gstadaptivedemux.c:1462:gst_adaptive_demux_stream_push_buffer:<mssdemux0: > > video_00> buffer pts=99:99:99.999999999 > > Even for the first buffer of a segment? No, the first buffer has a valid PTS, sorry for the confusion :)
Ok, makes sense then. Now the bonus question: what should be the stream time reported for 456:21:01.564400000, i.e. what the position query reports?
With current master the position query reports positions starting at 0 and before the adaptivedemux change the position reported was $huge_number :)
But what *should* it be? 0 would mean that you can't seek backwards, which at least in theory is possible :)
Created attachment 311363 [details] [review] patch attempt (probably too) naive implementation of period start and presentation offset reporting for mssdemux. Doesn't help much fixing the regression though, I think this needs more work :)
Created attachment 311407 [details] [review] adaptivedemux: Fix playback of live streams dashdemux seeks each live stream to its current fragment in the beginning, but the base class does not know about this. Update the demuxer segment with this seek so we generate the correct SEGMENT event and can actually play the stream. This needs some refactoring at some point.
Philippe, does this also help in your case?
Review of attachment 311407 [details] [review]: Looks good, we can think of some new API for this repositioning of the seek after the release.
For future reference, here's a live mss stream: http://live.unified-streaming.com/loop/loop.isml/Manifest?session_id=53860 Works with my patch, doesn't work without. Let's close this then
It works fine here as well, thanks Sebastian!