【基于libRTMP的流媒体直播之 AAC、H264 推送】

简介:

        这段时间在捣腾基于 RTMP 协议的流媒体直播框架,其间参考了众多博主的文章,剩下一些细节问题自行琢磨也算摸索出个门道,现将自己认为比较恼人的 AAC 音频帧的推送和解析、H264 码流的推送和解析以及网上没说清楚的地方分享给各位。

        RTMP 协议栈的实现,Bill 直接使用的 libRTMP,关于 libRTMP 的编译、基本使用方法,以及简单的流媒体直播框架,请参见博文[C++实现RTMP协议发送H.264编码及AAC编码的音视频],言简意赅,故不再赘述。

        言归正传,我们首先来看看 AAC 以及 H264 的推送。

        不论向 RTMP 服务器推送音频还是视频,都需要按照 FLV 的格式进行封包。因此,在我们向服务器推送第一个AAC 或 H264 数据包之前,需要首先推送一个音频 Tag [AAC Sequence Header] 以下简称“音频同步包”,或者视频 Tag [AVC Sequence Header] 以下简称“视频同步包”。


AAC 音频帧的推送                                         

        我们首先来看看音频 Tag,根据 FLV 标准 Audio Tags 一节的描述:

wKioL1Qje6_ApXbFAALZEhnUQhw347.jpg

wKioL1Qje7CzZWgCAADA_wp5OpM894.jpg

wKiom1QjjFvDUS-PAADRrM6v_UU397.jpg

        我们可以将其简化并得到 AAC 音频同步包的格式如下:

wKiom1Qj3lqRKafiAAKNXyQMvTU565.jpg

        音频同步包大小固定为 4 个字节。前两个字节被称为 [AACDecoderSpecificInfo],用于描述这个音频包应当如何被解析。后两个字节称为 [AudioSpecificConfig],更加详细的指定了音频格式。

        [AACDecoderSpecificInfo] 俩字节可以直接使用 FAAC 库的 faacEncGetDecoderSpecificInfo 函数来获取,也可以根据自己的音频源进行计算。一般情况下,双声道,44kHz 采样率的 AAC 音频,其值为 0xAF00,示例代码:

wKioL1QjvBOTgyzaAAGVe-V9kmI359.jpg

        根据 FLV 标准 不难得知,[AACDecoderSpecificInfo] 第 个字节高 位 |1010| 代表音频数据编码类型为 AAC,接下来  |11| 表示采样率为 44kHz,接下来 1 位 |1| 表示采样点位数 16bit,最低  |1| 表示双声道。其第二个字节表示数据包类型,0 则为 AAC 音频同步包,1 则为普通 AAC 数据包。

        音频同步包的后两个字节 [AudioSpecificConfig] 的结构,援引其他博主图如下:

wKioL1QiuO7zrhUwAAJxI9ZTnCM355.jpg

        我们只需参照上述结构计算出对应的值即可。至此,个字节的音频同步包组装完毕,便可推送至 RTMP 服务器,示例代码如下:

wKiom1Qjwf_AhpYBAALewqMU8R4358.jpg

        网上有博主说音频采样率小于等于 44100 时 SamplingFrequencyIndex 应当选择 3(48kHz)Bill 测试发现采样率等于 44100 时设置标记为 3 或 均能正常推送并在客户端播放,不过我们还是应当按照标准规定的行事,故此处的 SamplingFrequencyIndex 选 4

        完成音频同步包的推送后,我们便可向服务器推送普通的 AAC 数据包,推送数据包时,[AACDecoderSpecificInfo] 则变为 0xAF01,向服务器说明这个包是普通 AAC 数据包。后面的数据为 AAC 原始数据去掉前 个字节(若存在 CRC 校验,则去掉前 个字节),我们同样以一张简化的表格加以阐释:

wKiom1Qj3mqCw5lHAAIa-4cP-8I493.jpg

        推送普通 AAC 数据包的示例代码:

wKioL1QjwrvxaltsAAK8YUN-Lxc350.jpg

        至此,我们便完成了 AAC 音频的推送流程。此时可尝试使用 VLC 或其他支持 RTMP 协议的播放器连接到服务器测试正在直播的 AAC 音频流。     



H264 码流的推送                                           

        前面提到过,向 RTMP 服务器发送 H264 码流,需要按照 FLV 格式进行封包,并且首先需要发送视频同步包[AVC Sequence Header]。我们依旧先阅读 FLV 标准 Video Tags 一节:

wKioL1QjxnHgHEnEAAKJgSNqtus964.jpg

wKiom1QjxgTxHxcGAAHIvqsTyqY918.jpg

        由于视频同步包前半部分比较简单易懂,仔细阅读上述标准便可明白如何操作,故 Bill 不另作图阐释。由上图可知,我们的视频同步包 FrameType == 1CodecID == 7VideoData == AVCVIDEOPACKET,继续展开 AVCVIDEOPACKET,我们可以得到 AVCPacketType == 0x00CompositionTime == 0x000000Data == AVCDecoderConfigurationRecord

        因此构造视频同步包的关键点便是构造 AVCDecoderConfigurationRecord。同样,我们援引其他博主的图片来阐释这个结构的细节:

wKiom1QjyPqD1WfpAAL6V06Ylu8204.jpg

        其中需要额外计算的是 H264 码流的 Sps 以及 Pps,这两个关键数据可以在开始编码 H264 的时候提取出来并加以保存,在需要时直接使用即可。具体做法请读者自行 Google 或参见 参考博文[2],在此不再赘述。

        当我们得到本次 H264 码流的 Sps 以及 Pps 的相关信息后,我们便可以完成视频同步包的组装,示例代码如下:

wKiom1Qjzaaji__hAAKucP6fUmk422.jpg

wKioL1Qj2FiScNksAAL966Ultw0411.jpg


        至此,视频同步包便构造完毕并推送给 RTMP 服务器。接下来只需要将普通 H264 码流稍加封装便可实现 H264 直播,下面我们来看一下普通视频包的组装过程。

        回顾 FLV 标准 的 Video Tags 一节,我们可以得到 H264 普通数据包的封包信息,FrameType == H264 I ? 1 : 2),CodecID == 7VideoData == AVCVIDEOPACKET,继续展开,我们可以得到  AVCPacketType == 0x01CompositionTime 此处仍然设置为 0x000000,具体原因 TODO(billhoo)Data == H264 NALU Size + NALU Raw Data

        构造视频数据包的示例代码如下:

wKiom1Qj2_XiM6C9AAHC8RxCixU908.jpg

wKioL1Qj3Brwx8vTAAF2JsPqjeg495.jpg

        至此 H264 码流的整个推送流程便已完成,我们可以使用 VLC 或其他支持 RTMP 协议的播放器进行测试。


关于 AAC 音频帧及 H264 码流的时间戳         

        通过前文的步骤我们已经能够将 AAC 音频帧以及 H264 码流正常推送到 RTMP 直播服务器,并能够使用相关播放器进行播放。但播放的效果如何还取决于时间戳的设定。

        在网络良好的情况下,自己最开始使用的音频流时间戳为 AAC 编码器刚输出一帧的时间,视频流时间戳为 H264 编码器刚编码出来一帧的时间,VLC 播放端就频繁报异常,要么是重新缓冲,要么直接没声音或花屏。在排除了推送步骤实现有误的问题后,Bill 发现问题出在时间戳上。

        之后有网友说直播流的时间戳不论音频还是视频,在整体时间线上应当呈现递增趋势。由于 Bill 最开始的时间戳计算方法是按照音视频分开计算,而音频时戳和视频时戳并不是在一条时间线上,这就有可能出现音频时戳在某一个时间点比对应的视频时戳小, 在某一个时间点又跳变到比对应的视频时戳大,导致播放端无法对齐。

        目前采用的时间戳为底层发送 RTMP 包的时间,不区分音频流还是视频流,统一使用即将发送 RTMP 包的系统时间作为该包的时间戳。目前局域网测试播放效果良好,音视频同步且流畅。


参考博文

[1][C++实现RTMP协议发送 H.264 编码及 AAC 编码的音视频]

[2][使用 libRtmp 进行 H264 与 AAC 直播]

[3][RTMP直播到FMS中的AAC音频直播]





     本文转自Bill_Hoo 51CTO博客,原文链接:http://blog.51cto.com/billhoo/1557646,如需转载请自行联系原作者







相关文章
|
5月前
|
网络协议 Linux
音视频学习之rtsp推拉流学习2(流媒体服务器ZLMediaKit)
音视频学习之rtsp推拉流学习2(流媒体服务器ZLMediaKit)
513 0
|
编解码 监控 网络协议
Android平台音视频推送选RTMP还是GB28181?
早在2015年,我们发布了RTMP直播推送模块,那时候音视频直播这块场景需求,还不像现在这么普遍,我们做这块的初衷,主要是为了实现移动单兵应急指挥系统的低延迟音视频数据传输。好多开发者可能会疑惑,走RTMP怎么可能低延迟?网上看到的RTMP推拉流延迟,总归要2-3秒起,如果是自己实现框架,RTMP推拉流逻辑自己实现的话,延迟确实可以控制在毫秒级,这个已无需赘述。
|
Web App开发 数据采集 物联网
Android平台基于RTMP或RTSP的一对一音视频互动技术方案探讨
随着智能门禁等物联网产品的普及,越来越多的开发者对音视频互动体验提出了更高的要求。目前市面上大多一对一互动都是基于WebRTC,优点不再赘述,我们这里先说说可能需要面临的问题:WebRTC的服务器部署非常复杂,可以私有部署,但是非常复杂。传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量,难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景,行话说的好:从demo到实用,中间还差1万个WebRTC。
145 0
|
网络协议 编译器 Linux
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
848 1
FFMPEG音视频开发: 发布RTSP流(采用EasyDarwin作为流媒体服务器)
|
1月前
|
Web App开发 网络协议 Android开发
Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【9月更文挑战第4天】本文详细对比了在Android平台上实现一对一音视频通话时常用的WebRTC、RTMP及RTSP三种技术方案。从技术原理、性能表现与开发难度等方面进行了深入分析,并提供了示例代码。WebRTC适合追求低延迟和高质量的场景,但开发成本较高;RTMP和RTSP则在简化开发流程的同时仍能保持较好的传输效果,适用于不同需求的应用场景。
74 1
|
2月前
|
编解码 网络协议 开发工具
Android平台RTSP|RTMP直播播放器技术接入说明
大牛直播SDK自2015年发布RTSP、RTMP直播播放模块,迭代从未停止,SmartPlayer功能强大、性能强劲、高稳定、超低延迟、超低资源占用。无需赘述,全自研内核,行业内一致认可的跨平台RTSP、RTMP直播播放器。本文以Android平台为例,介绍下如何集成RTSP、RTMP播放模块。
104 0
|
4月前
|
编解码 API 开发工具
程序与技术分享:AAC音频格式详解
程序与技术分享:AAC音频格式详解
|
10月前
|
Web App开发 API
ZLMediaKit webrtc录像
ZLMediaKit webrtc录像
|
12月前
|
移动开发 编解码 缓存
【知识拓展】音视频中的推流与拉流
【知识拓展】音视频中的推流与拉流
378 1
|
编解码 监控 网络协议
干货:如何实现RTSP推送H.264、RTSP推送H.265(hevc)
rtsp推送相关的资料和测试软件比较少,本文介绍rtsp推送相关信令和测试效果: 1. rtsp推送流程. 主要分两部分:第一部分先发送信令;第二部分发送rtp包。
515 1