我的专业跟视频流媒体略有关系，所以对视频压缩也略知一二。
下面就谈谈我对HAVC的个人看法，如有出入，请大家指正。[ ]
谈到AVC大家一定不陌生阿，自从有了PSP，我就对AVC开始感兴趣了（以前比较注意RMVB）
作为目前最先进的视频编码之一的AVC已被广泛应用，比如视频监控、HD-DVD、蓝光DVD等。
由此可见，AVC的画质已经得到了业界的公认。
那么如何压制高质量的AVC视频呢？
首先，你需要一个好的编码器。
目前，得到大家公认的高质量AVC编码器有：NERO RECODER 2 （非开源）和X264（开源） .
至于它们那个更优秀呢，2004年时，你问我，我会回答是NERO RECODER 2
2005年时，你问我，我会回答是X264
至于现在，我很难理性的回答。我个人更喜欢X264。
这里，我要说明一个问题。
可播放视频文件大体有三部分组成：视频流、音频流、容器。
AVC（高级视频编码）这个定名，大约是在H.264列入规范后的事情（隶属MPEG 4 Part 10）。
也就是说，它只规范了视频流的压缩标准。
AAC（高级音频编码）官方制定的音频流压缩标准（隶属MPEG 4 Part 2）。
mp4官方制定的标准容器。
由于这些标准不太严格，所以大家都在说的格式一词也就模糊了。
同样的AVI文件中可能由 视频流MPEG4 SP和MP3组成，也有可能是视频流h.264和音频流aac.
但大家都习惯叫做AVI格式的视频。这是不太规范的。所以，才有了PMP这种自制格式阿。
那么，PMP-AVC 和HAVC那个更优秀呢?
我没有用过PMP-AVC，所以说不好，但据说PMP-AVC不支持B祯，这可能导致PMP-AVC不如
HAVC的压缩率高，质量也有一定的影响。
还有关键的一点，HAVC仅支持的H.264 的主规格（Main Profile，向下兼容），而AVC/H.264定义了4种不同的Profile(类)：Baseline(基线类), Main(主要类), Extended(扩展类)和High Profile(高端类)（它们各自下分成许多个层）：
- Baseline Profile 提供I/P帧，仅支持progressive(逐行扫描)和CAVLC
- Extended Profile 提供I/P/B/SP/SI帧，仅支持progressive(逐行扫描)和CAVLC
- Main Profile 提供I/P/B帧，支持progressive(逐行扫描)和interlaced(隔行扫描)，提供CAVLC或CABAC
- High Profile （也就是FRExt）在Main Profile基础上新增：8x8 intra prediction(8x8 帧内预测), custom quant(自定义量化), lossless video coding(无损视频编码), 更多的yuv格式（4:4:4...）
至于Main Profile的相关编码工具，也就是在我们应用MEGUI & X264时可以使用的有：
CAVLC/CABAC：
AVC/H.264定义了2种先进的重构数据流（包括macroblock-type(宏块), motionvectors(运动矢量) + reference-index(参考索引)...）的熵编码工具，一举超越MPEG-4 ASP：
Context-Adaptive Variable Length Coding(CAVLC/上下文自适应变长编码)和 Context-Adaptive Binary Arithmetic Coding(CABAC/上下文自适应二进制算术编码)
CABAC，与AVC/H.264中只是默认算法的CAVLC（也叫UVLC）相比，是个压缩率更强大的算法，据说能额外降低10-15%的比特率（特别在高码率）。CABAC（同CAVLC一样）是一种无损算法，因此不会降低质量，但会减缓编码和解码速度。
Loop/Deblocking Filter(循环/去块滤波器)：
与预处理滤波器（例如通过avisynth作用于输入端），或后处理滤波器（通过解码器作用于最终输出端）相反，循环滤波器在编码过程中对每桢进行滤波，编码完成后被用于下一桢的参考。它能消除块效应，尤其在低码率时，但同样会减缓编码和解码速度。
Variable Block Sizes/Macroblock Partitions(块大小可变/宏块划分)：
与MPEG-4 ASP（仅Inter4V/4MV能作16x16和8x8块变换）相比，AVC/H.264把动态搜寻精度(Motion Search Precision)提高到4x4（包含的步骤有8x4...）。子块大小是自适应/可变的，一个优秀的编码器应能对每个宏块明智地作出最恰当的划分大小决定。
Multiple Reference Frames(多重参考桢)：
与MPEG-4 ASP（仅允许当前桢的前一桢作为参考桢）相比，AVC/H.264使用帧间搜索方式并提供成倍的参考桢选择，它意味着AVC/H.264编码能决定是否只是简单地参考前一桢或甚至参考比前桢更过去的桢。因此（例如某个P桢能参考最近I桢前的某桢）不得不提出一种新型桢型：IDR桢，是种其后的桢不允许参考其前的桢的I桢。使用多重参考桢会减慢编码和解码速度并且可能导致只能在IDR桢剪切。
Rate Distortion Optimisation(RDO/码率-失真/损耗最佳化)：
只要编码器不得不在众多选择中作出绝择时，RDO允许选择最有效的编码方式（例如面临采用桢间/桢内的动态搜寻的决定...）
RDO不是AVC/H.264本身定义的工具，它是第一个由H.264参考软件引入的工具，可谓一种新的途径。其他的编码也能利用RDO，如XviD'的VHQ模式能使用RDO
这是我编写的MEGUI的命令行（发挥了所有可用的工具，高画质）：
--pass 2 --bitrate 1024 --stats ".stats" --level 2.1 --ref 2 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --filter -3,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --vbv-maxrate 4000 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "" "" --colormatrix YCgCo --sar 1:1
这里还有说的就是，X264是编码器，而并非视频编码规范，所以说“x264格式的视频“是不正确的。
VDM的压缩方法本身有缺陷，它调用的X264VFW.DLL本身没有完全的x264的功能。
目前，我们能利用的X264.EXE（命令行）并非官方放出的，大都来自高手的编译。官方只提供
源代码。但质量上有保障的，大家不用担心，官方承认的Unofficial builds for Windows are available from Jarod or Sharktooth.
再说以下，在一用MEGUI时，我们可以不用分离出音频再进行编码！！
这是AVS模板：
DirectShowSource("<%InputFile%>",convertfps=true)
#changefps(29.97)
ConvertToYV12()
ResampleAudio(48000)
Sharpen(0.2)
LanczosResize(480,272)
其实我们没有必要改变源视频的FPS，PSP可以正常播放的。还有，AAC音频应当是LC级别的。
直接将AVS脚本添加到音频转换就可。
|
