vlc的pts是如何计算的

[blackeye2004]

如果我播放一个rtsp流，VLC是怎么计算音视频的pts值。

[blackeye2004]

具体算法是怎么样的啊

[逸萌]

音视频的pts是由解码时算出来的

[雷霄骅]

可以参考ffplay代码，pts和time_base可以计算出音视频的播放时间。pts位于AVPacket中。vlc应该是差不多的

[blackeye2004]

live555只发送时间戳和npt时间，VLC是直接把时间戳换算一下当pts?

[xiao17174]

引用 5 楼 blackeye2004 的回复:

live555只发送时间戳和npt时间，VLC是直接把时间戳换算一下当pts?

这个时间戳就是PTS.

[xiao17174]

我也正在研究这一块.说解码才得到的都是不对的.其实是从LIVE555那里得到的.afterGettingFrame里面有一个参数是presentationTime.通过RTSP得到的流的PTS都是由它计算出来的.不过它的单位是us.还是90000.这个要值得注意.ffmpeg解码后只是校准了PTS.PTS真正的源头是RTSP的发送方.只有发送方才有能力告诉你数据采集的PTS从而帮助你进行同步.

[xiao17174]

还没结帖么,那再说一些这几天理解到的东西,RTP规范里,RTP包的TIMESTAMP字段应该指示图像的显示时间,而且时间单位是tick.像视频的话单位就是90K,那一段25fps的视频每增长一帧,时间戳就应该增加3600.但是同样是通过RTSP播实时流,ffplay和vlc对于时间戳的处理是不一样的.如果在ffplay里.它直接把rtp包里的timestamp当作是解码前的pts传入avcodec_decode_video2().ffmpeg进行重排序(如果没有B帧,一般是原样复制到解码后的AVFrame里),然后将它乘以1/90K还原成us的单位,然后直接用来usleep();而vlc的rtsp传输模块用的是live555,live555在我看来多此一举了,它对上层屏蔽了RTP包里的TIMESTAMP.而是直接帮你还原好了.单位就是us.也就是说,afterGettingFrame()函数的pts单位是us.可以直接拿来用usleep了

[Putin_yhc]

// 1s = 90000 time scale , 一帧就应该是 90000/video_frame_rate 个timescale static uint32_t video_frame_rate = 30; static uint32_t video_pts_increment = 90000 / video_frame_rate; //用一秒钟除以帧率,得到每一帧应该耗时是多少，单位是 timescale单位 static uint64_t video_pts = 0; pts初始值可以是任意的，我一般定为0，后面每一帧加上增量就可以了。 音频pts的计算方法同上，只不过不是通过帧率，而是通过采样率。 uint32_t audio_pts_increment = (90000 * audio_samples_per_frame) / audio_sample_rate; audio_samples_per_frame这个值对aac和mp3是不同的，aac固定为1024，mp3固定为1152.

[haohao345646798]

引用 7 楼 xiao17174 的回复:

还没结帖么,那再说一些这几天理解到的东西,RTP规范里,RTP包的TIMESTAMP字段应该指示图像的显示时间,而且时间单位是tick.像视频的话单位就是90K,那一段25fps的视频每增长一帧,时间戳就应该增加3600.但是同样是通过RTSP播实时流,ffplay和vlc对于时间戳的处理是不一样的.如果在ffplay里.它直接把rtp包里的timestamp当作是解码前的pts传入avcodec_decode_video2().ffmpeg进行重排序(如果没有B帧,一般是原样复制到解码后的AVFrame里),然后将它乘以1/90K还原成us的单位,然后直接用来usleep();而vlc的rtsp传输模块用的是live555,live555在我看来多此一举了,它对上层屏蔽了RTP包里的TIMESTAMP.而是直接帮你还原好了.单位就是us.也就是说,afterGettingFrame()函数的pts单位是us.可以直接拿来用usleep了

引用 7 楼 xiao17174 的回复:

还没结帖么,那再说一些这几天理解到的东西,RTP规范里,RTP包的TIMESTAMP字段应该指示图像的显示时间,而且时间单位是tick.像视频的话单位就是90K,那一段25fps的视频每增长一帧,时间戳就应该增加3600.但是同样是通过RTSP播实时流,ffplay和vlc对于时间戳的处理是不一样的.如果在ffplay里.它直接把rtp包里的timestamp当作是解码前的pts传入avcodec_decode_video2().ffmpeg进行重排序(如果没有B帧,一般是原样复制到解码后的AVFrame里),然后将它乘以1/90K还原成us的单位,然后直接用来usleep();而vlc的rtsp传输模块用的是live555,live555在我看来多此一举了,它对上层屏蔽了RTP包里的TIMESTAMP.而是直接帮你还原好了.单位就是us.也就是说,afterGettingFrame()函数的pts单位是us.可以直接拿来用usleep了

我在vlc处理的某一类视频中发现音视频不同步，现在想找到控制时间戳的代码位置，你知道在哪个甘薯里面么，音频和视频的dexum和output

[bolin123]

引用 8 楼 yhc223 的回复:

// 1s = 90000 time scale , 一帧就应该是 90000/video_frame_rate 个timescale static uint32_t video_frame_rate = 30; static uint32_t video_pts_increment = 90000 / video_frame_rate; //用一秒钟除以帧率,得到每一帧应该耗时是多少，单位是 timescale单位 static uint64_t video_pts = 0; pts初始值可以是任意的，我一般定为0，后面每一帧加上增量就可以了。 音频pts的计算方法同上，只不过不是通过帧率，而是通过采样率。 uint32_t audio_pts_increment = (90000 * audio_samples_per_frame) / audio_sample_rate; audio_samples_per_frame这个值对aac和mp3是不同的，aac固定为1024，mp3固定为1152.

用了你的计算方法，音视频可以用VLC同时播放，但是音频过一段时间后就变慢了。 而且越来延时越大，最后音频就没有了。 请问知道是什么原因吗？