directshow filter cpu占用100%

[petera]

source filter是自己开发的,h264解码filter 用的ffdshow filter, 在程序内使用的智能连接，会再加上video renderer,把这三个filter连接上。接收到的h264数据放入我的source filter,就可以正常播放了。

现在的问题是，如果连接上后，IMediaControl run时，如果没有放入数据，cpu使用高，如果过一会有数据放入了，这时cpu使用就正常了。
在有数据放入的情况下，调用IMediaControl的run和Pause时，cpu使用正常，如果调用run--stop再run,cpu使用又过高了。


从工具上看，不管cpu使用正常，还是过高，线程切换次数高的是在我的source filter内。
source filter只有在run起来时，graph正常调用的，我没有去做什么，我的source filter是从例子ball例子改的。

有了解的朋友请帮忙。

[petera]

自己解决了，直接把总节写在网络笔记上了，copy过来分享。

在测试时发现，没有视频时要比有视频时cpu使用高很多，最后定位到zkfilter模块。filter连接好run后，FillBuffer会被自动调用，我们在FillBuffer内用数据填充buffer。

下面的是我们的filter的父类CSourceStream的代码
do {
while (!CheckRequest(&com)) {

IMediaSample *pSample;

HRESULT hr = GetDeliveryBuffer(&pSample,NULL,NULL,0);
if (FAILED(hr)) {
Sleep(1);
continue; // go round again. Perhaps the error will go away
// or the allocator is decommited & we will be asked to
// exit soon.
}

// Virtual function user will override.
hr = FillBuffer(pSample);

if (hr == S_OK) {
hr = Deliver(pSample);
pSample->Release();
........

filter连接好run后，GetDeliveryBuffer，看下游filter的buffer是否准备好，如果准备好，会返回，否则阻塞。然后调用我们的FillBuffer，我们把数据放入buffer, Deliver把放入buffer内的数据推下去，如果这时下游的filter要处理的数据已经完成，Deliver会返回，否则阻塞，直到下游戏filter处理完当前数据。

所以我们的FillBuffer调用的时间间隔，由下游戏filter对数据的处理时间决定，如果我们FillBuffer时没有放入数据，则下游filter处理基本不用时间，这样就会占用过多cpu,
所以在我们的FillBuffer时，如果我们还没有数据，就先sleep(1)下，可以解决占用cpu过多的问题。
在FillBuffer内 调用Imediasample 的SetTime可以给下游filter设置大概的处理时间，如果不用sleep(1)，仍然占用太多的cpu， 如果SetTime设置的时间间隔太大，视频显示有点问题。
source filter 每个输出pin单独一个线程，其中一个输出pin fillbuffer时sleep(1)不会对另一个输出pin 有影响。

[kerbel]

受用 谢谢
我接收端接收数据，当缓存空了，我就possmesagge给主线程去暂停，然后发现数据线程还是会在跑（一直调用fillbuffer），我在fillbuffer里如果buffer空了就直接return了，也没去settime；

然后我在数据线程里，在possmesagge后面加了sleep，发现数据线程不会一直在跑

我也不知道是不是和你一样的原因，也许只是绕过了问题.....帮俺分析下...谢谢