[FFmpeg-devel] [PATCH v2 3/3] avcodec/libx264: remove separate libx264rgb RGB wrapper

[Jan Ekström]

On Fri, Jul 2, 2021 at 6:25 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Fri, Jul 02, 2021 at 02:25:13PM +0300, Jan Ekström wrote:
> > No other encoder wrapper in libavcodec is split like this, and
> > with RGB input this currently does not lead to 4:2:0 (which would
> > be generally supported in most hardware and software implementations),
> > but rather 4:4:4.
> >
> > The libx262 encoder definition was not touched, as it already has
> > 4:4:4 YCbCr defined for it, which as far as I can tell is not supported.
> > ---
> >  configure              |  2 --
> >  doc/encoders.texi      |  7 ++++---
> >  libavcodec/allcodecs.c |  1 -
> >  libavcodec/libx264.c   | 43 ++++++------------------------------------
> >  libavcodec/version.h   |  2 +-
> >  5 files changed, 11 insertions(+), 44 deletions(-)
>
> breaks:
> ./ffmpeg -i lena.pnm -vf format=bgr24 -vcodec libx264rgb  file-bgr.nut
>

That is expected since the encoder is no longer there and standard
"libx264" moniker is to be utilized.

> also it breaks creating files which are playable on devices not supporting rgb
> with a plain libx264 encoder selection
>

So things that:
1. Support 4:4:4
2. But don't support reading the BGR metadata.

I would say that is a rather limited set of things. For most users I
expect they already had to specify the pixel format they required
since the vast majority require 4:2:0 if they want to support HW
decoding on most devices.

The ticket that was pointed towards when this wrapper was added
(https://trac.ffmpeg.org/ticket/658) specifically requested that 4:2:0
YCbCr should be the default for hw and sw implementations that are
more limited. The result currently is that for RGB input you get 4:4:4
YCbCr, and most likely this was the case back then as well (albeit I
can be incorrect in this). In any case, the usefulness of having these
two things split seems to be /very/ limited at this point.

Jan