mpegts: PTS calculated from bitrate is wrong
When mpegtsmux has bitrate attribute set, it tries to write at exactly this bitrate, and sets PTS for outgoing buffers according to bytes written since beginning of stream - see gst/tsmux/tsmux.c
if (mux->bitrate)
GST_BUFFER_PTS (buf) =
gst_util_uint64_scale (mux->n_bytes * 8, GST_SECOND, mux->bitrate);
If (total bitrate of incoming streams) <= bitrate that's ok.
However, if user miscalculates and sets muxer bitrate to a value that is too low, muxer PTS counter starts to run ahead of the incoming streams. For instance, buffers might enter muxer with PTS=100,000,000,000 and exit with PTS=101,000,000,000. This leads to synchronized sink elements (udpsink for instance) delaying these buffers, so in effect we are losing some frames and output gets really jerky.
Please note that it is very easy for a user to miscalculate, since it is hard to estimate bitrate of subtitles, and muxer never complains if the actual bitrate exceeds nominal.
I am not sure what would be the right solution and if this code is really needed. What's the point really? Muxer always selects the "best" buffer among sinks - this is the one with the lowest PTS. So, PTS is monotonous. Why should it throw away this perfectly good PTS and replace it with some calculated value?
gstbasetxmux.c contains code for preserving incoming PTS, but it gets called AFTER the code above and has no effect.
if (!GST_CLOCK_TIME_IS_VALID (GST_BUFFER_PTS (buf)))
{
GST_BUFFER_PTS (buf) = mux->last_ts;
}
For my build I simply disabled this if statement so that incoming PTS (stored in last_ts) has priority. But I have no idea in what scenarios PTS calculation from bitrate is useful, so I can't make an MR.