GitLab

For 1.18 mpegtsmux was reworked for better conformance in !337 (merged) - in the process the calculation for when to insert a PAT/PMT packet was reworked in commit 9190541e from a last_pat_ts recording approach to a next_pat_pcr approach.

Before the last timestamp when PAT was emitted was recorded and then from there it would look whether it's time to insert the next one. Afterwards the timestamp for the next PAT emission is recorded instead, but the current timestamp doesn't influence it at all. After it's initially set, it's just now always incremented by the configured interval, even if the current timestamp jumped ahead for some reason. As a result, if the buffer timestamp suddenly jumps ahead for some reason, every 188 byte PCR PES packet will be preceded with PAT, PMT and SI (if any are configured) packets until it catches up from the constant interval increment - if the time jump was in hours, this catch-up effectively might never happen and thus the whole MPEG-TS stream after that point is at least triple the size (without SI) or more.

I think it's a straightforward fix to provide a MR for, but I'm not sure what the behaviour intention here would be:

• should the configured interval be a minimum - just set the next_*_pcr from cur_ts + interval instead of next_*_pcr += interval
• should the configured interval be a best effort, where if it's a little bit late once, the next interval should be just appropriately shorter - keeping the existing logic, but detecting bigger timestamp differences to reset it to cur_ts base instead to handle the jumps
• something else (like this just ought to not happen without DISCONT from upstreams?)

I got hit by this due to what !2011 tries to solve - amcvideoenc gave a timestamp of 0 in first buffer, and then the correct ones immediately after it, which were over 100 hours PTS values.