WINCE下Avi splitter的Allocator

        公司有一颗硬件解码Video的ARM9芯片，我负责为其开发WinCE下的Decoder。在WinCE的平台下，自然而然就会采用DirectShow的架构来实现这些解码器。硬件可以支持MPEG4/H.264/H.263/VC1等格式，相应的我就应该提供对应的Filter来实现DirectShow架构下的解码。由于这些格式全都是硬件解码，因此对Video Stream流的内存有些限制。一个Stream流的buffer地址必须要8字节对齐，且在物理地址上要连续。正因为如此，如果上游的Splitter Filter传下来的视频编码数据本身已经是8字节对齐，且物理地址上连续的，那我就可以省去一步Memory Copy的工作，这样可以提高一点运行效率。

        我们知道DirectShow架构里，Filters之间的握手，上下游的Filter会相互协商来确定由谁来创建buffer(一般在Output Pin的DecideAllocator里面)。由于我的Decoder Filter对输入buffer有上面讲的限制，因此我希望由我的Decoder来创建Buffer。既然要创建Buffer，那么就应该在Input Pin里实现一个Allocator，专门用来创建首地址为8字节对齐，同时物理地址上连续的内存。我实现了这个Allocator，经过程序测试运行没有问题。但是当我用Avi Splitter Filter（微软提供，WINCE下Catalog SYSGEN_DSHOW_AVI)来连接我的Decoder Filter时，就出现了问题，解码器异常。这个异常经过调试（当然是打印了无数的信息、看花了无数次眼睛之后）发现，由于每次Avi splitter传给我的地址并不是8字节对齐的，而且物理地址上也并不确保连续。难道我的Allocator并没有起作用吗？可是程序的调试过程中，Avi Splitter的Output Pin每次都会来调用Input Pin中的GetAllocator，而且我返回给它的Allocator明明就是我创建的，用这个Allocator一定可以生成8字节对齐并且物理上连续的内存。

 

       没有办法了，只能硬着头皮继续调试汇编代码了（心里咒骂微软1000遍，谁让他们不开放源代码）。调试之后发现Avi Splitter的Output Pin得到我的Allocator后，迅速的又Release掉了我的Allocator，并且在NotifyAllocator调用中，传进了它的Allocator。继续跟踪才知道，之所以会迅速的Release掉我的Allocator是因为Avi Splitter在调用Allocator的QueryInterface时失败了。它Query的Interface是IAMDevMemoryAllocator。这个接口在有些微软的文档中会说它是过时的，但是至少WINCE5版本的Avi Splitter里它还是起作用的。关于这个接口的具体说明，可以自行去查找微软的相关文档。这个接口实现了板级的内存分配方式，也就是通过这个接口可以让Avi Splitter创建出物理上连续的内存。实现方法，我们可以让我们的Allocator类继承这个接口，并实现相应函数。虽然通过这个接口我提供了物理上连续的内存给Avi splitter，但是是不是意味Avi Splitter就能满足Decoder 8字节对齐的内存要求呢？答案是否定的。

 

        事实上，Avi Splitter通过IAMDevMemoryAllocator接口来创建了一个Cache，这个Cache用来存放从Avi文件中读取的数据流。Avi Splitter并不会将视频帧的数据重新Copy到另一个Buffer中。它会直接获取到视频帧在这个Cache中的偏移地址，将此地址直接传递到下游的Input Pin。所以我无法从Avi Splitter中得到每一帧的视频Buffer都是8字节对齐的。视频帧Buffer是否为8字节对齐完全取决于该视频帧在文件中的位置，而这个位置往往是不确定的。

 

       看来我只能放弃让Avi Splitter提供给我既是8字节对齐同时有是物理上连续的Buffer了。只能在我的Decoder中创建一个8字节对齐且连续的Buffer，每次解码时，将Avi Splitter传下来的数据Memory Copy到我的Buffer中，然后再去解码。虽然会损失一些效率，但是幸好每一帧的数据量并不大。