rtmp和http flv协议总结

Dear 丶 2022-10-06 15:57 165阅读 0赞

一般来说我们总是将rtmp和http放在一起，一方面是因为他们都是采用tcp，另一方面它们的数据包都是互通的，一般来说，我们常见的服务器为如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzM2MDcwNw_size_16_color_FFFFFF_t_70]  
rtmp 可以传输三种方式的流，http为一种flv，我个人觉得rtmp主要是为了支持flash和webH5所以就兼容的flv和MP4,http就不用说了，b站转型找的一种兼容方案。

其实如果我们单纯的想要web播放，如果是自己开发webh5播放器，我觉得http采用h264更加好，反正就是将demux放在服务端还是客户端的事情。

以下为参考文档：

fmp4，是适应于现代浏览器的一种流媒体格式。和mp4格式不同的是，以往的mp4格式化也分为header信息和payload信息，一个大的mp4就会有一个很大的头信息，不适合与现在的网络环境。所以新的fmp4格式就出现了，fmp4格式有一个带了metadata的头片段，及后面一序列的fragment，每个fragment都有各自的header信息，这样就把header信息也分成了一个个小的片段，更适合现在的应用场景。所以fmp4格式也就是用于MediaSource对象的SourceBuffer的格式，通过一个initSegment和一序列的segment塞给MediaSource对象来播放。

直播，类似于新闻联播，视频流在网络上，只要终端接收流就从那一刻开始  
点播，类似于重播，编辑好的视频文件，被观众任意观看，每次都从头播放  
直播平台，国内最大的有yy、战旗、斗鱼tv、龙珠，新技术流“全民直播”全球首个实现了手机作为直播源的一键直播  
点播平台，优酷、土豆、百度视频、腾讯视频

视频点播  
服务端存放多个视频文件，客户端可通过网路点播客户端任意观看其中一个视频，并可拖动进度进行观看

视频直播  
服务端实时发送直播来源（如系统桌面、摄像头）的数据流，客户端通过支持流媒体协议的播放器实时播放同样的内容，不可拖动进度

> 参考：  
> MP4首先不能够像h264 es流进行直播，需要先mux成mp4然后点播。  
> 其次，mp4的类real-time传送方法，需要再mp4本地格式码流中加入hint track。mp4creator  
> ffmpeg都可以加入，这个过程的名词叫mp4流媒体化，只有流媒体化过的mp4才可以在网络间实时传送。  
> 你应该先学习学习mp4格式，不仅是本地格式，要学习流的格式。  
> 一、关于chrome的快速播放和拖拽

1、chrome使用H5的video标签来播放

2、chrome很智能，如果读取MP4文件，发现moov box不在文件前部，会直接读取MP4的文件尾部，加载moov box

3、拖拽时，chrome根据moov box得到的关键帧的字节偏移量，采用range请求来请求

4、Flash如果读取MP4文件，发现moov box不在文件前部，不会直接读取MP4的文件尾部去寻找moov box，所以Flash要等文件全部下载完，取到文件尾部的moov头，才可以正常播放。

一般来说，如果边下载边播放就需要moov前置。

1，RTMP协议  
（1）是流媒体协议。  
（2）RTMP协议是 Adobe 的私有协议，未完全公开。  
（3）RTMP协议一般传输的是 flv，f4v 格式流。  
（4）RTMP一般在 TCP 1个通道上传输命令和数据。

2，RTSP协议  
（1）是流媒体协议。  
（2）RTSP协议是共有协议，并有专门机构做维护。.  
（3）RTSP协议一般传输的是 ts、mp4 格式的流。  
（4）RTSP传输一般需要 2-3 个通道，命令和数据通道分离。

3，HTTP协议  
（1）不是是流媒体协议。  
（2）HTTP协议是共有协议，并有专门机构做维护。

（3）HTTP协议没有特定的传输流。  
（4）HTTP传输一般需要 2-3 个通道，命令和数据通道分离。

在最后着重讲一下视频消息的chunk

协议层                封装层
        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
        |RTMP Chunk Header | FLV VideoTagHeader | FLV VideoTagBody |     
        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

在实际发送的过程中我们并不发送 FLV VideoTagHeader，为什么呢？我们来看 FLV VideoTagHeader数据：  
FLv Tag Header结构占用11个字节：

第1个字节表示Tag类型，包括音频（0x08）、视频（0x09）和script data（0x12），其他类型值被保留。  即为0x09
    
    第2-4字节为UI24类型的值，表示该Tag Data部分的大小。 即为0x1E=30
    
    第5-7字节为UI24类型的值，表示该Tag的时间戳（单位为ms），第一个Tag的时间戳总是0。即为0x53=83，此时间戳表示解码时间！！！
    
    第8个字节为时间戳的扩展字节，当24位数值不够时，该字节作为最高位将时间戳扩展为32位值。  即为0x00
    
    第9-11字节为UI24类型的值，表示stream id，总是0. 即为0x00

class FlvTagHeader { 
    public:
        uint8_t type = 0;
        uint8_t data_size[3] = { 0};
        uint8_t timestamp[3] = { 0};
        uint8_t timestamp_ex = 0;
        uint8_t streamid[3] = { 0}; /* Always 0. */
    }PACKED;

关于flv 参考：https://my.oschina.net/u/2326611/blog/679702

这些数据跟chunk中的chunk Msg Header 相同

Basic header + Chunk Msg Header
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | format | chunk stream id | timestamp | message length | msg type id | msg stream id |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            2 bits      6 bits        3 bytes       3 bytes         1 bytes        4 bytes

class ChunkMsgHeader { 
    public:
        uint8_t flags;
        uint8_t time_stamp[3];
        uint8_t body_size[3];
        uint8_t type_id;
        uint8_t stream_index[4]; /* Note, this is little-endian while others are BE */
    }PACKED;

所以chunkMsgHeader就可以替代FlvTagHeader

关于rtmp参考：https://segmentfault.com/a/1190000018582618

总结：所以有同学问rtmp传输的时候到底传输视频的时候是不是首先将h264组包为flv格式，然后再组包chunk，实际上是不用的，直接将chunk Msg Header组包就可以。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzM2MDcwNw_size_16_color_FFFFFF_t_70]: /images/20221005/6a4a5226f3a54d3d8379d7ecd352ca58.png