[Bug 794909] ulpfecdec: output perfect seqnums
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Fri Apr 6 18:20:18 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=794909
Mathieu Duponchelle <mduponchelle1 at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #370612|0 |1
is obsolete| |
--- Comment #11 from Mathieu Duponchelle <mduponchelle1 at gmail.com> ---
Created attachment 370614
--> https://bugzilla.gnome.org/attachment.cgi?id=370614&action=edit
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list