FFAStrans forum

Hi, Steinar!

Did you consider Docker as the way to go cross platform?
Windows docker containers have the limitation - they don't have GUI, since use Windows 2016 Core edition, but every other things are there.

So the idea is following - separate workflow processing engine from GUI. All we need is CLI-only FFASTrans workflow processor (something that starts exe_manager.exe?). We'll be able to start GUI outside of Docker container to configure FFASTrans farm.

Dockerizing seems to be well fit with the architecture of FFASTrans.

Regards, Alex

Hi Alexander,

I've had this question before and it's absolutely something to consider. But it has not been a focus yet. There is so much work with FFAStrans that I have to choose my battles.

The FFAStrans GUI has already been detached from the actual running of the processors. If you run it as a service you don't need the gui at all. Also, the FFAStrans GUI is doing exactly what you suggest, just runs the exe_manager. You can easily trigger it yourself without using the service OR the GUI.

-steinar

It's a good news. I'll try to make a windows docker image with exe_manager.

Great, let me know how it goes!

-steinar

I know it's been a while but, did you have any luck with Docker @kibi ? I'm exploring the possibility to run the transcoding part on a rented VM.

Hmmm there are multiple things speaking against using ffastrans in a docker container... one of them is that it is a native windows application and you would need to run it through wine and (as ffastrans GUI does not work 100% in wine) you would need to install samba server and create an share where you place the installation files in order to open the ffastrans userinterface from a windows client which has access to the samba share from the docker machine.

But besides all of that, docker is designed to share resources of one machine for multiple applications, just like an ESX host. But transcoding typically requires all available resources of the machine you run it on (or much more). As we do not need to "install" ffastrans, deployment can also not be simplified by using docker.
So what would be the win of a docker image with ffastrans?
Running the transcoding on "Rented VMs" (Cloud) always involves the problem how to make the media files available. We could theoretically read from http share but in offline transcoding we must write to either a NAS or local drive - as NAS is typically not available for cloud servers, the rented server would need to have a pretty big local drive which makes it pretty expensive. You would need to "design" your own cloud transcoding solution which typically takes a pretty long time until it set up correctly and works as designed. A better alternative might be to use some existing cloud transcoding solution like amazon or zencoder - this removes the need to design a cloud transcoding solution on your own.

Transcoding in the cloud only makes sense if either the source or destination file/stream is located in the cloud.

Thank you for your detailed answer. I was able to create a VM on a QNAP with FFASTrans to process simple tasks for editors at there home without our intervention.

It's pretty useful to standardize the format of our "archives" we add in Avid MC. Conform, deinterlace, upscale...

Besides, FFASTrans heavily relies on Avisynth for many things and, as frameserver, it has been supporting Linux and OSX for a very short time (the work began recently when AVXSynth was merged in Avisynth+). Although this may give hope to some people, it really shouldn't be considered as usable on other OS 'cause it's just the core that is working, as all plugins would have to be re-written and re-compiled and it would take forever. In other words, as of now, even if you port FFASTrans to Linux/OSX, it would still have the huge problem of Avisynth not fully supporting other OS except for the core.

As a side note: there are actually years of development behind Avisynth and this resulted in making it the beloved frameserver we all rely on nowadays, but it also introduced some challenges, for instance, even on Windows there are some things one has to take into account. For instance, plugins compiled with GCC won't work with the frameserver if it has been compiled with MSVC, while those compiled with ICC from Intel Parallel Studio are compatible with the ones compiled by MSVC.

As to encoding on a Windows VM, sure, it can be done, it's just that you're not gonna use your hardware at 100%, but still, I would say that it's better than nothing...