Skip to main content
FFmpeg batch processing fits a Springwinter Worker when a continuously running consumer pulls media jobs from a durable queue. Put source files and outputs in S3 rather than the container filesystem. Updated October 9, 2026. Use S3 for durable media, a queue for job ownership, and local ephemeral disk only for active processing.
  1. A web API creates a job and returns an ID.
  2. The client uploads source media directly to S3 with a signed URL.
  3. The API publishes a message containing S3 keys and an operation profile.
  4. A Springwinter Worker downloads the input to temporary storage.
  5. The Worker invokes FFmpeg with a fixed allowlisted profile.
  6. The Worker uploads outputs and metadata to S3.
  7. Job state changes to complete only after durable upload succeeds.
Do not accept arbitrary shell fragments from users. Represent operations as validated fields and construct the FFmpeg argument array without a shell.

​
Build the image

Pin both the base image and FFmpeg version. Include only codecs whose licensing and redistribution terms fit your product.

​
Deploy on Springwinter

Create a Worker, choose enough CPU and memory for one measured transcode, and set queue, bucket, temporary directory, concurrency, and timeout variables. Start with concurrency one. FFmpeg can consume every available CPU core, so process-level parallelism must be deliberate.

​
Design for interruption

Long media jobs should be resumable. Segment large inputs, upload completed chunks, and make each chunk idempotent. Extend the queue visibility timeout while work progresses. On shutdown, stop receiving jobs and either finish within the deadline or leave the message unacknowledged for retry.

​
Know the current limits

Springwinter Workers are continuously running ECS services, not one-off AWS Batch jobs. Current standard Fargate resources do not expose GPU or VT1 acceleration. For bursty queues, specialized hardware, or scale-to-zero economics, AWS Batch or a dedicated ECS capacity design may fit better.

​
Observe quality and cost

Record input duration, output duration, bytes, codec, resolution, frames per second, wall time, CPU time, peak memory, retries, and output validation. Cost per media minute is more useful than container cost alone.

​
Frequently asked questions

Downloading to local ephemeral storage is usually easier to retry and measure. Streaming can reduce temporary storage but makes seeking, retries, and partial failure behavior more complex.
Yes, but only after measurement. Multiple transcodes compete for CPU, memory, disk throughput, and network. Begin with one job per container and increase concurrency carefully.
Use Batch when jobs are highly bursty, should scale to zero, require per-job sizing, need Spot fleets, or need specialized EC2 accelerators not available to the Springwinter Worker.

​
Sources and further reading

Last modified on October 8, 2026