视频压缩初探

最新推荐文章于 2021-11-07 12:13:15 发布

weixin_30345055

最新推荐文章于 2021-11-07 12:13:15 发布

阅读量65

点赞数

原文链接：http://www.cnblogs.com/hbg200/p/8931224.html

版权

最近研究这一部分，试图配合自创的压缩方式，形成自有的视频格式，试验总结如下。（以前没接触过这一块，都是在网上临时学习的，边学边试验，得出初步的结果）

1. 当前大部分视频经过DCT（离散余弦变换）处理后压缩，视频处理过程（编码过程）如下：

视频帧 -> 分解切割为8x8小块YUV数组 -> YUV-128偏移（+127_-128之间） -> DCT处理 -> 量化 -> 压缩 -> 压缩帧打包（存储）。视频解压是反过来的，（解码过程）如下：

视频帧 <- 将8x8小块YUV数组合成为图像 <-YUV+128偏移（0_255之间） <- 反DCT <- 反量化 <- 解压 <- 解压缩帧包。

2. DCT理论是无损的，得到的是浮点数，再用浮点反向DCT变换，回复原数（是浮点都会有损失，取决于浮点精度）。因压缩需要整形数，所以转成整形数，这一过程称“量化”，造成一定损失，如果DCT后将浮点数“放大”（乘以某数，提高精度），恢复质量有所提高，但压缩率下降。一般称这一数为量化质量，为10时，压缩率为20%，图像质量尚可，不“放大”，显示效果极差，无法接受。

3. DCT输入范围：测试过字节和字输入，特性一样。有符号数和无符号数特性基本一样。

4. 传统视频（几乎当前所有视频）需要转成YUV色差方式再DCT变换压缩，是因为以下三个原因：

（1）最早期是黑白电视机，也就是黑白灰度信号，当彩色电视机出现后，为了兼容黑白电视机，选择了色差信号，其中Y是三个基色合成的信号，可以针对彩色和黑白电视机。

（2）压缩需要，由于对颜色细节不敏感，单独减少颜色细节，具有一定压缩作用。

（3）因最早是由黑白电视机、摄像机、录像机、演播传播系统等发展而来，选择的是兼容方式，当今虽然有RGB摄像及录像原始信号，但未压缩，无法正常使用，所以需要转色差方式压缩。

5. 作为一款自研多媒体软件，视频是不可少的，现有视频播放器都是调用别人的视频播放库，没有任何自主权，虽然有免费的库，但考虑到完全自控，简洁，还是要走创新的路，思路如下：

（1）视频分解成色差方式，其一是为了“兼容”传统黑白系统，作为独立软件不需要考虑“兼容”，采用自有格式，自己的播放器。

（2）视频压缩不同于传统压缩，要求速度，还要兼顾压缩率，看了当今几乎所以的压缩原理，通过融合自我想法，尝试新压缩方法。

（3）转换成色差，压缩颜色，充分利用视觉特点也是很好的方案，相对基于RGB的压缩方式，是否有优势，还需更多的思考。目前可以确定 YUV4:2:0 效果不好，YUV4:1:1 有改善，但很少用，YUV4:2:2 效果和压缩均衡，相对较好。YUV的不足是需要分离视频，需要运算，耗用一定时间，另一个问题是三个基色相互依赖，对还原色纯度不利。

（4）如果分别压缩RGB三个基色变量，因相互无牵连，当压缩率不同时，可能造成色彩混乱。所以RGB作为一个变量压缩，使用最多的RGB888也就是RGB24原始彩色格式，作为一个24位无符号变量，但没有相关量化表，出现困局。

（5）自己造量化表有点悬了，量化表是根据心里因素，对去除图像中的高频分量（也就是清晰度），做了权衡，是相关专家组经过大量实践得出的，经试验，确实如此。

（6）转了一圈，还是回到了色差方式，不是为了兼容，而是为了压缩色彩，利用现有资源，先做到自主，完全掌握，迈出第一步。

（7）因历史原因，色域空间转换有三种算法，YIQ，YUV， YCrCb。YIQ针对NTSC彩色电视制式，YUV针对PAL和SECAM彩色电视制式（当今视频大多数格式），YCrCb针对计算机用的显示器（大多数JPEG图片）。YIQ，YUV在计算机用的显示器上显示需要“扩展”，YCrCb在电视机上需要“压缩”才能正常显示。

6. 相关参考：

//RGB->YCbCr转换
#define CalcY(R, G, B) (0.299 * R + 0.587 * G + 0.114 * B) // 0 - 255
#define CalcCb(R, G, B) (-0.1687 * R - 0.3313 * G + 0.5 * B + 128)// 0.5 - 255.5
#define CalcCr(R, G, B) (0.5 * R - 0.4187 * G - 0.0813 * B + 128) // 0.5 - 255.5
//YCrCb->RGB转换
#define CalcR(Y, Cb, Cr) (Y + 1.402 * (Cr - 128)) //
#define CalcG(Y, Cb, Cr) (Y - 0.34414 * (Cb - 128) - 0.71414 * (Cr - 128))//
#define CalcB(Y, Cb, Cr) (Y + 1.772 * (Cb - 128))//

const BYTE bzYQTable[8][8] = { //亮度Y量化表
{16,11,10,16,24,40,51,61},
{12,12,14,19,26,58,60,55},
{14,13,16,24,40,57,69,56},
{14,17,22,29,51,87,80,62},
{18,22,37,56,68,109,103,77},
{24,35,55,64,81,104,113,92},
{49,64,78,87,103,121,120,101},
{72,92,95,98,112,100,103,99}};

const BYTE bzUVQTable[8][8] = { //色度UV量化表
{17,18,24,47,99,99,99,99},
{18,21,26,66,99,99,99,99},
{24,26,56,99,99,99,99,99},
{47,66,99,99,99,99,99,99},
{99,99,99,99,99,99,99,99},
{99,99,99,99,99,99,99,99},
{99,99,99,99,99,99,99,99},
{99,99,99,99,99,99,99,99}};

void __fastcall CDCT::FDCT(float fOutPut[][8], char czInPut[][8])//正向离散余玄变换
{
   float ALPHA, BETA, tmp; int u,v,i,j;

   for(u = 0; u < 8; u++)
      {
        for(v = 0; v < 8; v++)
           {
             if(u == 0)
                ALPHA = sqrt(1.0 / 8.0);
                else
                ALPHA = sqrt(2.0 / 8.0);

             if(v == 0)
                BETA = sqrt(1.0 / 8.0);
                else
                BETA = sqrt(2.0 / 8.0);

             tmp = 0.0;
             for(i = 0; i < 8; i++)
             for(j = 0; j < 8; j++)
                {
                   tmp += czInPut[i][j] * cos((2 * i + 1) * u * PI / (2 * 8)) * cos((2 * j + 1) * v * PI / (2 * 8));
                }
             fOutPut[u][v] = ALPHA * BETA * tmp;
           }
      }
}

void __fastcall CDCT::FQuantizier(int czOutPut[][8], float InMatrix[][8], const BYTE bzQTable[][8])//量化
{
   int x,y; float fQuant;

   for(x = 0; x < 8; x++)
   for(y = 0; y < 8; y++)
      {
         fQuant = InMatrix[x][y] / bzQTable[x][y];//量化
         fQuant = fQuant * byQuantizationQuality;//量化质量
         czOutPut[x][y] = (int)fQuant;//截尾
      }
}

7. 通过学习，读取JPEG文件有关信息，JPEG文件自带有亮度和色度量化表，下载了些jpg文件，读取量化表，发现大致归属以下三种：

//高质量量化表

BYTE bzHHYQ[8][8] = 
{
 {3, 2, 2, 3, 2, 2, 3, 3},
 {3, 3, 4, 3, 3, 4, 5, 8},
 {5, 5, 4, 4, 5, 10, 7, 7},
 {6, 8, 12, 10, 12, 12, 11, 10},
 {11, 11, 13, 14, 18, 16, 13, 14},
 {17, 14, 11, 11, 16, 22, 16, 17},
 {19, 20, 21, 21, 21, 12, 15, 23},
 {24, 22, 20, 24, 18, 20, 21, 20}
};

BYTE bzHHCQ[8][8] =
{
 {3, 4, 4, 5, 4, 5, 9, 5},
 {5, 9, 20, 13, 11, 13, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20},
 {20, 20, 20, 20, 20, 20, 20, 20}
};

//中质量量化表

BYTE bzHLYQ[8][8] = 
{
 {5, 3, 4, 4, 4, 3, 5, 4},
 {4, 4, 5, 5, 5, 6, 7, 12},
 {8, 7, 7, 7, 7, 15, 11, 11},
 {9, 12, 17, 15, 18, 18, 17, 15},
 {17, 17, 19, 22, 28, 23, 19, 20},
 {26, 21, 17, 17, 24, 33, 24, 26},
 {29, 29, 31, 31, 31, 19, 23, 34},
 {36, 34, 30, 36, 28, 30, 31, 30}
};

BYTE bzHLCQ[8][8] =
{
 {5, 5, 5, 7, 6, 7, 14, 8},
 {8, 14, 30, 20, 17, 20, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30},
 {30, 30, 30, 30, 30, 30, 30, 30}
};

//低质量量化表

BYTE bzLLYQ[8][8] = 
{
 {8, 6, 6, 7, 6, 5, 8, 7},
 {7, 7, 9, 9, 8, 10, 12, 20},
 {13, 12, 11, 11, 12, 25, 18, 19},
 {15, 20, 29, 26, 31, 30, 29, 26},
 {28, 28, 32, 36, 46, 39, 32, 34},
 {44, 35, 28, 28, 40, 55, 41, 44},
 {48, 49, 52, 52, 52, 31, 39, 57},
 {61, 56, 50, 60, 46, 51, 52, 50}
};

BYTE bzLLCQ[8][8] =
{
 {9, 9, 9, 12, 11, 12, 24, 13},
 {13, 24, 50, 33, 28, 33, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50},
 {50, 50, 50, 50, 50, 50, 50, 50}
};

通过测试，量化质量越高，压缩率越低，高质量为7倍压缩，中质量为11倍压缩，低质量为16倍压缩，大致测试，后续取消量化质量系数，通过选择量化表，确定量化质量，和压缩率，文件自带一套相关量化表。其中xxYQ为亮度量化表，xxCQ为色度量化表。

8. YIQ色域空间有别于其他两种，具有计算简单，不采用色差方式，色彩串扰小，所以选择YIQ。

9. 又下了些jpg图片，发现量化值不属于以上三种，jpg携带任意量化值。自有文件是否自带，需要思考。

10. DCT输入为什么限制在+127和-128之间，网上几乎没说清的，经实际编制发现，色彩分离后，Y为0-255，其他两个值出现负向，为了统一，Y负向偏移128。不统一，不好统一处理。

11. 在检查色域范围时，发现YIQ和YUV超出0-255范围，是针对模拟电视信号的。所以回归到 YCrCb色域空间。

总结：

1. Z扫描与顺序扫描相比，Z扫描压缩率低，原因是打破了排列顺序，也就是相邻相同的数据被破坏，造成压缩率低，Z扫描的目的是从大到小排列，但顺序扫描同样有规律，所以选择顺序扫描。

2. DCT后量化，量化表竟然不如直接使用一个数值效果好，试验各种量化表，没有一固定数还原好，同时还能兼顾压缩率，究其原因，是因为DCT自身规律。

3. DCT、量化、已试验完成，与之配套的压缩也即将完成，虽然耗去1年时间，但还是值得的。不同于常规如下：

（1）输入DCT为BYTE型，不转换至+127-128，没有影响，统一采用BYTE型。

（2）采用单一量化数，不采用量化表，各参数不差于使用量化表。

（3）不采用Z形扫描，连续数值增多，有利于提高压缩率。

（4）采用自研压缩方法，充分利用DCT量化后数据特点，提高了压缩率和压缩速度。避免霍夫曼压缩占用速度，针对性可变长压缩。后续将改进不使用字典库。　

试验结果：

为了简单，先对图片试验，网上素材大部分是jpg格式的，所以转为bmp格式，读取bmp图像数据，加工成自有的图片格式，采用YUV444采样，图像误差最大为2个数值，压缩量比bmp图片小一倍，比jpg图片大6.8倍。目前无能力拍摄原始图片格式，无法进一步验证。后续准备推出采用这一想法的专用图片浏览器，主要为验证。当文件名选用.img时，发现系统作为镜像光盘处理，所以使用.imge做后缀，系统不认识，这就对了。另外发现编解码速度很慢，别家的浏览器瞬间打开，我家的一分钟才能打开，不是原理性问题，需要优化。

转载于:https://www.cnblogs.com/hbg200/p/8931224.html

weixin_30345055

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
视频压缩初探

最近研究这一部分，试图配合自创的压缩方式，形成自有的视频格式，试验总结如下。（以前没接触过这一块，都是在网上临时学习的，边学边试验，得出初步的结果）1. 当前大部分视频经过DCT（离散余弦变换）处理后压缩，视频处理过程（编码过程）如下：视频帧 ->分解切割为8x8小块YUV数组 -> YUV-128偏移（+127_-128之间） -> DCT处理 -> ...
复制链接

扫一扫