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
_______________________________________________
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".
