libstagefright 音视频同步方案

1:音视频数据都有一个list,用于存放解码后的数据;

List mFilledBuffers;

2:解码后的音视频数据不断的往list中存放,不做音视频同步方面的时间上控制

mFilledBuffers.push_back(i);

3:音视频同步主要表现在从list中取数据进行视频的显示和音频的输出;

4:其中audio数据在线程函数threadLoop中调用AudioPlayer的回调函数循环读取,不做时间上的控制;

4:视频数据正常情况下按照每10ms的时间取一次,如果有音视频不同步的情况,就可能需要做以下三种情况的处理

1:如果视频数据过快,超过音频时间10ms,则显示当前帧后,将读取数据的事件延时(慢的时间-10ms)后放入队列;

2:如果视频数据过慢,慢于音频时间40ms,则丢弃当前帧,然后再去取数据;

3:如果视频数据过慢,慢于音频时间500ms,则丢弃当前帧,并且需要丢弃一段视频帧,直接对video部分(SEEK_VIDEO_ONLY)seek到音频当前帧的时间戳;

PS:上面的三个时间参数可能会微调;

6:视频当前时间是指视频当前帧携带的时间戳,是通过该帧的sampleIndex从stts表中读取出来的;

int64_t timeUs;

CHECK(mVideoBuffer->meta_data()->findInt64(kKeyTime, &timeUs));

7:音频的时间戳通过以下方式计算:

result + diffUs - realtime_us + mediatime_us = -mLatencyUs + ALooper::GetNowUs() - mNumFramesPlayedSysTimeUs + mediatime_us

mNumFramesPlayedSysTimeUs = ALooper::GetNowUs() 和前面那个函数有一定的时间差

8:循环读取数据的机制

android中循环读取数据都是通过Thread类的threadLoop函数实现,这个函数的介绍如下:

Derived class must implement threadLoop(). The thread starts its life here. There are two ways of using the Thread object:

1) loop: if threadLoop() returns true, it will be called again if

requestExit() wasn‘t called.

2) once: if threadLoop() returns false, the thread will exit upon return.

virtual bool        threadLoop() = 0;

如果函数返回true,且没有调用requestExit()函数,则一直循环执行  ----------正常播放情况

如果函数返回true,但调用requestExit()函数,则停止执行          ----------停止播放情况

如果函数返回false,执行一次后返回

9:正常情况下音视频对应的threadLoop函数都在循环执行,并没有时间上的控制,音频数据确实如此,但是视频数据通过下面的机制控制读取

读取视频数据被封装为一个个事件,这些事件都会携带一个什么执行的时间戳,这些事件按照执行时间的先后顺序放入一个队列;

threadLoop函数循环执行的时候,会判断当前时间和队头事件的时间戳

前者大于等于后者,取出时间执行,return true;

前者小于后者,做下面的操作:

int64_t whenUs = (*mEventQueue.begin()).mWhenUs;

int64_t nowUs = GetNowUs();

if (whenUs > nowUs) {

int64_t delayUs = whenUs - nowUs;

mQueueChangedCondition.waitRelative(mLock, delayUs * 1000ll);

return true;

event = *mEventQueue.begin();

mEventQueue.erase(mEventQueue.begin());

gLooperRoster.deliverMessage(event.mMessage);

libstagefright 音视频同步方案

时间: 2024-10-12 03:52:52

libstagefright 音视频同步方案的相关文章

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

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

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

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

网络媒体流的音视频同步

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

音视频同步通讯SDK

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

音视频同步问题

音视频同步问题 音视频流里都包含了播放速率的信息,音频使用采样率来表示,而视频则采用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

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

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

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

PCR同步在非硬件精确时钟源的情况还是谨慎使用,gstreamer里面采用PCR同步,但是发现好多ffmpeg转的片儿,或者是CP方的片源,pcr打得很粗糙的,老是有跳帧等现象.音视频同步,有三种方法,视频同步音频,音频同步视频,同步到外部时钟! 第三种,同步到外部时钟也就是PCR同步,和我上面说的那种同步方式,一样! 用的最多的还是,视频同步音频,为什么呢?音频的采样率是固定的,若音频稍有卡顿,都会很明显的听出来,反则视频则不如此,虽然表面上说的是30fps,不一定每一帧的间隔就必须精确到33