https://bbs.popgo.org/bbs/read.php?tid=541499 https://www.nmm-hd.org/newbbs/viewtopic.php?t=999#p8725 做了decimate以后改变帧数了，可惜ConditionalFilter用不了 Edit: 刚刚又查了一遍TDecimate的readme，好像可以手动ovr，运用得当应该可以缩减一下trim的数量，我去试试 Edit2: 问题解决，果然是Trim太多的原因。 结合了RemapFrames和TDecimate的ovr代替了大部分不规律去重部分使用的Trim，行数缩减为原来的1/4，这次没有...

doom9看到有人提到写在不同avs里用import的方式，可以让avs在两个进程里运行。正在测试，不知会不会有效

经测试是无效的。
avs4x26x + x264_64_tMod-8bit-420
停在了同样的位置

最近在处理一个纪录片，做了Fields Match以后，发现有很多地方dup帧并不规律，所以花了几天时间尽我所能trim出来，接近240段Trim，按重复情况各自处理了，不过产生了另一个问题就是内存爆了。 源经过fields match以后是165512帧，我做完decimate以后是137835 第一次 avs4x26x + x264_64_tMod-8bit-420 停在81282帧 第二次 avs2yuv + x264_64_tMod-8bit-420 停在58654帧 第三次 x264_x86 停在77217帧 报错信息基本一致： avs [error]: GetFrameBuffer...

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

chroma的pattern我之前倒是看出来了，只不过之前用TDecimate试了几种方案，都没有成功分离bc和cd的blend，试了一下你提到的ExBlend，看起来完美分离了。

feisty2 写了：不知道lz 的问题解决没有 今天逛d9发现一个脚本可以自动解决这个问题 无线手动写ovr didee的脚本
完美解决的我的问题 lz可以试试

我刚刚试了下，用了以后不光chroma没好，luma原本很规则的24d也变的不规则了，而且部分细节也花了，咱们两个遇到的问题可能不一样。
不过不管怎样，还是谢谢你了。
后天还有考试，我等过几天有空了研究研究OVR的写法和手动decimate的pattern吧。谢谢啦

既不是重影也不是错位 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里...

manofman 写了：我不知道friends原幀速是多少，這只是估計。你sample是24fps的內容 + 30fps的幕後花絮。由於bluray不支持vfr，所以只有把24fps的部份也塞到30fps，規律應該是每4幀就塞1幀。

friends1080p的正片都是24的，这个30应该是做了变换的，我之前觉的chroma应该是在3:2pulldown组合后的帧内抹去拉丝产生的，再做场匹配也已经回不去了，所以来这里问一下。

manofman 写了：那些chroma應該是在塞之前就已經有，所以沒救的了。

不知道有没有人有方法能减轻这种chroma？看看其他人怎么说

feisty2 写了：我记得doom9里面有个什么DOCI是个和这个看上去相似的东西 但是我在我的源上测试这个失败了 不仅没有解决问题还产生了新的问题...
lz可以试试DOCI 可能有用

搜到了你的那个chroma ghosting的帖子了
我再去翻翻其他相关的

manofman 写了：你這個不是原盤文件，是已經被處理過的文件

我把原盘的00212.m2ts送到mmg里面切了15秒的片段，虽然封成mkv的了，画面应该还是原盘的画面 还是说，你认为原盘发行之前对这个视频做了处理

刚刚看了一下，同帧里奇数场和偶数场是一致的，要有错位，都有错位，要没错位都没错位。跟帧的规律是一样的
5帧里面有连续2帧，10场里面有连续4场