标签： 图像处理

AviSynth网络分布式计算TCPDeliver使用笔记

AVS有一个功能似乎一直不太为人所知，那就是TCPDeliver——可以利用网络进行分布式运算，实现性能的提升。然而通过一下午的测试，发现要想利用这个功能实现性能提升，条件还是很多的。

介绍一下TCPDeliver。TCPDeliver由两部分构成——TCPServer和TCPSource。
TCPServer，顾名思义，功能是建立一个服务器，监听指定点口。
TCPSource用来连接TCPServer建立的服务器，取得服务器输出的视频。
两个函数的使用方法很简单，手册里的说明和例子也很详细，这里不再赘述。
通过这两个参数的连环使用，理论上可以实现无数台节点来进行处理，但其结果同样是显而易见的——随着节点数量的增加，计算效率必然呈现下降。当这个下降超过分布处理带来的性能提升的时候，整体效能势必不升反降，结果适得其反。

===================================
以下是测试
===================================
先介绍一下参与本次测试的三台电脑：
1.E8400（没有OC） + 2G DDR800 （1000M网卡）
2.T7200 + 2G DDR667 （1000M网卡）
3.赛扬2.4G + 512M PC150（100M网卡）
今天下午主要测试了两个项目：中复杂度脚本和高复杂度脚本。使用最简单的分工方式——一台电脑负责处理AVS脚本，另一台电脑负责用x264去压缩。也就是，将处理和压缩这两个部分分别交给两台电脑，实现效能上的提升。

首先我很天真地在3号机上运行了一个中等复杂度AVS脚本，然后，在1号机上通过TCPSource (“192.168.0.7″,5415,”LZO”)来接收视频，并送给x264压缩。
压缩1200帧片段10.80fps，甚至不如1号机单独运行来的速度高（15.00fps），整体速度不升反降。思考一下，这个似乎也在预料之内，因为两台机器的性能差距太大了，3号机很显然成了性能瓶颈，1号机一直处于等待状态。
吸取教训之后，我用2号机替代3号机（此时网络连接速度是1000M），进行同样的测试。这次两台电脑配合无间，取得了16.50fps的好成绩，超过单独运行1.5fps。

接下来在2号机上运行高复杂度脚本，在1号机上用同样的参数压缩，速度10.32fps，比1号机单独进行的11.47fps慢了1fps。

结论：
因为两个机器之间存在性能差，所以测试高复杂度AVS的时候，T7200的性能瓶颈一下子就显示出来了，速度甚至不如E8400单独运行。但是，不是T7200的绝对性能不够，而是AVS不支持双核，T7200的CPU占用率一直在49%。
所以，根据编码器的参数和AVS脚本的复杂程度的不同，运用TCPDeliver提升性能的条件也不尽相同。简单地说，要想用TCPDeliver后性能高于使用前，至少要保证服务器端输出fps要大于客户端编码器的处理能力才行。
此外还有一个瓶颈在于网络。100M网络理论传输能力大概在12.5MByte/s上下（实际上是到不了这个速度的）。而704×480@24fps的YV12无压缩数据量有11.6MByte /s左右，如果整体处理速度到达20fps以上，网络将成为新的瓶颈，这点是需要预防的。

诡异的CCTV奥运开幕式SD信号

本来兴冲冲地买了一个爱狗USB电视棒想录CCTV-HD的，结果买到之后才了解到必须到能看得到天塔且没有建筑物阻挡的地方才能收到数字信号，遂乖乖断念在家录SD。本地电视台转播质量本来就差，再加上是老楼房，线路质量那是相当的不好，画面经常出现雪花，音质也不理想。但没想到SD一看，才看出来很多好玩的东西。开幕式本身的精彩程度是毋庸置疑的。恐怕以后也难有超越本届奥运会的开幕式了吧。
7：48分直播正式开始，屏幕上出现了鸟巢的画面。结果几秒钟之后字幕一出来我就囧了。
Image
这是搞什么飞机……电视有overscan，没听说过字幕自己overscan的……八成是CCTV偷懒，把HD的信号变形切边之后直接嫁接到SD这边来了。
Image

Image
这两个画面更加证实了我的想法，的确是HD信号变形切边之后嫁接过来的。字幕被切过了……

演出继续，画面切入了会场大屏幕的影像。
Image
竟然是25P的……看来是CCTV事先拿到了带子，直接播的录像。不过这没什么，雅典奥运会转播的时候，公共信号似乎也是这么做的。

之后更囧的事情发生了！看来这时CCTV自己也意识到了信号的问题。时间走到27分钟，也就是人体作画的环节。20473帧开始到20500（27:00.000秒，看来他们是掐着整点算的）帧结束，一个“温柔”的渐变，画面竟然从4：3画面渐变到了Letterbox形式的16：9……OMG……
Image
这时候画面上的“直播”logo也从新闻台的“直播”换成了CCTV-HD台的“直播”。下面是对比：
Image

Image
看来这回变成了把HD信号变形之后加黑边嫁接过来了。这时，字幕也恢复了正常。
Image
但随之而来的问题更囧了，以HD画面的尺寸为准加上去的滚动字幕缩小之后，就算在电脑显示器上也难以辨别，更别说在可怜的破电视上了。
（这张图没有经过缩放，720*576的）
Image

看来CCTV在HD信号和SD信号同时播放方面还没有足够的经验啊，开幕式就直播得这么囧……不过，我估计上述问题应该仅限国内提供SD信号的那几个频道，发送海外的公共信号应该没问题才是。
抛开画面上的囧处和偶热切错的几个镜头和点火前那台信号出问题的摄像机之外，总体来说，还算是完美。

TIVTC的自动交错帧记录与手动OVR脚本

上次在这篇帖子里提到了ovr的利用，今天来详细写写。

好长时间没码字了，那么今天就来写一个可能很多高手都会解决的问题，那就是利用TIVTC的自动记录交错与手动OVR脚本来手动指定Post-processing的动作。
在IVTC过程中，一部分帧会走PP，也就是被送去Deinterlace。但是这部分帧当中，有一部分是因为匹配失败而被PP（确实找不到合适的场匹配结果），有一部分是匹配成功但被误判为交错送去PP，而通常情况下只有较少的一部分帧是真正因为无法找到合适的匹配而出现交错的（也就是第一种情况）。

TIVTC的匹配精度很高，绝大多数情况下不会出现错匹配的情况（但是我也遇到过极少数例外的情况发生，需要通过ovr手动指定匹配pattern，这个下次有时间再写）。
TIVTC的问题在于，他的默认参数比较灵敏，在后处理检测时微小的交错也能察觉出来，因此容易造成误判，特别是动画OP/ED中的字幕，经过PP之后，文字不断抖动，非常难看。而那些参数又非常难以调整，常常是这边调好了，那边又坏掉了。虽然通过OVR也可以单独分段指定参数，但我还是建议使用默认参数，最后通过OVR来针对出错的帧进行修正。
因此，我们就需要结合TIVTC的记录输出功能和OVR手写脚本功能来“强制”TIVTC对我们指定的帧进行PP或者不进行PP。

我们首先要找出哪些帧出了问题。之前我注意到，不少同学还在使用我好多年前用ConditionalFilter + decomb写的那个交错侦测脚本，其实现在TIVTC里面已经内置了相当丰富的交错侦测功能，独立函数ShowCombedTIVTC和IsCombedTIVTC在调试TFM的cthresh、 MI、 chroma、 blockx、 blocky、 metric等参数方面很好用，也可以结合ConditionalFilter写出来交错侦测的脚本，但我们今天要用的是TFM内置的output参数来输出log文件。
首先，我们需要构建出来一个avs脚本，让tfm输出log文件。这个过程相当于IVTC过程的1pass，我们不需要通过这个脚本输出成品，因此要让这个脚本高速地执行，快速得到我们要得log文件。
1pass.avs:
d2v = "op.d2v"
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true, output="log.txt")
PointResize(96, 96)各个参数的目的是在保证检测精度的情况下尽量提高速度。
log.txt就是我们要输出的log文件。现在我们要执行这个脚本，你可以通过播放器去播放它，但是这样还不够快，我们可以让x264以一组简单的参数去压制这个脚本，这样通常能够得到数倍于播放的速度（它在我的E8400 CPU上跑出了150fps）。
x264 --crf 51.0 --level 1 --no-fast-pskip --nf --no-cabac --subme 1 --partitions none --me dia --threads 2 --thread-input --aq-mode 0 --progress --no-dct-decimate --no-psnr --no-ssim --output "F:druagaopop.mp4" "F:druagaopop.avs"（注意，请不要用MeGUI去压这个脚本，用MeGUI压制的话tfm之会输出一个空文件，而得不到我们要的log。更不要试图修改log文件，因为之后载入log文件的时候，tfm会检测log文件是否发生过改变。）
压制结束之后，我们会得到一个不小的文件，他包含了tfm对每一帧的处理方式、判断结果。但我们真正需要的是这个文件尾部以#号开头的那一段。
一段典型的该部分log会像下面一样（中文部分是我的注释）：
#
#
# OVR HELP INFORMATION:
#
# [COMBED FRAMES]
#以下是被判断为交错、需要走PP的帧。前面是帧号，后面是该帧的交错度。
#
# [Individual Frames]
# FORMAT: frame_number (mic_value)
#
# 1544 (256)
# 1545 (256)
# 1546 (256)
# 1547 (87)
# 1548 (108)
# 1563 (82)
# 1566 (92)
# 1569 (99)
# 1570 (99)
# 1571 (95)
# 1572 (110)
# 1578 (256)
# 1579 (256)
# 1613 (256)
# 1614 (256)
# 2184 (170)
#
# [Grouped Ranges Allowing Small Breaks]
# FORMAT: frame_start, frame_end (percentage combed)
#
# 1544,1548 (100.0%)
# 1563,1579 (47.1%)
# 1613,1614 (100.0%)
#
#
# [POSSIBLE MISSED COMBED FRAMES]
#下面是tfm觉得交错程度较大，被判断为可能交错的帧，但因为不够阈值设定的值，因此不会走PP，仅提供用户肉眼确认、参考。
#
# FORMAT: frame_number (mic_value)
#
# 455 (17)
# 470 (16)
# 950 (40)
# 1559 (76)
# 1560 (76)
# 1564 (75)
# 1565 (75)
# 1567 (74)
# 1568 (74)
# 1576 (69)
# 1577 (65)
# 1620 (72)
# 1621 (72)
# 1623 (73)
# 1624 (73)
# 1625 (78)
# 1626 (70)
# 1627 (71)
# 1631 (69)
# 2177 (20)
# 2182 (19)
# 2187 (42)
# 2192 (58)
#
#
# [u, b, AND AGAINST ORDER (n) MATCHES]
#使用了u、b、n这三种匹配方式，得到了“无交错匹配”的帧。为什么说“无交错匹配”而非“正确匹配”呢，因为DVD在制作中可能存在一些bad cut或者Telecine制作错误，u、b、n这三种匹配方式通常可以有更大的几率获得无交错的帧，但是也有可能造成画面一顿一顿的（恰好匹配到了和上一帧或下一帧相同的画面），因此tfm也认为这些帧需要肉眼确认。如果确认发生了jerkness，用户可以通过ovr来选择是输出无交错的帧好，还是通过pp输出一个模糊一些但保持动态的帧好。但这并非本文讨论话题，所以只略微提及一下，详细的……等有时间再写吧。
#
# FORMAT: frame_number match or range_start,range_end match
#
# 319 u
# 347 u
# 387 u
# 428 u
# 730 u
# 826 u
# 920 u
# 948 u
# 1511 u
# 1580 u
# 1615 u我又写了一个脚本来逐帧确认交错情况。
check.avs:
d2v = "op.d2v"
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true)用vdm或者au打开它，跳到[COMBED FRAMES]这段log中提到的帧，逐帧检查，并最终确认1544、1545、1546、1578、1579、1613、1614真正存在交错，其余全部是误判。现在，只需要用记事本写一个文件，告诉tfm其余帧是清白的即可（将误判为交错的帧用-号标记，强制tfm将这些帧直接输出）。
当然，如果你愿意，也可以检查[POSSIBLE MISSED COMBED FRAMES]里面记录的帧的情况，这部分帧被认为是可能存在交错的帧，输出时，这些帧会被当作好帧直接输出。如果这部分帧中真的存在交错，应该在ovr文件中用+号标记。
ovr.txt:
1547 -
1548 -
1563 -
1566 -
1569 -
1570 -
1571 -
1572 -
2184 -之后我们通过tfm载入之前的log和ovr文件，并引入PP、decimate。
MPEG2Source(d2v)
tfm(d2v=d2v, mode=3, pp=4, slow=2, chroma=true, input="log.txt", ovr="ovr.txt")
tdecimate(mode=1)这里说明一下，通过input载入之前的log文件可以提高tfm的速度，因为tfm直接从log文件中读取之前做过的计算结果，可以不用再次进行匹配了。而input（也就是tfm自己的计算结果）和ovr文件中指定的策略、参数冲突的时候，ovr的优先权高。

虽然这种工作对于OP/ED来说比较繁重，但是这样通常能够得到更完美的效果。

后记：
TFM的ovr功能超级丰富，几乎可以匹敌手动IVTC的效果。而配合output参数，我们可以用更高的效率来得到更好的结果。
关于p、c、n、b、u等匹配方式，以及通过ovr来指定pattern其实也不是很困难，tfm的readme里面都有很详细的说明。有时间的同学不妨阅读一下。

Aviutl用输出插件x264outLite v3

【原理】
本插件利用AVS中TCPDeliver功能，在AU中创建一个虚拟服务器，向AVS输出图像，实现了x264 cli版与AU的结合。

【安装与注意事项】
将x264outLite.auo、x264outLite.ini和tools文件夹放置于aviutl.exe所在目录。tools目录下包含x264 r839，您可以前往http://x264.nl随时下载新版本x264。
使用前，请确认您已经安装了最新版本的avisynth，且avisynth默认插件目录下存在TCPDeliver.dll。
由于程序需要使用部分本地网络功能，请先确认您的网络防火墙状态，必要时请将AU加入排除列表中。

【使用】
打开aviutl，首先打开「その他」菜单中的「出力プラグイン情報」，确认插件是否正确加载。如果看到“x264outLite v2 by Dgwxx, based on x264out by pomu.”说明插件已经正确加载。
此时打开您希望输出的影片，在「ファイル」菜单的「プラグイン出力」子菜单中选择「x264outLite」，单击「ビデオ圧縮」按钮，在弹出的对话框中选择希望的预设参数(Profile)后，进行输出即可。
如果您希望在任务完成后电脑自动关闭，请选择Shut down after finish复选框。注意，当您使用AU自带的批量处理「バッチ出力」时请勿使用插件的关闭电脑功能，否则第一个任务完成之后电脑就会关闭，后续任务不会执行。

【配置文件】
您可以使用任何文本编辑器（如windows记事本）打开x264outLite.ini，修改x264参数、创建/删除预设参数。
打开配置文件之后，您会发现配置文件被前方带有半角感叹号(!)的行分割为若干个部分，每个部分都为一个组设参数，叹号后即为该预设参数的名称。
预设参数实质为批处理命令(bat)，第一行普遍为
set x264OPT=…
此为指定x264的参数。
最后一行普遍为
x264.exe %x264OPT% -o “%OUT%.mp4” %AVS%
此处是执行x264压缩。实际运行时，%x264OPT%会被替换为之前指定的参数，”%OUT%.mp4″会被替换为输出文件名，%AVS%会被替换为avs临时文件的路径。
您可以在配置文件中加入注释，注释行必须以半角井号(#)开头，在执行时注释会被忽略。
除了常用的命令外，您还可以使用其他批处理命令来实现更加灵活和更加多变的功能，如自动2pass等。

【源代码】
本插件基于ぽむ的x264out v0.8修改而成。修改过程中将原作x264out的mkv封装功能、vfr功能、宽高比设定、声音处理等功能取消，简化配置文件设置，制成直接封装输出mp4文件的简化版。在今后的规划中，会在压缩设置界面中加入x264的GUI功能，不通过配置文件，直接设定压缩参数。
源代码已经包含于压缩包中，没有任何限制，您可以随意使用。
编译环境：VS2005 SP1 + SP1 Update for Vista/Windows Vista Ultimate SP1/Intel Core2 Duo T7300

【下载与反馈】
欢迎前往NMM论坛报告问题、提出建议、讨论使用心得。x264outLite的地址是：
http://www.dgwxx.com/nmmbbs/thread-626-1-1.html

【更新记录】
2008.05.02 v3
*从代码中去掉了声音处理功能。
*因为命令行窗口暂停会导致批处理功能失效，因此去掉了命令行窗口暂停的功能。
*增加了对视频宽度的判断，视频宽度必须能被4整除。

2008.05.01 v2
*从程序代码中去掉了vfr功能、宽高比设定功能。
*从配置文件中去掉了声音处理功能。
*增加了完成后自动关机功能。

2008.04.29 v1
第一版 内部测试用。

影片播放过程中的YC伸张

前天我和VempX瞄准DVDRIP过程中的YV伸张与压缩进行了一些实验。今天我做了一些实验，整理了一下播放过程中YC伸张与否的规律，分享给大家。其实我有些怀疑这篇文章的意义，因为用户随便按一下显示器上的MagicSet之类的按钮，或者调节一下亮度色温对比度给图像带来的改变远远大于播放设置错误带来的误差。老实说，我在这做了半天实验带来的实际意义似乎并不是很大。
但就算这样，该做的还是要做，该写的还是要写。少点错误总比多点错误强。
本文理论浓度较低，但是实践的部分比较复杂，估计有不少人会头晕，头晕的话可以先去看结论，等回过头来再看实践部分或许就能理解了。
文章中若存在错误、不足的地方，还要您请多指教。

废话少说，现在进入理论。
理论篇
首先我们要明确，YC伸张发生且仅发生于从YUV颜色空间向RGB颜色空间进行转换的过程。明确了这点之后我们就可以减少很多不必要的猜想和迷惑。
其次，在播放过程中影响YC伸张的环节有三，一个是解码器，一个是渲染器，还有就是显卡。
有些解码器/渲染器不带有YC伸张或RGB转换功能，那最终完成YUV到RGB转换任务的或许就是显卡。

实验准备篇
为了清楚地知道播放过程中是否进行了YC伸张，必须要准备的东西还是彩条，这里称为彩条A。因为普通的彩条难以判断黑、白、红、绿、蓝的范围，所以我们用Photoshop制作一张专门用来判断颜色、亮度范围的640*480的彩条图片，保存为24bit bmp格式。彩条上半部分的颜色范围为16～240，黑白部分为16～235（601 Range）。下半部分全部为0～255（Full range），用于进行对比。
之后，使用使用以下AVS代码将bmp图片生成一个5秒钟的短片。
#AVS代码1：
ImageSource ("colorbar.bmp",end=149)
AssumeFPS("ntsc_video")将这个短片送入TMPGEnc压缩成MPEG2格式。压缩时，打开TMPGEnc的YC压缩选项，此时图像上部为30～217，下部为16～235。
播放时：

  • 图像上部为30～217、下部为16～235，则没有进行YC伸张。（也就是MPEG2里面的原始数据）
  • 图像上部正常回复为601 Range、下部为Full range则判断为进行了一次YC伸张。
  • 如果上下全都变成了0～255的Full range，则是进行了两次YC伸张。

当然，只有第二种情况才是正确的。

除此之外，为了判断显卡/渲染器是否能够自动判断是否进行YC伸张，我们制作了另一个彩条，这里称为彩条B。彩条B的内容与彩条A完全一致，但是在送入TMPGEnc压缩成MPEG2格式时，关闭TMPGEnc的YC压缩选项，此时图像上部为16～235，下部为0～255。
播放时：

  • 图像上部为16～235、下部为0～255，则没有进行YC伸张。（也就是MPEG2里面的原始数据）
  • 图像上下完全相同，都是0～255，则进行了至少一次YC伸张。

只有第一种情况是正确的。
因为我在学校只有一台笔记本电脑，主板集成Intel X3100显卡，所以没办法测试其他厂商的显卡效果如何，所以在测试显卡是否做了YC伸张这个环节里，结果只代表X3100。

实验进行篇
【播放TV Scale的视频(彩条A)】（我们下载到的99%的视频都是TV Scale的）
haali’s video render(设置为tv scale，进行YC伸张)
Elecard(yuy2) 正确
ffdshow libmpeg2(yuy2 tv/pc) 正确
ffdshow libmpeg2(转换为rgb，设定为TV Scale，伸张) 正确
ffdshow libmpeg2(转换为rgb，设定为PC Scale，不伸张) 错误

haali’s video render(设置为pc scale，不进行YC伸张)
ffdshow libmpeg2(yuy2) 错误
ffdshow libmpeg2(转换为rgb，设定为TV Scale，伸张) 错误
ffdshow libmpeg2(转换为rgb，设定为PC Scale，不伸张) 正确

覆盖合成器
ffdshow libmpeg2(yv12) 正确
ffdshow libmpeg2(转换为rgb，设定为TV Scale，伸张) 正确
ffdshow libmpeg2(转换为rgb，设定为PC Scale，不伸张) 错误

VMR9无渲染
ffdshow libmpeg2(yv12) 正确
ffdshow libmpeg2(转换为rgb，设定为TV Scale，伸张) 正确
ffdshow libmpeg2(转换为rgb，设定为PC Scale，不伸张) 错误

小结：因为片源是TV Scale的，因此播放过程中需要做一次且只能做一次YC伸张。从实验结果看出，YC伸张发生并且仅发生于YUV颜色空间到RGB颜色空间的转换过程中。因此，要不在解码器这一步伸张并转换RGB，要不在渲染器中伸张转换成RGB。
当在解码器中转换为RGB时：ffdshow中，RGB变换页里的“对比度”设置会起作用。当选择“标准”的时候做YC伸张，选择“全范围”的时候不做YC伸张。渲染器收到RGB之后会跳过YC伸张步骤。
不在解码器中转换为RGB时：当解码器输出YUV颜色空间给渲染器时（haali不吃YV12，只吃YUY2和RGB的样子），部分渲染器会将其转换为RGB颜色输出给显卡。haali好像就是这样做的，haali会根据用户设置的TV range（伸张）还是PC range（不伸张）决定是否进行伸张。覆盖合成器和VMR9的资料比较少，我不知道他们是否会将颜色空间转换为RGB，但是至少从直观看来，通过覆盖合成器和VMR9之后，都经过了YC伸张，只是不知道这个伸张是显卡做的还是合成器做的。

【播放PC Scale的视频(彩条B)】
覆盖合成器
ffdshow libmpeg2(yv12) 错误

VMR9无渲染
ffdshow libmpeg2(yv12) 错误

haali’s video render(tv scale)
ffdshow libmpeg2(yuy2) 错误

haali’s video render(pc scale)
ffdshow libmpeg2(yuy2) 正确

小结：自动判断是否需要YC伸张是不可能实现的？

结论篇
主要的结论在前面的小结中已经给出。尽管不同的显卡对于图像具体的处理方式不同，我们仍然有一个方法可以在所有的显卡上显示出正确的图像：将正确的RGB颜色交给显卡就可以了（尽管可能需要较高的系统配置，但大多数标清级的视频的话P4以上的CPU应该都能胜任）。因此，ffdshow解码和haali渲染着对组合不错。ffdshow输出yuy2颜色，在haali渲染器中进行YC伸张。如果实在不知所措的话，不如干脆拿彩条试一试，看看怎么能放出正确的颜色即可。

DVDRIP过程中YC伸张与YC压缩的实验

YC伸张与YC压缩是一个从Silky大人时代就留下来的古老问题。包括我在内的很多人都没搞明白，制作和播放的时候提心吊胆，生怕弄错了颜色。最近正好没事，进行了一系列的实验，看看YC伸张和YC压缩到底是真么回事。本文的阅读对象是已经知道YC问题的由来，但不知道如何处理的读者，如果您还不知道什么是YC伸张和压缩，推荐您先去复习一下Silky的文章。
本次实验分为四个部分，分别是准备篇、AVS篇，AU篇和播放篇，由我和VempX分别进行自己熟悉的部分。
限于作者水平，或许会有疏漏错误，请多指教。
继续阅读DVDRIP过程中YC伸张与YC压缩的实验

(转载)x264 rev767测试

本文来自夜の工房，转载已获得原作者同意。

这两天x264又开始发疯似的更新…………
今天的767版changelog里这么写到

    skip intra pred+dct+quant in cases where it’s redundant (analyse vs encode)
    large speedup with trellis=2, small speedup with trellis=0 and/or subme>=6

到底这个large speedup是多么的large呢？
不禁激起我测试一下的欲望

测试方法如下

从DVD里截取一段1m11s的视频，然后Resize到864×480，并输出无压缩YV12的AVI，用AVS载入AVI，在CMD下送给x264压制。

我的CPU是Core2Duo E6550，超频到3.2G

首先用MEGUI自动更新的763 patched版。

命令行如下

–qp 18 –ref 3 –aq-strength 0.0 –mixed-refs –no-fast-pskip –bframes 3 –b-pyramid –b-rdo –bime –weightb –subme 6 –trellis 1 –analyse all  –8x8dct –me umh –threads 3 –thread-input –progress
–no-dct-decimate –no-psnr –no-ssim –output “test.mp4” “test.avs”

测试结果

avis [info]: 864×480 @ 23.98 fps (1724 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:19    Avg QP:15.00  size: 47242:00:00
x264 [info]: slice P:659   Avg QP:18.00  size:  9882
x264 [info]: slice B:1046  Avg QP:19.71  size:  1509
x264 [info]: mb I  I16..4: 39.4% 23.1% 37.6%
x264 [info]: mb P  I16..4:  8.1%  3.3%  3.0%  P16..4: 47.2%  8.6%  5.1%  0.6%  0.3%    skip:23.7%
x264 [info]: mb B  I16..4:  0.1%  0.0%  0.1%  B16..8: 20.7%  0.7%  1.3%  direct: 0.9%  skip:76.1%
x264 [info]: 8×8 transform  intra:22.8%  inter:59.3%
x264 [info]: ref P  73.0% 16.3% 10.7%
x264 [info]: ref B  88.9% 11.1%
x264 [info]: kb/s:1000.0

encoded 1724 frames, 18.04 fps, 1000.10 kb/s

再来测试x264.nl上的767版，参数一样。

测试结果

avis [info]: 864×480 @ 23.98 fps (1724 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:19    Avg QP:15.00  size: 47242:00:00
x264 [info]: slice P:660   Avg QP:18.00  size:  9868
x264 [info]: slice B:1045  Avg QP:19.71  size:  1511
x264 [info]: mb I  I16..4: 39.4% 23.1% 37.6%
x264 [info]: mb P  I16..4:  8.1%  3.3%  3.1%  P16..4: 47.2%  8.6%  5.1%  0.6%  0.3%    skip:23.7%
x264 [info]: mb B  I16..4:  0.1%  0.0%  0.1%  B16..8: 20.7%  0.7%  1.3%  direct: 0.9%  skip:76.1%
x264 [info]: 8×8 transform  intra:22.8%  inter:59.2%
x264 [info]: ref P  73.0% 16.3% 10.6%
x264 [info]: ref B  88.9% 11.1%
x264 [info]: kb/s:1000.1

encoded 1724 frames, 22.53 fps, 1000.24 kb/s

下面使用设置高一些的参数再压一次

–qp 18 –ref 3  –aq-strength 0.0 –mixed-refs –no-fast-pskip –bframes 3 –b-pyramid –b-rdo –bime –weightb –subme 7 –trellis 2 –analyse all  –8x8dct –me umh –threads 3 –thread-input –progress
–no-dct-decimate –no-psnr –no-ssim –output “test.mp4” “test.avs”

现在用MEGUI自动更新的763压制，结果如下

avis [info]: 864×480 @ 23.98 fps (1724 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:19    Avg QP:15.00  size: 45907:00:00
x264 [info]: slice P:659   Avg QP:18.00  size:  9229
x264 [info]: slice B:1046  Avg QP:19.71  size:  1420
x264 [info]: mb I  I16..4: 34.9% 27.7% 37.4%
x264 [info]: mb P  I16..4:  8.6%  3.1%  3.1%  P16..4: 43.4%  8.6%  4.1%  0.5%  0.3%    skip:28.1%
x264 [info]: mb B  I16..4:  0.1%  0.0%  0.1%  B16..8: 20.8%  0.7%  1.2%  direct: 1.2%  skip:75.8%
x264 [info]: 8×8 transform  intra:22.1%  inter:52.4%
x264 [info]: ref P  74.1% 15.7% 10.1%
x264 [info]: ref B  90.2%  9.8%
x264 [info]: kb/s:938.9

encoded 1724 frames, 13.33 fps, 939.02 kb/s

使用767压制，结果如下

avis [info]: 864×480 @ 23.98 fps (1724 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:19    Avg QP:15.00  size: 45907:00:00
x264 [info]: slice P:660   Avg QP:18.00  size:  9214
x264 [info]: slice B:1045  Avg QP:19.71  size:  1420
x264 [info]: mb I  I16..4: 34.9% 27.7% 37.4%
x264 [info]: mb P  I16..4:  8.5%  3.1%  3.1%  P16..4: 43.4%  8.7%  4.1%  0.5%  0.3%    skip:28.2%
x264 [info]: mb B  I16..4:  0.1%  0.0%  0.1%  B16..8: 20.8%  0.7%  1.2%  direct: 1.2%  skip:75.9%
x264 [info]: 8×8 transform  intra:22.2%  inter:52.4%
x264 [info]: ref P  74.1% 15.7% 10.2%
x264 [info]: ref B  90.1%  9.9%
x264 [info]: kb/s:938.8

encoded 1724 frames, 13.51 fps, 938.90 kb/s

变化对比

 

 

 项目 

763

767

参数

变化率

fps

18.04

22.53

subme 6 trellis 1

+25% 

bitrate

1000.10

1000.24

–

0%

fps

13.33

13.51

subme 7 trellis 2

0%

bitrate

939.02

938.90

–

0%

结果好像和changelog不一样哦~

在me6和tre1的情况下，767的速度确实大大的提高，提高幅度较763达到25%，很惊人！但是在me7和tre2的情况下，这个速度的提高基本可以忽略了。

再来看两个参数对码率的影响。同样是CQ18，第二套参数的码率要比第一套小6%左右，高参数对体积的影响还是可观的。不过缺点是会牺牲速度。到底是要速度还是要码率，就看各位Riper的意思了~

2007/11/03 Aviutl version0.99a更新！

官网：http://ruriruri.zone.ne.jp/aviutl/

首先感谢卡伯在MSN签名上告诉大家。

四年没更新了T_T本来以为作者早就放弃了，没想到11月3号突然就更新了。这次更新应该是一次bug修正，除了IVTC方面的大量修正以外，还解决了那个怨念了好多年的YUY2->YUV444转换的Bug，大快人心。此外，还加入了多线程处理的功能，同样大快人心。只不过到目前为止还不知道是连通外部插件一起多线程化了还是只有内部的功能多线程化了。

据原作者说是还没经过太多测试，不知道会不会出问题……如果AU能够继续完善就好了，最好开始支持Unicode。

2007/11/03 ver 0.99a
SSE2使用時に自動24fpsの範囲の値によっては落ちることがあるのを修正。
SSE2使用時にプラグイン外部関数のrgb2yc()で落ちることがあるのを修正。
インターレース自動24fps使用時に時間軸ノイズ除去の動作がおかしくなるのを修正。
YUY2->内部YCbCr変換時に画面の左上にごみが出ることがあるのを修正。
YUY2->内部YCbCr変換時にYUV4:2:2->YUV4:4:4の補間処理がおかしかったのを修正。
インターレース自動24fpsの横縞部分の二重化を少し改良。
インターレース自動を少し改良。
出力時の一度にファイルに書き込むバイト数を指定できるようにした。
出力の処理を少し高速化。(FILE_FLAG_NO_BUFFERINGを使用するようにした)
画像処理をマルチスレッド化した。

NTSC DVDRIP 切边与Resize速成

虽然今天讲这个问题有些炒冷饭了，但是因为很多人对这个问题还有很多不清楚的地方，所以今天再次专门写一篇文章出来总结一下这个问题。
本文专门针对对C&R了解不深的人，只讲我们最常见到的NTSC动画DVD的C&R操作，并且每种操作方法都讲解其优势、劣势。因为是只讲操作的文章，理论含量几乎为0，希望了解理论知识的朋友请移驾Silky圣经。 继续阅读NTSC DVDRIP 切边与Resize速成