<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> 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. <ul> <li>On Firefox for Android, the received video and audio streams were as expected</li> </ul> <ul> <li>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. </li> </ul> <ul> <li>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?) </li> </ul> 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? </body> </html>