引言：
作为消费者，我们对于各种形式的视频系统都已经非常熟悉了。但是从嵌入式开发人员的角度来看，视频就好像是一张纷繁复杂的网络，里面充满了各种不同的分辨率、格式、标准与显示等。
数字视频：
在20世纪90年代中期之前，几乎所有的视频都是模拟类型的。直到出现了MPEG-2压缩标准，流媒体在互联网上广泛流行，以及FCC(Federal Communications Commission,美国联邦电信委员会)采用了数字电视(DTV)标准，才产生了一次所谓的”完美风暴”，也就是把数字表示方法的好处带到了视频领域内。相对模拟视频而言，数字视频的优点包括:更高的信噪比，提高了带宽利用率(在现有的每一个模拟传输通道中可同时传输多个通道的数字视频信号)，以及通过数字压缩技术降低了对存储空间的要求。
从根本上来说，对模拟视频信号进行数字化处理包括两个方面:采样和量化。在视频帧的二维结构中，采样就必须向画格子一样，先将图像按空间划分为一些小的区域，然后根据每个区域颜色空间成分强度的不同分配一些相对的幅值。需要注意的是，模拟视频已经经过了垂直采样(离散的行数)和时间采样(每秒离散的帧数)。
采样与量化
量化是这样一个过程:在采样过程中决定那些离散的幅度值。在消费领域内，经常用8比特的视频，也就是说在每个颜色通道(RGB或者YCbCr)中用0表示最暗(即纯黑色)，用255表示最亮(即白色)。但是，我们应该注意到，每个颜色通常中10比特和12比特的量化正在快速进入主流的视频品中，这些额外的精度可以用来减小舍入误差，从而降低接受图像的噪声。
常用视频采样率
数字视频的出现，在很大程度上为NTSC和PAL系统接口的标准化提供了一个极好的机会。当国际电信联盟(ITU)开会制定数字视频标准的建议时，主要议题集中在如何实现NTSC和PAL标准之间最大程度的共用性，这样一来，两个标准就可以共享同一种编码格式。
国际电信联盟(ITU)定义了两个各自独立的建议——ITU-R BT.601和ITU-R BT.656。这两个建议放在一起，就定义了一种结构，可以使不同的数字视频系统进行互操作。BT.601定义了数字视频传输的参数，而BT.656定义了接口本身。
FPGA处理656格式视频数据流
ITU-RBT.601：
BT.601标注定义了以数字方式编码视频信号的方法，为了有效利用通道的带宽，使用了YcbCr颜色空间。该标注中建议将4:2:2 YcbCr作为广播视频中优先的格式。另外还提供了同步信号(HSYNC’ VSYNC’FIELD)和一个时钟信号，用来描述活动视频区域的边界。
每一个BT.601像素分量(Y’Cr或Cb)被量化为8比特或10 比特，NTSC和PAL系统的活动视频区域中每一行有720像素。但是，这两个系统在垂直分辨率上有所不同。30帧/秒的NTSC系统有525行(包括垂直消隐或者回扫区)，而25帧/秒的PAL系统比NTSC系统增加了100行，达到625行，这样PAL系统也适用同样的标准。
ITU-RBT.601输入时序图
BT.601标准中规定，Y分量在名义上的数值范围是16(纯黑)到235(全白)。色度分量Cb和Cr的数值范围是16~240，数值128相当于没有颜色。有时候，由于噪声或者舍入误差的影响，有的值落在了名义范围之外，但是却永远不会超过0~255的范围。
ITU-R BT.656：
BT.601描述的是如何对视频信号进行数字化编码，而BT.601所必须的物理接口和数据流。该标准定义了并行和串行两种模式。并行模式仅仅需要一个27MHz的时钟信号(NTSC 30帧/秒)和8或者10根数据线(根据像素的分辨率调整)。所有的同步信号都内嵌在数据流中，因而不需要额外的硬件连线。下图是使用嵌入式帧同步信号时的常用时序关系，包括BT:656 4:2:2YcbCr格式，以及”BT.656风格”的4:4:4YcbCr和RGB格式。
常用数字视频格式
串行模式下，只需要在单个通道上有一个多路复用的每像素10比特的串行数据流，但是这中间涉及一些复杂的技术，例如同步，频谱定形和时钟恢复等。而且，码流时钟频率接近300MHz，所以在许多系统中，实现串行BT.656是一个挑战。
ITU-R BT.656帧分割
ITU-R BT.656数据流
在BT.656标准中，水平同步(H)、垂直同步(V)和场同步(F)信号作为食品数据流中的一部分发送，这些数据构成了一个控制字。活动视频起始(SAV)信号和活动视频结束(EAV)信号表示每一行需要读入的数据的开始点和结束点。SAV是指H信号由1变为0，EAV是指H信号由0变为1。视频的一个整场由活动视频、水平消隐(EAV和SAV码子之间的间隔)和垂直消隐(V=1的间隔)组成。
一个视频的场从F比特的变化开始。”奇数场”由F=0表示，而F=1则表示”偶数场”。逐行扫描的视频中，场1和场2 之间没有任何区别，但是在隔行扫描视频中，则要求专门对每一个场进行独立的处理，因为每个场中交替的扫描行组合起来构成了实际的视频图像帧。
SAV/EAV前导信息码
上图列出了关于SAV和EAV码字的具体细节。要注意的是，在前面由一个预定义的长度为3个字节的前导信息(对于8比特视频为0xFF、0x00、0x00,对于10 比特视频为0x3FF、0x000、0x000)，后面紧跟着的是控制字节，依次为F(场)、V(处置消隐)和H(水平消隐)位，然后为4个保留位吧，用于单比特的错误检测和纠正。注意，F和V仅仅允许在EAV序列(也就是说H从0变为1)中改变。另外还要注意，对于10比特的视频，额外的两个比特加在了最低有效位，而不是加在最高有效位。
各个比特的定义如下：
-
-
F=0表示场1
-
F=1表示场2
-
V=1表示垂直消隐区
-
V=0表示不在垂直消隐区
-
H=0表示SAV
-
H=1表示EAV
-
P3=V XOR H
-
P2=F XOR H
-
P1=F XOR V
-
P0=F XOR V XORH
-
垂直消隐的间隔内(即V=1的时间段)，可以用来发送一些非视频的信息，例如音频、图文电视、闭路字幕，甚至是互动电视应用中的数据。BT.656使用辅助数据包实现了这种功能。和正常的控制字节前面的前导信息”0xFF、0x00、0x00”不同的是，辅助数据包的前导信息为”0x00、0xFF、0xFF”。
假定不发送辅助数据，水平消隐和垂直消隐期间，(Cb、Y、Cr、Y、Cb、Y、···)数据流是(0x80、0x10、0x80、0x10、0x80、0x10、···)。另外，由于数值0x00和0xFF专门留作控制前导字之用，它们不允许作为活动视频流中的一部分。在10 比特的系统中，数值0x00到0x003和0x3FC到0x3FF页保留值，以免引起8比特实现时同样的问题。
从系统角度看视频：
上图是一个常见的端到端嵌入式数字视频系统。在这种情况下，视频源输入到媒体处理器中(如果必要的话，首先要有视频解码器进行数字化处理)。视频数据在存储到本地或者发送到网络之前还需要用软件编码器进行压缩处理。
与此过程相反，我们可以从网络或者大容量存储器中得到压缩码流。然后通过软件解码器解压缩后，直接发送到数字输出显示设备上(例如TFT-LCD屏)进行显示，或者通过视频编码器转化为模拟信号，从而可以在传统的CRT显示器上进行显示。
视频压缩编码标准发展趋势
请牢牢记住，压缩和解压缩仅仅是媒体处理器上可实现的所有可能视频处理算法中的一部分而已。
由于篇幅，嵌入式视频基础这期内容先分享到这里，下期更精彩。
版权所有权归卿萃科技，转载请注明出处
作者：卿萃科技ALIFPGA
原文地址：卿萃科技FPGA极客空间 微信公众号
扫描二维码关注卿萃科技FPGA极客空间