欢迎访问我的独立博客

音视频编解码开发经验2

网络带宽足够,但是手机播放视频很卡,主要原因应该就是手机性能不够了,具体来说的话,可能有以下几个方面:1. 没有使用硬解,而软解的速度又跟不上。 2. 播放的是高清、高码率的视频。3. h264 high profile 编码的视频,解码比较费劲。4. 播放器本身的设计,包括:接收、解码、渲染的并行,数据的拷贝和格式转换等等。
怎么计算未压缩的音频的码率? 双声道、采样率为44.1KHz、采样位宽为16bit的数字音频,则其码率为:44.1kHz*16bit*2 = 1.411Mbit/s
做直播的视频播放器,有两个关键的指标:首开时间和累积延时,前者需要服务器配合缓存一个GOP,同时播放器减少缓冲(注:减少缓冲应该就是不缓存解码后的数据,而且解码后马上出帧);
后者有两种优化方向,第一是对播放缓冲队列定期做一些清理,第二是引入追帧策略。“追帧”不是单纯地指2倍、4倍之类的加速播放,因为加速播放的效果是“快进快退”,体验不好,“追帧” 正确的姿势应该是选择性地丢帧,从而快速消费掉缓冲区中的数据,达到降低累积延时的目的……而怎么丢同时又保持音视频同步则是开发难点。
音视频实时传输的延时主要来自哪里? 1.编码器/解码器一般需要缓冲2~4帧; 2.编码/解码的耗时; 3.业务代码中的帧缓冲区; 4.网络传输延时; 5.代码中的数据拷贝。
如何计算网络传输部分的延时,一帧10KB的图像在带宽为40Mbit/s的网络上传输,需要多长时间?答案: 10KB*8 = 80kbit, 80kbit/(40*1024)kbit/s = 1.9ms
音视频数据的网络传输与普通文件的传输有很大的不同,接收到文件数据流可以立马写磁盘,但是接收到一帧音视频数据则必须根据时间戳来决定何时送入解码器解码以及显示,没到时间,就得sleep,否则的话,播放过程会因为网络抖动而出现卡顿现象。
参考:
posted @ 2016-09-30 18:37  github.com/starRTC  阅读(629)  评论(0编辑  收藏  举报