FFAStrans forum

Hello,

I've been getting rather absorbed in this awesome program you've built here, and really appreciate the work y'all have put in. Honestly, fantastic stuff; if anything I just wanted to say that much.

That said, a recent workflow I've been testing has raised the question: is it possible to manually update the internal ffmpeg in FFAStrans, or would that cause problems? I ask because I have apparently come across a bug with the DXV encoder in the version of ffmpeg that FFAStrans uses that is not in the current version of ffmpeg. I'm also not particularly sophisticated enough to tell which exact file this encoder lives in, if simply updating that file would suffice.

I have already worked around the issue by using a command proc that calls an external ffmpeg instead of the internal one, but I was curious if I could just overwrite the ffmpeg inside FFAStrans and carry on. I suppose I could just try it on a test bench and see if anything breaks

It's perhaps not pertinent to FFAStrans, but for anyone curious, the bug appears to be that the DXV encoder doesn't properly encode video if the source goes through a scaling filter that isn't upscaling it. VLC simply won't display any video, and Resolume flat-out crashes if it even touches it. Which is fun, if you're using Resolume's REST API to automatically load the delivered video! The issue is fixed, just... not in FFAStrans's ffmpeg

Again, thank you for your work on FFAStrans. I had been writing batch files to manually run ffmpeg before I found this, and I'm glad those days are over.

-Roupine

Hey roupine,

welcome to the forum and thank you for using FFAStrans! Looks like we found another victim hrhrhr
First its a no to everything, updating a single ffmpeg dll would most likely not work and updating the ffmpeg version that we ship will also most likely end up in unforeseen problems in different situations. Especially these days ffmpeg changes to o many groundbraking things too fast.

But question is why you would like to change the stock ffmpeg only for DXV encoding? There is no DXV encoder builtin so you have to do the encoding either in a commandline processor or the custom ffmpeg processor. If you use the custom ffmpeg processor, just switch to the cmd processor. The only difference between them is that custom ffmpeg automatically inserts the path to ffmpeg and the source filename in the commandline but you can easily do that on your own.
Just place your copy in the root of your ffastrans installation e.g. c:\ffastrans\customffmpeg\VERSION\ffmpeg.exe
In your workflow, insert a cmd executor with the following lines:
Also, in the same cmd processor, you want to set checkbox at "set source variable to": This will lead to the cmd processor having the exact same behaviour as the custom ffmpeg one but work with your custom ffmpeg.exe.
If you need avisynth filters its a little different, you'd need to rename your ffmpeg.exe to something like "myffmpeg.exe" and place it in
C:\ffastrans\Processors\ffmpeg\x64

let me know any doubts!

Oh, I see, I see.
Thank you for the reply.

So that's why ffmpeg was erroring out when a still image was dropped in, because I have it go through the Stills decoder first? And if I hadn't taken the A/V Media decoder out while troubleshooting it would've done the same with video.
Interesting. Changing the command to call the copied/renamed 8.0 ffmpeg.exe in the x64 processors, instead of where I originally unpacked it, causes it to handle the output of the decoders/filters without issue and still encode valid video. Very cool.

As long as I'm using the %s_job_work% folder, FFAStrans will still tidy it up like any other job, right? That's mainly why I had hoped to stick with the encoder nodes instead of a command executor.

Well done!

roupine wrote: ↑Fri Oct 24, 2025 9:07 pm So that's why ffmpeg was erroring out when a still image was dropped in, because I have it go through the Stills decoder first? And if I hadn't taken the A/V Media decoder out while troubleshooting it would've done the same with video.

Actually stills is a topic on it's own. It is fine when you do it as of right now because we have avisynth doing all the work on stills. If you would just take the stills monitor and encode directly instead it would be a different beast because in that case we let ffmpeg do the stills using some -i *.jpg syntax or similar. Not sure if that works as intended with your current approach.

The only secret here is that we have the avisynth dll in the same folder as ffmpeg (because ffmpeg looks for avisynth.dll first in same folder). Its one of the secrets to make ffastrans completely portable.
Instead of placing your ffmpeg.exe in our ffmpeg folder, you could also place your own copy of avisynth and ffmpeg into some different folder and place them wherever you like. But after all it dont make a difference if you work with static ffmpeg (the one without dlls).

roupine wrote: ↑Fri Oct 24, 2025 9:07 pm As long as I'm using the %s_job_work% folder, FFAStrans will still tidy it up like any other job, right? That's mainly why I had hoped to stick with the encoder nodes instead of a command executor.

Very true, we just delete everything in the folder, its kind of impossible to keep track of each and every file thats dropped there. Also its a common practice that users create workflows writing random data in the job work so its just normal that we clean everything from there.

On a sidenote, we also have s_options and save_enc_cmd which enables you to retrieve (and modify) the internally generated ffmpeg command from encoders (while NOT executing the actual command). This is what i use if i want all the juicy filters and mappings generated by ffastrans but do little changes on the command before finally executing it myself in a cmd processor. (e.g. change the ffmpeg.exe)
Example where i replace libx264 encoder by h264_nvenc: viewtopic.php?p=9372&hilit=nvenc#p9372