[FFmpeg-devel] [PATCH] ffmpeg: Don't offer H.264 compatibility warning for NV12 input

wm4 nfxjfg at googlemail.com
Thu Jun 15 14:14:34 EEST 2017


On Thu, 15 Jun 2017 16:12:00 +0530
Gyan <gyandoshi at gmail.com> wrote:

> On Thu, Jun 15, 2017 at 3:04 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 
> 
> > It's wrong and dumb because the pixfmt is not enough to tell whether
> > the encoder will produce a file with w widely compatible profile.
> >  
> 
> yuv420p is not sufficient to ensure compatibility but !yuv420p is
> sufficient to ensure incompatibility (with browsers and most players).

That doesn't conflict with what I said.

> 
> > I think what you really want is either
> > - defaulting h264 encoding to Main or High profile only
> >  
> 
>  libx264 already defaults to High, which doesn't prevent non-yuv420p output
> e.g. encoding of a PNG sequence.

"non-yuv420p output" doesn't make ANY sense. You don't know and don't
have to care what some random third party decoders will output. Many
indeed never output yuv420p, but use nv12 and even packed or tiled
formats.

The same is true for encoder input. As the patch shows, not all
encoders are restricted to yuv420p even when encoding only to the simple
profiles.

Forcing the "High" or maybe "Main" profile is enough to ensure
compatibility. That is what profiles were designed for. Applying your
bogus "non-yuv420p output" idea on libavcodec's decoder, libavcodec
would indeed never output non-yuv420p for High profile input (unless you
use hwaccel, then it would most likely output nv12).

> Presets bring their other baggage along with them, which the user may not
> want. If the user knew how to select or set presets, they would know which
> pixel format is required. The primary audience for this warning is the lay
> or occasional user, who isn't manually setting the profile or the pix_fmt,
> and and is likely to get tripped up if the input is not yuv420p.

By default, ffmpeg CLI's design is something like "fuck the user". I'm
not sure what you are even arguing about. The situation is bad, and the
warning is a shitty insufficient hack trying to prevent damage caused
by that.


More information about the ffmpeg-devel mailing list