前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >手撕Rtmp协议细节(11)——videoData

手撕Rtmp协议细节(11)——videoData

作者头像
视界音你而不同
发布2020-05-26 16:23:12
2.3K0
发布2020-05-26 16:23:12
举报

上一篇我们看了rtmp audio的数据结构,这一篇我们来一起看一看rtmp video的数据结构。

老规矩,先上一个video数据的抓包文件,有个直观的感受。

通过抓包文件,我们可以看到,熟悉的Rtmp Header + Rtmp Body的组织结构,Body中打包的是经过压缩的视频数据。Body中打包视频数据的方式也与音频类似。首先用一个字节表示视频数据的header,之后是压缩后的视频数据(压缩后的数据是使用FLV的标准进行封装的)。

我们来看一下videoData中的header部分的组织结构:

相比音频比较简单,1个字节,高4位表示视频帧类型,低4位表示codecID。

帧类型:

表示该帧视频是关键帧还是非关键帧。可选值如下:

类型

说明

1

key frame

H264的关键帧,包括IDR

2

inter frame

H264的非关键帧

3

disposable inter frame

只针对H263

4

generated keyframe

5

video info/command frame

这么多值,当前主要用的无非就是1和2,即H264的关键帧和非关键帧,其他类型当下几乎见不到了。

codecID:

表示该帧的数据编码codecID。可选值如下:

类型

说明

1

JPEG

2

Sorenson H.263

3

Screen Video

4

On2 VP6

5

On2 VP6 with alpha channel

6

Screen video version2

7

AVC

H264

对于codecID,其实我们主要关注AVC即可,它代表的是H264编码。

接下来,我们看一个具体的例子:

可以看出videoData中Body中,第一个字节为0x17,二进制为:0001 0111。所以type=0001=1,codec_id=0111=7,所以表示该视频数据采用H264编码,该帧是关键帧,这一点,wireshark也有所体现。

在头信息之后,就是具体的压缩后的视频编码数据,不过基于FLV的格式对视频数据做了封装,这里就不展开了。

我们再看一个非关键帧的抓包:

我们可以看到,只是帧类型变成了2,codecID依然是7,代表H264。

好了,这一篇介绍完,关于rtmp协议的交互流程我们也介绍完毕了,这一遍走完,我们对rtmp有了基本的了解,知道了其基本的协议交互流程,以及其数据封装的格式。了解一个协议,核心就是掌握其数据组织格式以及协议交互流程,通过这一系列的文章,相信我们可以对rtmp做到心中有数。

结语

写到这一篇,关于rtmp协议的专题也就告一段落了,希望对各位有所帮助

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-05-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 视界音你而不同 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
文件存储
文件存储(Cloud File Storage,CFS)为您提供安全可靠、可扩展的共享文件存储服务。文件存储可与腾讯云服务器、容器服务、批量计算等服务搭配使用,为多个计算节点提供容量和性能可弹性扩展的高性能共享存储。腾讯云文件存储的管理界面简单、易使用,可实现对现有应用的无缝集成;按实际用量付费,为您节约成本,简化 IT 运维工作。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档