[Bug 769771] rtpbuffer: Add buffer flag RETRANSMISSION

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=769771

--- Comment #8 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
(In reply to Tim-Philipp Müller from comment #7)
> I think Sebastian suggested such a flag as well a while back but after
> discussion with Wim it was rejected. I don't remember all the details (we'll
> have to dig deep in our irc logs), but it may have been because it's not
> possible to reliably distinguish whether a packet has been re-sent or not.
> The packet coming in might just be the original one that came in late, no?
> So the conclusion was that these packets should not be excluded from the
> calculations. But I might be making this up, Sebastian and/or Wim will
> hopefully remember the full details.

https://tools.ietf.org/html/rfc4588 explains why RTX needs its own SSRC and
payload number, so when a packet is requested for retransmission, the packet
that arrives is basically the original packet wrapped with a new RTP-header.
The rtxreceive elements then "unpacks" the original packet, and from that time
on it is indistinguishable from the original. So in order to be able to tell
that this packet was once a RTX packet, a buffer flag felt like the right
choice.

What you are describing was exactly what the jitterbuffer was suffering from,
that the rtx-stats (like round-trip time) was being updated based on the packet
arriving, but having to way to distinguish the original from the rtx that stats
would often become very skewed, and rtx would suffer as a result. With the
flag, the whole system becomes a lot more solid, and rtx is suddenly performing
very well.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.