qtdemux: Don't emit GstSegment correcting start time when in MSE mode
When using qtdemux in a pipeline that should only work as a pure demuxer (not for actual playback), the GstSegment shouldn't emit new GstSegments to correct the start time (jump to the future) to ensure that the user experiences no playback delay. By doing so, it's generating the wrong segments when an append of data from the past happens. When that happens, downstream elements such as parsers (eg: aacparse) may clip those buffers laying before the GstSegment and create problems on the GStreamer client app (eg: WebKit).
Getting buffers clipped out because of the wrong GstSegments started becoming a problen when this commit was introduced:
ab6e49e9 audioparsers: add back segment clipping to parsers that have lost it
This clipping makes test DASH shaka 35 from MVT tests[1] to fail in WebKitGTK/WPE (at least) and can potentially cause a number of other problems in the WebKit Media Source Extensions (MSE) code.
Note that this new behaviour of not emitting new GstSegments only makes sense when qtdemux is being used as a pure demuxer and not as part of a regular pipeline. This is why the mse_mode flag has been added. It will make qtdemux behave differently in push mode, taking decisions that meet the expectations for an MSE-like processing mode. This kind of tweaks have been done in the past for MSS streams, for instance.
Co-authored by: Alicia Boya García ntrrgc@gmail.com
...who suggested to add mse_mode flag and to use "variant: mse-bytestream" in the caps to identify that mode, as proposed in her unmerged patch: