How to Use FFmpeg -re for Live Streaming

This article explains how to use the -re option in FFmpeg to read input files at their native frame rate, a critical technique for simulating live streams. You will learn the exact command-line syntax for implementing this flag, understand the technical reasons why it is essential for streaming to platforms like YouTube or Twitch, and discover when you should avoid using it.

What is the FFmpeg -re Option?

By default, FFmpeg processes input files as fast as your system’s CPU and GPU will allow. If you are converting a video file, this speed is ideal. However, if you are streaming a pre-recorded file to a live server, dumping the entire file into the network at maximum speed will cause the stream to fail.

The -re flag (short for “read rate” or “real-time”) tells FFmpeg to throttle its reading speed to match the native frame rate of the input file. For example, if your video is 30 frames per second (fps), FFmpeg will read exactly 30 frames every second, mimicking a live camera feed.

How to Use -re in FFmpeg

To use the -re option correctly, you must place the flag before the input file (-i) in your command line. If placed after the input, it may be ignored or applied incorrectly.

Here is the standard command structure:

ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv rtmp://your-streaming-url/stream-key

Command Breakdown:

• -re: Forces FFmpeg to read the input file at its native frame rate.
• -i input.mp4: Specifies the input video file.
• -c:v libx264: Encodes the video using the H.264 codec.
• -c:a aac: Encodes the audio using the AAC codec.
• -f flv: Formats the output stream as FLV (standard for RTMP).
• rtmp://...: The destination URL of your streaming service.

Why -re is Crucial for Live Streaming

Live streaming servers (like RTMP, SRT, or HLS ingest points) expect a steady, continuous flow of data that matches real-world time. Using -re is critical for three main reasons:

1. Prevents Server Overwhelment: Without -re, FFmpeg will attempt to push hours of video to the ingestion server in a matter of minutes. The receiving server will reject this sudden flood of data, resulting in buffer overflows, disconnected streams, or dropped packets.
2. Maintains Viewer Synchronization: Throttling the input ensures that video and audio packets are timestamped and sent at a pace that players can decode in real-time. This prevents lag, playback stuttering, and desynchronization for the viewers.
3. Simulates Live Broadcasts from Pre-recorded Files: If you want to run a “24/7 live stream” using pre-recorded files, -re allows you to treat a playlist of MP4 files exactly like a live camera feed.

When You Should NOT Use -re

While essential for streaming pre-recorded files, there are scenarios where you should never use the -re option:

• Live Hardware Inputs: If your input is a webcam, capture card, or microphone (e.g., -i /dev/video0), the hardware is already feeding data in real-time. Adding -re is redundant and can cause latency issues or dropped frames.
• Standard Transcoding: If you are converting a video from one file format to another (e.g., MP4 to MKV) and saving it locally, do not use -re. You want this process to run as fast as possible, and using -re will artificially slow the conversion down to the duration of the video.