mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-22 12:00:11 +00:00
f11735c97b
When configured in constant bitrate mode, the muxer computes timing information using the configured bitrate and the byte counter (now = bytes sent / byterate). When an application changes the bitrate in CBR mode during playback, the relationship between bytes sent and bitrate is no longer valid so new timing values will be off by the ratio of the old bitrate to the new bitrate. Furthermore, it will upset the way that padding is generated. pad_stream() works by trying to fit the byte counter to now * byterate. The result is that when decreasing bitrate, the muxer stalls, waiting until the byte counter is in agreement with now * byterate. Also, when increasing bitrate, the padding will spike in volume until the byte counter fits with now * byterate. If the byte counter is scaled by the ratio of new bitrate / old bitrate when adjusting bitrate, then padding is generated in a way that applications would more likely expect. One detail this change doesn't yet address is whether the next PCR will match up optimally with the previous PCR right after the byte counter is scaled. In that case, some correction may be necessary. Also, perhaps the user should be prevented from changing from bitrate=0 to bitrate=nonzero during playback since it's not straightforward how to scale the byte counter in that case. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7158> |
||
|---|---|---|
| .. | ||
| tsmux.c | ||
| tsmux.h | ||
| tsmuxcommon.h | ||
| tsmuxstream.c | ||
| tsmuxstream.h | ||