#8195 closed defect (duplicate)
v210 encoding clips to 4-1019
Reported by: | pdr0 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
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
Attachments (1)
Change History (6)
by , 5 years ago
Attachment: | belle_nuit_mod_v210_vdub.7z added |
---|
follow-up: 2 comment:1 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
comment:2 by , 5 years ago
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.
comment:3 by , 2 years ago
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.
follow-up: 5 comment:4 by , 2 years ago
Resolution: | invalid → duplicate |
---|
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.
comment:5 by , 2 years ago
Description: | modified (diff) |
---|
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
v210 with 0,1023 patches