GNOME Bugzilla – Bug 762933
dashdemux: fails to download initialisation segment when switching bitrates
Last modified: 2018-11-03 13:46:59 UTC
Occasionally dashdemux switches bitrates but fails to download the initialisation segment for the new bitrate. This typically causes the decoder that is downstream of dashdemux to produce numerous decode errors. As an example, here is part of an HTTP access log: 2016-02-12T16:08:54.623Z/dash2/dash-multi-clear/video6/Header.m4s 2016-02-12T16:08:54.769Z/dash2/dash-multi-clear/audio1/4001040.m4s 2016-02-12T16:08:54.999Z/dash2/dash-multi-clear/video6/4001040.m4s 2016-02-12T16:08:57.831Z/dash2/dash-multi-clear/manifest.mpd 2016-02-12T16:08:58.952Z/dash2/dash-multi-clear/audio1/4001041.m4s 2016-02-12T16:09:02.151Z/dash2/dash-multi-clear/manifest.mpd 2016-02-12T16:09:02.754Z/dash2/dash-multi-clear/video4/4001041.m4s 2016-02-12T16:09:03.162Z/dash2/dash-multi-clear/audio1/4001042.m4s 2016-02-12T16:09:06.012Z/dash2/dash-multi-clear/video4/4001042.m4s When switching from "video6" representation to the "video4" representation, it is not downloading video4/Header.m4s. I have managed to produce a unit test that reproduces the problem, which I will attach to this ticket. I have not yet managed to work out why it is going wrong, but I suspect it is related to the manifest refresh, which is set to happen after every segment.
Created attachment 322786 [details] [review] dashdemux: tests: check adaptive bitrate logic during manifest refresh This test is based upon the patches from the following other tickets: https://bugzilla.gnome.org/show_bug.cgi?id=762147 https://bugzilla.gnome.org/show_bug.cgi?id=762149 https://bugzilla.gnome.org/show_bug.cgi?id=762150
Created attachment 322837 [details] [review] dashdemux: copy currently selected Representation during manifest refresh I've found the problem. During a manifest reload, a new GstMpdClient is created, along with new GstActiveStream objects for each active AdaptationSet. The function gst_dash_demux_update_manifest_data() does not copy over the currently selected representation information from the old to the new GstActiveStream. This means that the new GstActiveStream has its currently selected representation_idx set to zero, regardless of the currently selected bitrate. If a manifest refresh occurs and at the same time a bitrate switch occurs to the lowest bitrate (representation index 0) from a higher bitrate (representation index > 0), the code path that causes a header to be downloaded is not triggered because stream->representation_idx is already set to zero. This causes video decode errors because the decoder is using the wrong initialisation data. This patch copies the currently selected Representation for every active stream. This allows the code that decides if a header download is required to function correctly. With this patch applied, the testBitrateSwitchingDuringManifestRefresh test (which is in attachment 322786 [details] [review]) passes.
(In reply to A Ashley from comment #1) > Created attachment 322786 [details] [review] [review] > dashdemux: tests: check adaptive bitrate logic during manifest refresh > > This test is based upon the patches from the following other tickets: > > https://bugzilla.gnome.org/show_bug.cgi?id=762147 > https://bugzilla.gnome.org/show_bug.cgi?id=762149 > https://bugzilla.gnome.org/show_bug.cgi?id=762150 .. actually that's not quite right .. The test patch requires the following patches: https://bugzilla.gnome.org/attachment.cgi?id=322381 which is from ticket https://bugzilla.gnome.org/show_bug.cgi?id=758387 Plus the three patches from https://bugzilla.gnome.org/show_bug.cgi?id=762147 It was written on top of the patches from: https://bugzilla.gnome.org/show_bug.cgi?id=758387 https://bugzilla.gnome.org/show_bug.cgi?id=762147 https://bugzilla.gnome.org/show_bug.cgi?id=762149 https://bugzilla.gnome.org/show_bug.cgi?id=762150 .. because I was lazy and started from a branch with all those already applied, but they should not be required to make this test work.
Created attachment 355326 [details] [review] dashdemux: copy currently selected Representation during manifest refresh Re-based to current master.
Created attachment 358941 [details] [review] tests: dashdemux: check adaptive bitrate logic during manifest refresh Updated to master. It is based upon the following other open tickets: Re-enable dash_demux tests: https://bugzilla.gnome.org/show_bug.cgi?id=781632 Add infrastructure to perform tests on live DASH streams: https://bugzilla.gnome.org/show_bug.cgi?id=762149
Created attachment 358942 [details] [review] dashdemux: copy currently selected Representation during manifest refresh Re-based to master
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/353.