Bug 325884 – Software VP9 decoder silently drops 4:4:4 frames and corrupts 12-bit frames

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jean-Yves Avenard [:jya]]

In LibWebRTCVPXVideoDecoder, which is used by WebCodecs and as the software fallback for media playback:

1. 4:4:4 frames are dropped with no error.
   - libwebrtc's LibvpxVp9Decoder::ReturnFrame() wraps VPX_IMG_FMT_I444 and VPX_IMG_FMT_I44416 output as kI444 and kI410 buffers (libvpx_vp9_decoder.cc:309, :340).
   - VideoFrameLibWebRTC::create() only accepts kI420, kI010, kI422 and kI210 (VideoFrameLibWebRTC.cpp:45-49), so it returns nullptr for these.
   - LibWebRTCVPXInternalVideoDecoder::Decoded() then does if (!videoFrame) return 0;, and the decode promise resolves successfully with no output frame.
2. 12-bit 4:2:0 frames are corrupted.
   - ReturnFrame() wraps every VPX_IMG_FMT_I42016 image with WrapI010Buffer() (:320-328), regardless of img->bit_depth.
   - The conversion to a CVPixelBuffer then calls libyuv::I010ToP010(), which is hardcoded to depth 10 (third_party/libyuv/source/convert.cc:643, IxxxToPxxx(..., 1, 1, 10)). It shifts each sample left by 6 into a 16-bit word, so 12-bit values above 1023 overflow.
   - I expect 12-bit 4:2:2 to be corrupted the same way through I210ToP210(); I haven't checked that path.

WebCodecs vp09.02.12.* strings reach this path today (see bug 1), and so does a vp09.00/vp09.02 string over a 12-bit or 4:4:4 bitstream.

Expected
The decode fails with an error: reject keyframes whose header says 12-bit, and reject a decode whose output couldn't be wrapped. This should stay in place until 12-bit and 4:4:4 output are supported.

[Radar WebKit Bug Importer]

<rdar://problem/188868857>

[Jean-Yves Avenard [:jya]]

Pull request: https://github.com/WebKit/WebKit/pull/75488

[EWS]

Committed 322513@main (566407e0d178): <https://commits.webkit.org/322513@main>

Reviewed commits have been landed. Closing PR #75488 and removing active labels.