FFmpegVideoEncoder never signals color information to the codec, so nothing we encode carries color metadata in the bitstream. There is a commented-out sketch of this in FFmpegVideoEncoder.cpp (the "TODO: do this properly, based on the colorspace of the frame" block in InitEncoder).

Consequences:

• Every WebCodecs, MediaRecorder, and WebRTC encode that goes through FFmpegEncoderModule produces AV1/VP9/H.264 bitstreams with unspecified color info, even when the input frames carry a fully specified color space. Any decoder, ours included, then falls back to resolution-based heuristics, which guess wrong for 601 SD content labeled 709 and vice versa.
• The bitstream roundtrip variants of webcodecs/full-cycle-test.https.any.js ("w/ stripped color space") only pass today by coincidence: the color information the test expects to survive in the bitstream is never written, and the receiving side's never-filled defaults happen to alias to bt709.

The encoder already has the information: EncoderConfig::SampleFormat carries a VideoColorSpace populated by SampleFormat::FromImage for planar YUV input.

I have a patch that maps the config's color space onto the AVCodecContext (color_range, colorspace, color_primaries, color_trc) and the submitted AVFrames, with version guards so older system libraries degrade to unspecified rather than misreporting. Fields the config does not know stay unspecified, so RGB-converted input (for example canvas sources, where the conversion matrix question is its own bug) is unchanged. Includes a gtest that encodes AV1 with a BT2020/PQ/full-range input and asserts the parsed sequence header color_config via AOMDecoder::ReadSequenceHeaderInfo.

The encoder config's SampleFormat already carries the input frames' color
space for planar YUV sources, but nothing was ever set on the codec
context, so every bitstream we produce says unspecified and decoders
fall back to resolution-based heuristics. Map the known fields onto the
AVCodecContext and the submitted AVFrames; fields the config does not
know stay unspecified, so RGB-converted input is unchanged. The guards
follow when each AVCOL_* constant was introduced so older system
libraries degrade to unspecified rather than misreporting.

The gtest encodes AV1 with a BT2020, PQ, full-range input, deliberately
different in every field from the CICP defaults, and asserts the parsed
sequence header color_config via AOMDecoder::ReadSequenceHeaderInfo.

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

https://hg.mozilla.org/mozilla-central/rev/f2bd628f3dc6