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

Michael Niedermayer michaelni at gmx.at
Tue Jul 30 20:11:54 CEST 2013


On Tue, Jul 30, 2013 at 04:38:16PM +0200, Stefano Sabatini wrote:
> On date Monday 2013-07-29 21:04:00 +0200, Reimar Döffinger encoded:
> > On Mon, Jul 29, 2013 at 10:18:07AM -0800, Lou Logan wrote:
> > > On Mon, 29 Jul 2013 12:04:09 +0200, Hendrik Leppkes wrote:
> > > 
> > > > On Mon, Jul 29, 2013 at 11:50 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > > > > Stefano Sabatini <stefasab <at> gmail.com> writes:
> > > > >
> > > > >> On date Monday 2013-07-29 09:36:06 +0000, Carl Eugen Hoyos encoded:
> > > > >> > Stefano Sabatini <stefasab <at> gmail.com> writes:
> > > > >> >
> > > > >> > > Will push the change in a day.
> > > > >> >
> > > > >>
> > > > >> > You still haven't explained why raising the level
> > > > >> > of a purely informational message makes any sense.
> > > > >>
> > > > >> I did it extensively and repeatedly in the past thread.
> > > > >
> > > > > While I can't really follow you with this message,
> > > > > please do not commit, this patch does no good.
> > > > >
> > > > 
> > > > Luckily, everyone is entitled to their own opinion.
> > > > 
> > > > I think the patch is useful, since it warns the user about an
> > > > assumption the code makes, which in quite a lot of cases may not be
> > > > what the user really wants.
> > > > To ensure the user sees this warning, it should also be marked as a
> > > > warning, or it might be missed, resulting in questions and/or
> > > > complaints later.
> > > > 
> > > > So IMHO, just go ahead and push.
> > > > 
> > > > - Hendrik
> > > 
> > > Agreed. After helping dozens of users with this issue, and observing
> > > others spending their time to do the same, making the message more
> > > likely to be seen is something that I support.
> > 
> > I know I am being pedantic, but what is "this issue"? Certainly
> > not the fact that a format was auto-selected.
> > So in principle it seems likely an even better solution would
> > be to only print this message when there is reason to believe
> > it might cause issues - which I think might address Carl's
> > objection (in particular I guess that it clutters the output with something
> > that is actually not a warning or in any way indicative of any issue).
> > Not that I say I believe it worth implementation effort.
> 
> Exact, the point is that there is nothing intrinsically wrong with
> yuv444 in H.264, and ffmpeg can create many outputs which can only be
> played by ffmpeg.
> 
> The only difference is that there are lot of people who do that
> specific conversion (RGB -> H-264) and realize the output seems
> "broken" and players usually don't care giving sensible feedback why
> they can't play the file.
> 
> So I agree that it would be more correct to keep the current INFO
> level, on the practical side raising the log level might avoid user
> reports, since it will increase the chance that people will notice the
> message.
> 
> I have no strong opinion on this and will leave the choice to the
> ffmpeg tool maintainer.

not choosing != 420 automatically for x264 is maybe better than
warning the user that it was changed.
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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/a68c4c3b/attachment.asc>


More information about the ffmpeg-devel mailing list