备份向:尽量不浪费压制时间的简单视频高压要点

http://blog.sina.com.cn/s/blog_3df9d2330100zcy4.html
 
备份向,以免原文某天没了。作者zj262144。
 
好几年了,供参考。
 

 
度熊胃口真好……放这边好了
此前本人在bili发过2个高压视频(在ac也投过,但两天后被xilin给吃了)
http://www.bilibili.tv/video/av26434/
http://www.bilibili.tv/video/av41621/

这里再额外放一个,是x264核心开发者之一Dark Shikari于09年7月31日压制的某个东方project动画(梦想夏乡),视频流67.4kbps,音频流26.2kbps
http://x264.nl/developers/Dark_Shikari/Flash/lowbitrateanime.html
可以用flvcapture下载视频
此视频只是为了说明x264可以将动画压得很小,同时视频本身不至于烂到渣(显然即使是这么低的码率,也明显要比很多在线视频质量更好)

很多人都来问是如何压的,事实上只要CPU足够强劲,直接--preset placebo就是最省事的方法,但对大多数人(比如像我这样只买得起E5200的穷人)来说,这样压制在时间上就过于不划算了。很多高手,比如doom9上面的x264开发者,是建议用户直接使用preset+tune方式压制的,满足绝大多数需求,在压制时间和压缩率上的平衡杠杆上也处理地不错,但对我这种精益求精到EP的程度的人来说,还是喜欢自定义所有参数来压制视频,以确保在可以接受的压制时间前提下,以尽可能低的码率,来获得尽可能高的画质。(会这么EP某种程度上可以说是受了真红之瞳的影响)

我现在压制都是基于命令行方式。为了让广大使用MC的群众明白我之后说的,建议先看此文
http://www.nmm-hd.org/doc/X264使用介绍
作为命令行压制入门,这是很好的文章;同时里面也有各个版本的x264下载链接页面。
此文是让大家了解下什么是命令行式操作,具体操作在本文后面会提及。

不走牺牲压制时间这条路,可以通过适度降低分辨率来达到在较低码率下实现清晰的画质。现在AB两站大多还是512x288或者512x384的视频,这点倒没有什么说的。不过在线1080P则可以说是完全没必要,因为要实现1080P比较好的画质,如果视频同时还是很多高动态场景的视频,或者在材质、颗粒精细度要求较高的视频上,码率是无论如何都不可能低下来的。在线视频的话,高码率和高分辨率会对视频的解码和网速有不低的要求,此外flash在资源利用的优化上也很渣,在线看1080p和本地看1080p无论从解码流畅度角度还是观赏角度来说,都不是一样的。因此本人压在线高清的上限为720p,码率也是够用就行;如果用相同码率压制1080p,马赛克什么的就很明显了。1080P目前最好的分享方式还是通过网盘或者P2P
高清缩小分辨率有一个折中的方案,就是靠拉伸分辨率。11区的电视台玩的就是这套。现在我们看的动画的HDTV片源只是1440x1080拉伸到1920x1080放给11区人看的,并非BD的原生1920x1080。这么做的原因是,质量上损失是相对较小的,但视频码率可以得到有效降低,毕竟数字电视就是靠数据传输。我压制的av26434那个,实际分辨率是1024x720,自动拉伸至1280x720,明显节省码率的同时,相比直接用1280x720并没损失多少质量,同时还加快了编码速度。

另外一个重要点是crf(Const Quality, 固定质量),我上面给的那个地址也有提到。这种码率控制方式是非常优秀的,以至于可以无需2pass压制,即即使1pass也能实现非常好的码率分配利用。像质量模式的压制方式在其他编码器也有(如xvid或者压制rmvb的ERP),但据我所知都只是“固定量化(Const Quantization)”x264的crf在量化的基础上,根据人的视觉心理学更为合理地分配码率,其目标是让人在看视频的时候,视频的质量尽可能地统一,但码率达到尽可能的有效利用。

crf模式的主要缺陷是不知道压出来的视频到底会有多大,但除此以外,跟现在最常见的2pass码率法相比,如果其他参数相同,同码率下在质量上不会有什么区别,哪怕你去一帧一帧比较。但显然,crf只需要跑1遍,2pass需要跑两遍,整体上用crf明显省了不少时间
尽量不浪费压制时间的简单视频高压要点
上面是crf,下面是2pass bitrate
尽量不浪费压制时间的简单视频高压要点
crf所用时间=1466/85.82=17.082(秒)
2pass所用时间=1466/182.84+1466/95.41=23.383(秒)
这样crf就能节省(23.383-17.082)/23.383=27%的时间,但码率就摆在那,质量上的差别肉眼是无法察觉的(事实上,2pass用的RC算法就是crf所使用的)
x264默认就是--crf 23,范围1.0~51.0(过低会强制转为预测性无损编码),值越高码率越低,一般在线用crf 24就能获得不错的水平了,当然也可以进一步提升crf,出来的视频码率往往都不高的
crf模式还有个优势,很多人在压片的时候不清楚应该给视频压到多少码率才比较好。crf就是按需要来分配码率的,故其实就省下了到底要多少码率的苦恼。
 
下面说下其他参数(以r1884为例)
-r, --ref <整数>  Reference Frame,即参考帧,决定最多可能的参考帧数。
有效范围值1~16。该值越大,压缩率越高;但大于6后对压缩率的贡献很低(可以看压制完后x264 [info] ref 项,例如上图P L0那行,71.0%表示P帧参考自己,4.2%表示参考隔壁1个帧的百分比,16.1%代表参考了2个的百分比,以此类推),而速度的损失则是很明显的。
此外,该值同时会影响视频的解码等级(如果不加额外限制),过高的ref对解码的需求也高。
默认3,推荐3~6,我现在用5
--b-adapt <整数> 决定B帧替换P帧的算法。
0为无差别替换(显然绝大部分情况是不建议用这个的,这会让帧分配变得很不合理);
1为快速替换(此模式下bframes≥3都不会有明显的速度差别,但更高的bframes在此模式下并不意味着更好的压缩率);
2为优化替换(此模式下bframes越高,压缩率越好,当然速度越慢,可以理解跟ref差不多了)。
默认1,推荐2,我现在用的也是2
-b, --bframes <整数> 最多允许P帧替换为B帧的连续个数。特性上面说了。
默认3,推荐3~6(配合--b-adapt 2),我现在用的是5
这里额外说下,P帧只能前向预测(即参考它之前的帧),B帧能够双向预测,从而可以提高压缩率,更适合场景变化不大的帧群
如果是静态图比重很大的视频,比如音乐区常见的图集类视频,使用direct264的deldup(删重复帧)更好,既可以节省码率,又能节省压制时间,见http://hi.baidu.com/zj_262144/blog/item/fff0ed4cbd7e731bb3de05bb.html
除此以外direct264支持不经过AVS或mencoder方式可直接内嵌ass这类特效字幕
-I, --keyint <整数或"infinite"> 最大IDR帧间距。IDR就是关键帧,本身不参考其他任何帧。
IDR的存在对视频跳转有极大帮助,但不参考其他帧注定压缩率不高,过多的IDR就会影响视频的压缩率。
如果视频较短,认定看视频的人不大会拉进度条,该值可直接用infinite,对压制时间和压缩率都有好处
视频较长可适当拉长。
默认是250,建议设15xfps(如23.976fps的视频,可设360)
-i, --min-keyint <整数> 最小IDR帧间距。
越小越好,这样能允许在值得插入IDR的时候没有束缚,因为IDR往往是被参考最多的帧,在合适的地方使用IDR,整体上能够更好地利用有限的码率
默认fps取整,建议设1
--scenecut <整数> 控制额外插入IDR帧的参数。除了keyint的限制,scenecut会根据视频前后两帧的变化程度判断是否插入IDR,这个是额外的,但依然会受min-keyint的影响,故上面建议min-keyint设1
默认40,该值越大越容易插入额外的IDR帧
因为本人主要压制OP/ED这样的视频,故这三个参数现在是使用-I infinite -i 1 --scenecut 50这样的组合

还有很多属于动态预测分析类参数,如--partitions(可简写为-A),--direct--me--merange--subme(简写-m), --trellis(简写-t) 可直接参考preset里的设置调整
这些参数在视频画面变化较大时很有用,在视频变化较小时对视频质量的贡献也较小。举个极端例子:静态图视频,用--me dia --subme 2跟--me tesa --subme 10的差别在同码率说实话质量都不是很大,但压一个燃系的MAD或者AMV就可看出这两个参数在质量上是天差地别了(相同较低的码率,其余参数一样)
这块我跟很多字幕组用的参数是一致的,如下
-A all --direct auto --me umh --merange 32 -m 10 -t 2
前两个对速度的影响比较小,故直接加上来
trellis对速度和压缩率影响都算是中等水平,高压设为最高的2还是有意义的,并且此时也不用去考虑deadzone了
subme直接用最高的10也是因为相比默认的7在速度上的损失还能接受,基本相同质量下还是能省下不少码率
me不用更慢更好的esa或tesa是因为速度损失太大,但获得的好处太小

--rc-lookahead <整数> 为宏块树码率控制(MacroBlock-Tree Ratecontrol, 简称mb-tree)设置可用帧的数量。
该值从压缩率角度说是越大越好,当然也越慢。实际起效会受限于keyint,但若keyint只要不小于250就没瓶颈。
默认40,最大250,建议60
--qcomp <小数> 量化器曲线压缩参数。
范围0.0~1.0
0意味着固定码率,1意味着固定量化。不过从本人实际测试来看还是有一定偏差
默认0.6
另外,该值越小意味着mb-tree效果越大,所以不少地方的高压都有使用--rc-lookahead 250 --qcomp 0.5,即通过适当降低qcomp让mb-tree发挥更大作用;由于--rc-lookahead 250并没有--ref 16或者--b-adapt 2 --bframes 16那样费时间,这个参数是可以一试的

-f, --deblock <整数A:整数B> 调节H.264标准中的内置去块滤镜,也叫控制loop滤镜
AB的范围都是-6~6,官方建议在-3~3里调节。默认0:0  tune animation里为1:1
一般而言,偏向负值能更好地保留细节性的东西,偏向正值则能使视频画面显得更为干净和柔和。不过实际效果其实不是很明显,尤其是跟avs和ffdshow的那些滤镜相比。如果喜欢rmvb的那种略模糊效果,此参数可直接设6:6,在低码率下效果还是不错的
从整体上看,高压的话这个应该开正值,建议就用1:1
--psy-rd <小数A:小数B> 这个参数不好用中文来直接翻译。简单说是一种心理视觉模型算法,能提升细节,似乎也有锐化效果让视频看起来更好。
默认1.0:0.0  tune animation里为0.4:0
高压一般是0:0,因为要把有限的码率给大致的轮廓这些部分;如果有限的码率都被psy-rd这块使用了,画质就会显得很渣的感觉
不管怎么说,这个是一个比较主观的参数,没有任何辅助参数可以用来客观检测这个参数使用的好坏,只能靠眼睛去辨认。
--aq-mode <0|1|2> Adaptive Quantization Mode,弹性量化模式。
先简单说明一下aq是干嘛的
在一帧图片里,简单点,假设这个图片是32x32的,该帧可划分为4个16x16的宏块,如果关闭AQ,x264在编码时会给所有的宏块的量化值都是A;如果开启AQ,则4个宏块的量化值可能分别是A-2, A+2, A, A。如果第1块是一般人都在意的内容,而基本不会去在意第2块的内容,那么这时AQ就起到了更为合理分配码率的作用(量化值越低,保留的信息就越多,其他条件不变的话所需体积也更大;反之亦然)
0为关闭这个特性
1和2是不同的分配算法,默认是1,2到目前为止还是“实验性”
高压的话,保险起见建议用1,2是否更好目前没任何决定性的东西可以证明(2014年更新:从这么久汇总的信息来看,高压的话还是使用mode 2更佳)
此外这个参数同样也是偏主观性的参数
--aq-strength <小数> 与上面的参数是配套的。弹性量化强度。网上一般解释为设定AQ偏向低细节宏块的强度。
范围0.0~3.0,但超过1.5一般视频的物体边缘会变得很糙,尤其是高压
tune animation是设为0.6

以上就是大致高压的核心参数了,归总起来就是这些参数(注:x264 r2036对预设参数有所更新,故这里参数也适当调整下;另外由于acfun和bilibili都支持宽屏模式了,所以没有再压512x288的必要了)
x264 --crf 24 --preset 8 -r 6 -b 6 -I infinite -i 1 --scenecut 60 -f 1:1 --qcomp 0.5 --psy-rd 0.3:0 --aq-mode 2 --aq-strength 0.8
preset 8即preset veryslow,可以用--fullhelp看到 后面的参数有复写的

下面再说一些必要的
重设画面大小(resize)是经常用到的东西,对于现在大部分16:9视频来说,都需要将视频resize成512x288
现在官方x264已经集成此滤镜,参数格式为--vf resize:宽,高,拉伸比,拉伸方式,色彩空间转换,方式
举个实例,我一开始在文章前面说的1024x720的压法(原视频是1280x720,正常的16:9),这里可以用--vf resize:1024,720,5:4,,,lanczos这样的参数,5:4是通过1280:1024算出来的,lanczos是resize算法之一,对动画resize来说质量已经很好了,主要是速度也不慢;最好的方式是spline,但速度比较慢。注意不要把视频的分辨率弄大,这是很严重的无用功。

最后简单说下通过命令行方式,从拿到原视频到成品flv的过程
这里以官方x264+neroaacenc+官方ffmpeg+roozhou修改版ffmpeg的组合为例子(该组合不依赖于你现在装的是什么解码器,这样起码不会有经常看到的因解码器造成的压制问题;也不需要额外安装其他东西,只需要这4个exe单文件就能正常工作)
创建一个记事本(与这3个exe在同一目录下即可),里面内容如下
CD /D "%~dp0"
x264 --crf 24 --preset 8 -r 6 -b 6 -I infinite -i 1 --scenecut 60 -f 1:1 --qcomp 0.5 --psy-rd 0.3:0 --aq-mode 2 --aq-strength 0.8 --vf resize:768,432,,,,lanczos -o "%~dpn1_v.mp4" "%~1"
ffmpeg -i "%~1" -f wav - | neroaacenc -q 0.28 -if - -ignorelength -of "%~dpn1_a.m4a"
ffmpegr -i "%~dpn1_v.mp4" -vcodec copy -i "%~dpn1_a.m4a" -acodec copy "%~dpn1_enc.flv" -map 0:v -map 1:a
pause
关闭保存,txt后缀改为bat,之后用鼠标拖拽视频文件扔给bat即可编码;局部测试的话可以给x264里面加这样的参数--frames 1000 表示只编码1000帧,可粗略看下效果
如果觉得neroaac用-q 0.28在码率上有些高,可尝试降到0.24或0.2(建议用0.04的倍数)
如果原视频的音频码率本来就低,则可以直接用ffmpeg复制,上面的ffmpeg两行参数改为
ffmpegr -i "%~dpn1_v.mp4" -vcodec copy -i "%~1" -acodec copy "%~dpn1_enc.flv" -map 0:v -map 1:a
中间的纯视频文件和纯音频文件我没自动删,主要是可能在封装过程中出问题,此时可以试试先封装成mkv再转flv
此外ffmpeg也没有自动覆盖已存在的文件,需手动确认,此举也是防止误操作

这里再提供一种批量转换(方式也是批量拖拽)
以x264压制+复制音频流的方式说明
@ECHO OFF & CD/D "%~dp0"
:Enc1
IF "%~1"=="" GOTO :EOF
x264 --crf 24 --preset 8 -r 6 -b 6 -I infinite -i 1 --scenecut 60 -f 1:1 --qcomp 0.5 --psy-rd 0.3:0 --aq-mode 2 --aq-strength 0.8 --vf resize:768,432,,,,lanczos -o "%~dpn1_v.mp4" "%~1"
ffmpegr -i "%~dpn1_v.mp4" -vcodec copy -i "%~1" -acodec copy "%~dpn1_enc.flv" -map 0:v -map 1:a
SHIFT /1
GOTO :Enc1
批量转换没有pause,转完cmd窗口即自动消失

x264可经由我一开始给的nmm链接那里下载(下面附了个地址);
neroaacenc.exe在MC这样的编码器里应该有,直接拿就是
似乎MC里的neroaacenc.exe的有些问题,NeroAACEnc官方下载:http://www.nero.com/eng/downloads-nerodigital-nero-aac-codec.php
x264纯净编译版下载:http://x264.nl/
ffmpeg下载:http://ffmpeg.zeranoe.com/builds/
或者roozhou的编译版:http://sourceforge.net/projects/direct264/files/Related Programs/ffmpeg (demuxer_muxer only)/ (注意roozhou的ffmpeg没法做pipe给neroaacenc那一步)
 
相关帖:http://tieba.baidu.com/f?kz=989441422

10 thoughts on “备份向:尽量不浪费压制时间的简单视频高压要点

  1. StarBrilliant

    说两点:
    1、Adobe Flash 的 FLV 播放器解码的时候是不开 deblock 的。
    比如我的 av1031637,下载播放和在线播放有区别,尤其是开头几分钟夕阳的镜头,大概就是这个原因。
    2、NeroAAC 的音质并没有大家吹得那么好,在低码率的时候甚至拼不过 FAAC。
    我个人推荐 libFDK-AAC,在低码率和中码率的表现可以和商业的 Apple Quicktime 相媲美(但是对 profile 的支持比 Apple 多而好)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *