### YUV颜色空间

视频是由一帧一帧的数据连接而成，而一帧视频数据其实就是一张图片。

yuv是一种图片储存格式，跟RGB格式类似。

RGB格式的图片很好理解，计算机中的大多数图片，都是以RGB格式存储的。

yuv中，y表示亮度，单独只有y数据就可以形成一张图片，只不过这张图片是灰色的。u和v表示色差(u和v也被称为：Cb－蓝色差，Cr－红色差)

常用的I420(YUV420P),NV12(YUV420SP),YV12（YUV420P）,NV21(YUV420SP)等都是属于YUV420，NV12是一种两平面存储方式，Y为一个平面，交错的UV为另一个平面

通常，用来远程传输的是I420数据，而本地摄像头采集的是NV12数据。（iOS）

所有在真正编码的过程中, 需要将NV12数据转成I420数据进行编码

### 视频编码方式

硬编码：使用非CPU进行编码，如显卡GPU、专用的DSP、FPGA、ASIC芯片等

软编码：使用CPU进行编码，软编码通常使用：ffmpeg+x264

ffmpeg：是一套开源的、用于对音视频进行编码&解码&转化计算机程序

x264：x264是一种免费的、开源的、具有更优秀算法的H.264/MPEG-4 AVC视频压缩编码方式

编码的流程：采集--> 获取到视频帧--> 对视频帧进行编码 --> 获取到视频帧信息 --> 将编码后的数据以NALU方式写入到文件

帧率：每秒钟多少帧画面

码率：单位时间内保存的数据量

（GOPsize)间隔：多少帧为一个GOP

### FFMPEG结构体 --AVPacket

AVPacket是存储压缩编码数据相关信息的结构体。本文将会详细分析一下该结构体里重要变量的含义和作用。

uint8_t *data：压缩编码的数据。

例如对于H.264来说。1个AVPacket的data通常对应一个NAL。

注意：在这里只是对应，而不是一模一样。他们之间有微小的差别：使用FFMPEG类库分离出多媒体文件中的H.264码流

因此在使用FFMPEG进行视音频处理的时候，常常可以将得到的AVPacket的data数据直接写成文件，从而得到视音频的码流文件。

int   size：data的大小

int64_t pts：显示时间戳

int64_t dts：解码时间戳

int   stream_index：标识该AVPacket所属的视频/音频流。

### FFMPEG结构体 --AVStream

AVStream是存储每一个视频/音频流信息的结构体。本文将会分析一下该结构体里重要变量的含义和作用。

int index：标识该视频/音频流

AVCodecContext *codec：指向该视频/音频流的AVCodecContext（它们是一一对应的关系）

AVRational time_base：时基。通过该值可以把PTS，DTS转化为真正的时间。FFMPEG其他结构体中也有这个字段，但是根据我的经验，只有AVStream中的time_base是可用的。PTS*time_base=真正的时间

int64_t duration：该视频/音频流长度

AVDictionary *metadata：元数据信息

AVRational avg_frame_rate：帧率（注：对视频来说，这个挺重要的）

AVPacket attached_pic：附带的图片。比如说一些MP3，AAC音频文件附带的专辑封面。

### FFMPEG结构体 --AVCodec

AVCodec是存储编解码器信息的结构体。

const char *name：编解码器的名字，比较短

const char *long_name：编解码器的名字，全称，比较长

enum AVMediaType type：指明了类型，是视频，音频，还是字幕

enum AVCodecID id：ID，不重复

const AVRational *supported_framerates：支持的帧率（仅视频）

const enum AVPixelFormat *pix_fmts：支持的像素格式（仅视频）

const int *supported_samplerates：支持的采样率（仅音频）

const enum AVSampleFormat *sample_fmts：支持的采样格式（仅音频）

const uint64_t *channel_layouts：支持的声道数（仅音频）

int priv_data_size：私有数据的大小

& H.264解码器的结构体如下:

AVCodec ff_h264_decoder = {  

    .name           = "h264",  

    .type           = AVMEDIA_TYPE_VIDEO,  

    .id             = CODEC_ID_H264,  

    .priv_data_size = sizeof(H264Context),  

    .init           = ff_h264_decode_init,  

    .close          = ff_h264_decode_end,  

    .decode         = decode_frame,  

    .capabilities   = /*CODEC_CAP_DRAW_HORIZ_BAND |*/ CODEC_CAP_DR1 | CODEC_CAP_DELAY |  

                      CODEC_CAP_SLICE_THREADS | CODEC_CAP_FRAME_THREADS,  

    .flush= flush_dpb,  

    .long_name = NULL_IF_CONFIG_SMALL("H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),  

    .init_thread_copy      = ONLY_IF_THREADS_ENABLED(decode_init_thread_copy),  

    .update_thread_context = ONLY_IF_THREADS_ENABLED(decode_update_thread_context),  

    .profiles = NULL_IF_CONFIG_SMALL(profiles),  

    .priv_class     = &h264_class,  

};  

### FFMPEG结构体 --AVIOContext

AVIOContext是FFMPEG管理输入输出数据的结构体。本文将会详细分析一下该结构体里每个变量的含义和作用。

unsigned char *buffer：缓存开始位置

int buffer_size：缓存大小（默认32768）

unsigned char *buf_ptr：当前指针读取到的位置

unsigned char *buf_end：缓存结束的位置

void *opaque：URLContext结构体

在解码的情况下，buffer用于存储ffmpeg读入的数据。例如打开一个视频文件的时候，先把数据从硬盘读入buffer，然后在送给解码器用于解码。

### FFMPEG结构体 --AVCodecContext

enum AVMediaType codec_type：编解码器的类型（视频，音频...）

struct AVCodec  *codec：采用的解码器AVCodec（H.264,MPEG2...）

int bit_rate：平均比特率

uint8_t *extradata; int extradata_size：针对特定编码器包含的附加信息（例如对于H.264解码器来说，存储SPS，PPS等）

AVRational time_base：根据该参数，可以把PTS转化为实际的时间（单位为秒s）

int width, height：如果是视频的话，代表宽和高

int refs：运动估计参考帧的个数（H.264的话会有多帧，MPEG2这类的一般就没有了）

int sample_rate：采样率（音频）

int channels：声道数（音频）

enum AVSampleFormat sample_fmt：采样格式

int profile：型（H.264里面就有，其他编码标准应该也有）

int level：级（和profile差不太多）

### FFMPEG结构体 -- AVFormatContext

AVFormatContext是包含码流参数较多的结构体。在使用FFMPEG进行开发的时候，AVFormatContext是一个贯穿始终的数据结构，很多函数都要用到它作为参数。它是FFMPEG解封装（flv，mp4，rmvb，avi）功能的结构体。下面看几个主要变量的作用（在这里考虑解码的情况）：

struct AVInputFormat *iformat：输入数据的封装格式

AVIOContext *pb：输入数据的缓存

unsigned int nb_streams：视音频流的个数

AVStream **streams：视音频流

char filename[1024]：文件名

int64_t duration：时长（单位：微秒us，转换为秒需要除以1000000）

int bit_rate：比特率（单位bps，转换为kbps需要除以1000）

AVDictionary *metadata：元数据

### FFMPEG结构体 -- AVFrame

AVFrame结构体一般用于存储原始数据（即非压缩数据，例如对视频来说是YUV，RGB，对音频来说是PCM），此外还包含了一些相关的信息。比如说，解码的时候存储了宏块类型表，QP表，运动矢量表等数据。编码的时候也存储了相关的数据。因此在使用FFMPEG进行码流分析的时候，AVFrame是一个很重要的结构体。

uint8_t *data[AV_NUM_DATA_POINTERS]：解码后原始数据（对视频来说是YUV，RGB，对音频来说是PCM）

int linesize[AV_NUM_DATA_POINTERS]：data中“一行”数据的大小。注意：未必等于图像的宽，一般大于图像的宽。

int width, height：视频帧宽和高（1920x1080,1280x720...）

int nb_samples：音频的一个AVFrame中可能包含多个音频帧，在此标记包含了几个

int format：解码后原始数据类型（YUV420，YUV422，RGB24...）

int key_frame：是否是关键帧

enum AVPictureType pict_type：帧类型（I,B,P...）

AVRational sample_aspect_ratio：宽高比（16:9，4:3...）

int64_t pts：显示时间戳

int coded_picture_number：编码帧序号

int display_picture_number：显示帧序号

int8_t *qscale_table：QP表

uint8_t *mbskip_table：跳过宏块表

int16_t (*motion_val[2])[2]：运动矢量表

uint32_t *mb_type：宏块类型表

short *dct_coeff：DCT系数，这个没有提取过

int8_t *ref_index[2]：运动估计参考帧列表（貌似H.264这种比较新的标准才会涉及到多参考帧）

int interlaced_frame：是否是隔行扫描

uint8_t motion_subsample_log2：一个宏块中的运动矢量采样个数，取log的;<4->16x16, 3->8x8, 2-> 4x4, 1-> 2x2

### 运动矢量表的存储方式

int16_t (*motion_val[2])[2];//运动矢量表存储了一帧视频中的所有运动矢量

int mv_sample_log2= 4 - motion_subsample_log2;  

int mb_width= (width+15)>>4;  

int mv_stride= (mb_width << mv_sample_log2) + 1;  

motion_val[direction][x + y*mv_stride][0->mv_x, 1->mv_y];  

大概知道了该数据的结构：

1.首先分为两个列表L0和L1

2.每个列表（L0或L1）存储了一系列的MV（每个MV对应一个画面，大小由motion_subsample_log2决定）

3.每个MV分为横坐标和纵坐标（x,y）

注意，在FFMPEG中MV和MB在存储的结构上是没有什么关联的，第1个MV是屏幕上左上角画面的MV（画面的大小取决于motion_subsample_log2），第2个MV是屏幕上第1行第2列的画面的MV，以此类推。因此在一个宏块（16x16）的运动矢量很有可能如下图所示（line代表一行运动矢量的个数）：

### 音频编码基本原理

（1）  音频信号的冗余信息

数字音频信号如果不加压缩地直接进行传送，将会占用极大的带宽。例如，一套双声道数字音频若取样频率为44.1KHz，每样值按16bit量化，则其码率为：

2*44.1kHz*16bit=1.411Mbit/s

如此大的带宽将给信号的传输和处理都带来许多困难，因此必须采取音频压缩技术对音频数据进行处理，才能有效地传输音频数据。

数字音频压缩编码在保证信号在听觉方面不产生失真的前提下，对音频数据信号进行尽可能大的压缩。数字音频压缩编码采取去除声音信号中冗余成分的方法来实现。所谓冗余成分指的是音频中不能被人耳感知到的信号，它们对确定声音的音色，音调等信息没有任何的帮助。

冗余信号包含人耳听觉范围外的音频信号以及被掩蔽掉的音频信号等。例如，人耳所能察觉的声音信号的频率范围为20Hz～20KHz，除此之外的其它频率人耳无法察觉，都可视为冗余信号。此外，根据人耳听觉的生理和心理声学现象，当一个强音信号与一个弱音信号同时存在时，弱音信号将被强音信号所掩蔽而听不见，这样弱音信号就可以视为冗余信号而不用传送。这就是人耳听觉的掩蔽效应，主要表现在频谱掩蔽效应和时域掩蔽效应，现分别介绍如下：

（a）  频谱掩蔽效应

一个频率的声音能量小于某个阈值之后，人耳就会听不到，这个阈值称为最小可闻阈。当有另外能量较大的声音出现的时候，该声音频率附近的阈值会提高很多，即所谓的掩蔽效应。如图所示：

频率掩蔽效应

由图中我们可以看出人耳对2KHz～5KHz的声音最敏感，而对频率太低或太高的声音信号都很迟钝，当有一个频率为0.2KHz、强度为60dB的声音出现时，其附近的阈值提高了很多。由图中我们可以看出在0.1KHz以下、1KHz以上的部分,由于离0.2KHz强信号较远，不受0.2KHz强信号影响,阈值不受影响；而在0.1KHz～1KHz范围，由于0.2KHz强音的出现,阈值有较大的提升，人耳在此范围所能感觉到的最小声音强度大幅提升。如果0.1KHz～1KHz范围内的声音信号的强度在被提升的阈值曲线之下，由于它被0.2KHz强音信号所掩蔽，那么此时我们人耳只能听到0.2KHz的强音信号而根本听不见其它弱信号，这些与0.2KHz强音信号同时存在的弱音信号就可视为冗余信号而不必传送。

（b）  时域掩蔽效应

当强音信号和弱音信号同时出现时，还存在时域掩蔽效应。即两者发生时间很接近的时候，也会发生掩蔽效应。时域掩蔽过程曲线如图所示，分为前掩蔽、同时掩蔽和后掩蔽三部分。

时域掩蔽效应

由图我们可以看出，时域掩蔽效应可以分成三种：前掩蔽，同时掩蔽，后掩蔽。前掩蔽是指人耳在听到强信号之前的短暂时间内，已经存在的弱信号会被掩蔽而听不到。同时掩蔽是指当强信号与弱信号同时存在时，弱信号会被强信号所掩蔽而听不到。后掩蔽是指当强信号消失后，需经过较长的一段时间才能重新听见弱信号，称为后掩蔽。这些被掩蔽的弱信号即可视为冗余信号。

（2）  压缩编码方法

当前数字音频编码领域存在着不同的编码方案和实现方式, 但基本的编码思路大同小异, 如图所示。

数字音频编码系统模型

对每一个音频声道中的音频采样信号,首先都要将它们映射到频域中,这种时域到频域的映射可通过子带滤波器实现。每个声道中的音频采样块首先要根据心理声学模型来计算掩蔽门限值, 然后由计算出的掩蔽门限值决定从公共比特池中分配给该声道的不同频率域中多少比特数，接着进行量化以及编码工作，最后将控制参数及辅助数据加入数据之中，产生编码后的数据流。

### 视频编码的基本原理

1)视频信号的冗余信息

以记录数字视频的YUV分量格式为例，YUV分别代表亮度与两个色差信号。例如对于现有的PAL制电视系统，其亮度信号采样频率为13.5MHz；色度信号的频带通常为亮度信号的一半或更少，为6.75MHz或3.375MHz。以4：2：2的采样频率为例，Y信号采用13.5MHz，色度信号U和V采用6.75MHz采样，采样信号以8bit量化，则可以计算出数字视频的码率为：13.5*8 + 6.75*8 + 6.75*8= 216Mbit/s

如此大的数据量如果直接进行存储或传输将会遇到很大困难，因此必须采用压缩技术以减少码率。数字化后的视频信号能进行压缩主要依据两个基本条件：

l  数据冗余。例如如空间冗余、时间冗余、结构冗余、信息熵冗余等，即图像的各像素之间存在着很强的相关性。消除这些冗余并不会导致信息损失，属于无损压缩。

l  视觉冗余。人眼的一些特性比如亮度辨别阈值，视觉阈值，对亮度和色度的敏感度不同，使得在编码的时候引入适量的误差，也不会被察觉出来。可以利用人眼的视觉特性，以一定的客观失真换取数据压缩。这种压缩属于有损压缩。

数字视频信号的压缩正是基于上述两种条件，使得视频数据量得以极大的压缩，有利于传输和存储。一般的数字视频压缩编码方法都是混合编码，即将变换编码，运动估计和运动补偿，以及熵编码三种方式相结合来进行压缩编码。通常使用变换编码来消去除图像的帧内冗余，用运动估计和运动补偿来去除图像的帧间冗余，用熵编码来进一步提高压缩的效率。下文简单介绍这三种压缩编码方法。

2)压缩编码的方法

a）  变换编码

变换编码的作用是将空间域描述的图像信号变换到频率域，然后对变换后的系数进行编码处理。一般来说，图像在空间上具有较强的相关性，变换到频率域可以实现去相关和能量集中。常用的正交变换有离散傅里叶变换，离散余弦变换等等。数字视频压缩过程中应用广泛的是离散余弦变换。

离散余弦变换简称为DCT变换。它可以将L*L的图像块从空间域变换为频率域。所以，在基于DCT的图像压缩编码过程中，首先需要将图像分成互不重叠的图像块。假设一帧图像的大小为1280*720，首先将其以网格状的形式分成160*90个尺寸为8*8的彼此没有重叠的图像块，接下来才能对每个图像块进行DCT变换。

经过分块以后，每个8*8点的图像块被送入DCT编码器，将8*8的图像块从空间域变换为频率域。下图给出一个实际8*8的图像块例子，图中的数字代表了每个像素的亮度值。从图上可以看出，在这个图像块中各个像素亮度值比较均匀，特别是相邻像素亮度值变化不是很大，说明图像信号具有很强的相关性。

一个实际8*8图像块

下图是上图中图像块经过DCT变换后的结果。从图中可以看出经过DCT变换后，左上角的低频系数集中了大量能量，而右下角的高频系数上的能量很小。

图像块经过DCT变换后的系数

信号经过DCT变换后需要进行量化。由于人的眼睛对图像的低频特性比如物体的总体亮度之类的信息很敏感，而对图像中的高频细节信息不敏感，因此在传送过程中可以少传或不传送高频信息，只传送低频部分。量化过程通过对低频区的系数进行细量化，高频区的系数进行粗量化，去除了人眼不敏感的高频信息，从而降低信息传送量。因此，量化是一个有损压缩的过程，而且是视频压缩编码中质量损伤的主要原因。

量化的过程可以用下面的公式表示：

其中FQ（u,v）表示经过量化后的DCT系数；F（u,v）表示量化前的DCT系数；Q（u,v）表示量化加权矩阵；q表示量化步长；round表示归整，即将输出的值取为与之最接近的整数值。

合理选择量化系数，对变换后的图像块进行量化后的结果如图所示。

量化后的DCT系数

DCT系数经过量化之后大部分经变为0，而只有很少一部分系数为非零值，此时只需将这些非0值进行压缩编码即可。

（b）  熵编码

熵编码是因编码后的平均码长接近信源熵值而得名。熵编码多用可变字长编码（VLC，Variable Length Coding）实现。其基本原理是对信源中出现概率大的符号赋予短码，对于出现概率小的符号赋予长码，从而在统计上获得较短的平均码长。可变字长编码通常有霍夫曼编码、算术编码、游程编码等。其中游程编码是一种十分简单的压缩方法，它的压缩效率不高，但编码、解码速度快，仍被得到广泛的应用，特别在变换编码之后使用游程编码，有很好的效果。

首先要在量化器输出直流系数后对紧跟其后的交流系数进行Z型扫描（如图箭头线所示）。Z型扫描将二维的量化系数转换为一维的序列，并在此基础上进行游程编码。最后再对游程编码后的数据进行另一种变长编码，例如霍夫曼编码。通过这种变长编码，进一步提高编码的效率。

（c）  运动估计和运动补偿

运动估计（Motion Estimation）和运动补偿（Motion Compensation）是消除图像序列时间方向相关性的有效手段。上文介绍的DCT变换、量化、熵编码的方法是在一帧图像的基础上进行，通过这些方法可以消除图像内部各像素间在空间上的相关性。实际上图像信号除了空间上的相关性之外，还有时间上的相关性。例如对于像新闻联播这种背景静止，画面主体运动较小的数字视频，每一幅画面之间的区别很小，画面之间的相关性很大。对于这种情况我们没有必要对每一帧图像单独进行编码，而是可以只对相邻视频帧中变化的部分进行编码，从而进一步减小数据量，这方面的工作是由运动估计和运动补偿来实现的。

运动估计技术一般将当前的输入图像分割成若干彼此不相重叠的小图像子块，例如一帧图像的大小为1280*720，首先将其以网格状的形式分成40*45个尺寸为16*16的彼此没有重叠的图像块，然后在前一图像或者后一个图像某个搜索窗口的范围内为每一个图像块寻找一个与之最为相似的图像块。这个搜寻的过程叫做运动估计。通过计算最相似的图像块与该图像块之间的位置信息，可以得到一个运动矢量。这样在编码过程中就可以将当前图像中的块与参考图像运动矢量所指向的最相似的图像块相减，得到一个残差图像块，由于残差图像块中的每个像素值很小，所以在压缩编码中可以获得更高的压缩比。这个相减过程叫运动补偿。

由于编码过程中需要使用参考图像来进行运动估计和运动补偿，因此参考图像的选择显得很重要。一般情况下编码器的将输入的每一帧图像根据其参考图像的不同分成3种不同的类型：I（Intra）帧、B（Bidirection prediction）帧、P（Prediction）帧。如图所示。

典型的I，B，P帧结构顺序

如图所示，I帧只使用本帧内的数据进行编码，在编码过程中它不需要进行运动估计和运动补偿。显然，由于I帧没有消除时间方向的相关性，所以压缩比相对不高。P帧在编码过程中使用一个前面的I帧或P帧作为参考图像进行运动补偿，实际上是对当前图像与参考图像的差值进行编码。B帧的编码方式与P帧相似，惟一不同的地方是在编码过程中它要使用一个前面的I帧或P帧和一个后面的I帧或P帧进行预测。由此可见，每一个P帧的编码需要利用一帧图像作为参考图像，而B帧则需要两帧图像作为参考。相比之下，B帧比P帧拥有更高的压缩比。

（d）  混合编码

上面介绍了视频压缩编码过程中的几个重要的方法。在实际应用中这几个方法不是分离的，通常将它们结合起来使用以达到最好的压缩效果。下图给出了混合编码（即变换编码+ 运动估计和运动补偿+ 熵编码）的模型。该模型普遍应用于MPEG1，MPEG2，H.264等标准中。

混合编码模型

从图中我们可以看到，当前输入的图像首先要经过分块，分块得到的图像块要与经过运动补偿的预测图像相减得到差值图像X，然后对该差值图像块进行DCT变换和量化，量化输出的数据有两个不同的去处：一个是送给熵编码器进行编码，编码后的码流输出到一个缓存器中保存，等待传送出去。另一个应用是进行反量化和反变化后的到信号X’，该信号将与运动补偿输出的图像块相加得到新的预测图像信号，并将新的预测图像块送至帧存储器。

### RTSP协议剖析

RTSP(Real-TimeStream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。

RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话.

### 字节序

现代的计算机系统一般采用字节(Octet, 8 bit Byte)作为逻辑寻址单位。当物理单位的长度大于1个字节时，就要区分字节顺序(Byte Order, orEndianness)。常见的字节顺序有两种：Big Endian(High-byte first)和Little Endian(Low-byte first)，这就是表2.1中的BE和LE。Intel X86平台采用Little Endian，而PowerPC处理器则采用了Big Endian。举例来说，整型数字$1234ABCD存储的时候就会有两种方式：

字节顺序内存数据备注

Big Endian (BE)0xAB 0xCD 0x12 0x34此时的0xAB被称为most significant byte (MSB)

Little Endian (LE)0xCD 0xAB 0x34 0x12此时的0xCD被称为least significant byte (LSB)

大端: 低地址存放最高有效位（MSB），既高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。

小端: 低地址存放最低有效位（LSB），既低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。

TCP/IP各层协议将字节序定义为Big-Endian，因此TCP/IP协议中使用的字节序通常称之为网络字节序。

### QoS(网络视频传输的服务质量)

QoS（Qualityof Service）服务质量，是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技术。在正常情况下，如果网络只用于特定的无时间限制的应用系统，并不需要QoS，比如Web应用，或E-mail设置等。但是对关键应用和多媒体应用就十分必要。当网络过载或拥塞时，QoS 能确保重要业务量不受延迟或丢弃，同时保证网络的高效运行。

ITU将服务质量定义为决定用户对服务的满意程度的一组服务性能指标。从另一角度来说，QoS参数也是流媒体媒体传输的性能指标。主要的QoS参数有如下几项：传输带宽，传输时延和抖动，丢包率。

1.传输带宽

传输带宽也指的是数据传输的速率。对于流媒体的播放，影响最大的属性就是传输带宽。如果带宽过低，使得数据传输下载的速度小于视频流播放的数率，那么在视频的播放将会经常出现停顿和缓冲，极大的影响了客户观看的流畅性；而为了保证视频观看的流畅性，在低带宽的条件下，只能选择低品质、低码流的视频进行传输，这样又会影响到客户的光看效果。所以，一个良好的传输带宽环境是客户活动高品质的流媒体体验的重要保证。

2.传输时延和抖动

传输时延定义为从服务器端发送数据到接受端接收到该数据之间的时间差，它是用来描述网络时延的一个指标。时延抖动定义为网络传输延时的变化率。流媒体最重要一个特性的就是实时性强，所以流媒体通信需求更难于满足的是对通信系统的传输时延限制。时延限制主要是用在具有实时性要求的交互分布式实时流媒体应用中，如视频会议系统，为防止时延给交互式通信带来不便，建议的最大端到端的总时延不要超过150ms，否则交互双方会感到明显的时延，给双方的信息交流带来不便。端到端的时延可分为以下四个部分：

1．信息源的媒体采样、压缩编码和打包的时延；

2．传输时延；

3．接收端的排队和播放缓冲时延；

4．接收端的拆包、解码和输出时延。

抖动定义为网络传输延时的变化率。时延抖动对流媒体播放质量的影响非常大，一般会采用缓存排队的办法平滑数据报的抖动。但如果数据传输的抖动较大，则必须采用大的缓存，这将直接造成更大的时延，直接影响流媒体的体验效果。

3.丢包率

流媒体数据传输中的时延和抖动是可以通过缓存的办法减少影响，所以流媒体业务可以允许在一定范围内的时延和抖动。但丢包会对流媒体数，据播放质量造成极其重大的影响。丢包率会造成视频和音频质量严重恶化，小的丢包率会造成图像的失真和语音的间歇中断，过高的丢包率甚至可以导致业务的中断。网络设计的目标是丢包率为零，但显然不存在这样的理想网络。所以丢包的大小将直接决定流媒体业务质量的好坏。

### 分离H264码流

1.第一次存储AVPacket之前需要在前面加上H.264的SPS和PPS。这些信息存储在AVCodecContext的extradata里面。

并且需要使用FFMPEG中的名为"h264_mp4toannexb"的bitstream filter 进行处理。

然后将处理后的extradata存入文件.

    1.FILE *fp=fopen("test.264","ab");

    2.AVCodecContext *pCodecCtx=...  

    3.unsigned char *dummy=NULL;   //输入的指针  

    4.int dummy_len;  

    5.AVBitStreamFilterContext* bsfc =  av_bitstream_filter_init("h264_mp4toannexb");    

    6.av_bitstream_filter_filter(bsfc, pCodecCtx, NULL, &dummy, &dummy_len, NULL, 0, 0);  

    7.fwrite(pCodecCtx->extradata,pCodecCtx-->extradata_size,1,fp);  

    8.av_bitstream_filter_close(bsfc);    

    9.free(dummy);

2.通过查看FFMPEG源代码我们发现，AVPacket中的数据起始处没有分隔符(0x00000001), 也不是0x65、0x67、0x68、0x41等字节，所以可以AVPacket肯定这不是标准的nalu。其实，AVPacket前4个字表示的是nalu的长度，从第5个字节开始才是nalu的数据。所以直接将AVPacket前4个字节替换为0x00000001即可得到标准的nalu数据。

char nal_start[]={0,0,0,1};  

fwrite(nal_start,4,1,fp);  

fwrite(pkt->data+4,pkt->size-4,1,fp);  

fclose(fp);

### AAC格式简介

AAC的音频文件格式有以下两种：

ADIF：Audio Data Interchange Format 音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。

ADTS：Audio Data Transport Stream 音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。这种格式可以用于广播电视。

简言之。ADIF只有一个文件头，ADTS每个包前面有一个文件头。

AAC的ADIF格式见下图：

AAC的ADTS的一般格式见下图：

### RTMP规范简单分析

RTMP协议是一个互联网TCP/IP五层体系结构中应用层的协议。RTMP协议中基本的数据单元称为消息（Message）。当RTMP协议在互联网中传输数据的时候，消息会被拆分成更小的单元，称为消息块（Chunk）。

1 消息

消息是RTMP协议中基本的数据单元。不同种类的消息包含不同的Message Type ID，代表不同的功能。RTMP协议中一共规定了十多种消息类型，分别发挥着不同的作用。例如，Message Type ID在1-7的消息用于协议控制，这些消息一般是RTMP协议自身管理要使用的消息，用户一般情况下无需操作其中的数据。Message Type ID为8，9的消息分别用于传输音频和视频数据。Message Type ID为15-20的消息用于发送AMF编码的命令，负责用户与服务器之间的交互，比如播放，暂停等等。消息首部（Message Header）有四部分组成：标志消息类型的Message Type ID，标志消息长度的Payload Length，标识时间戳的Timestamp，标识消息所属媒体流的Stream ID。消息的报文结构如图3所示。

2 消息块

在网络上传输数据时，消息需要被拆分成较小的数据块，才适合在相应的网络环境上传输。RTMP协议中规定，消息在网络上传输时被拆分成消息块（Chunk）。消息块首部（Chunk Header）有三部分组成：用于标识本块的Chunk Basic Header，用于标识本块负载所属消息的Chunk Message Header，以及当时间戳溢出时才出现的Extended Timestamp。消息块的报文结构如图4所示。

在消息被分割成几个消息块的过程中，消息负载部分（Message Body）被分割成大小固定的数据块（默认是128字节，最后一个数据块可以小于该固定长度），并在其首部加上消息块首部（Chunk Header），就组成了相应的消息块。消息分块过程如图5所示，一个大小为307字节的消息被分割成128字节的消息块（除了最后一个）。

### TI和SI的概念

SI表征一帧图像的空间细节量。空间上越复杂的场景，SI值越高。

TI表征视频序列的时间变化量。运动程度较高的序列通常会有更高的TI值。

SI计算方法：对第n帧视频进行Sobel滤波，然后对滤波后图像计算标准差。选这些帧中的最大值为SI。

TI计算方法：求n与n-1帧图像的帧差，然后对帧差图像计算标准差。选这些帧中的最大值为TI。

### 函数avformat_open_input

FFMPEG打开媒体的的过程开始于avformat_open_input，因此该函数的重要性不可忽视。

在该函数中，FFMPEG完成了：

- 输入输出结构体AVIOContext的初始化；

- 输入数据的协议（例如RTMP，或者file）的识别（通过一套评分机制）:1判断文件名的后缀 2读取文件头的数据进行比对；

- 使用获得最高分的文件协议对应的URLProtocol，通过函数指针的方式，与FFMPEG连接（非专业用词）；

- 剩下的就是调用该URLProtocol的函数进行open,read等操作了.

      URLProtocol结构如下,是一大堆函数指针的集合:

typedef struct URLProtocol {  

    const char *name;  

    int (*url_open)(URLContext *h, const char *url, int flags);  

    int (*url_read)(URLContext *h, unsigned char *buf, int size);  

    int (*url_write)(URLContext *h, const unsigned char *buf, int size);  

    int64_t (*url_seek)(URLContext *h, int64_t pos, int whence);  

    int (*url_close)(URLContext *h);  

    struct URLProtocol *next;  

    int (*url_read_pause)(URLContext *h, int pause);  

    int64_t (*url_read_seek)(URLContext *h, int stream_index,  

                             int64_t timestamp, int flags);  

    int (*url_get_file_handle)(URLContext *h);  

    int priv_data_size;  

    const AVClass *priv_data_class;  

    int flags;  

    int (*url_check)(URLContext *h, int mask);  

} URLProtocol;  

### 视频插入

视频直播想在 HLS 流中无缝插入一段广告的 ts 文件，有问题想请教一下：1、这段 ts 的分辨率是否一定要和之前的视频流一致？2、pts 时间戳是否要和上一个 ts 递增？

徐立：1、可以不一致。这种情况两段视频完全是独立状态，可以没有任何关系，只需要插入 discontinue 标记，播放器在识别到这个标记之后重置解码器参数就可以无缝播放，画面会很平滑的切换。2、不需要递增。举个例子，视频 A 正在直播，播放到 pts 在 5s 的时候，插入一个视频 B，需要先插入一个 discontinue，再插入 B，等 B 播放完之后，再插入一个 discontinue，再插入 A，这个时候 A 的 pts 可以和之前递增，也可以按照中间插入的 B 的时长做偏移，一般做点播和时移的时候 pts 会连续递增，直播的话会算上 B 的时长。

### I帧和IDR帧的区别

中文都把 I 帧翻译成关键帧了，不过既然提到了 IDR 帧，可以展开说明一下。所有的 IDR 帧都是 I 帧，但是并不是所有 I 帧都是 IDR 帧，IDR 帧是 I 帧的子集。I 帧严格定义是帧内编码帧，由于是一个全帧压缩编码帧，通常用 I 帧表示 “关键帧”。IDR 是基于 I 帧的一个 “扩展”，带了控制逻辑，IDR 图像都是 I 帧图像，当解码器解码到 IDR 图像时，会立即将参考帧队列清空，将已解码的数据全部输出或抛弃。重新查找参数集，开始一个新的序列。这样如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR 图像之后的图像永远不会使用 IDR 之前的图像的数据来解码。

### 直播体验优化

这其实是一个直播过程中传输网络不可靠时的容错问题。例如，播放端临时断网了，但又快速恢复了，针对这种场景，播放端如果不做容错处理，很难不出现黑屏或是重新加载播放的现象。

为了容忍这种网络错误，并达到让终端用户无感知，客户端播放器可以考虑构建一个FIFO（先进先出）的缓冲队列，解码器从播放缓存队列读取数据，缓存队列从直播服务器源源不断的下载数据。通常，缓存队列的容量是以时间为单位（比如3s），在播放端网络不可靠时，客户端缓存区可以起到“断网无感”的过渡作用。

&物理上优化线路，逻辑上优化策略，比如选择性丢帧，不影响编码画质的前提下减轻传输体积.

### 直播秒开策略

大部分播放器都是拿到一个完成的 GOP 后才能解码播放，基于 FFmpeg 移植的播放器甚至需要等待音画时间戳同步后才能播放.

GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。

& 如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。从缓存 GOP 改成缓存双关键帧（减少图像数量），这样可以极大程度地减少播放器加载 GOP 要传输的内容体积。

& 提前做好 DNS 解析（省却几十毫秒），和提前做好测速选线（择取最优线路）。经过这样的预处理后，在点击播放按钮时，将极大提高下载性能。

& 除了移动端可以做体验优化之外，直播流媒体服务端架构也可以降低延迟。例如收流服务器主动推送 GOP 至边缘节点，边缘节点缓存 GOP，播放端则可以快速加载，减少回源延迟。

### 采集端第三方框架推荐

& VideoCore 目前国内很多知名的推流框架都是对VideoCore的二次开发.<支持RTMP>

& LiveVideoCoreSDK 基于OpenGL,实现了美颜直播和滤镜功能,是一款非常厉害的推流SDK.

& LFLiveKit 可读性较好的推流框架,支持动态切换码率和美颜功能.

& GPUImage 纯OC语言,可以做出各种不同滤镜,美颜也可以直接使用BeautifyFace

### m3u8文件简介

m3u8，是HTTP Live Streaming直播的索引文件。m3u8基本上可以认为就是.m3u格式文件，区别在于，m3u8文件使用UTF-8字符编码。

#EXTM3U                     m3u文件头，必须放在第一行

#EXT-X-MEDIA-SEQUENCE       第一个TS分片的序列号

#EXT-X-TARGETDURATION       每个分片TS的最大的时长

#EXT-X-ALLOW-CACHE          是否允许cache

#EXT-X-ENDLIST              m3u8文件结束符

#EXTINF                     extra info，分片TS的信息，如时长，带宽等

一个简单的m3u8索引文件

### 各种音频格式

AAC: AAC其实是“高级音频编码（advanced audio coding）”的缩写，它是被设计用来取代MP3格式的。你可能会想，它压缩了原始的声音，导致容量占用少但是质量肯定会有所下降。不过这些质量的损失 取决于声音比特率的大小，当比特率合适的时候，这些损失人耳是很难听出来的。事实上，aac比mp3有更好的压缩率，特别是在比特率低于128bit/s 的时候。

HE-AAC: HE-AAC是AAC的一个超集，这个“HE”代表的是“High efficiency”。 HE-AAC是专门为低比特率所优化的一种音频编码格式，比如streaming audio就特别适合使用这种编码格式。

AMR: AMR全称是“Adaptive Multi-Rate”，它也是另一个专门为“说话（speech）”所优化的编码格式，也是适合低比特率环境下采用。

ALAC: 它全称是“Apple Lossless”，这是一种没有任何质量损失的音频编码方式，也就是我们说的无损压缩。在实际使用过程中，它能够压缩40%-60%的原始数据。这种编码格式的解码速度非常快，这对iphone或者ipod这种小型设备来说非常适合。

iLBC: 这是另一种专门为说话所设计的音频编码格式，它非常适合于IP电话等其它需要流式音频的场合。

IMA4: 这是一个在16-bit音频文件下按照4：1的压缩比来进行压缩的格式。这是iphone上面一种非常重要的编码格式。

它的中文意思是基于线性脉冲编码调制，用于将模拟声音数据转换成数字声音数据。简而言之，就是意味着无压缩数据。由于数据是非压缩的，它可以非常快的播放，并且当空间不是问题时，这是在iphone上面首选的音频编码方式。

μ-law and a-law: 就我所知道的，这种编码是交替的编码模拟数据为数字格式数据，但是在speech优化方面比linear PCM更好。

MP3: 这种格式是我们都知道也喜欢的，虽然很多年过去了，但MP3到目前为止仍然是一种非常流行的编码格式，它也能被iphone很好地支持。

LPCM也很早就被定义在DVD播放机 的标准内，为了和CD有所区别，DVD的的采样规格为16bit/48KHz，随着技术的发展，DVD的的采样规格更提升到24bit/96KHz，以达 到更高的播放品质，用96KHz/24bit方式记录的音频信号所能达到的频率上限是96÷2= 48KHz，而它的最大动态范围将可以达到24×6=144dB。从指标上就可以看出：它的声音比CD要好得多。pcm编码的最大的优点就是音质好，最大的缺点就是体数据量大。

### OpenGL概述

1. GL表示Graphics Library,即图形库;OpenGL是一种可以对图形硬件设备特性进行访问的软件库.

2.我们需要通过一系列的几何图元<点,线,三角形,Patch>来创建3维空间的物体.

3.像素是显示器上最小的可见单元.计算机系统将所有的像素保存到帧缓存当中;后者是由图像硬件设备管理的一块独立内存区域,可以直接映射到最终的显示设备上.

4.光栅化:将输入图元的数学描述转为屏幕位置对应的像素片元,称为光栅化.

5.OpenGL被设计为一个用来更新帧缓冲区内容的状态机;将几何图元,图像和位图转换为屏幕上的像素的过程是由非常多的状态设置来控制的.这些状态设置是彼此是正交的--设置某一个状态不会影响其他状态;

& 图片的本质是像素点的数组.

### H264裸流结构组成

      H.264 的基本流由一系列NALU (Network Abstraction Layer Unit )组成,不同的NALU数据量各不相同。H.264 草案指出，当数据流是储存在介质上时，在每个NALU 前添加起始码:0x000001 或 0x00000001， 来指示一个NALU 的起始和终止位置。在这样的机制下，在码流中检测起始码，作为一 个NALU的起始标识,当检测到下一个起始码时，当前NALU结束。

      H.264 码流中每个帧的开头的3~4个字节是H.264 的start_code(起始码)，0x00000001或者0x000001。3字节的0x000001只有一种场合下使 ，就是一个完整的帧被编为多个slice(片)的时候，包含这些slice的NALU 使用3字节起始码。其余场合都是4字节0x00000001的。 每个NALU单元由一个字节的 NALU头(NALU Header)和若干个字节的载荷数据(RBSP)组成。

& 常见的帧类型

NAL_SLICE = 1 非关键帧    NAL_SLICE_DPA = 2    NAL_SLICE_DPB = 3    NAL_SLICE_DPC =4

NAL_SLICE_IDR =5 关键帧  NAL_SEI = 6 增强帧    NAL_SPS = 7 SPS帧

NAL_PPS = 8 PPS帧          NAL_AUD = 9 分隔符    NAL_FILLER = 12

enum AVPictureType {

    AV_PICTURE_TYPE_NONE = 0, ///< Undefined

    AV_PICTURE_TYPE_I,    ///< Intra

    AV_PICTURE_TYPE_P,    ///< Predicted

    AV_PICTURE_TYPE_B,    ///< Bi-dir predicted

    AV_PICTURE_TYPE_S,    ///< S(GMC)-VOP MPEG4

    AV_PICTURE_TYPE_SI,    ///< Switching Intra

    AV_PICTURE_TYPE_SP,    ///< Switching Predicted

    AV_PICTURE_TYPE_BI,    ///< BI type