[Bug 700505] Video corruption when dashdemux changes bitrate

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=700505
  GStreamer | gst-plugins-bad | git

Thiago Sousa Santos <thiago.sousa.santos> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago.sousa.santos at collabo
                   |                            |ra.co.uk

--- Comment #3 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2013-06-02 15:59:36 UTC ---
(In reply to comment #2)
> 
> I am working on a fix where we can signal a decode group switch for a single
> stream when a representation switch is needed.

mssdemux has this same scenario, and it works because qtdemux knows hows to
handle a bitrate/resolution switch by reconfiguring itself and pushing a new
caps event downstream, informing the decoders/parsers of the change.

In the dashdemux case, qtdemux is simply ignoring the switch and continues
pushing data and the decoders/parsers will interpret the new data with the old
resolution/bitrate, leading to corrupted video/audio. The difference is that
MSS doesn't use 'moov' atoms with the track information, the track information
is sent directly in the caps event. Dashdemux, OTOH, sends another moov
everytime it switches bitrates, but qtdemux currently ignores all but the first
moov it receives.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.