音视频八股文-- flv的h264六层结构和aac六层结构

Posted 2023-04-29 在等月亮和你

flv介绍

FLV(Flash Video)是Adobe公司推出的⼀种流媒体格式，由于其封装后的⾳视频⽂件体积⼩、封装简单等特点，⾮常适合于互联⽹上使⽤。⽬前主流的视频⽹站基本都⽀持FLV。采⽤FLV格式封装的⽂件后缀为.flv。

FLV封装格式是由⼀个⽂件头(file header)和 ⽂件体(file Body)组成。其中，FLV body由⼀对对的(Previous Tag Size字段 + tag)组成。Previous Tag Size字段 排列在Tag之前，占⽤4个字节。Previous Tag Size记录了前⾯⼀个Tag的⼤⼩，⽤于逆向读取处理。FLV header后的第⼀个Pervious Tag Size的值为0。

Tag⼀般可以分为3种类型：脚本(帧)数据类型、⾳频数据类型、视频数据。FLV数据以⼤端序进⾏存储，在解析时需要注意。⼀个标准FLV⽂件结构如下图：

FLV⽂件的详细内容结构如下图：

⼤体的解析框架

FLV header

注：在下⾯的数据type中，UI表示⽆符号整形，后⾯跟的数字表示其⻓度是多少位。⽐如UI8，表示⽆符号整形，⻓度⼀个字节。UI24是三个字节,UI[8*n]表示多个字节。UB表示位域，UB5表示⼀个字节的5位。可以参考c中的位域结构体。

FLV头占9个字节，⽤来标识⽂件为FLV类型，以及后续存储的⾳视频流。⼀个FLV⽂件，每种类型的tag都属于⼀个流，也就是⼀个flv⽂件最多只有⼀个⾳频流，⼀个视频流，不存在多个独⽴的⾳视频流在⼀个⽂件的情况。

00000 1 0 1

FLV头的结构如下：

FLV Body

FLV Tag

每⼀个Tag也是由两部分组成:tag header和tag data。Tag Header⾥存放的是当前tag的类型、数据区(tag data)的⻓度等信息。

tag header⼀般占11个字节的内存空间。FLV tag结构如下：

注意：

1.flv⽂件中Timestamp和TimestampExtended拼出来的是dts。也就是解码时间。Timestamp和TimestampExtended拼出来dts单位为ms。(如果不存在B帧，当然dts等于pts)

2.CompositionTime 表示PTS相对于DTS的偏移值， 在每个视频tag的第14~16字节， 。显示时间(pts) = 解码时间（tag的第5~8字节） + CompositionTime CompositionTime的单位也是ms

Script data脚本数据就是描述视频或⾳频的信息的数据，如宽度、⾼度、时间等等，⼀个⽂件中通常只有⼀个元数据，⾳频tag和视频tag就是⾳视频信息了，采样、声道、频率，编码等信息。

Script Tag Data结构(脚本类型、帧类型)

该类型Tag⼜被称为MetaDataTag,存放⼀些关于FLV视频和⾳频的元信息，⽐如：duration、width、height等。通常该类型Tag会作为FLV⽂件的第⼀个tag，并且只有⼀个，跟在File Header后。该类型TagDaTa的结构如下所示（source.200kbps.768x320.flv⽂件为例）:

第⼀个AMF包：第1个字节表示AMF包类型，⼀般总是0x02，表示字符串。第2-3个字节为UI16类型值，标识字符串的⻓度，⼀般总是0x000A（“onMetaData”⻓度）。后⾯字节为具体的字符串，⼀般总为“onMetaData”（6F,6E,4D,65,74,61,44,61,74,61）。

第⼆个AMF包：第1个字节表示AMF包类型，⼀般总是0x08，表示数组。第2-5个字节为UI32类型值，表示数组元素的个数。后⾯即为各数组元素的封装，数组元素为元素名称和值组成的对。常⻅的数组元素如下表所示。

注：Lavf54.63.104即是 Libavformat version 54.63.104. 即是ffmpeg对于库的版本

Audio Tag Data结构(⾳频类型)

⾳频Tag Data区域开始的：

第⼀个字节包含了⾳频数据的参数信息，

第⼆个字节开始为⾳频流数据。

（这两个字节属于tag的data部分，不是header部分）

第⼀个字节为⾳频的信息（仔细看spec发现对于AAC⽽⾔，⽐较有⽤的字段是SoundFormat），格式如下：

If the SoundFormat indicates AAC, the SoundType should be set to 1 (stereo) and the
SoundRate should be set to 3 (44 kHz). However, this does not mean that AAC audio in FLV
is always stereo, 44 kHz data. Instead, the Flash Player ignores these values and extracts the
channel and sample rate data is encoded in the AAC bitstream.

第⼆个字节开始为⾳频数据（需要判断该数据是真正的⾳频数据，还是⾳频config信息）。

AAC AUDIO DATA

The AudioSpecificConfig is explained in ISO 14496-3. AAC sequence header存放的是
AudioSpecificConfig结构，该结构则在“ISO-14496-3 Audio”中描述。

《完整版ISO-14496-3(2009-09).pdf 》

如果是AAC数据，如果他是AAC RAW, tag data[3] 开始才是真正的AAC frame data。

Video Tag Data结构(视频类型)

视频Tag Data开始的：

第⼀个字节包含视频数据的参数信息，

第⼆个字节开始为视频流数据。

第⼀个字节包含视频信息，格式如下:

第⼆个字节开始为视频数据

AVCVIDEOPACKET

（1）CompositionTime 单位毫秒

CompositionTime 每个视频tag（整个tag）的第14 ~ 16字节（如果是tag data偏移[2] ~ [4]）（表示PTS相对于DTS的偏移值 ）。

CompositionTime 单位为ms : 显示时间 = 解码时间（tag的第5 ~ 8字节,位置索引[4] ~ [7]）+ CompositionTime

（2）AVCDecoderConfigurationRecord

AVC sequence header就是AVCDecoderConfigurationRecord结构

FLV时间戳计算

题记：时间戳将每⼀秒分成90000份，即将每⼀毫秒分成90份 在flv中直接存储的都是毫秒级 在TS存储的
是时间戳级
其中TS、flv⼀般按照编码顺序排列
⼀个视频tag⼀般只包含⼀帧视频的码流
其中视频tag的时间戳对应的是解码时间戳（DTS/90）
当前序列：
编码顺序 I P P B B B......
对应帧号 0 1 5 3 2 4.......
flv对每⼀个tag都规定了它将要播放的时间戳
每个时间戳都可以对应转换特性的时间
其中script（脚本）、video（视频）、audio（⾳频）的第⼀个tag的时间戳值都为0
时间戳占4个字节 其中第四个字节是⾼位 前三个字节是低位(每个tag的5~8字节)
如6E 8D A8 01 = 0x 01 6E 8D A8 = 24022440
CompositionTime 每个视频tag的第14~16字节（表示PTS相对于DTS的偏移值 ）
CompositionTime 单位为ms 显示时间 = 解码时间（tag的第5~8字节） + CompositionTime
例如（注意显示时间最后⼀个字节是⾼位）
tag0 （脚本） ：时间戳为0
tag1 （视频） ：第⼀个视频时间戳 值为0 ⽆CompositionTime (头信息)
tag2 （⾳频） ：第⼀个⾳频时间戳 值为0
tag3 （视频） ：00 00 00 00 值：0 00:00:00:00 (解码时间) CompositionTime：0x 00 00 50 值：80
00:00:00:80 I帧 显示时间： 00:00:00: 80 poc=0
tag4 （视频） ：00 00 28 00 值：40 00:00:00:40 (解码时间) CompositionTime：0x 00 00 50 值：
80 00:00:00:80 P帧 显示时间： 00:00:00: 120 poc=1
tag5 （视频） ：00 00 50 00 值：80 00:00:00:80 (显示时间) CompositionTime：0x 00 00 C8 值：
200 00:00:00:200 P帧 显示时间： 00:00:00: 280 poc=5
tag6 （⾳频） ：00 00 50 00 值：80 00:00:00:80(显示时间)
tag7 （⾳频） ：00 00 67 00 值：103 00:00:00:103(显示时间)
tag8 （视频） ：00 00 78 00 值：120 00:00:00:120 (解码时间) CompositionTime：0x 00 00 50
值：80 00:00:00:80 B帧 显示时间： 00:00:00: 200 poc=3
tag9 （⾳频） ：00 00 7E 00 值：126 00:00:00:126(显示时间)
tag10 （⾳频） ：00 00 96 00 值：150 00:00:00:150(显示时间)
tag11 （视频） ：00 00 A0 00 值：160 00:00:00:160(解码时间) CompositionTime：0x 00 00 00
值：00 00:00:00:00 b帧 显示时间： 00:00:00: 160 poc=2
tag12 （⾳频） ：00 00 AD 00 值：173 00:00:00:173(显示时间)
tag13 （⾳频） ：00 00 C4 00 值：196 00:00:00:196(显示时间)
tag14（视频） ：00 00 C8 00 值：200 00:00:00:200(解码时间) CompositionTime：0x 00 00 28
值：40 00:00:00:40 b帧 显示时间： 00:00:00: 240 poc=4我们可以看到 每个视频tag相差约40ms 刚
好是25fps视频 每帧视频的播放时⻓
在上例中，我们会看到按照解码时间排列
编码顺序 I P P B B B......
对应帧号 0 1 5 3 2 4.......

tag data

Tag Data : Audio Data

1-1：音频头【AudioTagHeader】

--1-4bit，音频格式【SoundFormat】

----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 , reserved

----8 = G.711 mu-law logarithmic PCM , reserved

----9 = reserved

----10 = AAC (supported in Flash Player 9,0,115,0 and higher)

----11 = Speex (supported in Flash Player 10 and higher)

----14 = MP3 8 kHz , reserved

----15 = Device-specific sound , reserved

--5-6bit，采样率【SoundRate】

----0 = 5.5kHz

----1 = 11kHz

----2 = 22kHz

----3 = 44kHz

--7-7bit，位宽，0 = 8bit samples, 1= 16bit samples【SoundSize】

----8-8bit，通道，0 = Mono, 1 = Stereo【SoundType】

[2-2]：AAC音频类型，注，只有在 SoundFormat=AAC 时，才有此数据

--0 = AAC sequence header

--1 = AAC raw

x-x：音频数据

注：SoundFormat

如果 SoundFormat=10 即AAC格式，官方建议使用44.1kHz采样率和双声道，即SoundType=1，SoundRate=3；Flash Player会忽略这两个参数，并从音频比特流中解析获得。

如果 SoundFormat=11 即Speex格式，音频使用压缩的16kHz采样率的单声道，各参数取值为SoundRate=0，SoundSize=1，SoundType=0。

Tag Data : Video Data

1-1：视频头【VideoTagHeader】

--1-4bit，帧类型【FrameType】

----1 = key frame (for AVC, a seekable frame)

----2 = inter frame (for AVC, a non-seekable frame)

----3 = disposable inter frame (H.263 only)

----4 = generated key frame (reserved for server use only)

----5 = video info/command frame

--5-8bit，编码类型【CodecID】

----2 = Sorenson H.263

----3 = Screen video

----4 = On2 VP6

----5 = On2 VP6 with alpha channel

----6 = Screen video version 2

----7 = AVC（H.264）

[2-5]：H.264视频类型，注，只有在 CodecID=AVC 时，才有此数据
AVCPacketType
CompositionTime (ISO 14496-12, 8.15.3)

x-x：视频数据

Tag Data : Script Data

1-1：格式类型【Type】

--0 = Number【DOUBLE】

--1 = Boolean【UI8】

--2 = String【SCRIPTDATASTRING】

--3 = Object【SCRIPTDATAOBJECT】

--4 = MovieClip (reserved, not supported)

--5 = Null

--6 = Undefined

--7 = Reference【UI16】

--8 = ECMA array【SCRIPTDATAECMAARRAY】

--9 = Object end marker

--10 = Strict array【SCRIPTDATASTRICTARRAY】

--11 = Date【SCRIPTDATADATE】

--12 = Long string【SCRIPTDATALONGSTRING】

x-x：

flv视频层次结构，h264视频数据作为参考。

第一层：flv：⼀个⽂件头(file header)和 ⽂件体(file Body)。

第二层：flv body：多个(Previous Tag Size字段 + tag)。

第三层：tag（video）：tag header+tag data。

第四层：tag data：1字节的参数信息+AVC VIDEO PACKET。—— 注，只有在 CodecID=AVC 时，才有第五层，否则没有第五层。

第五层：AVC VIDEO PACKET：4字节的视频类型+视频数据。

第六层：视频数据。

flv音频层次结构，aac数据作为参考。

第一层：flv：⼀个⽂件头(file header)和 ⽂件体(file Body)。

第二层：flv body：多个(Previous Tag Size字段 + tag)。

第三层：tag（audio）：tag header+tag data。

第四层：tag data：1字节的参数信息+AAC AUDIO PACKET。—— 注，只有在 SoundFormat=AAC 时，才有第五层，否则没有第五层。

第五层：AAC AUDIO PACKET：1字节的音频类型+音频数据。

第六层：音频数据。

(原)从mp4,flv文件中解析出h264和aac,送解码器解码失败

　　转载请注明出处：http://www.cnblogs.com/lihaiping/p/5285166.html

　　今天在做本地文件解码测试,发现从mp4,flv文件中读出来的帧数据,h264和aac帧直接送解码器解码,发现解码失败,但文件放在pc上用ffplay和vlc却都能播放,而且这个测试的视频文件是用ffmpeg.exe进行转码出来的,所以应该不存在解码不了的问题,那问题在哪呢？

　　百度了下,网上有人说mp4文件里面封装的h264有两种格式：h264和avc1：

　　而这两种格式的差别是：

　　　　AVC1 描述:H.264 bitstream without start codes.一般通过ffmpeg转码生成的视频，是不带起始码0×00000001的。
　　　　H264 描述:H.264 bitstream with start codes.一般对于一下HDVD等电影的压制格式，是带有起始码0×00000001的。

　　所以我又用vlc播放查看了下，原来真的是avc1,这才发现原来自己接触了这么久的流媒体,连avc1都没听过,哎,悲哀。

　　那要如何才能解码呢？同时我查看了一下,ffmpeg中对h264的avc1并没有设置单独的解码器,只有一个h264的解码器codeid,那它是怎么实现解码avc1的？又是如何区分的呢？

　　问题1：如何解码？

　　在这里其实有人遇到了和我一样的问题：http://stackoverflow.com/questions/11330764/ffmpeg-cant-decode-h264-stream-frame-data

　　同时还有人在论坛上讨论该如何解决：http://bbs.csdn.net/topics/390538510

　　有人说avc1是原始的NAL打包格式，就是开始的若干字节（1，2，4字节）是NAL的长度，而不是start_code,此时必须借助某个全局的数据来获得编码器的profile,level,PPS,SPS等信息才可以解码。

　　既然这样，那我要如何才能获得pps,sps等这些信息呢？有人写过：http://blog.csdn.net/gavinr/article/details/7183499,在这篇文章里面,需要注意几个之前没认真了解的新地方：

　　　　1)pps及sps不能从packet获得，而是保存在AVCodecContext的extradata数据域中

　　　　2)如何从extradata中解析出sps及pps呢？ffmpeg中提供了一个流过滤器"h264_mp4toannexb"可以完成

　　解决方法为：使用ffmpeg提供的h264_mp4toannexb流过滤器进行解决：具体方法可以参考：http://blog.csdn.net/leixiaohua1020/article/details/11800877

　　问题2：ffmpeg中没有对avc1使用单独的解码器,而是和h264同样使用同一个解码器？那它是如何区分的呢？

　　这个问题,需要仔细翻看一下ffmpeg的源代码了,在ff_h264_decode_init函数中有这样的一段代码：

　　

if (avctx->extradata_size > 0 && avctx->extradata) {
        ret = ff_h264_decode_extradata(h, avctx->extradata, avctx->extradata_size);
        if (ret < 0) {
            ff_h264_free_context(h);
            return ret;
        }
    }

继续往下看,看ff_h264_decode_extradata函数中做了些什么？

int ff_h264_decode_extradata(H264Context *h, const uint8_t *buf, int size)
{
    AVCodecContext *avctx = h->avctx;
    int ret;

    if (!buf || size <= 0)
        return -1;

    if (buf[0] == 1) {
        int i, cnt, nalsize;
        const unsigned char *p = buf;

        h->is_avc = 1;

        if (size < 7) {
            av_log(avctx, AV_LOG_ERROR,
                   "avcC %d too short\\n", size);
            return AVERROR_INVALIDDATA;
        }
        /* sps and pps in the avcC always have length coded with 2 bytes,
         * so put a fake nal_length_size = 2 while parsing them */
        h->nal_length_size = 2;
        // Decode sps from avcC
        cnt = *(p + 5) & 0x1f; // Number of sps
        p  += 6;
        for (i = 0; i < cnt; i++) {
            nalsize = AV_RB16(p) + 2;
            if(nalsize > size - (p-buf))
                return AVERROR_INVALIDDATA;
            ret = decode_nal_units(h, p, nalsize, 1);
            if (ret < 0) {
                av_log(avctx, AV_LOG_ERROR,
                       "Decoding sps %d from avcC failed\\n", i);
                return ret;
            }
            p += nalsize;
        }
        // Decode pps from avcC
        cnt = *(p++); // Number of pps
        for (i = 0; i < cnt; i++) {
            nalsize = AV_RB16(p) + 2;
            if(nalsize > size - (p-buf))
                return AVERROR_INVALIDDATA;
            ret = decode_nal_units(h, p, nalsize, 1);
            if (ret < 0) {
                av_log(avctx, AV_LOG_ERROR,
                       "Decoding pps %d from avcC failed\\n", i);
                return ret;
            }
            p += nalsize;
        }
        // Store right nal length size that will be used to parse all other nals
        h->nal_length_size = (buf[4] & 0x03) + 1;
    } else {
        h->is_avc = 0;
        ret = decode_nal_units(h, buf, size, 1);
        if (ret < 0)
            return ret;
    }
    return size;
}

所以再这里h264的解码器是通过AVCodecContext的extradata在ff_h264_decode_init的时候，进行了区分，同时也进行初始化解码。

=================================================================

aac解码失败的问题：

http://blog.csdn.net/leixiaohua1020/article/details/39767055   这篇文章说了,视音频分离器（Demuxer）,并不适用于一些格式。对于MP3编码的音频是没有问题的。但是在分离MP4/FLV/MKV等一些格式中的AAC编码的码流的时候，得到的AAC码流是不能播放的。原因是存储AAC数据的AVPacket的data字段中的数据是不包含7字节ADTS文件头的“砍头”的数据，是无法直接解码播放的（当然如果在这些数据前面手工加上7字节的ADTS文件头的话，就可以播放了）。

adts？又是一个新概念,怎么解决？谷歌不在问度娘,http://blog.csdn.net/tx3344/article/details/7414543,这篇文章介绍了adts的概念。

本来是想通过和h264的avc1方案一样来解决，但发现使用aac_adtstoasc流过滤器是行不通的,因为他一直是返回0,于是我看了一下ffmpeg中这个函数的源码，原来这个函数的源码就是返回0的.测试结果也是解码不了。

后面找到了一篇文章：http://blog.chinaunix.net/uid-24922718-id-3692670.html,本来想参考着这里面的方法实现：

                char bits[7] = {0};
                int sample_index = 0 , channel = 0;
                char temp = 0;
                int length = 7 + audiopack.size;
                sample_index = (audioCodecCtx->extradata[0] & 0x07) << 1;
                temp = (audioCodecCtx->extradata[1]&0x80);
                switch(audioCodecCtx->sample_rate)
                {
                    case 44100:
                        {
                            sample_index = 0x7;
                        }break;
                    default:
                        {
                            sample_index = sample_index + (temp>>7);
                        }break;
                }
                channel = ((audioCodecCtx->extradata[1] - temp) & 0xff) >> 3;
                bits[0] = 0xff;
                bits[1] = 0xf1;
                bits[2] = 0x40 | (sample_index<<2) | (channel>>2);
                bits[3] = ((channel&0x3)<<6) | (length >>11);
                bits[4] = (length>>3) & 0xff;
                bits[5] = ((length<<5) & 0xff) | 0x1f;
                bits[6] = 0xfc;

                fwrite(bits,1,7,f);

结果失败了，添加这几个自己的adts头还是一样解码不出数据。

最后参考http://blog.itpub.net/30168498/viewspace-1576794/这个文章的代码，进行应用，顺利解码aac。