[jitsi-dev] jitsi videobridge rtcp handling

#1

I haven’t seen the videobridge signaling pli/fir from the receiver at all (tried it with all rtcp strategies):

googPlisReceived 0

googFirsReceived 0

However the receiving side is sending them for sure (googPlisSent 415).

Also on jitsi-meet I can see this behaviour if you see onRemoveStream and later onAddStream being called, video is sometimes black for up to 100 seconds, also as expected because of chrome’s default key frame interval 3000. Means 3000f / 30fps = 100s.

···

2015-05-16 1:00 GMT+02:00 Philipp Hancke fippo@goodadvice.pages.de:

Am 15.05.2015 um 15:13 schrieb Brian Baldino:

try…

[…]
[…]

adding

a=rtcp-fb:100 nack pli

here. Not sure what meet does these days but chrome has been explicitly signaling pli for about a year.

dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

Thanks John,

Gave that a shot but still see the issue. From what I can tell, even in

working jitsi calls the same behavior (receive stream created before send

stream) seems to happen, so maybe this is an issue but something about the

way the jitsi meet client is written is working around it? Driving a key

frame in some other way, perhaps?
type: offer, sdp: v=0
a=rtcp-fb:100 nack

#2

Yeah, that's what we see here...tons of PLIs sent by the receiver, but none
received by the sender. I tried changing it to: "a=rtcp-fb:100 nack pli"
(as well as adding it as another line in addition to "a=rtcp-fb:100 nack",
which is what apprtc seems to do) but still no luck :confused: This is after, by
the way, I stopped the filtering out of the PLI feedback packets with SSRC
1 in the RtpChannelDatagramFilter...I guess there must be other logic
further up the chain that's still preventing them from getting forwarded.

···

On Fri, May 15, 2015 at 4:48 PM, <dr.andreas.rice@gmx.net> wrote:

I haven't seen the videobridge signaling pli/fir from the receiver at all
(tried it with all rtcp strategies):

googPlisReceived 0
googFirsReceived 0

However the receiving side is sending them for sure (googPlisSent 415).

Also on jitsi-meet I can see this behaviour if you see onRemoveStream and
later onAddStream being called, video is sometimes black for up to 100
seconds, also as expected because of chrome's default key frame interval
3000. Means 3000f / 30fps = 100s.

2015-05-16 1:00 GMT+02:00 Philipp Hancke <fippo@goodadvice.pages.de>:

Am 15.05.2015 um 15:13 schrieb Brian Baldino:

Thanks John,
Gave that a shot but still see the issue. From what I can tell, even in
working jitsi calls the same behavior (receive stream created before send
stream) seems to happen, so maybe this is an issue but something about
the
way the jitsi meet client is written is working around it? Driving a key
frame in some other way, perhaps?

try...
[...]

   type: offer, sdp: v=0

[...]

a=rtcp-fb:100 nack

adding
a=rtcp-fb:100 nack pli
here. Not sure what meet does these days but chrome has been explicitly
signaling pli for about a year.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev