超强详解FLV解复?实战之FlvParser源码分析

1.环境准备

下载flvparser的源码:https://github.com/riverlight/FlvParser

qt工具设置如下:

在以下这个函数打下端点:

这个函数很长，只截出了一部分。

打印的媒体数据如下，与MediaInfo输出的一致:

如下图，是FLVParser的源码结构图:

1.main函数调用Process输出。

2.在process方法，把解析的数据存到内存里。

3.看看这个Parser方法。使用CheckBuffer、CreateFlvHeader检测9字节header。

4.进入CreateFlvHeader方法，观察flvHeader及其debug的数据结构。

pHeader->pFlvHeader = new uint8_t[pHeader->nHeadSize];
 memcpy(pHeader->pFlvHeader, pBuf, pHeader->nHeadSize);

//把这9个字节拷贝起来，然后再缓存起来，最终写到文件里。

flvHeader描述的就是一些flv header的信息，与MediaInfo分析出的信息一样。

还有TagHeader。

关于TAG的父类结构体。

子类CVideoTag、CAudioTag、CMetaDataTag都是继承上面父类的TAG。如下:

其中int ParseH264Configuration(CFlvParser *pParser, uint8_t *pTagData);这里一般就是一个AVC头部信息的解析，这里就是int ParseNalu(CFlvParser *pParser, uint8_t *pTagData)的数据NALU的解析;。int ParseAudioSpecificConfig(CFlvParser *pParser, uint8_t *pTagData);这里一般就是一个AAC音频头的解析，int ParseRawAAC(CFlvParser *pParser, uint8_t *pTagData);对于AAC数据的解析。

这里就会分析出相关信息。

关于媒体脚本数据就是解析视频宽高，采样率等。源码如下。

这里就是一些字段信息。

5.需要有完整的15个字节才能检查出TAG Header。15个字节的来源就是nPrevSize(4字节) + Tag header(11字节)。没有15个字节，就不一定能够检查出来，就需要使用return返回。

识别不同的TAG，然后进行解析。返回，不管是什么类型的TAG，然后插入到队列中。这里可以看出，音视频的裸流是没有时间戳。

6.分别详细看看VideoTag，AudioTag，ScriptTag。

初始化是把头部和body信息一起拷贝了。这里的_pTagData就是body信息。这里表示只处理AVC类型。

再来看看ParseH264Tag的数据包做了什么。

nAVCPacketType = pd[1]表示数据包类型，视频数据被压缩之后被打包成数据包在网上传输。根据包类型，分别去解析视频配置信息，还是真正的视频数据包。

注意:有两种类型的数据包：视频信息包（sps、pps等）和视频数据包（视频的压缩数据）。

那我们接下来，继续看看H264的配置信息，也就是具体解析AVC sequence header。要解析H264的配置信息，那么需要跨过 Tag Data的5个字节，比如VIDEODATA(1字节) AVCVIDEOPACKET(AVCPacketType(1字节) 和CompositionTime(3字节) 4字节)，这样才能找到相关的配置信息结构体AVCDecoderConfigurationRecord。

注意:这里还有添加TAG Header的start code。

AVCDecoderConfigurationRecord结构体:

这里要说明下，为什么NALU的长度信息，需要4字节长度对齐。

_nNalUnitLength 这个变量告诉我们用几个字节来存储NALU的长度，如果NALULengthSizeMinusOne是0，那么每个NALU使用一个字节的前缀来指定长度，那么每个NALU包的最大长度是255字节，这个明显太小了，使用2个字节的前缀来指定长度，那么每个NALU包的最大长度是64K字节，也不一定够，一般分辨率达到1280*720 的图像编码出的I帧，可能大于64K；3字节是比较完美的，但是因为一些原因（例如对齐）没有被广泛支持；因此4字节长度的前缀是目前使用最多的方式。

注意下：这几个数据结构的说明。一般的flv和MP4文件都是不带startcode，所以解析的时候就需要添加startcode，这样dump下来的裸流才能够正确播放。

接下来再看看，真正解析H264的视频数据，ParseNalu。这里也需要跨过Tag Data的5个字节，分别是VIDEODATA(1字节) AVCVIDEOPACKET(AVCPacketType和CompositionTime 4字节。132 - 5 = 127 = _nNalUnitLength(4字节) + NALU(123字节)=startcode(4字节) + NALU(123字节) = 127。所以一般NALU数据的也包含了NALU的长度。 计算NALU（视频数据被包装成NALU在网上传输）的长度，一个tag可能包含多个nalu(所以可能就有多帧), 所以每个nalu前面有NalUnitLength字节表示每个nalu的长度，来去表示不同的数据长度。这里的ｓｗｉｔｃｈ就描述了，ＮＡＬＵ的长度用多少个字节去描述。

大概就是类似这样的图：

这里有个文件是，用户可以根据自己的需要，对该函数进行修改或者扩展，功能大致就是往视频中写入SEI信息等。如果起始码后面的两个字节是0x05或者0x06，那么表示IDR图像或者SEI信息。

继续看看音频的AudioTag， CAudioTag 音频Tag Data区域开始的第一个字节包含了音频数据的参数信息，这里的第一个字节的信息，就仅供参考了，正真的还是要看ＡＡＣｓｅｃｕｑｕｅｎｃｅ里面的参数配置。从第二个字节开始为音频流数据，但第二个字节对于AAC也要判断是AAC sequence header还是AAC raw。可以对照代码看。

第一个字节：SoundFormat 4bit 音频格式 0 = Linear PCM, platform endian
                        1 =ADPCM; 2 = MP3; 3 = Linear PCM, little endian
                        4 = Nellymoser 16-kHz mono ; 5 = Nellymoser 8-kHz mono
                        6 = Nellymoser;  7 = G.711 A-law logarithmic PCM
                        8 = G.711 mu-law logarithmic PCM; 9 = reserved
                        10 = AAC ; 11  Speex 14 = MP3 8-Khz
                        15 = Device-specific sound
              SoundRate 2bit 采样率 0 = 5.5-kHz; 1 = 11-kHz; 2 = 22-kHz; 3 = 44-kHz
                        对于AAC总是3。但实际上AAC是可以支持到48khz以上的频率。
              SoundSize 1bit 采样精度  0 = snd8Bit; 1 = snd16Bit
                        此参数仅适用于未压缩的格式，压缩后的格式都是将其设为1
              SoundType 1bit  0 = sndMono 单声道; 1 = sndStereo 立体声，双声道
                        对于AAC总是1

这里还要根据数据包类型去解析配置信息还是解析音频数据。

在ParseAudioSpecificConfig才会正真拿到解析配置信息，虽然关于媒体脚本包里面也有音频的相关值，比如采样率，通道数，但是最终还是以这里获取处理的值为准。

接下来在ParseRawAAC就是为了解析AAC的真实的数据，这里正如前面文章分析的，如果输入文件是flv或MP4的时候，一样要每帧裸数据前添加adts头，也就是代码注释中制作元数据的地方。最终把裸流和ADTS头一起拼装起来。

注意: memcpy(_pMedia + 7, pTagData + 2, dataSize)，这里 pTagData + 2,表示跳过了2个字节，表示分别跳过了AAC header和AAC RAW里的packet type，他们加在一起是2个字节，这里就是跳过了2个字节。

  // 是bits的最高8bit，实际为0  
  p64[0] = (uint8_t)(bits >> 56); 
   // 才是ADTS起始头 0xfff的高8bit
    p64[1] = (uint8_t)(bits >> 48); 
    p64[2] = (uint8_t)(bits >> 40);
    p64[3] = (uint8_t)(bits >> 32);
    p64[4] = (uint8_t)(bits >> 24);
    p64[5] = (uint8_t)(bits >> 16);
    p64[6] = (uint8_t)(bits >> 8);
    p64[7] = (uint8_t)(bits);

再来看看CMetaDataTag，画红色框的部分，这里的m_amf1_type一定是2，否则就视为错误。如果是2，就去解析MetaDataTag。

这里的不同颜色部分，就表示不同的amf包，就表示一个完整的字段。

看看parseMeta具体解析做了什么工作。为什么这里 uint32_t offset = 13，是偏移了13个字节呢？

根据MediaInfo信息，这里Type是1个字节，Value_Size是2个字节，Value是占用了10个字节，一共就是13个字节，所以就需要偏移13个字节，这个值一般也是固定值。

前面已经把相应字段的名字和value值都读取出来了，就是可以去赋值给相应的字段了。

这里pd[offset++] == 0x08就需要判断类型，读4个字节，就偏移4个字节。

通过分析上面的，每个字段都有一个数据长度，然后才是具体字段的值。结合上面代码的注释看，就是结合不同类型，去读取不同的值，然后获取相应的长度，得到相应的偏移值。

为了解析方便，加上这个打印函数，就可以打印出如下值:

截取dump flv数据的一部分。

DumpH264:

这种dump数据，也是非常实用。

本篇解析源码，也花了很长时间整理，如果对你有用，欢迎关注，点赞，转发，收藏。

如果需要源码注释版本，可以关注，私信。