RTMP傳輸基本流程
發(fā)送端
- Step 1: 把數(shù)據(jù)封裝成消息(Message)。
- Step 2: 把消息分割成消息塊(Chunk, 網(wǎng)絡中實際傳輸?shù)膬?nèi)容)。
- Step 3: 將分割后的消息塊(Chunk)通過TCP協(xié)議發(fā)送出去。
接收端:
- Step 1: 在通過TCP協(xié)議收到數(shù)據(jù)后, 先將消息塊重新組合成消息(Message)。
- Step 2: 通過對消息進行解封裝處理就可以恢復出數(shù)據(jù)。
RTMP的突出優(yōu)點是: 延時低，正常延時1~3秒，理想的話直播可控制在1秒之內(nèi)。
它是怎么做到的?
有什么好的設計思想?
RTMP設計思想
大而化小 輕車簡行
RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息(Message)。
在互聯(lián)網(wǎng)中傳輸數(shù)據(jù)時, 消息(Message)會被拆分成更小的單元, 稱為消息塊(Chunk).
大的Message被切割成利于在網(wǎng)絡上傳輸?shù)男hunk，個人認為這是RTMP之所以延時低的核心原因。
切成小塊, 還可防止大的數(shù)據(jù)塊(如視頻數(shù)據(jù))阻塞小的數(shù)據(jù)塊(如音頻數(shù)據(jù)或控制信息)。
本是天涯同路人 你方唱罷我登場
RTMP基于TCP協(xié)議，包括控制信息、視頻數(shù)據(jù)、音頻數(shù)據(jù)都共用同一個TCP Connection。
也就是說路只有一條。而且同一時間只允許一輛車通過。
生成好的視頻Chunk和音頻Chunk，依次上路。
這就涉及到RTMP中一個非常重要的概念: 復用。
RTMP協(xié)議開篇是這么介紹的:
Abstract
This memo describes Adobe’s Real Time Messaging Protocol (RTMP), an
application-level protocol designed for multiplexing and packetizing
multimedia transport streams (such as audio, video, and interactive
content) over a suitable transport protocol (such as TCP).
其中multiplexing就是復用的意思，指的就是將獨立的音視頻數(shù)據(jù)整合到一個數(shù)據(jù)流，讓音視頻流可以同步傳輸?shù)倪^程。
RTMP直播中，實時生成視頻Chunk和音頻Chunk，依次加入到數(shù)據(jù)流，通過網(wǎng)絡發(fā)送到客戶端。
復用在RTMP中是傳輸方式，也是音視頻同步的關鍵。
事分輕重緩急 軍令最重 糧草次之
在RTMP中，消息(Message)主要分為兩大類: 控制消息和數(shù)據(jù)消息。
數(shù)據(jù)消息中由包括Video 消息和Audio 消息等。
這些消息都是怎么進行管理的呢?
有點像車輛的管理問題。
也就是說路，只有一條，到底誰先走呢，誰后走呢?
答案是: 分優(yōu)先級，優(yōu)先級高的先行。優(yōu)先級低的不能阻塞優(yōu)先級高的。
RTMP協(xié)議可從整體分為兩個層次:
Message stream屬于應用層次消息，Chunk stream屬于更底層RTMP協(xié)議層次。
RTMP Chunk Stream does not provide any prioritization or similar forms of control, but can be used by higher-level protocols to provide such prioritization.
For example, a live video server might choose to drop video messages
for a slow client to ensure that audio messages are received in a
timely fashion, based on either the time to send or the time to
acknowledge each message.
RTMP Chunk Stream層級沒有優(yōu)先級的劃分，而是在高層次Message stream提供優(yōu)先級的劃分。
也就是說: 不同類型的消息會被分配不同的優(yōu)先級，當網(wǎng)絡傳輸能力受限時，優(yōu)先級用來控制消息在網(wǎng)絡底層的排隊順序。
比如當客戶端網(wǎng)絡不佳時，流媒體服務器可能會選擇丟棄視頻消息，以保證音頻消息可及時送達客戶端。
Chunking allows large messages at the higher-level protocol to be
broken into smaller messages, for example to prevent large low priority
messages (such as video) from blocking smaller high-priority
messages (such as audio or control).
RTMP Chunk Stream層級允許在Message stream層次，將大消息切割成小消息，這樣可以避免大的低優(yōu)先級的消息(如視頻消息)阻塞小的高優(yōu)先級的消息(如音頻消息或控制消息)。
Protocol Control Messages
RTMP Chunk Stream uses message type IDs 1, 2, 3, 5, and 6 for
protocol control messages.
These messages contain information needed by the RTMP Chunk Stream protocol.
These protocol control messages MUST have message stream ID 0 (known as the control stream) and be sent in chunk stream ID 2.
Protocol control messages take effect as soon as they are received;
their timestamps are ignored.
Protocol Control Messages屬于RTMP Chunk Stream層級的控制消息，用于該協(xié)議的內(nèi)部控制。
User Control Messages (4)
RTMP uses message type ID 4 for User Control messages.
These messages contain information used by the RTMP streaming layer.
Protocol messages with IDs 1, 2, 3, 5, and 6 are used by the RTMP
Chunk Stream protocol (Section 5.4).
**User Control messages SHOULD use message stream ID 0 (known as the control stream) ** and, when sent over RTMP Chunk Stream, be sent on
chunk stream ID 2. User Control messages are effective at the point
they are received in the stream; their timestamps are ignored.
User Control Messages (4)是RTMP streaming layer(即Message stream層次)的消息。
- 軍令最重
協(xié)議控制消息(Protocol Control Messages)和用戶控制消息(User Control Messages)應該包含消息流ID 0(控制流）和塊流ID 2，并且有最高的發(fā)送優(yōu)先級。 - 糧草次之
數(shù)據(jù)消息(音頻信息、音頻消息)比控制信息的優(yōu)先級低。
另外，一般情況下，音頻消息比視頻數(shù)據(jù)優(yōu)先級高。
凡事好商量
發(fā)送端，在將Message切割成Chunk的過程中，是以Chunk Size(默認值128字節(jié))為基準進行切割的。
Larger chunk sizes reduce CPU usage, but also commit to larger writes that can delay other content on lower bandwidth connections. Smaller chunks are not good for high bit rate streaming.
Chunk Size越大，切割時CPU的負擔越小；但在帶寬不夠?qū)捲５沫h(huán)境下，發(fā)送比較耗時，會阻塞其他消息的發(fā)送。
Chunk Size越小，利于網(wǎng)絡發(fā)送，但服務器CPU負擔大。不適用于高碼率數(shù)據(jù)流的情況。
Chunk Size是可以實際情況進行改變的，即通過發(fā)送控制命令(Set Chunk Size)的方式進行更新。
The chunk size is configurable. It can be set using a Set Chunk Size
control message (Section 5.4.1). Chunk size is maintained independently for each direction.
Protocol control message 1, Set Chunk Size, is used to notify the
peer of a new maximum chunk size.
The maximum chunk size defaults to 128 bytes.
The maximum chunk size SHOULD be at least 128 bytes, and MUST be at
least 1 byte.
充分考慮流媒體服務器、帶寬、客戶端的情況，通過Set Chunk Size可動態(tài)的適應環(huán)境，從而達到最優(yōu)效果。
能偷懶時就偷懶
RTMP Chunk Header的長度不是固定的，分為: 12 Bytes、8 Bytes、4 Bytes、1 Byte 四種。
Chunking also allows small messages to be sent with less overhead, as
the chunk header contains a compressed representation of information
that would otherwise have to be included in the message itself.
一般情況下，msg stream id是不會變的，所以針對視頻或音頻， 除了第一個RTMP Chunk Header是12Bytes的，后續(xù)即可采用8Bytes的。
如果消息的長度(
message length)和類型(msg type id, 如視頻為9或音頻為8)又相同，即可將這兩部分也省去，RTMP Chunk Header采用4Bytes類型的。
如果當前
Chunk與之前的Chunk相比, msg stream id相同，msg type id相同，message length相同，而且都屬于同一個消息(由同一個Message切割成)，這類Chunk的時間戳(timestamp)也是相同的，故后續(xù)的也可以省去，RTMP Chunk Header采用1 Byte類型的。
當
Chunk Size足夠大時(一般不這么干)，此時所有的Message都只能相應切割成一個Chunk，該Chunk僅msg stream id相同。此時基本上除了第一個Chunk的Header是12Bytes外，其它所有Chunk的Header都是8Bytes。
香港衛(wèi)視的RTMP流:
rtmp://live.hkstv.hk.lxdns.com/live/hks就是這種情況。
可見Chunk Size很大，為
2147483650。
小結(jié)
RTMP設計的核心思想: 分塊 復用 分等級
還有一些設計思想是: 可靈活設置Chunk Size和靈活的選擇RTMP Chunk Header(實現(xiàn)壓縮的效果)。
References:
rtmp_specification_1.0.pdf
Love ZY Forever
