Understanding RTMP Protocol and Livego Source Code Analysis

The article introduces the Real-Time Messaging Protocol (RTMP), a widely used application‑layer protocol for live video streaming originally designed by Adobe for Flash. It explains why RTMP is a fundamental skill for developers working on live streaming services.

Protocol Features

RTMP supports multiplexing, packetization, and operates as an application‑layer protocol over TCP. Multiplexing allows multiple messages to be split into chunks and transmitted over a single TCP connection, which are later reassembled on the receiver side. Packetization (or "分包") reduces latency by breaking large audio/video packets into smaller chunks.

Core Concepts

The protocol defines a Chunk consisting of a Chunk Header and Chunk Body. The Chunk Header has a variable‑length Basic Header (1‑3 bytes) that encodes the Chunk Stream ID (csid) and a format (fmt) field determining the size of the Message Header. Four Message Header formats exist (fmt = 0, 1, 2, 3) with lengths of 11, 7, 3, or 0 bytes respectively, carrying fields such as timestamp, message length, message type ID, and message stream ID.

The Chunk Body carries the actual payload, typically encoded in AMF0/AMF3 or FLV formats. AMF (Action Message Format) is a binary serialization format similar to JSON, used for command messages.

Message Types

RTMP defines three main message categories: protocol control messages (type IDs 1‑6), data messages (type IDs 8, 9, 18 for audio, video, and metadata), and command messages (type IDs 17, 20 for AMF0/AMF3 commands).

Handshake Process

The handshake consists of three exchanges: C0/C1 from client, S0/S1/S2 from server, and C2 from client. These messages establish version, timestamps, and random data. WireShark captures show the handshake resembles TCP’s three‑way handshake.

Connection and Stream Creation

After the handshake, the client sends a Set Chunk Size command, a Connect command (AMF0) specifying the application name, and the server responds with a _result. The client then issues a createStream command and receives a stream ID.

Publishing and Pulling Streams

Using the livego server (a Go implementation of RTMP), the article demonstrates how to obtain a channel key via a curl request:

$ curl http://localhost:8090/control/get?room=movie
StatusCode        : 200
StatusDescription : OK
Content           : {"status":200,"data":"rfBd56ti2SMtYvSgD5xAV0YU99zampta7Z7S575KLkIZ9PYk"}
...

The client then publishes to rtmp://localhost:1935/live/<channelKey> using OBS. The server validates the channel, sends NetStream.Publish.Start, receives metadata, and then streams audio/video data. Pulling follows a similar flow with a play command, after which the server sends NetStream.Play.Start and the media data.

Latency Issues and Solutions

RTMP’s end‑to‑end latency (3‑8 seconds) stems from CDN transmission delays and client buffer sizes. The article discusses typical mitigation strategies and notes that many cloud providers now offer low‑latency solutions (e.g., WebRTC‑based services) to overcome RTMP’s inherent delay.

References

The article concludes with a list of reference links to the RTMP specification, AMF specifications, FLV documentation, livego source code, and related tutorials.