FFAStrans forum

I then ran tests outside of FFAStrans and finally discovered something that significantly improved performance: -hwaccel decoding.
It increased speed from around 1.5x to about 8x.


Yep, hardware decoding will always be faster than relying on pure software decoding from libav as it's gonna use ...

I know that you wanted to use the Web Interface to do that, but this could also technically be done via a watchfolder and I actually created something similar in the past, so I've just re-adapted one of our workflows for this.

Screenshot 2026-06-21 170618.png

Audio Interleave 6 Mono to 5.1 MMA ...

To add to this, even if by some magic we were to rewrite the entire program, there would still be the problem of the frameserver, namely Avisynth. Although the core itself runs and it's cross platform after all the efforts made by the community to bring together the various forks like AVXSynth etc ...

it means the author really cares about his product.


He really does. If there's something I learned after all these years is that Grandmaster Steinar goes above and beyond to make every release as good and bug free as possible. To be perfectly transparent, I've been running version 1.4.2.19 ...

emcodem wrote: Mon Feb 23, 2026 12:34 pm we switched everything to omneon.

*me, reading with a very happy and proud face* :')

Yep, I would definitely suggest setting it to "No Decode" so that the indexer is invoked without any lossless caching.
About indexing, you know my stance on it, better safe than sorry hahahahahahahahahahahaha
You trust suppliers, I don't XD

Jokes aside, I know you know it but I'll write it down ...

sure, but it would still not protect you from dynamically changing frame properties without specifying -reinit_filter 0 which is what is likely at stake here. The reason why I say this is that even when adding an A/V decoder, it will still index the source and deliver the same pixel format as the ...

Yeah, in general it's always nice to have the indexing in front as it means that the encoder downstream gets an uncompressed A/V stream directly from the frameserver (Avisynth) which takes care of several things including tackling problems within the container of the source or dynamically changing ...

The loudness correction performed within FFAStrans is - by default - performed in two passes: the first one measures and the second one applies the correction. Although performing this conversion in two passes is better (a bit like when you encode a video in two passes with the first one analyzing ...

I'm glad to hear that.
Avisynth saves the day once again