通俗的解释下音视频同步里pcr作用

PCR同步在非硬件精确时钟源的情况还是谨慎使用,gstreamer里面采用PCR同步,但是发现好多ffmpeg转的片儿,或者是CP方的片源,pcr打得很粗糙的,老是有跳帧等现象。
音视频同步,有三种方法,视频同步音频,音频同步视频,同步到外部时钟!

第三种,同步到外部时钟也就是PCR同步,和我上面说的那种同步方式,一样!

用的最多的还是,视频同步音频,为什么呢?音频的采样率是固定的,若音频稍有卡顿,都会很明显的听出来,反则视频则不如此,虽然表面上说的是30fps,不一定每一帧的间隔就必须精确到33.33ms,因为人肉眼是观察不出来的,所以视频的帧率可以是动态的,并不是严格标准的!

用视频同步音频,做法很简单!首先,音频线程只管自己独立解码播放。视频线程在显示之前只需要检测视频PTS是否大于音频PTS,若大,则等待音频PTS>=视频PTS,若小,则直接播放,小太多则可以直接丢弃(跳帧)。做法就如此简单!但前提是你编码器一定要打好正确的PTS,若没有则只有自己伪造PTS了!

音视频同步和帧率控制其实是一个东西。我们先不管音视频同步是什么,我们先来看看如何进行帧率控制。明白了帧率控制,音视频同步那些都一通百通。一些基本的音视频术语我就不介绍了。

1、帧率控制

帧率控制的方法有千万种,最2的方法无非是每解码/显示一帧就进行延时,为了方便我们在进行帧率控制的同时能够理解音视频同步,我在此采用PCR同步的方式来进行帧率控制。网上关于PCR同步的原理讲了一大堆,有些很是难懂,一点儿也不通俗,我这里来给大家把晦涩的理论以最通俗的方式表达出来。

拿[email protected]的视频源来做理解。30P也就是说每秒钟30帧,也就是每一帧需要1/30*1000ms大概也就是每隔33.33ms就必须显示一帧。

要想知道如何正确的进行解码,就必须先了解编码端是如何工作的!一般编码器会以27MHZ的时钟来进行编码,这些都不重要,重要的就是,编码器一般默认会每隔30ms会发送一次PCR信息,这里的PCR信息就很重要了,他是我们在解码端解码进行帧率控制的时间基点,同时也是我们以后在进行同步校准的校准基点。

说了这么多,那么我就那个PCR信息来给大家分析分析。PCR信息是33bit组成的一个int64的数据,从解复用器里面出来我们可以得到一个很庞大的数字,看这个我们当然看不太懂!但是如果知道这个数字如何生成的那就好理解多了!

PCR信息说白了就是给视频的时间戳信息,比如一部电影是从  (00:01:23:033)时 : 分 : 秒 : 毫秒 开始,那么这个时间基点生成的PCR信息就是 (((00*60+1)*60+23.033)*90K)%2^33。90K为27M,300分频的结果。刚刚说了PCR会每30ms更新一次,那么PCR每次递增的数值就为0.030*90K=2700,这和PTS的值原理是相同的,这里先提一下,其实这个增量也不重要。我们需要的知识第一个PCR值就OK,但是如果考虑到后期校准,还是要用到以后的PCR值的。这里先不管校准的问题!

说了PCR,还有个值是我们需要的,那就是PTS。其实对于硬解码器来说DTS信息我们根本就不需要管他,我们只需要一帧一帧的把数据送进去,顺便把每一帧的PTS信息送进去,解码器送出来的就是排列好了PTS信息的帧了,其他解码器不知道至少RK3288是这样的。大家可以试着把解复用后的每一帧的PTS打印出来,你会发现在解复用后一般是这样排列的9000
3000 6000 18000 12000
15000.......这种是AVC编码的使用的是预测编码决定的,先不管他,你只管这样把没一帧依次送入解码器,解码器解码输出后自然就排列成3000
6000 9000 12000 15000 18000这才是我们需要的PTS!至于什么是PTS,实际上和PCR原理差不多,但是有个关键的地方PTS的增量值可不是默认的30ms了,他是由视频的帧率来决定的!说道重要的地方了哈!根据上面PCR的原理,如果是30p的视频那么每一帧就是1/30这么多的增量,再乘90K=3000。

说透了,我们这里就是利用这个PTS值来进行同步顺便进行帧率控制!

关键的地方来了!

如果视频流现在来了,我们先获取到第一个PCR值为1230000,我们现在马上在解码器端重建一个90K的时钟!这就是关键所在,至于如何重建90K的时钟,说白了就是开一个定时器,定时时间为1/90K(11.11us),每隔11.11us我们就把PCR计数值+1,同时这时候解码器也在工作,试想一下,如果是30P的视频,也就是33.33ms显示一次,那么当过了33.33ms后,PCR的数值加到好多了呢?没错就是33.33ms/11.11us=3000,这个增量不是和PTS的增量一摸一样!这时候你只需要在解码线程里判断当前帧的PTS是不是和这个PCR相等,如果相等就显示,如果PCR大可以丢弃当前帧,也就是说的跳帧,如果PCR小说明解码快了,这个时候就可以等待定时器线程到PCR==PTS。

这样就很巧妙的解决了帧率控制的问题了!同理,音视频同步也可以这样!你可以让音频的PTS去和PCR对比!其实大多数情况下都是以视频同步音频,音频解码不用管它,直接解码播放就OK了,你只需要进行帧率控制就OK了!同时注意随着时间的推移有可能出现延时,那么这个时候就需要重新来获取PCR来更新定时器线程里面的PCR基值了!

时间: 2024-08-14 17:12:17

通俗的解释下音视频同步里pcr作用的相关文章

即时通讯——详解音视频同步技术

转自:http://tieba.baidu.com/p/2138076570 摘要:针对网络传输中由于延迟.抖动.网络传输条件变化等因素引起的音视频不同步的问题,设计并实现了一种适应不同网络条件的音视频同步方案.利用音视频编码技术AMR-WB和H.264具有在复杂网络环境中速率可选择的特性,结合RTP时间戳和RTCP反馈检测QOS,通过控制音视频编码方式,实现了动态网络环境下的音视频同步方案.重点介绍了可靠网络环境和动态网络环境下同步算法的设计过程,并通过实际测试验证了此方案的可行性.结果表明,

音视频同步问题

音视频同步问题 音视频流里都包含了播放速率的信息,音频使用采样率来表示,而视频则采用f/s来表示,但是我们却不能简单地用这两个数据来对音视频进行同步,我们需要使用DTS(解码时间戳)和PTS(播放时间戳)这两个数据:我们知道影视数据在存储时,会存在多种帧形式,例如MPEG中就采用了I,B和P,由于B帧的存在使得PTS和DTS存在不同(原因见附录),如图1所示为一个简单的例子:当然真正影响我们音视频同步的是PTS. 我们可以从影视文件中获得包的PTS,但是我们无法直接获得帧(我们真正关心的)的PT

ffplay(2.0.1)中的音视频同步

最近在看ffmpeg相关的一些东西,以及一些播放器相关资料和代码. 然后对于ffmpeg-2.0.1版本下的ffplay进行了大概的代码阅读,其中这里把里面的音视频同步,按个人的理解,暂时在这里作个笔记. 在ffplay2.0.1版本里面,视频的刷新不再直接使用SDL里面的定时器了,而是在主的循环中event_loop中,通过调用函数refresh_loop_wait_event来等待事件, 同时在这个refresh_loop_wait_event函数里面,通过使用休眠函数av_usleep 来

ffmpeg转码MPEG2-TS的音视频同步机制分析

http://blog.chinaunix.net/uid-26000296-id-3483782.html 一.FFmpeg忽略了adaptation_field()数据FFmpeg忽略了包含PCR值的adaptation_filed数据; 代码(libavformat/mpegts.c)分析如下: /* 解析TS包 */int handle_packet(MpegTSContext *ts, const uint8_t *packet){  ...   pid = AV_RB16(packe

libstagefright 音视频同步方案

1:音视频数据都有一个list,用于存放解码后的数据: List mFilledBuffers; 2:解码后的音视频数据不断的往list中存放,不做音视频同步方面的时间上控制 mFilledBuffers.push_back(i); 3:音视频同步主要表现在从list中取数据进行视频的显示和音频的输出: 4:其中audio数据在线程函数threadLoop中调用AudioPlayer的回调函数循环读取,不做时间上的控制: 4:视频数据正常情况下按照每10ms的时间取一次,如果有音视频不同步的情况

音视频同步通讯SDK

视频流中的DTS/PTS到底是什么? DTS(解码时间戳)和PTS(显示时间戳)分别是解码器进行解码和显示帧时相对于SCR(系统参考)的时间戳.SCR可以理解为解码器应该开始从磁盘读取数据时的时间. mpeg文件中的每一个包都有一个SCR时间戳并且这个时间戳就是读取这个数据包时的系统时间.通常情况下,解码器会在它开始读取mpeg流时启动系统时钟(系统时钟的初始值是第一个数据包的SCR值,通常为0但也可以不从0开始). DTS 时间戳决定了解码器在SCR时间等于DTS时间时进行解码,PTS时间戳也

vlc源码分析(五) 流媒体的音视频同步

http://www.cnblogs.com/jiayayao/p/6890882.html vlc播放流媒体时实现音视频同步,简单来说就是发送方发送的RTP包带有时间戳,接收方根据此时间戳不断校正本地时钟,播放音视频时根据本地时钟进行同步播放.首先了解两个概念:stream clock和system clock.stream clock是流时钟,可以理解为RTP包中的时间戳:system clock是本地时钟,可以理解为当前系统的Tick数.第一个RTP包到来时: fSyncTimestamp

(转)音视频同步-时间戳

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

网络媒体流的音视频同步

一.音视频同步原理介绍 在多媒体采样/编码时,音频和视频都有一个固定的频率,比如视频以h264为例,其帧率是15F/S,音频以AAC为例,其采样率为44100,每帧含1024个sample,这样其帧率约为43F/S.这样,在理论上,每秒钟需要播放15帧视频数据和43帧音频数据.如果有一方播放速度过快或过慢,都会影响用户体验,这是音视频需要同步的原因. 二.实现方案简介 2.1两个时间参考点 要实现音视频同步,需要有两个时间参考点(1).编码时间参考点   以第一个到达的视频帧时间戳作为编码参考时