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.
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 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.
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.
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.
This is after, by