Why You Need the -re Option in FFmpeg RTMP Streaming

This article explains the critical role of the -re option in FFmpeg when streaming video files to an RTMP server. It details the technical consequences of omitting this flag—such as server overload, network congestion, and stream termination—and explains how FFmpeg handles input reading speeds by default.

The Role of the -re Option in FFmpeg

By default, FFmpeg is designed to process media files as fast as your system’s CPU, disk, and network interface will allow. When you convert a file locally, this high-speed processing is ideal because you want the job finished quickly.

However, when streaming a pre-recorded file (like an MP4) to a live RTMP destination, this default behavior causes issues. The -re option forces FFmpeg to read the input file in “real-time” according to its native frame rate. If your video is 30 frames per second (fps), FFmpeg will read and send exactly 30 frames per second.

What Happens When You Omit -re?

If you omit the -re flag when streaming a pre-recorded file to an RTMP server, FFmpeg will attempt to upload the entire video file at maximum speed. This leads to several immediate problems:

1. RTMP Server Ingest Buffer Overflow

RTMP servers (such as Nginx-RTMP, Wowza, Nimble Streamer, or platforms like YouTube Live and Twitch) expect a steady, real-time pace of data. When FFmpeg dumps minutes or hours of video data into the RTMP stream within seconds, the server’s ingest buffer overflows. Most RTMP servers will immediately terminate the connection to protect their resources.

2. Immediate Stream Disconnection and Failures

Because the packet timestamps arrive too quickly and out of sync with real-time, the ingestion handshake or the active session will fail. CDNs and streaming platforms will often flag the stream as unstable and disconnect the broadcast.

3. Extreme Bandwidth Spikes

Without throttling, FFmpeg will consume all available upload bandwidth to push the packets as fast as possible. This can saturate your local network, causing high latency, packet loss, and connection drops for other services on the same network.

4. Playback Buffering and Stuttering

If the RTMP server does manage to accept the rapid influx of data without crashing, viewers will experience severe playback issues. Video players cannot process timestamps that arrive faster than wall-clock time, resulting in frozen frames, infinite buffering loops, or the player skipping directly to the end of the video.

Summary of Best Practices

• Use -re when: You are streaming pre-recorded files (like MP4, MKV, or FLV) to a live RTMP server.
• Do not use -re when: You are streaming from a live input source (like a webcam, capture card, or microphone). Live capture devices naturally generate data in real-time, so forcing the -re option is redundant and can cause latency or sync issues.