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 767682 - Mpeg DASh live streaming header's update
Mpeg DASh live streaming header's update
Status: RESOLVED DUPLICATE of bug 777206
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.5
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-15 08:48 UTC by WeiChungChang
Modified: 2018-05-06 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description WeiChungChang 2016-06-15 08:48: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.
Comment 1 Sebastian Dröge (slomo) 2016-06-17 08:10:18 UTC
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.
Comment 2 WeiChungChang 2016-06-18 01:10:27 UTC
dear Slomo:

you can access the test URL by 

http://24x7dash-i.akamaihd.net/dash/live/900080/elemental/dash.mpd

Thank you.
Comment 3 Sebastian Dröge (slomo) 2016-06-21 08:49:04 UTC
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
Comment 4 sraut 2017-03-12 07:37:31 UTC
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.
Comment 5 WeiChungChang 2017-03-13 01:14:01 UTC
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.
Comment 6 Sebastian Dröge (slomo) 2018-05-06 13:09:45 UTC
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 ***