Fraps無損要使用什麼AVS腳本 壓成x264 10bit才不會有顏色上的損失

[msg7086]

32位爆内存可能性大

[litfal]

似乎果然是系統不穩。加個0.03v電壓，還沒跳過錯。
另外請問一下，Dither裡面 lsb=true 是什麼意思呢？

10bit真的好讚，檔案小、顏色佳、SSIM更高
缺點就是...壓得比較久 + 沒辦法直接傳youtube

[mawen1250]

lsb(Least significant bit)就是16bit输出的开关，用8bit的MSB来表示前8位数据，8bit的LSB来表示后8位的数据，所以AVS预览起来就看到上下层叠的图像（用于AVS内处理）或者是左右交错的图像（用于输出给x264编码）

[litfal]

再交叉測試後發現，Down10的tv_range=false會使得x264轉檔時在一開始就crash。

關於lsb，我這樣理解不知道對不對：
所以是用Dither_convert_rgb_to_yuv加上lsb=true，將RGB轉成16bit的yuv，
再利用Down10把16bit轉成10bit，好餵給10bit x264吃。
...但好像又不對，照您的說法，16bit應該是兩個8bit，但depth應該是10bit阿...

又有了疑問：為什麼不能直接rgb->10bit yuv? 感覺少一個步驟應該會再快一點，是位元組合的問題?
而且這樣掃描線寬度必須要是40的倍數？不然位元數沒辦法同時滿足16bit和10bit？

還有，YCgCo相較於bt709，來源同樣是RGB32或RGB24的話，在編碼上有什麼優勢嗎？

爬文中:
Co=R-B，Cg=G-(B+(Co>>1))，Y=(B+(Co>>1))+Cg>>1)
光這條的話，這樣的算法看起來是比轉換YUV要快一點...
但是其中應該不只這樣...
稍微做了一下實驗，不過很短，說不定沒什麼參考價值= =
bt709:
x264 [info]: SSIM Mean Y:0.9906224 (20.279db)
x264 [info]: kb/s:15962.76
remux [100.00%], 6562/6562 KiB, 1312571 KiB/s, total elapsed 0:00:00
YCgCo:
x264 [info]: SSIM Mean Y:0.9904841 (20.215db)
x264 [info]: kb/s:16477.21
remux [100.00%], 6774/6774 KiB, 1354862 KiB/s, total elapsed 0:00:00

不過輸入就有不同，SSIM價值也僅供參考。

[06_taro]

1. 關於crash，您提供的數據不足以分析crash原因；

2. lsb是指對整體影響不明顯的位。例如123.456，這個數字高位是123，對數值大小影響大；地位是456，對數值大小影響小，所以前者是msb，後者是lsb，這個意義按英文名一目了然。avs本身只支持8-bit yuv/rgb的數據結構，因此如果我們想儲存16-bit的數據，必須用兩個8-bit的clip疊加，疊加方法可以是stack也可以是interleave，這是根據最後用途決定的。在很多16-bit濾鏡裡，用lsb表示對象clip是與avs默認存儲的普通8-bit不同的16-bit clip，相當於對存儲結構標註的一個flag，僅此而已；

3. 16-bit是8-bit msb + 8-bit lsb，當然如果要10-bit的話就用2-bit msb + 8-bit lsb就行了，然而前面2-bit的msb還是放在8-bit msb的空間內的，只不過這個msb裡前6位都是0而已，數據還是佔據16-bit空間的。總不能有一種bit depth就給avs專門hack一個數據結構吧（當然有人很勤快地這麼做也無所謂…）。Down10就是把8-bit msb + 8-bit lsb的16-bit轉成msb裡8位中前6位都是0的8-bit msb + 8-bit lsb；

4. 直接rgb->10bit yuv可以，沒問題，如果您去寫的話就有，不去寫的話就沒有。10bit不是什麼通用泛用的數據結構，8bit/16bit才是。當然少一步中間步驟速度是會快些，譬如從12.000fps提升到12.001fps，但是顯然這種做法不符合封裝函數保持通用性的目標。假設我這個片子用A+B+C+D的組合，另一個片子用D+C+B+A的組合，而B+C在一起時可以合併，D+C在一起時可以合併，是不是我要個自己處理的每一個片子都專門寫一個把冗餘操作都合併好的函數，為了這個速度提升呢？

5. YCgCo的優勢是8-bit RGB->10-bit YCgCo（PC Level），轉換正確的情況下，這個過程是完全無損的，將10-bit YCgCo轉回去產生的是完全不帶小數部分的8-bit interger RGB。而轉成YCbCr/YPbPr的話，不管精度多高都是有損的，即使轉成16-bit YCbCr，然後再轉回8-bit RGB，也許數值上可能也保持不變，不過這種不變是將小數round回8-bit整數情況下正好不產生error而已，並非是無損的轉換。所以YCgCo可以在壓制前的處理上保持無損。當然這是很多人對於前期處理過程不肯接受哪怕一點點RGB->YCbCr的損失，而且對於編碼過程非要用逐幀AB對比這種比較靜態圖像編碼的方式去比較動態視頻編碼，我沒辦法只好折衷推薦的方法，有這麼EP的顯然應該去配合--qp 0來編碼而不是lossy編碼了= =；

6. YCgCo的轉換後確實可以做到比YCbCr快，不過dither工具裡是用和YCbCr相同的算法來做的，只是matrix coefficients改了而已，中間省略的步驟不多，實際上速度差不多，反正都不算慢，隨便上一個稍微EP點的濾鏡前面RGB/YUV轉換的速度差就看不出來了；

7. 不同的源比SSIM，連參考意義都沒有。當然像這個例子要比的話也是有辦法的。像有些4:2:0/4:2:2/4:4:4對比中源有做up/down sampling、前期做up/down sampling和壓完了播放時再做甚至壓完了導入avs再做都是不同的，完全是四個始終沒法達到相同的變量在比較，那種測試再比SSIM什麼的就很搞笑了。這裡原始RGB片源作為a，壓制好的YUV作為b，將b轉成RGB，然後用Compare來比PSNR，例如
AviSource("RGB-Source.avi")
WhateverProcess()
拿這個東西去壓制，然後
a = AviSource("RGB-Source.avi")
b = xxxSource("YUV-Encoded.ext").Dither_Convert_YUV_TO_RGB()
Compare(a, b)
參數不加了，按情況自己調整。不過我記得目前缺少能直接吃入成10/16bit YUV4:4:4的源濾鏡，可能只能先把壓好的東西解碼成raw yuv，然後用rawsource之類的工具讀入，比較麻煩…這樣比較確實是同源的，如果不同方式處理之後壓出來的保證碼率相同的話是有比較價值的（或者做不到完全相同可以用bitrate-PSNR曲線）。另外注意比SSIM的話需要--tune ssim，比PSNR需要--tune psnr，否則psy-rd/trellis的算法本身對ssim/psnr影響都太大了…

[litfal]

感謝！

原來如此，我以為10bit是緊湊而無填0的結構(其實是以為30bit填2bit的0做為結構)，原來在input時是16bit。
8bit的input少一半所以速度會快些?
另外好奇，Down10對捨去的6bit是有做Round，還是 & 0x3FFF ?

[06_taro]

30bit填2bit成32那個是在DCT quantization過程會用到的結構，avs裡沒這麼用
一般avs濾鏡GetFrame耗時間遠低於後面處理的時間，8bit少一半一般不會速度成倍提升
Down10自己看參數說明去，默認開dither

[tea1111980]

顺便强烈抗议mawen的x264参数太长太累赘了纯属吓唬小白,直接preset veryslow就不用写那么多了...

是的，参数看上去很多，很全。。哈哈~~~

[littlepox]

最近我就在做游戏视频，用Fraps录制8bit RGB无损，用dither工具转换为16bit 444 PC Range YUV，然后降为10bit输出给x264用10bit 444编码。

参考AVS：

代码： 全选

avisource("M:\Test\Wow 2012-05-04 23-55-12-86.avi")

Dither_convert_rgb_to_yuv(matrix="709",tv_range=false,lsb=true,mode=-1,ampn=0,output="YV24")
Down10(depth=10,dither=-1,smooth=0,tvrange=false,stack=false)

这样会转换成交错格式的10bit输出。

我也是套用了这个avs，x264 crash，然后去掉down10里面的tvrange=false之后（默认是true）就一切正常了。输出的视频和片源相比肉眼看不出颜色错误（如果是直接AVISource+converttoyv12() 就是一眼的区别）

[littlepox]

需要dither 1.17.0或以上版本，需要AviSynth 2.6

[syntax lang="avisynth" lines="f"]__ANY_SOURCE_FILTER_FOR_RGB_INPUT__
Dither_Convert_RGB_TO_YUV(lsb=true, matrix="YCgCo", output="YV24", tv_range=false)
Down10(dither=-1, stack=false)[/syntax]
理論上完全無損，同時保持YUV colorspace的高壓縮效率
然後x264部分：

[syntax lang="winbatch" lines="f"]x264_10bit.exe [any other options] --output-csp "i444" --input-range "pc" --range "pc" --input-depth 10 --colormatrix "YCgCo" --output "output.mkv" "input.avs"[/syntax]

dither 用的是pcrange，down10默认用的是tvrange，为啥x264又换回pcrange？