[FFmpeg-devel] [PATCH] mpeg4videodec: silence "Invalid and inefficient vfw-avi packed B frames detected" warning

[wm4]

On Fri, 30 Aug 2013 20:58:24 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> 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.

Just trying to reduce the general noise. If it's so controversial, I
can as well give up on it. However, my point stands that this message
is not really very informative, so it should be improved. (I think
there was some suggestions in this thread.)

> In part due to performance, in part because for example this
> format isn't working with the new VDPAU API (I am told).

It's the first time I hear about a VDPAU issue.

> [...]
> > 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.

There are many cases where it does that silently; even recently added
workarounds didn't print any warnings. Well, maybe they are not as
critical as this case in your opinion.