3 ms·

The RFC does not mandate that the RTCP timestamp (which you need to handle wraparound if you join a stream halfway through) needs to be the same as the video/au

The RFC does not mandate that the RTCP timestamp (which you need to handle wraparound if you join a stream halfway through) needs to be the same as the video/audio clock. In practice this clock is generated via the PC clock so it isn't the same clock at all: https://chromium.googlesource.com/external/webrtc/+/lkgr/modules/rtp_rtcp/source/rtcp_sender.cc#457 https://chromium.googlesource.com/external/webrtc/+/lkgr/mod... RTCP SRs are sent quite rarely (defaulting to 1s for video, 5s for audio) so quite poor for precise clock recovery required in professional applications. Probably practical implementations just use buffer fullness to drive their resampler.

derf_ 3y ago
> In practice this clock is generated via the PC clock so it isn't the same clock at all... Yes, that is the point. WebRTC has to work with cheap / commodity hardware running a general purpose OS with clocks that are not synchronized. You get a bunch of clocks in different units running at different rates, and periodically are told the mappings between them. It is your job not to "run out of memory, or advance too quickly and run out of data to process," and indeed, WebRTC implementations have methods of solving those problems. > Probably practical implementations just use buffer fullness to drive their resampler. You are correct that in practice this gets driven by the jitter buffer in libwebrtc, but there is no resampler at all. Small changes in sampling rate are hard / computationally expensive to do well (as you certainly know). That is an implementation detail, though. You can use a different strategy if you have different requirements. > ...precise clock recovery required in professional applications. What are your actual precision requirements? I also do not understand your concerns with wrap-around. Even SRs once every 5 seconds are more than enough to resolve ambiguity. You would have to go over half a day without seeing one before you could actually get confused, by which point you would have bigger issues. Keep in mind that even at the start of the stream, the media timestamps are not absolute: each chooses an initial offset randomly.

derf_ 3y ago

> In practice this clock is generated via the PC clock so it isn't the same clock at all... Yes, that is the point. WebRTC has to work with cheap / commodity hardware running a general purpose OS with clocks that are not synchronized. You get a bunch of clocks in different units running at different rates, and periodically are told the mappings between them. It is your job not to "run out of memory, or advance too quickly and run out of data to process," and indeed, WebRTC implementations have methods of solving those problems. > Probably practical implementations just use buffer fullness to drive their resampler. You are correct that in practice this gets driven by the jitter buffer in libwebrtc, but there is no resampler at all. Small changes in sampling rate are hard / computationally expensive to do well (as you certainly know). That is an implementation detail, though. You can use a different strategy if you have different requirements. > ...precise clock recovery required in professional applications. What are your actual precision requirements? I also do not understand your concerns with wrap-around. Even SRs once every 5 seconds are more than enough to resolve ambiguity. You would have to go over half a day without seeing one before you could actually get confused, by which point you would have bigger issues. Keep in mind that even at the start of the stream, the media timestamps are not absolute: each chooses an initial offset randomly.