既不是重影也不是错位
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得了…