GitLab

Since 1.18, by default the first stream created (based on the pad creation order) is considered the PCR stream. Yet this PCR stream may not be the first stream whose buffers' are muxed, which results in writing stream data prior to writing the PAT/PMT.

In 1.16, despite the logic introduced by 3f0463c4, it isn't until a few lines below that the stream is initially created. So despite logging that a PCR stream had been selected and calling tsmux_program_set_pcr_stream it did not have any effect. Afterwards the first stream used for output is selected as the PCR stream here.

So it appears quite intentional to choose the first program stream as the PCR stream. However, at least for my use case, it is common not to know if the first buffer will be audio or video until after linking the pipeline. In this case the behavior of 1.16 where it selects the first stream buffer for output as the PCR stream is needed.

I do hesitate to create an MR to remove that logic as I only have a limited familiarity with the code. Perhaps it would be better instead to ensure that the SI structures are written before the first stream data?

Reproduction: gst-launch-1.0 audiotestsrc num-buffers=1 timestamp-offset=1 ! avenc_aac ! aacparse ! .sink_101 mpegtsmux name=mux ! tsdemux ! fakesink videotestsrc num-buffers=1 ! x264enc ! mux.sink_102

In this case audio is selected as the PCR stream as it is linked first. Yet due to audio's 'timestamp-offset=1' the first video buffer is sent before the PAT/PMT. If you enable logging in the demuxer there will be a bunch of "PID 0x0066 Saw packet on a pid we don't handle" messages.