GNOME Bugzilla – Bug 695846
hlsdemux: No longer switches pads on playlist changes
Last modified: 2014-03-06 22:18:30 UTC
+++ This bug was initially created as a clone of Bug #695203 +++ gst-launch-1.0 playbin uri="https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8" -v - I see decoding errors/warnings from libav, also artefacts - sometimes criticals like: ** (gst-launch-1.0:31931): CRITICAL **: gst_fragment_get_buffer: assertion `fragment != NULL' failed (gst-launch-1.0:31931): GStreamer-CRITICAL **: gst_buffer_get_sizes_range: assertion `GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:31931): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object != NULL' failed I'm sure this used to work better a while back, or maybe it's just bad luck, I don't know.
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source: Not Found got another link ?
$ gst-launch-1.0 playbin uri=http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock 0:01:22.437680802 10834 0xe980f0 ERROR tsdemux tsdemux.c:1320:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 8, stream 10 0:01:22.500829756 10834 0xe980f0 ERROR tsdemux tsdemux.c:1320:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 12, stream 13 ** (gst-launch-1.0:10834): CRITICAL **: gst_fragment_get_buffer: assertion `fragment != NULL' failed (gst-launch-1.0:10834): GStreamer-CRITICAL **: gst_buffer_get_sizes_range: assertion `GST_IS_BUFFER (buffer)' failed (gst-launch-1.0:10834): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object != NULL' failed ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstFaad:faad0: Could not decode stream. Additional debug info: gstfaad.c(820): gst_faad_handle_frame (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstFaad:faad0: Failed to init decoder from stream Execution ended after 0:00:08.731503916 This is with -bad git from a few days ago. After updating just now, I don't get the criticals any longer (though I'm not sure why, I don't think anything changed recently..), but still the continuity errors and faad erroring out.
So, essentially hlsdemux has been broken since porting to 1.0. It no longer switches pads when switching playlists, resulting in tsdemux receiving new data with incorrect PID....
The criticals are still there in git master btw, here's how I can reproduce them: $ git clone git://github.com/jbochi/hls-loop.git $ cd hls-loop $ python hls-loop.py $ gst-launch-1.0 playbin uri=http://localhost:5000/variant.m3u8 (This is the bipbop_4x3_variant.m3u8 playlist from above it seems).
gsthlsdemux.c:switch_pads() is supposed to add/remove pads on fragment change. But only does that now if the caps are changing. That's something that was accidentially changed in the 0.11 port. Patch coming after testing that it works :)
Created attachment 248615 [details] [review] hls.diff This should fix it, but breaks it even more. The segments seemed to be handled wrong.
Review of attachment 248615 [details] [review]: ::: ext/hls/gsthlsdemux.c @@ +708,1 @@ bufcaps = gst_fragment_get_caps (fragment); That sounds wrong, it always unconditionally switches
when always switching pads ... it ends up quickly adding two new (pending) decodebin after the first one. The first one (0-10s) ends ... and then for some reason the 3rd decodebin (20-30s) gets plugged instead of the 2nd one (10s-20s).
And in case you are wondering, tsdemux is pushing the right segments :)
Well, how would you detect if a new pad has to be added or not? There's nothing in HLS that tells us that the next fragment is the seamless continuation of the previous fragment. We could check the caps for equality, but the caps should always be equal anyway "video/mpegts". So either we always switch or we can't do anything about the continuation errors that Tim reported. Independent of that the pad switching itself is completely broken as my patch shows :) The segments look correct, yes, I'm not sure yet what exactly is the problem. Might be related to the about-to-finish bug, the handling is almost the same.
If it's not a continuation, there will be a #EXT-X-DISCONTINUITY in the m3u file. And I think Apple's implementation is quite strict about it.
Or if we skip bitrates. So the plan would be to only switch pads if bitrate change or #EXT-X-DISCONTINUITY? And in all other cases we can assume that nothing fundamentally changed? Might be a bit tricky for seeking :)
This fails even more interesting now (not related to my changes yesterday, was like that before already): Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock 0:00:02.672400881 30171 0x7f5960002800 WARN tsdemux tsdemux.c:1531:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 8, stream 10 0:00:07.441051530 30171 0x7f5938007f00 WARN pulse pulsesink.c:678:gst_pulsering_stream_underflow_cb:<pulsesink1> Got underflow 0:00:08.898228190 30171 0x7f5960002800 WARN tsdemux tsdemux.c:1531:gst_ts_demux_queue_data: CONTINUITY: Mismatch packet 12, stream 13 0:00:10.232472393 30171 0x7f5954002590 WARN audiodecoder gstaudiodecoder.c:1457:GstFlowReturn gst_audio_decoder_drain(GstAudioDecoder *):<faad0> still 1 frames left after draining 0:00:10.234224264 30171 0x7f5954002590 WARN audiodecoder gstaudiodecoder.c:2782:GstFlowReturn _gst_audio_decoder_error(GstAudioDecoder *, gint, GQuark, gint, gchar *, gchar *, const gchar *, const gchar *, gint):<faad0> error: decoding error: Maximum number of bitstream elements exceeded 0:00:10.235187470 30171 0x7f5954002590 WARN default codec-utils.c:83:guint gst_codec_utils_aac_get_sample_rate_from_index(guint): Invalid sample rate index 14 0:00:10.235235096 30171 0x7f5954002590 WARN default codec-utils.c:105:gint gst_codec_utils_aac_get_index_from_sample_rate(guint): Invalid sample rate 0 0:00:10.235254326 30171 0x7f5954002590 WARN default codec-utils.c:83:guint gst_codec_utils_aac_get_sample_rate_from_index(guint): Invalid sample rate index 14 0:00:10.235287835 30171 0x7f5954002590 WARN audiodecoder gstaudiodecoder.c:2782:GstFlowReturn _gst_audio_decoder_error(GstAudioDecoder *, gint, GQuark, gint, gchar *, gchar *, const gchar *, const gchar *, gint):<faad0> error: decoding error: Invalid number of channels 0:00:10.237498280 30171 0x7f5954002590 WARN audiodecoder gstaudiodecoder.c:2782:GstFlowReturn _gst_audio_decoder_error(GstAudioDecoder *, gint, GQuark, gint, gchar *, gchar *, const gchar *, const gchar *, gint):<faad0> error: decoding error: Bitstream value not allowed by specification 0:00:10.239117599 30171 0x7f5954002590 WARN audiodecoder gstaudiodecoder.c:2782:GstFlowReturn _gst_audio_decoder_error(GstAudioDecoder *, gint, GQuark, gint, gchar *, gchar *, const gchar *, const gchar *, gint):<faad0> error: decoding error: Unexpected fill element with SBR data 0:00:10.239338295 30171 0x7f5954002590 WARN faad gstfaad.c:820:gst_faad_handle_frame:<faad0> error: Failed to init decoder from stream
This version of bipbop works fine though: http://devimages.apple.com/iphone/samples/bipbop/gear4/prog_index.m3u8
This should be a bit more correct now: commit 0a32c5f7a4b3e522f1b4407ac98817d32d62f190 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Mar 1 17:13:58 2014 +0100 hlsdemux: Implement proper handling of discontinuities It's not really correct yet for seeks but better than what we had before. See https://bugzilla.gnome.org/show_bug.cgi?id=695846 Still the stream here is not playing without problems yet.
Works here now after this commit commit d2880dce68591d9b85ba777abcb4f4e4f6baa70c Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Mar 6 23:14:10 2014 +0100 hlsdemux: Implement proper segment handling https://bugzilla.gnome.org/show_bug.cgi?id=695846 https://bugzilla.gnome.org/show_bug.cgi?id=723268