当AVI遇到AVC

公司最近终于开始在低端产品上推h264。出于该产品线代码结构关系，我有幸获得调试avi+h264、flv+h264、qt+h264的衔接任务。h264流数据的处理已由另外的同事开发好。我的任务就是按照已有的h264 decoder，将几支container中的视频流数据送到h264 parse端。现将调试中遇到的其中一个比较有意思的问题备忘于此。

h264流通常以sps和pps开始，flv(第一个video tag)、qt(avcC atom)有专门的位置去存放，只要按照对应container和14496-15中关于AVCDecoderConfigurationRecord的说明解出来放到流上就OK。但AVI却很难找到一个专用的位置去存放此信息，所以通常AVI会选择将它直接放到movi断的视频流中，直接将其中的视频流分出另存到一个.h264文件中便可以被VLC播放器解码。而有部分AVI文件选择将h264的AVCDecoderConfigurationRecord信息放在video stream list的strf后面。这种pattern需要将strf中的AVCDecoderConfigurationRecord解出放到视频流的前面才能播放。微软告诉我们video stream list的strf后面应该放BITMAPINFO(40 BYTE)结构，那么我们需要的AVCDecoderConfigurationRecord自然就被放到了前述结构体的后面。抓完前面的结构后，如果发现strf chunk还剩下许多数据，就应该是AVCDecoderConfigurationRecord了。参考14496-15中的说明将其解出来放入h264流，后面的流便能解码。据了解，最新的QQ影音、暴风影音都不能顺利的解这种pattern，有点令人汗颜。还好ffmpeg、VLC是正常的。

以下便是一段截自真实AVI文件的一个strf chunk，最后40 BYTE橙底高亮的数据便是一个AVCDecoderConfigurationRecord结构。

                    73 74 72 66  50 00 00 0050 00 00 00
40 01 00 00 F0 00 00 00  01 00 18 00 48 32 36 34
00 84 03 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 01 64 00 0D  FF E1 00 17 67 64 00 0D
AC D9 41 41 FB 0E 10 00  00 06 40 00 01 76 A0 F1
42 99 60 01 00 06 68 EB  E3 CB 22 C0