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

[FFmpeg]

#9132: Wrong pixel format/output when converting video to yuv444p*
------------------------------------+----------------------------------
             Reporter:  viley       |                    Owner:  (none)
                 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:19 Balling]:
 > >this one case of invalid metadata
 >
 > There are other cases??
 >

 I generally don't expect any code to be perfect. So there may or may not
 be issues. It's a way of wording. So far it's this one that has popped up.

 > Why you do not want to reset all
 https://github.com/jeeb/ffmpeg/commit/09abc1ea76d87d73ad2ec4a331139baeb618f8fb
 #diff-
 dc711ef6bb905f1c3a99a4552c12f72c2020e1fc6240ed5f3d9d5867081d4ca4R743?
 >

 Because nobody helped me when I asked regarding swscale and where the
 needed locations were. Also it was disliked since it throws the baby out
 together with the bathwater. So the simple invalidation it is. If the
 AVFrame is flagged as RGB, but pix_fmt is not RGB, then off that value
 goes.

 I expect that more logic that actually follows what swscale itself is
 doing (whatever it is doing) will be added as the swscale AVFrame API gets
 merged.

 > In particular it is very important that chroma siting (which is
 different for JPEG, avc and HDR in HEVC) will be correctly set in VUI in
 avc/hevc bitsream. P.S. I do not know whether it is being done even now,
 for example '''convertion''' from jpeg 4:2:0 to avc 4:2:0 should change
 chroma siting from center to left not just tag it, but does it happen?
 >

 I don't think there's any other filter than maybe zscale which will do
 chroma_location adjustment for you in libavfilter (and even in that case
 you probably have to go through 4:4:4). So much more realistic is just the
 case of passing that value on from the input, so it is flagged in the
 output correctly.

 That said, you can just look at the result of:

 {{{
 git grep -E "chroma_sample_location|chroma_location" -- libavcodec/
 }}}

 You can see that the cli tools and pretty much two or so encoders actually
 touch that value :P . H.264/HEVC decoders and the dav1d wrapper do expose
 it, though. Which is why players have access to the value in these cases.

 I actually noticed this the other day when reviewing an SVT-AV1 patch that
 touched other metadata values, but not chroma location.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9132#comment:20>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker