分页: 2 / 2

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-04 11:19
06_taro
既不是重影也不是错位
StackHorizontal(ConvertToY8, StackVertical(UtoY8, VtoY8))
直接看就明白了,Y/U/V三个平面的帧没有对应,譬如说Y的帧序是0 1 2 3 4 5的话,UV是-1 0 2 3 5 5这样就会出现了,可以随便找个视频用MergeChroma(Loop(0, 0, -1).Loop(2, framecount-1, -1))重现出类似的现象…只不过这里不是简单的单向错位没法直接简单地移回去…

首先这个mkv肯定不是DVD源,您在主楼里说有DVD,但传上来的这个要么是已经别的非官方encoder处理过的东西,要么是BD里的东西,不知道您是不是指官方拿DVD做成BD,反正先找官方的DVD/BD都来看看有没有没问题的,如果有没问题的版本的话直接拿那个来做;
如果官方DVD/BD原盘都是这样,那就只能麻烦点了。看Y平面是24p dup到30p(以下简称24d),按照Y来做decimate,然后U和V手动decimate,使得结果和Y相匹配即可:[syntax lang="avisynth"]YToUV( UToY.TDecimate(ovr="U-ovr.txt", chroma=False),
\ VToY.TDecimate(ovr="V-ovr.txt", chroma=False),
\ TDecimate(chroma=False) )[/syntax]没仔细看U和V之间是否完全同步,这里使用最保险的做法;否则如果UV完全同步的话直接TDecimate(chroma=False).MergeChroma(TDecimate(ovr="chroma-ovr.txt"))手动deci一个chroma就行了。

当然这里还有另一个问题,只看chroma的话这片子其实是24d/30p的hybrid,而luma是24d,出现不同步的帧其实都是在chroma 30p的地方,dup的Y和含motion的UV不匹配。我不知道是不是官方或者之前的encoder在某些scene里强行把30p的luma给deci到24p,然后再dup回24d的(包括对24d的chroma部分也有这种怀疑)。如果是这样的话,足够蛋疼的做法是把24d的luma以及24d部分的chroma在deci成24p之后插补出中间丢掉的帧,再和30p的chroma合成,当然插补帧效果不会有原生的好了。否则就用上面的做法按现在的luma统一做成24p得了…

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-04 12:31
feisty2
taro大可以帮忙看看这是怎么回事吗? 我按照上面的方法操作没有效果啊
这是从vob上截的一点点TFM以后的样品 http://pan.baidu.com/share/link?shareid ... =370037491
感觉UV里面只有一个和Y不同步 不清楚是哪一个
所以 YToUV( UToY.TDecimate(ovr="ovr.txt",chroma=False),
\ VToY.TDecimate(chroma=False),
\ TDecimate(chroma=False) )
YToUV( UToY.TDecimate(chroma=False),
\ VToY.TDecimate(ovr="ovr.txt",chroma=False),
\ TDecimate(chroma=False) )
都尝试了 都没有解决问题
这是这一小段样品的chroma ovr
0,22 ++-++

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-04 18:25
buaaqlyj
06_taro 写了:既不是重影也不是错位
StackHorizontal(ConvertToY8, StackVertical(UtoY8, VtoY8))
直接看就明白了,Y/U/V三个平面的帧没有对应,譬如说Y的帧序是0 1 2 3 4 5的话,UV是-1 0 2 3 5 5这样就会出现了,可以随便找个视频用MergeChroma(Loop(0, 0, -1).Loop(2, framecount-1, -1))重现出类似的现象…只不过这里不是简单的单向错位没法直接简单地移回去…

首先这个mkv肯定不是DVD源,您在主楼里说有DVD,但传上来的这个要么是已经别的非官方encoder处理过的东西,要么是BD里的东西,不知道您是不是指官方拿DVD做成BD,反正先找官方的DVD/BD都来看看有没有没问题的,如果有没问题的版本的话直接拿那个来做;
如果官方DVD/BD原盘都是这样,那就只能麻烦点了。看Y平面是24p dup到30p(以下简称24d),按照Y来做decimate,然后U和V手动decimate,使得结果和Y相匹配即可:[syntax lang="avisynth"]YToUV( UToY.TDecimate(ovr="U-ovr.txt", chroma=False),
\ VToY.TDecimate(ovr="V-ovr.txt", chroma=False),
\ TDecimate(chroma=False) )[/syntax]没仔细看U和V之间是否完全同步,这里使用最保险的做法;否则如果UV完全同步的话直接TDecimate(chroma=False).MergeChroma(TDecimate(ovr="chroma-ovr.txt"))手动deci一个chroma就行了。

当然这里还有另一个问题,只看chroma的话这片子其实是24d/30p的hybrid,而luma是24d,出现不同步的帧其实都是在chroma 30p的地方,dup的Y和含motion的UV不匹配。我不知道是不是官方或者之前的encoder在某些scene里强行把30p的luma给deci到24p,然后再dup回24d的(包括对24d的chroma部分也有这种怀疑)。如果是这样的话,足够蛋疼的做法是把24d的luma以及24d部分的chroma在deci成24p之后插补出中间丢掉的帧,再和30p的chroma合成,当然插补帧效果不会有原生的好了。否则就用上面的做法按现在的luma统一做成24p得了…

很详细啊。谢谢taro大,我一会儿试试看 {:cat_17}

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-05 17:06
feisty2
不知道lz 的问题解决没有 今天逛d9发现一个脚本可以自动解决这个问题 无线手动写ovr didee的脚本
xxxsource
o=last

a1 = o.TFM(chroma=false).greyscale()
a2 = a1.trim(1,0)

fixed = o.blur(0,1).FixBlendIVTC()

x0 = fixed.mt_lut("0")
x1 = mt_lutxy(a1,fixed,"x y - abs 2 *")
x2 = mt_lutxy(a2,fixed,"x y - abs 2 *")
x1 = mt_lutf(x1,x1,mode="average",expr="x")
x2 = mt_lutf(x2,x2,mode="average",expr="x")

fixed.greyscale()
corrector(x0,last,x1,x2,a1,a2,mode=1,th=255).mergechroma(fixed)
tdecimate()

return(last)

完美解决的我的问题 lz可以试试

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-05 19:29
buaaqlyj
feisty2 写了:不知道lz 的问题解决没有 今天逛d9发现一个脚本可以自动解决这个问题 无线手动写ovr didee的脚本
完美解决的我的问题 lz可以试试
我刚刚试了下,用了以后不光chroma没好,luma原本很规则的24d也变的不规则了,而且部分细节也花了,咱们两个遇到的问题可能不一样。
不过不管怎样,还是谢谢你了。 {:cat_17}
后天还有考试,我等过几天有空了研究研究OVR的写法和手动decimate的pattern吧。谢谢啦 {:cat_16}

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-06 15:36
lwppkn
StackHorizontal(ConvertToY8, StackVertical(UtoY8, VtoY8))看了一下

看起来luma是24d/30p的hybrid,其中30p的部分不知道怎么回事

luma为24d的部分,luma是A B C D D的话,对应的chroma是A B bc cd D(中间两帧大概带着交错做了什么处理)
试了一下ExBlend(要2pass)

1pass:
[syntax lang="avisynth"]
AVCSource("...\00212_track1_eng.dga").Trim(210,436)
UToY().ExBlend(mode=1)[/syntax]

2pass:
[syntax lang="avisynth"]
AVCSource("...\00212_track1_eng.dga").Trim(210,436)

# A B bc cd D --> A B C' D D
MergeChroma(ExBlend(mode=2, decimate=false, DISP=2, CompUB=0))

#删重复帧
ExBlend(mode=2, decimate=true, DISP=0, CompUB=0)

#对unblend出来的C'进行后处理
pp=ClipClop(MCDegrain(3), Cmd="ExBlend_Decimated.TXT")
MergeChroma(pp)[/syntax]
2pass000046.png

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-06 23:14
buaaqlyj
lwppkn 写了: luma为24d的部分,luma是A B C D D的话,对应的chroma是A B bc cd D(中间两帧大概带着交错做了什么处理)
试了一下ExBlend(要2pass)
chroma的pattern我之前倒是看出来了,只不过之前用TDecimate试了几种方案,都没有成功分离bc和cd的blend,试了一下你提到的ExBlend,看起来完美分离了。 {:cat_16}

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-06 23:50
06_taro
feisty2 写了:不知道lz 的问题解决没有 今天逛d9发现一个脚本可以自动解决这个问题 无线手动写ovr didee的脚本
xxxsource
o=last

a1 = o.TFM(chroma=false).greyscale()
a2 = a1.trim(1,0)

fixed = o.blur(0,1).FixBlendIVTC()

x0 = fixed.mt_lut("0")
x1 = mt_lutxy(a1,fixed,"x y - abs 2 *")
x2 = mt_lutxy(a2,fixed,"x y - abs 2 *")
x1 = mt_lutf(x1,x1,mode="average",expr="x")
x2 = mt_lutf(x2,x2,mode="average",expr="x")

fixed.greyscale()
corrector(x0,last,x1,x2,a1,a2,mode=1,th=255).mergechroma(fixed)
tdecimate()

return(last)

完美解决的我的问题 lz可以试试
暫時沒法下載,不過看這裡的解決方法,如果有效的話應該和樓主不是同樣問題。LZ是yuv三個平面不是同一幀,但是並沒有在一個平面內出現幀間串擾(少數有渣deint/錯誤fm的畫面不算,至少也不是blend),所以分別找匹配的幀重新組合,在24p部分應該是可以無損解決的,相當於你手裡有一張黑桃A一張紅桃2,我手裡有一張方塊A和一張梅花2,我們交換一下牌就可以還原回成對的牌;而blend是指你我手裡的牌都是被劣質打印機把完全不同的牌面印在同一張牌上產生的,無論我們怎麼交換都不可能變成正確的,而只能通過分析猜測出每張牌應該是什麼樣子,然後重新打印出來。估計您應該重新開個帖子解決那個問題。

不過exblend確實是個很有意思的東西,根據分析結果找原始處於那個位置的幀,這個方法也許對lz的也有一定幫助。就算沒100%準確也至少給ovr提供便利了吧。反正遇到這種視頻肯定要從頭到尾檢查的,ovr也不麻煩。

至於說ovr沒用,首先如前文所說這是針對lz這種直接重新組合就可以搞定的東西,如果是單平面內幀間blend的情況那肯定不行的。另一方面這裡tdecimate的ovr不再是為了去除dup幀,而是為了找到和每個luma對應的chroma幀並按相同次序組合,前面那個ovr文件的內容起始就是有問題的。

Re: 【小白求助】这是什么artifacts?

发表于 : 2013-01-07 10:27
feisty2
taro大能从原理上解答不胜感激 小白现在还是avs的初学者 遇到问题还都只能靠其他人写好的脚本/滤镜解决 目前还不具备自己独立解决问题的能力 遇到表象上相似的问题难免会弄混
ovr的问题我是按同步的想法来尝试的 先不知道是blend问题 以为是chroma与luma不同步的时候 发现每5帧开始正好从第3帧开始chroma错位了 这一帧的chroma成了后一帧的chroma 2 3帧的chroma正好相同 那把2帧的chroma去掉应该这个循环正好对其了 结果因为没搞清楚问题的原由 以失败告终