Opened 6 years ago

Closed 6 years ago

#1687 closed defect (fixed)

-v quiet -stats

Reported by: gd2shoe Owned by:
Priority: minor Component: ffmpeg
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Change History (5)

comment:1 in reply to: ↑ description Changed 6 years ago by cehoyos

  • Status changed from new to open
  • Version changed from unspecified to git-master

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

comment:2 Changed 6 years ago by 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.

comment:3 follow-up: Changed 6 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 6 years ago by 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.)

comment:5 Changed 6 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.