qtdemux sends an extra segment event when segmented with edit lists
When demuxing an fmp4 with a single edit list there are two segment events, the first being the correct edit list, and the second being a dummy segment ending at the end of the asset (so the final cts). This is because of gst-plugins-good!643 (merged) which made fragmented inputs with only one segment also fire a dummy segment event with the total length of the asset (for compatibility with some proprietary programs).
The problem with this of course is that I want the demuxer to respect the edit list and discard any further data, but it gets the whole thing!
To simply demonstrate the problem, here is a fragmented input with one 1s edit list:
% GST_DEBUG=qtdemux:5 gst-launch-1.0 multifilesrc location=flowers_1sec_%02d.fmp4 ! decodebin ! autovideosink 2>&1 | grep 'new segment'
0:00:00.042229197 2587587 0x55e9289362a0 DEBUG qtdemux qtdemux.c:4953:gst_qtdemux_stream_update_segment:<qtdemux0:video_0> new segment 0 from 0:00:01.066666666 to 0:00:02.066666666, time 0:00:00.000000000
0:00:00.042398097 2587587 0x55e9289362a0 DEBUG qtdemux qtdemux.c:4953:gst_qtdemux_stream_update_segment:<qtdemux0:video_0> new segment 0 from 0:00:02.133333332 to 0:00:05.000000000, time 0:00:01.066666666
I'm happy to work on a fix for this, but it would be great if you could point me in the correct direction. I've added an ignore-dummy
property on qtdemux which disables the dummy segment and I'm happy to put that up for review if that's an acceptable approach?
cc @ystreet as you wrote the initial patch