Webm files with different duration


In some of our recordings (manual individual recording) the webm files of the single streams differ in duration. Not only a few milliseconds which can be caused by the delayed start of the recorder endpoints but a few seconds.

Example: 4 participants in a session, no one joined or left the session during recording. The startTimeOffset and endTimeOffset are very low and not the reason for the difference.
The final webm files do have the following lengths:


The biggest difference is in stream 4. It is too short and we can also see that the stream is in sync with the other streams at the beginning and runs out of sync more and more during the playback.
The duration in the meta data is 217.974 which is 00:03:37.97

Can this be caused by packet drops in a bad network? We did not see this issue in 2.15 and I guess Kurento introduced a new method regarding packet loss.

Fixed Recorder synchronization on streaming gaps

The RecorderEndpoint suffered from an audio/video synchronization issue that multiple users have noticed over time. The root cause of this issue was packet loss in the network: any missing packet would cause a gap in the sequence of audio timestamps that got stored to file. These gaps would make the audio and video tracks to drift over time, ending up with a noticeable difference and with a broken lipsync.

A new method to avoid timestamp gaps has been added to the recorder: now, whenever a gap is detected, the recorder will overwrite the timestamps in order to take into account the missing data. This way, both audio and video will still match and be synchronized during playback.

Maybe this new method is causing the difference in duration? Does anyone have another idea how this is caused and how to avoid this?

It’s very important for our use case that the single streams are in sync - not only audio and video in the webm files but also across the webm files.