-v quiet -stats

[gd2shoe]

Summary of the bug:

-v quiet overrides even an explicit -stats flag.

I'm trying to write a python script that uses ffmpeg for transcoding. I'd like to retain the progress for the user, but scrap the initial info (and other info lines). I'll probably devise some filter in the meanwhile, but this still seems broken.

As it stands now, I can't see what -stats is supposed to do. It is always on, except when -v turns it off, and then it is always off. This seems very odd.

I suspect the solution will be to make the debugging level of the progress output conditional on the -stat flag. Without actually finding it in the code, I think this should be fairly straightforward.

How to reproduce:

% ffmpeg -v quiet -stats -i input ... output
% ffmpeg -v panic -stats -i input ... output
% ffmpeg -v fatal -stats -i input ... output
% ffmpeg -v error -stats -i input ... output
% ffmpeg -v warning -stats -i input ... output

Running on Windows XP in Cygwin Console, but I really doubt that matters.

ffmpeg version N-43594-gf0896a6 Copyright (c) 2000-2012 the FFmpeg developers
  built on Aug 15 2012 21:25:48 with gcc 4.7.1 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 69.100 / 51. 69.100
  libavcodec     54. 52.100 / 54. 52.100
  libavformat    54. 23.101 / 54. 23.101
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  9.100 /  3.  9.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100

[cehoyos]

Replying to gd2shoe:

As it stands now, I can't see what -stats is supposed to do.

So is this a request to remove it?
(In the past, ffplay by default did not show any stats, I suspect this was the reason for the option.)

[gd2shoe]

No, this is a request to fix it.

As it stands today, it really make no sense to keep, unless it is decoupled from the debugging levels (or unless I'm missing something).

It would, on the other hand, be really useful to have progress, and ONLY progress as program output. The obvious way to communicate that on the command line is:
ffmpeg -v quiet -stats ...

This, of course doesn't work, but I don't see why it shouldn't.

[Cigaes]

The -stats option exists mostly for symmetry with the -nostats option, because the options parsing code works that way. The default is -stats, so it has no effect.

The stats go through the logging mechanism, and as such are subject to the loglevel system, regardless of the -stats option.

[gd2shoe]

Replying to Cigaes:

The -stats option exists mostly for symmetry with the -nostats option, because the options parsing code works that way.

Interesting.

The default is -stats, so it has no effect.

Part of my point. It makes little to no sense to have an option that does nothing whatsoever.

The stats go through the logging mechanism, and as such are subject to the loglevel system, regardless of the -stats option.

It is this idea that I wish to challenge. If -stats appears on the command line, it is because the user explicitly wants that particular output, regardless of logging level.

Is there any reason to think otherwise?

Frankly, I don't see why the progress meter must be fixed at the info level. Why can't it exist at info by default? Why can't -stat move progress to the current log level? Especially if attached to a tty?

If that sounds stupid, then why can't -stat change from logging to stderr? Or why can't there be another option to suppress non-progress output. (It makes more sense to me to fix and reuse the option that is already there-- but worthless-- than to invent a new one, but it would fit the bill.)