[FFmpeg-trac] #9132(undetermined:new): Wrong pixel format/output when converting video to yuv444p*

[FFmpeg]

#9132: Wrong pixel format/output when converting video to yuv444p*
-------------------------------------+-------------------------------------
             Reporter:  viley        |                     Type:  defect
               Status:  new          |                 Priority:  important
            Component:               |                  Version:  git-
  undetermined                       |  master
             Keywords:  regression   |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Converting a video input to ''any'' yuv444p pixel format seems broken
 right now.  Visually it looks very wrong (purples instead of blacks), in
 VLC, Potplayer and FFplay.
 FFmpeg's scaler (or auto_scaler) says it's writing the requested pixel
 format, but using FFprobe on the result, it finds a "gbrp" pixel format.

 This happens for video sources regardless of input format, and doesn't
 seem to depend on the target encoder (tried both libx264 and libx265) or
 container (tried avi, mp4, and matroska).

 Simplest way to reproduce, i.e. with the attached TESTCASE.mkv:

 {{{ffmpeg -i TESTCASE.mkv -pix_fmt yuv444p -c:v libx264 -crf 10 TESTCASE-
 yuv.mkv}}}

 Full debug log attached in a file, but if I add -loglevel 42, I see the
 auto_scaler converting to the correct format apparently:

 {{{
 [graph 0 input from stream 0:0 @ 0000000004e8cd00] w:420 h:212 pixfmt:gbrp
 tb:1/1000 fr:25/1 sar:1/1
 [auto_scaler_0 @ 0000000004e92c00] w:iw h:ih flags:'bicubic' interl:0
 [format @ 0000000004e8e0c0] auto-inserting filter 'auto_scaler_0' between
 the filter 'Parsed_null_0' and the filter 'format'
 [auto_scaler_0 @ 0000000004e92c00] w:420 h:212 fmt:gbrp sar:1/1 -> w:420
 h:212 fmt:yuv444p sar:1/1 flags:0x4
 }}}

 However, FFprobe detects gbrp:

 {{{
 Input #0, matroska,webm, from 'TESTCASE-yuv.mkv':
   Metadata:
     ENCODER         : Lavf58.68.100
   Duration: 00:00:04.00, start: 0.000000, bitrate: 17 kb/s
   Stream #0:0: Video: h264 (High 4:4:4 Predictive), gbrp(tv,
 gbr/unknown/unknown, progressive), 420x212 [SAR 1:1 DAR 105:53], 25 fps,
 25 tbr, 1k tbn, 50 tbc (de
 fault)
     Metadata:
       ENCODER         : Lavc58.126.100 libx264
       DURATION        : 00:00:04.000000000
 }}}

 More notes:

 * As mentioned, any yuv444p* pixel format will show the issue.  If I use
 yuv444p10le, FFprobe will report gbrp10le, etc.

 * Trying to explicitly insert a scaler does '''not''' fix the issue, for
 instance with {{{-vf
 "scale=iw:ih:flags=neighbor+full_chroma_inp:in_range=full:out_range=full:out_color_matrix=bt709"}}}

 * This doesn't happen with yuv420p* or yuv422p* formats, only the 4:4:4
 ones.

 * This also does not happen if the source is a looped .png, for instance:
 {{{ffmpeg -loop 1 -i testcase.png -frames:v 100 -pix_fmt yuv444p -c:v
 libx264 -crf 0 out.mkv}}} - in this case the output looks correct and
 FFprobe shows "yuv444p(tv, progressive)".

 Version: Using gyan.dev's Windows build (git-master, 2021-02-28).

 Tagging as a regression, since it looks like this was broken at some point
 between 2020-11-19 (last build that didn't show the issue) and 2021-01-12.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/9132>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker