即时通讯中音视频同步的实现

DTS(解码时间戳)和PTS(显示时间戳)分别是解码器进行解码和显示帧时相对于SCR(系统参考)的时间戳。SCR可以理解为解码器应该开始从磁盘读取数据时的时间。

mpeg文件中的每一个包都有一个SCR时间戳并且这个时间戳就是读取这个数据包时的系统时间。通常情况下,解码器会在它开始读取mpeg流时启动系统时钟(系统时钟的初始值是第一个数据包的SCR值,通常为0但也可以不从0开始)。

DTS 时间戳决定了解码器在SCR时间等于DTS时间时进行解码,PTS时间戳也是类似的。通常,DTS/PTS时间戳指示的是晚于音视频包中的SCR的一个时 间。例如,如果一个视频数据包的SCR是100ms(意味着此包是播放100ms以后从磁盘中读取的),那么DTS/PTS值就差不多是200 /280ms,表明当SCR到200ms时这个视频数据应该被解码并在80ms以后被显示出来(视频数据在一个buffer中一直保存到开始解码)下 溢通常发生在设置的视频数据流相关mux率太高。

如果mux率是1000000bits/sec(意味着解码器要以1000000bits/sec的速率 读取文件),可是视频速率是2000000bits/sec(意味着需要以2000000bits/sec的速率显示视频数据),从磁盘中读取视频数据时 速度不够快以至于1秒钟内不能够读取足够的视频数据。这种情况下DTS/PTS时间戳就会指示视频在从硬盘中读出来之前进行解码或显示(DTS/PTS时间戳就要比包含它们的数据包中的SCR时间要早了)。

如今依靠解码器,这基本已经不是什么问题了(尽管MPEG文件因为应该没有下溢而并不完全符合MPEG标准)。一些解码器(很多著名的基于PC的播放器)尽可能快的读取文件以便显示视频,可以的话直接忽略SCR。

注意在你提供的列表中,平均的视频流速率为~3Mbps(3000000bits/sec)但是它的峰值达到了14Mbps(相当大,DVD限制在 9.8Mbps内)。这意味着mux率需要调整足够大以处理14Mbps的部分, bbMPEG计算出来的mux率有时候太低而导致下溢。

你计划让视频流速率这么高么?这已经超过了DVD的说明了,而且很可能在大多数独立播放其中都不能播放。如果你不是这么计划,我会从1增加mquant的值并且在视频设置中将最大码流设置为9Mbps以保持一个小一点的码流。

如果你确实想让视频码率那么高,你需要增大mux率。从提供的列表可以得出bbMPEG使用14706800bits/sec或者1838350bytes /sec的mux率(总数据速率为:1838350bytes/sec(14706800bits/sec)行)。你在强制mux率字段设置的值应该是以bytes/sec为单位并被50整除。所以我会从36767(1838350/50)开始,一直增加直到不会再出现下溢错误为止。

音视频同步原理[ffmpeg]

ffmpeg对视频文件进行解码的大致流程:

1. 注册所有容器格式和CODEC: av_register_all()

2. 打开文件: av_open_input_file()

3. 从文件中提取流信息: av_find_stream_info()

4. 穷举所有的流,查找其中种类为CODEC_TYPE_VIDEO

5. 查找对应的解码器: avcodec_find_decoder()

6. 打开编解码器: avcodec_open()

7. 为解码帧分配内存: avcodec_alloc_frame()

8. 不停地从码流中提取中帧数据: av_read_frame()

9. 判断帧的类型,对于视频帧调用: avcodec_decode_video()

10. 解码完后,释放解码器: avcodec_close()

11. 关闭输入文件:av_close_input_file()

output_example.c 中AV同步的代码如下(我的代码有些修改),这个实现相当简单,不过挺说明问题。

音视频同步-时间戳

媒体内容在播放时,最令人头痛的就是音视频不同步。从技术上来说,解决音视频同步问题的最佳方案就是时间戳:首先选择一个参考时钟(要求参考时钟上的时间是线性递增的);生成数据流时依据参考时钟上的时间给每个数据块都打上时间戳(一般包括开始时间和结束时间);在播放时,读取数据块上的时间戳,同时参考当前参考时钟上的时间来安排播放(如果数据块的开始时间大于当前参考时钟上的时间,则不急于播放该数据块,直到参考时钟达到数据块的开始时间;如果数据块的开始时间小于当前参考时钟上的时间,则“尽快”播放这块数据或者索性将这块数据“丢弃”,以使播放进度追上参考时钟)。

可见,避免音视频不同步现象有两个关键——一是在生成数据流时要打上正确的时间戳。如果数据块上打的时间戳本身就有问题,那么播放时再怎么调整也于事无补。假如,视频流内容是从0s开始的,假设10s时有人开始说话,要求配上音频流,那么音频流的起始时间应该是10s,如果时间戳从0s或其它时间开始打,则这个混合的音视频流在时间同步上本身就出了问题。打时间戳时,视频流和音频流都是参考参考时钟的时间,而数据流之间不会发生参考关系;也就是说,视频流和音频流是通过一个中立的第三方(也就是参考时钟)来实现同步的。第二个关键的地方,就是在播放时基于时间戳对数据流的控制,也就是对数据块早到或晚到采取不同的处理方法。图2.8中,参考时钟时间在0-10s内播放视频流内容过程中,即使收到了音频流数据块也不能立即播放它,而必须等到参考时钟的时间达到10s之后才可以,否则就会引起音视频不同步问题。

基于时间戳的播放过程中,仅仅对早到的或晚到的数据块进行等待或快速处理,有时候是不够的。如果想要更加主动并且有效地调节播放性能,需要引入一个反馈机制,也就是要将当前数据流速度太快或太慢的状态反馈给“源”,让源去放慢或加快数据流的速度。熟悉DirectShow的读者一定知道,DirectShow中的质量控制(Quality Control)就是这么一个反馈机制。DirectShow对于音视频同步的解决方案是相当出色的。但WMF SDK在播放时只负责将ASF数据流读出并解码,而并不负责音视频内容的最终呈现,所以它也缺少这样的一个反馈机制。

音视频同步通讯SDK源码包分享:

Android:http://download.csdn.net/detail/james_nba06/5179068
Windows:http://download.csdn.net/detail/weixiaowenrou/5170068
Linux:http://download.csdn.net/detail/weixiaowenrou/5178787
IOS:http://download.csdn.net/detail/weixiaowenrou/5169796
Web:http://download.csdn.net/detail/weixiaowenrou/5178791

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30004768/viewspace-1332626/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/30004768/viewspace-1332626/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
资源包主要包含以下内容: ASP项目源码:每个资源包都包含完整的ASP项目源码,这些源码采用了经典的ASP技术开发,结构清晰、注释详细,帮助用户轻松理解整个项目的逻辑和实现方式。通过这些源码,用户可以学习到ASP的基本语法、服务器端脚本编写方法、数据库操作、用户权限管理等关键技术。 数据库设计文件:为了方便用户更好地理解系统的后台逻辑,每个项目都附带了完整的数据库设计文件。这些文件通常包括数据库结构图、数据表设计文档,以及示例数据SQL脚本。用户可以通过这些文件快速搭建项目所需的数据库环境,并了解各个数据表之间的关系和作用。 详细的开发文档:每个资源包都附有详细的开发文档,文档内容包括项目背景介绍、功能模块说明、系统流程图、用户界面设计以及关键代码解析等。这些文档为用户提供了深入的学习材料,使得即便是从零开始的开发者也能逐步掌握项目开发的全过程。 项目演示与使用指南:为帮助用户更好地理解和使用这些ASP项目,每个资源包都包含项目的演示文件和使用指南。演示文件通常以视频或图文形式展示项目的主要功能和操作流程,使用指南则详细说明了如何配置开发环境、部署项目以及常见问题的解决方法。 毕业设计参考:对于正在准备毕业设计的学生来说,这些资源包是绝佳的参考材料。每个项目不仅功能完善、结构清晰,还符合常见的毕业设计要求和标准。通过这些项目,学生可以学习到如何从零开始构建一个完整的Web系统,并积累丰富的项目经验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值