<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.<br>
    </p>
    <p>Using GStreamer 1.18 on Ubuntu 18.04.<br>
    </p>
    <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.<br>
      </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?)<br>
      </li>
    </ul>
    <p>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.</p>
    <p>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.</p>
    <p>Has anyone else seen this behavior and found a means to
      counteract it without delaying the whole stream?<br>
    </p>
  </body>
</html>