[Bug 738319] rtpsession: fix Early Feedback Transmission

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Jan 26 01:39:23 PST 2015


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

--- Comment #31 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2015-01-26 09:39:17 UTC ---
(In reply to comment #28)
> Review of attachment 295380 [details]:
> 
> ::: gst/rtpmanager/rtpsession.c
> @@ +3101,3 @@
> +  if (gst_rtcp_buffer_get_first_packet (&rtcp, &packet)) {
> +    /* FIXME: Do we also need to compare the ssrc in the packet with the
> +     * source's ssrc? */
> 
> I think so, the packet we're trying to duplicate could also have come from
> another peer in the group, and there could be multiple senders.

But if it is from another peer, we shouldn't send another request, right?
Someone requested FIR already and that should give us a new keyframe too.

(In reply to comment #29)
> Review of attachment 295381 [details]:
> 
> I'm not sure I understand your code exactly, if we sent a nack with "23" as
> lost and then we discover that 5 is lost, will it is "235" or just "5" ?

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().


Note that this is about observing feedback from others in the group, not from
ourselves. If someone else in the group requested retransmission for something
we care about, then we don't have to do that again as it will just increase
traffic for no good reason. Same goes for PLI and FIR.

-- 
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.


More information about the gstreamer-bugs mailing list