NMM视频技术(旧)

 找回密码
 成为会员
搜索
查看: 16770|回复: 27

[AVC(H.264)] [转载]寻找最适合动漫的视频编码

    [复制链接]
发表于 2009-11-16 22:10 | 显示全部楼层 |阅读模式
quality_chart1[1].png
寻找最适合动漫的视频编码

作者:Dark Shikari(作者系x264主要开发者之一)
译者:ssnake
关键词:H.264、结构相似度(SSIM)、评测、码率控制、x264
原标题为Encoding animation(编码动漫),原文链接:http://x264dev.multimedia.cx/?p=102

而今各类编码器的横评早已烂大街了,但我却几乎从未看到过关于动画片源的测评。与(真人)电影相比,动画素材有着完全不一样的特性,对于视频编码来说是一次全新的挑战。

首先,我们讨论一下为什么这些(动漫)视频容易压缩。动漫主要由静态画面组成:人物置于完全静态的背景上。而人物本身也几乎是静态的:现代动画往往有着一个远低于真实视频的帧速率(FPS)。此外,人物往往只是站在那里动动嘴巴,这又大大降低了复杂度。最后,动画往往非常干净,没有任何胶片颗粒。这一切,让动画压缩看上去是如此轻松。

但是,不要让上面这些理由欺骗了你——另一方面,动漫其实很难被压缩。首先,动漫中大量的码流被用于锐利的物体边缘。这些边缘信息频域转换后会产生大量的高频频谱系数,编码代价颇高。事实上,简而言之,不论是基于离散余弦转换方式(DCT-based)(如H.264、MPEG-4、MPEG-2、Theora等等)还是基于小波变换(Wavelet-based)(如Dirac、Snow等等),现有的视频格式都完全不适于编码这些动漫固有的边缘信息。而据我所知,也没有人提出能明显改善的办法(编者按:其实编码就像地图测绘,不怕一座高耸的珠穆朗玛,就怕连绵不绝的小山小丘)。或许方向小波(Directional wavelet)可以达到目的。

除了变换的难题外,就编码器的角度来看也有着重重问题。在动画素材中,移动鲜见平滑:因为动漫往往以一个(相对于真实视频来说)非常低的帧速率制作,一个物体可能在静躁之间游移,这让时间轴预测的动态搜寻难以为继。当这个物体突然向右跳了20个像素时,常规方法必然很难找到这个物体的去向。

还有视觉效果的问题:那些边缘是如此耗费码流,因而编码器会倾向于给画面其他部分(比如背景)很少的码流。这意味着我们反而经常需要设置很高的码率以防背景崩坏。

此外,动漫对于码率控制来说也是个麻烦事:对于动画片源,常规的预测方法往往无能为力;因为一帧时而耗费颇多,时而所需寥寥——尽管它们看上去可能是一样复杂。对于动画输入,即使是x264的VBV(视频缓存检验器)在一次编码(1-pass)模式下也难以给出一个良好结果;因此,也无怪许多编码器对于此类素材都束手无策。

如此总总,让动画编码好比“王母娘娘编笸箩”,看着容易做着难。

于是,让我们来看看这些编码器们的表现吧。由于几乎无法找到一段合适的免费动画资源,我从我手头唯一合适的动漫DVD——东方二次同人《梦想夏乡》——中选出5000帧进行测试。这是一个有着相对较少动作的非常干净的素材——典型的动画。

作为测试标准,我选择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设置”文件,所以我并不知道是否有更优的设置。

对于所有编码器,我使用250kbps的视频码率和(我所能设置的最接近于)250帧的最大关键帧间隔。少数不知名的编码器(比如Bink)不允许设置最大关键帧间隔。下面是我所用到的编码器、参数以及它们各自的视频格式。

x264 (r1206)
视频格式: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
视频格式:H.264/AVC Baseline Profile
参数:--preset ultrafast --tune ssim,二次编码

x264 Veryfast
视频格式:H.264/AVC High Profile
参数:--preset veryfast --tune ssim,二次编码

x264 Medium
视频格式:H.264/AVC High Profile
参数:--preset medium --tune ssim,二次编码

x264 PSNR
视频格式:H.264/AVC High Profile
参数:--preset placebo --tune psnr --rc-lookahead 250 --profile baseline,二次编码

WMV (Expression Encoder 3)
视频格式:VC-1 Advanced Profile
参数:“best”预设

Xvid (1.2.1)
视频格式:MPEG-4 Part 2 ASP
参数:全选,包括bframes、qpel、GMC

Thusnelda (August 7th ffmpeg2theora nightly)
视频格式:Theora
参数:二次编码(没有别的质量参数了)

Quicktime (7.6.2)
视频格式:H.264/AVC Main Profile
参数:二次编码(没有别的质量参数了)

ffmpeg mpeg2
视频格式: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
参数:-flags mv4+qpel+mv0+cbp+aic -dia_size 1040 -g 250 -bf 8 -b_strategy2 -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,二次编码.

On2 VP7
视频格式:VP7
参数:二次编码以及“best”预设

Ateme (1.11)
视频格式:H.264/AVC High Profile
参数:“Full” preset with “macroblock-level” psy optimizations.
注意:这并不是它的最新版本2.0,因为我不知道有谁能弄到它。所以请权当这是个一般的H.264编码器,并非Ateme的最佳表现。

Real Producer (10)
视频格式:RV40 (similar to H.264/AVC Main without CABAC)
参数:“High”质量,二次编码.

Bink Video
视频格式:Bink Video
参数:64-frame lookahead(没有别的质量参数了)

Elecard Converter Studio (3.1)
视频格式:H.264/AVC High Profile
参数:全部最高;我测试了complexity mask以期能改善SSIM,但结果并不理想,故而未用

Badaboom (1.2.1)
视频格式:H.264/AVC Main Profile
参数:它没什么设置,连二次编码都没有。

Indeo 5 (5.1)
视频格式:Indeo 5
参数:它没什么设置。

ffmpeg Snow
视频格式: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 (二次编码)

ffmpeg 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
注意:这仅作为最佳预变换时代视频格式——矢量量化(VectorQuantization)编码器的范例。我使用ffmpeg是因为因为Apple版本很糟糕,而使用固定质量模式则是因为ffmpeg对于SVQ1不提供码率模式(我使用了牛顿法以在固定质量模式中求得一个匹配的码率)。

我本打算在测试中包括Dirac,但我找不到最大关键帧间隔的设置,而用它默认很低的最大关键帧间隔(40)与其他编码器比较是非常不公平的。下面是测试结果:
Link

图例:
蓝色:x264
红色:非x264的H.264编码器
绿色:ffmpeg的编码器
黄色:不属于以上各类的开源编码器
紫色:不属于以上各类的私有编码器

有着太多的惊奇,且听我娓娓道来。

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

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

综上所述,这张图表突出展现了优秀方案的重要性:一个糟糕的H.264解决方案(Apple)连上一代(MPEG-4 ASP)的优秀解决方案(ffmpeg)都不如。

作为参考,几乎所有的(或许我遗漏了一两个)测试片段都可以在这里找到。

评分

1

查看全部评分

发表于 2009-11-16 23:24 | 显示全部楼层
本帖最后由 wtyrambo 于 2009-11-16 23:30 编辑

我说看着怎么眼熟了....原来是某蛇的妇联啊,X264普及目前最大的问题不是编码质量,而是缺乏个好的GUI啊....要是X264有个GUI比ERP好用的话,REAL格式国内还会有什么市场啊
发表于 2009-11-16 23:46 | 显示全部楼层
我说看着怎么眼熟了....原来是某蛇的妇联啊,X264普及目前最大的问题不是编码质量,而是缺乏个好的GUI啊....要 ...
wtyrambo 发表于 2009-11-16 23:24


MeGUI不是不错么(虽然最近几个版本烂了)。
RMVB我认为是认知度的问题。现在很多人心目中rmvb已经是“高清”的代名词了,300M一个的电影看得可来劲了。
发表于 2009-11-16 23:59 | 显示全部楼层
本帖最后由 wtyrambo 于 2009-11-17 00:33 编辑
MeGUI不是不错么(虽然最近几个版本烂了)。
RMVB我认为是认知度的问题。现在很多人心目中rmvb已经是“ ...
dgwxx 发表于 2009-11-16 23:46



    一个拖进文件就能转换的ERP和一个要写AVS的MEGUI,那个好?虽然有AVS creater,但是默认的directshowsource的各种问题.....国内一般人用转换软件无非是想缩小视频体积,在面对rv之类这种vfr视频源的时候看到转换出来声画不同步就不毫不犹豫放弃了?他们需要的是个能一眼看到的有resize,fps,码率这三样的简单工具就行了,MEGUI的话在这方面还差得远...大量的preset/编码格式等等能把一般用户看的头大...国外的确RV也没什么市场了,但是国内的话MEGUI这种没有中文又比较难懂的GUI一般人会去用吗?

认知度什么的倒不是问题,如果某个小组突然不做rmvb,改做mp4的话,会丧失些国产MPX观众,但是会多些PSP观众,结果还是一样,PC播放只要装了XX解码,OO影音的都没问题.

现在还有字幕组在压Xvid的片子才是我最惊讶的
发表于 2009-11-17 17:02 | 显示全部楼层
回复 4# wtyrambo
晕……在这层意义上MeGUI的确悲剧了。
发表于 2009-11-17 17:35 | 显示全部楼层
呀原来这里也有啊……嘛不过转帖至少请写个出处吧……而且Link也都丢了……
其实谁有心拿dshow2raw写个GUI应该能跟ERP竞争一下。。嘛我没心就是了= =
发表于 2009-11-17 20:18 | 显示全部楼层
回复 6# ssnake
噢噢!蛇大大本人来了!
帮您编辑好了
发表于 2009-11-18 13:44 | 显示全部楼层
啊 坑蛇你把这篇给翻译了呀-.-
ds的diary上应该还有很多文章值得翻译的 比如最近那篇为啥其它编码器质量那么糟糕的文章
发表于 2009-11-18 13:50 | 显示全部楼层
本帖最后由 ssnake 于 2009-11-18 13:53 编辑

呀秋月大你这是在挑逗我么= =

有空的话就把那篇也翻译掉好了,反正这一卷K-ON也要做了……(为什么每次都是做K-ON的时候顺便写文章呢……

唔15日有一篇关于weightp的吐槽诶= =不过没什么营养,虽然可以解决当下一些人的问题。。
发表于 2009-11-18 13:52 | 显示全部楼层
回复 9# ssnake


   嘛 我开始想翻你这篇的 后来发现你翻了
再加上你有妇联评论 咱就不抢了
发表于 2009-11-18 14:02 | 显示全部楼层
多句嘴,让anime更难编码的另一个原因是anime太多平滑/单一色调/缓慢渐变的背景
这种背景在Estimation-Transform-Quantization Based Hybrid编码方案中是很容易遭到破坏的,而人眼的主观评价中,又对这种场景的质量损失非常敏感,于是意味着对anime来说,精确地预测算法、优秀的量化器、energy conservation良好的变换基都是缺一不可的。但这三者要同时实现,各种tradeoff作用下难度颇大。
发表于 2009-11-22 14:43 | 显示全部楼层
虽然咱不是动漫派的...
就我自己接触的范围吧 国内各类的FanSub发布h.264的还真不多...
好像一说压制大家先想到的就是RMVB... 惯性思维也好, 推广度也好, 反正大多数人还是认RMVB~
其实很多很多的FanSub组远远的没有那么专业
wtyrambo说的挺对, 一个avs就能让不少人望而却步了... 更何况megui里其他那么多的参数...
有毅力和兴趣愿意深入研究的人并不多, 觉得大部分人还是"只要能压出东西就好"的态度...

至于xvid嘛 还是觉得各有优劣吧, 有的时候还是挺喜欢它的噪点的, 对于真人视频更有立体和真实感
倒是近期看到有人压的DivX, 真真吓了跳...
发表于 2009-11-23 08:17 | 显示全部楼层
回复 12# yntang66
撒 我们组坚持全部264编码发布已经一年多了-.-
发表于 2009-11-23 08:31 | 显示全部楼层
有些真人拍摄的地方看着就让人绝望,XVID的选择还是很不错的,至少不用考虑太多,还有就是动作游戏视频,感觉xvid高码率舒服一些
发表于 2009-11-23 09:20 | 显示全部楼层
我是实写白痴
发表于 2009-11-23 11:00 | 显示全部楼层
本帖最后由 ssnake 于 2009-11-23 11:08 编辑

XviD给足码率的话实写确实好,但(相对较低的)同码率现在已经不如x264了。上次疼Suara那LIVE的时候试过,720p,接近5000kbps,x264还是比XviD强。再之前疼ef的黑白特典的时候也试过,1080p,7000+kbps,XviD灰度观感居然还是不如x264。

不过观感这个东西也不好说,因为我喜欢干净的画面所以x264肯定占便宜……
发表于 2009-11-23 11:45 | 显示全部楼层
XviD及其他近期的壓縮器, 也會將線條糊化來降低碼率, XviD用CQ2 (MPEG Quant)也令畫面變得很模糊。
我上次壓Aquaplus Live 2008 1080i 平均用25000kbps至30000kbps, 要到這個碼率才能保留大部分細節.......包括暗位細節、ISO雜訊等。
x264的缺點是會令畫面質感改變。

現在正在面對一個大難題.......8-bit YUV產生的色階問題
发表于 2009-11-25 19:15 | 显示全部楼层
XviD给足码率的话实写确实好,但(相对较低的)同码率现在已经不如x264了。上次疼Suara那LIVE的时候试过,7 ...
ssnake 发表于 2009-11-23 11:00



    高码率下xvid的确是不错,但是那些字幕组一般是一部DVDRIP分辨率为6XX*3XX时只给1200左右码率....真人的话这个码率怎么也不会够吧....
发表于 2009-11-26 00:09 | 显示全部楼层
哇 我压720p crf18砍掉30%下来也不过1500
当然 是264啦(死
发表于 2010-1-26 01:45 | 显示全部楼层
呀原来这里也有啊……嘛不过转帖至少请写个出处吧……而且Link也都丢了……
其实谁有心拿dshow2raw写个GUI ...
ssnake 发表于 2009-11-17 17:35

POPGO有人写了个GUI。。。。
http://popgo.net/bbs/showthread.php?s=&threadid=524640
您需要登录后才可以回帖 登录 | 成为会员

本版积分规则

小黑屋|手机版|NMM视频技术

GMT+8, 2019-10-15 10:11 , Processed in 0.104747 second(s), 21 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表