[FFmpeg-trac] #9132(ffmpeg:open): Wrong pixel format/output when converting video to yuv444p*
FFmpeg
trac at avcodec.org
Tue Jun 22 00:20:33 EEST 2021
#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):
I did make an attempt
(https://github.com/jeeb/ffmpeg/commits/swscale_check_colorspace_changed)
some time ago, but alas with that quick test I couldn't flag the right
spots on where swscale had changed the color space. In theory having
swscale tell you when it changed the content color space would be the best
way since that way people utilizing swscale wouldn't have to duplicate
that logic onto their own API usage (outside of vf_scale). Alternatively
we'd just have AVFrame interfaces for swscale, but I don't think that
would happen any time soon.
Thus it seems like the most realistic short term thing is a change towards
vf_scale where you have a color space checker function that checks if
f.ex. the gbr identify matrix is set and your output pix_fmt is not RGB
(among other cases). Then the color space information could be reset
accordingly (since currently the problem is that `av_frame_copy_props`
does indeed copy all properties from the source AVFrame to the output
AVFrame, and nothing touches the colorspace value in the structure).
On IRC there were ideas like just stopping the exposure of the identity
matrix since effectively the RGB pix_fmts already provide that
information, but I was not sure if that was the best solution.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9132#comment:15>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list