seeking问题

[momoFresh]

我在source filter的pin上继承了CSourceSeeking，可以正常播放，现在想实现seeking的功能。

ChangeStart（），ChangeStop(），UpdateFromSeek()等函数都参照msdn上ball的方法实现。
因为我在video transform filter中有个bufferlist，所以需要在BegainFlush中进行flush操作。由于receive（）和Flush函数都会对bufferlist进行操作，所以尝试使用Transform Filter基类中的 CCritSec m_csReceive 来进行lock。但是发现在flush()函数中只要一加这把锁，程序在seeking时就会死在那边。我也尝试过使用自定义的CCritSec object，但是还是会死掉。从基类上看，如果我在flush中使用m_csReceive来进行lock，那么receive和flush就应该是串行了，应该不会有问题，奇怪了。

HRESULT DecoderFilter::flush()
{
HRESULT hr = S_OK;
ra_buffer * pTemp = NULL;
CAutoLock lck(&m_csReceive);

/*Flush the framebuffer list*/
while(framebuffer.pOutBufList)
{
/*flush this buffer list*/
}

DEBUGMSG(1,(TEXT("flush()! \r\n")));
return hr;
}

HRESULT DecodeFilter::BeginFlush(void)
{
HRESULT hr = NOERROR;
if (m_pOutput != NULL)
{
// block receives -- done by caller (CBaseInputPin::BeginFlush)

// discard queued data -- we have no queued data
hr = flush();
if(FAILED(hr))
{
return hr;
}
// free anyone blocked on receive - not possible in this filter

// call downstream
hr = m_pOutput->DeliverBeginFlush();
}
return hr;

}

还有就是如果不加锁的话，flush的同时receive并不能被block住。

高手帮忙看看一下，谢谢了！

[xjfox]

用m_csReceive肯定不行，beginflush和receive本来就不是一条线上的，为什么要让他们串行执行？

[momoFresh]

最近有事，没有上来看，呵呵。

“beginflush和receive本来就不是一条线上的，为什么要让他们串行执行？”
主要是因为我在receive里面有一个自己的bufferlist，那么在flush的时候需要将它清空，如果没有锁来控制这个区域的话，两个线程同时读这个bufferlist，肯定会出问题的。

如果没有什么好办法，我就只能把bufferlist去掉，麻烦啊，呵呵

[momoFresh]

自己钻进死胡同了，晕死！结贴，呵呵