NMM-HD

沒有

interleaved RGB和planar YUV格式完全不一樣，要添加的話pipe的過程至少為了RGB需要完全修改，反正正常來說也沒人用x264的RGB。8-bit RGB -> 10-bit YCgCo已經是無損了，壓縮率也接近YCbCr，遠優於RGB，所以覺得即使非要用無損的前處理也應該用YCgCo而不是RGB，而且YCgCo是可以用avs4x264mod來pipe的（就當普通的YUV一樣pipe），所以懶得加RGB的pipe支持…

需要pipe RGB的有ffmpeg/libav，或者相對方便一些的有avs2pipemod，因為不是x264專用工具，所以基本上不管有沒有人用，該有的東西都有。或者用x64的avs配合x64的MPP，然後所有block都走win32，僅最後一個main block用win64，這樣可以讓x64的x264直接吃avs而不需要pipe。

感谢指点，但是貌似madvr有些问题，
测试过用--qp 0 压出444的YCgCo，用madvr渲染，并不是无损的，几乎都是dither噪声
（所以开了dither渲染出颜色是错误的，虽然几乎看不出来）
madvr的dither算法也许有问题，就连渲染8bit rgb也会出现dither噪声
关闭dither的话，压成10bit几乎没有意义...

10-bit YCgCo如果來源是8-bit RGB的話，轉會8-bit RGB時關閉dither，這個過程也是無損的，如果不考慮編碼過程損失的話，這個逆向轉換過程中2-bit的lsb全部可以歸零（如果是error diffusion的dither的話，就算不關閉dither，10-bit轉換後得到的也是8-bit整數RGB不帶lsb，因此是否dither應該沒有區別，不過好像madVR的dither算法不是error diffusion的…）。當然如果用的不是無損編碼，10-bit YCgCo也許沒法不round直接轉換為8-bit無尾數的RGB，不過有損的編碼下本來也沒有保持源的方式…

確實madVR關dither會怎樣我沒試過，畢竟本身x264正常使用都是有損編碼，我自己肯定不會去用--qp 0這種沒有實際使用意義的東西，要無損保持RGB乾脆直接用更多intra型支持RGB的無損編碼器就行了，沒必要冒險去做兩次轉換或者用x264的RGB這種沒有經過嚴格測試的東西。而既然編碼階段都有損了，madVR為了改善輸出的畫面整體顯示效果做的dither反而不能接受，倒是很奇怪的事情。不dither也許單個像素看起來更準確，但是就整個畫面在漸變部分看起來反而更偏離原始畫面。dither就是在接受error的情況下讓整個畫面看上去更接近源，而不是考慮單個像素的轉換準確性這種對視頻播放來說意義不大的東西，例如
AAAAAAAAA
BBBBBBBBB
CCCCCCCCC
DDDDDDDDD
這樣一個平滑過渡，如果轉換過後的數據精度下round之後只剩下A'和D'，B和C都round到A'和D'了，這時使用
A'A'A'A'A'A'A'A'A'
A'D'A'A'D'A'A'D'A'
D'A'D'D'A'D'D'A'D'
D'D'D'D'D'D'D'D'D'
的過渡效果肯定好於準確round的
A'A'A'A'A'A'A'A'A'
A'A'A'A'A'A'A'A'A'
D'D'D'D'D'D'D'D'D'
D'D'D'D'D'D'D'D'D'
dither本身就是為了整體效果的準確性而設計的，想單點的準確，就要接收整體難看的結果，如何取捨自己看著辦吧。不過就算madVR的轉換以及它的dither有問題，也應該直接去報issue。madVR之前YCgCo的一大堆問題上報過之後都很快在新版裡修正了。LAV Video也準備支持YCgCo的matrix了。本身有益但是因為支持度不高就不去用的話好東西沒法普及，然後支持度會更低，惡性循環…

额 同样的参数taro的能用,MR不行...求MR~debug

R:\a>avs4x264mod_taro 001.avs --output 01.mp4
avs [info]: AviSynth 2.58, build:Dec 22 2008 [08:46:51]
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 35319
avs4x264 [info]: "x264_64" - --output 01.mp4 --frames 35319 --fps 24000/1001 --input-res 1920x1080 --input-csp i420
raw [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
raw [info]: color matrix: undef
mp4 [info]: audio muxing feature is disabled.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile High, level 4.0
x264 [info]: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 fade_compensate=0.00 psy_rd=1.00:0.00 m
xed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 l
okahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=3 b_p
ramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0
rc_lookahead=40 rc=crf mbtree=1 crf=23.0000 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
x264 [info]: started at Sun Nov 04 19:48:02 2012

aborted at input frame 8, output frame 0
mp4 [error]: failed to finish movie.
x264 [info]: ended at Sun Nov 04 19:48:08 2012
x264 [info]: encoding duration 0:00:06
^C
R:\a>avs4x264mod 001.avs --output 01.mp4

avs4x264mod - simple Avisynth pipe tool for x264
Version: 0.6.2.52, built on May 19 2012, 04:43:06

avs [info]: Trying to open 001.avs
avs [info]: Avisynth version: 2.58
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 35319
avs4x264 [info]: " x264_64" - --output 01.mp4 --frames 35319 --fps 24000/1001 --input-res 1920x1080 --input-csp i420
Error: Failed to create process <2>!

264768502 写了：avs4x264 [info]: " x264_64" - --output 01.mp4 --frames 35319 --fps 24000/1001 --input-res 1920x1080 --input-csp i420
Error: Failed to create process <2>!

当年重构软件的时候在文件名解析这块纠结了很久，不过看来还是有问题就是了

试试看 --x264-binary x264_64 ？

等我哪天有空了把新版本的更改合并回去吧 -v-

文件名解析那塊相當糾結，原版使用的邏輯是avs4x264所在路徑+"x264_64"，我不知道為什麼一定要加上avs4x264路徑（為了防止使用系統path裡的x264_64.exe？），所以一開始先保留這個過程了，然後為了防止avs4x264mod與x264-binary在不同目錄且都使用完整路徑指定時生成的最終路徑衝突而加了一個workaround（中途還不小心搞出了指針越界，導致有段時間XP/Server2003直接crash…），Excalibur好像就是使用當時有這個workaround的版本作為codebase的估計改起來各種糾結吧…後來看看這個過程實在沒必要就直接去掉了(commit)，只使用x264-binary作為完整路徑，現在不管啥情況都工作良好…

加不加--x264-binary都不能用...

已经把大部分新的commit都merge进来了，等编译测试 -w-

在用taro大大的avs4x264mod时说缺失avsrecursion.dll
可是貌似片子还是可以继续压的。。。求解

和avs4x264mod没关系。avsrecursion是一个dynanic library，像RemoveGrain之类函数的某些功能会要求有这个东西在path里，丢进system32/syswow64就行了