[FFmpeg-devel] [PATCH] ffmpeg: raise level for message printed in case of auto-select pixel format

[Michael Niedermayer]

On Tue, Jul 30, 2013 at 10:05:55PM +0200, Nicolas George wrote:
> Le duodi 12 thermidor, an CCXXI, Michael Niedermayer a écrit :
> > not choosing != 420 automatically for x264 is maybe better than
> > warning the user that it was changed.
> 
> Is it really possible, conveniently?
> 
> For example, I frequently use "format=yuv444p" in a filter chain to control
> precisely where the conversion happens with regard to the other filters
> (yadif and hqdn3d for example). If that happens, ffmpeg does not know that I
> specifically selected that pixel format, will I have to also specify
> -pix_fmt yuv444p? That is ridiculously redundant. Or shall we add a flag
> "user specified" to all format fields on a filter link? That is a lot of
> work for a rather trivial issue.
> 
> > If its to be a log message instead of avoiding the issue that needs
> > the message then i think the majority is in favor of
> > it being warning level though i didnt re-count
> 
> The core issue here is that the user does not inform the software of what
> they want precisely, and instead relies on default values and imperfect
> heuristics. IMHO, the good way of solving that is to educate the users.

i think that 90% of the users dont know if they want 420 or
444 h264.
IMO software (and hardware) should just work, not _require_
complicated manual tweaking for the common use cases.

Educating users is a great idea as long as its just one case
and one product. But honestly i dont think i would want every product
i use from a toothbrush to a potato peeler to _force_ me to have to
read the manual and google some problem to get it working.
and IMHO ffmpeg isnt different for other people
ffmpeg -i inputfile outputfile
should just work

if it fails with a warning that many users accessing it through a GUI
wont see and thuse who do see it and dont miss it maybe wont fully
understand it without educating themselfs on it to make a decission.
then IMHO this is not optimal

Its a bit as if when calling someone over the phone the phone would
stay silent and display a message that it choose a protocol that might
not be supported but would then be higher quality if it is supported
and require manual intervention to get a working phone connection.
The correct thing to do is to pick the more compatible choice by
default if it cant be autodetected and leave users with the option
to override it, change the default as they prefer

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130730/aa484ffb/attachment.asc>