[Bug 738319] rtpsession: fix Early Feedback Transmission

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738319
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #34 from Olivier Crête <olivier.crete at ocrete.ca> 2015-01-26 17:30:24 UTC ---
(In reply to comment #31)
> If we observed a NACK with "23" and now we want to send one with "5", we will
> send one with "5". But if we observed one for "235" and we now want to send one
> for "456" then we will send one for "46" only. There is no merging done here,
> only filtering of seqnums that were already requested. The merging is done in
> rtp_source_register_nack().

I think if someone already announced that "5" was lost, and we didn't receive
456, then we should nack 456, otherwise the sender will think that one lost 5
and the other lost 46 but not 5, which may be confusing. As for large groups,
NACKs may only be used statically, not as a request for an immediate
retransmission.

(In reply to comment #32)
> But it will already pass the "soon enough" as parameter (max-delay) to that
> API. So the user of the API will tell it when "soon enough" ends, and if it's
> not possible to send anything until then, FALSE is returned.

Oops, forget what I said then, I had completely forgotten about that... ++ on
the patch

(In reply to comment #33)
> What are these FIR packets? Are they this?
> https://tools.ietf.org/html/rfc2032#section-5.2.1
> If they are supposed to be this, I think we are creating and parsing them wrong
> currently.

No, they're in RFC 5104 3.5.1.. Google Hangouts was using them instead of PLI
at some point, but I understand that their correct use is really for stream
switching.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.