If that threshold is reached, `iqa` will emit an ERROR message on the
bus, stopping any processing.
This way we can do a simpler comparison with gst-validate and the
process will error out if the specified threshold is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=795428
We don't want to reset the muxer, otherwise the continuity counter will
reset after each segment and some software gets confused. We want to
create a continuous stream.
https://bugzilla.gnome.org/show_bug.cgi?id=794816
There are two issues, both related to dependency checking with the meson
support for the ladspa plugin.
With autotools, lrdf is handled like an optional dependency. But with
meson it is required. This makes the meson support less flexible and
inconsistent with autotools.
When autotools is used it properly checks if ladspa.h is available.
But with meson it does not, instead it treats lrdf as the main
dependency. This could cause a build failure if lrdf is installed, but
the ladspa sdk is not.
https://bugzilla.gnome.org/show_bug.cgi?id=794350
Strictly speaking, the TTML spec requires that text backgrounds extend
only to the font height of the related text, rather than to the vertical
distance between lines. The result of this is that there will typically
be vertical gaps between line backgrounds through which moving video can
be seen. Since this was unnacceptable to some content providers, v1.0.1
of the IMSC spec (which profiles TTML) adds a new attribute,
itts:fillLineGap[1], that allows content authors to specify that clients
should extend text backgrounds such that there are no gaps between
lines. This attribute is also going to be included in the next release
of EBU-TT-D.
This patch adds support for fillLineGap to ttmlparse and ttmlrender.
[1] https://www.w3.org/TR/ttml-imsc1.0.1/#itts-fillLineGaphttps://bugzilla.gnome.org/show_bug.cgi?id=787071
Fixes ffeb09e4ab
if (sscanf(...)) { // != 0
error;
}
Is not correct where != 0 indicates some kind of success.
Check instead that the correct number of elements were slurped.
SDP's are generated and consumed according to the W3C PeerConnection API
available from https://www.w3.org/TR/webrtc/
The SDP is either created initially from the connected
sink pads/attached transceivers as in the case of generating an offer or
intersected with the connected sink pads/attached transceivers as in
the case for creating an answer. In both cases, the rtp payloaded streams
sent by the peer are exposed as separate src pads.
The implementation supports trickle ICE, RTCP muxing, reduced size RTCP.
With contributions from:
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
Edward Hervey <edward@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792523
By removing the indirection to the main loop completely when receiving
the peer certificate. For reference, the on-decoder-key signal does not
have a redirection.