Learn FFmpeg - Streaming & Network Protocols

#Introduction

In episode 12 you learned to split video into segments and assemble their playlist. But all that work still happened inside one computer — files going out and into the same disk. In episode 13 we step outside: how you send video from one machine to another, or from your machine to millions of viewers.

The streaming world is full of protocols, each with its own origins and interests. Understanding which protocol fits which case is a far more valuable skill than memorizing commands. That's why this episode starts from the anatomy of the protocols — RTSP, RTMP, SRT, and UDP — then builds a complete live streaming pipeline from capture, encode, to push, and closes with the art of low-latency tuning.

#Anatomy of Streaming Protocols

All streaming protocols share one idea: sending a video bitstream from source to destination, either directly (live streaming) or in stages (on-demand streaming). What distinguishes them are three things: how the session is controlled, how data is transported, and the reliability they offer. Let's break them down one by one.

#RTSP: The Camera and Media Control Protocol

RTSP (Real Time Streaming Protocol) is the remote control for media: it manages the session — play, pause, teardown — while the actual video data travels over another protocol, usually RTP. You most often meet RTSP as a viewer: nearly every IP camera and NVR exposes an RTSP stream that FFmpeg can ingest.

Sending a file as an RTSP stream requires `-re{:bash}`, which makes FFmpeg read the input at real-time speed instead of as fast as possible:

ffmpeg -re -i input.mp4 -c copy -f rtsp rtsp://kameraserver.local/live/stream

Without -re, FFmpeg would exhaust the file in seconds then close the connection — not live streaming, but a lightning-fast delivery. -re is the keyword you'll see in almost every live pipeline.

#RTMP: The Flash Legacy That's Still Alive

RTMP (Real Time Messaging Protocol) was born in the Flash era, and although Flash has long been dead, RTMP remains the de facto standard for ingesting live streams to platforms like YouTube, Twitch, and media servers like Nginx RTMP. The interesting part: even though the protocol is named RTMP, the format FFmpeg sends is FLV, because the RTMP bitstream is essentially FLV carried over TCP.

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -c:a aac -f flv rtmp://ingest.example.com/live/kunci-stream

The URL structure is rtmp://host/app/stream-key: the live part is the application name on the server, and stream-key is the unique key you usually get from the platform when creating a stream. This key is the "address" viewers use to reach you — keep it secret, because anyone holding it can send to your account.

#SRT: Reliable Video Over Bad Networks

SRT (Secure Reliable Transport) was built for one problem: sending video over unreliable networks — intercontinental internet, satellite uplinks, or edge-of-town wifi. It uses UDP as the carrier but adds an ARQ mechanism (retransmission of lost packets) and congestion control. Result: picture quality doesn't fluctuate up and down, only latency rises when the network worsens.

ffmpeg -re -i input.mp4 -c copy -f mpegts srt://192.168.50.10:9000?mode=caller

The SRT URL carries query parameters. mode=caller means this machine takes the initiative to contact the receiver; the receiving side uses mode=listen. The format carried is usually MPEG-TS, because SRT is treated as a reliable "pipe" and any format can pass through it.

#UDP: Broadcast and Multicast Streaming

At the lowest level there's UDP — no connection, no acknowledgments, no retransmission. The consequence is twofold: the lowest latency, but lost packets are lost forever. UDP was originally unsuitable for video, but MPEG-TS was built to survive small packet loss, so the combination of the two is the industry standard for internal broadcast and multicast.

ffmpeg -re -i input.mp4 -c copy -f mpegts udp://239.1.1.1:1234

The 239.x.x.x address is a multicast address: packets are sent once by the source, then routers duplicate them for all receivers that joined that group. One encoder can serve thousands of receivers in a multicast-capable network — that's why UDP/multicast dominates video distribution inside broadcast buildings and stadiums.

#Live Pipeline: Capture - Encode - Push

You may not have a professional camera, but everyone has one video source: a webcam. Let's assemble a complete live streaming pipeline using a webcam (V4L2) and microphone (ALSA) on Linux:

ffmpeg -f v4l2 -framerate 30 -video_size 1280x720 -i /dev/video0 \
  -f alsa -ac 2 -i default \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k \
  -c:a aac -b:a 128k \
  -f flv rtmp://ingest.example.com/live/kunci-stream

This pipeline has three clear stages, and understanding all three lets you debug any problem:

1. Capture — -f v4l2 reads /dev/video0 as the video source, and -f alsa reads default as the audio source. Notice that each source has its own format that must be declared in front of its respective -i option.
2. Encode — libx264 at the veryfast preset with -tune zerolatency encodes the video, aac encodes the audio. Tuning at this stage determines latency, and we'll discuss it shortly.
3. Push — -f flv wraps the bitstream and sends it to the target RTMP URL. This stage is just muxing and delivery; all the heavy work was done at the encode stage.

A fitting analogy for this pipeline is a restaurant kitchen: the raw ingredient source (capture), the cook (encode), and the courier delivering orders (push). Problems visible at the final stage often root in an earlier stage.

#Why Latency Rises, and How to Squeeze It Down

Live streaming latency is the total time from a frame being captured by the camera to it being displayed on the viewer's screen. Its sources aren't one: input buffer, encoder buffer, network buffer, and player buffer. The three biggest leaks we can control from FFmpeg's side are the encoder, GOP, and buffering.

Encoder. -tune zerolatency makes libx264 not delay frames for lookahead analysis — frames go out as fast as they come in. This sacrifices a little compression efficiency for latency. For two-way streaming like conferencing, this priority is right.

GOP. The distance between keyframes determines how fast players can join and how fast you recover from interruptions. A short keyframe interval lowers join latency but raises bitrate. A healthy rule of thumb for live: a 2-second GOP.

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -tune zerolatency \
  -g 60 -keyint_min 60 -sc_threshold 0 \
  -fflags nobuffer -flags low_delay -flush_packets 1 \
  -f flv rtmp://ingest.example.com/live/kunci-stream

• -g 60 forces a keyframe every 60 frames (2 seconds at 30 fps), -keyint_min 60 prevents keyframes from appearing sooner than that, and -sc_threshold 0 disables the scene-change detection that can trigger unexpected keyframes. Result: a tidy, predictable keyframe interval — exactly what we stressed in episode 12 for segmenting.
• -fflags nobuffer and -flags low_delay reduce input and decoder buffering.
• -flush_packets 1 writes packets immediately instead of accumulating them — important for network output.

#Choosing a Protocol: A Decision Guide

With all the options in hand, how do you decide? Three quick questions:

1. Which way does the video flow? If it's going to a public platform, RTMP is its language. If it's between internal machines or sites, SRT is more robust. If it's within one multicast-supporting network, UDP gives the highest efficiency.
2. How bad is the network? Unstable intercontinental internet is SRT territory. A healthy, controlled LAN can safely use RTMP or UDP.
3. Must the session be controlled? If you need play/pause/seek from the receiving side and structured session parameters, RTSP provides that.

No protocol is absolutely "most correct" — there's only the one that best fits your network characteristics and needs.

#Conclusion

In episode 13 you've stepped out of the file world into the network world: understanding RTSP as the media control protocol, RTMP as the live ingest standard carrying FLV, SRT as reliable transport over bad networks, and UDP multicast as the lowest-latency path for internal distribution. You also assembled a complete live streaming pipeline from V4L2 capture, libx264 encode, to RTMP push, along with low-latency tuning via -tune zerolatency, GOP control, and reduced buffering.

Key takeaways:

• -re turns input into real-time rate; without it, there's no live streaming.
• RTMP carries FLV; SRT carries MPEG-TS; the two use different formats.
• A live pipeline always has three stages: capture, encode, push — and debugging starts from understanding those three stages.
• Latency is the combined result of encoder, GOP, and buffers, not a single switch.

If you're only sending a raw stream, these protocols are enough. But modern viewers don't just need video to reach their devices — they need quality that adapts to their bandwidth, and a player that can jump forward and back freely.

In the next episode 14 we'll assemble all the foundations you've built since episode 12: HLS & Adaptive Streaming — how -f hls turns segments and playlists into a streaming experience that can adjust quality dynamically. Keep your enthusiasm up!