视频直播源码开发中的流媒体协议:rtmp协议

本文涉及的产品
视频直播,500GB 1个月
简介: 视频直播源码的RTMP协议从属于应用层,被设计用来在适合的传输协议(如TCP)上复用和打包多媒体传输流(如音频、视频和互动内容)。RTMP提供了一套全双工的可靠的多路复用消息服务,类似于TCP协议[RFC0793],用来在一对结点之间并行传输带时间戳的音频流,视频流,数据流。通常情况下,不同类型的消息会被分配不同的优先级,当网络传输能力受限时,优先级用来控制消息在网络底层的排队顺序。

一、概念与摘要
视频直播源码的RTMP协议从属于应用层,被设计用来在适合的传输协议(如TCP)上复用和打包多媒体传输流(如音频、视频和互动内容)。RTMP提供了一套全双工的可靠的多路复用消息服务,类似于TCP协议[RFC0793],用来在一对结点之间并行传输带时间戳的音频流,视频流,数据流。通常情况下,不同类型的消息会被分配不同的优先级,当网络传输能力受限时,优先级用来控制消息在网络底层的排队顺序。

二、RTMP块流
视频直播源码的实时消息传递协议块流(RTMP块流)。它作为一款高级多媒体流协议提供了流的多路复用和打包服务。RTMP块流被设计用来传输实时消息协议,它可以使用任何协议来发送消息流。每个消息都包含时间戳和有效类型标识。RTMP块流和RTMP适用于各种视听传播的应用程序,包括一对一的,和一对多的视频直播、点播服务、互动会议应用程序。

当使用一个可靠的传输协议如TCP[RFC0793]时,RTMP块流提供了一种可以在多个流中,基于时间戳的端到端交付所有消息的方法。RTMP块流不提供任何优先级或类似形式的控制,但可以使用更高级别的协议来提供这样的优先级。例如,一个视频服务器可以根据发送的时间或确认每个消息的时间,来决定为一个网络差的用户丢弃视频信息,以确保音频信息的及时接收。

RTMP块流不仅包含了自己的协议控制信息,同时也提供了一个更高级别的协议机制,用来嵌入用户控制信息。

消息格式
视频直播源码的消息格式可以被分割成多个块,用来在更高的协议中支持多路复用。在创建块消息格式时,应该包含以下字段:

时间戳
消息的时间戳。这个字段占用4字节。

长度
消息的有效长度。如果消息头不能被忽略,它应该包括长度。这个字段在块头中占用3字节。

类型ID
各种类型的协议控制消息的ID。这些消息使用RTMP块流协议和更高级别的协议来传输信息。所有其他类型的ID可以用在高级协议,这对于RTMP块流来说,是不透明的。事实上,RTMP块流中没有要求使用这些值作为类型;所有(无协议的)消息可能是相同的类型,或者应用程序使用这个字段来区分多个连接,而不是类型。这个字段在块头中占用1字节。

消息流ID
消息流ID可以是任意值。当同一个块流被复用到不同的消息流中时,可以通过消息流ID来区分它们。另外,对于RTMP块流而言,这是一个不透明值。该字段占用4字节,使用小端序。

握手
RTMP连接从握手开始。它包含三个固定大小的块,不像其他的协议,是由头部大小可变的块组成的。

客户端(初始化连接的一端)和服务端发送同样的三个块。为了方便描述,客户端发送的三个块命名为C0,C1,C2;服务端发送的三个块命名为S0,S1,S2。  

握手序列

客户端通过发送C0和C1消息来启动握手过程。客户端必须接收到S1消息,然后发送C2消息。客户端必须接收到S2消息,然后发送其他数据。

服务端必须接收到C0或者C1消息,然后发送S0和S1消息。服务端必须接收到C1消息,然后发送S2消息。服务端必须接收到C2消息,然后发送其他数据。

C0和S0格式

C0和S0包由一个字节组成,下面是C0/S0包内的字段:

1

2

3

4

5

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|   version     |

+-+-+-+-+-+-+-+-+

 C0 and S0 bits

版本(8比特)
在C0包内,这个字段代表客户端请求的RTMP版本号。在S0包内,这个字段代表服务端选择的RTMP版本号。此文档使用的版本是3。版本0-2用在早期的产品中,现在已经被弃用;版本4-31被预留用于后续产品;版本32-255(为了区分RTMP协议和文本协议,文本协议通常以可打印字符开始)不允许使用。如果服务器无法识别客户端的版本号,应该回复版本3。客户端可以选择降低到版本3,或者中止握手过程。

C1和S1格式

C1和S1包长度为1536字节,包含以下字段:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        time (4 bytes)                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        zero (4 bytes)                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        random bytes                           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                         random bytes                          |

|                            (cont)                             |

|                             ....                              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         C1 and S1 bits

时间(4字节)
本字段包含一个时间戳,客户端应该使用此字段来标识所有流块的时刻。时间戳取值可以为零或其他任意值。为了同步多个块流,客户端可能希望多个块流使用相同的时间戳。

零(4字节)
本字段必须为零。

随机数据(1528字节)
本字段可以包含任意数据。由于握手的双方需要区分另一端,此字段填充的数据必须足够随机(以防止与其他握手端混淆)。不过没必要为此使用加密数据或动态数据。

C2和S2格式

C2和S2包长度为1536字节,作为C1和S1的回应,包含以下字段:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        time (4 bytes)                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       time2 (4 bytes)                         |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        random echo                            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                         random echo                           |

|                            (cont)                             |

|                             ....                              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         C2 and S2 bits

时间(4字节)
本字段必须包含对端发送的时间戳。

时间(4字节)
本字段必须包含时间戳,取值为接收对端发送过来的握手包的时刻。

随机数据(1528字节)
本字段必须包含对端发送过来的随机数据。握手的双方可以使用时间1和时间2字段来估算网络连接的带宽和/或延迟,但是不一定有用。

三、RMTP握手

握手过程示意图
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

+-------------+                           +-------------+

|    Client   |       TCP/IP Network      |    Server   |

+-------------+            |              +-------------+

      |                    |                     |

Uninitialized              |               Uninitialized

      |          C0        |                     |

      |------------------->|         C0          |

      |                    |-------------------->|

      |          C1        |                     |

      |------------------->|         S0          |

      |                    |<--------------------|

      |                    |         S1          |

 Version sent              |<--------------------|

      |          S0        |                     |

      |<-------------------|                     |

      |          S1        |                     |

      |<-------------------|                Version sent

      |                    |         C1          |

      |                    |-------------------->|

      |          C2        |                     |

      |------------------->|         S2          |

      |                    |<--------------------|

   Ack sent                |                  Ack Sent

      |          S2        |                     |

      |<-------------------|                     |

      |                    |         C2          |

      |                    |-------------------->|

 Handshake Done            |               Handshake Done

      |                    |                     |

          Pictorial Representation of Handshake

                     握手示意图

下面是握手示意图中提到的状态:

未初始化
协议版本号在此阶段发送。客户端和服务器均处于未初始化状态。客户端发送携带协议版本号的C0包。如果服务器支持此版本,回复S0和S1包。如果服务器不支持此版本,使用适当的动作回复。在RTMP协议中,此动作是中止连接。
注: 在”C0和S0格式”章节中提及,如果服务器不支持客户端的版本号,可以选择降到版本3或中止。

发送版本
视频直播源码客户端和服务器双方在未初始化状态后,会进入发送版本状态。之后,视频直播源码客户端等待S1包,服务器等待C1包。待接收到数据包,视频直播源码客户端发送C2包,服务器发送S2包。然后,双方都进入答复状态。客户端等待C2的答复,服务器等待S2的答复。

握手完成
视频直播源码客户端和服务器交换消息。

本文转载自网络,感谢原作者的分享,转载仅为分享干货知识,如有侵权欢迎联系作者进行删除处理。

相关文章
|
应用服务中间件 视频直播 Linux
windows下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
windows下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
2856 0
windows下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
|
1月前
|
缓存 视频直播 Linux
FFmpeg开发笔记(四十三)使用SRS开启SRT协议的视频直播服务
《FFmpeg开发实战》书中介绍了轻量级流媒体服务器MediaMTX,适合测试但不适用于生产环境。SRS是一款国产开源服务器,支持RTMP、SRT等协议,适合生产使用。要启用SRS的SRT推流,需配置`srt.conf`,开启SRT服务并配置端口。在确保FFmpeg集成libsrt后,拉流则使用类似但带有`m=request`的地址。在Windows上,同样需要集成libsrt的FFmpeg来使用ffplay拉流。SRS的日志确认了推拉流的成功。书中提供更深入的FFmpeg开发知识。
73 2
FFmpeg开发笔记(四十三)使用SRS开启SRT协议的视频直播服务
|
缓存 网络协议 应用服务中间件
Linux下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
Linux下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
1021 0
Linux下使用Nginx搭建Rtmp流媒体服务器,实现视频直播功能
|
视频直播
视频直播源码技术知识分享:连麦功能(一)
我们开发视频直播平台就要去了解视频直播开发相关功能知识,这对我们开发平台有着重要的作用,连麦技术就是视频直播源码重要的技术功能之一,每一个功能技术都有自己的用武之地
视频直播源码技术知识分享:连麦功能(一)
|
视频直播
详解!视频直播源码平台搭建开发:录制功能
视频直播源码平台的录制功能能够为用户提供更多方便、灵活性,同时也增加了直播内容的传播和价值,这也使录制功能成为布谷科技视频直播源码平台的必备功能之一。
详解!视频直播源码平台搭建开发:录制功能
|
编解码 iOS开发 流计算
调用Live555接收RTSP直播流,转换为Http Live Streaming(iOS直播)协议
调用Live555接收RTSP直播流,转换为Http Live Streaming(iOS直播)协议
454 1
|
视频直播 定位技术 UED
海外视频直播源码技术视频直播间的搭建
大家听到这里是不是感觉这个源码平台非常的熟悉,没错,这个源码平台就海外视频直播源码平台,而我说的这个房间就是视频直播间,主持人就是视频直播间内的主播,今天我就为大家分享海外视频直播源码技术视频直播间的搭建。
海外视频直播源码技术视频直播间的搭建
|
域名解析 网络协议 安全
Live555源码阅读笔记(四):groupsock 目录详解
Live555源码阅读笔记(四):groupsock 目录详解
296 0
Live555源码阅读笔记(四):groupsock 目录详解
|
存储 调度
Live555源码阅读笔记(三):BasicUsageEnvironment 目录详解-BasicTaskScheduler、DelayQueue、HandlerSet
Live555源码阅读笔记(三):BasicUsageEnvironment 目录详解-BasicTaskScheduler、DelayQueue、HandlerSet
149 0
Live555源码阅读笔记(三):BasicUsageEnvironment 目录详解-BasicTaskScheduler、DelayQueue、HandlerSet
|
调度 C++
Live555源码阅读笔记(二):UsageEnvironment 目录详解
Live555源码阅读笔记(二):UsageEnvironment 目录详解
140 0
Live555源码阅读笔记(二):UsageEnvironment 目录详解