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 original code (old mpegtsparse) from which this plugin was based on
was dual-licensed. This allowed usage of the code under any of the
licenses (which including LGPL):
"""
* Alternatively, the contents of this file may be used under the terms of
* the GNU Lesser General Public License Version 2 or later (the "LGPL"),
* in which case the provisions of the LGPL are applicable instead
* of those above. If you wish to allow use of your version of this file only
* under the terms of the LGPL, and not to allow others to
* use your version of this file under the terms of the MPL, indicate your
* decision by deleting the provisions above and replace them with the notice
* and other provisions required by the LGPL. If you do not delete
* the provisions above, a recipient may use your version of this file under
* the terms of the MPL or the LGPL.
"""
When refactored (leading to the creation of this new plugin), I chose all
new code to be LGPL-only (which was allowed for pre-existing code) by removing
the MPL sections.
The headers were all updated, but not the plugin license field. This commit
fixes this.
In order to be able to change the caps on multiple capsfilters the
source element needs to be stopped, otherwise it will get a few
reconfigure events and might try to renegotiate while the bin
is still transitioning its caps, leading to a not-negotiated failure
and the image capture won't happen because the source will be
unusable.
The solution is to keep the source in paused while the caps are being
changed in the bin, and then bring the element back to playing once
it is done. Unfortunately this increases the image capture latency,
but it should always work.
A possible improvement to reduce the latency is to add another signal
to be called before 'start-capture': 'prepare-capture'. At this step
the camera source should set all caps it needs and get the source
ready for doing the capture as soon as 'start-capture' is called.
This can be done on a future commit
* stream-start-id is mandatory at the beginning, so add that to the
gdp headers
* caps must be sent before new segment, invert the order from legacy
0.10 code
And fix the tests as a ref is now kept for those buffers that compose
the header
It is not perfect but it allows us to be sure that the mandatory 'framerate'
field is present in the caps.
As soon as some information is found in the stream, that will be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=723243
An SEI RBSP could contains more than one SEI message as specified in
7.4.2.3.1.
This commit change the parser API: the gst_h264_parser_parse_sei()
function now create and fill a GArray containing GstH264SEIMessage.
https://bugzilla.gnome.org/show_bug.cgi?id=721715
If the first buffer that we handle for a stream has no timestamp, we
would never consider this pad again for muxing which causes queues to
fill up and pipelines to stall. Instead, try to mux pads with -1
timestamps as soon as possible.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722330
mpeg4videoparse might not push buffers while parsing. If those buffers
contain the DISCONT flag, it gets lost and downstream won't get any
buffer with the flag.
Fix it by adding the DISCONT to the next pushed buffer.
This makes backwards playback work.
Collectpads assumes that it can pass any buffer to the clip function
for adjustment, some of which are artificially injected - so don't
adjust global timestamp tracking there. Instead, only adjust the
buffer timestamps and use them directly in the collection function.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=698748
