[Regression (again)] Metal YUV rendering broken on Intel MacOS

[olekolek1000]

I was going to report a very similar YUV format issue related to internal webcam capture on MacOS (green tint and double vision), but on the way I encountered this:

It's probably highly related to the resolved issue I reported before: issue

Steps to reproduce: Run testcamera on Intel Macbook (2015 in this case). MacOS 12.7.2 (the newest one available for this hardware)

[olekolek1000]

Bisecting (again)...

[olekolek1000]

It is quite difficult to bisect testcamera, I tried to pinpoint which commit started causing this problem, but due to various failures in some older commits (SIGABRT crash, compilation errors etc), I couldn't do that reliably.

[slouken]

I ran testcamera on an Intel MacBook 2019, running macOS 14.5, and it worked with no issues.

Does everything except testcamera work? If so, what are the inputs and outputs to the CoreMediaFormatToSDL() function?

[icculus]

Just to be clear, this is happening if you explicitly use the software renderer and not OpenGL or Metal?

[olekolek1000]

Yes, tested testdrawchessboard and testgeometry, both run without any issues.
I've hooked up a printf() just under CoreMediaFormatToSDL() in GatherCameraSpecs function, it prints out these formats:
SDL_PIXELFORMAT_YUY2
SDL_PIXELFORMAT_UYVY
SDL_PIXELFORMAT_NV12
SDL_PIXELFORMAT_YUY2
SDL_PIXELFORMAT_UYVY
SDL_PIXELFORMAT_NV12
SDL_PIXELFORMAT_YUY2
SDL_PIXELFORMAT_UYVY
SDL_PIXELFORMAT_NV12

[olekolek1000]

Just to be clear, this is happening if you explicitly use the software renderer and not OpenGL or Metal?

Let me check, one moment

[olekolek1000]

Just to be clear, this is happening if you explicitly use the software renderer and not OpenGL or Metal?

Yup, that's it!
SDL_RENDER_DRIVER software and opengl works as intended, Metal is broken.

Texture renders correctly now (when it comes to the display itself, the color space of the camera is a different issue that I was originally going to report):

[olekolek1000]

testdrawchessboard and testgeometry both work OK on this laptop, in all three video backends (metal, gl, software).

[slouken]

Yes, tested testdrawchessboard and testgeometry, both run without any issues. I've hooked up a printf() just under CoreMediaFormatToSDL() in GatherCameraSpecs function, it prints out these formats: SDL_PIXELFORMAT_YUY2 SDL_PIXELFORMAT_UYVY SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_YUY2 SDL_PIXELFORMAT_UYVY SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_YUY2 SDL_PIXELFORMAT_UYVY SDL_PIXELFORMAT_NV12

Do you know which of these formats is actually used when you're getting frames from the camera?

[olekolek1000]

Do you know which of these formats is actually used when you're getting frames from the camera?

SDL_PIXELFORMAT_UYVY, grabbed from next_frame just below SDL_AcquireCameraFrame()

[icculus]

SDL_PIXELFORMAT_UYVY

The Metal renderer doesn't support this format, so it's something in the fallback code (GetClosestSupportedFormat or something down the line from that in SDL_CreateTextureWithProperties) that's probably blowing up.

[slouken]

Yeah, I tested with testyuv --uyvy and it worked with the metal renderer, so this needs more investigation.

[slouken]

I was able to reproduce this. There were two problems. The first is that we were trying to use a YUV shader with an RGB texture, which caused the graphical corruption and occasional crash. The second is that we were using default frame output settings, which converted the YUVY frame to NV12.

[icculus]

which converted the YUVY frame to NV12.

Oh, I think Sylvain mentioned something about how Apple was giving NV12 data when you ask for YUVY data in the original pull request...! Mystery solved!

[1bsyl]

yes, indeed something gets fixed. Previous SDL3 version didn't work on macosx for me with an external camera, and now that's ok.