加载中…
正文 字体大小:

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

(2012-05-15 13:24:22)
标签:

高压

x264

杂谈

分类: MediaTechnology

度熊胃口真好……放这边好了

此前本人在bili发过2个高压视频(在ac也投过,但两天后被xilin给吃了尽量不浪费压制时间的简单视频高压要点

http://www.bilibili.tv/video/av26434/

http://www.bilibili.tv/video/av41621/

 

这里再额外放一个,是x264核心开发者之一Dark Shikari09年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

 

部分评论:http://cache.baidu.com/c?m=9d78d513d9d431d84f9e97697c15c0166d4381132ba7d0020fa48449e3732a43501793ac57270772d0d27d1716d94a4b9afb2104331451b38cc9f85dacc885582c9f5745676b805613a30edfcc5154c737912afedf68f0cef025e3a9c5a0d84352ba44740997868a4d7110dd1ff7033093b1e942022964ad9b33728f526028ef3436b6508a93251e009681dc480b8374df3b57d1ed22b14d0fa848b31f6c7e1fb74cc658027d66a758278815605b8fa305f02d0d4027b64bb5bfdce6b515d9c1b177cfa5d6aa7e9030e7c1baf87a452652fa20b8aebfb83d654702da9ec916b368faa5b2a71db44b884700fc4a775b2a8f30c2958e21f0755af0b328a37635275e00d9b524e875743f67bf396cf34c9522a689020d97a8ca9f9e6346b899c1342ca8babe34f2365d64b7304562cff65571139307799ad4b96ea3760fa4ca17c00358db7d1368bcaca2fedf6ab62f1fae03cbf9d5b96542&p=8b2a9e1e86cc42ad53b98a6f4a008f&user=baidu&fm=sc&query=������˷�ѹ��ʱ��ļ���Ƶ��ѹҪ��&qid=c6d9cfed06c1a2f3&p1=2

0

阅读 评论 收藏 转载 喜欢 打印举报
已投稿到:
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 不良信息反馈 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有