[FFmpeg-user] It appears that FFmpeg is slipping into command mode

[Jim DeLaHunt]

Mark, I get the impression that you are not hearing what people in this 
thread are trying to tell you.

On 2025-07-28 14:05, Mark Filipak wrote:
> FFmpeg is clearly entering a command mode even though I'm not submitting
> any options that support command mode.

FFmpeg listens to stdin and accepts commands all. the. time., unless you 
tell it not to by giving the `-nostdin` option.

Here is some more information about that behaviour.

1. In the FFmpeg transcripts you posted, FFmpeg prints, "Press [q] to 
stop, [?] for help".  That is FFmpeg telling you that it is accepting 
commands from stdin.

2. To find out more about those commands, press [?] while FFmpeg is 
running. You will probably get a printout like:

> key    function
> ?      show this help
> +      increase verbosity
> -      decrease verbosity
> c      Send command to first matching filter supporting it
> C      Send/Queue command to all matching filters
> h      dump packets/hex press to cycle through the 3 states
> q      quit
> s      Show QP histogram
>
(For those who like to read source code, the relevant function is 
`check_keyboard_interaction()` at fftools/ffmpeg.c:805-867 
<https://github.com/FFmpeg/FFmpeg/blob/7c5319e6924fd82772eff890df191f973767d38e/fftools/ffmpeg.c#L805C1-L867C2>.)

3. note that "c" is one of those FFmpeg commands, and that your code 
includes "c":

> ...[elided]...
> The command is:
>
> ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3"
> echo this is foo>c:\FOO.TXT
>
> The thing that's bothering me so much is that while it's doing the
> concatenation, FFmpeg signals:
>
> 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'

This is consistent with something feeding "echo this is foo>c:\FOO.TXT" 
to FFmpeg's stdin, FFmpeg ignoring the 'e' as unrecognised, accepting 
the 'c' as "Send command to first matching filter supporting it", FFmpeg 
printing an "Enter command:" prompt, then attempting and failing to 
parse "ho this is foo>c:\FOO.TXT" as a command.

And, the Windows Command Prompt appears to be sloppy about how it 
handles stdin.
On 2025-07-27 23:57, Ferdi Scholten wrote:
 > 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

So, do you hear us when we tell you that FFmpeg by default accepts 
commands on stdin while running?

Do you hear us when we tell you that the `-nostdin` option is the way to 
tell FFmpeg not to do that?

Do you hear us when we tell you that the Windows command prompt maybe be 
what feeds the Echo command to FFmpeg's stdin? And that this may just be 
a limitation of how the Windows command prompt works?

Best regards,
     —Jim DeLaHunt