[FFmpeg-trac] #9573(avcodec:new): libx264 ignores color range flag for gray10 input

[FFmpeg]

#9573: libx264 ignores color range flag for gray10 input
-------------------------------------+-------------------------------------
             Reporter:  Diederick    |                    Owner:  (none)
  Niehorster                         |
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  libx264      |               Blocked By:
  gray10                             |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Diederick Niehorster):

 Thanks both!

 It seems that the docs here https://trac.ffmpeg.org/wiki/Encode/H.264 are
 wrong then, it says crf 0 is lossless.

 I can indeed verify that
 {{{
 ffmpeg -y -i test.mkv -vf
 "scale=in_range=pc:out_range=pc,format=yuv420p10" -c:v libx264 -preset
 veryfast -qp 0 test3.mp4
 }}}
 leads to a losslessly encoded file (yields zero pixel intensity value
 errors), super!

 Using your commands i have furthermore found that the workaround is not
 necessary. full-range gray10 is encoded correctly, it was a playback
 issue:
 {{{
 ffmpeg -y -i test.mkv -c:v libx264 -preset veryfast -qp 0 test3.mp4
 }}}
 followed by reading in the file with either "-vf extractplanes=y" or "-vf
 scale=in_range=pc" yields zero pixel intensity value errors in the output:
 input and output are identical.

 Note here that with reading in, i mean directly through the api
 (demux+decode). Its annoying that the pc scale info is lost by the
 automatically inserted filter turning the yuv420p10 back into gray10 /
 some rgb format and "-vf scale=in_range=pc" is thus needed. I'll dig into
 this to see if its set on the AVFrame delivered by the decoder, etc. Seems
 to me like this info should not get lost if its available.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9573#comment:10>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker