ffmpeg 转换flv压缩大小_用FFMPEG SDK进行视频转码压缩时解决音视频不同步问题的方法(转)..._寻尘客的博客-程序员秘密

用FFMPEG SDK进行视频转码压缩的时候，转码成功后去看视频的内容，发现音视频是不同步的。这个的确是一个恼火的事情。我在用FFMPEG SDK做h264格式的FLV文件编码Filter的时候就碰到了这个问题。经过研究发现，FFMPEG SDK写入视频的时候有两个地方用来控制写入的时间戳，一个是AvPacket, 一个是AvFrame。在调用avcodec_encode_video的时候需要传入AvFrame的对象指针，也就是传入一帧未压缩的视频进行压缩处理，AvFrame包含一个pts的参数，这个参数就是当前帧将来在还原播放的时候的时间戳。而AvPacket里面也有pts，还有dts。说起这个就必须要说明一下I,P,B三种视频压缩帧。I帧就是关键帧，不依赖于其他视频帧，P帧是向前预测的帧，只依赖于前面的视频帧，而B帧是双向预测视频帧，依赖于前后视频帧。由于B帧的存在，因为它是双向的，必须知道前面的视频帧和后面的视频帧的详细内容后，才能知道本B帧最终该呈现什么图像。而pts和dts两个参数就是用来控制视频帧的显示和解码的顺序。pts就是帧显示的顺序。dts就是帧被读取进行解码的顺序。如果没有B帧存在，dts和pts是相同的。反之，则是不相同的。关于这个的详细介绍可以参考一下mpeg的原理。再说说AvPacket中包含的pts和dts两个到底该设置什么值？pts和dts需要设置的就是视频帧解码和显示的顺序。每增加一帧就加一，并不是播放视频的时间戳。

但是实践证明经过rmvb解码的视频有时候并不是固定帧率的，而是变帧率的，这样，如果每压缩一帧，pts和dts加一的方案为导致音视频不同步。那怎么来解决音视频同步的问题呢？请看如下代码段。lTimeStamp 是通过directshow 获取的当前的视频帧的时间戳。m_llframe_index为当前已经经过压缩处理的帧的数量。首先av_rescale计算得到当前压缩处理已经需要处理什么时间戳的视频帧，如果该时间戳尚未到达directshow当前提供的视频帧的时间戳，则将该帧丢弃掉。否则进行压缩操作。并设置AVPacket的pts和dts。这里假设B帧不存在。因为在将来播放的时候视频以我们设定的固定播放帧率进行播放，所以需要根据设定的播放帧率计算得到的视频帧时间戳和directshow提供的当前视频帧的时间戳进行比较，设定是否需要进行实施延缓播放的策略。如果需要延缓播放，则将pts增加步长2，否则以普通速度播放，则设置为1.dts与之相同。__int64 x =av_rescale(m_llframe_index,AV_TIME_BASE*(int64_t)c-

if( x < lTimeStamp ){return TRUE;}m_pVideoFrame2-

m_llframe_index += pkt.duration;}//pkt.pts = lTimeStamp * (__int64)frame_rate.den / 1000;if( c-

请问avcodec_decode_video解码的帧为什么后面的比前面的pts小呢？

请问如下代码：while( av_read_frame(pFormatCtxSource,&packet)<=0 ){if( packet.stream_index==videoStream ){int out_size = avcodec_decode_video(pCodecCtxSource,pFrameSource, &bFrameFinished, packet.data, packet.size); // Decode fromsource frameif( bFrameFinished ){pFrameSource-

在我Decode的时候，第一帧得到的 pFrameSource-

答复：

Because you have B - Framefor example:the Inputsequence for video encoder1 2 3 4 5 6 7I B B P B B ILet's take1,2,3.. as PTS for simplificationthe out sequencefor video encoder ( this equals the decoder sequence)1 4 2 3 7 5 6I P B B I B Byou will get aPTS sequence as following:

1 4 2 3 7 5 6 7 5 6sequence will be same as your question

问：

哦，那是不是我的pts不能这么算呢？而是要每次+1,对吗？那么，packet中的pts和dts要用在什么地方呢？我这样按存储顺序进行解码的话，显示之前是不是要自己进行缓存呢？谢谢！

另外，还有个问题，既然解码的时候，不一定是按照pts递增的顺序得到的解码后的画面，那我在编码图像的时候，是应该按照解码出来的帧顺序进行编码吗？还是把帧先缓存起来，最后严格接照图像的显示顺序来编码呢？用代码来表示，就是：方法一：while(av_read_frame ){ 解码; pts+1; 编码; 输出;}

方法二：while(av_read_frame ){解码;if( pts{

缓存;

}

else

{

编码缓存的帧并写入文件;

}

这两个方法，哪个是正确的呢？因为我看到网上的代码都用的是方法一，但是我觉得方法二是对的呀？

答：

the output of decoderis the right order for display because I/P frames will be cacheduntil next I/P

理解：

Decoder 后output的pts 是按正常的顺序，即显示的顺序输出的，如果有B帧，decoder会缓存。

但encoder后，输出的是按dts输出的。

Pts,dts并不是时间戳，而更应该理解为frame的顺序序列号。由于每帧frame的帧率并不一定是一致的，可能会变化的。转换为时间戳的话，应该是(pts*帧率)。为加深理解

可以将pts比做是第pts帧frame，假设每帧的帧率不变的话，则显示的时间戳为(pts*帧率)，如果考虑帧率变化的，则要想办法将(pts*当前的帧率)累加到后面。

在tutorial5中在decode 下增加trace后打印情况：

len1 = avcodec_decode_video(is-

packet-

printf("-----------------------------------------------------------------------------\n");

printf("avcodec_decode_videopacket-

printf("avcodec_decode_videopFrame-

if(pFrame-

printf("avcodec_decode_video*(uint64_t *)pFrame-

其中播一个mp4文件的打印情况：

-----------------------------------------------------------------------------

avcodec_decode_video packet-<1ae>