Opened 12 years ago
Closed 12 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 by , 12 years ago
Status: | new → open |
---|---|
Version: | unspecified → git-master |
comment:2 by , 12 years ago
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.
follow-up: 4 comment:3 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
Reproduced by developer: | set |
---|---|
Resolution: | → fixed |
Status: | open → closed |
Replying to gd2shoe:
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.)