Skip to content

cameraCapture test doesn't reliably get a real frame #4363

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kainino0x opened this issue Apr 19, 2025 · 3 comments · Fixed by #4365
Closed

cameraCapture test doesn't reliably get a real frame #4363

kainino0x opened this issue Apr 19, 2025 · 3 comments · Fixed by #4365
Assignees

Comments

@kainino0x
Copy link
Collaborator

kainino0x commented Apr 19, 2025

The cameraCapture test from #3874 doesn't reliably get a real video frame. In Chrome on Mac, I'm seeing that the first time I run the test, it passes, but then if I run it again, it fails:
https://gpuweb.github.io/cts/standalone/?q=webgpu:web_platform,external_texture,video:importExternalTexture,cameraCapture:dstColorSpace=%22srgb%22

If I display the image with:

    document.body.append(canvas);

it is black on the first run, and has a real image on the second run. When it has a real image, it fails, usually with a margin of around 0.05. I don't know why.

I found this because if I use --use-fake-device-for-media-stream --auto-accept-camera-and-microphone-capture in Chrome to test with a fake camera, then it gets a real frame on the first try, and that causes it to fail.

cc @shaoboyan

@kainino0x
Copy link
Collaborator Author

kainino0x commented Apr 19, 2025

Another comment about the code that gets video frames:

There are three codepaths. Chrome always takes the first path, the other paths don't seem to work, even in Chrome (the ImageCapture path throws an exception, the video element path. We should not have fallbacks, we should pick the path deterministically (use one path for the main thread, which should never skip, and another path for worker threads, which may skip).

Safari: EXCEPTION: TypeError: imageCapture.grabFrame is not a function. (In 'imageCapture.grabFrame()', 'imageCapture.grabFrame' is undefined)
Firefox: SKIP: HTMLVideoElement.captureStream is not supported

@shaoboyan091
Copy link
Contributor

The cameraCapture test from #3874 doesn't reliably get a real video frame. In Chrome on Mac, I'm seeing that the first time I run the test, it passes, but then if I run it again, it fails: https://gpuweb.github.io/cts/standalone/?q=webgpu:web_platform,external_texture,video:importExternalTexture,cameraCapture:dstColorSpace=%22srgb%22

If I display the image with:

    document.body.append(canvas);

it is black on the first run, and has a real image on the second run. When it has a real image, it fails, usually with a margin of around 0.05. I don't know why.

I found this because if I use --use-fake-device-for-media-stream --auto-accept-camera-and-microphone-capture in Chrome to test with a fake camera, then it gets a real frame on the first try, and that causes it to fail.

cc @shaoboyan

Thanks for ccing. FYI, my previous github account @shaoboyan has lost due to I linked all my recover methods to intel company email address and forget to change that... Now I used @shaoboyan091 instead. I see your fix PR, is there anything need to be further investigated? (e.g. #4364)?

@kainino0x
Copy link
Collaborator Author

FYI, my previous github account @shaoboyan has lost due to I linked all my recover methods to intel company email address and forget to change that... Now I used @shaoboyan091 instead.

Oops, I forgot. I've removed the old account from the gpuweb org, that should make it easier to remember.

I see your fix PR, is there anything need to be further investigated? (e.g. #4364)?

Eventually yes, we should add some more coverage here, but let's get a fix landed first.

kainino0x added a commit that referenced this issue Apr 23, 2025
- Don't use fallback paths in camera capture; instead, have the test pick the exact path it's using, and parameterize over it. Test two paths: VideoFrame from MediaStreamTrackProcessor, and the old-fashioned HTMLVideoElement.
- Work around an issue where Chrome (at least on Mac) shows blank frames for a while after initializing the camera.
- I happened to notice that requesting different width/height from the camera is broken in Chrome in several ways, so added cases for that.
- Added a TODO for copyExternalImageToTexture from camera

These tests only worked in Chrome, and even then they were buggy (usually running the test on a blank first frame). Now, the HTMLVideoElement tests work in Safari.

Test failures are as follows, on an M1 Mac:
- Chrome: https://crbug.com/411656657
  - HTMLVideoElement passes some cases, but fails when a requested size is passed to getUserMedia().
  - VideoFrame fails due to incorrect color management (regardless of dstColorSpace).
- Safari:
  - HTMLVideoElement fails due to incorrect color management (regardless of dstColorSpace).
  - VideoFrame is skipped.
- Firefox: doesn't yet implement importExternalTexture.

Issue: fixes #4363, cc #4364
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants