It appears that FFmpeg is slipping into command mode
PREFACE: It appears that FFmpeg is slipping into command mode, taking the next couple letters from stdin, and interpreting them. That screws up the remaining script of course. Note: This is using Gyan's latest git build. Workaround: Use 'start ffmpeg' instead of 'ffmpeg'. That causes the two invocations to run in separate terminal sessions (but note that they then run concurrently instead of sequentially). I will not submit this as a bug until it's been replicated. This requires some set up. %_JOB_%DELAY2CH.ac3 and %_JOB_%DELAY6CH.ac3 are 33 frames of silence, created by the first script. %_JOB_%a0.ac3 is an existing 2.0 ac3 file. %_JOB_%a1.ac3 is an existing 5.1 ac3 file. %_JOB_%CONCATa0.txt and %_JOB_%CONCATa1.txt are created. %_JOB_%DELAYEDa0.ac3 and %_JOB_%DELAYEDa1.ac3 are created. : set _JOB_=<d:\path\name> set _JOB_=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] set _DELAY2CH_=%_JOB_%DELAY2CH.ac3 set _DELAY6CH_=%_JOB_%DELAY6CH.ac3 set _SILENCE2_=anullsrc=channel_layout=2:sample_rate=48000 set _SILENCE6_=anullsrc=channel_layout=5.1:sample_rate=48000 set _33FRAMES_=1.376375 ffmpeg -f lavfi -i %_SILENCE2_% -t %_33FRAMES_% -c ac3 "%_DELAY2CH_%" ffmpeg -f lavfi -i %_SILENCE6_% -t %_33FRAMES_% -c ac3 "%_DELAY6CH_%" The following works: (Note the use of 'start' commands. ) : set _JOB_=<d:\path\name> set _JOB_=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] set _DELAY2CH_=%_JOB_%DELAY2CH.ac3 set _DELAY6CH_=%_JOB_%DELAY6CH.ac3 set _SOURCEa0_=%_JOB_%a0.ac3 set _SOURCEa1_=%_JOB_%a1.ac3 set _DELAYEDa0_=%_JOB_%DELAYEDa0.ac3 set _DELAYEDa1_=%_JOB_%DELAYEDa1.ac3 echo ffconcat version 1.0>"%_JOB_%CONCATa0.txt" echo file '%_DELAY2CH_%'>>"%_JOB_%CONCATa0.txt" echo file '%_SOURCEa0_%'>>"%_JOB_%CONCATa0.txt" start ffmpeg -y -safe 0 -i "%_JOB_%CONCATa0.txt" "%_DELAYEDa0_%" echo ffconcat version 1.0>"%_JOB_%CONCATa1.txt" echo file '%_DELAY6CH_%'>>"%_JOB_%CONCATa1.txt" echo file '%_SOURCEa1_%'>>"%_JOB_%CONCATa1.txt" start ffmpeg -y -safe 0 -i "%_JOB_%CONCATa1.txt" "%_DELAYEDa1_%" The following screws up as described in PREFACE: : set _JOB_=<d:\path\name> set _JOB_=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] set _DELAY2CH_=%_JOB_%DELAY2CH.ac3 set _DELAY6CH_=%_JOB_%DELAY6CH.ac3 set _SOURCEa0_=%_JOB_%a0.ac3 set _SOURCEa1_=%_JOB_%a1.ac3 set _DELAYEDa0_=%_JOB_%DELAYEDa0.ac3 set _DELAYEDa1_=%_JOB_%DELAYEDa1.ac3 echo ffconcat version 1.0>"%_JOB_%CONCATa0.txt" echo file '%_DELAY2CH_%'>>"%_JOB_%CONCATa0.txt" echo file '%_SOURCEa0_%'>>"%_JOB_%CONCATa0.txt" ffmpeg -y -safe 0 -i "%_JOB_%CONCATa0.txt" "%_DELAYEDa0_%" echo ffconcat version 1.0>"%_JOB_%CONCATa1.txt" echo file '%_DELAY6CH_%'>>"%_JOB_%CONCATa1.txt" echo file '%_SOURCEa1_%'>>"%_JOB_%CONCATa1.txt" ffmpeg -y -safe 0 -i "%_JOB_%CONCATa1.txt" "%_DELAYEDa1_%" Here is the 'screw-up's terminal output: (Note these lines: (Enter command: <target>|all <time>|-1 <command>[ <argument>] ( (Parse error, at least 3 arguments were expected, only 1 given in string 'ho file ' ('%_SOURCEa1_%'>>"%_JOB_%CONCATa1.txt"') C:\Windows\System32>set _JOB_=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] C:\Windows\System32>set _DELAY2CH_=%_JOB_%DELAY2CH.ac3 C:\Windows\System32>set _DELAY6CH_=%_JOB_%DELAY6CH.ac3 C:\Windows\System32>set _SOURCEa0_=%_JOB_%a0.ac3 C:\Windows\System32>set _SOURCEa1_=%_JOB_%a1.ac3 C:\Windows\System32>set _DELAYEDa0_=%_JOB_%DELAYEDa0.ac3 C:\Windows\System32>set _DELAYEDa1_=%_JOB_%DELAYEDa1.ac3 C:\Windows\System32>echo ffconcat version 1.0>"%_JOB_%CONCATa0.txt" C:\Windows\System32>echo file '%_DELAY2CH_%'>>"%_JOB_%CONCATa0.txt" C:\Windows\System32>echo file '%_SOURCEa0_%'>>"%_JOB_%CONCATa0.txt" C:\Windows\System32>ffmpeg -y -safe 0 -i "%_JOB_%CONCATa0.txt" "%_DELAYEDa0_%" 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 @ 0000000002632900] Estimating duration from bitrate, this may be inaccurate Input #0, concat, from 'c:\work\MISS PETTIGREW LIVES FOR A DAY [2007]CONCATa0.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:\work\MISS PETTIGREW LIVES FOR A DAY [2007]DELAYEDa0.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 @ 000000000269d080] Estimating duration from bitrate, this may be inaccurate size= 2816KiB time=00:02:02.77 bitrate= 187.9kbits/s speed= 242x elapsed=0:00:00.50 Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho ffconcat version 1.0>"%_JOB_%CONCATa1.txt"' size= 8192KiB time=00:05:54.97 bitrate= 189.1kbits/s speed= 229x elapsed=0:00:01.55 Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho file '%_DELAY6CH_%'>>"%_JOB_%CONCATa1.txt"' size= 13824KiB time=00:10:00.60 bitrate= 188.6kbits/s speed= 231x elapsed=0:00:02.59 Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho file '%_SOURCEa1_%'>>"%_JOB_%CONCATa1.txt"' [out#0/ac3 @ 0000000001ccbcc0] video:0KiB audio:129039KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000000% size= 129039KiB time=01:31:45.65 bitrate= 192.0kbits/s speed= 227x elapsed=0:00:24.22
On 26/07/2025 19.17, Mark Filipak wrote:
PREFACE: It appears that FFmpeg is slipping into command mode, taking the next couple letters from stdin, and interpreting them. That screws up the remaining script of course.
Note: This is using Gyan's latest git build.
Workaround: Use 'start ffmpeg' instead of 'ffmpeg'. That causes the two invocations to run in separate terminal sessions (but note that they then run concurrently instead of sequentially).
I will not submit this as a bug until it's been replicated.
I'm told I need to be more explicit... Q: Is there anyone who would like to replicate this issue and then reply to the list so I can submit it to the bug list (that has entries that are two decades old)? Thank you for your attention. --Mark.
On 27-07-2025 01:36, Mark Filipak wrote:
On 26/07/2025 19.17, Mark Filipak wrote:
PREFACE: It appears that FFmpeg is slipping into command mode, taking the next couple letters from stdin, and interpreting them. That screws up the remaining script of course.
Note: This is using Gyan's latest git build.
Workaround: Use 'start ffmpeg' instead of 'ffmpeg'. That causes the two invocations to run in separate terminal sessions (but note that they then run concurrently instead of sequentially).
I will not submit this as a bug until it's been replicated. I'm told I need to be more explicit...
Q: Is there anyone who would like to replicate this issue and then reply to the list so I can submit it to the bug list (that has entries that are two decades old)?
Thank you for your attention.
--Mark.
Cannot replicate as I do not have Windows anymore, but... From my own experience when I used batch scripting in Windows (and when using Windows in general). File creation (from stdin) is slow on Windows and my guess is this, when creating a file from stdin and invoking a command directly after this creation, that relies on the crated file you might need to pause until the file has been created. Otherwise the stdin might also be used by the started command in the same session. Using start needs Windows to create a new session for the job and this gives time for the file creation to complete and stdin is not in the same session as the invoked program Should you want to run ffmpeg sequentially use start /wait
Hello Mark, On 2025-07-27T01:17:51+0200, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
PREFACE: It appears that FFmpeg is slipping into command mode, taking the next couple letters from stdin, and interpreting them. That screws up the remaining script of course. You do realize this is totally off-topic for this mailinglist? But fine, I'll bite.
set JOB=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] set DELAY2CH=%JOB%DELAY2CH.ac3 set DELAY6CH=%JOB%DELAY6CH.ac3 set SOURCEa0_=%_JOB%a0.ac3 set SOURCEa1_=%_JOB%a1.ac3 set DELAYEDa0_=%_JOB%DELAYEDa0.ac3 set DELAYEDa1_=%_JOB%DELAYEDa1.ac3 echo ffconcat version 1.0>"%JOB%CONCATa0.txt" echo file '%DELAY2CH%'>>"%JOB%CONCATa0.txt" echo file '%SOURCEa0_%'>>"%_JOB%CONCATa0.txt" ffmpeg -y -safe 0 -i "%JOB%CONCATa0.txt" "%_DELAYEDa0_%" echo ffconcat version 1.0>"%JOB%CONCATa1.txt" echo file '%DELAY6CH%'>>"%JOB%CONCATa1.txt" echo file '%SOURCEa1_%'>>"%_JOB%CONCATa1.txt" ffmpeg -y -safe 0 -i "%JOB%CONCATa1.txt" "%_DELAYEDa1_%" %_JOB% doesn't exist. %_DELAYEDa0_% doesn't exist. %_DELAYEDa1_% doesn't exist.
I would recommend quoting your variables when spaces are involved. The following works for me: SET "JOB=D:\work\MISS PETTIGREW LIVES FOR A DAY [2007]" SET "DELAY2CH=%JOB%DELAY2CH.ac3" SET "DELAY6CH=%JOB%DELAY6CH.ac3" SET "SOURCEa0=%JOB%a0.ac3" SET "SOURCEa1=%JOB%a1.ac3" SET "DELAYEDa0=%JOB%DELAYEDa0.ac3" SET "DELAYEDa1=%JOB%DELAYEDa1.ac3" echo ffconcat version 1.0>"%JOB%CONCATa0.txt" echo file '%DELAY2CH%'>>"%JOB%CONCATa0.txt" echo file '%SOURCEa0%'>>"%JOB%CONCATa0.txt" ffmpeg -y -safe 0 -i "%JOB%CONCATa0.txt" "%DELAYEDa0%" echo ffconcat version 1.0>"%JOB%CONCATa1.txt" echo file '%DELAY6CH%'>>"%JOB%CONCATa1.txt" echo file '%SOURCEa1%'>>"%JOB%CONCATa1.txt" ffmpeg -y -safe 0 -i "%JOB%CONCATa1.txt" "%DELAYEDa1%" But why so many unneccesary variables? Also the creation of the ffconcat-file can be done more efficiently. How about: SET "JOB=D:\work\MISS PETTIGREW LIVES FOR A DAY [2007]" (FOR %%A IN ("%JOB%DELAY2CH.ac3" "%JOB%a0.ac3") DO @ECHO file '%%~A') > "%JOB%CONCATa0.txt" ffmpeg -y -safe 0 -f concat -i "%JOB%CONCATa0.txt" "%JOB%DELAYEDa0.ac3" (FOR %%A IN ("%JOB%DELAY6CH.ac3","%JOB%a1.ac3") DO @ECHO file '%%~A') > "%JOB%CONCATa1.txt" ffmpeg -y -safe 0 -f concat -i "%JOB%CONCATa1.txt" "%JOB%DELAYEDa1.ac3" -- Reino
On 27/07/2025 07.00, Reino Wijnsma via ffmpeg-user wrote:
Hello Mark,
On 2025-07-27T01:17:51+0200, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
PREFACE: It appears that FFmpeg is slipping into command mode, taking the next couple letters from stdin, and interpreting them. That screws up the remaining script of course. You do realize this is totally off-topic for this mailinglist? But fine, I'll bite.
The point is this: While ffmpeg -y -safe 0 -i "%JOB%CONCATa0.txt" "%_DELAYEDa0_%" executes, it's apparently slipping into command mode and taking in the next line echo ffconcat version 1.0>"%JOB%CONCATa1.txt" and complaining Enter command: <target>|all <time>|-1 <command>[ <argument>] Parse error, at least 3 arguments were expected, only 1 given in string 'ho ffconcat version 1.0>"%_JOB_%CONCATa1.txt"' That seems a little odd to me. --Mark.
Hi, Reino, this is off-list. set _JOB_=c:\work\MISS PETTIGREW LIVES FOR A DAY [2007] set _DELAY2CH_=%_JOB_%DELAY2CH.ac3 set _DELAY6CH_=%_JOB_%DELAY6CH.ac3 set _SOURCEa0_=%_JOB_%a0.ac3 set _SOURCEa1_=%_JOB_%a1.ac3 set _DELAYEDa0_=%_JOB_%DELAYEDa0.ac3 set _DELAYEDa1_=%_JOB_%DELAYEDa1.ac3 echo ffconcat version 1.0>"%_JOB_%CONCATa0.txt" echo file '%_DELAY2CH_%'>>"%_JOB_%CONCATa0.txt" echo file '%_SOURCEa0_%'>>"%_JOB_%CONCATa0.txt" start ffmpeg -y -safe 0 -i "%_JOB_%CONCATa0.txt" "%_DELAYEDa0_%" echo ffconcat version 1.0>"%_JOB_%CONCATa1.txt" echo file '%_DELAY6CH_%'>>"%_JOB_%CONCATa1.txt" echo file '%_SOURCEa1_%'>>"%_JOB_%CONCATa1.txt" start ffmpeg -y -safe 0 -i "%_JOB_%CONCATa1.txt" "%_DELAYEDa1_%" On 27/07/2025 07.00, Reino Wijnsma via ffmpeg-user wrote:
Hello Mark,
I would recommend quoting your variables when spaces are involved. The following works for me:
SET "JOB=D:\work\MISS PETTIGREW LIVES FOR A DAY [2007]"
I think you mean this: SET JOB="D:\work\MISS PETTIGREW LIVES FOR A DAY [2007]" The quotes are not needed, and their presence creates problems later. The quotes are only needed at the end, in the FFmpeg command.
But why so many unneccesary variables?...
The variable names document what the step does (e.g. _DELAY2CH_) or what the file is (e.g. _SOURCEa0_, _DELAYEDa0_). The goal is to keep the FFmpeg command line from wrapping, in email for example. ffmpeg -y -safe 0 -i "%_JOB_%CONCATa0.txt" "%_DELAYEDa0_%" And the reason I put tokens in all-caps and with leading and trailing underscores is so that they stand out (e.g. %_JOB_%).
... Also the creation of the ffconcat-file can be done more efficiently...
Efficiency often matters, but not in this case. It's readability that matters here. Thanks for your thoughts. I appreciate your passion to help!--Mark.
On 27/07/2025 10.53, Rob Hallam wrote:
On Sun, 27 Jul 2025, 15:21 Mark Filipak, <markfilipak.imdb@gmail.com> wrote:
Hi, Reino, this is off-list.
This off list reply came to the list FYI
Yes, I see. Well, TBird sometimes does surprising things, eh? It did not indicate that it was going to send to ffmpeg-user, but it did. I think TBird has undocumented behavior regarding message IDs and message threading. However, that's different from what happened between us. What happened between us was that you 'CC'ed me and I replied to your 'CC'. With your 'CC', you took any further discussion between us, off-list. When I replied to your 'CC', it was off-list (according to its recipient ("To") header, which should also be visible in your email client). You then sent my reply to your 'CC' to the list. I guess you thought you were being helpful. The problem originated with your 'CC' -- it's essentially an invitation to continue via a private discussion between you and the person you 'CC'. 'CC' is not necessary when you're responding to a mailing list because the person that you want to see your reply will see it on the mailing list. I hope that's clear. Peace. Regards--Mark.
On Sun, Jul 27, 2025 at 8:34 AM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
executes, it's apparently slipping into command mode and taking in the next line
echo ffconcat version 1.0>"%JOB%CONCATa1.txt"
So prefixing the ">" with a number actually changes the redirection behavior to indicate the specific filenumber to redirect (e.g. "2> blah" redirects stderr). Try the following: echo "ffconcat version 1.0" >"%JOB%CONCATa1.txt" and see if starts working for you. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
On 28/07/2025 11.39, Devin Heitmueller wrote:
On Sun, Jul 27, 2025 at 8:34 AM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
executes, it's apparently slipping into command mode and taking in the next line
echo ffconcat version 1.0>"%JOB%CONCATa1.txt"
So prefixing the ">" with a number actually changes the redirection behavior to indicate the specific filenumber to redirect (e.g. "2> blah" redirects stderr).
Try the following:
echo "ffconcat version 1.0" >"%JOB%CONCATa1.txt"
and see if starts working for you.
Devin
Hi Devin, Substituting ' >' for '>' had no effect. 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' FFmpeg is clearly entering a command mode even though I'm not submitting any options that support command mode. --Mark.
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'
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
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 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
On 28/07/2025 17.52, Jim DeLaHunt wrote:
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.
Thank you, Jim. Yes, I understand now. FFmpeg is not waiting for a specific command. It accepts _all_ stdin, no matter whether an option that expects commands is employed, or in fact whether there's any options at all, and it silently disposes of stdin that is not a command, and apparently continues to do so until stdin is empty. Oh, that's just *ducky*. I was vaguely aware of FFmpeg commands but had no idea that they are so global and 'thoughtless', 'unthinking'. Wonderful! ;-( What I have learned: To forevermore submit "start ffmpeg" instead of "ffmpeg". Thanks again!--Mark. PS: I don't believe it is Windows that is misbehaving. Not at all.
On 29-07-2025 01:40, Mark Filipak wrote:
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. Thank you, Jim. Yes, I understand now. FFmpeg is not waiting for a specific command. It accepts _all_ stdin, no matter whether an option
On 28/07/2025 17.52, Jim DeLaHunt wrote: that expects commands is employed, or in fact whether there's any options at all, and it silently disposes of stdin that is not a command, and apparently continues to do so until stdin is empty. Oh, that's just *ducky*.
I was vaguely aware of FFmpeg commands but had no idea that they are so global and 'thoughtless', 'unthinking'. Wonderful! ;-(
What I have learned: To forevermore submit "start ffmpeg" instead of "ffmpeg".
Thanks again!--Mark.
PS: I don't believe it is Windows that is misbehaving. Not at all.
Both FFmpeg and the Windows Command prompt are behaving as designed. Both also offer ways to circumvent their intended behavior.
participants (6)
-
Devin Heitmueller -
Ferdi Scholten -
Jim DeLaHunt -
Mark Filipak -
Reino Wijnsma -
Rob Hallam