huhuyaya
帖子: 24
注册时间: 2011-05-26 18:58

关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

见norm team压制的live亮度效果非常好,感觉是不是在压制前做过 luma upsampling之类的 亮度强化,

感觉在做锐化部分~luma比chroma重要。是否有方法可以加强亮度区域~专门针对亮度进行强化

刚尝试10bit rip的一个live在crf 18量化后明显的色泽差了大截而且整个live有点光亮度降低不少错觉,(量化前做足锐化出了遍sourcecopy,相比量化前的差别)

向各位求教有没有方法强化亮度使得量化后亮度变弱不这么明显? 额至少感官上不会时不时有种这幅图是vcd画质的感觉. 压制组是用什么方法使得演唱会氛围保存的完好而且抹去不必要细节后出片的码率也很低?
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

[syntax lang="avisynth"]
MP_Pipeline("""

### platform: win32

XXXSource("xxx.xxx")

### prefetch: 32, 16
### ###

### platform: win32

SetMemoryMax(1536)

src = last
nr = src.MCTD(settings="low", radius=3, sigma=4, limit=-1, limit2=0, chroma=true, twopass=false, useTTmpSm=false, GPU=true, fixband=true, pp=true, useMMask=false, protect=true, deblock=false, useQED=true, sharp=false, enhance=false)

nr.Repair(src, 3, 3)

### prefetch: 16, 0
### ###

SetMemoryMax(768)

MCTD_PP(settings="low", useMMask=false, AA=false, edgeclean=false, sharp=false, stabilize=false, enhance=true, dbF="GradFun3( smode=2, thr=0.25, elast=2.5, ampn=0, radius=14, lsb=true, lsb_in=false, mask=0 )")

#降为720p输出去掉#
#Dither_y_gamma_to_linear(curve="709").Dither_reszie16(1280, 720).Dither_y_linear_to_gamma(curve="709")

#设置输出位深
output_depth = 10

output_depth == 8 ? DitherPost(mode=6) : Down10(output_depth, stack=false)

""")
[/syntax]
不嫌慢的话Live这样搞一下就差不多了,如果源是有交错的再在SourceFilter之后加上deint之类的步骤。
如果用10bit版x264的话参数里加上--input-depth 10。
如果用8bit版x264的话最后设为output_depth = 8。
上次由 mawen1250 在 2012-06-21 0:23,总共编辑 10 次。
头像
rshadow
帖子: 57
注册时间: 2011-03-23 10:18
联系: ICQ

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

mawen1250 写了:

代码: 全选

MCTD(settings="medium",sigma=0,limit=4,chroma=true,GPU=false,fixband=false,sharp=true,strength=80,protect=true,AA=false,deblock=true,useQED=true,edgeclean=false,stabilize=false,enhance=false)
f3kdb(range=15,Y=40,Cb=36,Cr=36,ditherY=0,ditherC=0,output_mode=2,output_depth=10)
不嫌慢的话Live这样搞一下就差不多了,如果源是隔行编码的逐行视频,最前面再加上一个Vinverse(amnt=1)。
x264里加上--input-depth 10
{:cat_18} 插楼一下,“隔行编码的逐行视频”谷歌查了下还是翻不到什么有效信息。隔行和逐行不是对立的吗?实在理解不能,求解答

还想请问下:
在f3kdb使用output_depth=10,再x264加上--input-depth 10
和不使用output_depth=10,直接输入8bit源到x264中(如x264_tmod_10bit)有区别吗?
此外好像还经常见到现在avs中dither到16bit的做法……不知道好处在哪呢
huhuyaya
帖子: 24
注册时间: 2011-05-26 18:58

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

rshadow 写了:
mawen1250 写了:

代码: 全选

MCTD(settings="medium",sigma=0,limit=4,chroma=true,GPU=false,fixband=false,sharp=true,strength=80,protect=true,AA=false,deblock=true,useQED=true,edgeclean=false,stabilize=false,enhance=false)
f3kdb(range=15,Y=40,Cb=36,Cr=36,ditherY=0,ditherC=0,output_mode=2,output_depth=10)
不嫌慢的话Live这样搞一下就差不多了,如果源是隔行编码的逐行视频,最前面再加上一个Vinverse(amnt=1)。
x264里加上--input-depth 10
{:cat_18} 插楼一下,“隔行编码的逐行视频”谷歌查了下还是翻不到什么有效信息。隔行和逐行不是对立的吗?实在理解不能,求解答

还想请问下:
在f3kdb使用output_depth=10,再x264加上--input-depth 10
和不使用output_depth=10,直接输入8bit源到x264中(如x264_tmod_10bit)有区别吗?
此外好像还经常见到现在avs中dither到16bit的做法……不知道好处在哪呢

额,这两个问题我是这样理解的:
rshadow 大大和mawen1250大大说的隔行编码的逐行视频 是不是指的 TV的隔行抽线显示的progressive 视频

f3kdb输出16位色深的目的是有一个更高精度的去除了banding的源,8bit的本身一量化就容易出banding~
不知道理解的是否正确,求大大们指正
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

隔行编码就是将视频按隔行方式编码(MBAFF或PAFF),但里面的视频却可以有各种各样的,可以是标准的隔行扫描视频30i,也可以是24p通过Telecine转成的24t,也可以是30p的视频按场来编码(通常这种情况下正片是无交错的25p/30p,但片尾Credits之类的是25i/30i,如各种演唱会、BBC的纪录片之类的),还有就是各种类型的hybrid(比如AIR BD这种正片24t,OP、ED 30p,fade场景30i,还有各种各样的BD特典、DVD特典经常能看到各种奇葩的东西)。除此之外还有缟缟upconv、重复场、25p转30i之类的各种脑残的奇葩交错形式。

f3kdb内部使用16bit精度进行处理,然后dither成10bit交给10bit的x264编码当然比dither成8bit交给10bit的x264编码要好,这种道理我觉得都无需解释。

for example
1.原始8bit数据(0-255):
61 61 63
61 63 63
61 63 63
转成16bit(0-65535):
15616 15616 16128
15616 16128 16128
15616 16128 16128
2.做debanding(数字为大概估计):
15616 15840 15984
15744 15904 16064
15840 15984 16128
3.直接转成10bit(0-1023)
244 247 250
246 249 251
247 250 252
4.先转成8bit
61 62 62
61 62 63
62 62 63
再转成10bit
244 248 248
244 248 252
248 248 252

以上由高位深转低位深过程均为rounding(可以理解为四舍五入),实际过程中通常使用dither方式减少降位深的损失,代价就是数据更难压缩,所以dither成8bit再编码成10bit,相比于直接dither成10bit不但效果略差,理论上还需要更高码率。
huhuyaya
帖子: 24
注册时间: 2011-05-26 18:58

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

mawen1250 写了:隔行编码就是将视频按隔行方式编码(MBAFF或PAFF),但里面的视频却可以有各种各样的,可以是标准的隔行扫描视频30i,也可以是24p通过Telecine转成的24t,也可以是30p的视频按场来编码(通常这种......
谢谢~ 思路又清晰了不少
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

huhuyaya 写了:感觉在做锐化部分~luma比chroma重要。是否有方法可以加强亮度区域~专门针对亮度进行强化
不知道到底是說銳化還是改亮度,我就當銳化好了

[syntax lang="avisynth" lines="f"]Sharpen(0.4).MergeChroma(last)[/syntax]
完了。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

mawen1250 写了:所以dither成8bit再编码成10bit,相比于直接dither成10bit不但效果略差,理论上还需要更高码率。
我相信這句話裡,“效果略差”肯定沒有自己確認過,至少壓之前肯定沒有用不dither回8bit的方法預覽過dither成10bit的效果,就當純理論的認定好了……“還需要更高碼率”則更像是口胡了。dither成8bit後x264內shift時兩位lsb的熵為0,dither成10bit後兩位lsb熵則不為0,只看lsb的話顯然是dither成8bit更容易壓縮。當然實際壓縮要看整個10位的情況,也許dither到8bit比dither到10bit時的msb部分信息量更大。不過如果“效果略差”是正確的話,dither到10bit時全部10位的信息量肯定要比dither到8bit時再shift的全10位信息量更大,哪個需要更高碼率則一目了然。所以這句話前後兩部分必然有一個是錯的……

個人而言,如果dither到8bit來預覽時覺得沒問題的話,說明這個時候dither到8bit的效果是可以接受的,而且是經過預覽確認不會有任何問題的。這樣的話我寧可保留dither到8bit的結果來壓,一來效果已經確認過可以接受,二來lsb是直接shift 0時碼率應該更小(實際上madshi在闡述pc range的8->10方式時有很具體的說明,將8bit shift 0需要的碼率顯然比同樣的數據升到16bit再dither回10bit要小,這個過程其實和16bit直接dither回8bit再shift到10bit/將16bit直接dither回10bit的差別類似),而使用10bit編碼的目的僅僅是用更小的碼率來更好地保留dither到8bit的效果而已。相比之下,冒著沒有確認過實際效果如何的風險,還需要更高碼率的dither到10bit,私以為未必值得……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
mawen1250
核心会员
核心会员
帖子: 670
注册时间: 2011-07-24 20:33

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

于是测试数据更新,使用了--tune ssim,上图为1/(1-SSIM),下图为PSNR。我由此得出的结论是10bit输出的编码效率更高。至于效果什么的,还是得靠眼睛来收货,拿10bit编码后的结果再dither并转换成8bit RGB,与16bit的源数据dither并转换成8bit RGB做SSIM比较我觉得难以办到并且有N种实现方式,每种方式结果也会不同,也难以保证公平比较,而且实际意义也不如主观比较强。
test2-1.png
test2-2.png
AVS

代码: 全选

sourcefilter

f3kdb(range=15, Y=42, Cb=36, Cr=36, ditherY=0, ditherC=0, precision_mode=3, dynamic_dither_noise=true, keep_tv_range=false, input_mode=0, output_mode=0, output_depth=8)
或
f3kdb(range=15, Y=42, Cb=36, Cr=36, ditherY=0, ditherC=0, precision_mode=3, dynamic_dither_noise=true, keep_tv_range=false, input_mode=0, output_mode=2, output_depth=10)
Trim(0,1599)
x264 info

代码: 全选

x264 [info]: profile High 10, level 4.0, 4:2:0 10-bit
x264 [info]: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=6 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=3 b_pyramid=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=16.0/18.0/20.0 qcomp=0.60 qpmin=0 qpmax=81 qpstep=4 ip_ratio=1.40 aq=2:1.00
上次由 mawen1250 在 2012-02-26 13:18,总共编辑 4 次。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: 关于live的处理_请教_luma和chroma分别处理,也愿此能给大家帮助

比ssim不用--tune ssim,還開著psy-rd這種本來就會對dither有很大的psy影響的參數

ssim是編碼前後的比較,二者編碼前的數據都不一樣,拿A:B和C:D來比較

x264內部是Sierra-2-4A error diffusion,f3kdb內部是Floyd-Steinberg error diffusion,做subjective comparison都沒給出sample size
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

回到 “视频编码器 / Video encoder discussion”