关于新版x264 2074中添加的1.8M内容（相当于1995）

猜你喜欢: MEGUI, qtaac, ios

这几天把x264从1995更新到2074，发现体积增加不少。

结果发现惊喜，直接有音频编码器了。

初步发现支持PCM\MP3\AAC（raw、lame、faac）

本人对音频不了解，请教一些x264对音频编码的质量如何？

另外这1.8M还有一些什么其他的更改呢？

------------

另外我想知道有人对精确控制体积有心得的高手么？
(基本上算是用AVS控制体积，以求在低码率获得高画质，但是另外一种是用x264的强力参数，其实有人研究这2者对速率的影响么）
目前小弟采用1pass CRF,2pass 指定码率的方式。
测试来看，基本上对于新番来说，每话都可以保证一个相对稳定的体积。

-----
另外吐槽x64的AVS。这玩意根本不能用啊不能用。


[ 此贴被pHaTty在2011-09-10 17:01重新编辑 ]

megui里的升级？

1995->2074并未引入音频，这个是非官方编译版（或者叫非纯净版更好）
引入的音频为L-SMASH的扩展功能

音频编码跟直接用这些音频编码器去单独编码没有质量上的差别，只有参数限制差异
比如这里编码mp3用的是lame，直接用相同版本、相同参数的lame.exe编码是一样的

但是其中质量最好的qtaac现在在发布版里往往都被取消了，因为不想跟Apple惹上可能的版权问题，如有需要可以将x264替换为这个：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=219

另外，L-SMASH最初只是改良mp4的封装规范，因为GPAC方式输出的mp4会有一定的概率性质的问题，即这1.8MB还有对mp4输出的相关优化

此外我不清楚那个编译版是不是还加了其他东西


1pass CRF,2pass 指定码率控制体积也够精确了吧，貌似现在质量向的都是这样做的
如果你是指AVS降噪之类的来控制体积的话，我个人觉得这是个见仁见智的做法
至于速度就只有靠自己测试了，毕竟这还很可能会影响质量，尤其是细节相关，也不好比较


期待AVS出3.0吧……把x64和多线程的问题都完美解决


[ 此贴被upyzl在2011-09-10 18:15重新编辑 ]

感谢楼上的解答。
我曾经看到一个关于使用1pass的crf码率的80%来作为2pass的脚本。
不知道是否有人工获取这个码率的办法。

我个人没人编程基础，对于python有点抵触啊。
============
1pass CRF,2pass 指定码率控制体积也够精确了吧，貌似现在质量向的都是这样做的
---------
这样做主要还是效率太低。1pass有没有什么好的方法？
有人给我说换10bit的x264，但是这个的话，可能会引发一些普通观众换播放器。
现在字幕界在推广720P嘛，我个人觉得这个要推广的话，必须搞定体积和质量的平衡。
10bit是个好选择，可惜……普及度


关于AVS的x64，我研究了一下午。
用播放器可以播放，但是放在x64的megui又会报错。
另外主要是x64没有字幕插件啊，太致命了。

是需要x64的VSFilter.dll么？
这里有
http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-3-3677.html
下载Standalone Filters - Win64 (x64)即可

这样的megui报错我想一般都是分离器和解码器的问题，64bit下可以用CodecTweakTool调整，再尝试


另外你说的那个脚本是SAP的么？有免Python版的


1pass要平衡好720p体积和质量的话，我个人觉得用crf 22 + preset veryslow + level 4.1再根据视频微调下deblock/psy/aq应该是个不错的选择
另外还有个损招，用--zones强制把仅OP/ED部分的码率拉低，虽然我个人并不喜欢这样……因为我看动画极少跳OP/ED，并且喜欢截取搜集OP/ED；但客观说，这样做对节省一集24分钟动画的体积却很有用，比如当年SOSG做的K-ON，OP+ED往往能占到一集体积的40%


[ 此贴被upyzl在2011-09-10 20:30重新编辑 ]

我已经放弃x64的尝试了。。
折腾，bug多不说，效率也搞不到哪里去。
-----
--crf 23.5 --tune animation --deblock -1:-1 --me umh --merange 32 --subme 11 --trellis 2 --threads 24 --vbv-bufsize 10000 --vbv-maxrate 10000 --rc-lookahead 85 --keyint 240 --aq-mode 2 --qpmin 10 --qpmax 51

这是某人给我参数，我觉得吧，subme 11似乎没有必要。
--------
SOSG做的K-ON，OP/ED往往能占到一集体积的40%
这个好像是拜特效所赐。
-------
另外还有个损招，用--zones强制把仅OP/ED部分的码率拉低
我觉得还好吧。720P作为首发的低体积版本可以考虑牺牲OP/ED
你收集OP/ED应该还是会等BD/DVD的无字幕版本的吧？


===
顺便问问，FFmpegSource产生的.ffindex有啥作用啊，可以关闭么。。


此区……好像就靠你撑着了？
wiki也没收录你的资料诶。。


[ 此贴被pHaTty在2011-09-10 20:44重新编辑 ]

嗯，umh + subme 11没tesa + subme 10好，不管是速度还是压缩率，当然像要推广720p高清+比较早发布的话，umh32+subme10就已经挺好了



对我而言，带特效的更有价值……至于是否有那些STAFF之类的信息都无所谓了
不过BD的质量相当好，非常喜欢的还是要收的，比如电磁炮这样的



ffms必须的东西。。就是作索引用，分离视频时都会有这东西，只不过一般分离器将其弄在内存里而不在硬盘上；压完片再删也无所谓吧。。



非也。。多翻下本区其他帖子自然知道哪些是常客了

嘛，我刚才翻了一下本区的帖子。
原来SOSG的视频区如此强大。
我会经常来玩的。
-----
ffms必须的东西。。就是作索引用，分离视频时都会有这东西，只不过一般分离器将其弄在内存里而不在硬盘上；压完片再删也无所谓吧。。

我自己去看了一下wiki，好像这个东西还有很多高级设置。
---
关于AVS的分段处理的话，一般可以这样写吧

a=ffaudiosource(file)
v1=ffvideosource(file,fpsnum = 24000,fpsden = 1001).trim(0,b).
v2=ffvideosource(file2,fpsnum = 24000,fpsden = 1001).trim(b,c).
……
vz=ffvideosource(filex,fpsnum = 24000,fpsden = 1001).trim(y,z).

v = v1+v2+……vz
audiodub(a,v)
-

------------
嗯，umh + subme 11没tesa + subme 10好，不管是速度还是压缩率，当然像要推广720p高清+比较早发布的话，umh32+subme10就已经挺好了

我测试了一下，tesa + subme 10比umh + subme 11慢诶。。
我是I5的cpu……


[ 此贴被pHaTty在2011-09-11 14:04重新编辑 ]

subme 11目前应该没什么大用
SAP那个脚本我记得是从输出信息里读取1pass码率的
不产生索引文件可以这么写：ffvideosource(clip,cache=false)
另外某电视台的说法：
crf+2pass bitrate比较耗时间，1pass crf足够用；码率为王，EP参数在高码率前都得败

不产生索引文件可以这么写：ffvideosource(clip,cache=false)
=-=
嗯，我在wiki查到这个了，还是感谢回答

=======

另外某电视台的说法：
crf+2pass bitrate比较耗时间，1pass crf足够用；码率为王，EP参数在高码率前都得败

如果国内应该普及4Mbps，我犯得着去控制体积么。。
另外，电视台…我就不吐槽

X264那个音频编码器用处不大，该用单独音频编码器的还会继续用，再说某些音频编码他也集成不进去，版权问题之类的

某电视台ORZ，京都还是ATX还是TBS，反正都是某两人的MJ

crf+2pass bitrate比较耗时间，1pass crf足够用；码率为王，EP参数在高码率前都得败
这话不得不+MAX，蛋痛EP参数的效果还不如提升点码率或者多研究研究"洗白"滤镜,至少给一般人看的TV新番用这招绝对好用，就现在TV动画这素质，哪有多少细节啊