Opened 6 years ago
Closed 5 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
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: ↓ 4 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 5 years ago by michael
- Reproduced by developer set
- Resolution set to fixed
- Status changed from open to 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.)