[jitsi-dev] [jitsi/jitsi-videobridge] fix: Increases the delay before a keyframe request. (#310)


#1

You can view, comment on, or merge this pull request online at:

  https://github.com/jitsi/jitsi-videobridge/pull/310

-- Commit Summary --

  * fix: Increases the delay before a keyframe request.

-- File Changes --

    M src/main/java/org/jitsi/videobridge/VideoChannel.java (7)

-- Patch Links --

https://github.com/jitsi/jitsi-videobridge/pull/310.patch
https://github.com/jitsi/jitsi-videobridge/pull/310.diff

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310


#2

Merged #310.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#event-787808198


#3

@bgrozev i was talking with @gpolitis a bit about this...i was wondering why add the extra delay and he reminded me in non-last-n there's an extra round trip to wait for the 'selectedEndpoint' even to come around, hence why IDRs may be coming too early. in last-n though we don't have that extra roundtrip, and really want the IDRs as quickly as possible. maybe we could add a check for a last-n value and, if present, minimize the delay?

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#issuecomment-246836767


#4

@brianh5 this doesn't affect the last-n logic. For last-n, FIRs will still be sent as soon as the dominant speaker changes through the code here: https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/Conference.java#L1672

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#issuecomment-246843211


#5

ah great, thanks @bgrozev. so does that mean in last-n we'll double request the IDR (once due to the code you just cited, and again due to the code in the diff)? or is there some throttling for requests on the bridge side that will prevent that? what's that value set to?

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#issuecomment-246843699


#6

Yes, there is a possibility for a double request, but it should happen very rarely. Both use cases (the last-n one, and the one with the delay for simulcast) go through RTCPFeedbackMessageSender#sendFIR(), which will throttle the FIRs to at most one every 300ms if I am reading the code correctly.

A double request will happen if the delay is big:
max(receiver_rtts) - sender_rtt + 10ms > 300ms

and also the keyframe arrives in less than 300ms.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#issuecomment-246846196


#7

sounds good. thanks boris.

···

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/310#issuecomment-246847845