不过，FLV也分FLV1和FLV4二种格式。（二者的文件后缀名都是FLV，但在电脑上用KMPLAYER播放时，FLV4的文件会有提示）

FLV1主要在欧美和中国的视频网站流行，特点是体积小，在线播放流畅，但清晰度低。

而FLV4是近年在日、韩视频网站开始流行的新格式，特点是解析度普遍在400*300以上，同等画面尺寸下，要比FLV1清晰得多，色彩饱和度也特别浓郁。缺点是，文件比较大，在线播放经常停顿。

我从日韩视频网站上搜集、下载了不少日韩歌星MV的FLV视频，格式当然是FLV4的。 很想知道，国内的MP4是否能直接播放FLV4的格式？

恳请有知道的朋友能指点一下

问题补充：不好意思,我不是笼统地指MP4是否支持FLV，而是特指FLV4格式，因为我知道是有几款MP4支持FLV1。

据说，二种FLV的视频编码格式不同，FLV1的视频编码格式是Sorenson H.263或H.264，而FLV4则是ON2 VP6 。

FLV4在线视频片段观赏:
http://tclon2.com/index.htm

MC目前还办不到，我见过FLV4格式，是比较清楚。
你可以用MC转成MP4（H.264+AAC），再修改后缀为FLV，FLASH播放器可以直接调用播放，效果同样非常好，不比On2VP6+MP3差.

On2 VP6-S 高清视频
On2 VP6-S编码器是Adobe Flash Player的新伙伴，专为播放高清内容而设。比较H.264 (AVC)及其他同类技术，为 Adobe® Flash® Player 而设的On2 VP6-S能以较低的数据传输率及处理器利用率，输出一流的高清影像。

压制flv4视频参考地址：http://sk.sosg.net/post/45.htm
On2 VP6和Sorenson Spark 视频编解码器比较：http://hi.baidu.com/jinzhou_shi/blog/item/0b249beffbde2c32adafd501.html
土豆网为网络视频选用On2 VP6技术，有效节省带宽成本：http://www.eetchina.com/ART_8800558976_621496_NT_ae7228dc.HTM

早期的Realplayer Pluse播放器

RMVB源自于Real Network公司的RealMedia(RM)格式，该公司是拥有悠久历史，在网络媒体上具有强大的技术力量。RealMedia普遍的特点是体积小，能够适应非常窄的网络带宽，RMVB是原有的RM格式的改进，从RM9开始支持VBR编码模式，并且改进了编码算法，使其具有更高的要缩率和品质。它的推出在一定程度上弥补了一些原有的缺憾。相对于随身领域而言，RMVB格式最大的优势莫过于动态比特率，“雾化”技术和无须转换这三点了。

现在的RealOne Player

区别与之前的RM格式，RMVB最大的特色就是加入了VBR技术，也就是Variable Bit Rate（可改变之比特率）的英文缩写。VBR编码是多媒体文件广泛使用的编码方式，例如常见的Mp3、wma、mpeg1、2、4都支持VBR编码模式！以往我们在播放常见的RM格式电影时，可以在某些播放器看到“xxxKbps”字样，这就是比特率。影片的静止画面和运动画面对压缩采样率的要求是不同的，如果始终保持固定的比特率，会对比特利用造成浪费。 RMVB打破了原先RM格式那种平均压缩采样的方式，在保证平均压缩比的基础上，编码器会根据画面变化的复杂程度设定动态的不同的位率，最高位率一般为平均平均位率两倍的最大位率。将较高的比特率用于复杂的动态画面（歌舞、飞车、战争等），而在静态画面中则灵活地转为较低的采样率，合理地利用了比特率资源，使得在牺牲少部分影片质量情况下最大限度地压缩了影片的大小，最终拥有了和固定比特率编码的文件相近的视听效果，可谓体积与清晰度“鱼与熊掌兼得”。

除了动态比特率外，RMVB格式与传统视频格式另一个最大的区别就在于：压缩文件时RMVB采用的特殊的“雾化”技术，而不是传统丢帧的方式。从平时的使用中，我们就可以看出来，一般播放RMVB格式的文件，在放大到一定程度或者全屏时，画面会显得模糊，而不是出现“马赛克”现象。这就是RMVB格式的优势。在很低的位率下，画面会显得很朦胧，但不会出现色块。而位率超过700kbps之后其画质开始步入DVDRip！因此RMVB可以在非常低的位率实现相当好的效果。

就目前的市场来看，歌美X750，艾诺V2000等几款产品，都采用了主频达到500MHz的ADI Blackfin 533处理器，这样一来网络上超过85%的RMVB文件都可以直接在MP4播放器上直接播放了。而我们从网上下载的绝大多数RMVB电影显示都超过了480P，而这个在电脑上播放的分辨率换到屏幕尺寸相对较小的MP4播放器时，清晰度就大大提高了，换句话说，由于没有进行二次的转换压缩，配合RMVB格式本身特殊“雾化”技术和动态比特率两个优势，实现了另一种形式的“高清”！在随身播放器容量不断增大的今天，我们可以轻松的播放器中拷入多部电影。而无须转换，直接播放，并且比以往任何一种二次压缩的视频格式更加清晰，流畅！这就是直接支持RMVB格式播放器相对于现有视频播放器最大的优势所在！

MP3是今天一种常见的音乐格式，但恐怕除了工作要求之外，有兴趣对此进行研究的人恐怕不多。所以，当我打算做MP3解码方面的工作时，在找资料时也颇费了一番周折，同时也觉得很有趣。所以想在这里分享一下自己的心得，做一个总结性的介绍。这样有兴趣的同志也可以对此有一个大概了解，尽快入门。

MP3是MPEG-1 Audio Layer 3的简称，是当今比较流行的一种数字音频编码和有损压缩格式（有Layer 3，也必然有Layer1和Layer2，也就是MP1和MP2，但不在本文讨论范围之内）。MP3技术的应该可以用来大幅度的降低音频文件存储所需要的空间。它丢掉脉冲编码调制（PCM）音频数据中对人类听觉不重要得数据，从而达到了较高的压缩比（高达12：1－10：1）。简单地说，MP3在编码时先对音频文件进行频谱分析，然后用过滤器滤掉噪音电平，接着通过量化的方式将剩下的每一位打散排列，最后形成有较高压缩比的MP3文件，并使压缩后的文件在回放时也能够达到比较接近原音源的效果。

MP3的音频质量取决于它的Bitrate和Sampling frequency，以及编码器质量。MP3的典型速度介于每秒128到320kb之间。采样频率也有44.1，48和32 kHz三种频率，比较常见的是采用CD采样频率——44.1kHz。常用的编码器是LAME，它完全遵循LGPL的MP3编码器，有着良好的速度和音质。

2，      MP3文件格式

用一个二进制查看器（比如Ultra-Edit）打开一个MP3文件，就能看到一大堆看似杂乱无序的数据。但只要用心了解就会知道，其实，这一切都是有规律可循的。

MP3文件是由帧（frame）构成，帧是MP3文件的最小组成单位。每帧都包含帧头，并可以计算帧的长度。根据帧的性质不同，文件主要分为三个部分，ID3v2标签帧，数据帧和ID3v1标签帧。并非每个MP3文件都有ID3v2，但是数据帧和ID3v1帧是必须的。ID3v2在文件头，以字符串“ID3”为标志，包含了演唱者，作曲，专辑等信息，长度不固定，扩展了ID3V1的信息量。ID3v1在文件结尾，以字符串“TAG”为标记，其长度是固定的128个字节，包含了演唱者、歌名、专辑、年份等信息。

I, ID3V2

ID3V2到现在一共有四个版本，但流行的播放软件一般只支持第三版，既ID3V2.3。每个ID3V2.3 的标签都一个标签头和若干个标签帧或一个扩展标签头组成。关于曲目的信息如标题、作者等都存放在不同的标签帧中，扩展标签头和标签帧并不是必要的，但每个标签至少要有一个标签帧。标签头和标签帧一起顺序存放在MP3 文件的首部。

标签头

长度为10个字节，位于文件首部，其数据结构如下：

char Header[3]; /* 字符串 "ID3" */

char Ver;       /* 版本号ID3V2.3 就记录3 */

char Revision; /* 副版本号此版本记录为0 */

char Flag;     /* 存放标志的字节，这个版本只定义了三位，很少用到，可以忽略 */

char Size[4]; /* 标签大小，除了标签头的10 个字节的标签帧的大小 */

标签大小为四个字节，但每个字节只用低7位，最高位不使用，恒为0，其格式如下：
0xxxxxxx 0xxxxxxx 0xxxxxxx 0xxxxxxx

计算公式如下：

ID3V2_frame_size = (int)(Size[0] & 0x7F) << 21
                 | (int)(Size[1] & 0x7F) << 14
                  | (int)(Size[2] & 0x7F) << 7
                  | (int)(Size[3] & 0x7F) + 10;

标签帧

每个标签帧都有一个10字节的帧头和至少一个字节的不固定长度的内容组成。它们是顺序存放在文件中，由各自特定的标签头来标记帧的开始。其帧的结构如下：

char FrameID[4];   /*用四个字符标识一个帧，说明其内容 */

char Size[4];      /* 帧内容的大小，不包括帧头，不得小于1 */

char Flags[2];     /* 存放标志，只定义了6 位，此处不再说明 */

常用帧标识：

TIT2：标题
TPE1：作者
TALB：专辑
TRCK： 音轨，格式：N/M，N表示专辑中第几首，M为专辑中歌曲总数
TYER：年份
TCON：类型
COMM：备注，格式：“eng\0备注内容”，其中eng表示所使用的语言
帧大小为四个字节所表示的整数大小。

II, ID3V1

其数据结构如下：

char Header[3];    /* 标签头必须是"TAG"否则认为没有标签 */
char Title[30];    /* 标题 */
char Artist[30];   /* 作者 */
char Album[30];    /* 专集 */
char Year[4];      /* 出品年代 */
char Comment[28]; /* 备注 */
char reserve;      /* 保留 */
char track;;       /* 音轨 */
char Genre;        /* 类型 */

其实，关于最后31个字节还存在另外一个版本，就是30个字节的Comment和一个字节的Genre.

有了上述的这些信息，我们就可以自己写代码，从MP3文件中抓取信息以及修改文件名了。但是，如果真的想写一个播放软件，还是需要读它的数据帧，并进行解码。

III, 数据帧

数据帧往往有多个，至于有多少，由文件大小和帧大小来决定。每个帧都有一个四字节长的帧头，接下来可能有两个字节的CRC校验，其存在由帧头中的具体信息决定。接着就是帧的实体数据，也就是MAIN_DATA了。

A,帧头结构如下：

位置     长度     描述
（BIT）  （BITS）
————————————————————————————
31－19   12       Frame sync(0xFFF)
18/17    2        Layer, 00 – reserved, 01 – Layer III
                         10 – Layer II, 11 － Layer I
16       1         protection_bit, 0 意味着受CRC保护，帧头后面跟16位的CRC。
15-12    4        bitrate_index, 比特率
11-10    2        sampling_frequency,    00 – 44.1KHz, 01 – 48KHz
                                         10 – 32 KHz,  11 – 保留
9        1        padding_bit,1 意味着帧里包含padding位，仅当采样频率为44.1KHz时发生。
8        1        private_bit
7－6     2        mode,    00－stereo,        01-joint stereo(intensity stereo and/or ms_stereo)
                           11- dual_channel, 11 – single_channel
5-4      2        mode_extension,在Layer III中表示使用了哪一种joint stereo编码方式。
                            Intensity_stereo   ms_stereo
                   00            off                off
                   01            on                 off
                   10            off                on
                   11            on                 on
3        1        copyright,1 表示受版权保护。
2        1        original，0表示该bitstream是一个copy，1表示是original.
1-0      2        emphasis，表示会使用哪一种de-emphasis。
                   00 － no emphasis,     01 – 50/15 microsec. Emphasis
                   10 – reserved,        11 – CCITT J.17

1)      无论帧长是多少，每帧的播放时间都是26ms

2)      数据帧大小：

FrameSize = 144 * Bitrate / SamplingRate + PaddingBit
当144 * Bitrate / SamplingRate不能被8整除，则加上相应的paddingBit.

B,MAIN_DATA:

MP3的granule包含18 * 32个subband采样。每个数据帧含有两个granule的数据，其内容结如下：
       - main_data_end pointer
       - side info for both granules (scfsi)
       - side info granule 1
       - side info granule 2
       - scalefactors and Huffman code data granule 1
       - scalefactors and Huffman code data granule 2

主要数据里包含了scalefactors, Huffman encoded data和ancillary information。其内容不再详叙，可以参考MP3 SPEC－IS0 11172-3 AUDIO PART。我们一般用的都是立体声，scfsi的长度为32个字节。

这里要解释的一个概念就是位流――bitstream。我们平常接触到的数据都是整数，最小的单位就是byte后者char。虽然我们也会用一个字节里的不同位来表示不同的含义，但总的来说，我们在出来数据的时候还是把它当作一个个字节看待。但对MP3这种数据格式来说，这是行不通的。在解码时，它的数据输入就是一个个比特流。其中一个或几个比特会是你的采样数据或者信息编码。你需要从整个MAIN_DATA里提取你所需要的以BIT为单位的参数和输入信号，从而进行解码。所以我们需要一个子程序，getbit(n)，也就是从缓冲中提取所需要的位，并形成一个新的整数，作为我们的输出。

C,LAME标签帧

可是，当你真的打开一个MP3文件的时候，你会发现，很奇怪，很多时候第一个数据帧的帧头后面的32个字节居然都为0，这是为什么呢，这么奇怪的解码信息该如何解释？找到MP3 INFO TAG REV SPECIFICATION的网站，我才明白，原来第一帧并不是真正的数据帧，而是LAME编码的标志帧。

这里又要牵涉到两个概念：CBR和VBR。CBR表示比特率不变，也就是每帧的长度是一致的，它以字符串“INFO”为标记。VBR是Variable BitRate的简称，也就是每帧的比特率和帧的长度是变化的，它以字符串“Xing”为标记。同时，它还存放了MP3文件里帧的总个数，和100个字节的播放总时间分段的帧的INDEX，还有其他一些参数，这被称为Zone A，传统Xing VBR标签数据，共120个字节。

在二进制文本编辑器里我们还可看到一个字符串“LAME”，并且后面清楚地跟着版本号。这就是20个字节的Zone B初始LAME信息，表示该文件是用LAME编码技术。接下来一直到该帧结束就是Zone C－LAME标签。

3，      相关资料

× Mp3 Info Tag rev 1 specifications - draft 0

× MP3 文件格式

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1688758

MEncoder 是常用的离线编码器，属于 mplayer 项目的一部分，这里介绍了怎样用 MEncoder 编码常见的视频流。

首先，要安装 x264 编码库，mplayer 需要这个库才能加上 H. 264 编码支持:

$ git clone git://git.videolan.org/x264.git
$ cd x264
$ ./configure
$ make && sudo make install

注意 x264 库需要 yasm 汇编器，MacPorts 下可以用 sudo port install yasm 安装。

然后编译 mplayer (包括 mencoder)。

$ svn co svn://svn.mplayerhq.hu/mplayer/trunk mplayer
$ cd mplayer
$ ./configure # 注意输出中是否有 "Checking for x264 ... yes" 字样
$ make && sudo make install

然后就可以调用 MEncoder 了:

$ mencoder input.fmt -o output.fmt -ovc x264 -oac copy -x264encopts \
    bframes=4:b_pyramid:weight_b:pass=1:psnr:bitrate=1500:turbo=1

其中 input.fmt, output.fmt 分别是输入和输出文件，其调用格式见 MEncoder 的文档，而后面 -x264encopts 的参数制定的是 x264 编码参数，这是影响编码质量和速度的地方，文档中也有专门一节详细说明，这里选取的是一个中等偏上的效果。

# make
gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I"/home/yujingtao/soft/ffmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -fasm -std=c99 -fomit-frame-pointer -pthread -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wcast-qual -Wwrite-strings -O3 -fno-math-errno       -c -o libavdevice/v4l.o libavdevice/v4l.c
In file included from libavdevice/v4l.c:32:
/usr/include/linux/videodev.h:55: error: syntax error before "ulong"
/usr/include/linux/videodev.h:71: error: syntax error before '}' token
libavdevice/v4l.c: In function `grab_read_header':
libavdevice/v4l.c:77: error: storage size of 'tuner' isn't known
libavdevice/v4l.c:141: error: invalid application of `sizeof' to incomplete type `video_tuner'
libavdevice/v4l.c:148: error: invalid application of `sizeof' to incomplete type `video_tuner'
libavdevice/v4l.c:77: warning: unused variable `tuner'
make: *** [libavdevice/v4l.o] 错误 1

vi /usr/include/linux/videodev.h

查找rangelow, rangehigh;      /* Tuner range */这一行
把  ulong rangelow, rangehigh;      /* Tuner range */
改为：
     unsigned long rangelow, rangehigh;      /* Tuner range */

参考：
http://www.2hei.net/mt/2008/08/ffmpeg-3gp-install.html

　　Super是一个免费的媒体转换器，使用图形界面的前端，后端是几个强大的命令行工具，如FFmpeg、MEncoder和MPlayer.这个转化器拥有广泛的应用，且可以根据用户的喜好进行定制选项，几乎可以转换任何类型的文件。缺点是操作控制和使用较为混乱，初次使用会感到设置较为麻烦。

　　FormatFactory (Windows)

　　Format Factory是一个基于Windows的免费的媒体转换器，可以转换视频，音频，甚至图片格式。Format Factory有美观大方的图标驱动的界面，易于使用，并可以进行批量的媒体转换。

　　MediaCoder (所有平台)

　　MediaCoder是一个批处理媒体格式转换器，可以转换大多数流行的视频和音频格式。和Super类似，MediaCoder也是前端图形界面，后端为大量命令行工具，MediaCoder目前在所有平台都可使用，但对Windows的支持最好。MediaCoder还为iPhone、iPod touch和PSP提供特殊设备接口。

　　HandBrake (所有平台)

　　HandBrake是一个颇受欢迎的开放源码媒体转换器，可以将DVD视频编码转换为多种流行的输出格式。具有在图形和命令行两种用户界面，HandBrake仅能够转换MPEG视频（包括DVD视频），是一个很好的DVD转换工具。

　　FFmpeg (所有平台)

　　FFmpeg是免费的、跨平台的命令行编码格式转换工具，上面介绍的不少图形化工具实际上都是后台调用FFmpeg的，虽然FFmpeg的易用性较差，但不可否认FFmpeg是强大而灵活的，FFmpeg使用命令行来进行格式转换。

　　英文原文：Five Best Media Converters

功能和特点

• 基于优秀的众多的开源编解码后台，能够解码和编码的格式多
• 良好的多线程设计，为多核处理器和多处理器系统优化(PCPOP评)
• 极为丰富的可调整的编码参数
• 全部编解码器自带，不依赖于系统的编解码器和任何组件
• 良好的可扩展的程序架构，快速适应新的需求，不断增加新的格式的支持
• 利用脚本语言扩展的界面，支持众多影音设备

典型应用

• 提高影音文件压缩率，减小其文件尺寸
• 转换至可在各种影音设备上播放的影音文件，如MP3播放器、MP4播放器、手机、PDA、VCD/DVD播放机
• 提取视频文件中的音轨并转换成MP3、AAC、WMA等音频文件
• 修复和改善一些损坏的、部分下载的或质量不佳的影音文件

支持格式

• MP3, Vorbis, AAC, AAC+, AAC+v2, MusePack, Speex, AMR, WMA, RealAudio, mp3PRO*
• FLAC, WavPack, Monkey's Audio, OptimFrog, AAC Lossless, TTA, WAV/PCM, Waveform
• H.264, XviD, DivX, MPEG 1/2/4, Theora, Flash Video, Dirac, 3ivx*, RealVideo*, Windows Media Video
• AVI, MPEG/VOB, Matroska, MP4, PMP, RealMedia*, ASF, Quicktime*, OGM*
• CD, DVD, VCD, SVCD, CUESheet*, HTTP*, FTP*, RTSP*, UDP*

*仅支持输入/解码

工具主页：http://www.mediacoderhq.com/index_zh.htm

当Filter的Pin之间连接完成，也就是说，连接双方通过协商取得了一种大家都支持的媒体类型之后，即开始为数据传输做准备。这些准备工作中，最重要的是Pin上的内存分配器的协商，一般也是由输出Pin发起。在DirectShow Filter之间，数据是通过一个一个数据包传送的，这个数据包叫做Sample。Sample本身是一个COM对象，拥有一段内存用以装载数据，Sample就由内存分配器（Allocator）来统一管理。已成功连接的一对输出、输入Pin使用同一个内存分配器，所以数据从输出Pin传送到输入Pin上是无需内存拷贝的。而典型的数据拷贝，一般发生在Filter内部，从Filter的输入Pin上读取数据后，进行一定意图的处理，然后在Filter的输出Pin上填充数据，然后继续往下传输。下面，我们就具体阐述一下Filter之间的数据传送。
首先，大家要区分一下Filter的两种主要的数据传输模式：推模式（Push Model）和拉模式(Pull Model)。参考图如下：

  
所谓推模式，即源Filter（Source Filter）自己能够产生数据，并且一般在它的输出Pin上有独立的子线程负责将数据发送出去，常见的情况如代表WDM模型的采集卡的Live Source Filter；而所谓拉模式，即源Filter不具有把自己的数据送出去的能力，这种情况下，一般源Filter后紧跟着接一个Parser Filter或Splitter Filter，这种Filter一般在输入Pin上有个独立的子线程，负责不断地从源Filter索取数据，然后经过处理后将数据传送下去，常见的情况如文件源。推模式下，源Filter是主动的；拉模式下，源Filter是被动的。而事实上，如果将上图拉模式中的源Filter和Splitter Filter看成另一个虚拟的源Filter，则后面的Filter之间的数据传输也与推模式完全相同。
那么，数据到底是怎么通过连接着的Pin传输的呢？首先来看推模式。在源Filter后面的Filter输入Pin上，一定实现了一个IMemInputPin接口，数据正是通过上一级Filter调用这个接口的Receive方法进行传输的。值得注意的是（上面已经提到过），数据从输出Pin通过Receive方法调用传输到输入Pin上，并没有进行内存拷贝，它只是一个相当于数据到达的“通知”。再看一下拉模式。拉模式下的源Filter的输出Pin上，一定实现了一个IAsyncReader接口；其后面的Splitter Filter，就是通过调用这个接口的Request方法或者SyncRead方法来获得数据。Splitter Filter然后像推模式一样，调用下一级Filter输入Pin上的IMemInputPin接口Receive方法实现数据的往下传送。深入了解这部分内容，请认真研读SDK的基类源代码（位于DXSDK\samples\Multimedia\DirectShow\BaseClasses\source.cpp和pullpin.cpp）。
下面，我们来讲一下流的定位（Media Seeking）。在GraphEdit中，当我们成功构建了一个Filter Graph之后，我们就可以播放它。在播放中，我们可以看到进度条也在相应地前进。当然，我们也可以通过拖动进度条，实现随机访问。要做到这一点，在应用程序级别应该可以知道Filter Graph总共要播放多长时间，当前播放到什么位置等等。那么，在Filter级别，这一点是怎么实现的呢？
我们知道，若干个Filter通过Pin的相互连接组成了Filter Graph。而这个Filter Graph是由另一个COM对象Filter Graph Manager来管理的。通过Filter Graph Manager，我们就可以得到一个IMediaSeeking的接口来实现对流媒体的定位。在Filter级别，我们可以看到，Filter Graph Manager首先从最后一个Filter（Renderer Filter）开始，询问上一级Filter的输出Pin是否支持IMediaSeeking接口。如果支持，则返回这个接口；如果不支持，则继续往上一级Filter询问，直到源Filter。一般在源Filter的输出Pin上实现IMediaSeeking接口，它告诉调用者总共有多长时间的媒体内容，当前播放位置等信息。（如果是文件源，一般在Parser Filter或Splitter Filter实现这个接口。）对于Filter开发者来说，如果我们写的是源Filter，我们就要在Filter的输出Pin上实现IMediaSeeking这个接口；如果写的是中间的传输Filter，只需要在输出Pin上将用户的获得接口请求往上传递给上一级Filter的输出Pin；如果写的是Renderer Filter，需要在Filter上将用户的获得接口请求往上传递给上一级Filter的输出Pin。进一步的了解，请认真研读SDK的基类源代码（位于DXSDK\samples\Multimedia\DirectShow\BaseClasses\transfrm.cpp的类方法CTransformOutputPin::NonDelegatingQueryInterface实现和ctlutil.cpp中类CPosPassThru的实现）。
以上我们介绍了一下如何学习DirectShow Filter开发，以及一些开始写自己的Filter之前的预备知识。下一讲，笔者将根据自己开发Filter的经验，手把手教你如何写自己的Filter。

流媒体的处理，以其复杂性和技术性，一向广受工业界的关注。特别伴随着因特网的普及，流媒体在网络上的广泛应用，怎样使流媒体的处理变得简单而富有成效逐渐成为了焦点问题。选择一种合适的应用方案，事半功倍。此时，微软的DirectShow，给了我们一个不错的选择。
DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的开发包，与DirectX开发包一起发布。目前，DirectX最新版本为9.0。
那么，DirectShow能够做些什么呢？且看，DirectShow为多媒体流的捕捉和回放提供了强有力的支持。运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换。更值得一提的是，DirectShow提供的是一种开放式的开发环境，我们可以根据自己的需要定制自己的组件。
接下去，我们需要对DirectShow系统有个整体的印象。参见以下DirectShow的系统示意图：

图中央最大的一块即是DirectShow系统。DirectShow使用一种叫Filter Graph的模型来管理整个数据流的处理过程；参与数据处理的各个功能模块叫做Filter；各个Filter在Filter Graph中按一定的顺序连接成一条“流水线”协同工作。大家可以看到，按照功能来分，Filter大致分为三类：Source Filters、Transform Filters和Rendering Filters。Source Filters主要负责取得数据，数据源可以是文件、因特网、或者计算机里的采集卡、数字摄像机等，然后将数据往下传输；Transform Fitlers主要负责数据的格式转换、传输；Rendering Filtes主要负责数据的最终去向，我们可以将数据送给声卡、显卡进行多媒体的演示，也可以输出到文件进行存储。值得注意的是，三个部分并不是都只有一个Filter去完成功能。恰恰相反，每个部分往往是有几个Fitler协同工作的。比如，Transform Filters可能包含了一个Mpeg的解码Filter、以及视频色彩空间的转换Filter、音频采样频率转换Filter等等。除了系统提供的大量Filter外，我们可以定制自己的Filter，以完成我们需要的功能。下图是一条典型的Avi文件回放Filter Graph链路：

在DirectShow系统之上，我们看到的，即是我们的应用程序（Application）。应用程序要按照一定的意图建立起相应的Filter Graph，然后通过Filter Graph Manager来控制整个的数据处理过程。DirectShow能在Filter Graph运行的时候接收到各种事件，并通过消息的方式发送到我们的应用程序。这样，就实现了应用程序与DirectShow系统之间的交互。下图给出了DirectShow应用程序开发的一般过程：

以上简单介绍了DirectShow的系统结构，希望大家对这个强劲的应用框架已经有了大概的认识。如果你有兴趣，可以详细研究DirectX的帮助文档。DirectShow是一个强大的开发包；另外，它是基于COM的，因此要求程序员具有COM编程的一些基本知识。关于如何深入学习DirectShow应用结构以及开发自己的Filter，请参阅笔者的后续文章。笔者将从编程的角度，详细讲述来源于实际工作中的经验之谈。

小知识：AVI文件格式----摘自《DirectShow实务精选》 作者：陆其明

AVI（Audio Video Interleaved的缩写）是一种RIFF（Resource Interchange File Format的缩写）文件格式，多用于音视频捕捉、编辑、回放等应用程序中。通常情况下，一个AVI文件可以包含多个不同类型的媒体流（典型的情况下有一个音频流和一个视频流），不过含有单一音频流或单一视频流的AVI文件也是合法的。AVI可以算是Windows操作系统上最基本的、也是最常用的一种媒体文件格式。

先来介绍RIFF文件格式。RIFF文件使用四字符码FOURCC（four-character code）来表征数据类型，比如‘RIFF’、‘AVI ’、‘LIST’等。注意，Windows操作系统使用的字节顺序是little-endian，因此一个四字符码‘abcd’实际的DWORD值应为0x64636261。另外，四字符码中像‘AVI ’一样含有空格也是合法的。

RIFF文件首先含有一个如图3.31的文件头结构。

 

图3.31 RIFF文件结构

最开始的4个字节是一个四字符码‘RIFF’，表示这是一个RIFF文件；紧跟着后面用4个字节表示此RIFF文件的大小；然后又是一个四字符码说明文件的具体类型（比如AVI、WAVE等）；最后就是实际的数据。注意文件大小值的计算方法为：实际数据长度 + 4（文件类型域的大小）；也就是说，文件大小的值不包括‘RIFF’域和“文件大小”域本身的大小。

RIFF文件的实际数据中，通常还使用了列表（List）和块（Chunk）的形式来组织。列表可以嵌套子列表和块。其中，列表的结构为：‘LIST’ listSize listType listData ——‘LIST’是一个四字符码，表示这是一个列表；listSize占用4字节，记录了整个列表的大小；listType也是一个四字符码，表示本列表的具体类型；listData就是实际的列表数据。注意listSize值的计算方法为：实际的列表数据长度 + 4（listType域的大小）；也就是说listSize值不包括‘LIST’域和listSize域本身的大小。再来看块的结构：ckID ckSize ckData ——ckID是一个表示块类型的四字符码；ckSize占用4字节，记录了整个块的大小；ckData为实际的块数据。注意ckSize值指的是实际的块数据长度，而不包括ckID域和ckSize域本身的大小。（注意：在下面的内容中，将以LIST ( listType ( listData ) )的形式来表示一个列表，以ckID ( ckData )的形式来表示一个块，如[ optional element ]中括号中的元素表示为可选项。）

接下来介绍AVI文件格式。AVI文件类型用一个四字符码‘AVI ’来表示。整个AVI文件的结构为：一个RIFF头 + 两个列表（一个用于描述媒体流格式、一个用于保存媒体流数据） + 一个可选的索引块。AVI文件的展开结构大致如下：

 

RIFF (‘AVI ’
      LIST (‘hdrl’
            ‘avih’(主AVI信息头数据)
            LIST (‘strl’
                  ‘strh’ (流的头信息数据)
                  ‘strf’ (流的格式信息数据)
                  [‘strd’ (可选的额外的头信息数据) ]
                  [‘strn’ (可选的流的名字) ]
                  ...
                 )
             ...
           )
      LIST (‘movi’
            { SubChunk | LIST (‘rec ’
                              SubChunk1
                              SubChunk2
                              ...
                             )
               ...
            }
            ...
           )
      [‘idx1’ (可选的AVI索引块数据) ]
     )

首先，RIFF (‘AVI ’…)表征了AVI文件类型。然后就是AVI文件必需的第一个列表——‘hdrl’列表，用于描述AVI文件中各个流的格式信息（AVI文件中的每一路媒体数据都称为一个流）。‘hdrl’列表嵌套了一系列块和子列表——首先是一个‘avih’块，用于记录AVI文件的全局信息，比如流的数量、视频图像的宽和高等，可以使用一个AVIMAINHEADER数据结构来操作：

typedef struct _avimainheader {
    FOURCC fcc;   // 必须为‘avih’
    DWORD  cb;    // 本数据结构的大小，不包括最初的8个字节（fcc和cb两个域）
    DWORD  dwMicroSecPerFrame;   // 视频帧间隔时间（以毫秒为单位）
    DWORD  dwMaxBytesPerSec;     // 这个AVI文件的最大数据率
    DWORD  dwPaddingGranularity; // 数据填充的粒度
    DWORD  dwFlags;         // AVI文件的全局标记，比如是否含有索引块等
    DWORD  dwTotalFrames;   // 总帧数
    DWORD  dwInitialFrames; // 为交互格式指定初始帧数（非交互格式应该指定为0）
    DWORD  dwStreams;       // 本文件包含的流的个数
    DWORD  dwSuggestedBufferSize; // 建议读取本文件的缓存大小（应能容纳最大的块）
    DWORD  dwWidth;         // 视频图像的宽（以像素为单位）
    DWORD  dwHeight;        // 视频图像的高（以像素为单位）
    DWORD  dwReserved[4];   // 保留
} AVIMAINHEADER;

然后，就是一个或多个‘strl’子列表。（文件中有多少个流，这里就对应有多少个‘strl’子列表。）每个‘strl’子列表至少包含一个‘strh’块和一个‘strf’块，而‘strd’块（保存编解码器需要的一些配置信息）和‘strn’块（保存流的名字）是可选的。首先是‘strh’块，用于说明这个流的头信息，可以使用一个AVISTREAMHEADER数据结构来操作：

typedef struct _avistreamheader {
     FOURCC fcc;  // 必须为‘strh’
     DWORD  cb;   // 本数据结构的大小，不包括最初的8个字节（fcc和cb两个域）
FOURCC fccType;    // 流的类型：‘auds’（音频流）、‘vids’（视频流）、
                   //‘mids’（MIDI流）、‘txts’（文字流）
     FOURCC fccHandler; // 指定流的处理者，对于音视频来说就是解码器
     DWORD  dwFlags;    // 标记：是否允许这个流输出？调色板是否变化？
     WORD   wPriority;  // 流的优先级（当有多个相同类型的流时优先级最高的为默认流）
     WORD   wLanguage;
     DWORD  dwInitialFrames; // 为交互格式指定初始帧数
     DWORD  dwScale;   // 这个流使用的时间尺度
     DWORD  dwRate;
     DWORD  dwStart;   // 流的开始时间
     DWORD  dwLength;  // 流的长度（单位与dwScale和dwRate的定义有关）
     DWORD  dwSuggestedBufferSize; // 读取这个流数据建议使用的缓存大小
     DWORD  dwQuality;    // 流数据的质量指标（0 ~ 10,000）
     DWORD  dwSampleSize; // Sample的大小
     struct {
         short int left;
         short int top;
         short int right;
         short int bottom;
}  rcFrame;  // 指定这个流（视频流或文字流）在视频主窗口中的显示位置
             // 视频主窗口由AVIMAINHEADER结构中的dwWidth和dwHeight决定
} AVISTREAMHEADER;

然后是‘strf’块，用于说明流的具体格式。如果是视频流，则使用一个BITMAPINFO数据结构来描述；如果是音频流，则使用一个WAVEFORMATEX数据结构来描述。

当AVI文件中的所有流都使用一个‘strl’子列表说明了以后（注意：‘strl’子列表出现的顺序与媒体流的编号是对应的，比如第一个‘strl’子列表说明的是第一个流（Stream 0），第二个‘strl’子列表说明的是第二个流（Stream 1），以此类推），‘hdrl’列表的任务也就完成了，随后跟着的就是AVI文件必需的第二个列表——‘movi’列表，用于保存真正的媒体流数据（视频图像帧数据或音频采样数据等）。那么，怎么来组织这些数据呢？可以将数据块直接嵌在‘movi’列表里面，也可以将几个数据块分组成一个‘rec ’列表后再编排进‘movi’列表。（注意：在读取AVI文件内容时，建议将一个‘rec ’列表中的所有数据块一次性读出。）但是，当AVI文件中包含有多个流的时候，数据块与数据块之间如何来区别呢？于是数据块使用了一个四字符码来表征它的类型，这个四字符码由2个字节的类型码和2个字节的流编号组成。标准的类型码定义如下：‘db’（非压缩视频帧）、‘dc’（压缩视频帧）、‘pc’（改用新的调色板）、‘wb’（音缩视频）。比如第一个流（Stream 0）是音频，则表征音频数据块的四字符码为‘00wb’；第二个流（Stream 1）是视频，则表征视频数据块的四字符码为‘00db’或‘00dc’。对于视频数据来说，在AVI数据序列中间还可以定义一个新的调色板，每个改变的调色板数据块用‘xxpc’来表征，新的调色板使用一个数据结构AVIPALCHANGE来定义。（注意：如果一个流的调色办中途可能改变，则应在这个流格式的描述中，也就是AVISTREAMHEADER结构的dwFlags中包含一个AVISF_VIDEO_PALCHANGES标记。）另外，文字流数据块可以使用随意的类型码表征。

最后，紧跟在‘hdrl’列表和‘movi’列表之后的，就是AVI文件可选的索引块。这个索引块为AVI文件中每一个媒体数据块进行索引，并且记录它们在文件中的偏移（可能相对于‘movi’列表，也可能相对于AVI文件开头）。索引块使用一个四字符码‘idx1’来表征，索引信息使用一个数据结构来AVIOLDINDEX定义。

 

typedef struct _avioldindex {
   FOURCC  fcc;  // 必须为‘idx1’
   DWORD   cb;   // 本数据结构的大小，不包括最初的8个字节（fcc和cb两个域）
   struct _avioldindex_entry {
      DWORD   dwChunkId;   // 表征本数据块的四字符码
      DWORD   dwFlags;     // 说明本数据块是不是关键帧、是不是‘rec ’列表等信息
      DWORD   dwOffset;    // 本数据块在文件中的偏移量
      DWORD   dwSize;      // 本数据块的大小
  } aIndex[]; // 这是一个数组！为每个媒体数据块都定义一个索引信息
} AVIOLDINDEX;

注意：如果一个AVI文件包含有索引块，则应在主AVI信息头的描述中，也就是AVIMAINHEADER结构的dwFlags中包含一个AVIF_HASINDEX标记。

还有一种特殊的数据块，用一个四字符码‘JUNK’来表征，它用于内部数据的队齐（填充），应用程序应该忽略这些数据块的实际意义。

小马歌 2008-09-19 15:03 发表评论

]]>

    今天利用FFmpeg -h > ffmpeg.txt,把FFmpeg的命令打印出来后,才发现了这一参数:

-ss time_off set the start time offset

使用-ss参数,可以从指定的时间开始处理转换任务.如:

ffmpeg -i test2.asf -y -f image2 -ss 08.010 -t 0.001 -s 352x240 b.jpg

那么从任意一帧截图的问题也就解决了.只要-ss后的时间参数是随机产生,并且在视频的有效时间内,就可以了.

 另外,-ss后跟的时间单位为秒。

2006-06-27 补充：