feat: Add explicit yuv-420-8-bit-video/yuv-420-8-bit-full target pixel formats

[wcandillon]

What

Adds two explicit values to TargetVideoPixelFormat (used by FrameOutputOptions.pixelFormat), reusing the naming of the existing VideoPixelFormat type:

• 'yuv-420-8-bit-full': explicitly YUV 4:2:0 8-bit full-range (kCVPixelFormatType_420YpCbCr8BiPlanarFullRange on iOS, same as 'yuv' today)
• 'yuv-420-8-bit-video': explicitly YUV 4:2:0 8-bit video-range (kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange on iOS)

The 'yuv' target is unchanged, so existing behavior is not affected.

Why

The 'yuv' target resolves to kCVPixelFormatType_420YpCbCr8BiPlanarFullRange (420f) on iOS. Some GPU video pipelines can only import video-range YUV buffers. Concretely, WebGPU (Dawn) only maps video-range formats to wgpu::TextureFormat for external texture import on Metal; full-range 420f fails validation with "Unsupported IOSurface format". See GetFormatEquivalentToIOSurfaceFormat in Dawn's SharedTextureMemoryMTL.mm, which supports kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange (mapped to R8BG8Biplanar420Unorm) but not the full-range variant.

With this change, react-native-webgpu users can request pixelFormat: 'yuv-420-8-bit-video' on a CameraFrameOutput and import the resulting Frames zero-copy as WebGPU external textures.

Notes

• On Android both new values resolve to YUV_420_888 (same as 'yuv'), as CameraX/Camera2 do not allow configuring the color range of the output. This is documented on the type and in the docs page.
• Nitrogen specs regenerated via bun camera specs.
• Docs: extended the "Pixel Formats Map" page with the two new targets.

🤖 Generated with Claude Code

[vercel]

@wcandillon is attempting to deploy a commit to the Margelo Team on Vercel.

A member of the Team first needs to authorize it.

[mrousavy]

Are you sure Dawn only supports kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange? Isn't kCVPixelFormatType_420YpCbCr8BiPlanarFullRange the default YUV format supported everywhere?

I think it can be good to have control over which format it should be, but the fact that changing from 'yuv-420-8-bit-full' to 'yuv-420-8-bit-video' does absolutely nothing and gives you the exact same buffer on Android is a bit weird to me.

Technically that would make a big difference and could break assumptions based on Pixel Data. But I guess since the Frame gives you a .pixelFormat it's fine, it's just weird that you request -video and receive -full on Android then.. 🤔