A source of intermittent in the past has been due to readyState changing in the HTMLMediaElement while there was no frame to be painted. That is because we may not have a received an image yet, though we do know the image duration. The current approach is very hackish, where we move back the readyState to HAVE_METADATA if we haven't painted on the canvas yet: https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp#5753 We could instead always have a frame ready to be painted, even if none has been received yet. A black frame will do.
s/though we do know the image duration/though we do know the image dimensions
Component: WebRTC → WebRTC: Audio/Video
Priority: -- → P1
If we are playing an audio-only MediaStream and add a video track to said stream, we won't know the video dimensions yet. How would you draw that into a canvas? You could fairly easily make a case with a stream (per above) played in a video element, which is drawn to a canvas, which is captured to a stream, which is recorded by MediaRecorder -- and every recording would start with a black frame of arbitrary size. I'm not convinced that would be better than the current hackish solution.
(In reply to Andreas Pehrson [:pehrsons] from comment #2) > If we are playing an audio-only MediaStream and add a video track to said > stream, we won't know the video dimensions yet. How would you draw that into > a canvas? have a dummy frame of a given size.
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.