> 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.
