专栏首页谢金运的专栏音频缺失录制分析
原创

音频缺失录制分析

实验框架:

实验框架

RTMP Reader和Muxing各自包含音视频的AVCodecContext,共四个AVCodecContext

背景:

用户实际推流过程中,存在推流无音频数据的异常场景,导致录制RTMP Reader无法正确初始化音频的AVCodecContext,进而影响录制Muxing音频AVCodecContext初始化,最终导致录制文件出现静音等问题。

正常的音频推流过程是:AAC Sequence header | AAC data | AAC data | …… | AAC data

场景1:视频包正常推送,音频包则只推送AAC Sequence header,对应推流端代码是

1.正常初始化推流端RTMP Reader的音视频AVCodecContext

2.正常初始化推流端Muxing的音视频AVCodecContext

3.调用avformat_write_header

4. RTMP Reader读取音频视频包,Muxing写视频包,丢弃音频包

抓包如下:

抓包

红框中包含on mata data和视频的sps/pps以及音频的AAC Sequence header

结果:

录制RTMP Reader堵塞于avformat_find_stream_info直至超时返回,此时RTMP Reader的音视频AVCodecContext均已存在,但是音频AVCodecContext并未正确初始化,音频AVCodecContext如下:

AVCodecContext

红框的重要信息中只有bit_rate存在了,其他全未被初始化,用该音频AVCodecContext初始化Muxing的音频AVCodecContext时,ffmpeg会报错:

ffmpeg报错

此时若忽略音频的AVCodecContext,可以正常录制静音文件,这样做存在的问题是若后续推送了正常的音频数据,也会被录制端忽略。

场景2:视频包正常推送,音频包完全不推送,对应推流端代码是

1.正常初始化推流端RTMP Reader的音视频AVCodecContext

2.正常初始化推流端Muxing的视频AVCodecContext,初始化音频AVCodecContext为0,不打开音频stream

3.调用avformat_write_header

4. RTMP Reader读取音频视频包,Muxing写视频包,丢弃音频包

抓包如下:

抓包

红框看到只有on mata data和video的sps/pps,没有audio的AAC Sequence header

结果:

录制RTMP Reader堵塞于avformat_find_stream_info直至超时返回,此时RTMP Reader的视频AVCodecContext已生成并初始化,而音频AVCodecContext指针则为0,忽略音频录制则静音录制。缺点同场景1。

场景3:视频包正常推送,音频包以及aac sequence header均延迟推送,该场景需要修改rtmp server的代码实现,对应的代码实现是

1.推流端初始化时推送aac sequence header,音频数据则延迟推送

2.rtmp server接收到aac sequence header先进行保存,等到第一个音频数据包达到再一起推送给录制模块,实现均延迟的效果

录制中途,日志有(ffmpeg发现了上行音频stream):

结论同场景2.

场景4:视频包正常推送,音频包只发送数据,不发送aac sequence header,代码实现:

1.rtmp server接收到aac sequence header直接丢弃,只发送后续音频数据包

该场景实际是会影响音频AVCodecContext的extradata的初始化,该场景中,录制代码对录制hls和非hls有不同的做法,录制hls时,放弃录制音频,其他格式则依旧使用无extradata的AVCodecContext录制。

本实验也对该场景做了详细实验:

1.录制flv/mp4时,无extradata也可以正常录制音频数据,播放正常;

2.录制hls时,若强制使用无extradata的AVCodecContext进行录制,则会core掉(这也是录制代码当时要区分hls与非hls录制逻辑的原因);

录制优化:

当前版本,录制初始化设置获取音视频AVCodecContext超时时间为90秒,并有重试逻辑,获取3次不成功就会减少超时时间,最终还不成功则忽略音频AVCodecContext,直接录制静音视频。实验过程中发现,以上3种场景,只要推流端之后能正确推音频数据上来,录制中使用avformat_open_input得到的AVFormatContext中的音频AVCodecContext都会被正确初始化。意味着,如果录制途中再去获取音频的AVCodecContext是可以获取到的,这刚好适用于录制hls的场景,因为录制每次切ts分片的时候都会重新调用setup muxing。

优化效果:

假定,m3u8里有两个ts分片,1.ts和2.ts,1.ts不含音频数据,2.ts含有音频数据(优化的结果)。

ffplay/potplay/hls.js 播放全程静音

ios 1分钟前静音,1分钟后正常同步音频

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • IOS播放异常音频案例分析

    IOS播放器对播放文件要求比较严格,对于一些异常文件兼容性不是特别好,而且IOS播放器相对封闭,无法查看源代码或者看相关日志跟踪问题,所以定位IOS播放问题可谓...

    onexie
  • Audioburst:开放API,助力开发者调用AI音频搜索引擎

    这款基于浏览器的新搜索引擎只是Audioburst技术的最新界面。公司还提供独立的音频转录服务,以及一个API——可以让应用程序开发人员将Audioburst的...

    BestSDK
  • 基于Tensorflow实现DeepFM前言网络结构代码部分

    DeepFM,Ctr预估中的大杀器,哈工大与华为诺亚方舟实验室荣耀出品,算法工程师面试高频考题,有效的结合了神经网络与因子分解机在特征学习中的优点:同时提取到低...

    sladesal
  • Dubbo on Istio 改造方案的思考

    虽然 Dubbo 是个很优秀的 SOA 框架,在国内也是非常流行,但在 service mesh 的大风下,有些跟不上时代了。一方面官方还没有给出权威的 mes...

    鲍远林
  • Dubbo on Istio 改造方案的思考

    虽然 Dubbo 是个很优秀的 SOA 框架,在国内也是非常流行,但在 service mesh 的大风下,有些跟不上时代了。一方面官方还没有给出权威的 mes...

    鲍远林
  • Dubbo源码解析 —— Router

    前言 估算了一下, dubbo里面涉及的东西还是比较多的.比如谈到框架的时候,设计模式都是一个老生常谈的话题,再比如我们开发中我们不常用的一些概念, spi、...

    芋道源码
  • 消息总线真的能保证幂等?

    一、缘起 如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点: (1)消息落地 (2)消息超时、重传、确认 ? 再次回顾消息总线核心架构,它由发送...

    架构师之路
  • 深度强化学习-Policy Gradient基本实现

    在之前的几篇文章中,我们介绍了基于价值Value的强化学习算法Deep Q Network。有关DQN算法以及各种改进算法的原理和实现,可以参考之前的文章: 实...

    石晓文
  • 分布式事务原理解析

    了解过TCC分布式事务的都知道它有三个阶段:try,confirm,cancel,但很多文章就只有原理图,和对原理图的解释,看一遍也留不下印象,这里用实际场景举...

    老梁
  • 8.16 VR扫描:VR社交平台AltspaceVR宣布回归;Facebook将推《部落冲突》AR体验

    VRPinea

扫码关注云+社区

领取腾讯云代金券