For clock recovery, it's more about frame-accuracy here. The drift and jitter requirements on the PCRs (Program Clock References, one of the timestamps in the transport stream), stream is limited very strictly on a wide timescale. Here's a nice reference about it: https://download.tek.com/document/25W_14617_1.pdf, see for example Figure 8.
The limits here are surprisingly hard to achieve, both on the multiplexer side and on the decoder side. I've implemented clock recovery for the transport stream products at my company and it has been quite surprising how many multiplexers inject bad PCR data that's outside of the acceptable range.
Writing a T-STD compliant TS multiplexer is not trivial. When I was at LSI Logic, I spent many hours perfecting the TS multiplexer used on the MPEG-2 encoder in the Motorola DCT-6412 P3 STB.
Here's a short clip that's T-STD compliant with about 29 ns of PCR jitter.
Don't RTMP and probably WebRTC both handle this in ~1-4 second chunks with video segments and a playlist?
For non-live content a buffer can be attempted multiple times.
Live content, yes that's an issue, but often if it's missed it's too late.