RTMP傳輸基本流程
發(fā)送端
- Step 1: 把數(shù)據(jù)封裝成消息(Message)。
- Step 2: 把消息分割成消息塊(Chunk, 網(wǎng)絡(luò)中實(shí)際傳輸?shù)膬?nèi)容)粗悯。
- Step 3: 將分割后的消息塊(Chunk)通過TCP協(xié)議發(fā)送出去同欠。
接收端:
- Step 1: 在通過TCP協(xié)議收到數(shù)據(jù)后, 先將消息塊重新組合成消息(Message)铺遂。
- Step 2: 通過對消息進(jìn)行解封裝處理就可以恢復(fù)出數(shù)據(jù)。
RTMP的突出優(yōu)點(diǎn)是: 延時低撤逢，正常延時1~3秒捌斧，理想的話直播可控制在1秒之內(nèi)捞蚂。
它是怎么做到的?
有什么好的設(shè)計(jì)思想?
RTMP設(shè)計(jì)思想
大而化小 輕車簡行
RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息(Message)姓迅。
在互聯(lián)網(wǎng)中傳輸數(shù)據(jù)時, 消息(Message)會被拆分成更小的單元, 稱為消息塊(Chunk).
大的Message被切割成利于在網(wǎng)絡(luò)上傳輸?shù)男hunk，個人認(rèn)為這是RTMP之所以延時低的核心原因肩杈。
切成小塊, 還可防止大的數(shù)據(jù)塊(如視頻數(shù)據(jù))阻塞小的數(shù)據(jù)塊(如音頻數(shù)據(jù)或控制信息)扩然。
本是天涯同路人 你方唱罷我登場
RTMP基于TCP協(xié)議夫偶，包括控制信息觉增、視頻數(shù)據(jù)、音頻數(shù)據(jù)都共用同一個TCP Connection说铃。
也就是說路只有一條腻扇。而且同一時間只允許一輛車通過。
生成好的視頻Chunk和音頻Chunk阳柔，依次上路蚓峦。
這就涉及到RTMP中一個非常重要的概念: 復(fù)用暑椰。
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就是復(fù)用的意思一汽，指的就是將獨(dú)立的音視頻數(shù)據(jù)整合到一個數(shù)據(jù)流低滩，讓音視頻流可以同步傳輸?shù)倪^程恕沫。
RTMP直播中，實(shí)時生成視頻Chunk和音頻Chunk鲸阔，依次加入到數(shù)據(jù)流褐筛，通過網(wǎng)絡(luò)發(fā)送到客戶端叙身。
復(fù)用在RTMP中是傳輸方式信轿，也是音視頻同步的關(guān)鍵。
事分輕重緩急 軍令最重 糧草次之
在RTMP中愧旦，消息(Message)主要分為兩大類: 控制消息和數(shù)據(jù)消息定罢。
數(shù)據(jù)消息中由包括Video 消息和Audio 消息等。
這些消息都是怎么進(jìn)行管理的呢?
有點(diǎn)像車輛的管理問題酬凳。
也就是說路遭庶，只有一條峦睡，到底誰先走呢，誰后走呢?
答案是: 分優(yōu)先級煎谍，優(yōu)先級高的先行龙屉。優(yōu)先級低的不能阻塞優(yōu)先級高的转捕。
RTMP協(xié)議可從整體分為兩個層次:
Message stream屬于應(yīng)用層次消息五芝，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)先級结蟋，當(dāng)網(wǎng)絡(luò)傳輸能力受限時嵌屎，優(yōu)先級用來控制消息在網(wǎng)絡(luò)底層的排隊(duì)順序。
比如當(dāng)客戶端網(wǎng)絡(luò)不佳時植榕，流媒體服務(wù)器可能會選擇丟棄視頻消息尊残，以保證音頻消息可及時送達(dá)客戶端。
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)應(yīng)該包含消息流ID 0(控制流）和塊流ID 2戚绕，并且有最高的發(fā)送優(yōu)先級舞丛。 - 糧草次之
數(shù)據(jù)消息(音頻信息果漾、音頻消息)比控制信息的優(yōu)先級低绒障。
另外，一般情況下鸵钝，音頻消息比視頻數(shù)據(jù)優(yōu)先級高恩商。
凡事好商量
發(fā)送端必逆，在將Message切割成Chunk的過程中，是以Chunk Size(默認(rèn)值128字節(jié))為基準(zhǔn)進(jìn)行切割的锤窑。
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的負(fù)擔(dān)越猩暌佟哗讥；但在帶寬不夠?qū)捲５沫h(huán)境下，發(fā)送比較耗時魏宽，會阻塞其他消息的發(fā)送队询。
Chunk Size越小构诚，利于網(wǎng)絡(luò)發(fā)送范嘱，但服務(wù)器CPU負(fù)擔(dān)大。不適用于高碼率數(shù)據(jù)流的情況叠聋。
Chunk Size是可以實(shí)際情況進(jìn)行改變的盏阶，即通過發(fā)送控制命令(Set Chunk Size)的方式進(jìn)行更新名斟。
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.
充分考慮流媒體服務(wù)器砰盐、帶寬、客戶端的情況囊骤，通過Set Chunk Size可動態(tài)的適應(yīng)環(huán)境也物，從而達(dá)到最優(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類型的棘幸。
如果當(dāng)前
Chunk與之前的Chunk相比, msg stream id相同，msg type id相同倦零，message length相同误续，而且都屬于同一個消息(由同一個Message切割成)，這類Chunk的時間戳(timestamp)也是相同的扫茅，故后續(xù)的也可以省去蹋嵌，RTMP Chunk Header采用1 Byte類型的。
當(dāng)
Chunk Size足夠大時(一般不這么干)葫隙，此時所有的Message都只能相應(yīng)切割成一個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設(shè)計(jì)的核心思想: 分塊 復(fù)用 分等級
還有一些設(shè)計(jì)思想是: 可靈活設(shè)置Chunk Size和靈活的選擇RTMP Chunk Header(實(shí)現(xiàn)壓縮的效果)。
References:
rtmp_specification_1.0.pdf
Love ZY Forever
