tsdemux: Regressed DISCONT buffer handling with program changes
I have a pipeline where tsdemux is fed via an appsrc, whereas the incoming stream might switch.
To CPU efficiently detect this switch (by the new code not running a full compare for every PAT/PMT since !3421 (merged)), even if being unlucky and having various continuity counters line up between the different streams, @bilboed suggested I set the GST_BUFFER_IS_DISCONT flag bit on the first GstBuffer put into the appsrc after a switch. So I did that.
Result: now the existing program switch detection that was restored via !3530 (merged) doesn't even trigger and everything stalls in the pipeline as the pads aren't even switched around when I do the stream switch between programs that use a completely different set of PIDs even.
It works if I either remove the DISCONT flag setting on the buffer again OR I revert !3421 (merged) and !3530 (merged) (former just to cleanly revert the latter). Because of that, I would consider this another regression in main
and 1.20
.
I also checked with debug pad probes that after the DISCONT buffer I'm not getting any downstream events on the demuxer pads, no EOS, no FLUSH or anything at all. Also no data buffers. The multiqueue after demuxer is empty, as the demuxer source pads just become silent (the PIDs are different now).
If I switch between different streams that happen to use the same PIDs, then data flow on the same PIDs continues, but without any events sent nor the pads re-added (as the program change didn't trigger), so downstream elements seem to get very unhappy on this right now and thus eventually fill the multiqueue. There was a spurious gap event on one of the demuxer source pads sent, but ca 5 seconds after the stream switch.
All these problems go away if I simply stop setting DISCONT on the first buffer of the new stream, but then there's no solution for properly covering a known stream switch while not risking on being extremely unlucky on mpeg-ts counters matching.