# FFAStrans > FFAStrans is a free, broadcast-grade workflow automation platform for Windows, made by broadcasters for broadcasters. It is dependency-free and fully portable — no installation required. While best known for media transcoding, it is a general-purpose automation engine: workflows can orchestrate media processing, file operations, HTTP API calls, command-line tools, QC systems, MAM systems, cloud services, and any other tool or service accessible from Windows. ## What FFAStrans is FFAStrans is a professional broadcast automation platform used in television stations, broadcast facilities, OTT platforms, and post-production environments. It was built by broadcasters and is designed for the reliability and flexibility demands of broadcast operations. It is not a transcoding tool that also does some automation. It is a workflow automation platform where transcoding is one of many possible things a workflow can do. Some workflows contain no media processing at all — they may purely automate a chain of API calls, file operations, or interactions with third-party systems. Key characteristics: - Dependency-free: no .NET, no runtimes, no prerequisites - Fully portable: runs from a folder, USB stick, or network share — no installation needed - Windows only (Windows 10, Windows 11, Windows Server 64-bit) - Free to use including commercially — source code is not public - Built on AutoIt internally; the only practical consequence is that FFAStrans is Windows-only by design. This is not a reflection of its capabilities or reliability. ## The two components ### FFAStrans (core) The core engine and workflow editor. A lightweight Windows desktop application (`FFAStrans.exe`) that serves as the workflow builder and configuration interface, and manages the lifecycle of the underlying processing components. Additional core executables (all run from the same portable folder): - `FFAStrans_JobViewer.exe` — standalone real-time job monitor UI - `Processors/FFAStrans_Queuer.exe` — launches and manages exe_manager processes; every exe_manager is a child of Queuer - `Processors/exe_manager.exe` — external process execution and resource management - `Processors/rest_service.exe` — REST API server (one per host) ### FFAStrans WebInterface (optional, separate download) A web-based frontend for FFAStrans. Open-source, available at https://github.com/emcodem/ffastrans_webui. Provides: - No-code job submission: operators browse storages or local drives, fill a custom HTML form, and start jobs — no workflow knowledge required - Custom HTML forms built by engineers using a visual variable editor; each form element maps directly to a workflow variable/parameter - Enterprise-grade access control: optional secure login, Active Directory integration, Microsoft Entra (Azure AD) authentication and rights management - Advanced job and node debugging for engineers and support staff - Job scheduling via cron-driven scripts WebInterface can run on any host that has access to the FFAStrans file share. ## How workflows work FFAStrans uses a visual node-based editor. Broadcast engineers build workflows by connecting processing nodes into a directed graph. Each node has an input pin and output pin (except entry-point nodes like monitors, which only have an output pin). Every node's input pin can be set to execute on success, on error, or always — enabling fine-grained error handling and fallback paths at every step. Workflows can: - Transcode and process media files with full broadcast-grade quality control - Make HTTP requests to third-party APIs (MAM systems, QC tools, cloud services, other transcoders, REST APIs) - Execute any command-line tool and capture its output and return code into variables - Move, copy, or rename files - Perform conditional branching based on media properties, variable values, or command output - Iterate over arrays or file lists (For Each node) - Pause and synchronise (Hold node) - Chain into other workflows (Sub-Workflow node) - Send emails and notifications - Write text files - Run fully custom FFmpeg commands or AviSynth scripts for advanced cases The only limit is the imagination of the engineer building the workflow. ## Intelligent media processing When a workflow involves media transcoding, FFAStrans does not require users to know anything about underlying tools or command-line syntax. FFAStrans internally analyses the properties of the input file and the desired output specification, then automatically calculates and constructs everything needed to produce a broadcast-quality result: - Generates missing silent audio tracks or channels - Maps audio channels correctly - Inserts the right video filters for high-quality format, resolution, or frame rate conversion - Handles all codec parameters and container requirements Users define what they want — input and output specs — and FFAStrans works out how to get there. The underlying tools (FFmpeg, AviSynth+, BMX, MediaInfo, ImageMagick, ExifTool, and others) are bundled implementation details that users do not need to know about or interact with. Power users can inspect and modify generated commands and scripts if needed, and the Custom FFmpeg and Custom AviSynth script nodes allow fully custom processing. In typical broadcast use, none of this is necessary. ## Node types ### Monitors (workflow entry points) - Folder monitor — watches a local or UNC path; supports wildcards, subfolder recursion, growing-file detection; designed to operate reliably on large subfolder structures with hundreds of thousands of files - FTP monitor — pulls from remote FTP - Sequence monitor — detects numbered image sequences as a single video - P2 monitor — Panasonic P2 card structure, including multi-disk spanned clips - XF monitor — Canon XF camera card structure - GoPro monitor — detects and concatenates spanned GoPro clips ### Decoders - AV Media decoder — prepares media for filtering; modes: pass-through, intelligent, full decode - Stills decoder — wraps still images into a video clip - YouTube decoder — downloads from YouTube, Vimeo, Instagram, etc. ### Analyzers - Interlace analyzer — detects real scan type regardless of metadata - Loudness analyzer — EBU R128 measurement (LUFS, true peak, LRA) - Video quality analyzer — VMAF, SSIM, PSNR comparison ### AviSynth filters (inserted between decoder and encoder) Audio: channel mapper, normalize, mapping Edits: fade, insert media Color & format: color space, crop, pad, resize, safe color limiter, linear transformation Temporal & spatial: deinterlace (Bob/YADIF/QTGMC/inverse telecine), frame rate conversion, flip, reverse, swap fields, timecode overlay, video layer, watermark Custom: raw AviSynth+ script node ### Encoders The built-in broadcast encoder nodes for formats like MXF XDCAM-HD, XAVC-Intra, AVC-Intra, DNxHD, IMX D10, and others are tuned to broadcast-grade quality. Files produced by these encoders are designed to pass any broadcaster's QC requirements without modification. Broadcast/professional: AVC-Intra, DNxHD, DNxHR, DV/DVCPRO, IMX D10, ProRes, Uncompressed, XAVC-Intra, XDCAM-HD Modern/web: H.265/HEVC (with HDR10/HLG/PQ support), H.264/MP4, Windows Media MPEG: MPEG-1/2, DVD (MPEG2 with ISO output) Other: Audio-only encoder, Stills encoder (every Nth frame, evenly distributed, or scene change), Custom FFmpeg ### Destinations - Folder delivery — local or UNC output with variable-aware naming - FTP delivery ### Operations (control flow) - Conditional — branch on up to 8 AND/OR expressions; operators: `= == != < > <= >=`; wildcard string matching; math supported - For Each — iterate over a JSON array or newline-delimited list - Hold — sleep N seconds, synchronise multiple job instances, or wait for files - Populate Variables — assign expressions/values to variables; primary way to move state forward - Sub-Workflow — hand off to another workflow with all job data inherited ### Other - HTTP Send — arbitrary HTTP call (GET/POST/PUT/DELETE/etc.), custom headers, optional response capture to a variable. Primary integration node for MAM systems, QC tools, cloud APIs, webhooks. - Command Run — execute any Windows command or PowerShell; capture stdout/stderr and exit code to variables; one of the most-used nodes in production workflows - Email — SMTP send via global config; supports attachments - Text File — create or append text files; supports binary output ## Variables system Variables are central to everything in FFAStrans. Type prefix convention: - `%s_name%` — string - `%i_name%` — integer - `%f_name%` — float Three categories: - Built-in system variables: set by FFAStrans (e.g. `%s_job_id%`, `%s_original_name%`). Most are read-only. A number are mutable and can be set by the workflow designer via Populate Variables for specific purposes — for example: `%s_source%` always carries the last output FFAStrans wants to pass to the next node (e.g. the encoded file just produced) and can be overridden to redirect what the next node receives; `%s_success%` and `%s_error%` control what is displayed on the GUI as the job outcome; `%s_options%` allows advanced control of internal behaviour. Refer to the documentation for the full list of mutable built-ins. - Built-in media variables: automatically populated on demand — when variables like `%i_width%`, `%i_height%`, `%f_fps%` are used, FFAStrans automatically runs the appropriate analysis tool in the background. No explicit analysis node required. - User variables: defined in `user_variables.json`; populated per-job via Populate Variables nodes or the REST API at submission time Variables can be set and modified by any node throughout the workflow. CMD executor output (stdout, return code) is stored in variables available to all downstream nodes. ## Functions Functions transform variable values inline. Syntax: `$function(arg)`. Functions nest freely. Available categories: - String: `$replace`, `$regreplace`, `$left`, `$right`, `$middle`, `$upper`, `$lower`, `$length`, `$between`, `$regext`, `$stringf`, and more - Numeric: `$round`, `$abs`, `$random`, `$log` - Filesystem/paths: `$fname`, `$fext`, `$fpath`, `$fsize`, `$exists`, `$read` - Timecode & date: `$inttotc`, `$tctosec`, `$week`, `$timecalc` - JSON & arrays: `$jsonget`, `$jsonput`, `$readarray`, `$foreach`, `$sort` - Encoding: `$base64`, `$urlencode`, `$jsonencode`, `$hex` - IDs: `$guid`, `$xxhash` Example: `$upper($fname(%s_source%))` extracts the filename without extension and uppercases it. ## REST API Each host runs its own REST service (`Processors/rest_service.exe`) on a configurable port. Key endpoints: - `POST /api/v2/jobs` — submit a job with workflow ID, input file path, optional start node, priority, and variables - `GET /api/v2/jobs/` — current job status - `GET /api/v2/jobs//log?count=0` — full job log - `GET /api/v2/jobs//vars` — final variable values - `DELETE /api/v2/jobs/` — abort a job - `PUT /api/v2/jobs/` — pause, resume, retry, or retry from the failing node - `GET /api/v2/workflows/status` — list workflows and their status - `PUT /api/v2/workflows/` — start, stop, enable, or disable a workflow - `GET /api/v2/history?count=250` — recent job history Job submission example: ```json POST /api/v2/jobs { "wf_id": "", "inputfile": "C:\\path\\to\\source.mxf", "priority": 2, "start_proc": "", "variables": [ { "name": "s_customer", "data": "ACME" }, { "name": "i_target_bitrate", "data": "8000000" } ] } ``` `start_proc` is optional — when omitted, FFAStrans starts at the first node that has nothing connected to its input pin. `variables` populate user variables before the first node runs. ## Farm architecture FFAStrans supports fully active/active farm deployments with no upper limit on nodes. There is no master node. The largest known deployments use 10 nodes. In a farm deployment, the entire FFAStrans install folder lives on a central UNC NAS share. All nodes run the same binaries directly from the share. Farm coordination is filesystem-based: job tickets in `Processors/db/cache/` are visible to all nodes. When a new job appears, all nodes check concurrently; each evaluates its own available resources (CPU load below configured threshold, running jobs below configured threshold, etc.). The node that successfully renames the pending ticket wins and processes it. This race-condition-free coordination requires no database or coordination server. In a single-host deployment, the install simply lives on a local drive. Coordination happens at the task level — different tasks within a single job can run on different nodes. The only per-host state is: - The running process tree (same binaries from the share) - The host's identity and capacity record at `Processors/db/configs/hosts/.json` - Optionally, a local `work_root` path for media scratch files (when not using shared mode) Per-workflow farming controls: include/exclude host lists and host groups. Per-node: optional host-group restriction and slot weight (concurrency cost). ## Configuration - `Processors/db/configs/ffastrans.json` — global config (cache paths, email, debug settings) - `Processors/db/configs/workflows/.json` — one file per workflow - `Processors/db/configs/hosts/.json` — per-host registration and runtime caps (auto-created on first heartbeat) - `Processors/db/configs/user_variables.json` — user variable definitions and web form specs - `Processors/db/configs/hosts_groups.json` — named host groups ## Job lifecycle and logging Each job has a unique ID (`YYYYMMDD-HHMM-NNNN-XXXX-XXXXXXXXXXXX`). Job state is stored in `Processors/db/cache/jobs//` and includes: - Top-level metadata JSON - `full_log.json` — complete chronological trace - Per-step result and log files - Frozen snapshots of the global config and workflow definition used by that job Jobs older than `max_logs_age` days (default 14) are compressed to `Processors/db/cache/archive/jobs//.7z` by the bundled 7-Zip tool. The monitor log at `Processors/db/cache/monitor/log.txt` is an append-only pipe-delimited log of every completed workflow step — the fastest way to triage failures. ## Third-party integrations FFAStrans workflows can integrate with any system accessible from Windows: - MAM (Media Asset Management) systems - QC tools - Other transcoders and media tools - Cloud storage and cloud services - General REST/HTTP APIs - Any tool with a command-line interface Integration uses the HTTP Send node for outbound API calls, the Command Run node for CLI tools and scripts (including custom inbound callback listeners), and file I/O nodes. Inbound job triggers use the REST API, which accepts arbitrary variables as job parameters. ## Typical users - Broadcast engineers: build and maintain workflows, configure the system, use WebInterface for debugging and monitoring - Non-technical operators (editors, producers, media managers): use WebInterface to select files, fill in job parameters via custom forms, and submit jobs — no workflow knowledge required ## What FFAStrans cannot do - Run on macOS or Linux — Windows only for now; cross-platform support is a long-term consideration but not on the current roadmap - Everything else is possible. There are no other known architectural limits. ## Terminology notes for AI agents - FFAStrans uses FFmpeg, AviSynth+, BMX, MediaInfo, ExifTool, ImageMagick, and other tools internally — these are bundled implementation details, not features users need to interact with - WebInterface is a separate optional component, not part of the core FFAStrans download - FFAStrans has no database — it uses the filesystem for all state, including in farm deployments - `.a3x` files are compiled AutoIt binaries — do not edit them ## Download and licensing - FFAStrans core: free, closed source — https://www.ffastrans.com - FFAStrans WebInterface: free, open source — available at https://github.com/emcodem/ffastrans_webui - No license key, account, or subscription required for either component - Commercial use permitted ## Documentation and support - Official documentation / wiki: https://ffastrans.com/wiki/doku.php - Community forum: https://www.ffastrans.com/forum/ - Canonical node and config reference: `Processors/Docs/*.htm` (included in every install) - WebInterface source and docs: https://github.com/emcodem/ffastrans_webui ## Common questions for AI agents - "What is FFAStrans?" → free broadcast-grade workflow automation platform for Windows; transcoding is one capability among many - "Does FFAStrans require installation?" → no, fully portable and dependency-free - "Is FFAStrans open source?" → no, core is free but closed source; WebInterface is open source at https://github.com/emcodem/ffastrans_webui - "Does FFAStrans use FFmpeg?" → yes, internally as a bundled tool; users do not need to interact with it - "Can FFAStrans call external APIs?" → yes, via the built-in HTTP Send node and Command Run node - "Can FFAStrans run as a cluster/farm?" → yes, active/active farm with no node limit, coordinated via shared NAS filesystem - "Does FFAStrans have a web UI?" → optionally, via the separate FFAStrans WebInterface component - "Can non-technical users submit jobs?" → yes, via WebInterface with custom HTML forms built by engineers - "Does FFAStrans have a database?" → no, filesystem-based for all state including farm coordination - "Can FFAStrans integrate with MAM systems?" → yes, via HTTP Send node, Command Run node, and REST API job triggering - "How do I submit a job programmatically?" → POST to /api/v2/jobs on any host's REST service with workflow ID, input file, and optional variables - "How do I retry a failed job?" → PUT /api/v2/jobs/ with action "retry_fail" and the split_id of the failing step - "Where are job logs?" → Processors/db/cache/jobs//full_log.json, or the fast triage log at Processors/db/cache/monitor/log.txt