Commit graph

12 commits

Author SHA1 Message Date
Mathieu Duponchelle
0da8f111e6 rtpulpfdecdec: only put recovered packet back into storage if not recovered from there 2019-03-06 19:40:10 +00:00
Mathieu Duponchelle
f9b49aef09 rtpulpfecdec: fix buffer leak when packet is recovered from storage
Exposed by rtpulpfecdec_recovered_from_storage test.
2019-03-06 19:40:10 +00:00
Mathieu Duponchelle
90f5ae8f45 ulpfecdec: output perfect seqnums
ULP FEC, as defined in RFC 5109, has the protected and protection
packets sharing the same ssrc, and a different payload type, and
implies rewriting the seqnums of the protected stream when encoding
the protection packets. This has the unfortunate drawback of not
being able to tell whether a lost packet was a protection packet.

rtpbasedepayload relies on gaps in the seqnums to set the DISCONT
flag on buffers it outputs. Before that commit, this created two
problems:

* The protection packets don't make it as far as the depayloader,
  which means it will mark buffers as DISCONT every time the previous
  packets were protected

* While we could work around the previous issue by looking at
  the protection packets ignored and dropped in rtpptdemux, we
  would still mark buffers as DISCONT when a FEC packet was lost,
  as we cannot know that it was indeed a FEC packet, even though
  this should have no impact on the decoding of the stream

With this commit, we consider that when using ULPFEC, gaps in
the seqnums are not a reliable indicator of whether buffers should
be marked as DISCONT or not, and thus rewrite the seqnums on
the decoding side as well to form a perfect sequence, this
obviously doesn't prevent the jitterbuffer from doing its job
as the ulpfec decoder is downstream from it.

https://bugzilla.gnome.org/show_bug.cgi?id=794909
2018-04-19 18:17:39 +02:00
Sebastian Dröge
ed2ccb1a60 rtp: Fix compilation with non-C99 compilers
By moving variable declarations out of loop headers.
2018-03-20 12:08:28 +02:00
Tim-Philipp Müller
56577236f8 rtpulpfecdec: fix build with older gcc
As on Ubuntu Trusty.

https://bugzilla.gnome.org/show_bug.cgi?id=794493
2018-03-19 18:39:08 +00:00
Tim-Philipp Müller
65ede0b565 rtpulpfec: don't use non-portable notation for 64-bit int constants
Use GLib macro instead, even if it's a bit unwieldy.
2018-03-17 13:04:47 +00:00
Tim-Philipp Müller
c21765e88e rtpulpfecdec: don't use __builtin_ctzll unconditionally
Fixes build with MSVC, and possibly other compilers too.
2018-03-17 12:55:57 +00:00
Mathieu Duponchelle
3a754d51e0 FEC elements: document, remove irrelevant properties
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
2018-02-26 16:41:12 +01:00
Arnaud Bonatti
e3a3d4fb76 rtpulpfec: fix debug log printf format warning on 32-bit platforms
https://bugzilla.gnome.org/show_bug.cgi?id=793732
2018-02-23 10:02:23 +00:00
Tim-Philipp Müller
427033591c docs: hook up new RTP FEC elements
https://bugzilla.gnome.org/show_bug.cgi?id=792696
2018-02-22 15:56:49 +00:00
Tim-Philipp Müller
3789afd491 rtp: fec: fix build with gstreamer debug log system disabled 2018-02-21 19:01:15 +00:00
Mikhail Fludkov
d5ad50bd61 rtp: Implement ULPFEC (RFC 5109)
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
2018-02-21 14:15:22 +01:00