视频、音频打时间戳的方法及其音视频同步(播放)原理

简介: 视频、音频打时间戳的方法    http://blog.csdn.net/wfqxx/article/details/5497138 1. 视频时间戳      pts = inc++ *(1000/fps);  其中inc是一个静态的,初始值为0,每次打完时间戳inc加1.

视频、音频打时间戳的方法

  
http://blog.csdn.net/wfqxx/article/details/5497138

1. 视频时间戳

     pts = inc++ *(1000/fps);  其中inc是一个静态的,初始值为0,每次打完时间戳inc加1.

    在ffmpeg,中的代码为

    pkt.pts= m_nVideoTimeStamp++ * (m_VCtx->time_base.num * 1000 / m_VCtx->time_base.den);

 

2. 音频时间戳

    pts = inc++ * (frame_size * 1000 / sample_rate)

   在ffmpeg中的代码为

   pkt.pts= m_nAudioTimeStamp++ * (m_ACtx->frame_size * 1000 / m_ACtx->sample_rate);

 

采样频率是指将模拟声音波形进行数字化时,每秒钟抽取声波幅度样本的次数。

。正常人听觉的频率范围大约在20Hz~20kHz之间,根据奈奎斯特采样理论,为了保证声音不失真,采样频率应该在40kHz左右。常用的音频采样频率有8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等,如果采用更高的采样频率,还可以达到DVD的音质

对采样率为44.1kHz的AAC音频进行解码时,一帧的解码时间须控制在23.22毫秒内。

背景知识:

(一个AAC原始帧包含一段时间内1024个采样及相关数据)

分析:

1 AAC

音频帧的播放时间=一个AAC帧对应的采样样本的个数/采样频率(单位为s)

一帧 1024个 sample。采样率 Samplerate 44100KHz,每秒44100个sample, 所以 根据公式   音频帧的播放时间=一个AAC帧对应的采样样本的个数/采样频率

当前AAC一帧的播放时间是= 1024*1000000/44100= 22.32ms(单位为ms)

2 MP3

 

mp3 每帧均为1152个字节, 则:

frame_duration = 1152 * 1000000 / sample_rate

例如:sample_rate = 44100HZ时, 计算出的时长为26.122ms,这就是经常听到的mp3每帧播放时间固定为26ms的由来。

 

 

 

 

 

音视频同步(播放)原理

每一帧音频或视频都有一个持续时间:duration:
采样频率是指将模拟声音波形进行数字化时,每秒钟抽取声波幅度样本的次数。
。正常人听觉的频率范围大约在20Hz~20kHz之间,根据奈奎斯特采样理论,为了保证声音不失真,采样频率应该在40kHz左右。常用的音频采样频率有8kHz、

11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz等,如果采用更高的采样频率,还可以达到DVD的音质
对采样率为44.1kHz的AAC音频进行解码时,一帧的解码时间须控制在23.22毫秒内。
背景知识:
(一个AAC原始帧包含一段时间内1024个采样及相关数据)
分析:
1) AAC
音频帧的播放时间=一个AAC帧对应的采样样本的个数/采样频率(单位为s)
一帧 1024个 sample。采样率 Samplerate 44100KHz,每秒44100个sample, 所以根据公式   音频帧的播放时间=一个AAC帧对应的采样样本的个数/采样频率
当前AAC一帧的播放时间是= 1024*1000000/44100= 22.32ms(单位为ms)
2) MP3
mp3 每帧均为1152个字节, 则:
frame_duration = 1152 * 1000000 / sample_rate
例如:sample_rate = 44100HZ时,计算出的时长为26.122ms,这就是经常听到的mp3每帧播放时间固定为26ms的由来。
3)H264
视频的播放时间跟帧率有关 frame_duration = 1000/fps
例如:fps = 25.00 ,计算出来的时常为40ms,这就是同行所说的40ms一帧视频数据。

理论上的音视频(播放)同步是这样的:
由此得到了每一帧数据的持续时间,音视频交叉存储在容器中:一个时间轴:
时间轴:0   22.32   40     44.62    66.96    80     89.16      111.48    120       ................
音   频 :0   22.32            44.62    66.96             89.16      111.48                ................
视   频 :0              40                              80                                   120       ................
即视频的持续时间相加 和音频的持续时间相加作比较,谁小写入哪个。

 

但实际情况(播放)是不成立的

1:首先解决一个问题

为什么不 音频播音频的 视频播视频的 即上面的 到 第22.32ms播一帧音频 ,到40ms播一帧视频。

因为这个22.32ms 或40ms是算不准的或者说和声卡播的时间是不一样的。这里就需要知道声卡播一帧/或者说播放一个buf音频需要多长时间。

2:声卡每次播一个采样点 而不是一帧。声音当一个采样点丢失了都可以听出来,视频则不然。

3:音视频同步方式:1----回调方式

假设声卡有两块缓存都是存放要播放的声音pcm的 一直在播放"B"buf 首先确定几点

(1)buf大小是固定的这样播放一个buf的时间就是固定的,假设30ms;

(2)当buf“B”播放完毕即buf用完,再播放buf“A",保证音频pcm一直都连续

(3)当一个buf播放完毕,那说明系统(声卡)过了30ms, 这时候有可能真正的时间过了40ms(这里不用关心),这里则通过回调得到一次时间30ms;

(4)再去用视频对应音频的30ms,这时候的时间就是准确的:

时间轴:0                    30                         60                         90                                        120       ................
音   频 :0     22.32                 44.62                 66.96     89.16                       111.48                     ................
视   频 :0                          40                                    80                                                  120       ................

(5)这里有个问题就是 视频中 30ms 到40ms 这中间的10ms是怎么算出来的,这个是不用关心的,因为人的眼睛10ms是看不出来的,

即当音频的30ms一次回调时,就可以播放第二帧视频,如上图

第一次回调(30ms)---播(40ms)视频,

第一次回调(60ms)---播(80ms)视频,

第一次回调(90ms)---不播视频,

第一次回调(120ms)---播(120ms)视频。

4:音视频同步方式:1----阻塞方式

还是看上面的图

(1)buf"B"一直在播放,传入buf"A"的外部buf把数据给buf"A"后 不立即返回,等到buf"B"播放完成再返回,

这时从传入到经过阻塞出来就是一个buf的时间例如上面的30ms。

(2)然后buf"A"一直在播放,传入buf"B"的外部buf把数据给buf"B"后 不立即返回,等到buf"A"播放完成再返回,

这时从传入到经过阻塞出来就是一个buf的时间例如上面的30ms。

(3)循环上面(1)(2),即得到了如回调方式同样的那个30ms时间。下面和回调方式一样,见回调方式(4)(5)。

 

转自   http://blog.csdn.net/zhuweigangzwg/article/details/25815851
目录
相关文章
|
9月前
|
存储 算法 C++
深入理解ffmpeg视频播放以及音视频同步:时间基与样本处理
深入理解ffmpeg视频播放以及音视频同步:时间基与样本处理
654 1
|
9月前
|
存储 编解码 调度
剖析ffmpeg视频解码播放:时间戳的处理
剖析ffmpeg视频解码播放:时间戳的处理
797 0
|
5月前
|
编解码 算法 图形学
同一路RTSP|RTMP流如何同时回调YUV和RGB数据实现渲染和算法分析
我们播放RTSP|RTMP流,如果需要同时做渲染和算法分析的话,特别是渲染在上层实现(比如Unity),算法是python这种情况,拉两路流,更耗费带宽和性能,拉一路流,同时回调YUV和RGB数据也可以,但是更灵活的是本文提到的按需转算法期望的RGB数据,然后做算法处理
|
6月前
|
编解码 开发工具 Android开发
低延迟播放超高分辨率(4K+)帧率(50帧+)RTSP|RTMP流技术探讨和实现
为满足安检等场景需求,需支持4K+分辨率与50帧以上的高帧率视频流播放。实现这一目标的关键步骤包括:确保视频源支持高帧率输出、选用高性能RTSP/RTMP播放器以处理高负载视频解码、采用硬件解码以降低CPU负担、保证充足的网络带宽以维持流畅播放并控制延迟、合理配置播放器缓冲策略以适应网络波动、进行性能监控与调试以优化播放效果,以及确保播放器在多平台上的良好兼容性和表现。例如,大牛直播SDK的SmartPlayer在不同平台上实现了稳定且低延迟(150-300ms)的播放体验,支持多种视频和音频格式及多种功能,如多实例播放、事件回调、视频快照等。
169 1
|
9月前
|
存储 算法 API
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略(三)
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略
324 1
|
9月前
|
传感器 机器学习/深度学习 编解码
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略(二)
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略
569 1
|
9月前
|
编解码 UED
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略(一)
音视频同步的方法:深入探索基于FFmpeg的音视频同步策略
1130 1
|
9月前
|
存储 算法 前端开发
深入理解FFmpeg音视频编程:处理封装、解码、播放 队列与回放策略
深入理解FFmpeg音视频编程:处理封装、解码、播放 队列与回放策略
380 0
|
编解码 Android开发
【Android FFMPEG 开发】FFMPEG 音视频同步 ( 音视频同步方案 | 视频帧 FPS 控制 | H.264 编码 I / P / B 帧 | PTS | 音视频同步 )(二)
【Android FFMPEG 开发】FFMPEG 音视频同步 ( 音视频同步方案 | 视频帧 FPS 控制 | H.264 编码 I / P / B 帧 | PTS | 音视频同步 )(二)
766 1

热门文章

最新文章