WebRTC Inconsistent Playout Across Browsers
Cameron Blomquist
cameron at blomqu.ist
Mon Apr 26 15:56:07 UTC 2021
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>
More information about the gstreamer-devel
mailing list