Author here: >I have had no problems with measuring NTP drift. As the clocks change I would measure. Did you read the article? NTP is not the same as the vide

Author here: >I have had no problems with measuring NTP drift. As the clocks change I would measure. Did you read the article? NTP is not the same as the video/audio clock which is what you need to care about. I have to now take a drink even though it's 5am here in Singapore. > Common Clock for Audio and Video No idea what sequence numbers have to do with clocks here. Maybe you mean a mapping of absolute time to relative time in RTCP? If the RTCP SR value for absolute time is using NTP (or any other wrong clock as it's not mandated to match audio/video clock), then it's by definition impossible to know how to sync audio and video after several wraparounds of each RTP timestamp. > WebRTC provides playoutDelay. This is not the same as a defined, video frame or audio sample accurate delay (ten milliseconds as a unit...) to allow for variations in frame size to maximise quality. It also appears to mix up network delays vs VBV delays. They are separate delays and are handled at different layers of the stack. > You can transport anything you want via RTP or DataChannels None of this is standardised and therefore requires control of both ends. Also high end applications need Uncompressed Audio and for the above RTP timestamp reasons this can't be precisely synced with video.