功能如题（拖），主要是用来解决部分EP滤镜组合使用时爆内存的情况。具体用法请参考压缩包内的示例脚本。

更新日志：

0.11
* 大大改善性能，某些情况下开销可下降80%
* 可锁定子进程内的工作线程到单一核心

0.9
* 新功能：帧预读
* 新功能：同时输出多个clip变量
* 新功能：可在多个进程间共享部分代码

0.3
* 修正x86文件夹内的子程序版本
* 内置TCPDeliver，不再依赖外部滤镜
* 修正退出时的随机崩溃
* 分块Branch

0.2
* 新增x64支持（请将压缩包内各平台的TCPDeliver.dll复制到对应的插件目录内）
* 可混合使用x86/x64子进程，详情请参考示例脚本（需要同时安装x86/x64的AviSynth）
* BRANCH进程新增一个变量，使脚本内可以区分不同的进程

源代码 下载

使用实例：

1. 基础用法

MP_Pipeline("""
FFVideoSource("SomeVideo")
QTGMC()
### prefetch: 16, 0
### ###
""")
MCTD()

# MCTD及QTGMC会在两个不同的进程内并行运行

2. 以大量内存为代价提速MCTD

# 要运行这个脚本，系统必须为64位并且至少有8GB内存
MP_Pipeline("""

# 此处数值可能有下降余地，不过我只测试过这个数
SetMemoryMax(3072)

FFVideoSource("SomeVideo")
MCTD(settings="high")
### prefetch: 16, 0
### ###
""")

# 之前用类似的脚本编码时比单纯MCTD有20%~30%速度提升

3. 分支

MP_Pipeline("""
FFVideoSource("SomeVideo")
TNLMeans()
### prefetch: 16, 0
### branch: 4
### ###
""")

# TNLMeans会在4个进程内分支执行

• encx264：encx264-20110819.7z
• Aegisub-2.1.9-r5553-ffms-2.16.7z
• Aegisub-2.1.9-r5773-ffms-2.16.7z with 24/32 bit audio support + subtitle grid fix
• Aegisub-2.1.9-r5789-ffms-r581.7z
• Aegisub-2.1.9-r5995-ffms-r589.7z
• Aegisub-2.1.9-r6159-ffms-r589.7z
• Aegisub-2.1.9-r6195-2-ffms-r643.7z
• Aegisub-2.1.9-r6195M13-ffms-r656-exec-only.7z
• VFRHelper：VFRHelper_1.2.7.7z
• flash3kyuu_deband 1.4.2：x86 / x64
• ffms2_r581_with_10bit_hack_libav_ec6d743.7z
• ffms2 r589
• ffms2_r643_libav_86b57e4_with_seeking_bug_workaround.7z
• ffms2-r656-libav-8ca6e52.7z
• MP_Pipeline 0.11

2. libav里面会引用inttypes.h，这个文件必须从mingw里面复制到某个地方，然后把内容改掉，不然会出现一大堆错误。改好的文件

3. LIB路径参考设置：D:\MinGW\local\lib;D:\MinGW\lib\gcc\i686-pc-mingw32\4.6.1;D:\MinGW\lib;$(LibraryPath)

4. 如链接时找不到 __imp____lc_codepage 符号，参考此处修复。注意libs.cpp里面的文件名要修正。

VFRHelper - MKV章节制作工具（不要问我为什么叫这个名字。。。
更新日志：
1.2.7
(*)TFM OVR文件编辑器1.0.3
(*)FFMS更新到r581
1.2.6
(*)FFMS更新到2.16
1.2.4
(*)FFMS更新到2.13
(*)点击视频进度条可直接跳转到指定位置
(+)TFMOverrideEditor可使用AVS脚本作为视频
(*)其它改动略
1.2.3
(*)修复部分MKV章节文件无法加载的问题
(*)Bug修复
1.2.2
(*)FFMpegSource更新到2.0 beta 4
1.2.1
(*)Bug修复及易用性改动
1.2.0
(+)新增插件框架，章节编辑器改为插件形式
(+)新增插件：TFM OVR文件编辑器
(*)一些小改动
1.1.1
(+)新增功能：按时间跳转
1.1.0
(*)视频代码重写，速度提高
(+)FFMpegSource更新到2.0 beta 3，现在打开非avs文件不需要AviSynth了
(+)使用FFMpegSource打开文件时，在标题栏显示索引进度
(+)新增支持读取VFR MP4的Timecode
(*)一些小改动及bug修复
1.0.2
(+)新增1个快捷键
(+)FFMpegSource更新到1.19
(-)使用按钮能够正常打开非AVI文件了
1.0.1
(+)新增2个快捷键
(+)快捷键现在可以自定义
(*)退出程序时会询问是否保留临时文件（如果有的话）
1.0.0
初始版本
功能：
*可视化制作MKV章节文件
*支持打开TXT及XML格式的章节
*支持VFR（只支持V2的Timecode，如果是V1的话请预先转换好
*查看V2 Timecode各帧的时间（附带功能
*编辑TFM的OVR文件
支持的视频格式：
AVI
AVS
MKV
MP4
FLV
MKV、MP4及FLV需要FFMS2.dll支持。
快捷键说明：
方向键左/右					跳转至上一个/下一个关键帧
Shift+方向键左/右			跳转至上一帧/下一帧（注意：跳转的时候会忽略空帧）
方向键上/下					上一个/下一个章节
空格								设置当前选中章节的时间
F12									解码速度测试（可以无视
快捷键可以自定义，使用记事本之类的工具编辑keymappings.xml即可。按键名称可查看KeyNames.htm获得。
一些注意事项：
*章节文件的格式无法被改变（即只能保存为打开时候的格式）
*新建章节只支持TXT格式

下载：

完整包（内附源代码）

系统需求：

.Net Framework 2.0

Windows（废话

AviSynth（可选

源代码编译需求VS2008

效果图： https://picasaweb.google.com/SAPikachu/Flash3kyuu_deband110SampleRev2?feat=directlink

文档：https://raw.github.com/SAPikachu/flash3kyuu_deband/1.4.2/flash3kyuu_deband.zh.txt

更新记录：

1.4.2 (2011-11-10)
   修复某些非mod16视频的崩溃问题

1.4.1 (2011-11-05)
   修复YUY2支持
   改进位深相关参数的默认值处理
   precision_mode 4 / 5已过时，并可能会在新的版本中移除，请改用output_mode 1 / 2以得到同样效果

1.4.0 (2011-10-30)
    9 ~ 16位深输入/输出
        相关参数：input_mode/input_depth/output_mode/output_depth
    新的随机数生成器，参考像素位置及噪声可以为均匀分布或高斯分布
        相关参数：random_algo_ref / random_algo_dither
    diff_seed已被dynamic_dither_noise取代，启用时每帧的噪声模式会变化
    另一个新参数：enable_fast_skip_plane
    新增滤镜短名：f3kdb
    新的ICC编译版理论上可在SSE2前的CPU上运行（未测试）
    少量Bug修复

1.3.0 (2011-09-07)
    新增x64版本
    新增降色深滤镜：f3kdb_dither
    内部处理精度提升至16bit
    新增参数：keep_tv_range，具体说明请参考readme.zh.txt
    修改sample_mode的默认值到2
    Bug修复：Floyd-Steinberg dither用于full-range视频时，结果可能会有错误
    Bug修复：错误的YUY2 debanding
    少量优化
 
1.2.0 (2011-08-01)
    新增支持YUY2（未优化）
    新增支持AviSynth 2.6中新的平面YUV格式
    滤镜现在同时支持AviSynth 2.5及2.6
    16bit输出（precision_mode = 4/5）
    （目前内部处理精度仍然为14bit，未来的版本会改进）
1.1.0 (2011-06-18)
    修复在高精度模式下高阈值造成的错误
    更改阈值效果以增加可调节性，同一个阈值在新版中的效果会变弱
    SSE优化高精度模式
    对某些无效参数组合直接提示错误
1.0.2 (2011-06-06)
    高精度处理模式（目前未进行优化，将会下一个版本添加）
    正确处理帧边缘
    修正某些情况下的崩溃
    其它bug修复
1.0.1 (2011-05-27)
    多线程处理
    不处理阈值为0的平面
   
1.0.0 (2011-05-21)
    修复大量Bug
    新增SSE优化，速度大幅提升，i5-520m默认参数可以达到24fps以上
0.9.1 (2011-05-05)
    修正：当blur_first=false时，处理结果会出错
0.9 (2011-05-04)
    原始发布版

下载：http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=239

脚本主要功能：
* 支持1Pass crf + 2Pass bitrate模式，自动获取crf出来的码率作为2pass参数
* 自动记录压制log
* 多target支持，脚本内可定义多套预置参数

代码 | 代码打包下载 | 免Python打包版

（脚本需求Python 3

更新日志：

 

## 2011-08-19

* Bug修复
* 如在参数中指定音频，则在1pass自动禁用以防止错误（可使用–1pass-same-extra-args禁用此行为）

## 2011-08-15
* 任务系统显示增强
^ 控制台标题栏显示整体及运行中任务进度
^ 任务完成后在信息输出中显示码率及fps

## 2011-08-12
* 以彩色输出任务列表
* 修复：1pass任务有时会在完成时卡死

## 2011-08-05
* 修复任务系统与额外参数的冲突

## 2011-08-04
* 新增任务系统，默认可同时运行两个1pass任务，并于所有1pass完成后再逐个运行2pass任务。简单命令说明请参考encx264.py !task help
* 可于target内指定x264路径，可参考sample设置
* 本版本无法从旧版自动更新，请下载完整版

## 2011-04-11
* 新参数：–inFile-2pass * ：2pass时使用另一个avs脚本
* 参数现在对大小写不敏感了

## 2011-03-15
* 默认不记录压制进度，减小log体积

## 2011-03-14
* 支持指定x264优先级
* 支持1pass压制，把target内的2pass参数删除即可
* 支持脚本自动更新

## 2011-03-06
* 可直接在命令行附加x264参数

## 2011-03-03
* 修正路径内不能包含空格的问题

基本用法：
下载后放到x264目录，然后使用以下格式执行命令即可开始压制：

 

    encx264.py <target> xxxx.avs xxxx.mp4 <crf> --tc ""


其中<target>为脚本内定义的target名字，后面的–tc ""是禁用输入timecode（因为我做的片子全部是VFR，为了偷懒脚本默认会使用脚本目录下的timecode.txt作为输入timecode，如果找不到就会报错）
target的定义方法请参考脚本内的现有target，注意花括号参数会在运行时替换为实际值。最终传给x264的参数由公共参数和target特定参数组成。
脚本可选参数：

–bitrate *：强制指定码率，适用于1pass不是crf的target
–sar *：指定sar，注意如果target内没有default_sar，不在命令行指定sar会报错
–ref *：指定ref，如忽略脚本会使用target指定的default_ref
–pass 2：跳过1pass，如之前用脚本运行过1pass，码率会从记录文件内读取，否则需要用–bitrate指定码率
–tc "xxxx.txt"：指定输入timecode，忽略的话脚本会使用avs目录下的timecode.txt，找不到就会报错。如要禁用输入timecode，指定–tc ""
–bitrate-ratio *：2pass和1pass的码率比例，默认为1.0（即使用一样的码率）
–priority [idle|below_normal|normal|above_normal|high]：指定x264进程优先级
–inFile-2pass "xxxxx.avs"：2pass时使用另一个avs脚本
– [参数]：在–后面的所有参数都会直接添加到x264命令行，例：
encx264.py <….> — –vf resize:640×480

任务系统：

默认可同时运行两个1pass任务，并于所有1pass完成后再逐个运行2pass任务。
添加任务： encx264.py !task add <参数>
（如：encx264.py !task add mkv_720p avs.avs video.mp4 20 –tc ""）
清空任务： encx264.py !task clear
执行任务： encx264.py !task run

Reflector跟踪一下，很容易能找到关键方法是System.Web.Configuration.MachineKeySection.EncryptOrDecryptData，对比补丁前和补丁后的方法主体发现补丁后的版本主要是添加了Hash签名检测：

   1: // ... snip ...

   2:  

   3: if (!fEncrypt && signData)

   4: {

   5:     if ((start != 0) || (length != buf.Length))

   6:     {

   7:         byte[] dst = new byte[length];

   8:         Buffer.BlockCopy(buf, start, dst, 0, length);

   9:         buf = dst;

  10:         start = 0;

  11:     }

  12:     buf = GetUnHashedData(buf);

  13:     if (buf == null)

  14:     {

  15:         throw new HttpException(SR.GetString("Unable_to_validate_data"));

  16:     }

  17:     length = buf.Length;

  18: }

  19: // ... snip ...

（hash函数内部使用validationKey作为salt或者HMAC的key，这里略过）

另外整个方法体也被一个try catch块包了起来，遇到异常直接抛出统一的异常：

   1: try

   2: {

   3:     // ... snip ...

   4: }

   5: catch

   6: {

   7:     throw new HttpException(SR.GetString("Unable_to_validate_data"));

   8: }

从这两点看来，理论上Padding Oracle攻击的漏洞已经被堵上了。首先，因为加上了数据签名，攻击者没办法随意修改已知的数据；另外抛出的异常内部把有关错误原因的信息都消除了，攻击者没办法区分Padding错误和解密错误，攻击自然没办法进行了。

M$这次的反应速度算是不错，漏洞爆出来两个星期左右就放出补丁了，估计是因为影响太大了吧。

另外浏览器目前只测试过IE7/8/FF3.6/Chrome6/Opera10.62/Safari5.0.2，其它浏览器有可能会RP（特别是IE6），这个稍后再决定是否支持。。。

   1:  

   2: // "true" or "false"

   3: public static string Bool2Str(bool b)

   4: {

   5:     switch (b)

   6:     {

   7:         case true:

   8:         return System.Boolean.TrueString;

   9:         case false:

  10:         return System.Boolean.FalseString;

  11:         default:

  12:         return "error";

  13:     }

  14: } 

  15:  

  16: Console.WriteLine(Bool2Str(true));

  17: Console.WriteLine(Bool2Str(false)); 

  18: unsafe

  19: {

  20:     bool val;

  21:     *((byte*)&val) = 2;

  22:     Console.WriteLine(val); 

  23:     Console.WriteLine(val==true); 

  24:     Console.WriteLine(Bool2Str(val));

  25: }

  26:  

大家可以猜一下这段代码会输出什么，我也是看了某篇文章的评论才知道会出现这么诡异的情况。。。