TIVTC的自动交错帧记录与手动OVR脚本

dgwxx

上次在这篇帖子里提到了ovr的利用，今天来详细写写。

好长时间没码字了，那么今天就来写一个可能很多高手都会解决的问题，那就是利用TIVTC的自动记录交错与手动OVR脚本来手动指定Post-processing的动作。
在IVTC过程中，一部分帧会走PP，也就是被送去Deinterlace。但是这部分帧当中，有一部分是因为匹配失败而被PP（确实找不到合适的场匹配结果），有一部分是匹配成功但被误判为交错送去PP，而通常情况下只有较少的一部分帧是真正因为无法找到合适的匹配而出现交错的（也就是第一种情况）。

TIVTC的匹配精度很高，绝大多数情况下不会出现错匹配的情况（但是我也遇到过极少数例外的情况发生，需要通过ovr手动指定匹配pattern，这个下次有时间再写）。
TIVTC的问题在于，他的默认参数比较灵敏，在后处理检测时微小的交错也能察觉出来，因此容易造成误判，特别是动画OP/ED中的字幕，经过PP之后，文字不断抖动，非常难看。而那些参数又非常难以调整，常常是这边调好了，那边又坏掉了。虽然通过OVR也可以单独分段指定参数，但我还是建议使用默认参数，最后通过OVR来针对出错的帧进行修正。
因此，我们就需要结合TIVTC的记录输出功能和OVR手写脚本功能来“强制”TIVTC对我们指定的帧进行PP或者不进行PP。

我们首先要找出哪些帧出了问题。之前我注意到，不少同学还在使用我好多年前用ConditionalFilter + decomb写的那个交错侦测脚本，其实现在TIVTC里面已经内置了相当丰富的交错侦测功能，独立函数ShowCombedTIVTC和IsCombedTIVTC在调试TFM的cthresh、 MI、 chroma、 blockx、 blocky、 metric等参数方面很好用，也可以结合ConditionalFilter写出来交错侦测的脚本，但我们今天要用的是TFM内置的output参数来输出log文件。
首先，我们需要构建出来一个avs脚本，让tfm输出log文件。这个过程相当于IVTC过程的1pass，我们不需要通过这个脚本输出成品，因此要让这个脚本高速地执行，快速得到我们要得log文件。

1. 
   
2. 1pass.avs:
   
3. d2v = "op.d2v"
   
4. MPEG2Source(d2v)
   
5. tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true, output="log.txt")
   
6. crop(8,8,16,16)
   

复制代码

各个参数的目的是在保证检测精度的情况下尽量提高速度。
log.txt就是我们要输出的log文件。我们可以用VDM打开这个avs，然后通过Direct Stream Copy模式输出为.avi（它在我的E8400 CPU上跑出了150fps）。完成之后，.avi可以直接删除，留下log.txt供我们分析。
（注意，请不要用MeGUI去压这个脚本，用MeGUI压制的话tfm之会输出一个空文件，而得不到我们要的log。更不要试图修改log文件，因为之后载入log文件的时候，tfm会检测log文件是否发生过改变。）
压制结束之后，我们会得到一个不小的文件，他包含了tfm对每一帧的处理方式、判断结果。但我们真正需要的是这个文件尾部以#号开头的那一段。
一段典型的该部分log会像下面一样（中文部分是我的注释）：

1. 
   
2. #
   
3. #
   
4. # OVR HELP INFORMATION:
   
5. #
   
6. # [COMBED FRAMES]
   
7. #以下是被判断为交错、需要走PP的帧。前面是帧号，后面是该帧的交错度。
   
8. #
   
9. #   [Individual Frames]
   
10. #   FORMAT:  frame_number (mic_value)
    
11. #
    
12. #   1544 (256)
    
13. #   1545 (256)
    
14. #   1546 (256)
    
15. #   1547 (87)
    
16. #   1548 (108)
    
17. #   1563 (82)
    
18. #   1566 (92)
    
19. #   1569 (99)
    
20. #   1570 (99)
    
21. #   1571 (95)
    
22. #   1572 (110)
    
23. #   1578 (256)
    
24. #   1579 (256)
    
25. #   1613 (256)
    
26. #   1614 (256)
    
27. #   2184 (170)
    
28. #
    
29. #   [Grouped Ranges Allowing Small Breaks]
    
30. #   FORMAT:  frame_start, frame_end (percentage combed)
    
31. #这部分是被判断为微动或者bad cut渐变等连续交错的地方，同样应该留意
    
32. #
    
33. #   1544,1548 (100.0%)
    
34. #   1563,1579 (47.1%)
    
35. #   1613,1614 (100.0%)
    
36. #
    
37. #
    
38. # [POSSIBLE MISSED COMBED FRAMES]
    
39. #下面是tfm觉得交错程度较大，被判断为可能交错的帧，但因为不够阈值设定的值，因此不会走PP，仅提供用户肉眼确认、参考。
    
40. #
    
41. #   FORMAT:  frame_number (mic_value)
    
42. #
    
43. #   455 (17)
    
44. #   470 (16)
    
45. #   950 (40)
    
46. #   1559 (76)
    
47. #   1560 (76)
    
48. #   1564 (75)
    
49. #   1565 (75)
    
50. #   1567 (74)
    
51. #   1568 (74)
    
52. #   1576 (69)
    
53. #   1577 (65)
    
54. #   1620 (72)
    
55. #   1621 (72)
    
56. #   1623 (73)
    
57. #   1624 (73)
    
58. #   1625 (78)
    
59. #   1626 (70)
    
60. #   1627 (71)
    
61. #   1631 (69)
    
62. #   2177 (20)
    
63. #   2182 (19)
    
64. #   2187 (42)
    
65. #   2192 (58)
    
66. #
    
67. #
    
68. # [u, b, AND AGAINST ORDER (n) MATCHES]
    
69. #使用了u、b、n这三种匹配方式，得到了“无交错匹配”的帧。为什么说“无交错匹配”而非“正确匹配”呢，因为DVD在制作中可能存在一些bad cut或者Telecine制作错误，u、b、n这三种匹配方式通常可以有更大的几率获得无交错的帧，但是也有可能造成画面一顿一顿的（恰好匹配到了和上一帧或下一帧相同的画面），因此tfm也认为这些帧需要肉眼确认。如果确认发生了jerkness，用户可以通过ovr来选择是输出无交错的帧好，还是通过pp输出一个模糊一些但保持动态的帧好。但这并非本文讨论话题，所以只略微提及一下，详细的……等有时间再写吧。
    
70. #
    
71. #   FORMAT:  frame_number match  or  range_start,range_end match
    
72. #
    
73. #   319 u
    
74. #   347 u
    
75. #   387 u
    
76. #   428 u
    
77. #   730 u
    
78. #   826 u
    
79. #   920 u
    
80. #   948 u
    
81. #   1511 u
    
82. #   1580 u
    
83. #   1615 u
    

复制代码

我又写了一个脚本来逐帧确认交错情况。

1. 
   
2. check.avs:
   
3. d2v = "op.d2v"
   
4. MPEG2Source(d2v)
   
5. tfm(d2v=d2v, mode=3, pp=1, slow=2, chroma=true)
   

复制代码

用vdm或者au打开它，跳到[COMBED FRAMES]这段log中提到的帧，逐帧检查，并最终确认1544、1545、1546、1578、1579、1613、1614真正存在交错，其余全部是误判。现在，只需要用记事本写一个文件，告诉tfm其余帧是清白的即可（将误判为交错的帧用-号标记，强制tfm将这些帧直接输出）。
当然，如果你愿意，也可以检查[POSSIBLE MISSED COMBED FRAMES]里面记录的帧的情况，这部分帧被认为是可能存在交错的帧，输出时，这些帧会被当作好帧直接输出。如果这部分帧中真的存在交错，应该在ovr文件中用+号标记。

1. 
   
2. ovr.txt:
   
3. 1547 -
   
4. 1548 -
   
5. 1563 -
   
6. 1566 -
   
7. 1569 -
   
8. 1570 -
   
9. 1571 -
   
10. 1572 -
    
11. 2184 -
    

复制代码

之后我们通过tfm载入之前的log和ovr文件，并引入PP、decimate。

1. 
   
2. MPEG2Source(d2v)
   
3. tfm(d2v=d2v, mode=3, pp=4, slow=2, chroma=true, input="log.txt", ovr="ovr.txt")
   
4. tdecimate(mode=1)
   

复制代码

这里说明一下，通过input载入之前的log文件可以提高tfm的速度，因为tfm直接从log文件中读取之前做过的计算结果，可以不用再次进行匹配了。而input（也就是tfm自己的计算结果）和ovr文件中指定的策略、参数冲突的时候，ovr的优先权高。

虽然这种工作对于OP/ED来说比较繁重，但是这样通常能够得到更完美的效果。

后记：
TFM的ovr功能超级丰富，几乎可以匹敌手动IVTC的效果。而配合output参数，我们可以用更高的效率来得到更好的结果。
关于p、c、n、b、u等匹配方式，以及通过ovr来指定pattern其实也不是很困难，tfm的readme里面都有很详细的说明。有时间的同学不妨阅读一下。

diseac

谢谢Dgwxx为我们写了这么一篇精彩的文章，我又学到了不少东西。
我想再补充一些详细的东西，如果看这篇帖子的人不能明白我说的是什么，请先完全读过Dgwxx的帖子再往下看。

首先来说一下TIVTC的5种场匹配手段：
p 向上一帧匹配
c 向当前帧匹配（用当前帧作为匹配后的帧）
n 向下一帧匹配
b 用另一场向上一帧匹配
u 用另一场向下一帧匹配

有时候TIVTC遗漏交错，并不是匹配的问题，而是默认参数下，TIVTC并没有完全使用这5种手段去进行匹配。
这5种手段，我们可以在ovr里去指定，当然，也可以让TIVTC自己去判断。
为了说的详细些，下面请看TIVTC的8种运行模式：

mode=0，进行p/c匹配。
mode=1，进行p/c匹配，如交错，则承认n匹配。
mode=2，进行p/c匹配，如交错，则承认u匹配。
mode=3，进行p/c匹配，如交错则进行n匹配，如再交错则进行u/b匹配并承认u/b匹配。
mode=4，进行p/c/n匹配。
mode=5，进行p/c/n匹配，如交错则进行u/b匹配并承认u/b匹配。
mode=6，进行p/c匹配，如交错，则进行u匹配，再交错进行n匹配，再交错进行b匹配并且承认b匹配。
mode=7，进行p/c匹配，并且参照前面做过的帧，需要线性编辑。

大家从上面8种模式可以看到，只有3、5、6这三种模式使用了pcnbu全部的五种手段来做。
即使是在3、5、6中，b/u匹配只会在场景转换时进行（TIVTC有一个侦测场景转换的模块）。
因为在很多情况下，片源在经过了 pull down 以后，才会进行剪辑，这样在场景切换时就可能出现错误，匹配的情况就会比较复杂。
但有时候，在非场景切换时，我们也需要b/u匹配。
还有的时候，TIVTC误判场景切换，误用b/u匹配。
如果你需要让TIVTC将b/u匹配应用到全部帧的话，这样设置：ubsco=false（mode=3/5/6有效）

然后请大家再看一下TIVTC的2种检测方式：
1、小区块检测：根据metric参数设定的公式对blockx*blocky区块内的象素进行计算，如大于MI值则交错。当帧内所有的小区块中有一个被检测为交错，则承认当前帧为交错帧。
2、全帧检测：将整个帧作为一个区块进行检测，方法同上。

想必大家一眼就能看出来，小区块检测要用在场景切换时候，这样比较精确。实际上TIVTC就是这样做的，如果你想为全部帧应用小区块检测，这样设置：mmsco=false

接下来说点麻烦的情况吧。

首先我们来看看TIVTC的设计思路，这里我以mode=5为例来讲述一下TIVTC的处理流程。
1、将用户给出的cthresh值代入公式，分别计算p/c/n的值。
2、以优先c为前提，比较MI值，采用MI值最小的匹配。
3、如果p/c/n的MI值全部大于80（默认MI值），进行u/b匹配。
4、将用户给出的cthresh值代入公式，分别计算u/b的值。
5、比较u/b的MI值，采用MI值最小的匹配并且输出匹配结果。
6、后处理：将用户给出的cthresh值代入公式计算，检查匹配过的帧是否交错。（如PP=0则放弃从此开始的操作）
7、如匹配后的帧为交错，则进行后处理，将帧交给PP或clip2参数指定的函数。
8、检查用户给出的PP值。PP=1：只检测但不做后处理；PP=2/3/4：将交错帧送去后处理；PP=5/6/7：将交错帧内的运动象素送去后处理。
9、承认后处理结果，输出后处理后的帧。

这样就比较让人头疼了，TIVTC只有1个cthresh值，cthresh既会影响场匹配，也会影响后处理。
也就是说，你的cthresh值定下来就不能再改，否则后处理检测精度上去了，场匹配可能又错了。
那么，接下来让我们来看看TIVTC会犯错的情况，以及出现错误的原因。

1、场匹配本应为c，但误判c为交错，进行了p，导致匹配后反而交错。（这种情况最恶心，但有时候不太容易察觉，所以容易被忽略）
2、场匹配本应为p，但误判c为非交错，进行了c，导致匹配失败。
3、场匹配本应为c，但误判c为交错，又误判了场景切换，进行了u，导致匹配后反而交错。（恶心程度同1）
4、场匹配已经正确，但后处理时误判为交错，导致正确的帧被送去deinterlace。（这种情况的正确场匹配完全是碰上的，因为cthresh值只有一个，常出现于文字部分）
5、场匹配失败，但后处理时误判为非交错，没有进行后处理，导致交错遗留。（常出现于渐变部分）

其实还有很多让人头疼的情况，这里就不再多例举了。
总之，面对 Bad Edit ，再强大的场匹配功能也会显得很脆弱。
所以我们只好自己手动写ovr来帮助TIVTC去判断，ovr的写法dgwxx已经说的很详细，我再简单补充一下。

ovr的写法：帧号 空格 参数
1000 p  对第1000帧使用p方式匹配
1000 c  同上，c方式
1000 b  同上，b方式
1000 u  同上，u方式
1000 n  同上，n方式
1000,2000 cccpp 对第1000到2000帧使用cccpp的顺序进行匹配
1000 + 第1000帧是交错帧
1000 -  同上，非交错
1000,2000 ---++  对第1000到2000帧使用---++的顺序进行交错判断
1000 f 1 设置第1000帧的field参数为1
1000 o 1  设置第1000帧的order参数为1
1000 m q 设置第1000帧的mode参数为1
1000 M 5 设置第1000帧的mthresh参数为5，注意这里M大写
1000 P 2  设置第1000帧的PP参数为2，注意这里P大写
1000 i 80 设置第1000帧的MI参数为80
1000,2000 f 1 设置第1000到2000帧的field参数为1
;1000 + 前面加分号使这句不生效
#你是猪！ 注释

以上是一些对dgwxx的补充，以及一些我自己关于场匹配方面的经验，希望对大家有帮助，如果你看出了问题，请不吝赐教，帮助我改正错误。

下面的蓝字不是本帖的讨论主题，如果你有兴趣的话请看下去。

如果片子做的不错的话，我们可以手写ovr，但面对 Bad Edit ，这样做显然太累了。

cthresh值只有一个，场匹配和后处理有时候很难兼顾。ubsco/mmsco到底开不开？拆东墙补西墙的情况经常发生。东边不亮西边亮时，把TIVTC的参数调整一遍，有时候你会发现东边亮了，西边不亮了。

所以，我和Dgwxx的观点有些不同，我认为TIVTC的场匹配成功率不是很高。

TIVTC有强大的后处理，ovr，debug参考，屏幕显示，日志输出。但是有时候我不得不舍弃这些。

面对 Bad Edit ，我的处理方式是要使场匹配成功率尽量最高，避免将progressive反弄成interlace，避免jerkness。

下面这2段代码是我面对 Bad Edit 时的处理方式，供大家参考。

1. 
   
2. # 极限方式：（可以保证匹配正确率最高，并且一根拉丝都没有，但是画面模糊）
   
3. DoubleWeave.a60224().AssumeTFF
   
4. TDeint(mode=2,order=1,field=1,mthreshL=0,mthreshC=0,cthresh=65535,
   
5. \edeint=separatefields.EEDI2(field=-2))
   
6. 
   
7. # 半极限方式：（可以保证匹配正确率最高，但是怕遇到渐变）
   
8. DoubleWeave.a60224().AssumeTFF
   
9. TDeint(mode=2,order=1,field=1,type=1,full=false,tryweave=true,slow=2)
   

复制代码

我个人感觉日本人做的a60224更适应动画片，比TIVTC的匹配正确率要高。但是它没有后处理功能。

我写这2段代码的思想是，首先用匹配成功率最高的插件去做匹配，删除亢余帧后，再将场拆开，在24fps下重新匹配。（用TDeint的mode=2）因为只要a60224的匹配正确的话，24fps时片子也拥有30fps的全部画面信息，仍然可以进行匹配。
极限方式是用EEDI2的插场法为全部帧做奇偶混合。
半极限方式没有全部做混合，TDeint只是将场拆开后重新匹配检测一遍，对交错帧进行奇偶混合。

这2种方法只是比不手写ovr更准确一些，实际上在半极限方式下，你仍然要手动调整渐变部分。
这2种方法更适合想让片子更好看，而又不愿意去手动操作的人。

由于这2种方法我没有进行大量实验，也暂时没有办法弥补它的种种缺点，所以不再细说了。
如果你发现了问题，或者有更好的办法，请不吝赐教。期待您的批评指点。


[ 本帖最后由 diseac 于 2008-8-8 07:45 编辑 ]

VempX

感谢dgwxx和diseac同学这么精彩的文章
针对大虾的avs脚本我补充一点
其实不需要用PointResize(96, 96)，用Crop裁剪成16x16，之后用VDM打开脚本，选择直接复制数据流，然后保存个AVI出来就OK了，这样不经过编码器，相对来说速度能够更快一点~

dgwxx

diseac我太崇拜你了T_T凌晨码字…真是太伟大了，把内容写得这么详细，我偷懒没写的手动pattern都写出来了，简直是tfm详解了。
我觉得tfm匹配精度好，是因为我做「ストレンヂア」的时候tfm爆除了100%匹配的超好记录，不开PP一个交错都没留下。不过可能也跟片源没有bad cut有一定关系，片源是不太完美的film（forced film会留下不少交错，但都不在场景切换）。此外，tfm走pp的帧比以前decomb时代要少不少。

不过说到bad cut，的确是一个比较难对付的问题，或许纯手动都不好解决。因为TMPGEnc的纯手动好像只有p和c两种匹配方式，得到无交错匹配的概率还不如tfm大。但是通过n、b、u方式进行匹配得到无交错帧却造成jerkness的历史，从decomb开始就有了（当时我了一半烂尾的高品质DVDRIP教程里面翻译了一些decomb的readme），到现在这个问题都很难解决。IVTC的历史还真是人类同bad cut斗争的历史啊，呵呵。遇到实在恶心的DVD我们可以干脆deinterlace了了事。

前年还是大前年来的记不清楚了，那时候我压彩云国物语，OP最后一个镜头的最后几帧令我印象深刻。那个镜头背景是蓝色的天空，一只凤凰飞翔远方，最后化为光点从屏幕中央向四周飞散开来。那个镜头中光点飞散的交错tfm就完全没有办法处理，几乎全部错误匹配（不是找不到合适的匹配帧，而是tfm自以为找到了正确的匹配，但实际上错了），输出了很多交错帧，而且没走pp（想想也是，既然过了匹配时cthresh那一关，就不可能走pp了）。这个场景说来也比较极端，因为光点都很小，背景是比较亮的浅蓝色，光点是很亮的稍微偏白的浅黄色，我也是放达到400%才看出来交错的，而且光点在飞散过程中还改变了交错的pattern，也难怪tfm无能为力了。那是我第一次也是惟一一次用ovr来指定pattern呢（笑）。

diseac

今天早晨起来看到这么一篇好文，有点激动，回的过长一点了。
现在想找点中文的技术文章，而且是讲得好的文章，实在太难了。
有时候我真想把dgwxx的家底都掏出来，取之精华为我所用

关于比较极端的 bad edit ，大家想象这样一个场景：
在动画片中，远景拍摄一座大楼，大楼有很多窗户、房檐之类，所以有很多水平的黑线。
这时候突然发生地震，大楼不停抖动。
没有任何近景和其他物体提供参考。

大家再想象这样的一个场景：
在动画片中，特写拍摄一台电视机。
电视机里面正在播放节目，为了让电视的效果看上去真实，故意制作了interlace
电视里面的节目也是动画片，30i 3:2 pull down 类型的，与周围场景PD同步。

当然这只是我想象出来的场景，不过不用我详说，大家就知道想要正确判断很不容易。
这种场景还是有无jerkness、无interlace的正确匹配可能的，但在这种极端场景下，自动判断通常带来的是一塌糊涂的错误匹配，jerkness和interlace。

日本人做的动画片DVD，有时候让人很为难，比如上面2象素的黑边，虽然在电视上被切掉看不到，但在电脑上看就很恶心了，这2象素黑边会给deinterlace、warpsharp等滤镜带来麻烦，而且YV12偏偏又要4mod。特别是如果要除掉这2象素的话，704基本是做不到了。

日本人做的滤镜和编码器，有时候也让人很为难，比如日本人的OreAQ版x264，虽然作者在他的网站上说得很好，可我真的一点也没看出它对暗场有什么帮助。日本人的warpsharp很适合动画，而且很少带来码率提升，但它经常会破坏上下各1象素的图象，出现烂边。

这些东西有时候想一想就一身汗

[ 本帖最后由 diseac 于 2008-8-8 11:08 编辑 ]

dgwxx

原帖由 diseac 于 2008-8-8 11:05 发表
今天早晨起来看到这么一篇好文，有点激动，回的过长一点了。
现在想找点中文的技术文章，而且是讲得好的文章，实在太难了。
有时候我真想把dgwxx的家底都掏出来，取之精华为我所用  

有用的请尽管拿走，千万不要客气。以后也请加油码长文||||NMM要是多您这么一位作者，将来肯定大有前途啊。
关于上面2px黑边的问题我也困扰了一阵，困扰之后，我就决定不再管它，让它黑着去吧。反正现在大部分片子都是16：9了，就算有黑边，16：10的显示器和4：3的显示器都看不出来 囧。

diseac

原帖由 dgwxx 于 2008-8-8 11:17 发表

有用的请尽管拿走，千万不要客气。

虽然有点跑题了，但我非常非常想请dgwxx另开一帖，详细讲一讲关于x264的各种AQ patch版本的利弊、设置方法、码率控制等方面的知识。各种版本AQ的利弊，对暗场和纹理进行优化的帮助和不足。
dgwxx写的《x264关键参数》并没有提到patch版的AQ，而且关于AQ，网上的讨论不是很多。外语网站有一些，但读起来比较费力，而且我的经验很不足。
如果dgwxx有时间的话，请写一写这方面的教程，期待。

dgwxx

我实在是对x264没经验，也没专门研究过各个patch，这方面我要外行了。vempx似乎研究过patch方面，回来请他写吧。

52wy

原帖由 diseac 于 2008-8-8 12:04 发表


虽然有点跑题了，但我非常非常想请dgwxx另开一帖，详细讲一讲关于x264的各种AQ patch版本的利弊、设置方法、码率控制等方面的知识。各种版本AQ的利弊，对暗场和纹理进行优化的帮助和不足。
dgwxx写的《x264关键 ...

关于AQ，公认的看法是不适合压动画。官方的预设动画模板也是关闭了AQ MODE的。

x265

请问bad edit是什么意思

dgwxx

原帖由 x265 于 2008-11-22 16:46 发表
请问bad edit是什么意思

在后期的剪辑、制作过程中由于失误造成场序乱掉，或者某个场景的第一帧或最后一帧丢掉一场补不回来。

x265

了解 谢谢

悍匪

对于某些有密集线条急动的OP，比如灼眼的夏娜的某个NCOP，以及akiduki （http://www.nmm-hd.org/bbs/thread-648-1-1.html）提到的向阳素描那样的画面，设置较低的MI值导致误判严重，但是MI设置高了会漏掉部分交错画面。“密集横向细线条（包括头发、文字、眼睛、甚至点状方格的背景）造成mic略大于mi导致被误判为交错的情况非常多”。OVR做OP和ED劳动量不大，做正片还是要放地图炮啊XD。。。

dgwxx

13# 悍匪
凉宫春日也有不少类似画面…比如，拍摄书桌抽屉中的书，为了表现书页，上面画了密集的线条。这种画面几乎是来一个错一个，必错无疑。

悍匪

13# 悍匪
凉宫春日也有不少类似画面…比如，拍摄书桌抽屉中的书，为了表现书页，上面画了密集的线条。这种画面几乎是来一个错一个，必错无疑。
dgwxx 发表于 2009-4-29 07:06

我觉得，这样的动画，先设置正常的MI，跑出LOG并校验写OVR。然后设较低的MI，单独去肉眼辨别那些横向线条复杂的场景。这样既可以保证精度，也不太浪费时间。

myshapigou

log.txt就是我们要输出的log文件。我们可以用VDM打开它，然后通过Direct Stream Copy模式输出为.avi

VDM打开txt文件显示Cannot detect file type~~!!!!!!!!

dgwxx

回复 16# myshapigou
抱歉，是我笔误，上下文指代关系不明。
应该是用vdm打开那个avs文件。

正文已经改正，谢谢指出。