转载,写的不错的一个关于dshow的文章

转载地址:http://blog.sina.com.cn/s/blog_a2e5bcda01019gkg.html

六、自己写一个“filter”(1)

(2012-12-04 09:40:59)
转载
标签:

directshow

filter

开发文档

分类: DirectShow开发文档翻译

DirectShow filter开发介绍

DirectShow基本类库

DirctShow开发包中包含了用来写一个filter要用到的一套C++类,推荐使用这些类来写自定义的filter,当然这也不是必须的,如果你想所有东西都自己实现。使用这些基本的类库,你要将源文件编译为静态库然后在项目中连接生成的.lib文件。

在基本类库中定义了一个根类:CBaseFilter,还有其他一些为了完成特定功能的继承自它的派生类,比如CTransformFilter,它继承自CBaseFilter,用来生成一个转换filter。创建一个filter,你要根据类库中提供的这些继承自CBaseFilter的类派生出自定义的类,然后完成它的功能,就像下面这样:

class CMyFilter : public CTransformFilter

{

private :

   // 声明自定义的变量和方法

public :

   // 重写CTransformFilter的方法

}

创建引脚 

一个filter必须包含至少一个引脚,引脚的数量可以在设计filter的时候指定,也可以在需要时filter在创建引脚。引脚类从CBasePin类或其派生类派生,如从CBaseInputPin类派生。引脚应该在filter类中被声明为变量。有些filter类中已经定义好了引脚,所以会直接继承这些引脚,但是如果是从CBaseFilter继承,就必须要自己声明引脚。

引脚协商连接

当filter graph manager试图连接两个filter时,引脚必须在一些方面达成一致,如果不能达成一致就会连接失败。通常,引脚会按照下面规则进行协商:

  • 传输机制:相连的filter是按照什么机制从输出引脚向输入引脚传输media sample的。是使用IMemInputPin接口(推模式)还是IAsyncReader接口(拉模式)。
  • 媒体类型:几乎所有引脚都使用媒体类型来描述它们可以传递的数据格式。
  • 分配器:引脚之间必须协商由那个引脚提供分配器,及分配的缓存大小、缓存数量等属性。

类库提供的基类中已经提供了协商的框架,而你在派生类要做的就是重写这些方法,完成所以协商细节。到底要重写哪些方法取决于继承的类、自定义filter要实现的功能。

处理、传递数据

大多数filter的主要功能就是处理和传递数据,不同类型filter的操作方式也有所不同:

  • 使用推模式的源filter会使用一个工作线程来持续不断地填充media sample并向下级传递。
  • 使用拉模式的源filter会等地其下级filter来请求一个sample,然后它才会写数据到一个空闲sample并向下级传递。驱动数据流动的线程由下级filter提供。
  • 转换filter接收sample、处理、向下传递。
  • 提交filter接收sample、按时间戳呈现。

支持COM

DirectShow filter是COM对象,基类中实现了支持COM标准的框架。

创建DirectShow filter

推荐使用基本类库来创建filter,可以按以下步骤执行:

  • 编译基本类库,添加环境(头文件、库文件)到项目中
  • 包含头文件:Streams.h
  • 使用__stdcall调用约定
  • 使用"多线程C运行时库"(debug/retail)
  • 包含.def文件(导出DLL接口方法)。下面是一个.def文件的例子,假定输出文件名为MyFilter.dll:

      LIBRARY MYFILTER.DLL

      EXPORTS

         DllMain                    PRIVATE

         DllGetClassObject         PRIVATE

         DllCanUnloadNow            PRIVATE

         DllRegisterServer          PRIVATE

         DllUnregisterServer        PRIVATE

  • 连接以下文件:

      debug:Strmbasd.lib、Msvcrtd.lib、Winmm.lib

      retail:Strmbase.lib、Msvcrt.lib、Winmm.lib

  • 在连接设置中选择“忽略默认类库”
  • 源代码中声明DLL入口点:

      extern "C" BOOL WINAPI DllEntryPoint(HINSTANCE, ULONG, LPVOID);

      BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)

      {

          return DllEntryPoint((HINSTANCE)hModule,dwReason,lpReserved);

      }

Filter如何连接

引脚连接

filter通过引脚连接,使用引脚上的IPin接口,输出引脚连接到输入引脚。引脚连接要协商媒体类型,媒体类型由AM_MEDIA_TYPE结构给出。

应用程序通过调用filter graph manager上的方法来连接filter,而不是调用filter或是pin上的方法。可以调用IFilterGraph::ConnectDirect或IGraphBuilder::Connect方法来连接指定的filter,也可以调用IGraphBuilder::RenderFile来间接连接filter。

连接filter首先要调用IFilterGraph::AddFilter来添加filter到filter graph中,添加后,filter graph manager会调用IBaseFilter::JoinFilterGraph来通知filter。

连接的大体过程如下:

    1. filter graph manager调用输出引脚上的IPin::Connect,传递一个指针到输入引脚

    2. 如果输出引脚接受连接,会调用输入引脚上的IPin::ReceiveConnection

    3. 如果输入引脚接受连接,连接成功

个别引脚支持“动态重连”,暂时不予讨论。

通常filter自上而下建立连接,也就是一个filter的输入引脚会先建立连接,然后是输出引脚(这里说的是对同一个filter而言,并非建立连接的一对引脚)。个别filter会使用相反的顺序建立连接,比如:MUX filter。

当一个引脚的Connect、ReceiveConnection方法被调用,它会验证是否支持该连接,不同的filter过程会有所不同,下面的一些通用的过程:

  • 检测媒体类型是否支持
  • 协商分配器属性
  • 在配对的引脚上查找需要的接口

协商媒体类型

当filter graph manager调用IPin::Connect建立连接时,有以下几种方式来指定媒体类型:

  • 完全类型:如果媒体类型被完全指定,那么引脚连接时媒体类型稍有出入,连接就会失败
  • 不完全媒体类型:如果mayortype、subtype、formattype之一是GUID_NULL,那么媒体类型为不完全类型,这时GUID_NULL作为通配符
  • 无限定媒体类型:如果filter graph manager使用空指针作为媒体类型,那么引脚连接时只要双方可就任意一种媒体类型达成一致,就可建立连接

一旦引脚之间建立了连接,那么媒体的完全类型就被确定。filter graph manager使用媒体类型来限定连接类型。

在协商过程中,输出引脚指定一种媒体类型并调用输入引脚上的IPin::ReceiveConnection。输入引脚可以接受或拒绝这种请求的媒体类型。会重复这种操作直到输入引脚接受了一种媒体类型的请求,或是输出引脚已遍历完所有支持的媒体类型,连接失败。

到底输出引脚是如何选择一种媒体类型向输入引脚请求的,这要依赖实际运行情况。在DirectShow基础类库中,输出引脚调用输入引脚上的IPin::EnumMediaTypes,它会返回一个遍历器,这个遍历器可以遍历出输入pin可支持的媒体类型。如果不行,输出引脚就要遍历自身支持的媒体类型。

处理媒体类型

在任何接收AM_MEDIA_TYPE类型参数的函数中,在对pbFormat变量取值前,都要先验证cbFormat、formattype的有效性。

if((pmt->formattype == FORMAT_VideoInfo)&&

   (pmt->cbFormat> sizeof(VIDEOINFOHEADER)&&

   (pbFormat != NULL))

{

    VIDEOINFOHEADER *pVIH = (VIDEOINFOHEADER*)pmt->pbFormat;

}

协商分配器

当引脚建立连接,它们需要一种机制来交换数据,这种机制叫作“传输机制”。两个相连的filter可以协商使用任一种它们都支持的传输机制。

最通用的传输机制是:本地内存传输。在这种机制中,媒体数据存储在主内存中。这种传输机制又分成两种模式:推模式和拉模式。在推模式中,源filter通过调用下级filter的输入引脚上的IMemInputPin接口来向下传递数据。而在拉模式下,下级filter通过调用上级filter的输出引脚上的IAsyncReader接口来请求数据。

在本地内存传输机制下,使用分配器来负责分配缓存,分配器支持IMemAllocator接口。连接的两个引脚共享用一根分配器。任意一个引脚都可以提供一个分配器,而输出引脚最终决定使用哪个分配器。

同样由输出引脚设置分配器的相关属性,比如创建多少缓存、缓存大小、内存对齐方式。输出引脚也可以根据输入引脚的需求来设置这些属性值。

在使用IMemInputPin建立连接时,即在推模式下,分配器按照下面的步骤完成协商过程:

    1. 根据具体情况,输出引脚决定是否调用IMemInputPin::GetAllocatorRequirements,这个方法会检查输入引脚对缓存的属性需求。通常输出引脚会尊重输入引脚的要求,除非有绝对理由不这么做。

    2. 根据具体情况,输出引脚绝对是否调用IMemInputPin::GetAllocator,向输入引脚请求一个分配器。输入引脚提供一个分配器,或返回错误。

    3. 输出引脚选择一个分配器:使用输入引脚提供的,或是自己创建一个。

    4. 输出引脚调用IMemAllocator::SetProperties设置分配器的属性(分配器可以不回应对属性的更改,这会发生在分配器由输入引脚提供的情况下)。分配器会将最终的实际属性作为输出参数返回。

    5. 输出引脚调用IMemInputPin::NotifyAllocator来通知输入引脚它对分配器的最终选择。

    6. 输入引脚调用IMemAllocator::GetProperties来验证分配器的属性是否可用。

    7. 输出引脚负责提交和反提交分配器。(当媒体流开始和停止时)

在使用IAsyncReader建立连接时,即在推模式下,分配器按照下面的步骤完成协商过程:

    1. 输入引脚调用输出引脚上的IAsyncReader::RequestAllocator。输入引脚要指定它对缓存的需求,当然,它可以自己提供一个分配器。

    2. 输出引脚选择一个分配器:有输入引脚提供的,或是自己创建的。

    3. 输出引脚将分配器作为IAsyncReader::RequestAllocator的输出参数返回。输入引脚要检查分配器的属性。

    4. 输入引脚负责分配器的提交和反提交。

    5. 在分配器协商过程的任何时候,任意引脚可以停止连接。

    6. 如果输出引脚使用了输入引脚提供的分配器,那么它只能传递数据到那个对应的输入引脚。

提供一个通用的分配器

这一节描述如何给一个filter提供自定义的分配器。这里只给出了推模式的描述,拉模式下,步骤类似。

首先,为自定义的分配器定义一个C++类,可以继承自一个标准分配器类,如CBaseAllocator、CMemAllocator。当然也可以完全自己实现,而且必须实现IMemAllocator接口。

剩下的步骤要取决于分配器属于filter中的输入引脚还是输出引脚。因为在分配器协商阶段,输入输出引脚扮演着不同的角色。

为输入引脚定义分配器

为输入引脚提供分配器,要重写输入引脚上的CBaseInputPin::GetAllocator函数,在这个函数内,检查m_pAllocator变量是否为空,如果不为空,说明已经选择了分配器,函数返回分配器指针。如果为空,说明还未选择分配器,要返回输入pin优先支持的分配器指针,这种情况下,创建自定义分配器的实例并返回IMemAllocator接口指针。下面代码给出了GetAllocator方法的实现:

STDMETHODIMP CMyInputPin::GetAllocator(IMemAllocator **ppAllocator)

{

    CheckPointer(ppAllocator,E_POINTER);

    if(m_pAllocator)

    {

       // 已经有了分配器,返回吧

        *ppAllocator = m_pAllocator;

        (*ppAllocator)->AddRef();

        return S_OK;

    }

   // 还没有分配器的话,就返回一个我们自定义的分配器

    HRESULT hr = S_OK;

    CMyAllocator *pAlloc = new CMyAllocator(&hr);

    if(!pAlloc)

    {

        return E_OUTOFMEMORY;

    }

    if(FAILED(hr))

    {

        delete pAlloc;

        return hr;

    }

   // 返回IMemAllocator接口

    return pAlloc->QueryInterface(IID_IMemAllocator,(void**)ppAllocator);

}

为输出引脚定义分配器

为输出引脚提供分配器,要重写CBaseOutputPin::InitAllocator函数来创建分配器的实例:

HRESULT MyOutputPin::InitAllocator(IMemAllocator **ppAlloc)

{

    HRESULT hr = S_OK;

    CMyAllocator *pAlloc = new CMyAllocator(&hr);

    if(!pAlloc)

    {

        return E_OUTOFMEMORY;

    }

    if(FAILED(hr))

    {

        delete pAlloc;

        return hr;

    }

   // 返回IMemAllocator接口

    return pAlloc->QueryInterface(IID_IMemAllocator,(void**)ppAllocator);

}

默认的,CBaseOutputPin类会先向输入引脚请求分配器,如果返回的分配器不适合,输出引脚就创建自己的分配器。如果强制使用自定义的分配器,你要重写CBaseOutputPin::DecideAllocator函数。但是这会导致一个问题,就是可能会影响到filter的连接,因为另一个filter可能也在请求使用它自己创建的allocator。

重连引脚

开发一个filter,除了要关心filter的连接过程,第二个要关心的就是数据的流动。

这一节就要详细描述数据如何在filter graph中流动,主要是针对“本地内存传输机制”,由前面章节可知,这种机制下是通过IMemInputPin或IAsyncReader接口来完成连接。

贯穿filter graph的数据主要分为两类:媒体数据、控制数据。媒体数据从上向下移动,主要包括视频帧、音频采样、MPEG包、流结束通知等。控制数据移动方向则相反,控制命令有定位命令、质量控制请求等。

传递采样

下面描述filter在推模式和拉模式下分别如何传递媒体采样。

推模式:传递媒体采样

输出引脚调用输入引脚上的IMemInputPin::Reveive或IMemInputPin::ReceiveMultiple来传递采样,后者比前者唯一的区别就是传递的数量,可以传递一个采样数组。输入引脚可以在上述方法中阻塞。如果希望阻塞呢,那么在重写IMemInputPin::ReceiveCanBlock方法时,要返回S_OK,否则返回S_FALSE。当然返回S_OK也并不是每次一直都阻塞,只是说明有发生阻塞的可能,到底会不会发生和具体运行过程相关。

尽管在Receive*方法内会发生阻塞去等待需要的资源,但是不可以是从上级filter等待数据或资源,因为上级filter可能也同时在等待下级filter释放一个媒体采样,这样就造成了死锁。如果一个filter上有多个输入引脚,那么一个输入引脚可以等待另一个输入引脚完成接收数据,比如AVI Mux filter就是这样来交替视频和音频数据的。

输入引脚可能因为以下原因而拒绝接收一个sample:

  • 引脚刷新数据
  • 引脚未连接
  • filter已停止
  • 其他错误发生

在第一种情况下,Receive*方法应当返回S_FALSE,其他情况会返回一个错误码。没上级filter收到返回结果不是S_OK时,就应当停止发送sample。

可以把前3种情况视为“可预知的错误”,看作这时filter不是处于接收状态。而第四种情况就是即使现在filter是处于接收状态,但是仍然因为某种不可预知的错误而拒绝了sample,这时该输入引脚就应该向下发送一个“流结束通知”,而且发送一个EC_ERRORABORT事件给filter graph manager。

在DirectShow基本类库中,用CBaseInputPin::CheckStreaming来检查常见的错误:刷新数据、停止等。传递数据的类需要检查自定义filter中指定的错误。当一个错误发生,CBaseInputPin::Receive就发送一个流结束通知和EC_ERRORABORT事件。

拉模式:请求媒体采样

输入引脚通过调用以下方法来向输出引脚请求媒体采样:

  • IAsyncReader::Request
  • IAsyncReader::SyncRead
  • IAsyncReader::SyncReadAliqned

其中Request方法是异步的,要调用IAsyncReader::WaitForNext来等待请求的完成。其他两个方法都是同步的。

传递数据的时机

filter通常在运行状态下会传递数据,暂停状态也会。这样可以提前调出数据,一旦调用Run方法运行就能立即开始回放。如果你的自定义filter在暂停状态下不想传递数据的话,那它的IMediaFilter::GetState方法在暂停状态应该返回一个VFW_S_CANT_CUE,这标识着在filter graph完成暂停转换前不会等待filter中完成数据调出。如果不返回这个标识的话,Pause方法就要无限期等下去了,等待调出数据。

下面是几个需要返回VFW_S_CANT_CUE的例子:

  • 现场采集源filter,在暂停时不应继续发送数据,提前调出的数据到下次运行时都是过时的数据。
  • 一个分离filter如果使用单独的线程来使各个输出引脚传递数据,那么在暂停时,它可以继续调出数据。但是当分离filter只使用一个线程传递数据,线程可能在其中一个引脚上调用Receive时阻塞,这时其他引脚就不能发送数据了,应该在这里返回VFW_S_CANT_CUE。
  • 一个filter可能会零零散散的传递数据。比如解析接收的数据,然后过滤掉一些内容,发送剩下的数据。这种情况下,将不能保证暂停时传递数据。

一个推模式的源filter或是一个解析filter会创建多个流线程来尽可能快地传递数据。而下级filter,比如解码filter、转换filter,经常是当其输入引脚上的Receive方法被调用时才会去执行传递数据的操作。

处理数据

解析媒体数据

如果你的自定义filter要解析媒体数据,千万不要信任内容header等其他一些自我描述数据。比如:不能相信AVI RIFF块、MPEG包中的size值。常见的这类错误有:

  • 从数据内容中获取了数据大小为N字节,然后不检查实际大小就直接读取N字节。
  • 不检查是否过界,直接在缓存数据中定位指针。

另一类常见的错误是不验证数据的格式描述,比如:

  • 在位图中,BITMAPINFO结构由颜色表和BITMAPINFOHEADER构成,紧跟着颜色表RGBQUAD数组的是一个BITMAPINFOHEADER结构。RGBQUAD数组的大小由biClrUsed指定,所以拷贝一个颜色表到BITMAPINFO之前要验证分配给它的内存大小。
  • 一个WAVEFORMATEX结构可能会紧跟着一些扩展格式信息,cbSize变量指定了扩展信息的大小。

引脚连接过程中,filter应当先验证所有的格式结构体格式合法并且具体合理值。如果验证发现问题,则拒绝连接。在验证格式结构体的代码中,尤其要注意算术溢出,比如:在一个BITMAPINFOHEADER结构中,width、height都是32位long值,但imagesize却是个DWORD值。

如果从数据源中得到的格式值比分配的缓存大,千万不要截断拷贝进缓存,这样会造成隐含尺寸比实际尺寸大(因为实际尺寸只是原始的一截),比如,一个位图头信息中可能指定了一个调色板,但是却不存在了。所以只能重新分配适合大小的缓存或直接连接失败。

流中的错误

当graph运行时,filter可能会接收到有缺陷的数据内容,这时它应该按以下步骤终止数据流:

  • 从Receive方法中返回一个错误码
  • 调用下级filter上的IPin::EndOfStream
  • 调用CBaseFilter::NotifyEvent发送EC_ERRORABORT事件

改变格式

有几种机制供filter在流传递过程中改变媒体格式,这造成了误接收的可能性。当你的自定义filter接收到一个动态转换格式的请求,它要么拒绝,要么以新格式来处理接收到的数据。同样,在另一个filter同意格式转换之后,当前filter才能切换数据格式并发送。

流结束通知

当一个源filter完成数据的发送后,要调用下级filter的输入引脚上的IPin::EndOfStream方法,然后下级filter继续向下重复这一过程。当“流结束通知”到达提交filter,它会向filter graph manager发送EC_COMPLETE事件。如果提交filter有多路输入,就会等待所有输入引脚接收到“流结束通知”后发送EC_COMPLETE。

filter应该序列化所有的流调用,也就是下级filter必须有序地接收这些流调用。

有时,下级filter可能会比源filter先察觉到流的结束。这时,下级filter会向下发送流结束通知,而对IMemInputPin::Receive要返回S_FALSE直到graph停止或是刷新数据结束。S_FALSE可以通知源filter停止发送数据。

对EC_COMPLETE的默认处理

默认的,filter graph manager并不会传递每一个EC_COMPLETE给应用程序,它只会等待所有流都发送了EC_COMPLETE事件,才会向应用程序发送一个EC_COMPLETE。

filter graph manager通过检查filter是否支持定位(IMediaSeeking/IMediaPosition接口)而且有“提交输出引脚”来确定有几个流。通过两种方法来确定一个引脚是不是“提交引脚”:

  • IPin::QueryInternalConnections函数的nPin参数返回0。
  • filter提供了IAMFilterMiscFlags接口且返回AM_FILTER_MISC_FLAGS_IS_RENDERER标识。

拉模式下的流结束通知

源filter不发送流结束通知,而是由下级filter(如:解析filter)向下发送。

刷新数据(Flushing)

当filter graph在运行时,一些临时数据会在graph中移动,其中一些可能正在等待被传递。当filter graph需要删除这些待传递的数据并用新数据填充时,会需要一定时间。比如,应用程序发送定位命令后,源filter会从一个新位置来生成sample,为了达到最小延迟,下级filter应该丢弃所有定位命令之前的数据,这个过程就叫作“刷新数据”。当有改变发生在当前数据流上时,这个功能可以让graph响应更灵敏。

在推模式和拉模式下的刷新数据会稍有不同。

刷新数据有两个阶段:

  • 首先,源filter调用下级filter的输入引脚上的IPin::BeginFlush方法,然后下级filter就开始拒绝结束sample,并丢弃所有现有的sample,然后向下逐级调用BeginFlush。
  • 当源filter准备好发送新数据后,调用输入引脚上的IPin::EndFlush,通知下级filter可以接收新sample了,同样是会逐级向下调用EndFlush。

在BeginFlush中,输入引脚会做以下事情:

    1. 调用下级的BeginFlush。

    2. 拒绝所有的流数据调用请求,包括Receive、EndOfStream。

    3. 对等待allocator分配空闲sample的上级filter的阻塞调用进行解阻塞。一些filter是通过“反提交分配器”来实现的。

    4. 从所有阻塞流的等待中退出。比如,提交filter当暂停时会阻塞,当等待准确时间呈现sample时也在阻塞,它必须解阻塞,然后上级filter中等待被传递的sample才能被传递进而被拒绝。这一步保证了上级filter的解阻塞。

在EndFlush中,输入引脚做如下操作:

    1. 等待所有在队列中的sample被丢弃。

    2. 释放缓存数据,这个操作有时在BeginFlush中执行,但是,BeginFlush和流处理线程不同步。filter在BeginFlush和EndFlush的调用之间不能继续处理或缓存任何数据。

    3. 清除所有挂起的EC_COMPLETE通知。

    4. 调用下级EndFlush函数。

这时,filter就可以继续接收新sample了,可以保证所有sample都是新的。

在拉模式下,解析filter启动刷新数据,而不是源filter。它不仅要调用下级的IPin::BeginFlush和IPin::EndFlush,还要调用源filter输出引脚上的IAsyncReader::BeginFlush和IAsyncReader::EndFlush。如果源filter中有尚未处理的读数据请求,会全部丢弃。

定位

filter通过IMediaSeeking接口支持定位功能。应用程序中从filter graph manager上询问IMediaSeeking接口然后用它来处理定位命令。filter graph manager会把定位命令分发到graph中的所有提交filter。每个提交filter再依次通过输出引脚向上级传递定位命令,直到到达一个可以执行定位的filter。典型的执行定位filter就是源filter和解析filter,比如AVI Splitter。

当filter执行定位操作,它会刷新所有未处理的数据,来最小化定位延迟。定位命令执行后,“流时间”会重置为零。

下图说明了操作执行的顺序:

转载,写的不错的一个关于dshow的文章_第1张图片

如果一个解析filter不止一个输出引脚,通常指定其中一个来接收定位命令,其他输出引脚要拒绝并忽略定位命令。这样,解析filter就可以维持所有流的同步。但是,所有的输出引脚都应该执行IMediaSeeking::GetCapabilities和IMediaSeeking::CheckCapabilities来返回filter的定位能力,来保证filter graph manager返回正确的值到应用程序。

IMediaPosition接口已经被弃用了。一些自动化的客户端依然调用这个接口,filter graph manager会自动把对它的调用转换到IMediaSeeking的调用。

动态格式转换


线程和临界区

下面描述DirectShow filter中的线程,及开发中为避免冲突和死锁要做的处理。

流处理线程和应用程序线程

每个DirectShow应用程序都至少包括两个重要的线程:应用程序线程、一个或多个流处理线程。媒体采样在流处理线程上传递,而状态转换发生在应用程序线程上。源filter和解析filter创建“主流处理线程”,其他filter也会创建自己的工作线程来传递sample,这些工作线程也被看作是流处理线程。

有些函数需要在应用程序上调用,而另一些需要在流处理线程来调用,比如:

  • 流处理线程:IMemInputPin::Receive,IMemInputPin::ReceiveMultiple,IPin::EndOfStream,IMemAllocator::GetBuffer等
  • 应用程序线程:IMediaFilter::Pause,IMediaFilter::Run,IMediaFilter::Stp,IMediaSeeking::SetPositions,IPin::BeginFlush等
  • 任意线程:IPin::NewSegment等

使用独立的流处理线程可以保证graph中数据流动的同时,应用程序可以接收用户输入。但是,风险就是filter可能在暂停时在应用程序线程中创建资源,在流线程方法中使用,当停止时又在应用程序线程中销毁资源。一不小心,流线程中可能就会使用已经在应用程序线程中销毁的资源。对应的解决方案就是使用临界区,及使流处理函数和状态切换同步。

filter需要一个临界区来保护状态,CBaseFilter自身带有这么个变量:CBaseFilter::m_pLock。这个临界区被叫作“filter锁”。每个输入引脚也需要一个临界区来保护流线程要处理的资源,这种临界区叫作“流锁”,必须在自定义的引脚类中声明这种锁。最简单的就是使用CCritSec类,它封装了一个Windows CRITICAL_SECTION内核对象,这个类还提供了一些有用的调试函数。

当filter停止或刷新数据时,必须让应用程序线程和流处理线程同步。为了避免死锁,必须让流线程解阻塞。流线程阻塞的原因如下:

  • 在IMemAllocator::GetBuffer函数中等待sample,当分配器的sample暂时都被使用时。
  • 等待另一个filter从流处理函数中返回。像Receive函数。
  • 在自身的流处理线程中等待,比如等待某个资源可以被使用(当前被其他线程使用)。
  • 如果是提交filter,要等待准确时间来呈现sample。
  • 如果是提交filter,当暂停时,在Receive函数中等待。

因此,当一个filter停止或刷新数据时,一定要做如下处理:

  • 无条件释放它所持有的所有sample,可以让GetBuffer函数返回。
  • 迅速从流处理函数中返回。如果一个流函数在等待一个资源,必须立即停止。
  • 在Receive函数中拒绝接收sample,这样流处理线程就不会继续去占用新资源了。
  • stop函数中必须反提交所有filter的分配器。(CBaseInputPin类自动处理)

刷新数据和停止命令都发生在应用程序。调用IMediaControl::Stop后,filter graph manager会从提交filter开始向上级传递停止命令。在CBaseFilter::Stop中执行停止操作,该函数返回后,filter应该处于停止状态。

刷新数据通常是由定位命令引起。刷新命令从源filter或解析filter开始,向下传递。刷新信息分两个阶段:IPin::BeginFlush函数通知filter丢弃待处理的数据并拒绝到来的数据。IPin::EndFlush函数通知filter开始接收新数据。刷新需要两个阶段是因为BeginFlush的调用是在应用程序线程,这时流处理线程仍然在继续传递数据。因此,在BeginFlush调用后,依然有一些sample到达了filter而没来得及传递,filter应该丢弃它们。所有EndFlush调用后到来的sample可以保证都是新的,应该被传递。

后面的内容会包含一些重要函数的示例代码,有Pause、Receive函数等。这些示例中会考虑到死锁和资源竞争的问题。每个filter都不同,所以要小心把这些示例代码移植到你的自定义filter中。

注意:CTransformFilter和CTransInPlaceFilter基类会处理以下描述的部分操作,如果要写一个转换filter,这两个类已经可以实现一些基本的功能。

暂停

所有filter在状态转换时都必须被锁定,来创建filter需要的资源:

转载,写的不错的一个关于dshow的文章_第2张图片

CBaseFilter::Pause函数设置了filter的正确状态(State_Paused)并调用CBasePin::Active函数来通知filter上的引脚这个filter已经激活了。如果引脚要创建资源,就重写Active方法:

转载,写的不错的一个关于dshow的文章_第3张图片
接收和传递媒体采样

下面是IMemInput::Receive函数的伪代码:
转载,写的不错的一个关于dshow的文章_第4张图片

Receive方法保持流锁定,而不是filter锁定。filter可能在处理数据之前要像上面代码中那样等待某个事件WaitForSingleObject,但这不是必须的。CBaseInutPin::Receive方法验证流状态,如果流停止则返回VFW_E_WRONG_STATE,如果是在刷新数据则返回S_FALSE。只要返回的不是S_OK,就说明函数要立刻失败返回。sample被处理后,要调用CBaseOutputPin::Deliver向下传递。一个filter可以把数据传递到多个引脚。

传递“流结束通知”

当输入引脚接收到流结束通知,它要向下传递该通知。任何一个从该引脚接收数据的下级filter都应该获得该通知。这里同样要设置流锁定,而不是filter锁定。当一个filter接收到流结束通知,而它还有些数据没有来得及传递,应该马上传递下去,然后发送流结束通知到下级,之后就不能再发送任何数据。

转载,写的不错的一个关于dshow的文章_第5张图片

CBaseOutputPin::DeliverEndOfStream方法会调用下级filter输入引脚上的IPin::EndOfStream。

刷新数据

下面是IPin::BeginFlush的伪代码:

转载,写的不错的一个关于dshow的文章_第6张图片

当刷新开始,BeginFlush函数启用filter锁定。现在还不能启用流锁定,因为刷新数据发生在应用程序线程,流线程可能在Receive方法中。需要先保证Receive方法没有阻塞且下面的调用都会失败。CBaseInputPin::BeginFlush函数设置一个内部标识m_bFlushing,当为TRUE时,Receive会失败。

通过向下级传递BeginFlush,保证所有的下级filter都释放sample并从Receive返回。首先是保证输入引脚从GetBuffer、Receive解阻塞。如果引脚仍在Receive方法上等待,BeginFlush就强制其返回。并且m_bFlushing标识会阻止后续的对Receive的调用。

对一些filter来说,上面就是它的全部工作了,然后EndFlush方法会通知filter重新开始接收新数据。另一些filter可能要在BeginFlush中要使用到一些数据,而这些数据在Receive中也会使用。这时,要先启用流锁定,不然有可能造成死锁。

EndFlush函数启用filter锁定,并依次向下传递:

转载,写的不错的一个关于dshow的文章_第7张图片
CBaseInputPin::EndFlush函数将m_bFlushing重置为FALSE。这样Receive才能重新接收sample。当然这要在EndFlush的最后才做,因为刷新数据完成之前还不能让filter能接收新数据。
停止

Stop方法应该解阻塞Receive方法并反提交filter的分配器。反提交分配器会强制GetBuffer的调用返回,会解阻塞上级filter的等待。Stop函数启用filter锁定,然后调用CBaseFilter::Stop方法,这个方法会调用所有引脚的CBasePin::Inactive:

转载,写的不错的一个关于dshow的文章_第8张图片

重写Inactive方法:

转载,写的不错的一个关于dshow的文章_第9张图片
获取缓存

如果你的filter有一个自定义的分配器,该分配器会使用filter资源,那么GetBuffer函数应该和其他流函数一样启用流锁定:

转载,写的不错的一个关于dshow的文章_第10张图片
流线程和滤镜图表管理器

当filter graph manager停止图表时,它要等待所有的流线程关闭。这对filter有如下影响:

  • filter不能在流线程中调用filter graph manager上的方法。

    filter graph manager使用临界区来同步各项操作,如果一个流线程试图控制这个临界区,可能导致死锁。比如:假如另一个线程停止了graph,这个线程占用了filter graph锁并等待你的filter停止传递数据。而你的filter中在等待这个锁,就造成死锁了。

  • filter不能在流线程中对filter graph manager增加引用、询问接口。

    如果filter通过AddRef、QueryInterface来控制filter graph manager的引用计数。可能会成为最后唯一一个引用filter graph manager的对象。当这个filter释放时,filter graph manager也要销毁自己。在销毁代码中,filter graph manager试图停止graph,于是等待流线程退出。但是在流线程内部也处于等待状态,于是死锁了。


DirectShowCOM

如何实现IUnknow接口

DirectShow基于组件对象模型,所以你要些自己的filter,就必须把它实现成一个COM对象。DirectShow基本类库提供了相关的框架,它可以简化开发过程。下面会描述一些COM对象知识和在DirectShow基本类库中是如何实现的。

下面的文章假定读者能够编写COM客户端程序---即,读者直到如何使用IUnknown接口。但并不需要读者一定会独立编写一个COM对象。DirectShow处理了开发COM对象的许多细节。

COM是一种规范,而不是任何实现代码。它定义了开发组件要遵守的规则,具体怎样来开发符合规则的应用要开发人员自己处理。在DirectShow中,所有对象都是从一系列C++基类派生。基类的构造函数和方法做了大部分COM工作,比如保持引用计数。当你的filter从基类派生,要继承基类的方法。为了更有效的使用基类,你需要大概理解这些基类如何实现COM规范。

IUnknown接口如何工作

通过IUnknown接口,可以询问组件上支持的接口,还可以管理组件的引用计数。

引用计数

引用计数是一个内部变量,通过AddRef、Release来增加、减小引用计数。基类管理引用计数并控制多线程中引用计数的同步使用。

询问接口

询问接口也很简单,调用者传递两个参数:接口ID、接口指针地址,如果组件支持这种接口,就会返回接口指针到传入的指针地址,并增加接口引用计数,然后返回S_OK。否则,返回E_NOINTERFACE。

你可能感兴趣的:(转载,写的不错的一个关于dshow的文章)