Spontaneously slipping into command mode
This is a serious post about a serious issue -- restarted due to distracting responses. The best way to see and replicate the problem is to run this script (which creates three AC3s and a FOO.TXT on c:\): ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file1.ac3" ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file2.ac3" echo ffconcat version 1.0>c:\concat.txt echo file 'file1.ac3'>>c:\concat.txt echo file 'file2.ac3'>>c:\concat.txt ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3" echo this is foo>c:\FOO.TXT On my computer, '-t 240.0' created silent AC3s that were long-large enough to provoke the issue -- on your system, '-t' may need to be bigger. In the terminal output shown below, note these lines: <quote> Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho this is foo>c:\foo.txt' </quote> Egad! That should not be happening. To me, it indicates that after a certain length of execution time, FFmpeg goes into some sort of command mode during which it fetches the 'echo' string and responds to it as though it was a command to FFmpeg. WTF? If FFmpeg does have some sort of automatic command mode that it monitors, isn't that asking for trouble? Certainly I consider it a bug (or design flaw). C:\Windows\System32>ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file1.ac3" ffmpeg version 2025-07-23-git-829680f96a-full_build-www.gyan.dev Copyright (c) 2000-2025 the FFmpeg developers built with gcc 15.1.0 (Rev6, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-lc ms2 --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enabl e-avisynth --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enab le-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-liboapv --enable-libqrencode --enable-librav1e --enable -libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --en able-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidst ab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-openal --enable-libgme -- enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc -- enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --ena ble-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 60. 6.100 / 60. 6.100 libavcodec 62. 8.100 / 62. 8.100 libavformat 62. 1.103 / 62. 1.103 libavdevice 62. 0.100 / 62. 0.100 libavfilter 11. 3.100 / 11. 3.100 libswscale 9. 0.100 / 9. 0.100 libswresample 6. 0.100 / 6. 0.100 [out @ 0000000001cabf40] The "sample_fmts" option is deprecated: set the supported sample formats [out @ 0000000001cabf40] The "all_channel_counts" option is deprecated: accept all channel counts Input #0, lavfi, from 'anullsrc=channel_layout=2:sample_rate=48000': Duration: N/A, start: 0.000000, bitrate: 384 kb/s Stream #0:0: Audio: pcm_u8, 48000 Hz, 1 channels (FR), u8, 384 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_u8 (native) -> ac3 (native)) Press [q] to stop, [?] for help Output #0, ac3, to 'c:\file1.ac3': Metadata: encoder : Lavf62.1.103 Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s Metadata: encoder : Lavc62.8.100 ac3 [out#0/ac3 @ 0000000001cac040] video:0KiB audio:5625KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000000% size= 5625KiB time=00:03:59.99 bitrate= 192.0kbits/s speed= 329x elapsed=0:00:00.72 C:\Windows\System32>fmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file2.ac3" 'fmpeg' is not recognized as an internal or external command, operable program or batch file. C:\Windows\System32>echo ffconcat version 1.0>c:\concat.txt C:\Windows\System32>echo file 'file1.ac3'>>c:\concat.txt C:\Windows\System32>echo file 'file2.ac3'>>c:\concat.txt C:\Windows\System32>ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3" ffmpeg version 2025-07-23-git-829680f96a-full_build-www.gyan.dev Copyright (c) 2000-2025 the FFmpeg developers built with gcc 15.1.0 (Rev6, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-lc ms2 --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enabl e-avisynth --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enab le-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-liboapv --enable-libqrencode --enable-librav1e --enable -libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --en able-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidst ab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-openal --enable-libgme -- enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc -- enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --ena ble-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 60. 6.100 / 60. 6.100 libavcodec 62. 8.100 / 62. 8.100 libavformat 62. 1.103 / 62. 1.103 libavdevice 62. 0.100 / 62. 0.100 libavfilter 11. 3.100 / 11. 3.100 libswscale 9. 0.100 / 9. 0.100 libswresample 6. 0.100 / 6. 0.100 [ac3 @ 00000000026f2ac0] Estimating duration from bitrate, this may be inaccurate Input #0, concat, from 'c:\concat.txt': Duration: N/A, start: 0.000000, bitrate: 192 kb/s Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s Stream mapping: Stream #0:0 -> #0:0 (ac3 (native) -> ac3 (native)) Press [q] to stop, [?] for help Output #0, ac3, to 'c:\concat.ac3': Metadata: encoder : Lavf62.1.103 Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s Metadata: encoder : Lavc62.8.100 ac3 [ac3 @ 00000000026f8240] Estimating duration from bitrate, this may be inaccurate00.50 Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho this is foo>c:\foo.txt' [out#0/ac3 @ 000000000280bd00] video:0KiB audio:8438KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000000% size= 8438KiB time=00:05:59.99 bitrate= 192.0kbits/s speed=300x elapsed=0:00:01.20 C:\Windows\System32>
Mark: On 2025-07-27 09:42, Mark Filipak wrote:
This is a serious post about a serious issue -- restarted due to distracting responses.
The best way to see and replicate the problem is to run this script (which creates three AC3s and a FOO.TXT on c:\):
ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file1.ac3" ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file2.ac3" echo ffconcat version 1.0>c:\concat.txt echo file 'file1.ac3'>>c:\concat.txt echo file 'file2.ac3'>>c:\concat.txt ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3" echo this is foo>c:\FOO.TXT
On my computer, '-t 240.0' created silent AC3s that were long-large enough to provoke the issue -- on your system, '-t' may need to be bigger.
In the terminal output shown below, note these lines:
<quote> Enter command: <target>|all <time>|-1 <command>[ <argument>]
Parse error, at least 3 arguments were expected, only 1 given in string 'ho this is foo>c:\foo.txt' </quote>
I was unable to reproduce this problem, on macOS Sonoma 14.7.6, using zsh, and making the anullsrc files 10x the length. Here is your test script, modified for zsh and Unix-style paths: ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 2400.0 -c ac3 "$HOME/tmp/file1_2025-07-27.ac3" ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 2400.0 -c ac3 "$HOME/tmp/file2_2025-07-27.ac3" echo ffconcat version 1.0>$HOME/tmp/concat_2025-07-27.txt echo file "$HOME/tmp/file1_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt echo file "$HOME/tmp/file2_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt ffmpeg -y -safe 0 -i "$HOME/tmp/concat_2025-07-27.txt" "$HOME/tmp/concat_2025-07-27.ac3" echo this is foo >$HOME/tmp/foo_2025-07-27FOO.TXT
Egad! That should not be happening. To me, it indicates that after a certain length of execution time, FFmpeg goes into some sort of command mode during which it fetches the 'echo' string and responds to it as though it was a command to FFmpeg. WTF? If FFmpeg does have some sort of automatic command mode that it monitors, isn't that asking for trouble? Certainly I consider it a bug (or design flaw).
I understand that FFmpeg routinely monitors stdin while running, by design. When FFmpeg is running, and you type 'q', FFmpeg reads that from stdin, interrupts its work and quites. Or, suppose you did not specify the "-y" option in your ffmpeg command, and a file already exists at the output path you specify. I would expect ffmpeg to print a message like:
File 'output.mp3' already exists. Overwrite? [y/N] ...and then read your response from stdin.
See FFMpeg documentation, 5.4 Main Options <https://ffmpeg.org/ffmpeg-all.html#Main-options>, search for "-stdin":
-stdin
Enable interaction on standard input. On by default unless standard input is used as an input. To explicitly disable interaction you need to specify |-nostdin|.
Disabling interaction on standard input is useful, for example, if ffmpeg is in the background process group. Roughly the same result can be achieved with |ffmpeg ... < /dev/null| but it requires a shell.
So, given that you are not wanting FFmpeg to use stdin, and you are using stdin for other purposes, try adding -nostdin to your FFmpeg command. Does it behave better for you then?
On 27/07/2025 16.51, Jim DeLaHunt wrote:
Mark:
On 2025-07-27 09:42, Mark Filipak wrote:
This is a serious post about a serious issue -- restarted due to distracting responses.
The best way to see and replicate the problem is to run this script (which creates three AC3s and a FOO.TXT on c:\):
ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file1.ac3" ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 240.0 -c ac3 "c:\file2.ac3" echo ffconcat version 1.0>c:\concat.txt echo file 'file1.ac3'>>c:\concat.txt echo file 'file2.ac3'>>c:\concat.txt ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3" echo this is foo>c:\foo.txt
On my computer, '-t 240.0' created silent AC3s that were long-large enough to provoke the issue -- on your system, '-t' may need to be bigger.
In the terminal output shown below, note these lines:
<quote> Enter command: <target>|all <time>|-1 <command>[ <argument>]
Parse error, at least 3 arguments were expected, only 1 given in string 'ho this is foo>c:\foo.txt' </quote>
I was unable to reproduce this problem, on macOS Sonoma 14.7.6, using zsh, and making the anullsrc files 10x the length.
Hi, Jim. Thanks! So, you did not get "Enter command ... Parse error ..." in zsh, eh? Hmmm... As you can see above, I did. My theory is as follows: 1 - The next line of my script is echo ffconcat version 1.0>c:\concat.txt 2 - The redirection (>) somehow causes the running FFmpeg to see ec as a command. 4 - It errors out and cites ho this is foo>c:\foo.txt as the error. I remember seeing "Enter command..." from FFmpeg a couple of times in the distant past, but I didn't know how or why it was appearing. Now I know how but I don't know why.
Here is your test script, modified for zsh and Unix-style paths:
ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 2400.0 -c ac3 "$HOME/tmp/file1_2025-07-27.ac3" ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t 2400.0 -c ac3 "$HOME/tmp/file2_2025-07-27.ac3" echo ffconcat version 1.0>$HOME/tmp/concat_2025-07-27.txt echo file "$HOME/tmp/file1_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt echo file "$HOME/tmp/file2_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt ffmpeg -y -safe 0 -i "$HOME/tmp/concat_2025-07-27.txt" "$HOME/tmp/concat_2025-07-27.ac3" echo this is foo >$HOME/tmp/foo_2025-07-27FOO.TXT
Oh, that's great. Thanks.
Egad! That should not be happening. To me, it indicates that after a certain length of execution time, FFmpeg goes into some sort of command mode during which it fetches the 'echo' string and responds to it as though it was a command to FFmpeg. WTF? If FFmpeg does have some sort of automatic command mode that it monitors, isn't that asking for trouble? Certainly I consider it a bug (or design flaw).
I understand that FFmpeg routinely monitors stdin while running...
Oh, yes, of course. But-- But-- But my understanding is that > redirects to stdout. I'm not sending anything to stdin. ...So, (?). --Mark.
On 2025-07-27 15:45, Mark Filipak wrote:
On 27/07/2025 16.51, Jim DeLaHunt wrote:
...I understand that FFmpeg routinely monitors stdin while running... Oh, yes, of course. But-- But-- But my understanding is that > redirects to stdout.
I'm not sending anything to stdin. ...So, (?).
You are not sending anything to FFmpeg's stdin in your commands. It certainly seems like FFmpeg is receiving something on its stdin. So, perhaps something else is sending something to FFmpeg's stdin? Another agent in this situation is the Windows command shell, perhaps it is sending? But understanding the root cause is one thing. Preventing the symptoms is another, but perhaps that is enough. Does adding -nostdin to your FFmpeg invocations prevent the problem?
On 28-07-2025 02:18, Jim DeLaHunt wrote:
On 2025-07-27 15:45, Mark Filipak wrote:
On 27/07/2025 16.51, Jim DeLaHunt wrote:
...I understand that FFmpeg routinely monitors stdin while running... Oh, yes, of course. But-- But-- But my understanding is that > redirects to stdout.
I'm not sending anything to stdin. ...So, (?).
You are not sending anything to FFmpeg's stdin in your commands. It certainly seems like FFmpeg is receiving something on its stdin. So, perhaps something else is sending something to FFmpeg's stdin? Another agent in this situation is the Windows command shell, perhaps it is sending?
But understanding the root cause is one thing. Preventing the symptoms is another, but perhaps that is enough. Does adding
-nostdin
to your FFmpeg invocations prevent the problem?
I have been reading in on batch processing on Windows The issue here is Windows and how it handles batch scripts, and the issue goes back to its roots in DOS. The batch script is literally read into stdin (as a whole) and executed from there. Just like if you are typing every single line of the script on a command prompt. (which was exactly what batch processing was designed for in DOS) So yes running a program like FFmpeg that accepts commands from stdin while running will eat your remaining batch script as input. Unless... You invoke that program from the .bat with the START command, which will cause the program to run in a new session and does not use the stdin from the previous session where it was started from. or use something more modern for scripting on Windows like Powershell to overcome the stdin issue. or use the suggestion from Jim with the -nostdin option
participants (3)
-
Ferdi Scholten -
Jim DeLaHunt -
Mark Filipak