2,543
社区成员
发帖
与我相关
我的任务
分享关于vlc中是如何同步live库得到的rtp audio,video流?
各位大牛,我最近做个实验,关于从wowza服务器发出的rtsp流. 是 audio为 mpa, video为 h264.
在客户端 ,用vlc 以tcp来连接,基本上可以看到 audio,video是同步的,虽然有时候会卡,但 顺畅之后还是保持同步.
不过,在 log消息里,将等级设为2,可以看到 很多 pts late,audio buffer,什么 drop buffer ,upsampling等消息.感觉,
vlc为了同步,去除了很多 不理想的数据?
请问,这个vlc这是通过什么算法,来 判断 哪些audio或者video数据不合理,从而选择丢弃,保持同步呢?
而我自己在自己实现的播放器代码里,也是调用了live库. 我自己的pts同步策略很简单.就是 将得到的 每个rtp数据包 所带的pts, 作为同步时间.当然要以第一个得到的数据pts为参考值,之后的与之相减. audio,video各自以 第一个作为参考值的.
但很明显,效果很不理想,播放之后,很快就不同步了. 声音总是慢慢的越来越之后 . 可见,我的同步算法太幼稚了.
我是假想 用live库从server上得到的pts应该,本身就是同步好了的.到我这边,我直接用就可以了. 可是,从现象来看,以及从 vlc的log来看, 似乎还需要做 pts的误差调整.
希望,哪位熟悉这个的,帮忙解解惑.应该怎么处理pts,才能维持好同步呢?
万分感谢~
在客户端 ,用vlc 以tcp来连接,基本上可以看到 audio,video是同步的,虽然有时候会卡,但 顺畅之后还是保持同步.
不过,在 log消息里,将等级设为2,可以看到 很多 pts late,audio buffer,什么 drop buffer ,upsampling等消息.感觉,
vlc为了同步,去除了很多 不理想的数据?
请问,这个vlc这是通过什么算法,来 判断 哪些audio或者video数据不合理,从而选择丢弃,保持同步呢?
而我自己在自己实现的播放器代码里,也是调用了live库. 我自己的pts同步策略很简单.就是 将得到的 每个rtp数据包 所带的pts, 作为同步时间.当然要以第一个得到的数据pts为参考值,之后的与之相减. audio,video各自以 第一个作为参考值的.
但很明显,效果很不理想,播放之后,很快就不同步了. 声音总是慢慢的越来越之后 . 可见,我的同步算法太幼稚了.
我是假想 用live库从server上得到的pts应该,本身就是同步好了的.到我这边,我直接用就可以了. 可是,从现象来看,以及从 vlc的log来看, 似乎还需要做 pts的误差调整.
希望,哪位熟悉这个的,帮忙解解惑.应该怎么处理pts,才能维持好同步呢?
万分感谢~
...全文
请发表友善的回复…
发表回复
dengzikun 2010-11-10
- 打赏
- 举报
楼主的做法只能实现媒体内的同步,不能实现媒体间的同步.
你的 假想 用live库从server上得到的pts应该,本身就是同步好了的.
这没问题,但是你的不是实时流,所以媒体数据到客户端的时间是受到客户端播放速度
控制的,也就是抖动会比较大.你可以参考DSHOW的音视频同步的办法,音视频用一个参考时钟,
早到的做缓存,到期播放,晚到的立即播放或丢弃. 当然,做这一切的前提是时间戳正确.
可以参考DSHOW的CBaseRender.
你的 假想 用live库从server上得到的pts应该,本身就是同步好了的.
这没问题,但是你的不是实时流,所以媒体数据到客户端的时间是受到客户端播放速度
控制的,也就是抖动会比较大.你可以参考DSHOW的音视频同步的办法,音视频用一个参考时钟,
早到的做缓存,到期播放,晚到的立即播放或丢弃. 当然,做这一切的前提是时间戳正确.
可以参考DSHOW的CBaseRender.
tufaqing 2010-11-10
- 打赏
- 举报
时间戳很关键，任何播放都是通过时间戳控制同步的，不能简单的处理，否则会不同步，如果偏差过大，缓冲区找不到要同时播放的数据，就会丢失比较快的包。
看这个情况，主要还是你的时间戳打得有问题。看一下你的音视频数据是怎么来的，一般有的自己带有时间戳。如果是抓的数据的话，可以以系统时间参考。
看这个情况，主要还是你的时间戳打得有问题。看一下你的音视频数据是怎么来的，一般有的自己带有时间戳。如果是抓的数据的话，可以以系统时间参考。
ear5cm 2010-11-10
- 打赏
- 举报
鲲哥：
谢谢你的帮忙 。我继续一头雾水。
之前，我对live server提供的 mpa/mpv的流，就是直接用 pts 来同步的，效果还行。
现在的这个 wowza server提供的 h264/mpa的流，效果就不行了。你说的“媒体间同步需要RTCP的时间戳”这个怎么理解呢？
因为我们的系统decoder那边，基本都是用pts来同步的。而理论上，只需要我这边 提供给decoder的接口buffer提供数据，和相应的pts。 其他的 好像 不需要我来管 。
所以，我觉得我需要处理的还是 pts 这个时间戳的 修正上？ （比较幼稚的想法是， 找个参照点，判断出当前时间戳 提前还是落后了，就对应 补上误差 。可是， 怎么来判断这个pts 提前还是落后， 不知，哎）
关于DSHOW，我完全没接触。。。
谢谢你的帮忙 。我继续一头雾水。
之前，我对live server提供的 mpa/mpv的流，就是直接用 pts 来同步的，效果还行。
现在的这个 wowza server提供的 h264/mpa的流，效果就不行了。你说的“媒体间同步需要RTCP的时间戳”这个怎么理解呢？
因为我们的系统decoder那边，基本都是用pts来同步的。而理论上，只需要我这边 提供给decoder的接口buffer提供数据，和相应的pts。 其他的 好像 不需要我来管 。
所以，我觉得我需要处理的还是 pts 这个时间戳的 修正上？ （比较幼稚的想法是， 找个参照点，判断出当前时间戳 提前还是落后了，就对应 补上误差 。可是， 怎么来判断这个pts 提前还是落后， 不知，哎）
关于DSHOW，我完全没接触。。。
dengzikun 2010-11-10
- 打赏
- 举报
你在A/V线程中分别使用A/V时间戳做定时播放，两个线程独立向前运行。
这样要做到A/V同步，需要两个条件：A/V时间戳正确，相应的A/V数据包同时到达，
现在你假设A/V时间戳是正确的，那么数据包同时到达是不可能保证的，这样，两个
线程的等待时间点会出现漂移，并且漂移会积累的很快，A/V很快就不同步了。
一个简单的解决办法就是，放弃时间戳，A/V分别按自己的帧率播放，当然，这个方法有局限性，
更适合实时流。
更好的办法可以参考DSHOW的时间戳。
这个问题的根源是因为RTP时间戳只能实现媒体内同步，媒体间同步需要RTCP的时间戳。你可以
参考MPEG2系统的媒体间同步方法，需要PCR在编解码器之间做时钟同步。
这样要做到A/V同步，需要两个条件：A/V时间戳正确，相应的A/V数据包同时到达，
现在你假设A/V时间戳是正确的，那么数据包同时到达是不可能保证的，这样，两个
线程的等待时间点会出现漂移，并且漂移会积累的很快，A/V很快就不同步了。
一个简单的解决办法就是，放弃时间戳，A/V分别按自己的帧率播放，当然，这个方法有局限性，
更适合实时流。
更好的办法可以参考DSHOW的时间戳。
这个问题的根源是因为RTP时间戳只能实现媒体内同步，媒体间同步需要RTCP的时间戳。你可以
参考MPEG2系统的媒体间同步方法，需要PCR在编解码器之间做时钟同步。
ear5cm 2010-11-10
- 打赏
- 举报
感谢 tufaqing ，dengzikun ~！
To dengzikun ：就像你说的 一切的前提是时间戳正确。 我现在就是假设的 我得到的 rtp包的 pts是正确的。用的rtpsource->curPacketRTPTimestamp()来取得的。 这些时间应该如何来 同步呢？理论上，我想，这些时间都是 server同步好，打在包里的 ，供client端来同步用。 能简单说下您的理解吗？谢谢~
To tufaqing ：我是用时间戳来同步。时间戳也是rtp包里，解析得到的。我看 audio，video都是以各自随机的一个值作为 时间戳的起点值，然后 根据fps递增的。“你说不能简单的处理”我就是很头疼，不知道怎么来有效的处理，因为我简单的将这些值 来比对，并不对。所以，能否请您给点建议呢？ 谢谢了
To dengzikun ：就像你说的 一切的前提是时间戳正确。 我现在就是假设的 我得到的 rtp包的 pts是正确的。用的rtpsource->curPacketRTPTimestamp()来取得的。 这些时间应该如何来 同步呢？理论上，我想，这些时间都是 server同步好，打在包里的 ，供client端来同步用。 能简单说下您的理解吗？谢谢~
To tufaqing ：我是用时间戳来同步。时间戳也是rtp包里，解析得到的。我看 audio，video都是以各自随机的一个值作为 时间戳的起点值，然后 根据fps递增的。“你说不能简单的处理”我就是很头疼，不知道怎么来有效的处理，因为我简单的将这些值 来比对，并不对。所以，能否请您给点建议呢？ 谢谢了
