WebRTC Native M96 H264打包方式解读--kH264SingleNalu、kH264StapA、kH264FuA

最新推荐文章于 2023-08-19 12:07:39 发布

一苇渡江694

最新推荐文章于 2023-08-19 12:07:39 发布

阅读量5.9k

点赞数

分类专栏： WebRTC Native M96 Cookbook 文章标签： webrtc

本文链接：https://blog.csdn.net/wangshubo1989/article/details/125285116

版权

WebRTC Native M96 Cookbook 专栏收录该内容

48 篇文章 38 订阅 ¥79.90 ¥99.00

订阅专栏

超级会员免费看

本文深入解析WebRTC中H264在RTP包中的打包方式，包括单个NAL单元包、STAP-A聚合包和FU-A分片单元，详细解释了RTP包头结构及NAL单元类型。通过VideoCodec::SetDefaultParameters设置RTP发包模式。

摘要由CSDN通过智能技术生成

在<WebRTC Native M96视频基础知识介绍–使用H264>中介绍了WebRTC中H264的相关知识，这边不再啰嗦。

抓了一个rtp的包：
在这里插入图片描述

90 60 7c 5d 11 ec 77 4d 4f 20 e6 05 be de 00 02
22 72 28 f6 31 00 01 00 7b fa d5 4c 16 f0 11 13  
43 9b 32 09 a5 26 7e 60 bd f2 fb 5c 52 b2 29 40
e1 62 00 5c 27 49 3c 55 33

RTP包header

在这里插入图片描述

V：RTP协议的版本号，占2位，当前协议版本号为2
Version: (2 bits) Indicates the version of t

了解本专栏

订阅专栏解锁全文

超级会员免费看

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

一苇渡江694

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录

订阅专栏

WebRTC Native M96视频基础知识介绍--使用H264

一蓑烟雨任平生也无风雨也无晴

04-27

1万+

名词解释视频泛指将动态影像以电信号方式加以捕捉、纪录、处理、存储、发送与重现的各种技术。视频格式视频是现在电脑中多媒体系统中的重要一环。为了适应储存视频的需要，人们设定了不同的视频文件格式以将视频和音频放在一个文件中，以方便同时播出。什么3gp、mp4、avi啊，这些视频格式，从中学时代就有听说。首先，MP4、AVI、MKV都是本地视频文件的后缀，在windows系统下，用于提示操作系统应该采用哪个应用程序打开。而在流媒体领域，这些都被称为『视频封装格式』视频协议是针对网络流媒体而言的，也

WebRTC Native M96 SDK接口封装--注册语音观测器对象获取原始音频数据registerAudioFrameObserver

一蓑烟雨任平生也无风雨也无晴

12-07

7055

很多时候，上层app需要获取RTC中的音频数据，比如获取RTC麦克风采集的裸数据、扬声器播放的混音之后的裸数据，再比如麦克风和扬声器混音后的裸数据等等。在实时音视频中，用户可以对采集到的音频数据进行前处理和后处理，获取自己想要的播放效果，例如变音、录音等等。那么就需要上层APP向RTC SDK注册一个观测器，也就是我们所说的callback，订阅音频数据输出该方法用于注册音频观测器对象，即注册回调。当需要 SDK 给出 onMixedAudioFrame、onRecordAudioFrame、onPlay

参与评论您还未登录，请先登录后发表或查看评论

解析RTP头

sunshineywz的博客

09-23

1343

else if (buf[pos] == 0x03 && buf[pos + 1] == 0x00) { if(len >= dataLen-4) { continue; } //ret = buf[pos + 2] << 8; //ret += buf[pos + 3]; ret = buf[pos + 2] + (buf[pos + 3...

rtp头解析

occupy8的专栏

07-27

3316

The following figure shows the RTP header structure - version (V): 2 bits This field identifies the version of RTP. The version is 2 upto RFC 1889.padding (P): 1 bit If the padding bit

RTP头结构解析

weixin_33858485的博客

04-02

486

RTP包头前12个固定字节机构图： 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

RTP头格式

bryanj的专栏

05-14

759

详细见RFC3550 5.1节，这部分只是对RTP头格式的一些翻译和总结（图片来自JMF 2.0 API Guide）前12个字节在每一个RTP packet中都存在，而一系列的CSRC标记只有存在Mixer时才有。 version (V): 2 bits 标明RTP版本号。协议初始版本为0，RFC3550中规定的版本号为2。 padd

RTP头解析、RTP头部创建

最新发布

u012836015的博客

08-19

1707

RTP头部协议，前12位为基础字节，对应第一个结构体，如果extension为1时候，才有外部扩展信息，外部扩展信息结构对应第二个结构体，分别对应profile、length、data。PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。1.V：RTP协议的版本号，占2位，当前协议版本号为2。

WebRTC Native M96 SDK接口封装--startAudioMixing播放音乐文件与麦克风采集声音混音

一蓑烟雨任平生也无风雨也无晴

02-22

5259

封装接口使用WebRTC大概有两种方式，一种是把WebRTC当做一种库来用；另一种是把WebRTC当做一个框架，自己在上层封装代码。不管怎么，做实时音视频SDK开发的，都需要封装接口，供给上层应用调用。在国内，声网的用户比较多，社区做的也比较好，所以很多公司的RTC SDK的接口设计都会仿造声网。这样做有很多的好处：不用自己写demo，直接使用agora的openlive。便于跟agora对标，向agora看齐，无论是产品功能上，还是音视频质量上。对于上层接入来说，如果做到接口一样，那么不管

WebRTC Native M96音频基础知识介绍--使用Opus

一蓑烟雨任平生也无风雨也无晴

04-26

3873

声波声音是振动产生的声波，通过介质（气体、固体、液体）传播并能被人或动物听觉器官所感知的波动现象。声音的特性可由三个要素来描述，即响度、音调和音色音频（音调）音调就是音频。物理学中用每秒内振动的次数–频率来描述物体振动的快慢。物体振动的快（即频率高）则音调高，物体振动的慢（及频率低）则音调低。声音的频率一般会以赫兹表示，记为Hz，指每秒钟周期性震动的次数音量（响度）响度就是声音的大小强弱。取决于物体振动的幅度分贝是用来表示声音强度的单位，记为dB。数字音频数字音频是指使用脉冲编码调制、.

WebRTC Native M96 视频发送编码(OpenH264)流程以及接收视频包解码(FFmpeg)播放流程

一蓑烟雨任平生也无风雨也无晴

02-18

3183

H264 和 OpenH264 H.264，又称为MPEG-4第10部分，高级视频编码（英语：MPEG-4 Part 10, Advanced Video Coding，缩写为MPEG-4 AVC）是一种面向块，基于运动补偿的视频编码标准。到2014年，它已经成为高精度视频录制、压缩和发布的最常用格式之一。第一版标准的最终草案于2003年5月完成。 H.264/AVC项目的目的是为了创建一个更佳的视频压缩标准，在更低的比特率的情况下依然能够提供良好视频质量的标准（如，一半或者更少于MPEG-2,H.263

纯C语言解析RTP包的头部

YIZIMU的博客

03-28

1126

2、填充位（P）：占1位，如果P=1，则该RTP包的尾部包含附加的填充字节。3、作用是为了字节对齐，填充字节的数量保存在最后一个字节中 4、扩展位（X）：占1位，如果X=1，则RTP固定头部后面就跟有一个扩展头部，即上面的CSRC信息 5、CSRC计数器（CC）：占4位，指示 CSRC标识符的数量。6、载荷类型（PT）：占7位，标识了RTP载荷的类型，比如是视频还是音频类型 7、序列号（SN）：占16位，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。

RTP协议全解析（H264码流和PS流）

热门推荐

对牛乱弹琴

09-12

26万+

1RTP Header解析 2、RTP荷载H264码流 2.1、单个NAL单元包 2.2、分片单元（FU-A） 3、RTP荷载PS流 3.1、PS包头 3.2、系统标题 3.3、节目映射流 3.4、PES分组头部

RTP报文头部分析

01-02

2万+

RTP报文格式 RTP报文由两部分组成：报头和有效载荷。RTP报头格式如下图所示，其中： l V：RTP协议的版本号，占2位，当前协议版本号为2。 l P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 l X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 l CC：CSRC计数器，占4位，指示

rtp报文头

qq_43559669的博客

12-28

625

rtp模拟了tcp的一些东西。tcp和rtp都有sequence，都可以通过sequence number对包进行排序，但是和tcp的不同点是rtp每个包加1，第一个包是1，第二个包是2，一直加1，是按包来的，而不是按字节来的，tcp是按字节来的，tcp是流式的。同一帧数据，被拆包了，timestamp是一样的。多方通信的时候，每一个发送者都有一个ssrc，不能冲突，如果两个发送源ssrc一致，可以协商再分配。 csrc相当于是混音或者混源，有好几个ssrc PT是payload type，标识这个r.

RTP协议头详解

yuxiang1014的专栏

09-12

4293

1.RTP协议 RTP：即可心跑在TCP也可以跑在UDP上，实时流协议，所以通常是跑在UDP上。前 12 个字节出现在每个 RTP 包中，仅仅在被混合器插入时，才出现 CSRC 识别符列表。各个域的含义如下所示：（1）版本(V)：2 比特，此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用,值 0 用在最初"vat"语音工具使用的协议中。) （2）填充(P)：1 比特，若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填

RTP协议以及头部实现

m0_55875295的博客

10-05

512

类似TCP 是二进制协议最重要的是内容成分组成（嵌套式）和位宽 RTP包有一个头部和数据荷载/负载组成头部格式： V P X CC M PT 序列号时间戳 ...

rtp头部的完整解释---Wikipedia

码夫的专栏

03-07

2698

http://en.wikipedia.org/wiki/Real-time_Transport_Protocol bit offset0-1234-789-1516-310Ver.PXCCMPTSequence Number32Timestamp64SSRC identif

rtp头结构

11-26

1260

V P X CC M PT sequence number Timestamp SSRC CSRC 注： V 2 bit 版本. P 1 bit 填充标志，包的后面是否跟有一些填充字节。一般为0。 X 1 bit 后面是否跟扩展头。跟在CSRC的后面。扩展头用于存储用户的私有信息。一般为0。 CC 4 bit C