This is a custom mapping. There isn't much needed apart from that to store vp9
in mpeg-ts since the bitstream is self contained.
Since there are no official specification we don't want people to be mistaken in
believing that. Therefore that mapping is only used in the muxer if the (new)
property `enable-custom-mappings` is set to TRUE.
* The MPEG-TS Stream Type is Private Data (0x6) with the registration descriptor
set to `VP09`.
* The Access Unit are VP9 frames stored in PES packets
* As there is no emulation prevention byte in VP9 elementary stream, the can be
misdetection of PES start code. To avoid this, the start of a PES packet must
be signalled using the Payload Unit Start Indicator in the transport packet
header
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7707>
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>
There is an existing PMT mapping between PCR_%s and an mpegtsmux sink
pad name, where %s equals the program number that the PCR corresponds
to. We re-purpose this functionality to also support a mapping between
PCR_%s and an arbitrary PID. If this mapping is set, then the header PCR
PID is set to this value, and PCR is attached to the stream with this
PID.
Note: the current implementation also attaches PCR to the video stream,
so this may be inefficient.
Co-authored-by: Jordan Yelloz <jordan.yelloz@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5726>
- Don't try to make the parameters match `GHFunc`. Use a dedicated
callback for `g_hash_table_foreach`.
- Don't try to be clever with buffer memories. We're allocating a full
packet anyway, might as well memcpy and save on a lot of complexity.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5496>
This new property allows setting of PES stream number for AAC audio
and AVC video streams.
The stream number is subject to the following constraints:
1. it must be between 0 and 15 for video
2. it must be between 0 and 31 for audio
Currently the PES stream number is hard-coded to zero for these
stream types.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4822>
