#729 closed defect (invalid)
"Option loop not found."
Reported by: | burek | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
when I use "-loop 1" it says "Option loop not found."
and when I use "-loop_input" it says "-loop_input is deprecated, use -loop 1" :)
here are the respected outputs:
# ffmpeg -loop 1 -i http://admin:@82.13.197.168:82/audio.cgi -acodec libaacplus -ab 32k -ar 44100 -f mpegts udp://burek.teamnet.rs:10001 ffmpeg version N-35166-g9e794d1, Copyright (c) 2000-2011 the FFmpeg developers built on Nov 25 2011 22:41:19 with gcc 4.6.1 configuration: --enable-static --enable-shared --enable-gpl --enable-nonfree --enable-postproc --enable-libx264 --enable-libaacplus --enable-libmp3lame --enable-libv4l2 --enable-libvo-aacenc --enable-version3 libavutil 51. 29. 0 / 51. 29. 0 libavcodec 53. 37. 0 / 53. 37. 0 libavformat 53. 21. 0 / 53. 21. 0 libavdevice 53. 4. 0 / 53. 4. 0 libavfilter 2. 49. 0 / 2. 49. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 51. 2. 0 / 51. 2. 0 Option loop not found.
and 2nd try:
# ffmpeg -loop_input -i http://admin:@82.13.197.168:82/audio.cgi -acodec libaacplus -ab 32k -ar 44100 -f mpegts udp://burek.teamnet.rs:10001 ffmpeg version N-35166-g9e794d1, Copyright (c) 2000-2011 the FFmpeg developers built on Nov 25 2011 22:41:19 with gcc 4.6.1 configuration: --enable-static --enable-shared --enable-gpl --enable-nonfree --enable-postproc --enable-libx264 --enable-libaacplus --enable-libmp3lame --enable-libv4l2 --enable-libvo-aacenc --enable-version3 libavutil 51. 29. 0 / 51. 29. 0 libavcodec 53. 37. 0 / 53. 37. 0 libavformat 53. 21. 0 / 53. 21. 0 libavdevice 53. 4. 0 / 53. 4. 0 libavfilter 2. 49. 0 / 2. 49. 0 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 51. 2. 0 / 51. 2. 0 -loop_input is deprecated, use -loop 1 [wav @ 0x13ce7a0] parser not found for codec pcm_s16le, packets or times may be invalid. [wav @ 0x13ce7a0] max_analyze_duration 5000000 reached at 5120000 Input #0, wav, from 'http://admin:@82.13.197.168:82/audio.cgi': Duration: 00:00:32.76, bitrate: N/A Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, 1 channels, s16, 256 kb/s [mpegts @ 0x13d0da0] muxrate VBR, pcr every 2 pkts, sdt every 200, pat/pmt every 40 pkts Output #0, mpegts, to 'udp://burek.teamnet.rs:10001': Metadata: encoder : Lavf53.21.0 Stream #0:0: Audio: aac, 44100 Hz, 1 channels, s16, 32 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s16le -> libaacplus) Press [q] to stop, [?] for help ^Cze= 143kB time=00:00:32.36 bitrate= 36.1kbits/s
Change History (3)
comment:1 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Generally, you should try to minimize requests for additional user's actions, after a bug report has been made, otherwise you'll end up in a situation that nobody cares anymore to report a bug, because of all the 'prerequisites'. Also, most of the bug reports should be considered merely as hints to where the developers should take a look to make sure there is or is no bug present. I know the developers always lack free time to spend on bug reports, but guess what, we (users) also lack time and will to report bugs, because it's much easier to use another tool for the same task, which ultimately leaves FFmpeg project on the loosing side.
I personally wouldn't like the FFmpeg project to end up like VLC project, where various people have put a lot of effort to report bugs (with full output logs) which never even got a decent reply from the developers and in some cases replies were so offending and humiliated so that other users, reading those kind of posts, simply dropped their intention to participate in such community, which, again, makes the project itself suffer the most.
I understand your recommendations and I'll take them into account for my next bug reports, but you should at least update the FFmpeg bug reporting guidelines, to reflect what have you just said otherwise it will make no sense to repeat yourself each and every time somebody files a new bug report.
And finally (and most important), you shouldn't discard bug reports that easily, because they do reflect something odd in FFmpeg's behavior. In this particular case the correct behavior would be to change the FFmpeg's warning/error message to say "The -loop input option (exactly as -loop_input) only works for input of format -f image2. While -loop_input is (was) silently accepted even for input media that is not of format image2...", because otherwise the message really looks silly and completely useless, adding to that the documentation says absolutely nothing about it.
Cheers.
Generally, regarding bug reports (mostly unrelated to the issue in question):
If it is not needed for a report, please do not use external libraries like libx264, libfaac or libaacplus in the command line given to reproduce the problem. (Of course only if the problem is reproducible without using the external library.)
Please use network input and output only if you want to report a network issue, most issues should be reported only using the file (or the pipe) protocol.
And finally (and most difficult): Please try to use either the media file(s) that comes with FFmpeg (tests/lena.pnm) as input, or a file that is produced by make fate, or a file that is part of the fate test suite. This is of course not always possible!
The -loop input option (exactly as -loop_input) only works for input of format -f image2. While -loop_input is (was) silently accepted even for input media that is not of format image2 (but did not work), -loop correctly fails if the input format does not support -loop.