Skip to content

Do not prevent keyframe detection when throttling PLIs sent (#408) #409

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+14 −14
Open

Do not prevent keyframe detection when throttling PLIs sent (#408) #409

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Do not prevent keyframe detection when throttling PLIs sent 
When using simulcast client it receives huge number of PLIs.
This change avoids preventing keyframe detection for activation of individual simulcast RTPEngines when throttling PLIs sent

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 show continues.
  • Loading branch information
@avila-devlogic
avila-devlogic committed Mar 12, 2018
commit eb8b82ba9dc583bb5b72008b3d99537ed3c4ac94
28 changes: 14 additions & 14 deletions src/org/jitsi/impl/neomedia/rtp/MediaStreamTrackDesc.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -222,21 +222,21 @@ void update(
return;
}

if (nowMs - statistics.lastKeyframeMs < MIN_KEY_FRAME_WAIT_MS)
{
// The webrtc engine is sending keyframes from high to low and less
// often than 300 millis. The first fresh keyframe that we observe
// after we've waited for that long determines the streams that are
// streaming (not suspended).
//
// On the other hand, if this packet is not a keyframe, the only
// other action we can do is send an FIR and it's pointless to spam
// the engine.
return;
}

if (!frameDesc.isIndependent())
{
if (nowMs - statistics.lastKeyframeMs < MIN_KEY_FRAME_WAIT_MS)
{
// The webrtc engine is sending keyframes from high to low and less
// often than 300 millis. The first fresh keyframe that we observe
// after we've waited for that long determines the streams that are
// streaming (not suspended).
//
// On the other hand, if this packet is not a keyframe, the only
// other action we can do is send an FIR and it's pointless to spam
// the engine.
return;
}

if (!isPacketOfNewFrame)
{
// We only check for stream suspension if this is the first
Expand Down Expand Up @@ -308,7 +308,7 @@ void update(
{
// This is a late key frame header packet that we've missed.

if (!encoding.isActive())
if (!encoding.isActive() && !(nowMs - statistics.lastKeyframeMs < MIN_KEY_FRAME_WAIT_MS))
{
if (logger.isTraceEnabled())
{
Expand Down