WebRTC Inconsistent Playout Across Browsers

[Cameron Blomquist]

I have been testing webrtc and came across a strange behavior with 
browsers on the receiving side. To verify this behavior, I used 
gst-examples/webrtc/sendrecv/gst-rust. Changed audiotestsrc to use the 
ticks wave and videotestsrc to sweep and use running-time so that the 
tick should line up with a single sweep of the ball.

Using GStreamer 1.18 on Ubuntu 18.04.

  * On Firefox for Android, the received video and audio streams were as
    expected

  * On Safari for iOS, the received audio stream saw significant delay
    from the video stream in the range of 250-750ms by ear (no exact
    measurements, just comparing the motion.) Such a delay makes it
    unusable for real-time streams.

  * On Chrome for Android, the video would not start. I believe this to
    be unrelated though to the subject (chrome not allowing any autoplay
    and hiding video controls without a source?)

This delay was initially seen with an H264 video stream on an Android 
device and was reproduced in an audio-only stream before testing 
sendrecv. I've had others able to reliably reproduce the issue on other 
iOS devices but it seems harder to replicate on any given Android.

With the problem on the receiving end, I would first think that the 
issue is with browser implementations of webrtc but with control being 
extremely limited on that side, I'm not really sure where else to look 
except at what can be done on the GStreamer and webrtcbin side.

Has anyone else seen this behavior and found a means to counteract it 
without delaying the whole stream?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210426/b26a76f9/attachment.htm>