Description
When working with H264 simulcast we have noticed that on stream 0 simulcast client receives huge number of PLIs in very short time even if there is no other participants.
I have confirmed that simulcast client is sending keyframes on all streams when PLI is received.
It turned out that RTP encoding for other two streams in simulcast haven't been marked as active, so it requests another PLI.
Analysis shows that identifying keyframes from another two streams is blocked by the PLI send rate control:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/rtp/MediaStreamTrackDesc.java#L235
When first stream is inactive, it will trigger PLI and it will basically ignore any keyframes within 300ms since PLI has been sent.
First packet received will probably be intra frame so it will trigger another PLI and block keyframe detection for another 300ms.
the reason why lowest simulcast layer is marked as active is because it has highest probability of being received just in time when 300ms elapses since it's smallest in byte size.
since the other two higher layers haven't been marked as active, it will request PLI on lowest stream again... and continue to loop the process.
I'm preparing a fix for this issue.