User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.96 Safari/537.36

Steps to reproduce:

https://codepen.io/aertmann/pen/mAVaPx?editors=1010

Actual results:

it throws NS_ERROR_NOT_AVAILABLE

Expected results:

it should draw the frame from the video to the canvas

I tried this on stable (65), beta (65), nightly (67), all are affected

I have managed to reproduce the issue on the latest version of Nightly (67.0a1) and Beta (66.0b6) using the device Huawei MediaPad M3 Lite 10 (Android 7.0), after a video is uploaded no preview is generated.

Based on the description and my comment I will set this issue as new.

I discover this originally on Firefox 65, is it necessary to make Firefox 65 as affected as well?

*mark

Hello Seanplwong, I was able to reproduce it on FF 65 too, based on Comment 3 and my comment I will mark as affected 65 too.

It's the canvas drawImage with a video element bug.

Snorp, is this finally fixable now that bug 1486659 has landed? I gather we now make an extra copy of the image for the compositor? Does that we're allowed to bind the SurfaceTexture for readback, so can implement SurfaceTextureImage::GetAsSourceSurface()?

(In reply to Jamie Nicol [:jnicol] from comment #6)

It's the canvas drawImage with a video element bug.

Snorp, is this finally fixable now that bug 1486659 has landed? I gather we now make an extra copy of the image for the compositor? Does that we're allowed to bind the SurfaceTexture for readback, so can implement SurfaceTextureImage::GetAsSourceSurface()?

Hmm. Maybe? We could at least ask the Compositor to get the bytes for us.

Issue still exists with 68.
This bug is surprisingly not triggered with every codec.
It is with h264, but not with theora codec, example; http://jsfiddle.net/mL0kzoc7/
Video colorspace doesn't seem to have any effect.

I can confirm this on Firefox for Android v68.3.0 using this example https://codepen.io/kus/pen/aOqvWP/.

I can confirm this is still happening on Firefox Preview Nightly for Android 200324 06:00 (Build #20840606). GV: 76.0a1. Can I provide any additional information to help narrow this down?

Jamie, are you able to take a look at this?

I can confirm this also happens on Firefox 74 for Windows 10. But I don't have a test case.
I've caught 10 exceptions over the last 30 days. (And more exceptions pre version 74, but that data has been lost.)
Based on that data I can extrapolate the following findings/remarks:

1. 8/10 of the exceptions happened at the start of the video when the video.currentTime is 0.
2. When the video.currentTime is 0, at least one or both of video.mozPaintedFrames or video.mozPresentedFrames is 0. And video.mozParsedFrames and video.mozDecodedFrames are always higher than 0.
3. It seems like 2/10 of the exceptions happened midway when the video.currentTime is not 0.
4. When video.currentTime is 0 then video.paused is false. But when video.currentTime is higher than 0 then video.paused is true.
5. The video.networkState is always 2 (NETWORK_LOADING)
6. video.videoWidth and video.videoHeight are always set to a value.

Regarding video codecs I've seen both the mimetypes video/mp4 (1 time) and video/webm (5 times).
The video/webm mimetype has always the vp9 codec.
The video/mp4 mimetype could have been one of the following codecs (it was not captured exactly):

avc1.42001E, mp4a.40.2
avc1.64001F, mp4a.40.2
avc1.4d401f
avc1.4d4014
avc1.4d401e
avc1.4d400c
avc1.4d400b

This is expected on Android, because of our use of SurfaceTextures. It is not expected on windows, and presumably has a different cause. could you please file a separate bug with that information?

I've filed a separate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1629381

Repros easily with https://jsfiddle.net/jib1/0dnyfab2/show (I had trouble operating the codepen)

We might be able to fix this by using ImageReader and AHardwareBuffer for video data instead of SurfaceTextures.

Fyi something funny is going on in bug 1667532 comment 3 where things worked in previous beta, but now not in latest beta. Any idea why this would work in previous beta?

I can confirm this is still broken on Firefox v93.1.0 on Android.

Testing with: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_drawimage_video

gecko now support only WebRender as compositor. Then this bug could be addressed without AHardwareBuffer usage.

These tests want to have their HW decoding re-enabled by this bug:
https://hg.mozilla.org/integration/autoland/rev/5976eb8e6be6
https://searchfox.org/mozilla-central/search?q=bug+1526207&path=&case=false&regexp=false

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 5 See Also bugs.
:sotaro, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.