ffmpeg installation doesn't include 'prores_ks'

[ben-richardson]

When trying to encode using prores_ks as the output codec under ffmpeg installed via scoop, it returns:

Unable to find a suitable output format for 'prores_ks'
prores_ks: Invalid argument

Manually installing and using the static binary of ffmpeg 3.4.1 from their main site works as expected with ffmpeg_ks.

Any thoughts as to why prores_ks is unsupported in scoop's install of ffmpeg?

Full command in use was:

ffmpeg -start_number 1001 -f image2 -r 23.98 -i inFile.%04d.dpx -codec:v prores_ks -profile:v 4444 -pix_fmt yuva444p10le -r 23.976 outFile_WinKeepAlpha.mov

[ben-richardson]

Further checking reveals scoop is using ffmpeg version N-90021-g4961ddfd35 Copyright (c) 2000-2018 vs Zeranoe's static build of ffmpeg version 3.4.1 Copyright (c) 2000-2017.

It was suggested that scoop's auto update servers may have pulled a version that's too new, although it doesn't appear to be a nightly version.

[r15ch13]

Did you try updating ffmpeg the current version 20180213-474194a?

scoop uses the nightly build versions from Zeranoe as default. Should we switch it to the stable build?

[ben-richardson]

I updated using scoop to the latest ffmpeg you mention. The same issue persists.

I would suggest yes, switching to the stable build of ffmpeg might be best for most users.

[r15ch13]

Done 👍

[ben-richardson]

Awesome, thanks.

Unfortunately, it didn't seem to fix my initial issue. Unless I'm misunderstanding something about scoop's operation.

I uninstalled ffmpeg with scoop, cleaned the cache, and reinstalled ffmpeg. The version now shows as 3.4.1.

But running my same command invoking -codec:v prores_ks gives the same error, [NULL @ 000001fcacd62fe0] Unable to find a suitable output format for 'prores_ks' prores_ks: Invalid argument

Running the identical command on the binary of ffmpeg downloaded directly from Zeranoe works as expected.

Is there anything else about the scoop installation that I am missing or misunderstanding?

[rasa]

Perhaps calling it via the shim is causing your issue. Try running the exe directly, via:

"%userprofile%\scoop\apps\ffmpeg\current\bin\ffmpeg.exe" ...

[ben-richardson]

@rasa Calling it directly worked. But obviously the shims are a big part of the usability of scoop.

(I am fairly familiar with command line tools on macOS, but only just setting up a Windows machine for the first time in a long while).

Is there anything that can be done to allow the shim to call with the same results as that direct command?

[r15ch13]

Can you provide some test data, so I can try to reproduce it? Would like to check if the shim.exe is the problem here.

[ben-richardson]

5x DPX frames and the expected ProRes result uploaded here: https://benrichardson.s3.amazonaws.com/dl/test.zip

[r15ch13]

It works from cmd but not with powershell.
Found something:
$args and @args seem to split at a colon, resulting in -codec: v prores_ks -profile: v 4444

[ben-richardson]

Sadly outside my realm of understanding…! Only a user, I'm afraid.

But glad it sounds like you found something. Does it seem resolvable?

[r15ch13]

Currently, I don't have any clue how to fix that. 😕
The easiest way would be to delete the ffmpeg.ps1 shim. The shim exe works fine.

[stkb]

I am taking a look at shims and args - see #2025.

[nkm8]

I just wanted confirm that this issue still exists and is related to the -c:v <library> command-line syntax that is supposed to be supported by ffmpeg.

Using -c:v libx264 with -loglevel debug results in:

Reading option '-c:' ... matched as option 'c' (codec name) with argument 'v'.
Reading option 'libx264' ... matched as output url.

Using the same switches by calling ffmpeg.exe directly works as expected.