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

FFmpeg trac at avcodec.org
Thu Mar 25 12:44:54 EET 2021


#9132: Wrong pixel format/output when converting video to yuv444p*
------------------------------------+----------------------------------
             Reporter:  viley       |                    Owner:
                 Type:  defect      |                   Status:  open
             Priority:  important   |                Component:  ffmpeg
              Version:  git-master  |               Resolution:
             Keywords:  regression  |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  0           |
------------------------------------+----------------------------------

Comment (by JEEB):

 Replying to [comment:10 Balling]:
 > Replying to [comment:9 JEEB]:
 > > I am not sure what that is a reference to?
 >
 > Because there are two h.264 wrappers around one 264 encoder, nobody
 cared about that bug is what I meant. rgb will not touch Identity matrix.
 And not rgb will always remove it.
 >

 I see it a bit differently. Nobody cared about this bug before as the
 information from the filter chain was not utilized. :) Thus you had to
 once set the metadata in the filter chain, and once for the encoder -
 separately. Also most likely other filters would then only look at pix_fmt
 to see if it's RGB or not, not the colorspace field.

 Also it would work if the input would not set any color space fields,
 which explains why f.ex. Ut Video from RGB to YCbCr would work, or just
 pure piped raw RGB. In this case the H.264 decoder sets the colorspace
 field, and that metadata is passed through the scale filter.

 > Also BTW, what that means is that there is no FATE for RGB to YCbCr that
 looks into matrix. Wow. See, it all passed:
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201027183056.17993-5-jeebjp@gmail.com/

 Yup. We have tests most likely to verify that the conversion from RGB to
 YCbCr works correctly (data wise), but nothing checks that if the input
 AVFrame has color metadata set, that the AVFrame metadata made after such
 a conversion. That would basically be something to add after the issue is
 fixed, I 100% agree.

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


More information about the FFmpeg-trac mailing list