jbuf: refactor frame calculation #788
Conversation
sreimers
force-pushed
the
jbuf_video
branch
2 times, most recently
from
900fd8a
to
a135ec9
Compare
| @@ -153,7 +154,7 @@ static void jbuf_destructor(void *data) | |||
| * | |||
| * @param jbp Pointer to returned jitter buffer | |||
| * @param min Minimum delay in [frames] | |||
There was a problem hiding this comment.
frames --> packets. Also here?
There was a problem hiding this comment.
No, because there should be at least min frames (f->nf) in the buffer to make sure the video codec can use them. The max must be packets, because we can't pre-calculate how many video packets are one frame (this varies a lot by codec, image size, state...).
|
Is this still correct that |
Fixed, is now renamed to |
|
I think this one should be ready to merge. apart from that, if we want to be more pragmatic, we could make a separate PR only |
|
I rebased and cleaned up, so renaming is separate commit now. I will rebase merge to keep these commits. |
* config: add different options for audio and video jitter buffer * fix audio.jbtype fallback * update min/max config description baresip/re#788
A video frame is usually divided into smaller packets. Since the rtp marker bit is not very reliable (packet can be lost) or has a different meaning for audio codecs (talk spurt), frames should be detected by timestamp after sequence deduplication and ordering.