I am using Individual recording.in Openvidu PRO, Session total duration is approx 10 minutes. The first Stream which is for 3:25 minutes is fine and after that Broadcaster Refreshed the page and a new recording streams was generated.
On the second STREAM which got generated after the Page Refreshed in not in Sync. We are facing AV syncing issue in this Stream
Can you please let me know the possible reason and fixes around that?
Faced AV lag issue again, but it’s a little bit strange.
When i run the video in chrome the AV lag is significant but when i play the same video in Mozilla the lag is marginal.
I also noticed for some Recording - In the beginning everything sounds fine, but slowly the audio goes faster than the video.
P.S - There was no lag in AV during live session @ load of Media server was below 15%. @pabloFuente@cruizba any suggestion what can be the reason behind this.
Broadcaster uses Chrome browser for live sessions.
We are using INDIVIDUAL recording.
Live session is based on 1-N topology.
I’m saying that if i play the recorded files in Chrome i see significant lag but if i play the recorded file in Firefox, lag is also there but it’s marginal or negotiable.
For some of the recording, everything sound fine in the beginning, but slowly the audio goes faster than the video (AV desync).
All such sessions where we are facing AV lag was running smooth during Live sessions.
I have shared one recording file with you, you can check the same. For example if you
Seek the video to 38 minutes and play for 2 mints and see the difference in both browser
Seek the video to 1 hr 21 minutes and play for 1-2 mints and see the difference in both browser.
Also if you’re able to know (from application logs or any other means) what is the exact browser that was used as source for this recorder, it would also help. Browser name (Chrome, Firefox, Safari, etc) and version number.
A sample recording that shows this A/V out of sync issue (I’ve now received it already) - Have shared 2 recording files with you. If not received please let me know.
A KMS log file that corresponds to the creation of one of these faulty recordings. All media nodes are added on the fly (auto scale mode) hence KMS log won’t be available from there, Please let me know is there any other options available.
Browser name (Chrome, Firefox, Safari, etc) and version number.
Source of Recording Browser was Chrome. Will try to get details of Version and will provide you.
Browsers where i have checked recording
- Mozilla (80.0.1) - No AV Lag / Negotiable lag found
- Chrome (84 and 85) - Checked with these 2 versions and in both AV lag is significant
@j1elo, I get below error/warning messages from Chrome which has sync problem. It shows below message on chrome://media-internals Please see the attached screen shots for 3 different recordings which has AV syncing issue. Please see if this can help to understand the behaviour.
It seems there is some problem with MediaRecorder while recording in the Chrome. I’m guessing that the problem is MediaRecorder creating audio streams with overlaps.
Please see the Chrome bug which they have fixed. May be need to upgrade the latest Chrome version in Openvidu Recording Container.
INDIVIDUAL recording does not use the recording conainer. INDIVIDUAL recording is performed directly by Kurento Media Server dumping stream data into disk.
The A/V sync issues in Chrome were caused by the sensitivity that Chrome player has to timestamp issues. Other players such Firefox are able to play the files correctly because it basically ignores the timestamp in the file.
The issue is caused by gaps in the recorded timestamps. For example, say that frames 4 and 5 are missing, the recorded file is like this:
1, 2, 3, 6, 7, 8, …
With frames 4 and 5 missing, Firefox assumes that between 3 and 6 there is a gap, and ignores the 6, 7, 8… bug Chrome doesn’t, so it accelerates the audio to accommodate the timestamps, and that’s why the audio comes ahead of the video.
We’ve improved this in Kurento Media Server, hoping it is a good enough solution: when there is a gap in timestamps, the next frames have their timestamp rewritten, so there are no gaps. Thus 6 would become 4, 7 would be 5, etc, and the recorded file would look like
1, 2, 3, 4, 5, 6, …
thus now Chrome plays the file correctly. This fix is already available in latest nightly builds of KMS, and will be released with 6.15.0 as soon as testing shows that there are no regressions or issues. And I believe it will be part of the next OpenVidu release too.