【图像处理】H.264开源解码器评测

转自：http://wmnmtm.blog.163.com/blog/static/38245714201142883032575/

要播放HDTV，就首先要正确地解开封装，然后进行视频音频解码。所以我们需要分离器，视频解码器和音频解码器，俗称hdtv的“三件套”，又统称滤镜。

H264的分离器:

常见的有Gabest MP4分离器，就是MP4splitter，也是Gabest编写的，Halli的分离器和NDigital分离器等。

H264的视频解码器：

CoreAVC的H264视频解码器CoreAVC DirectShow Video Decoder。

月光的H264解码器，全称为Moonlight H264 Video Decoder，ffdshow的解码器，全称为ffdshow
MPEG-4 Video Decoder，能打开N卡显卡硬件加速的CyberLink H.264/AVC Decoder(PDVD7)。

音频解码器：

ffdsshow，月光音频解码器、WinDVD的音频解码器、PowerDVD的音频解码器、AC3Filter音频解码器。

如果播放HDTV时碰到有声无画或者有画无声，就应该自己从解码器着手，替换一个试试。

缘起：HDTV的减肥药

其实HDTV个头大的根本原因，并非是分辨率太高，而是采用的MPEG2视频压缩算法力道不够，换成MPEG4就好得多，基本上可压缩到几G，但目前MPEG4编码群雄并起，编解码方案很不统一，有时拿着一部好片折腾半天却放不出来，再好的脾气也不免搓火。

现阶段比较好的选择是H.264/AVC。它是由ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（运动图像专家组）共同开发的视频处理标准，ITU-T称为H.264，而ISO/IEC称为AVC（高级视频编码），并将其作为MPEG-4 Part 10。可以说，H.264代表了当前业界最先进的视频压缩技术，具有压缩比高、码率低、图像质量好、容错能力强、网络适应性广等优点，在数字影像、网络电话、多媒体、IPTV、通讯等领域得到越来越广泛的应用。用H.264来处理HDTV，不仅能保留较高的视频质量，而且可以将HDTV瘦身到令人惊讶的程度，实在是对了HDTV肥胖症的减肥药。

实战：自己动手编码H.264影片

现在H.264的编码器已经很多，MainConcept H.264 Encoder和X264都很不错。下面以MainConcept
H.264 Encoder为例，介绍如何将Mpeg-HDTV转换为H.264-HDTV。

启动MainConcept H.264 Encoder，在Video编辑框中输入待转换视频文件名，或点击旁边的Open按钮选择。MainConcept H.264 Encoder能识别绝大多数视频格式，包括HDTV常使用的TS和M2V、MPG、AVI、WMV格式。由于许多HDTV节目视频和音频是分离的，因此 MainConcept H.264 Encoder单独设置了Audio编辑框，可在其中输入HDTV音频文件，或用旁边的Open按钮选择。如果音视频是合成在一起的，那么选择视频文件后，Audio编辑框自动出现该视频文件，勿需再选择音频文件了。Output编辑框设置目标文件名，一般为MPG文件。

下面Output format栏设置目标文件的格式。设置好后，点击主界面下的Convert按钮，即可开始转换。由于H.264编码需要大量计算，颇为耗时，所以用户得有比较好的耐心。编码完成后，大家可以拿目标文件同源文件对比一下，不难发现用H.264编码的HDTV文件大小只有MPEG2编码的三分之一左右。

小贴士：输出文件格式的具体设置

ＭＰＥＧ项： 和Ｈ．２６４相关的有三项：Ｈ．２６４ Ｂａｓｅｌｉｎｅ、Ｈ．２６４ Ｍａｉｎ和Ｈ．２６４Ｈｉｇｈ，其编码的画面质量从低到高，通常选择Ｈ．２６４ Ｍａｉｎ就可以了。

Ｖｉｄｅｏ项：设置制式ＮＴＳＣ或ＰＡＬ，最好选择与源文件一致的制式，以保证转换效果并减少转换时间。

Ｓｔｒｅａｍ项：设置流格式，主要有三种：Ｅｌｅｍｅｎｔａｒｙ、Ｐｒｏｇｒａｍ和Ｔｒａｎｓｐｏｒｔ，ＨＤＴＶ通常使用最后一种格式，因此选择Ｔｒａｎｓｐｏｒｔ（Ｖｉｄｅｏ＋Ａｕｄｉｏ）项较为合适。

Ａｕｄｉｏ项：设置音频格式，使用Ｌａｙｅｒ２和ＡＡＣ均可。点击Ｄｅｔａｉｌｓ按钮弹出辅助设置对话框，在此设置码率（Ｂｉｔｒａｔｅ）以及音频格式等，还可以利用Ｍｕｘｅｒ栏的选项分割ＨＤＴＶ文件。点击Ｖｉｄｅｏ栏中的Ａｄｖａｎｃｅｄ按钮，可更详细地设置视频参数。不建议普通用户修改。

回放：帮暴风影音搞定H.264

H.264的解码器现在太多了，不过Moonlight H.264 Video Decoder格外好一些。这款HDTV解码器的品质得到了广泛的认可，几乎成了HDTV的标准解码器。下面讲讲怎么把它和常用的暴风影音结合起来。

安装Moonlight H.264 Video Decoder，完成后启动暴风影音，选择“查看→选项”菜单，弹出选项对话框。点击“滤镜”项下的“管理”子项，再在右边的“管理”页中点击“添加滤镜”按钮。

弹出选择滤镜对话框，点击“浏览”按钮，到C:\Program Files\Common Files\Moonlight文件夹中找到h264dec.ax滤镜，将其加入，这样Moonlight H.264 Video Decoder解码器就添加到暴风影音中。最后别忘了在“管理”页中将Moonlight H.264 Video Decoder设为“首选”。

支招：回放吃力的问题

试着播放刚才压缩的ＨＤＴＶ，暴风影音已能正常解码，画面也很精致，与源文件相比，画质损失很小，可就是太卡了！Ｈ．２６４非常考验ＣＰＵ的运算能力。本来ＭＰＥＧ２格式的解码，就让许多ＣＰＵ败下阵来，若无支持ＨＤＴＶ硬解压的显卡帮忙，非得有顶级的配置才能使播放较为流畅。而Ｈ．２６４的算法比ＭＰＥＧ２更复杂，如果纯软件解码，即使是目前顶级的配置，解码高分辨率Ｈ．２６４－ＨＤＴＶ也比较吃力。

还好，ＡＴＩ和Ｎｖｉｄｉａ都有支持Ｈ．２６４硬解码的ＧＰＵ推出。ＡＴＩ的Ｒ５２０即使在较低配置下，也可以流畅地解码Ｈ．２６４－ＨＤＴＶ，只是价位不那么平易近人。而Ｎｖｉｄｉａ方面，因为Ｇｅｆｏｒｃｅ６／７系列ＧＰＵ都内建ＰｕｒｅＶｉｄｅｏ视频引擎，只需升级ＰｕｒｅＶｉｄｅｏ，即可使Ｇｅｆｏｒｃｅ６／７系列支持Ｈ．２６４解码，这一点比较实惠。至于解码效率，虽不及采用纯硬件解码模式，但比纯软件解码还是强些。Ｎｖｉｄｉａ称，在Ｆｏｒｃｅｗａｒｅ８５的支持下，６６００ＧＴ之后ＮｖｉｄｉａＧＰＵ产品都可以全速解码１０８０ｐ高清晰Ｈ．２６４视频。ＣＥＳ２００６上曾有人用Ｇｅｆｏｒｃｅ７８００演示Ｈ．２６４解码，效果还不错。

H.264标准的由来

１９９８年，视频编码专家组（ＩＴＵ－ＴＶＣＥＧ）启动了Ｈ．２６Ｌ工程，旨在研制新的视频编码压缩标准，要做到尽可能地简单直观，同时网络适应性要足够好，以适合广播、存储、流煤体等交互或非交互式应用。

２００１年１２月，ＶＣＥＧ和运动图像专家组（ＩＳＯ／ＩＥＣＭＰＥＧ）组成联合视频组（ＪＶＴ），在Ｈ．２６Ｌ基础上研制出Ｈ．２６４／ＡＶＣ编码标准，于２００３年３月正式获得ＩＳＯ／ＩＥＣ批准。

在网络时代，视频往往要借助网络进行传播，这就要求一个好的视频方案能适应各种网络应用及网络类型。Ｈ．２６４／ＡＶＣ无疑做到了这点。它包含两个层次：视频编码层（ＶＣＬ）和网络抽象层（ＮＡＬ），前者主要致力于有效地表示视频内容，后者则规范视频数据的格式，主要是提供头部信息，以适合各种媒体的传输和存储。

Ｈ．２６４／ＡＶＣ的高压缩率及其优良的网络特性，使它可能在网络电话、视频点播、ＩＰＴＶ、视频会议、视频聊天、远程教学、广播电视、ＨＤＴＶ、流媒体服务、３ＧＰＰ多媒体信息服务、视频邮件等方面得到广泛的应用。

 

转自：http://blog.csdn.net/sunshine1314/article/details/712401

H.264开源解码器评测

Peter Lee 2006.05.07 videosky.9126.com

2003年5月，当H.264编码标准草案发布时，很多人都觉得H.264太复杂，不宜实用。眨眼间3年过去了，以往的论断、疑惑被如今的现实冲洗的干干净净。随着硬件性能的提高和视频编码工作者对H.264的不断优化，如今的H.264已完全实用，最新的达芬奇芯片上能实现D1分辨率(720*480)视频的实时编码，而对于解码，普通的PC机就能实现x264编码的DVDrip电影的流畅播放。纵观过去的三年，有多少人对H.264倾注了热情和汗水才换来今天的成绩，而那些H.264的开源项目以及参与这些项目的开发者自然是功不可没。

本文评测的是作者接触过的H.264开源解码器，包括：JM
decoder, T264 decoder, x264 decoder, ffmpeg libavcodec, Intel IPP simple player。评测的内容有：对H.264特性的支持、解码速度以及二次开发难易程度。

一、H.264开源解码器介绍

1、JM
decoder

JM decoder是H.264的官方源码，通常也称为校验模型。其特点是支持特性好，实用性差。本文选用的程序是JM86，不支持high
profile，因为本文不对high profile部分进行实验比较。

NOTE: JM一直没有做实用化方面的努力，所以其解码速度代表的是2003年的水平。

2、T264
decoder

T264是国内的开源项目，T264
decoder的程序做过汇编优化，速度还可以，但只能解T264本身的码流。作者对T264 decoder version 0.14（2005-3-29）作了修改，支持baseline的解码。

3、x264
decoder

x264本没有decoder，但其包含decoder的部分函数雏形，猜想作者在一开始时是准备实现decoder，后来可能是因为有了ffmpeg，就放弃了这个想法（纯粹属于猜测，呵呵）。

本文的x264 decoder是作者在x264
svn check out 2005.12.26的基础上实现的，支持baseline的解码。

4、ffmpeg
libavcodec

ffmpeg是一个大项目，它包含各种音视频标准的codec，还支持各类file
format（.avi, .mp4, .mkv and etc）的parsing。所以，很多开源项目都有直接或间接地采用了ffmpeg，如mplayer播放器就是直接采用了ffmpeg，而mpc播放器则是先采用了ffdshow
filter，而ffdshow又采用了ffmpeg。ffmpeg是一个非常棒的音视频编解码库，支持的标准非常全，而且编解码速度也很快。

本文实验采用的是cvs check out 2006.02.20的版本，作者对其中的apiexample
demo进行了简单的修改，用于解码h.264码流

5、Intel
IPP simple player

Intel的IPP库，全称为Integrated
Performance Primitives，在Intel的各种处理器平台（IA-32, Itanium, xscale and etc）上实现了信号处理常用算法、常用数学运算及音视频编解码算法等等。IPP给我的第一感觉是，在Intel的处理器平台上，它实现的各种算法应该是最快的，至于实际结果如何，待等到实验比较后见分晓。

本文采用的IPP库版本为IA32
5.1.017 评估版

Intel IPP simple player是用于播放各种音视频文件的简单播放器，用c++实用，具体算法调用IPP库来实现。本文采用的simple
player版本是5.0.017

二、对于H.264特性的支持

1、JM86
decoder

support baseline, extended, main profile

2、T264
decoder

baseline

3、x264
decodeer

baseline

4、ffmpeg
libavcodec

support baseline, main profile, high profile except the feature: paff, mbaff…

5、Intel
IPP simple player

support baseline and main profile

【简单结论】

解码速度：ffmpeg > IPP simple player
> x264 decoder > t264 decoder > jm86 decoder

以ffmpeg的编码速度为基准，假设为100fps，则：

IPP simple player：90fps

x264 decoder：50fps

t264 decoder：30fps

jm86 decoder：3fps

五、程序开发上的比较

我估计阅读本文的大部分读者都是搞开发的，因此，阅读过程中自然会思考如何在程序开发上借鉴或者采用以上开源的H.264解码器，下面就针对程序开发上的难易、适用场合等作个比较。

1、JM86
decoder

适合写paper群体

2、T264
decoder

3、x264
decodeer

两者代码非常相似，所以就合在一起讲了。这两个源码的程序结构都比较清晰，支持vc和gcc的编译环境，但对H.264的特性支持不好，解码速度和ffmpeg相比，还有差距。

4、ffmpeg
libavcodec

程序结构比较差，H.264解码的代码基本上在h264.c一个文件中，这个文件有8000多行，不利于阅读。

编译环境为gcc或MinGW，移植到vc下比较难（我尝试过）。

解码速度快（BTW: 通过doom9论坛了解到，目前最快的h.264解码器是CoreAVC
decoder，比ffmpeg快50%左右）。

对于H.264特性的支持好。

5、Intel
IPP simple player

分两个方面讲：

（a）IPP库

我觉得是非常棒的，但实现的是H.264解码（IPP中也有H.264编码）的一些关键函数，如deblock，dct，插值补偿等，不能直接拿来用。

其它的缺点：IPP库是商业软件，要money的，而且只支持Intel平台

（b）simple
player

开源，用c++写的，而且是directshow编程，也就是说只支持windows平台。

其解码速度比ffmpeg慢10%左右，我觉得原因不在于IPP库，而是simple
player的代码不够完善。