Invalid color range error on ffmpeg 7.0

[Marius]

Summary of the bug:

I'm trying to transcode a video with h264, but I've also tried h265 having the same output.

How to reproduce:

ffmpeg -i https://vid.connatix.com/mmid-545c8cbb-f0f5-119b-2687-29df00ef32c7/original.mp4 -c:v libx264 -c:a aac output.mp4

ffmpeg version:

any 7.0 build

Platform:

windows, mac and linux

Output:

[graph 0 input from stream 0:0 @ 0x6000005fc420] Invalid color range
[vf#0:0 @ 0x6000000ff9f0] Error reinitializing filters!
[vf#0:0 @ 0x6000000ff9f0] Task finished with error code: -22 (Invalid argument)
[vf#0:0 @ 0x6000000ff9f0] Terminating thread with return code -22 (Invalid argument)
[vost#0:0/libx264 @ 0x12fe11870] Could not open encoder before EOF
[vost#0:0/libx264 @ 0x12fe11870] Task finished with error code: -22 (Invalid argument)
[vost#0:0/libx264 @ 0x12fe11870] Terminating thread with return code -22 (Invalid argument)
[out#0/mp4 @ 0x6000007fc000] Nothing was written into output file, because at least one of its streams received no packets.

I've also tried specifying -color_primaries 1, -color_trc 1 and -colorspace 1 with no success.

This error is not reproducible on any of the mentioned platforms when using ffmpeg version 6.1.

[Balling]

-color_range tv

[Marius]

Even with -color_range tv ffmpeg fails with the same error for this particular video.

[MasterQuestionable]

͏    "-color_range" alike may be as both input/output options?
͏    See also: ​https://trac.ffmpeg.org/wiki/colorspace#color_primaries

͏    The fix may be:
[[
͏= Assume reasonable default for unrecognized input colorspace characteristics =

͏    Rather than pass-through and failing.
]]

[Balling]

Color_range does not really work as input option ​https://trac.ffmpeg.org/ticket/3326#comment:3 and #443.

[MasterQuestionable]

͏    Thanks for the notice.
͏    ͏"color_primaries" related things are sort of tricky in FFmpeg:
͏    May work, may not, may not as intended... and difficult to tell.

[Balling]

Can be fixed with

ffmpeg.exe  -i https://vid.connatix.com/mmid-545c8cbb-f0f5-119b-2687-29df00ef32c7/original.mp4 -bsf:v h264_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 -c copy -colorspace
 1 -color_trc 1 -color_primaries 1 cxdasca.mp4

Even just ffplay.exe ​https://vid.connatix.com/mmid-545c8cbb-f0f5-119b-2687-29df00ef32c7/original.mp4

reproduces this.

I found the issue: yuv420p(tv, reserved, progressive), so colorspace is set to reserved. Indeed,

00023A video_full_range_flag: 0 (0x0) - (1 bits) - Limited
00023A colour_description_present_flag (3 bytes)
00023A colour_description_present_flag: Yes
00023A colour_primaries: 3 (0x03) - (8 bits) -
00023B transfer_characteristics: 3 (0x03) - (8 bits) -
00023C matrix_coefficients: 3 (0x03) - (8 bits) -

By looking into ITU-T H.273 all three of those are
Reserved (For future use by ITU-T | ISO/IEC)

also see:

​https://www.reddit.com/r/ffmpeg/comments/1cqzgc4/ffmpeg_fails_to_encode_in_av1_with_some_videos/

[Marius]

Greate findings and thank you for the workaround! Is there any chance that ffmpeg 7.0 will implement the same fallback as 6.1 does so it works out of the box with reserved colorspace?

[Balling]

there any chance that ffmpeg 7.0 will implement the same fallback

At the very least limited range BS warning should be fixed, of course.

This is very bad, I imagine, hahaha.