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?
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
