User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 Steps to reproduce: I initiated a session with firefox publishing h264 and opus. I traced out the rtp timestamps received on both channels and un-scaled them at 48k audio and 90k video. I also counted bytes decoded from audio and counted them(monitoring dropped packets, etc). Actual results: I found that audio packet times and audio bytes decoded both resolved to exact parity . Video packet times advance at a faster wall clock rate, such that muxing the audio and video into a media file results in growing synchronization issues. I then looked at RTCP for the offset and expected the offset to change with the advancing video drift. It did not. Expected results: un-scaled video and audio times should advance at the same wall clock rate. I expect un-scaled video and audio stream times to be within 500 milliseconds of each other at the receiver with RTCP providing the _exact_ offset, and updating the offset when drift is unavoidable and detected. perfect conditions would be drift free, using a shared clock(audio's), and perfectly muxed out-bound regarding incremented stream time. * unscaled time is transforming RTP packet times to linear stream time

I'd believe this. We don't have any special logic re-clocking video to the audio domain. We just clock video as it comes in on both the sending and receiving side. We do have plans to re-clock it properly. I'll put this into the dependency tree so we can keep track.