[FFmpeg-devel] [PATCH] mpeg4videodec: silence "Invalid and inefficient vfw-avi packed B frames detected" warning
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Aug 30 20:58:24 CEST 2013
On Thu, Aug 29, 2013 at 10:07:29PM +0200, wm4 wrote:
> On Thu, 29 Aug 2013 21:55:17 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>
> > On Thu, Aug 29, 2013 at 07:48:32PM +0000, Paul B Mahol wrote:
> > > On 8/29/13, wm4 <nfxjfg at googlemail.com> wrote:
> > > > On Thu, 29 Aug 2013 21:31:54 +0200
> > > > Nicolas George <nicolas.george at normalesup.org> wrote:
> > > >
> > > >> Le duodi 12 fructidor, an CCXXI, wm4 a ecrit :
> > > >> > Seeking (resetting the decoder) causes the warning to be printed again.
> > > >> > Disabling warnings is not an option, because warnings are supposed to
> > > >> > signal that something might be wrong.
> > > >>
> > > >> So it is printed once after each seek. How is that a problem?
> > > >>
> > > >> It informs about a problem that can have practical consequences (try
> > > >> playing
> > > >> this kind of files with a limited CPU) and can be fixed (although not with
> > > >> ffmpeg for now). That is exactly what a warning is made for. Simply
> > > >> removing
> > > >> it would be idiotic.
> > > >
> > > > The warning is completely meaningless and confusing.
> > >
> > > Perhaps warning can be printed only if error recognition is set to
> > > some reasonable value?
> >
> > One of the reasons for the warning is to make people stop using the
> > tools that create these broken files.
> > Ideally also to fix them.
>
> This doesn't work, you'll just annoy your users because you want to make
> a point. Most people who want to play (or transcode) a video couldn't
> care less how the original video was created.
It's not like the message jumps out of your monitor and tries to devour
you alive. This is useful information about a video that can have
potential issues. And as was pointed out, the way this file
was created is very relevant.
In part due to performance, in part because for example this
format isn't working with the new VDPAU API (I am told).
Also, if users are easily annoyed by programs trying to give
them useful information, they can set the log level to fatal.
> > However I think it is badly worded for that purpose.
> > In the link I gave I suggested at least pointing to tools
> > to fix it.
> > What would be a reasonable way?
> > 'Video uses a non-standard and wasteful way to store B-frames ("packed
> > B-frames"). Consider using a tool like VirtualDub or avidemux to fix
> > it.'
>
> Well, at least one file that prints the warning actually shows
> VirtualDub as creator, so that'd be confusing too. And again, users
> couldn't care less.
I don't know why you think you can speak for "users" in general,
I gave examples why some are likely to care.
Also I don't see why it is relevant that the file was created by
VirtualDub, it can still fix it (I suspect it has to do with the
codec used, but making the message novel-sized to explain all
the details seems hardly a good idea).
> > Is it really a problem if it's printed always when seeking?
> > I don't see the big deal with warning messages for files that definitely
> > are badly done.
>
> This warning seems to be printed relatively often, and it would be nice
> if warnings would be printed only in cases there is an actual problem.
It's not unlikely people will have real-world issues with those files.
Though I would have no objections with changing it to INFO, if people
think that might be more appropriate.
I am against making it not be displayed by default, and I am certainly
against removing it completely, and I would prefer it to be more
useful for users.
> Yes, ffmpeg has to tolerate broken tools and files by still being able
> decoding them. That's stupid, but hey, it's its job.
I don't know why it has to do so silently though, warning users
about tools/files that are questionable has been FFmpeg policy since
a long time, because it
1) helps developers of tools to avoid such mistakes
2) gives users an option to fix their tools or use better ones
3) helps users avoid storing data in formats that have a
higher-than-average risk of breaking in the future
with the last one being the most critical one.
More information about the ffmpeg-devel
mailing list