Hi, On Sat, Mar 14, 2026 at 2:52 PM Guangyu Sun <[email protected]> wrote: > > When encoding VP9 with a YUV pixel format (e.g. yuv420p) and > AVCOL_SPC_RGB colorspace metadata, libvpxenc unconditionally set > VPX_CS_SRGB. This produced a spec-violating bitstream: Profile 0 > (4:2:0) with sRGB colorspace, which is only valid for Profile 1/3 > (4:4:4). The resulting file is undecodable. > > Fix this by setting ctx->vpx_cs to VPX_CS_SRGB in set_pix_fmt() > for 4:4:4 YUV formats when AVCOL_SPC_RGB is set, matching the > existing GBRP path. This covers the legitimate case of RGB data in > YUV444 containers (e.g. H.264 High 4:4:4 with identity matrix). > > With this change, any AVCOL_SPC_RGB that reaches the switch in > set_colorspace() is guaranteed to be a subsampled format where > sRGB is invalid. Return an error so the user can fix their > pipeline rather than silently producing incorrect output. > > To reproduce: > > ffmpeg -f lavfi -i testsrc=s=64x64:d=1:r=1 \ > -c:v libvpx-vp9 -pix_fmt yuv420p -colorspace rgb bad.webm > ffprobe bad.webm > # -> "vp9 (Profile 0), none(pc, gbr/...), 64x64" > ffmpeg -i bad.webm -f null - > # -> 0 frames decoded, error > > Signed-off-by: Guangyu Sun <[email protected]> > --- > v2: > - Only fall back to BT.709 if the pixel format is not 4:4:4, > addressing feedback regarding Profile 1/3 support. > v3: > - Hard error via AVERROR(EINVAL) - set_colorspace() now returns > int, and the call site in vpx_init() propagates the error > v4: > - Rebased on master, no changes. cc maintainer > libavcodec/libvpxenc.c | 19 +++++++++++++++---- > 1 file changed, 15 insertions(+), 4 deletions(-) >
LGTM. I'll merge this soon (with a minor version update and a reference to the bug I filed for libvpx) if there are no comments. _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
