jbuf: frame fixes #806
jbuf: frame fixes #806
Conversation
sreimers
force-pushed
the
jbuf_video_adaptive
branch
2 times, most recently
from
be7bb95
to
98a7ea6
Compare
Since packets can be lost or late/reorderd, this can lead to multiple counting.
sreimers
force-pushed
the
jbuf_video_adaptive
branch
from
98a7ea6
to
8686db6
Compare
| if (f->le.prev) { | ||
| struct packet *pre_f = f->le.prev->data; | ||
| jb->nf = 1; | ||
| LIST_FOREACH(&jb->packetl, le) |
There was a problem hiding this comment.
Is it possible to avoid O(n) effort for jbuf_put()?
There was a problem hiding this comment.
I have not found a reliable way. Out-of-order, delayed packets lead to double or missed frame counts, and incorrect frame counts have a big impact on latency and jitter calculations.
There was a problem hiding this comment.
One way maybe could a separate list with frame timestamps
Edit: but this optimizes only video frame counting.
There was a problem hiding this comment.
The packets are inserted sorted by the sequence number. The sorted insert needs normally only one to a few checks.
Timestamps and sequence number should have the same order. So after the insert only one or a few checks are needed to find packets with same timestamp. Did I miss something?
Edit: I'll try a PR draft for a closer look.
There was a problem hiding this comment.
The problem is, we don't know if a sequence number is missing, because its lost or because it arrives later. This makes a simple increment unreliable. Maybe a list of missing sequence numbers can work. I plan to add RTCP Feedback NACK to trigger a resend for missing packets (video only).
Since packets can be lost or late/reordered, this can lead to multiple counting.