v210 encoding clips to 4-1019

[pdr0]

ffmpeg v210 encoding clips to 4-1019

You could argue, that for AV equipment , 10bit values <4 , >1019 are usually reserved for sync . But I don't think it should clip automatically, it should be up to the user.

I've prepared a 1 frame v210 test clip with Y = "0" and "1023" patches . (The patches in the leftmost and rightmost columns)

ffmpeg -i belle_nuit_mod_10bit422_vdub.avi -c:v v210 -an ffmpeg_v210_encode_to_v210.avi

The output file clips the patches to "4" and "1019" instead
(Pixel values were checked in vapoursynth editor)

At the very least, there seems to be some inconsistent handling.

If you encode that v210 clip to ,say DNxHR, the patches are decoded as 0, 1023

ffmpeg -i belle_nuit_mod_10bit422_vdub.avi -c:v dnxhd -profile:v dnxhr_hqx -an ffmpeg_v210_to_dnxhr.mxf

But if you decode/convert that dnxhr hqx to v210, it becomes 4 and 1019 .

ffmpeg -i ffmpeg_v210_to_dnxhr.mxf -c:v v210 -an ffmpeg_v210_to_dnxhr_encode_to_v210.avi

In other programs, e.g. Adobe, Resolve - there is no clipping unless you tell it to

[pdr0]

v210 with 0,1023 patches

[Carl Eugen Hoyos]

The bug tracker is not the right place to discuss this behaviour, feel free to send a patch - made with git format-patch - to the FFmpeg development mailing list.

[pdr0]

Replying to cehoyos:

The bug tracker is not the right place to discuss this behaviour, feel free to send a patch - made with git format-patch - to the FFmpeg development mailing list.

Why isn't it the right place to discuss? It's reporting a "bug" .

Uncompressed video shouldn't alter the code values. That's why it's a "bug" .

If there was some other rationale, some other reason behind "why" it's coded like that, I'd like to know

And if I knew how to "fix" it, I'd already have submitted a patch.

[t.rapp]

Stumbled over this issue, too. It turns out that the clipping you noticed is part of the specification document TN2162 "Uncompressed Y'CbCr Video in QuickTime Files" from Apple which also describes the v210 encoding scheme.

What is a bit surprising is that (as far as I can see) this clipping is only implemented for v210 in FFmpeg but not in other encoding schemes from the same document, like v410 for example.

[Balling]

Because v210 supports limited range only -- 0, 1, 2, 3 and 1020, 1021, 1022, 1023 are always invalid in all 3 components.

The same happens in #4417. It discusses the commit and docs.

[pdr0]

Replying to Balling:

Because v210 supports limited range only -- 0, 1, 2, 3 and 1020, 1021, 1022, 1023 are always invalid in all 3 components.

The same happens in #4417. It discusses the commit and docs.

As mentioned in the OP, you could argue that for AV equipment, certain values are reserved for sync (rightly so , no arguments there), just as 0 and 255 are reserved for 8bit

But for uncompressed generic digital video they shouldn't automatically clip. fourcc v210 is just uncompressed packed 4:2:2 10bit. It doesn't necessarily have any other situational information.

Auto clipping causes potential problems with other scenarios: intermediates and calculations - for example compositing applications and masks. You have incomplete transparency when using a Y channel mask. 0 is pure black, 255 in 8bit (or 1023 in 10bit) is pure white . If you use 1 or 254 in 8bit , or 1020 instead of 1023 - you end up with wrong values and incomplete transparency

*Other professional programs know this - eg. Adobe, Resolve - do not automatically clip v210... because the usage is not always AV equipment, or broadcast .

=> At the very least , again , it's inconsistent handling. If v210 is clipped, then why isn't uncompressed 8bit 4:2:2 in MOV (in QT environment the fourcc would be 2vuy, arranged as UYVY) clipped to [1,254] by ffmpeg ? It results in 0 to 255. If you blindly follow the same docs , 0 and 255 should clip too (and also cause the same potential problems).

eg.
ffmpeg -i 8bit422_gradient.avi -c:v rawvideo -pix_fmt uyvy422 -vtag 2vuy 2vuy.mov

I'd argue it should be up to the end user - if there is some situational constraint to be applied later such as AV equipment