[Regression (again)] Metal YUV rendering broken on Intel MacOS about sdl HOT 15 CLOSED

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.

from sdl.

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

from sdl.

Bisecting (again)...

from sdl.

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.

from sdl.

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?

from sdl.

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

from sdl.

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

from sdl.

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

Let me check, one moment

from sdl.

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):

from sdl.

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

from sdl.

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?

from sdl.

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()

from sdl.

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.

from sdl.

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

from sdl.

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!

from sdl.