Bug 235597 – Capturing canvas through local peer connection to video element does not show first frame

• Component: WebRTC
• Status: RESOLVED CONFIGURATION CHANGED

[Kimmo Kinnunen]

Created attachment 449941 [details]
shows the problem

Capturing canvas through local peer connection to video element does not show first frame

1) Load https://youennf.github.io/webrtc-tests/src/content/capture/canvas-pc/
2) See teapot and black rectangle

expected:
2) See teapot and teapot

[youenn fablet]

That is worth investigating, Safari and Chrome do not show the first frame but Firefox does.
Looking at Safari, the peer connection does not seem to send the first frame so it seems the issue is on sender side.

It might be a race between the time the track is generating the frame and the time the  peer connection is set up, in which case there might not be anything for us to change.

[:fippo]

This particular sample has been long haunted by autoplay issues.
Do you get the appropriate amount of teapots after running
  document.querySelector('video').play()
? Works in Chrome at least (which initially has .paused set to true the element)

[Radar WebKit Bug Importer]

<rdar://problem/88336856>

[:fippo]

  https://webrtc.github.io/samples/src/content/capture/canvas-pc/
has been updated with some  heuristics to detect autoplay woes.

Oddly dragging then only seems to show the first frame and then one needs to double-tap the right/lower teapot to make it update once?

[youenn fablet]

I retried today using https://webrtc.github.io/samples/src/content/capture/canvas-pc/ and all three browsers seem to behave the same now (teapot only appears when a redraw is done).
Closing.