GNOME Bugzilla – Bug 767682
Mpeg DASh live streaming header's update
Last modified: 2018-05-06 13:09:45 UTC
Dear members: I met a problem under my develop board which bases on older GStreamer (1.4.5) branch bur had also checked the latest version also. The problem is when live streaming Mpeg DASH, on my side sometimes I got (read in) a wrong stream which may lead to MOSAIC (decode fail) issue. The problem is: when MPD is updated, a default "slow start" policy is applied as below. ... #else /* slow start */ representation = gst_mpdparser_get_lowest_representation (rep_list); #endif ... It makes the representation to become the lowest bit-rate one. However, at least for 1.4.5 I see no header of the lowest bit-rate is downloaded. It will make us to decode the lowest bit-rate representation by the codec-data from other representation. So it definitely will make a decode fail & MOSAIC happens. I search adaptivedemux.c & found there are 4 places where will set "stream->need_header = TRUE". I think only stream->need_header = TRUE we will update (download) a new header again for representation of the lowest bit-rate. The 4 places are listed below: 1. gst_adaptive_demux_expose_stream() 2. gst_adaptive_demux_src_event - case stream->need_header = TRUE; 3. gst_adaptive_demux_stop_tasks() 4. when gst_adaptive_demux_stream_select_bitrate() returns TRUE - means we have a bit-rate change. For 1.4.5,the slow start logic goes through the execution path about: from gst_adaptive_demux_updates_loop -> gst_adaptive_demux_update_manifest -> gst_adaptive_demux_update_manifest_default ->gst_dash_demux_update_manifest_data -> gst_dash_demux_setup_mpdparser_streams -> gst_mpd_client_setup_streaming But it seems that there is no chance to set need_header = TRUE so once we jump to the lowest bit-rate representation & previous header does not match, we will get problem. Could anyone help to check the problem? Should we need to set need_header as TRUE every time when we update manifest? static GstFlowReturn gst_adaptive_demux_update_manifest (GstAdaptiveDemux * demux) { ... ret = klass->update_manifest (demux); if (ret == GST_FLOW_OK) { ... + for (iter = demux->streams; iter; iter = g_list_next (iter)) { + GstAdaptiveDemuxStream *stream = iter->data; + stream->need_header = TRUE; + } ... } return ret; } Thank you.
Can you test if this is still a problem with 1.8.2? There were a lot of changes in adaptivemux and dashdemux in the meantime. Or alternatively provide a stream and a way for reproducing this easily so someone else can check. Having a stream that shows this problem would be useful to have in any case.
dear Slomo: you can access the test URL by http://24x7dash-i.akamaihd.net/dash/live/900080/elemental/dash.mpd Thank you.
This stream gives 404 errors here when downloading the fragments, e.g. http://24x7dash-i.akamaihd.net/dash/live/900080/elemental/dash_video300-20160610T232545-1465750774.mp4
Hi WeiChungChang, Is there a way to reproduce the bug? I am new to Gstreamer and looking for some good newbie bugs to start contributing to. Please let me know if anybody is working on this bug. If not, will it be possible for me to work on it. (It will be great if you can let me know what I need to learn to understand, reproduce and tackle the issue.) Thank you.
Dear Sraut: The bug: https://bugzilla.gnome.org/show_bug.cgi?id=777206 The solution: https://bug777206.bugzilla-attachments.gnome.org/attachment.cgi?id=343415 You can reproduce it by the link or do simulate (a good practice by trying yourself to make this issue happen). The patch has been checked in several weeks ago. Thank you.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 777206 ***