Robin – IMG.LY Blog

A Guide to Batch Video Editing & Server Automation with FFmpeg

Robin — Mon, 10 Nov 2025 10:33:40 GMT

The explosion of video content across platforms from social media and streaming services to e-learning and surveillance has made manual video processing increasingly impractical. As organizations manage thousands of clips, the need for automation has become critical to handle transcoding, resizing, thumbnail generation, and other repetitive tasks efficiently. Manual workflows quickly become bottlenecks, consuming engineering time and introducing inconsistencies that slow down production and distribution.

In this article, you’ll go through a Docker-based batch video processing system powered by FFmpeg, complete with both a REST API and a command-line interface (CLI). This setup enables scalable, reproducible, and automated media operations suitable for local or cloud environments. You can deploy this server on cloud providers – our guides for running FFmpeg on AWS Spot Instances and running FFmpeg on GCP walk you through setup on each platform. By the end, you’ll understand how to design infrastructure that can process hundreds of videos reliably and in parallel. To follow along, you’ll need a basic understanding of Python, Docker, and common video formats such as MP4 and MOV. For a primer on running FFmpeg inside a Docker container, see our Docker guide.

You can clone this github repository and follow the article for a working Docker-based batch video processing system with FFmpeg handling the heavylifting.

Understanding Video Processing Fundamentals

FFmpeg is a powerful command-line toolkit capable of reading, transcoding, filtering, and muxing virtually any media format. It’s the foundation of countless commercial encoders, streaming platforms, and post-production tools. With a single command, you can convert between codecs, trim segments, extract audio, or even apply complex filter graphs and when these commands are chained together in scripts or APIs, they form the backbone of scalable media pipelines. For readers unfamiliar with FFmpeg, our Ultimate Guide to FFmpeg covers the basics and advanced techniques.

At its core, most video workflows revolve around a few recurring operations: transcoding (changing codecs or bitrates), compression (optimizing size for delivery), watermarking (branding or copyright protection), and thumbnail extraction (visual previews for cataloging). Each operation impacts performance differently depending on your hardware setup. CPU-based processing offers flexibility but can be slow for high-resolution workloads, while GPU acceleration through NVENC or VAAPI dramatically speeds up encoding at the cost of hardware dependencies. Managing memory and I/O efficiently is crucial, as reading and writing large video files can quickly become a bottleneck in batch pipelines.

Understanding the file format landscape and the quality–size trade-off is key to producing professional results. Modern codecs like H.264, H.265 (HEVC), and VP9 dominate for their balance of efficiency and compatibility, typically wrapped in container formats like MP4, MOV, or WebM. Tools like FFmpeg expose fine-grained control through parameters such as CRF (Constant Rate Factor), bitrate targeting, and encoding presets, allowing you to tune the ideal compromise between visual fidelity and storage or bandwidth requirements.

The FFmpeg Batch Video Processor builds on these fundamentals to demonstrate how FFmpeg can power fully automated, scalable media workflows. Packaged as a Docker-based, production-ready system, it automates complex operations, such as transcoding, compression, watermarking, and thumbnail generation across multiple videos simultaneously. By combining a FastAPI-powered REST API with a command-line interface (CLI), it provides flexible control over batch processing, progress tracking, and workflow automation. With built-in profiles, concurrent workers, and robust logging, it turns FFmpeg’s raw capabilities into a modern, reproducible video processing pipeline suited for professional production, web delivery, and large-scale content management. For tutorials on cropping and trimming at the client level, see our Flutter guide.

Now lets dig deeper into the project.

Architecture Deep Dive

System Components Overview

The system is modular by design, separating API logic, job management, and media processing into distinct layers for clarity and scalability. Lets look into the different layers of the project now:

**FastAPI REST interface (api.py)**This file defines the FastAPI application for our batch video processing API powered by FFmpeg. It provides endpoints for managing video processing jobs, profiles, workflows, and file uploads. Key components include:The API supports operations like transcoding, compressing, adding watermarks, and more, using profiles and workflows for predefined configurations. With the help of this API, you can create a dashboard to monitor the jobs and manage them too.
1. Global Instances:The VideoProcessor executes FFmpeg-based tasks like transcoding and compression, while the JobQueue manages concurrent job execution through a worker pool. The ConfigManager maintains processing profiles and workflows, ensuring consistent parameters across all jobs.
2. Endpoints:The API provides endpoints for managing jobs, profiles, and workflows, as well as handling uploads and system monitoring. You can create, list, retrieve, cancel, and download jobs; access predefined profiles and workflows; upload videos for processing; check system health and queue stats; and retrieve metadata for uploaded videos.You can go to http://localhost:8000/docs#/ when the docker container is running to see a detailed description of every endpoints.
3. Startup/Shutdown Events:Initializes and cleans up the job queue.
**Job queue management (job_queue.py)**This file implements the job queue system for managing and processing video processing tasks asynchronously. It includes:This system makes batch video processing possible, supporting asynchronous execution and state persistence.
1. Job Class:The class represents a video processing task with attributes such as id, input_file, output_file, operation, parameters, status, progress, timestamps, and error details. It supports operations like thumbnail generation, GIF creation, and audio extraction, automatically generating output file paths. A to_dict method is included for easy serialization of task data.
2. JobQueue Class:The class manages a queue of video processing jobs using a pool of asynchronous workers. It allows adding, retrieving, listing, and canceling jobs, filtering by status, and starting or stopping workers as needed. It also tracks key statistics such as total, completed, and failed jobs and can persist the queue state to a file. Workers process jobs asynchronously, updating progress and handling errors throughout execution.
3. Worker System:This component processes jobs using a processor object that defines the specific operations to perform. It runs these operations within a thread pool to prevent blocking the event loop, while continuously updating job progress and handling both successful completions and failures.
**Video processing engine (video_processor.py)**This file defines a VideoProcessor class that provides a set of methods for video processing using FFmpeg. Key features include:The class uses subprocesses to interact with FFmpeg and supports progress callbacks for real-time updates.
1. Video Metadata Extraction:
  - get_video_info: Extracts video details like duration, size, resolution, codec, and frame rate.
2. Video Operations:
  - transcode: Converts videos to different formats/codecs.
  - compress: Reduces video size with optional scaling or target size.
  - add_watermark: Adds a watermark to a video at specified positions.
  - generate_thumbnail: Creates a thumbnail image from a video.
  - extract_audio: Extracts audio from a video in various formats.
  - create_gif: Converts a video segment into a GIF.
  - concatenate_videos: Merges multiple videos into one.
  - trim_video: Trims a video to a specific duration or time range.
3. FFmpeg Execution:
  - _execute_ffmpeg: Handles FFmpeg command execution with progress tracking and error handling.
**Configuration system (config_manager.py)**This file defines a ConfigManager class that manages video processing profiles and workflows stored in a YAML configuration file. Key functionalities include:This class is essential for managing reusable configurations for video processing tasks.
1. Configuration Management:Loads profiles and workflows from a YAML file (config/profiles.yaml) and saves any updates or new definitions back to the same file, ensuring configurations remain persistent and easily editable.
2. Profiles:The module allows retrieving specific profiles by name and listing all available profiles with their details. It validates each profile to ensure required fields like operation and parameters are defined, and also supports creating custom profiles dynamically for flexible and reusable video processing configurations.
3. Workflows:The module can retrieve a specific workflow by name and list all available workflows along with their descriptions and the number of jobs they contain, providing a clear overview of predefined processing pipelines.
4. Error Handling and Logging:Logs warnings for missing profiles/workflows and errors during file operations.

Design Patterns

The FFmpeg-batch system applies several proven software design patterns to ensure maintainability and scalability. It follows a producer–consumer model through its job queue: the FastAPI layer acts as the producer by submitting jobs, while asynchronous worker processes act as consumers, executing FFmpeg tasks concurrently. The system also supports profile-based processing templates, where predefined configurations, such as codec settings, bitrates, and resolutions allow teams to standardize repetitive tasks. On top of that, workflow orchestration ties multiple operations together, enabling complex pipelines (for example, transcoding followed by thumbnail extraction) to run automatically in sequence.

Scalability Considerations

From a scalability perspective, the project uses worker pools to parallelize workloads efficiently, ensuring multiple videos can be processed simultaneously without overloading the system. Effective resource management including queue throttling, memory optimization, and controlled CPU utilization keeps performance consistent even under heavy load. This modular and scalable design makes it straightforward to extend the system horizontally, whether deploying additional Docker containers, scaling Kubernetes pods, or integrating cloud-based distributed processing.

Setting Up the Development Environment

Before building or running the FFmpeg-batch system, it’s essential to configure a proper development environment that mirrors production conditions. The setup ensures smooth testing, consistent builds, and predictable behavior across machines.

Prerequisites Installation

You’ll need to have Docker, Python 3.11, and FFmpeg installed. Docker handles containerization and makes it easy to run the application and its dependencies consistently. Python 3.11 provides the runtime for FastAPI and background processing components, while FFmpeg performs the actual video operations. Once installed, you can verify your setup using commands like docker --version, python3 --version, and ffmpeg -version.

Project Structure Walkthrough

The project is organized into clear modules for scalability and maintainability. Core components include api.py for the REST interface, job_queue.py for task management, video_processor.py for media operations, and config_manager.py for loading and saving profiles and workflows. Additional directories like data/input/ and data/output/ are used for managing uploaded and processed files.

Configuration Setup

The system uses environment variables (.env) to manage runtime settings like the maximum number of workers or file storage paths and a profiles.yaml file to define reusable encoding profiles and workflows. By editing these configurations, you can customize how the system behaves, whether you’re running quick local tests or deploying to a cloud environment.

Docker Compose Deep Dive

The Docker Compose configuration defines a single service, video-processor, which builds from the local Dockerfile and runs the FFmpeg batch processing API. It maps port 8000 from the container to the host, allowing you to access the FastAPI interface externally. Several volumes are mounted including ./data/input, ./data/output, and ./data/logs to persist uploaded files, processed results, and runtime logs outside the container lifecycle. The ./config directory is also mounted to provide access to YAML configuration files for profiles and workflows. Environment variables such as MAX_WORKERS, API_HOST, and API_PORT define runtime parameters, while PYTHONUNBUFFERED=1 ensures immediate log output. Finally, the restart: unless-stopped policy guarantees the service automatically restarts if it crashes or the system reboots, making the setup robust for both local development and long-running batch processing tasks.

Development vs. Production Setup

In development mode, you can use live-reload for FastAPI and local volumes for quick iteration and debugging. In production mode, Docker Compose can be extended to include load-balanced worker containers, persistent storage, and monitoring tools. This setup enables horizontal scaling and high availability while maintaining the same base configuration used during development ensuring consistent results from your laptop to the cloud.

Configuration Management & Profiles

A core strength of the FFmpeg-batch system lies in its flexible configuration layer, which defines reusable processing templates and multi-step workflows through a YAML-based profile system. This allows developers and media teams to standardize encoding, compression, and transformation parameters while maintaining full control over quality, size, and performance trade-offs.

Profile System (`config/profiles.yaml`)

Profiles define how a video should be processed, specifying the operation type (e.g., transcode, compress, extract_audio) and its parameter set (e.g., codec, preset, CRF, or scaling). Each profile acts as a self-contained template that can be reused across multiple workflows or customized for specific business needs.

Common profiles include:

web_optimized — transcodes videos to H.264 with a medium preset and CRF 23 for web streaming.
social_media — compresses videos to 720p targeting 50 MB, ideal for platforms like Instagram or TikTok.
mobile_optimized — scales videos down to 480p and limits file size for efficient mobile delivery.
audio_mp3 and audio_aac — extract audio tracks at defined bitrates and formats for podcasts or companion files.
thumbnail and preview_gif — generate visual previews or short animated snippets to enhance content catalogs.

Creating custom profiles is straightforward: teams can define their own processing templates to meet business-specific requirements such as watermarking, caption embedding, or broadcast-compliant exports. The YAML format also supports profile inheritance, enabling developers to extend base configurations (like web_optimized) with minor overrides, ensuring consistency while reducing redundancy.

Workflow Orchestration

Beyond individual operations, the system supports multi-step workflows that chain multiple profiles into a single automated pipeline. For example, the social_media_package workflow combines compression, thumbnail generation, and GIF preview creation, all triggered as one batch job. Similarly, the archive_package workflow transcodes video at high quality, extracts MP3 audio, and generates a thumbnail for long-term storage. You can create your own workflows with your own custom profiles that fits your usecases and use them for your applications with this project.

Workflows also enable parallel execution, allowing independent operations (such as audio extraction and GIF creation) to run simultaneously for faster turnaround. More advanced pipelines can incorporate conditional logic, such as adapting encoding settings based on input resolution or target platform requirements. Additionally, batch operations can be applied to entire directories, processing hundreds of videos in a consistent, repeatable manner.

Together, the profile and workflow system transforms FFmpeg-batch from a simple video processor into a scalable, declarative media automation framework, one that adapts to varied production environments and evolving content demands.

Command Line Interface

The Command Line Interface (CLI) in the FFmpeg-batch system offers a fast, intuitive way to trigger and monitor batch processing jobs directly from the terminal. Built on top of the FastAPI backend, the CLI (cli.py) simplifies automation for developers, video engineers, and content teams who prefer command-line tools or need to integrate FFmpeg-batch into larger production pipelines.

CLI Design (`cli.py`)

The CLI is designed around clear, operation-based command grouping. Users can run commands like process, upload, list, or download to manage the entire lifecycle of a batch job, from input submission to result retrieval. Each command maps closely to the API endpoints, ensuring consistency between programmatic and manual use.

In interactive mode, the CLI provides progress bars and real-time feedback for active jobs, displaying percentage completion, estimated time remaining, and current processing status. This helps operators monitor workloads without constantly querying the API.

The CLI also supports batch operations, allowing users to process entire directories with a single command (e.g., cli.py process-folder ./input_videos --profile web_optimized). It automatically applies the chosen profile to all files and stores results in the designated output directory. In CLI, you can run the below docker-compose command to execute it in a docker container:

# Using a profile
docker-compose exec video-processor python cli.py profile /data/input/video.mp4 web_optimized --output /data/output/video.mp4

Finally, the CLI integrates seamlessly with shell scripting and automation workflows, perfect for CI/CD pipelines, cron jobs, or custom scripts that need to trigger video processing as part of larger media workflows. You can also create custom operations like the one given below which transcodes with custom parameters:

# Transcode with custom parameters
python cli.py create /data/input/video.mp4 transcode \\\\
  --params '{"codec":"libx264","preset":"slow","crf":18}'

Conclusion

The project demonstrates how even complex, large-scale video operations can be automated using open-source tools like FFmpeg, FastAPI, and Docker. By abstracting individual processing tasks into profiles and workflows, it enables reproducible, scalable, and platform-agnostic video processing pipelines from content creators automating their daily exports to enterprises handling thousands of assets.

Whether you deploy it locally or in the cloud, this architecture can serve as the foundation for more advanced systems like adding GPU acceleration, distributed job queues, or integration with cloud storage. The full source code is available on GitHub, so you can clone, modify, and extend it for your specific production needs.

How to run FFmpeg inside a Docker container

Robin — Wed, 29 Oct 2025 12:22:12 GMT

FFmpeg is a powerful multimedia framework used for video and audio processing. From transcoding and editing to streaming, its versatility makes it a go-to tool for developers and media professionals. However, installing FFmpeg directly on your system can sometimes lead to dependency conflicts or version mismatches.

This is where Docker comes in. If you’ve never used Docker before, think of it as a platform that lets you package applications and all their dependencies into something called a container. A container is like a lightweight, portable box that holds everything your application needs to run operating system libraries, binaries, and configurations. Unlike virtual machines, containers don’t include a full guest operating system, which makes them much more efficient and faster to start up. If you’re unfamiliar with FFmpeg itself, our Ultimate Guide to FFmpeg provides a comprehensive introduction.

The main takeaway is this: Docker ensures that your application runs the same way everywhere, whether on your laptop, a colleague’s computer, or a cloud server. That means no more “it works on my machine” problems. With FFmpeg inside a Docker container, you get a clean, isolated environment for media processing that you can easily replicate or share with others.

In this guide, we’ll walk through two approaches for using FFmpeg with Docker:

Running FFmpeg with a pre-built Docker image.
Building your own Dockerfile for more customization.

Before we start, we need to setup Docker on our machine. Lets do that now

Installing Docker

Before working with FFmpeg in Docker, you need to have Docker installed on your system. The installation process varies depending on your operating system, but Docker provides excellent step-by-step instructions.

Check system requirements. Docker Desktop works on macOS, Windows, and Linux distributions. Make sure your system meets the minimum requirements.
- Windows / macOS: Download Docker Desktop from the official download page. Run the installer, and follow the on-screen instructions. Once installed, Docker will run as a background service.
- Linux: On Linux distributions like Ubuntu, you can install Docker directly via the package manager. For example:

Test Docker with a hello-world container. Run the following command to check that Docker is working correctly:

docker run hello-world

This command pulls a small test image from Docker Hub, runs it, and prints a confirmation message.

Verify the installation. After installation, open a terminal (or PowerShell on Windows) and run:

docker --version

This should display the installed Docker version.

Install Docker Desktop (recommended for beginners)

sudo apt-get update
sudo apt-get install docker.io

Alternatively, follow the Linux installation guide for your distribution.

Once you see the “Hello from Docker!” message, you’re ready to start working with FFmpeg inside containers.

Approach 1: Using a Pre-Built FFmpeg Docker Image

The quickest way to get started with FFmpeg in Docker is to use an image that’s already prepared for you. One of the most widely used options is the image maintained by jrottenberg.

Pulling the Image

Start by opening your terminal and pulling the official FFmpeg image:

docker pull jrottenberg/ffmpeg

This downloads the latest FFmpeg image and makes it available on your system. To deploy your containerized FFmpeg pipelines on low‑cost cloud infrastructure, see our guide on running FFmpeg on AWS Spot Instances, and for deployment on Google Cloud, follow our guide on running FFmpeg on GCP.

Running a Container

Once the image is available, you can launch a container and access FFmpeg inside it:

docker run -it jrottenberg/ffmpeg bash

This command starts a container, opens a bash shell inside it, and gives you access to FFmpeg as if it were installed directly on your machine.

Using FFmpeg

Inside the container, you can run FFmpeg commands just like you normally would. For example, to convert a video file from MP4 to AVI:

ffmpeg -i input.mp4 output.avi

If your input files are on your host machine, you’ll want to mount them so the container can access them. A common pattern is:

docker run --rm -v $(pwd):/data jrottenberg/ffmpeg -i /data/input.mp4 /data/output.avi

Here, your current working directory is mounted into the container at /data, allowing you to process files without copying them into the container.

-rm : Automatically remove the container when it exits (keeps things clean).
-v $(pwd):/data : Mounts your current directory ($(pwd) prints it) into /data inside the container.
jrottenberg/ffmpeg : The ffmpeg image.
ffmpeg -i /data/input.mp4 /data/output.avi : The FFmpeg command that runs inside the container, reading from and writing to /data.

Want to build an app that crops and trims videos? Our Flutter tutorial shows how to crop and trim videos in Flutter using FFmpeg within a mobile UI.

Exiting the Container

When you’re done, simply type exit to leave the container and return to your host terminal.

Approach 2: Building a Custom Dockerfile with FFmpeg

Sometimes, you might need more control over your environment—for example, specifying which version of FFmpeg you want to use or installing additional tools. In that case, building your own Docker image is the better choice.

Creating a Dockerfile

Start by creating a file named Dockerfile with the following content:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y ffmpeg

This simple Dockerfile uses Ubuntu as the base image and installs FFmpeg on top of it.

Building the Image

Navigate to the directory containing your Dockerfile and build the image:

docker build -t custom-ffmpeg-image .

This creates a new image called custom-ffmpeg-image.

Running Your Custom Image

Now you can start a container from your custom image:

docker run -it custom-ffmpeg-image bash

This gives you the same FFmpeg functionality but within a controlled environment that you designed. Now, you are currently in the terminal of the UbuntuGitHub system with ffmpeg installed and ready to use. You can either mount your volume to the container or copy the input video to the container to process it with ffmpeg.

You can use this GitHub repository for the code.

Beyond the Basics

Depending on context and requirements, there are a few additional ways people run FFmpeg in Docker that you might find useful. Lets sneak-peak into those approaches now:

Multi-stage builds

Instead of installing FFmpeg on top of Ubuntu in a simple Dockerfile, some projects use a multi-stage build where the first stage compiles FFmpeg from source (with specific options or codecs), and the final stage copies only the compiled binaries into a minimal image (like alpine). This results in much smaller images, which is valuable for production environments.

FROM alpine:latest as build
RUN apk add --no-cache build-base yasm
RUN git clone <https://git.ffmpeg.org/ffmpeg.git> ffmpeg \\
    && cd ffmpeg \\
    && ./configure --enable-gpl --enable-nonfree \\
    && make && make install

FROM alpine:latest
COPY --from=build /usr/local/bin/ffmpeg /usr/local/bin/

Using FFmpeg inside a larger containerized workflow

In practice, FFmpeg is often not run alone. For example, it might be used as part of a media processing pipeline in Kubernetes or Docker Compose with other services like Nginx, Node.js, or a message queue. In those cases, FFmpeg runs inside a dedicated container, and files are passed to it via mounted volumes or network streams. For a Docker‑based pipeline with REST APIs and worker queues, see our production‑ready batch video processing server guide.

GPU-accelerated FFmpeg builds

For users doing heavy video processing, using NVIDIA GPU support is crucial. Docker supports GPU acceleration via -gpus all and NVIDIA’s base images. There are specialized FFmpeg images (like nvidia/cudabased builds) that enable hardware-accelerated encoding/decoding (NVENC, NVDEC, CUDA).

docker run --gpus all -it nvidia/cuda:12.2.0-base ffmpeg ...

This is extremely relevant for modern workloads (e.g., streaming, AI video processing).

Which Approach Should You Choose?

If you only need FFmpeg occasionally and want the fastest way to get started, the pre-built image is the way to go. It saves time and effort, and you’ll be up and running within minutes.

On the other hand, if your workflow requires specific versions of FFmpeg, or if you’d like to bundle other tools into the same container, creating a custom Dockerfile gives you that flexibility.

While Dockerized FFmpeg is powerful on its own, its real strength becomes clear when integrated into larger developer workflows. For example, CreativeEditor SDK (CE.SDK) provides a full-featured, customizable editing environment for images, graphics, and videos. When developers extend CE.SDK with Dockerized FFmpeg, they unlock a scalable way to handle demanding media tasks behind the scenes.

Conclusion: Why FFmpeg in Docker is the Smart Choice

Running FFmpeg inside Docker combines the power of a world-class media framework with the reliability and portability of containers. Instead of fighting dependency issues on your local system, you get a clean, isolated environment that works consistently across machines, teams, and production servers.

If you need speed and simplicity, a pre-built image like jrottenberg/ffmpeg gets you up and running in minutes.
If you want control and customization, a custom Dockerfile ensures your build has the exact codecs, libraries, and dependencies you need.
For advanced scenarios, GPU acceleration, multi-stage builds, or cloud pipelines, Docker ensures FFmpeg scales well into modern production environments.

And beyond standalone usage, frameworks like **CE.SDK** demonstrate how FFmpeg’s capabilities can power full-featured creative applications. Whether it’s transcoding video, exporting edits, or automating workflows, running FFmpeg in Docker keeps your setup clean and future-proof.

By combining Docker’s portability with FFmpeg’s versatility, you’re not just solving installation problems, you’re setting up a foundation for professional, scalable multimedia processing.

FFmpeg on GCP: Step-by-Step for Beginners

Robin — Wed, 08 Oct 2025 06:56:08 GMT

Introduction

When it comes to working with video and audio files, FFmpeg is one of the most powerful and widely used tools available. It’s an open-source command-line utility capable of handling almost any kind of media conversion, compression, and processing task. Whether you need to convert a video from MP4 to WebM, extract audio from a movie, or resize a large video for the web, FFmpeg is often the go-to solution for developers and media professionals alike. For an in‑depth overview of FFmpeg commands and features, read our Ultimate Guide to FFmpeg.

While you can install and run FFmpeg locally on your computer, there are limitations. Processing large video files on a personal machine can be slow, resource-intensive, and impractical if you need to handle multiple files or larger workloads.

This is where Google Cloud Platform (GCP) comes in. By running FFmpeg on GCP, you gain access to scalable cloud infrastructure that can process media files much faster than most local setups. You can choose the right machine size for your task, scale up when handling heavy jobs, and only pay for the resources you use. If you prefer Amazon Web Services, our guide to running FFmpeg on AWS Spot Instances covers a similar setup.

By the end of this guide, you’ll know how to set up a Google Cloud project, run FFmpeg on a virtual machine, and process videos efficiently in the cloud. This tutorial is designed with beginners in mind, so even if you’re new to cloud platforms or FFmpeg, you’ll be able to follow along step by step.

Set Up a Google Cloud Project

Before you can run FFmpeg on Google Cloud, you’ll need to create a project where all your resources, such as virtual machines and storage, will live. Think of a Google Cloud project as a workspace that keeps everything organized and secure. Each project has its own settings, billing, and resources, so you can keep experiments separate from production work.

1. Create a New Project

Start by going to the Google Cloud Console. In the top menu, click on the project selector and choose New Project. Give your project a name (for example, ffmpeg-demo) and, if prompted, select an organization. Once created, this project will serve as the container for all the steps that follow.

2. Enable Billing

Google Cloud requires billing to be enabled in order to use most services. If you haven’t set this up yet, you’ll be asked to link your project to a billing account. Don’t worry, Google Cloud offers a free tier with credits for new users, which is more than enough to complete this tutorial and experiment with small workloads.

3. Set Up Google Cloud Storage

Next, you’ll need a place to store your media files. Google Cloud Storage (GCS) works like a highly reliable online hard drive. You can upload your videos there, process them with FFmpeg on a virtual machine, and then save the results back to the same bucket.

In the Google Cloud Console, navigate to Cloud Storage → Buckets.
Click Create Bucket and choose a unique name (e.g., my-ffmpeg-videos).
Select the default storage class and location that best matches your region.
After the bucket is created, click Upload Files and add a small test video, this will be the file you process later in the tutorial.

At this point, you have a project set up with billing enabled and a storage bucket containing your test video. Need to crop or trim your videos before uploading? Our Flutter guide demonstrates how to crop and trim videos in Flutter using FFmpeg. You’re now ready to create a virtual machine that will run FFmpeg.

Note: Not all services are enabled when you start working with GCP. If you are prompted to enable a service while working on this setup, please do enable it and keep track on it in API & Services.

Start a Compute Engine VM

With your project and storage bucket ready, the next step is to create a Compute Engine Virtual Machine (VM). A VM is essentially a computer in the cloud, you decide how powerful it should be, and you only pay for the time it’s running.

1. Choose a Machine Type

Head over to the Compute Engine section in the Google Cloud Console and click Create Instance. You’ll need to configure a few options:

Name: Pick something descriptive like ffmpeg-vm.
Region & Zone: Choose a region close to you or your users for faster upload/download speeds.
Machine type:
- For testing and small videos, a smaller instance like e2-medium (2 vCPUs, 4 GB memory) is usually enough.
- For larger video processing jobs, choose something more powerful such as n2-standard-4 (4 vCPUs, 16 GB memory) or higher. The more CPU and memory you assign, the faster FFmpeg can handle big files.

💡 Tip: You can always resize or recreate the VM with a larger machine later if you find it’s too slow.

To automate large numbers of FFmpeg jobs using REST APIs and worker queues, refer to our batch video processing server guide.

2. Configure Boot Disk

By default, Google Cloud gives you a Debian or Ubuntu Linux image, which works perfectly for FFmpeg. You don’t need to change anything here unless you prefer another distribution.

3. Configure Access Scopes

By default, the instances can only read from a bucket, but we need to upload the output back to the bucket, so in Security tab set the Access Scopes to Set access for each API and set Storage to “Read Write”.

3. Create and Launch the VM

Click Create and wait a moment, Google Cloud will provision your VM. Once it’s ready, you’ll see it listed under VM Instances in the Compute Engine dashboard.

4. Connect via SSH

To start using the VM, click the SSH button next to your instance in the console. This opens a secure terminal session directly in your browser. You’re now logged into your VM and ready to install software, just as if you were sitting in front of a fresh Linux machine.

At this stage, you have a working VM connected to your project. Alternatively, you can run FFmpeg inside a Docker container for a reproducible environment - our Docker guide shows how. In the next section, you’ll install FFmpeg on this machine and run your first test command.

Install FFmpeg

FFmpeg is available in the default Debian/Ubuntu repositories that Google Cloud’s standard Linux images use, so installation is just a couple of terminal commands. For more information on FFmpeg for Linux distros, see here.

1) Install via APT (recommended)

# Update package lists
sudo apt update

# Install FFmpeg and ffprobe
sudo apt -y install ffmpeg

# Verify installation
ffmpeg -hide_banner -version
ffprobe -hide_banner -version

If you prefer the very latest FFmpeg, you can also download a prebuilt Linux static build from the official FFmpeg downloads page (no extra system libraries required).

2) Quick sanity checks

# See available encoders/decoders in your build
ffmpeg -hide_banner -encoders | head -n 20
ffmpeg -hide_banner -decoders | head -n 20

Refer to the official command reference if you want to understand what each option means.

Test FFmpeg with sample commands

You can test FFmpeg without any input file by generating a short test pattern using the built-in testsrc video source filter:

# Generate a 3-second 1280x720 MP4 test video
ffmpeg -f lavfi -i "testsrc=duration=3:size=1280x720:rate=30" \\
  -c:v libx264 -pix_fmt yuv420p ~/test.mp4

The testsrc filter creates a color bars pattern with a timestamp—perfect for verifying your install.

Tip: If you encounter “Unknown encoder” for a codec, either switch to another codec available in your build or install a newer build (e.g., the official static builds mentioned above).

You’re now ready to pull a real file from Cloud Storage and process it on your VM in the next section.

Process a Video

Now that FFmpeg is installed on your Compute Engine VM, let’s process a real video. The workflow looks like this: download a file from Google Cloud Storage → process it with FFmpeg → upload the result back to Google Cloud Storage.

Download Video from GCS to the VM

First, make sure the gcloud CLI is installed on your VM (it usually is on Google-provided images). Then, copy the test video from your storage bucket:

# Replace with your actual bucket and file names
gsutil cp gs://my-ffmpeg-videos/test.mp4 ~/test.mp4

This command uses gsutil to copy the file into your VM’s home directory.

Run a Conversion with FFmpeg

Let’s do a simple format conversion and resizing example:

# Convert MP4 to WebM, resized to 720p
ffmpeg -i ~/test.mp4 -vf "scale=1280:-2" \\
  -c:v libvpx-vp9 -b:v 1M -c:a libopus \\
  ~/output.webm

Here’s what this command does:

i ~/test.mp4 → input file.
vf "scale=1280:-2" → resizes video to 1280px wide while keeping aspect ratio.
c:v libvpx-vp9 -b:v 1M → encodes video with VP9 codec at ~1 Mbps.
c:a libopus → encodes audio with the Opus codec.
~/output.webm → output file.

When it finishes, you’ll have a new WebM file in your VM’s home directory.

Upload the Result Back to GCS

Finally, copy the processed file back into your storage bucket:

# Replace with your bucket name
gsutil cp ~/output.webm gs://my-ffmpeg-videos/

You can now view or download the processed video directly from your GCS bucket.

For a ready to use example of the above architecture, you can refer to this github repository.

Other Options on GCP

While running FFmpeg on a Compute Engine VM is the most straightforward way to get started, Google Cloud offers several other options that might better suit your needs depending on scale and workflow.

Cloud Run for Small Jobs

If you want a serverless option, Cloud Run lets you package FFmpeg into a container and run it on demand. This is a great fit for lightweight jobs or API-style services, where you don’t need to manage servers at all. You simply pay for the CPU and memory used during each request, making it cost-efficient for occasional media processing.

Transcoder API for a Managed Service

For teams who want to skip infrastructure entirely, Google offers the Transcoder API. It’s a fully managed video processing service where you just provide the input file and the desired output format, and Google handles the rest. It’s especially useful for production pipelines with predictable formats, but it’s less flexible than rolling your own FFmpeg setup.

Kubernetes for Large-Scale Workloads

If you’re dealing with a high volume of media jobs, consider deploying FFmpeg in a Google Kubernetes Engine (GKE) cluster. This allows you to scale horizontally, running multiple FFmpeg pods in parallel to process many videos at once. While it requires more setup, it provides the foundation for a production-grade, auto-scaling media processing system.

Beyond FFmpeg: A UI for Creative Editing

FFmpeg is excellent for batch conversions and automation, but what if you want to offer end-users a creative editing experience directly in the browser? This is where solutions like CE.SDK from IMG.LY come in. CE.SDK is a fully customizable editing SDK that you can integrate into your app, enabling Canva-grade photo, video, and design editing features on top of your processing pipeline. In fact, combining FFmpeg’s backend power on GCP with CE.SDK’s front-end UI gives you the best of both worlds: automated conversions plus user-driven creativity.

Conclusion

By now, you’ve seen how straightforward it is to run FFmpeg on Google Cloud Platform. With just a few steps—creating a project, setting up a Compute Engine VM, installing FFmpeg, and connecting it to Cloud Storage—you can process videos in the cloud as easily as on your local machine. The benefit is that your workflow is now backed by scalable infrastructure: you can choose a lightweight VM for simple conversions or a powerful instance when you need to process large files quickly.

This tutorial has given you a solid foundation, but it’s only the beginning. From here, you can explore automation by scripting your FFmpeg jobs and scheduling them with Cloud Functions or Cloud Scheduler. For scaling, you might package FFmpeg into containers and deploy it on Kubernetes to process thousands of files in parallel. And if you want to save time managing infrastructure altogether, managed services like the Transcoder API let Google handle the heavy lifting for you.

Whether you stick with Compute Engine for flexibility or move toward serverless and managed services for efficiency, running FFmpeg on GCP gives you the power to build media pipelines that grow with your needs.

How to Run FFmpeg on AWS Spot Instances for Scalable, Low-Cost Video Processing

Robin — Mon, 06 Oct 2025 08:25:43 GMT

In this guide, we’ll explore how to harness Amazon Web Services (AWS) for video processing with FFmpeg. You’ll learn why the cloud is so helpful for handling resource-heavy video tasks, how to set up your AWS Spot Instance and S3 bucket, and how to run FFmpeg jobs at scale. Along the way, we’ll get acquainted with AWS Spot Instances, a cost-saving compute option that can make large-scale video processing far more affordable. If you’re new to the tool itself, start with our Ultimate Guide to FFmpeg.

By the end of this article, you’ll know how to:

Set up AWS with S3 storage and a Spot instance.
Install and test FFmpeg in the cloud.
Run video processing jobs on a Spot Instance while keeping costs low.

Whether you’re new to cloud computing or just looking for a practical way to scale your FFmpeg workflows, this guide will walk you through the essentials step by step.

Lets dive into by setting up the AWS environment.

Set Up Your AWS Environment

Before you can run FFmpeg in the cloud, you need to prepare your AWS environment. This involves creating an account, setting up storage, and launching an instance where you’ll install and run FFmpeg. Let’s break it down step by step.

Create an AWS Account and S3 Bucket

If you don’t already have one, sign up for an AWS account. Once logged into the AWS Management Console, the first thing to set up is an Amazon S3 bucket. S3 (Simple Storage Service) is AWS’s object storage system, and it’s ideal for hosting both your input and output video files. For example, you can upload raw videos to S3, process them with FFmpeg, and then store the converted files back in the same bucket. When creating your bucket, be sure to choose a region close to where you expect to run your compute resources, as this reduces latency and transfer costs.

Launch a Spot Instance

Spot Instances

AWS Spot Instances are virtual machines that let you access unused cloud capacity at significantly reduced prices, sometimes up to 90% cheaper than regular On-Demand Instances. The catch is that they can be interrupted by AWS with little notice if the capacity is needed elsewhere. For workloads like video processing, which can be restarted or distributed across multiple nodes, Spot Instances are a perfect fit. They allow developers to take advantage of lower costs without sacrificing performance, provided they design workflows with fault tolerance in mind. This balance of affordability and scalability makes Spot Instances a popular choice for running FFmpeg jobs in the cloud.

Setup a Spot Instance

From the AWS console, go to the EC2 dashboard and launch a new instance. Choose Ubuntu Server or Amazon Linux as the operating system, since both have excellent community support and are well-documented. When selecting an instance type, start with something lightweight like t2.micro (eligible for the free tier), but keep in mind you may need more powerful instances (with higher CPU or GPU) for larger video workloads. Open the Advanced Details, under Purchasing option, check the box labeled Spot Instances to tell AWS you want to use discounted spare capacity instead of On-Demand pricing. You can also set a maximum price per instance hour if you want to control costs more tightly, but in most cases leaving it at the default ensures you’ll simply pay the current Spot market price, which automatically adjusts with supply and demand and is never higher than the standard On-Demand rate.

You can also choose between a persistent or one-time request type in the Customize Spot Instance options.

Once the instance is created, you can confirm that its lifecycle is spot under the instance details section. This indicates that a Spot Instance has been successfully created.

Connect to Your Instance via SSH

Once your Spot instance is running, you can connect to it remotely using SSH (Secure Shell). During instance setup, AWS will prompt you to create or download a key pair (.pem file). Keep this file safe, it’s your private key for secure access. On your local machine, open a terminal at the location where you saved the key pair file and run:

ssh -i "your-key.pem" <username>@<your-instance-public-dns>

Replace your-key.pem with the path to your private key file and <your-instance-public-dns> with the public DNS address of your Spot instance (visible in the console). You can get the exact SSH command for your instance by clicking the Connect button in the EC2 dashboard and selecting the SSH client option. Once connected, you’ll be inside the environment where you can install FFmpeg and start running commands. For a smooth operation, make yourself familiar with basic shell commands for the operating system you opted for in the instance. Examples for various shell commands on a linux system can be found here.

Install FFmpeg on the Spot Instance

With your spot instance up and running, the next step is to install FFmpeg so you can start processing videos. Installation is straightforward, and once complete, you’ll test it with a simple command to confirm everything works.

Update Your Package Lists

Before installing any software, it’s a good practice to make sure your system’s package list is up to date. Run:

sudo apt update && sudo apt upgrade -y

This command refreshes the list of available software and ensures your instance has the latest security patches. (If you’re using Amazon Linux instead of Ubuntu, replace this with sudo yum update -y.)

Install FFmpeg

On Ubuntu, FFmpeg is available directly through the official package repository:

sudo apt install ffmpeg -y

For Amazon Linux, the process may require enabling extra repositories first:

sudo amazon-linux-extras enable epel
sudo yum install ffmpeg -y

This will download and install FFmpeg along with its dependencies. To avoid dependency issues, consider running FFmpeg inside a Docker container.

Verify the Installation

After installation, check that FFmpeg is available by running:

ffmpeg -version

You should see output showing the installed FFmpeg version and configuration details.

Run FFmpeg on a Spot Instance

Now that you’ve installed FFmpeg on a regular Spot instance, it’s time to make evrything work together. In this section, upload a video to Amazon S3, and then run FFmpeg on the spot instance to process the video and save the output.

While it’s possible to upload videos directly to the instance and process them there, this approach isn’t reliable since the instance can be terminated at any time when AWS reclaims capacity. The better and safer practice is to use the S3 bucket, which ensures your files are stored safely and don’t need to be re-uploaded each time. This is especially important when working with large video files or multiple inputs, as S3 provides a more reliable and scalable storage solution. Prefer Google Cloud? See our tutorial on running FFmpeg on GCP for similar steps.

Upload a Sample Video to S3

Before running FFmpeg, you’ll need a video file available in your S3 bucket. From your local machine terminal (not the instance terminal), use the AWS CLI to upload a sample file:

aws s3 cp sample.mp4 s3://your-bucket-name/input/sample.mp4

This stores sample.mp4 inside the input folder of your bucket. Organizing files into input and output directories is a good practice for video workflows. You can do the same using the S3 dashboard in AWS. If your workflow involves cropping or trimming videos before upload, check out our Flutter guide on crop and trim videos in Flutter.

If you are using AWS CLI for the first time in you machine, then setup your credentials using aws configure command. See here for more help.

Run FFmpeg on the Spot Instance

Once your Spot Instance is running, connect to it via SSH (the same way you did earlier). Before we get the video from the S3 bucket, you should set an IAM Role for the instance to access the S3 bucket. For that, go to IAM>Roles>Create Role, select EC2 from use case dropdown menu. On the next page, search for AmazonS3FullAccess and select it, give a role name and finaly create it. Now the instances can access the files from the bucket.

Since the instance is a new system, you will need to install awscli from here. You will also have to setup credentials using aws configure command as mentioned above. Then, copy the input file from S3 down to your instance:

aws s3 cp s3://your-bucket-name/input/sample.mp4 sample.mp4

Now, run FFmpeg to process the video. For example, converting MP4 to WebM:

ffmpeg -i sample.mp4 output.webm

After processing, upload the result back to S3:

aws s3 cp output.webm s3://your-bucket-name/output/output.webm

You can now access your processed file directly in S3 and even configure it for delivery via Amazon CloudFront if needed.

By running FFmpeg jobs on Spot Instances, you can save up to 90% of costs compared to On-Demand pricing, making this setup ideal for batch video processing.

You can refer to this github repository for examples.

Spot Instances vs AWS Lambda for FFmpeg

When running FFmpeg on AWS, you have more than one option for compute. Two of the most common choices are AWS Lambda and EC2 Spot Instances. Each has its strengths and trade-offs, and the best fit depends on the type of video workload you’re running.

AWS Lambda for Lightweight Tasks

AWS Lambda is Amazon’s serverless compute service—you don’t need to manage servers, and your code runs only when triggered. It’s easy to set up and integrates seamlessly with other AWS services such as S3 and API Gateway. For example, you can automatically run an FFmpeg job as soon as a new video is uploaded to your S3 bucket.

However, Lambda comes with limitations: functions can only run for a maximum of 15 minutes, and they have limited temporary storage (512MB by default, extendable up to 10GB). This makes Lambda a great choice for lightweight tasks like generating thumbnails, clipping short videos, or converting smaller files, but not for large-scale processing.

EC2 Spot Instances for Heavy Workloads

EC2 Spot Instances, by contrast, are designed for long and heavy workloads. Spot Instances give you access to unused EC2 capacity at discounts of up to 90% compared to On-Demand pricing. Since they are full-fledged EC2 machines, Spot Instances don’t impose runtime limits or storage caps.

This makes them ideal for large video files, long-running transcodes, and GPU-accelerated workloads such as 4K/8K encoding or complex filter pipelines. The trade-off is that Spot Instances can be interrupted by AWS with two minutes of notification when EC2 needs the capacity back, so jobs need to be either restartable or split into smaller tasks.

Rule of Thumb

A simple guideline to choose between the two is:

Small, quick jobs → use AWS Lambda
Large, long jobs but restartable → use EC2 Spot Instances

By matching the right AWS service to your workload, you get the best balance of cost, performance, and reliability for running FFmpeg in the cloud.

Handling Spot Interruptions

Two-Minute Warning

One important aspect of using Spot Instances is that they can be interrupted at any time if AWS needs the capacity back. When this happens, AWS provides a two-minute warning before the instance is terminated. For video processing workflows, this means you need to plan for interruptions so that work isn’t lost midway.

Break Videos into Smaller Chunks

A common strategy is to break long videos into smaller chunks before processing. For example, instead of transcoding a two-hour video in one run, you can split it into 10-minute segments, process each segment separately, and then stitch them back together later. This way, if an interruption occurs, only the current segment is affected rather than the entire job. FFmpeg supports segmenting input files using options like -ss (start time) and -t (duration), which makes this approach straightforward.

Store Partial Results in S3

Another best practice is to store partial results in Amazon S3 as soon as they are completed. For instance, after processing each video chunk, upload the output back to your S3 bucket immediately. This ensures that even if the Spot Instance is terminated, your progress is safe, and you can resume processing from the last completed chunk instead of starting over. Using S3 as a central storage layer makes your workflow fault-tolerant and resilient against interruptions.

Reliable and Cost-Effective Workflows

By designing your FFmpeg workflows with these strategies, you can take full advantage of the cost savings of Spot Instances without risking data loss. This makes Spot instances a reliable option even for long-running or large-scale video processing jobs, provided you build in restart and recovery mechanisms.

Tips & Next Steps

Once you’ve set up FFmpeg on AWS and experimented with Spot Instances, there are a few ways to refine your workflow and explore more advanced options. These next steps will help you get the most out of your cloud-based video processing setup.

1. Try Different Instance Types

AWS offers many EC2 instance families, each optimized for different workloads. For general transcoding and compression tasks, compute-optimized instances like the c5 family are often a good fit, providing strong CPU performance at a reasonable cost. If you’re working with high-resolution videos or need hardware acceleration, GPU-based instances such as the g4dn family can dramatically speed up encoding with FFmpeg’s GPU-enabled libraries. Experimenting with instance types lets you balance performance and cost for your specific use case.

2. Orchestrate Jobs with SQS or Step Functions

As your workflows grow, running jobs manually can become inefficient. AWS provides orchestration tools to help automate FFmpeg jobs. Amazon SQS (Simple Queue Service) can be used to queue video processing tasks, allowing multiple Spot Instances to work on jobs in parallel. For a full Docker‑based pipeline with REST APIs and worker queues, see our production‑ready batch video processing server guide. For more complex workflows, AWS Step Functions provide a way to chain together multiple tasks such as fetching input files, running FFmpeg, handling errors, and saving outputs into a reliable, serverless state machine. These services ensure your video pipelines are scalable and fault-tolerant without requiring you to build custom orchestration logic.

3. Consider CE.SDK as an Alternative

If you’re building custom editing workflows on AWS, consider integrating a frontend editor like our CreativeEditor SDK. While FFmpeg and AWS handle the heavy lifting of transcoding and storage, CE.SDK provides a powerful in-browser editing interface for trimming, adding overlays, applying filters, or creating design templates. This combination allows you to deliver both scalable backend video processing and interactive, user-facing editing tools, similar to what platforms like Canva provide.

Conclusion

Running FFmpeg on AWS Spot Instances gives you a powerful and cost-effective way to handle large-scale video transcoding. By leveraging Spot pricing, you can cut costs by up to 90% compared to On-Demand instances, making it possible to process even long, high-resolution videos without breaking the budget. With strategies like chunking videos and storing partial outputs in S3, interruptions become manageable, allowing you to balance affordability with reliability.

For smaller, lightweight, or event-driven workflows, AWS Lambda is a perfect complement. Its serverless nature makes it easy to trigger FFmpeg jobs automatically, for example, generating thumbnails or clipping short clips as soon as a file is uploaded to S3. Although Lambda has strict runtime and storage limits, it shines when simplicity and automation are priorities.

As a next step, you can begin experimenting with automation and orchestration using services like SQS, Step Functions, or even AWS Batch to build resilient pipelines that combine the strengths of both Spot Instances and Lambda. For teams looking for a fully managed alternative, CE.SDK is also worth exploring.

By now, you’ve seen how to install FFmpeg, run it on spot instance, and handle serverless workflows with Lambda. With these tools and strategies, you’re ready to design flexible, scalable, and affordable video processing pipelines in the AWS cloud.

Join 3,000+ creative professionals who get early access to new features and updates—subscribe.

Robin – IMG.LY Blog

A Guide to Batch Video Editing & Server Automation with FFmpeg

Understanding Video Processing Fundamentals

Architecture Deep Dive

System Components Overview

Design Patterns

Scalability Considerations

Setting Up the Development Environment

Prerequisites Installation

Project Structure Walkthrough

Configuration Setup

Docker Compose Deep Dive

Development vs. Production Setup

Configuration Management & Profiles

Profile System (config/profiles.yaml)

Workflow Orchestration

Command Line Interface

CLI Design (cli.py)

Conclusion

How to run FFmpeg inside a Docker container

Installing Docker

Approach 1: Using a Pre-Built FFmpeg Docker Image

Pulling the Image

Running a Container

Using FFmpeg

Exiting the Container

Approach 2: Building a Custom Dockerfile with FFmpeg

Creating a Dockerfile

Building the Image

Running Your Custom Image

Beyond the Basics

Multi-stage builds

Using FFmpeg inside a larger containerized workflow

GPU-accelerated FFmpeg builds

Which Approach Should You Choose?

Conclusion: Why FFmpeg in Docker is the Smart Choice

FFmpeg on GCP: Step-by-Step for Beginners

Introduction

Set Up a Google Cloud Project

1. Create a New Project

2. Enable Billing

3. Set Up Google Cloud Storage

Start a Compute Engine VM

1. Choose a Machine Type

2. Configure Boot Disk

3. Configure Access Scopes

3. Create and Launch the VM

4. Connect via SSH

Install FFmpeg

1) Install via APT (recommended)

2) Quick sanity checks

Test FFmpeg with sample commands

Process a Video

Download Video from GCS to the VM

Run a Conversion with FFmpeg

Upload the Result Back to GCS

Other Options on GCP

Cloud Run for Small Jobs

Transcoder API for a Managed Service

Kubernetes for Large-Scale Workloads

Beyond FFmpeg: A UI for Creative Editing

Conclusion

How to Run FFmpeg on AWS Spot Instances for Scalable, Low-Cost Video Processing

Set Up Your AWS Environment

Create an AWS Account and S3 Bucket

Launch a Spot Instance

Connect to Your Instance via SSH

Install FFmpeg on the Spot Instance

Run FFmpeg on a Spot Instance

Upload a Sample Video to S3

Run FFmpeg on the Spot Instance

Spot Instances vs AWS Lambda for FFmpeg

AWS Lambda for Lightweight Tasks

EC2 Spot Instances for Heavy Workloads

Rule of Thumb

Handling Spot Interruptions

Two-Minute Warning

Break Videos into Smaller Chunks

Store Partial Results in S3

Reliable and Cost-Effective Workflows

Profile System (`config/profiles.yaml`)

CLI Design (`cli.py`)