[FFmpeg-trac] #8195(undetermined:closed): v210 encoding clips to 4-1019

[FFmpeg]

#8195: v210 encoding clips to 4-1019
-------------------------------------+-------------------------------------
             Reporter:  pdr0         |                    Owner:  (none)
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:  duplicate
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Old description:

> 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

New description:

 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

--
Comment (by pdr0):

 Replying to [comment:4 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
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/8195#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker