FFAStrans under WINE works

[emcodem]

Getting ffastrans running in WINE was something we tried in the past but failed and not investigated further because none of the team members really needed it.
Fortunately, Agents have a much easier time to engineer around such stuff and mine got it running in a few minutes finally.
I'll probably follow up with some experiences how it works after final deployment as container on AWS but until then:

Here are the Instructions my agent came up with:

0. ffastrans config
- it is adviseable to write a ready configured ffastrans config json to Processors/db/configs/ffastrans.json - note that local_processing must be on, otherwise no processing will happen

1. Environment
- Rocky Linux 9 was tried and abandoned (EPEL Wine needs mesa-libOSMesa, which no longer exists there).
- Installed a dedicated Ubuntu 24.04 WSL2 distro instead (wsl --install -d Ubuntu-24.04 --no-launch) — WineHQ's best-supported platform.

2. Install Wine from WineHQ's own repo (not Ubuntu's)
- Add i386 arch, add WineHQ's key/sources, apt install winehq-stable.
- Must downgrade to Wine 10.0 — Wine 11.0 has a real regression (RtlVirtualUnwind2) that crashes these AutoIt-compiled PE binaries on their very first instructions.

3. Extract FFAStrans fresh in WSL from the same GitHub source the Dockerfile uses, and pre-seed the same config JSON files bootstrap.ps1 normally writes (ffastrans.json, host config with local_processing/web_enable true).

4. Per-run environment variables (critical, not optional):
export WINEARCH=win64
export WINEPREFIX=/root/.wine64-<unique-name> # unique per attempt
export WINEDLLOVERRIDES="mscoree=d;mshtml=d" # disables Mono/Gecko auto-installer
- The Mono/Gecko auto-installer is disabled because it silently fails and eats the whole test window before the real binary even starts.
- The prefix path must be unique per attempt (reusing one right after rm -rf races the previous wineserver shutting down and corrupts it).

5. Just run it directly — no services.exe/RPCSS workaround needed (that was a red herring from wineserver contention, not a real COM blocker):
wine rest_service.exe -noman

[emcodem]

First result using ffastrans on WINE in a Container on AWS (Fargate, ECS).
Input File: 5 Minutes XDCAMHD, Encode config: XDCAMHD 1920x1080, 8 Audios

First Column is the cores i gave the Container.

┌──────┬──────────────────────────┬─────────┐
│ vCPU
│ 1 │ Failed — hit the 300sec timeout │
│ 2 │ Success │ 160.2s │
│ 4 │ Success │ 160.2s │
│ 8 │ Success │ 115.1s │
│ 16 │ Success │ 105.1s │

This confirms the WINE config works and the speed is ok.
Note these times involve the whole ffastrans job, e.g. analyze/verify steps and encoding.

Setup was read from and write to S3 directly, e.g. presigned URL as source and ffmpeg writes to Pipe output where the aws cmd tool receives the bytes and writes them directly back to S3 again. E.g. no local file copy involved which makes mediainfo and other stuff a little slower compared to working with Block storage.

Dockerfile attached, note that it adds some additional non ffastrans stuff that i need for my worklfow (e.g. python porable, aws tool and a py script)