Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulcast video sends huge number of PLIs on stream 0 #408

Open
avila-devlogic opened this issue Mar 12, 2018 · 1 comment
Open

Simulcast video sends huge number of PLIs on stream 0 #408

avila-devlogic opened this issue Mar 12, 2018 · 1 comment

Comments

@avila-devlogic
Copy link
Contributor

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.

image

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.

@avila-devlogic
Copy link
Contributor Author

#409

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant