aac

这几天在调研直播的技术。虽然现在有很多“开源”的SDK，或者各个厂家的SDK。但是还是想自己去调研一下整个的直播流程／技术，并且通过代码去实现一套这样的功能。 整体规划： 看网上的文章介绍，基本上的流程是这样的：采集，编码，发送，转发，解码。我这次主要研究一下采集，编码，发送这三个客户端采集的步骤。 采集设备：Android手机摄像头采集视频，麦克风采集音频。 编码格式：音频：aac，视频：h264。 发送协议：rtmp协议。 采集方法： 摄像头采集视频的方法有两种：Camera的onPreviewFrame的回调方法，和MediaRecorder的outPut方法。经过对比，发现各有各的优缺点： Camera的onPreviewFrame方法： 优点： 可以获取到视频的原始YUV数据。 使用简单：直接设置一个回调方法就能够获取到预览时的视频数据。 缺点： 需要自己将YUV数据编码为h264格式，对编码需要一定的了解。 MediaRecorder的outPut方法： 优点： 可以直接获取到编码后的h264格式的视频帧数据。 缺点： 获取部分的代码比较麻烦：需要在程序内部架设socket服务来获取h264视频数据。 在各有优缺点的情况下，通过对比其他现有的直播SDK的功能，最终采用了Camera的onPreviewFrame的方法。众所周知，美颜功能已经是目前直播的主要功能点之一

Android ApI提供了MediaRecorder和AudioRecord两个类给开发者来很方便地实现音视频的录制(前者可以实现音频和视频的录制，后者只能实 现音频的录制)。这两个类都提供了start()和stop()方法用于开始和结束音频或视频的录制，但令人费解的是这两个类都没有提供pause()方 法用于暂停录制音视频，因为在实际应用当中，暂停录制的功能是非常有必要的Android 实现能够暂停的录音功能 需实现音频录制的暂停功能，并且生成的音频文件格式必须是m4a格式 为什么项目中音频文件一定要采用m4a格式的呢？有以下几点原因： 1. 录制相同时间的音频，使用m4a格式存储的文件的大小要比使用其它格式类型存储的文件的大小要小(通过实验多次，在相同采样率16000的情况下，一般录 制5分钟的音频，采用m4a格式存储的音频文件只有1.2Mb，而采用arm、mp3及其它格式的一般都有2-5Mb)，这样当用户需要 下载 或上传录制的音频文件时，可以节省流量，并且相同压缩率的前提下，m4a格式音频的音质相比其它格式的也更高； 2.产品同时拥有Android客户端和IOS客户端，那为了避免使用Android客户端的用户录制的音频上传到服务器之后，使用IOS客户端的用户下 载下来发生无法播放的问题，我们需统一录制音频的存储格式

v_rescale_q用于计算Packet的PTS。av_rescale_q的返回值是一个很大的整数，且每次计算的结果间隔很大。 不同于avcodec_encode_video改变AVCodecContext *avctx的pts（小整数，且间隔小）。 av_rescale_q(a,b,c)是用来把时间戳从一个时基调整到另外一个时基时候用的函数。它基本的动作是计算a*b/c，但是这个函数还是必需的，因为直接计算会有溢出的情况发生。AV_TIME_BASE_Q是AV_TIME_BASE作为分母后的版本。它们是很不相同的：AV_TIME_BASE * time_in_seconds = avcodec_timestamp而AV_TIME_BASE_Q * avcodec_timestamp = time_in_seconds（注意AV_TIME_BASE_Q实际上是一个AVRational对象，所以你必需使用avcodec中特定的q函数来处理它）。 H264/90000,代表时钟频率必须是90000 背景知识: (一个AAC原始帧包含一段时间内1024个采样及相关数据) 1. 视频时间戳 pts = inc++ *(1000/fps); 其中inc是一个静态的，初始值为0，每次打完时间戳inc加1. 在ffmpeg，中的代码为 pkt.pts= m_nVideoTimeStamp++

RTMP推送的音视频流的封装形式和FLV格式相似，由此可知，向FMS推送H264和AAC直播流，需要首先发送"AVC sequence header"和"AAC sequence header"，这两项数据包含的是重要的编码信息，没有它们，解码器将无法解码。 　　AVC sequence header就是AVCDecoderConfigurationRecord结构，该结构在标准文档“ISO-14496-15 AVC file format”中有详细说明。 　　AAC sequence header存放的是AudioSpecificConfig结构，该结构则在“ISO-14496-3 Audio”中描述。AudioSpecificConfig结构的描述非常复杂，这里我做一下简化，事先设定要将要编码的音频格式，其中，选择"AAC-LC"为音频编码，音频采样率为44100，于是AudioSpecificConfig简化为下表： 　　这样，AVC sequence header和AAC sequence header的内容可以基本确定了，更详细的信息，大家可以去翻阅相关文档。 在发送这两个header需要在前面分别加上 VideoTags、AudioTags 这连个tags都是1个字节（8bits）的数据 其中AudioTags每bit表示的意义如下图： 其中SoundData

AAC编码后数据打包到FLV很简单。 1. FLV音频Tag格式 字节位置 意义 0x08, // 0, TagType 0xzz, 0xzz, 0xzz, // 1-3, DataSize, 0xzz, 0xzz, 0xzz, 0xzz, // 4-6, 7 TimeStamp | TimeStampExtend 0x00, 0x00, 0x00, // 8-10, StreamID 0xzz, // 11, AudioTag Header 0x0b, // 12, AACPacketType (如果不是AAC编码 没有这个字节) 0xzz ... 0xzz // 音频数据 2. AudioTagHeader 音频Tag头一般由一个字节定义（AAC用两个字节），第一个字节的定义如下： 音频格式 4bits | 采样率 2bits | 采样精度 1bits | 声道数 1bits| 音频格式 4bits 0x00 = Linear PCM, platform endian 0x01 = ADPCM 0x02 = MP3 0x03 = Linear PCM, little endian 0x04 = Nellymoser 16-kHz mono 0x05 = Nellymoser 8-kHz mono 0x06 = Nellymoser 0x07 = G.711 A-law

本篇FFMEPG实现对AAC解码，解码结果保存wav格式。对AAC编码文件来说，编码根据音频参数编码，解码根据音频参数重新构建声波，FFMPEG构建的音频存储方式不一定支持播放, 所以需要重采样样本，如AAC解码的样本格式AV_SAMPLE_FMT_FLTP。AAC的解码器如果是外部解码器"aac",解码格式需要AV_SAMPLE_FMT_FLTP，如果是“libvo_aacenc”这个解码器需要格式AV_SAMPLE_FMT_S16。 AVFormatContext * pFormatCtx = avformat_alloc_context ( ) ; //打开封装格式 avformat_open_input ( & pFormatCtx , INPUT_FILE_NAME , NULL , NULL ) ‘ avformat_find_stream_info ( pFormatCtx , NULL ) ; // Dump valid information onto standard error av_dump_format ( pFormatCtx , 0 , INPUT_FILE_NAME , false ) ; // Find the first audio stream👉👉int audioStream // Get a pointer to the codec