When the muxer is operating in VBR mode, it's kind of expected
for now that we might not put the PCR in exactly the right place,
because the muxer doesn't schedule packets that way. In that case
don't warn constantly about the PCR ending up a few ms off target.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2295>
Some elements will make use of the automatically generated names to
create new pads in future muxer instances, for example splitmuxsink.
Previously we would've created a pad with a random pid that would become
"sink_0", and then on a new muxer instance a pad "sink_0" and tsmux
would've then failed because 0 is not a valid PID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2318>
Previously pads might have been requested already (e.g. in NULL state),
then reset was called (e.g. because changing state) and then a new pad
was requested. Resetting is re-creating the internal muxer object and as
such resetting the pid counter, so the next requested pad would get the
same pid as the first requested pad which then leads to collisions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2317>
Each stream stores the `program_array_index` of its position in its
program's `streams` array. When we remove a stream from this array, we
need to correct the `program_array_index` of all streams that were
backshifted by the removal.
Also extract the removal into a new function and add some more safety
checks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2266>
In order to always insert a PCR packet right on time, we need to
check whether one is needed when outputting any packet, not only
a packet for the PCR stream. Most of the PCR packets will remain
data-carrying packets, but as a last resort we may insert stuffing
packets on the PCR stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2073>
Change PCR / SI scheduling so that instead of checking if
the current PCR is larger than the next target time, instead
check if the PCR of the next packet would be too late, so PCR
and SI are always scheduled earlier than the target, not later.
There are still cases where PCR can be written too late though,
because we don't check before each output packet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2073>
Ensure we take the object lock while accessing `GstElement.sinkpads`.
Use an iterator when the code isn't simple to avoid deadlock.
When we find the best pad, take a reference so a concurrent pad
release doesn't destroy the pad before we're done with it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1553>
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>
Previously, "en" (should have actually been "eng") was assumed
for the ISO-639 language descriptor if no language was explicitely given.
Neither ETSI EN 300 468 nor ATSC A/52 mandate for a language descriptor,
so we should simply not set it, if it's unknown.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1386>
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
We were unconditionally adding top-level descriptors in the PMT which
were only related to bluray support for PS3 (from 10 years ago).
These should be re-added conditionally
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
We can have multiple TsMuxPacketInfo objects for the same PID
with user-provided sections, for example ATSC requires multiple
tables with the same PID.
gstmpegtsmux.c:291:3: error: implicit declaration of function ‘memmove’ [-Werror=implicit-function-declaration]
memmove (map.data + 4, map.data, map.size - 4);
^
gstmpegtsmux.c:291:3: error: incompatible implicit declaration of built-in function ‘memmove’ [-Werror]
gstmpegtsmux.c:291:3: note: include ‘<string.h>’ or provide a declaration of ‘memmove’
