IOS 18.4.1 webrtc video and audio out of sync

M

Michael

Member
Hello

Since IOS get updated to version 18.4.1, we received a lot of complaints about audio/video sync on webrtc streamings.

When starting the stream, everything seems normal, but after few seconds the delay between audio and video gets increasing.

After 1 minute of stream, the audio play like 2 or 3 seconds before video.

We can reproduce in https://demo.flashphoner.com, using 2 way streaming example.

Do you have any idea to fix it?

Regards
 
Max

Max

Administrator
Staff member
We reproduced the issue and raised the ticket WCS-4432 to investigate it. We'll let you know about progress in this topic.
 
T

Taylor

Member
Hi Max

We've also been receiving a few similar issues regarding recording streams on IOS 18.4.1.

When we do a stream recording it appears to work fine within the local video playback, but when we view the video it's running at about 3fps and roughly 1/10th of the speed, all while the audio part is playing normally which puts it completely out of sync.

We were able to test this out on both iPhone and iPad, both on IOS 18.4.1, as well as with:
  • WCS 5.2.2071 and WCS 5.2.2232 (latest)
  • iOS Safari browser and iOS Chrome browser
and they all had the same video issue.

We also tested the iPad with IOS 17.7.6 and IOS 18.3.2 and both of those were able to successfully record videos without the issue, so it seems most likely that IOS 18.4.1 is when this issue started.

One other thing we found is that if we update the codec in flashphoner properties to swap 'h264' and 'vp8', so that the records are saved as 'webm' instead of 'mp4', we're able to successfully record videos on iOS 18.4.1 without issue.
Before: codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
After: codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv
Click to expand...
This unfortunately isn't an ideal solution for us as we want to keep recording in mp4 for all other browsers, but found these results interesting so we thought to include it here.

Hope this information is helpful.

Cheers
 
Max

Max

Administrator
Staff member
Our developers have investigated the issue and concluded that this is a bug in iOS Safari version 18.4.1.

The problem stems from the fact that the server expects incoming video streams using the H.264 codec with a standard RTP timestamp clock rate (timebase) of 90000. However, Safari 18.4.1 is sending video streams with a timebase of 900000 instead — effectively 10 times higher than expected.

To clarify: in RTP, a clock rate (or timebase) of 90000 means there are 90000 timestamp units per second, which equals 90 units per millisecond. If the browser sends a timebase of 900000, that translates to 900 units per millisecond — a 10x discrepancy.

As a result, the server interprets the timing between frames incorrectly. For example, with a frame rate of 30 FPS, each frame should be ~33 milliseconds apart. With a timebase of 90000, we expect a timestamp increment of 33 × 90 = 2970 between frames. But instead, Safari sends 33 × 900 = 29700. This inflated timebase causes the server to believe that frames are spaced much further apart than they really are, leading to audio/video desynchronization and issues with recording.

Our planned fix is to detect streams coming specifically from iOS Safari version 18.4.1, and to downscale the incoming video timestamps by a factor of 10 for this specific case. This corrects the timeline and restores proper synchronization.

We plan to release this fix next week, between May 12 and May 18.
 
You must log in or register to reply here.
Top