该笔记参考书籍《Developing Microsift Media Foundataion Application》，因此有不少是从该书中摘录的，如有侵权，不胜惶恐！
MF核心概念：component（组件），这里的组件类似于directshow的filter，即针对某一特定功能封装成一个component，该特定功能可以是解码，编码，渲染等等，通过把这些component组合，形成pipeline，就可以完成多媒体应用程序所需的各种功能，跟directshow链接filter一样，保持filter功能的独立性同时又提供灵活多变的组合功能。其实OpenGL也有pipeline一说，通过一道道工序完成最后屏幕中所想要输出的图形图像。
一个完整的文件播放pipeline，如下图所示（从《Developing Microsift Media Foundataion Application》书中复制而来）：
小的矩形框，例如“Audio decoder”、“Video decoder”即为component组件，整个的chain链路形成一个pipeline，完成文件播放功能。该链路可以切成3个部分：文件源、数据解码、渲染，在dshow里面则分别对应source filter，transform filter，render filter，但在MF里面有专门的术语，以下一一描述：
1. MF sources：对应图中的File source，源头的意思，用来产生数据以给后面组件处理，这里的数据可以是来自本地文件（如上图），也可以是来自网络。还应该注意的是该File source其实还做了音视频数据分离的工作，以分别针对后续组件（音频解码和视频解码)。
2. Media Foundation transforms (MFTs): 对应图中的Audio decoder和Video decoder，用来“转换”（transforms），解码嘛，很明显。
3. MF sinks：对应图中的Audio render和Video render，sink字面解释"渗透"、“下沉”，该组件可以用来做最终数据的渲染，也可以用来把数据发送至网络另一端，例如视频通话中把本地视频编码并在MF sinks中打包码流发送给网络另一端。
而以上三种类型component的连接，则是基于它们各自的输入输出类型，例如假设Video decoder的输入是h.264码流，输出是yuv图像，则它上游的file source的输出最起码能支持h.264码流输出，否则这两个component就连接不成功；同样video decoder的下游video render的输入类型也得是支持yuv图像输入的。可能以上描述不够严谨，但大致就是这个意思，到具体代码的时候再详加分析。
接下来要描述的是组件之间的数据传递，在MF中是以Media Sample来描述传递的数据，Media sample中还包括数据的属性（不仅仅是raw data）。DShow也是用的IMediaSample来传递数据，很和谐啊。
最后描述的是MF的调试工具，乖乖，名字是“topoedit”，骚年，DShow的是“graphedit”！windows sdk里面还有topoedit源码，不错哟，可以研究下。
谈谈感受，看完该章感觉和DShow结构模型类似，只是换了些说法，还没体会到MF的精髓啊！待续。。。