rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’
https://bugzilla.gnome.org/show_bug.cgi?id=793732
The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.
Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.
Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793843
It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.
https://bugzilla.gnome.org/show_bug.cgi?id=793798
We expose a set of new elements:
* ULPFEC encoder / decoder
* A storage element, which should be placed before jitterbuffers,
and is used to store packets in order to attempt reconstruction
after the jitterbuffer has sent PacketLost events
* RED encoder / decoder (RFC 2198), these are necessary to
use FEC in webrtc, as browsers will propose and expect ulpfec
packets to be wrapped in red packets
With contributions from:
Mathieu Duponchelle <mathieu@centricular.com>
Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792696
Packets with these payload types will be dropped. A use case
for this is FEC, where we want FEC packets to go through the
jitterbuffer, but not be output by rtpbin.
https://bugzilla.gnome.org/show_bug.cgi?id=792696
All received configurations are parsed and added to a list, this lead
to an unbounded memory usage. As the configuration is resent every
second this quickly lead to a large memory usage.
Add a check to only add the config if it is not already available in
the list. This fix only handle the typical case of a well behaved
stream, a malicious server could still send many useless
configurations to raise the client memory usage.
The smallest possible is 24 (and not 25) bytes.
The last "name" field can according to QTFF specifications not be present
at all. The parser will handle this fine and so will the rest of
the qtdemux code.
