In DASH, after a bitsream change, the video decoding pipeline may need to be reset if the spatial resolution of the content has changed.
This is typically achieved by passing new codec specific parameters to the decoder.

In most DASH/ISOBMFF contents available on the web today, the codec parameters are only included in the moov boxes of the initialization segments (and not provided per fragment).

The DASH demux therefore appends the correct initialization segment to each first segment after a bitstream switch.

This is however not sufficient to trigger the proper reinitialization of the decoder, since the isomp4 demux ignores any subsequent moov box it receives after the first one. 

In the first implementation of the DASH demux, this was solved by exposing the new stream in a new pad, thus triggering the instantiation of a brand new demux.

This behaviour was deprecated during the integration into gst-plugins-bad, with commit logs hinting at modifications into qtdemux to accept new moov after initialization: this doesn't seem to have been fully tested.

The following streams will output garbage after the first bitstream switch that corresponds to a change in resolution:

http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys13/redbull_4sec.mpd

http://imtc1.rd.francetelecom.com:8080/DASH/MP4/big_buck_bunny_CappedVBR_Multirate_4s_0_AudioVideo_LiveProfile.mpd

http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mp