莱娜图，很出名的一张图。

  在踏入服务器行业之前，接触过一段时间视频编码，所以一直对图像处理感兴趣。研究BMC的时候，多少还派上用场了。正好有人咨询，就说说自己了解到的。

  大家都知道BMC芯片具有KVM over IP（Keyboard-Video-Mouse over IP）功能，其中要把服务器界面显示的图像传递到远端客户端电脑上，实现客户端的实时查看。这是要通过IP网络传输，BMC有个百兆NCSI和千兆专用网口，受网络带宽影响，无法传输大量视频数据，所以要对所传输的视频图像进行压缩。当前主流产品是在BMC中使用JEPG压缩方式，我也考虑能否用H.264/265等方式呢

标准的JPEG如下：

  图像一帧以原始YUV送进来，切成8x8的小块，然后依次进行浮点数的DCT变换，量化，霍夫曼编码过程，得到压缩后的JPEG图像。可以看到，JPEG压缩过程自始至终都是一条直直的通路，没有环路。

H.264编码如下：

  直观感觉，H.264压缩过程有了环路，多了帧内预测模块可以预估当前块的像素值，相比于JPEG直接用原始值，H.264的残差值通常小的多。另外，H.264的DCT是整数DCT变换，相比于JPEG浮点数DCT取整过程，相对来说不会出现解码不太一致的情况。熵编码那里，H.264是CAVLC和CABAC+，压缩性能会更高。

一般来说，JPEG的压缩比为1：20，H.264能到1：50甚至1：100。这么看H.264是比JPEG性能好很多的。JPEG编码是针对单帧进行编码，H.264是针对多帧视频参考前后帧图片进行编码。那BMC是不是可以用H.264编码呢？

   先来看看应用场景，我认为服务器与私人用户使用电脑不同，用服务器来播放视频的时候比较少，多使用命令行方式操作，这种情况不追求高画质界面，对分辨率的要求不高，BMC的老大Aspeed芯片这么多年来一直最高为1920x1080。

   找了JPEG的代码和H.264代码进行了仿真。JPEG的代码相对来说好找一些，H.264就找到一个开源的。从仿真结果可以看出，在连贯性差的图片上，多帧图片之前相关性很小，视频编码H.264是参考前后帧进行编码，没有优势，编码输出的结果不如JPEG编码结果。一个1920x1080的视频流，JPEG的编码输出在100KB和300KB之前变化，而H.264的个别I/P帧最高输出到800多KB。而在连贯性强的图片，视频编码H.264就体现出优势，其压缩后输出的数据远远小于JPEG编码后结果，JPEG输出还是200KB，但H.264的个别B帧能到几KB。而服务器中那种命令行的方式算是连贯性差的图片。

   在仿真过程中还发现一点。就是JPEG因为没有帧间压缩，不需要大量存储，存储带宽要求少，可以不用考虑外挂DDR。而H.264需要因为有前后帧的对比，有大数据存储的需求，需要外挂DDR使用。对市面上的JPEG和H.264做了调研，JPEG的存储带宽大概为60MB/s，H.264要1.6GB/s，不保证数据的准确性，但H.264要更大的带宽是必须的。

   而对带宽的影响呢？1080情况下，JPEG大概是30Mb的带宽，H.264按照是其五分之一的情况来考虑，H.264能到5Mb的带宽。不过这个优势相对于百、千兆网络来说影响不大。当然如果上到4K（2160P）、‌8K（4320P）的分辨率，那优势就很明显了。

   还有一个二者对比的因素，就是成本。JPEG是比较老的编码标准了，而H.264还是比较先进的编码标准。如果去采购相关IP，二者的成本不得不在考虑之中。毕竟一颗芯片利润不到100人民币，需要多少颗才能覆盖这成本呢。

   JPEG毕竟是图片压缩，而H.264是视频压缩，H.264肯定是性能优异，但具体使用哪个，需要根据应用场景做个综合考虑。不过，是否可以考虑在JPEG里面借鉴H.264的一些算法做些优化呢？Aspeed有些专利感觉好像参考了帧间编码的思想。