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.

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

Save old TCC feedback timestamps, in case of packet reordering. #218

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

Save old TCC feedback timestamps, in case of packet reordering. #218

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
15 changes: 11 additions & 4 deletions src/main/kotlin/org/jitsi/nlj/transform/node/incoming/TccGeneratorNode.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,10 +92,11 @@ class TccGeneratorNode(
private fun addPacket(tccSeqNum: Int, timestamp: Long, isMarked: Boolean, ssrc: Long) {
synchronized(lock) {
if (packetArrivalTimes.ceilingKey(windowStartSeq) == null) {
// Packets in map are all older than the start of the next tcc feedback packet,
// remove them
// TODO: Chrome does something more advanced, keeping older sequences to replay on packet reordering.
packetArrivalTimes.clear()
// Start new feedback packet, cull old packets.
packetArrivalTimes.entries.removeIf {
entry -> entry.key < tccSeqNum &&
timestamp - entry.value >= BACK_WINDOW_MS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit concerning because:

  1. The map will usually contain ~500ms worth of packets (~150-200 packets).
  2. removeIf is linear
  3. removeIf will execute once per sent TCC feedback

Are any of my premises wrong?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think they are. I'll try profiling it and see what I find.

Chrome does the same thing (it uses an explicit for loop with an iterator rather than a lambda but the semantic is the same) but of course it's only sending one source, so presumably less media, and also the computational cost compared to a browser is relatively much less than an SFU.

In theory if we used an explicit loop we could terminate the search by entry.key, but I'm pretty sure that in the normal cases this wouldn't be much of a win since tccSeqNum will be greater than any previous key anyway.

}
}
if (windowStartSeq == -1 || tccSeqNum < windowStartSeq) {
windowStartSeq = tccSeqNum
Expand Down Expand Up @@ -183,4 +184,10 @@ class TccGeneratorNode(
addBoolean("enabled", enabled)
}
}

companion object {
/** The number of milliseconds of old tcc reports to save */
/** TODO: Chrome makes this a field trial param; do we need to make it configurable? */
private val BACK_WINDOW_MS = 500
}
}