[FFmpeg-user] Spontaneously slipping into command mode

[Jim DeLaHunt]

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?