[Bug 762933] dashdemux: fails to download initialisation segment when switching bitrates

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762933

--- Comment #2 from A Ashley <bugzilla at ashley-family.net> ---
Created attachment 322837
  --> https://bugzilla.gnome.org/attachment.cgi?id=322837&action=edit
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) passes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.