There are quite a few reserved PID in the various MPEG-TS (and derivate)
specifications which we should definitely not use. Those PID have a certain
meaning and purpose.
Furthermore, a lot of the code in the muxer implementation also makes assumption
on the purpose of streams based on their PID.
Therefore, when requesting a pad with a specific PID, make sure it is not a
restricted PID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1561>
The audio/mpeg,mpegversion=2 caps in GStreamer refer to
MPEG-2 AAC (ISO 13818-7), not to the extended MP3 (ISO 13818-3),
which is audio/mpeg,mpegversion=1,mpegaudioversion=2/3
Fix the caps, and add handling for MPEG-2 AAC in both ADTS and raw
form, adding ADTS headers for the latter.
Until now, any streams in tsmux had to be present when the element
started its first buffer. Now they can appear at any point during the
stream, or even disappear and reappear later using the same PID.
Since we are not requiring that profile equals GST_JPEG2000_PARSE_PROFILE_BC_SINGLE,
(as the standard requires) we can allow profile to be null. We relax this condition because
OpenJPEG can't create broadcast profiles.
This adds two properties:
* scte-35-pid: If not 0, enables the SCTE-35 support for the current
program. This will write the proper PMT and send SCTE-35 NULL
commands (i.e. heartbeats) at a regular interval
* scte-35-null-interval: This specifies the interval at which the
NULL commands should be sent
Sending SCTE-35 commands is done by creating the appropriate SCTE-35
GstMpegtsSection and then sending them on the muxer. See the
associated example
Instead of using a static hardcoded PCR interval, allow the user
to configure it.
Also revert back the default to a 40 ms interval, that was changed
in recent patches for no good reason.
As sections can be provided by the user through send_event
when the element state is NULL, their lifetime is expected
to match that of the muxer, and they must be preserved when
the state changes
