【转载】【译文】寻找最适合动漫的视频编码

寻找最适合动漫的视频编码

作者：Dark Shikari（作者系x264主要开发者之一）
9 [3 t: f2 Y+ h5 L* G译者：ssnake
% T4 H( I/ C8 {2 M- `% L关键词：H.264、结构相似度（SSIM）、评测、码率控制、x264
原标题为Encoding animation（编码动漫），原文链接：http://x264dev.multimedia.cx/?p=102
而今各类编码器的横评早已烂大街了，但我却几乎从未看到过关于动画片源的测评。与（真人）电影相比，动画素材有着完全不一样的特性，对于视频编码来说是一次全新的挑战。
% L2 Y3 c' F6 D, I$ @首先，我们讨论一下为什么这些（动漫）视频容易压缩。动漫主要由静态画面组成：人物置于完全静态的背景上。而人物本身也几乎是静态的：现代动画往往有着一个远低于真实视频的帧速率（FPS）。此外，人物往往只是站在那里动动嘴巴，这又大大降低了复杂度。最后，动画往往非常干净，没有任何胶片颗粒。这一切，让动画压缩看上去是如此轻松。
但是，不要让上面这些理由欺骗了你——另一方面，动漫其实很难被压缩。首先，动漫中大量的码流被用于锐利的物体边缘。这些边缘信息频域转换后会产生大量的高频频谱系数，编码代价颇高。事实上，简而言之，不论是基于离散余弦转换方式（DCT-based）（如H.264、MPEG-4、MPEG-2、 Theora等等）还是基于小波变换（Wavelet-based）（如Dirac、Snow等等），现有的视频格式都完全不适于编码这些动漫固有的边缘信息。而据我所知，也没有人提出能明显改善的办法（编者按：其实编码就像地图测绘，不怕一座高耸的珠穆朗玛，就怕连绵不绝的小山小丘）。或许方向小波（Directional wavelet）可以达到目的。
0 d; D7 i  q& c除了变换的难题外，就编码器的角度来看也有着重重问题。在动画素材中，移动鲜见平滑：因为动漫往往以一个（相对于真实视频来说）非常低的帧速率制作，一个 物体可能在静躁之间游移，这让时间轴预测的动态搜寻难以为继。当这个物体突然向右跳了20个像素时，常规方法必然很难找到这个物体的去向。
5 \% `4 c7 P, V, f; D1 j( h. w还有视觉效果的问题：那些边缘是如此耗费码流，因而编码器会倾向于给画面其他部分（比如背景）很少的码流。这意味着我们反而经常需要设置很高的码率以防背景崩坏。
此外，动漫对于码率控制来说也是个麻烦事：对于动画片源，常规的预测方法往往无能为力；因为一帧时而耗费颇多，时而所需寥寥——尽管它们看上去可能是一样复杂。对于动画输入，即使是x264的VBV（视频缓存检验器）在一次编码（1-pass）模式下也难以给出一个良好结果；因此，也无怪许多编码器对于此类素材都束手无策。
如此总总，让动画编码好比“王母娘娘编笸箩”，看着容易做着难。
& V" E6 k* o. K7 n1 j/ x于是，让我们来看看这些编码器们的表现吧。由于几乎无法找到一段合适的免费动画资源，我从我手头唯一合适的动漫DVD——东方二次同人《梦想夏乡》——中选出5000帧进行测试。这是一个有着相对较少动作的非常干净的素材——典型的动画。
( X* u0 L# W- Z; q作为测试标准，我选择SSIM（结构相似度）作为度量衡——鉴于主观评价无异于一场噩梦，而且从不会得出有说服力的结论。我之所以选择SSIM而非 PSNR（信号-噪音功率比，简称信噪比），不仅仅因为SSIM是一个更加科学的度量衡，而且其结果更加适合动漫。如前所述，动漫中大多数码流被用于源自物体边缘的黑线，这些边缘的均方误差让其他失真相形见绌。如此，为了让信噪比最优（PSNR-optimal），就算背景一塌糊涂，也要克扣码率给线条，让线条好看哪怕只是一点点——这显然不能获得良好的视觉效果。尽管SSIM也不尽完美，但从视觉效果的角度说它显然是比较好的选择。我使用MSU Video Quality Tool来计算SSIM。
为比较方便，我使用了公式1/(1-SSIM)以得出一个可比较的数字：0.98的SSIM比0.96的SSIM好上一倍，0.96的SSIM又比0.92的SSIM好上一倍；因此0.98的SSIM比0.92的SSIM好上三倍。
注意，尽管这种比较描述一种编码器比另一种“好上三倍”，但这并不意味着后者需要比前者多三倍的码率来获得同样的质量。
此外，我尝试让各个编码器的输出文件大小统一——因为并不是所有编码器都输出大小精确的文件（尽管我已经做了许多次重编码来试图让它们尽量接近）。这是一个不讨论速度的测试，我使用了每个编码器可用的最慢的参数。我没有过多调整编码器的片源设置，ffmpeg的设置来自我所有的“质量最优的ffmpeg设置”文件，所以我并不知道是否有更优的设置。
. g3 J3 ?9 ]5 h, q' [0 `对于所有编码器，我使用250kbps的视频码率和（我所能设置的最接近于）250帧的最大关键帧间隔。少数不知名的编码器（比如Bink）不允许设置最大关键帧间隔。下面是我所用到的编码器、参数以及它们各自的视频格式。
x264 (r1206)
5 s! S6 l. `" w( \; p$ T; E  F9 G视频格式：H.264/AVC High Profile
参数：--preset placebo --tune ssim --rc-lookahead 250，二次编码
我测试了五种不同的编码设置以比较x264在快一些的模式下有多少质量损失，以及--tune ssim预设相比--tune psnr有多少SSIM提升。
x264 Baseline
视频格式：H.264/AVC Baseline Profile
参数：--preset placebo --tune ssim --rc-lookahead 250 --profile baseline，二次编码
x264 Ultrafast
; ^% J8 l( E1 T6 o% ~& g" D& t视频格式：H.264/AVC Baseline Profile
参数：--preset ultrafast --tune ssim，二次编码
x264 Veryfast
视频格式：H.264/AVC High Profile
参数：--preset veryfast --tune ssim，二次编码
# W7 V, N0 j0 {% n% ~9 I2 |- \x264 Medium
视频格式：H.264/AVC High Profile
参数：--preset medium --tune ssim，二次编码
; M: a$ T! R1 w2 ux264 PSNR
视频格式：H.264/AVC High Profile
参数：--preset placebo --tune psnr --rc-lookahead 250 --profile baseline，二次编码
, N% T- R1 J! Q8 f7 xWMV (Expression Encoder 3)
视频格式：VC-1 Advanced Profile
" B3 P8 ?1 }% q. [; e: a9 s5 ]9 S参数：“best”预设
7 U) l$ H8 `7 i8 u2 g8 N5 {Xvid (1.2.1)
视频格式：MPEG-4 Part 2 ASP
参数：全选，包括bframes、qpel、GMC
Thusnelda (August 7th ffmpeg2theora nightly)
视频格式：Theora
5 f2 @0 P( x6 J参数：二次编码（没有别的质量参数了）
/ S3 P. N. y) z/ G  DQuicktime (7.6.2)
9 \$ u8 I8 J9 M; l  ^1 Y$ F视频格式：H.264/AVC Main Profile
# E2 _# k1 n* c' L" u: j参数：二次编码（没有别的质量参数了）
5 n9 b+ o5 t/ @7 ~8 }  I+ iffmpeg mpeg2
: @4 T! h' x: E/ Z9 I3 a9 ^# Q! S视频格式：MPEG-2 video
参数：-flags qpel+mv0+cbp+aic -dia_size 1040 -g 250 -bf 8 -b_strategy 2 -cmp sad -subcmp rd -mbd 2 -precmp sad -last_pred 4 -subq 8 -bidir_refine 4 -trellis 1 -qns 3，二次编码.
ffmpeg mpeg4
视频格式：MPEG-4 Part 2 ASP
" [; u+ a, S1 {* @: C6 s" p- c参数：-flags mv4+qpel+mv0+cbp+aic -dia_size 1040 -g 250 -bf 8 -b_strategy 2 -cmp sad -subcmp rd -mbd 2 -precmp sad -last_pred 4 -subq 8 -bidir_refine 4 -trellis 1 -qns 3，二次编码.
ffmpeg flv1
视频格式：Sorenson Spark H.263 (FLV1)
参数：-flags +mv4+mv0+cbp+aic -dia_size 1040 -g 250 -cmp sad -subcmp rd -mbd 2 -precmp sad -last_pred 4 -subq 8 -trellis 1 -qns 3，二次编码.
" Z# r: y" Y( ^' P3 w' C( d. z5 gOn2 VP7
; O  p; }: c/ S% ?/ H视频格式：VP7
参数：二次编码以及“best”预设
& _( S# \  Y- b% \! R+ T, UAteme (1.11)
# l8 L4 _8 [, @! e4 g6 E2 P视频格式：H.264/AVC High Profile
参数：“Full” preset with “macroblock-level” psy optimizations.
9 b7 `* I. ^# Y! E2 f注意：这并不是它的最新版本2.0，因为我不知道有谁能弄到它。所以请权当这是个一般的H.264编码器，并非Ateme的最佳表现。
0 @6 M) G9 Q) @, a7 ~Real Producer (10)
视频格式：RV40 (similar to H.264/AVC Main without CABAC)
" }1 a& `  G2 g* j5 C1 z% r( h参数：“High”质量，二次编码.
# ?) L( ?, _, H% ?Bink Video
( ~9 M/ @, p. m. Q& D2 @2 P视频格式：Bink Video
参数：64-frame lookahead（没有别的质量参数了）
) N" U  }9 c, V7 v: gElecard Converter Studio (3.1)
, l1 x  U* {, A) R视频格式：H.264/AVC High Profile
参数：全部最高；我测试了complexity mask以期能改善SSIM，但结果并不理想，故而未用
Badaboom (1.2.1)
视频格式：H.264/AVC Main Profile
2 I5 {- u+ Q9 d$ s* `, }参数：它没什么设置，连二次编码都没有。
" ~+ Q' a  [+ c" `Indeo 5 (5.1)
2 @. O" V& z- y  e6 O视频格式：Indeo 5
参数：它没什么设置。
5 T1 ]$ i7 J' C0 }. Q6 lffmpeg Snow
0 h( O' H& A6 N# u! ?& n' n/ x视频格式：Snow
参数：(mencoder) vcodec=snow:vstrict=-2:vbitrate=250:pred=0:mbd=2:cmp=12:subcmp=12:mbcmp=12:qpel:vme=8:refs=8:keyint=250 （二次编码）
) O6 A9 p/ e# p4 w* x, l+ Vffmpeg SVQ1
视频格式：SVQ1（译者注：Sorenson Video 1，SVQ1意为Sorenson Vector Quantizer #1）
参数：-qscale 23.5 -g 250 -cmp satd -subcmp satd -mbcmp satd -mbd rd -dia 4 -last_pred 2
注意：这仅作为最佳预变换时代视频格式——矢量量化（Vector Quantization）编码器的范例。我使用ffmpeg是因为因为Apple版本很糟糕，而使用固定质量模式则是因为ffmpeg对于SVQ1不提供码率模式（我使用了牛顿法以在固定质量模式中求得一个匹配的码率）。
我本打算在测试中包括Dirac，但我找不到最大关键帧间隔的设置，而用它默认很低的最大关键帧间隔（40）与其他编码器比较是非常不公平的。
! \$ L" ~8 H/ ^/ L3 |: }: [下面是测试结果：
Link
图例：
( J" j, d1 o/ a/ q. s蓝色：x264
9 P! t( D* `5 C1 O& T: S# }7 X1 W1 x红色：非x264的H.264编码器
. l; L7 \9 X  ?2 K2 S0 u  n绿色：ffmpeg的编码器
8 X& ^4 s% Z5 k' k. v4 p$ {黄色：不属于以上各类的开源编码器
4 j* e$ S1 T7 P  d2 d' d( e紫色：不属于以上各类的私有编码器
! Q9 d/ Q6 g$ {( e) }
1 V* Z( W' c0 v2 F' j# j) _8 A& `有着太多的惊奇，且听我娓娓道来。

• x264 Baseline Profile超过了一切非x264编码器
  ' k+ z) ], M8 F2 j  F6 r% g我没有料到会是这样。哪怕相比High Profile有着55%的差距，但x264 Baseline相比Elecard依然稍占上风。
• 哪怕是使用优化PSNR的参数，x264依然把其他编码器打得屁滚尿流（beats the hell out of everything）
  ( v2 g% Y7 P, T. z我曾预计AQ是x264获胜的一个重大因素，因为这是一个SSIM测试——但现在我们并没使用AQ（译者注：--tune psnr预设（即优化PSNR的参数）是关闭AQ的）。
• ffmpeg的编码器惊人的出色
  用了超级无敌慢无下限的极限设置，ffmpeg表现得非常好：它的MPEG-4编码击败了WMV，它的MPEG-2则力克Theora。就连FLV1也几乎与Badaboom打成平手。
• 优劣H.264编码器之间相差达4倍之多
  + i) W4 I8 Z; Y) W+ g1 y当然，也有很多事情一点也不奇怪：比如Apple和Badaboom是极其糟糕的H.264解决方案。我们基本都知道这个了。
• WMV表现得糟透了
  # b! L8 P$ U2 G, Q* w因为不允许在区块内使用除了8×8之外的变换（译者注：WMV自身的限制），WMV在这个测试中被严重削弱了。但这并不足以说明为什么ffmpeg的MPEG-4足以击败它。

下面是一些须知事项：
$ H. l- |& f( `6 a% x

• 如前所述，这仅仅是一个针对动漫的测试；这个测试先天偏向于能够使用较小变换尺寸的视频格式（比如H.264）。所以这些结果对于非动画素材来说了无意义。而且，一些编码器是为高速而设计的，与那些非常慢的编码器同台竞技并不是那么公平。
• 我了解很多种因解码器不一致而得出相对较低SSIM结果的可能，我相信我解决了一切这类问题，但我并不敢保证。
• 我所知唯一能让解码器完全统一的方法是使用ffmpeg的Real和WMV解码器，但这或许并不完全地精确，所以这些结果（译者注：Real和WMV）可能稍有偏差。
• （据一位Theora的开发者透露）对于这个片段，Theora显然有更好的码率控制手段。所以在将来的测试中，Theora或许会有相当的进步。
• Indeo 5.1丢弃了部分帧，这是它的SSIM如此低的原因。当然，如果这个编码器确实耗尽了所有码流，以至不得不丢弃部分帧的话，我们也毫无办法。

综上所述，这张图表突出展现了优秀方案的重要性：一个糟糕的H.264解决方案（Apple）连上一代（MPEG-4 ASP）的优秀解决方案（ffmpeg）都不如。
作为参考，几乎所有的（或许我遗漏了一两个）测试片段都可以在这里找到。

唔洗讲依家都系264系王道嘅~~

本嚟每种编码器对SSIM嘅好坏（相似度）都有唔同嘅理解噶啦！  有相差同埋差距大有咩咁出奇。  H264係十分优秀嘅解决方案。  但係再点讲，都离唔开受欢迎嘅几大原则先至可以立足于世。
我谂世界上，无边D人係唔认同以下几大原则嘅，无论係收藏或係收看也是如此：
1.尽可能以最小体积（空间）占用，达到最清晰流畅嘅效果。
1 X( _) r5 Q% i- e5 ^. S, L2.以最方便嘅方式，达到最佳嘅操作要求！（所谓操作要求指嘅係，加入多字幕多配音多媒体选项选择！）
0 M* p/ b- {1 c' ^3.最完整最近似嘅相似度呈现出原有画质及画面须求。举例原为16：9视频，在4：3方式中呈现时须要加入信箱（即上下黑边）。

6 s& a; t$ q' N4 Z# ~其实，我觉得用相似度嚟比较，也係比较片面的啦。  就动漫方面嚟讲，在质量与容量方面我觉得RMVB始终係王者，264的确係有能力超越，不过我觉得只係RMVB无进步所导致嘅。要知，两者并唔係同期嘅产物！！

好复杂，顶完先慢慢睇，学下嘢都好，或者以后有用

悄悄问下，如果用软件将.mkv转成.rmvb，对视频质量影响大么？

悄悄问下，如果用软件将.mkv转成.rmvb，对视频质量影响大么？