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.
In M2TS mode, we need an extra 4 bytes in the buffer, so need
to ensure the buffer can contain these. The allocation site
does not know the mode, so this is done in all cases.
The MPEG standard (ISO-13880-1) says the reserve bits need to be set
to one (2.1.64). This is causing transport streams to fail validation
on some systems.
https://bugzilla.gnome.org/show_bug.cgi?id=760127
Use the saved DTS, make it signed and pass that to the stream muxer. This
preserves the running time sign. All usage of -1 as invalid TS are now
replaced with G_MININT64. Negative values will be seen as wrap-around
point, but the delta between PTS and DTS will remain correct. Demuxers
don't care about absolute values, they only cares about deltas.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
It was previously a mix and match of both variants, introducing just too much
confusion.
The prefix are from now on:
* GstMpegts for structures and type names (and not GstMpegTs)
* gst_mpegts_ for functions (and not gst_mpeg_ts_)
* GST_MPEGTS_ for enums/flags (and not GST_MPEG_TS_)
* GST_TYPE_MPEGTS_ for types (and not GST_TYPE_MPEG_TS_)
The rationale for chosing that is:
* the namespace is shorter/direct (it's mpegts, not mpeg_ts nor mpeg-ts)
* the namespace is one word under Gst
* it's shorter (yah)
Turns out glib aborts on allocation failure, so this is pointless.
We'll just ignore Coverity warnings on such constructs.
This reverts commit d347809a82.
While it will probably not trigger, it should silence a Coverity
warning about the fail code path testing for NULLness before
freeing, where the buffer was already dereferenced. It seems
safest to keep that test, in case future goto fail statements
happen to have a NULL buffer there.
Coverity 1139851
The muxer is now able to include DVB sections in the transport stream.
The si-interval property will determine how often the SI tables are
muxed into the stream.
The section is handled by the mpeg-ts library. Below is a small example
that will include a Netork Information Table with a Network Name
descriptor in the stream.
GstMpegTsNIT *nit;
GstMpegTsDescriptor *descriptor;
GstMpegTsSection *section;
GstElement *mpegtsmux;
gst_mpegts_initialize ();
nit = gst_mpegts_section_nit_new ();
nit->actual_network = TRUE;
descriptor = gst_mpegts_descriptor_from_dvb_network_name ("Network name");
g_ptr_array_add (nit->descriptors, descriptor);
section = gst_mpegts_section_from_nit (nit);
// mpegtsmux should be retrieved from the pipeline
gst_mpegts_section_send_event (section, mpegtsmux);
gst_mpegts_section_unref (section);
The prog-map property of mpegtsmux only allows you to group pids together in a program.
The program number set in the PAT/PMT tables cannot be set explicitly.
This patch will set the program number according to the prog-map.
If a program id of 0 is given, the first vacant program number starting from 1 will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=697239
The PES header length is calculated before setting the dynamic flags, returning
a wrong value. Small frames that should be sent in a single TS packet are
spawned to a new packet because of that error. For audio streams where a single
frame can cope in one TS packet it introduces a huge overhead.
For a 100B packet, we prepare a TS packet with a payload of(100+9)B. Then, we
write the TS header using this value in tsmux_write_ts_header, and call
tsmux_stream_get_data(). The dynamic flags where not set yet and now
tsmux_stream_pes_header_length() returns 14B instead of 9B. The payload of the
TS packet is 114B, 5B more than what was calculated. 109B are sent in a first
packet and the remaining 5B are sent in another one.
Fixes bug #628548.
