推模式Source Filter，打过时间戳之后，Deliver阻塞－－－－在线急等

[wuwenli]

开发了一个推模式的Filter，开始，没有打时间戳，根据过来的数据 直接 调用 FillBuffer 发送出去，播放一定时间之后，音视频明显不同步，音频明显滞后。我根据其中的 PTS，打上时间戳之后，音视频同步问题解决了，但是往往只能正常播放一段时间，整个发送视频的线程就会在FillBuffer之后的 Deliver中阻塞掉，我查看了阻塞前的音视频时间戳，并没有相差太大，也在合理的范围之内。而且音视频是两个线程，假如阻塞是为了等同步，那么音频还在正常的播放，视频再怎么快都不可能永远比音频快，怎么视频却永远的阻塞下去呢？

[wuwenli]

请 高手 赐教！！！分不够，说，立马加

[xjfox]

能把你的filter graph帖一下吗？这样比较好分析

[wuwenli]

呵呵，我是 在 wince上 做的，是这样的，从 网络上得到音视频流，并且包含 PTS，我就 根据 音视频流上面的 PTS进行 Deliver，采用 CSourceStream，自己写了一个 FIFO 来接收数据，CSourceStream 负责 FillBuffer。结果 就出现了 死锁现象，根据日志，Deliver之后，视频的 线程就阻塞了，请 指教

[wuwenli]

还有一个 现象，就是 由服务器循环发送的时候，当一遍播放结束之后，第二遍要播放的时候，我发现视频也阻塞掉了。
而其实我根本就没有用时间戳只是收到数据就Deliver，时间戳，只不过是我手工进行控制的。

[happydeer]

也有可能是audio sample的时间戳出了问题。audio sample的时间戳会影响graph的参考时钟，因此也会影响video的播放。

假设audio / video的时间戳序列是这样的，那么就会出现你说的这种现象。
audio: 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 2 - 3 - 4 - ...
video: 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - ...

建议你source filter后面暂时不要接directshow的audio / video renderer。随便接个dump filter。然后把整个序列的audio / video时间戳都打印出来，看看有没有异常。

[wuwenli]

多谢多谢，我一开始也是这样分析的，但是，我在 FillBuffer 里面把我要压的Sample 的时间戳都打印了出来，发现音频的时间戳确实是递增的。后来，我干脆不用时间戳，音视频的时间戳我都不打，根据传进来的Sample上面的时间，自己按顺序下发，调用 Deliver ，结果运行了一段时间之后，视频仍然出现了死锁现象，音频正常播放，请指教，谢谢

[momoFresh]

我的现在也没解决，准备编译一个debug版本的render filter。看看打印消息

[wuwenli]

请高手继续 支持小弟，多谢多谢！！！

[momoFresh]

我之前也遇到这个问题，帮你顶一下，希望解决之后能说一下方法！

[wuwenli]

那你现在又是如何处理的啊？阻塞解决了吗？

[aoosang]

这个问题还没有解决吗？？/
根据你的描述，简单提供一下建议：

1 如果你不介意同步的话，你可以在fillbuffer函数的结束处，调用一下psample-〉settime（NULL，NULL）；试验一下。

2 如果还不行，建议你贴出你的graph 图表。怀疑是你的下游的filter的提供的allocter有问题。

3 你也可以重新编译dshow的baseclass ，增加调试信息，跟踪一下CSourceStream::DoBufferProcessingLoop函数，在这个函数里会调用fillbuffer，向下游推送数据。

[aoosang]

4 如果还不行，继续找陆其明，他既然回复了你的帖子，你就要跟紧他

[wuwenli]

呵呵，多谢，我的 这个 下游的都是系统默认的filter，除了 解码器是 硬件解码，其他的都是默认的
我就是 在 CSourceStream::DoBufferProcessingLoop 里面进行观察的，发现 Deliver 就阻塞了

[wuwenli]

还没有解决问题啊。。。

[深圳市视酷信息技术有限公司]

mark

[SmallBigCat]

顶