我的视频是1440x1080的 实际输出宽高比却是16:9的
在反交错参数完全不变的情况下 压制了两次
1.直接把视频改成1440x810（反交错也做了） 2.不改分辨率 只做反交错
结果1出现了很轻微的拉丝效果
结果2未出现拉丝
那我就想到可能是分辨率改动的原因 那我就手动呗 把结果2的视频用16:9的比例播放
结果发现还是无拉丝效果 此时还相当满意
可能是反交错的时候改动分辨率出现问题了吧
于是我就把结果2的视频改动分辨率 改成1440x810 （结果2的视频第一步的时候已经做过反交错 所以这次只要做个改分辨率）
等啊等 然后OK了 我就看吧 问题来了- - 诡异的拉丝现象竟然出现了
奇了怪了 我就想问 本身结果2的视频通过16:9播放并无拉丝 为什么经过改动分辨率
从1440x1080到1440x810 直接16:9播放反而出现拉丝效果呢
可能是因为片源输出宽高比不是16:9 可能是1.78 可能是1.778 也可能是1.7777777778造成的
影响？ 不懂啊I

还发现个诡异的 megui是不是不能处理时间太短 帧数太少的视频呢
因为我弄反交错是第一次 想看看不同反交错工具的效果
整场压制太慢 我就cut了下 保留了300帧 也就是10秒呗
mp4转mp4 只做反交错处理 别的都不动 竟然出来的视频只有几百K
视频保持同一个画面 只有音乐。。。
于是我换了个4分钟的mp4 转mp4 做同样的处理 毫无问题 可以看
那我就想可能是那个MP4本身有问题？ 就从300帧改成了500帧。。16秒左右呗。。
别的处理都是一样的 结果能看了 太诡异了I

再问下前辈们- - 这个反交错哪个模式最好
yadif？tdeint？还是那个Tom什么的？还是网上说最好的qtgmc(虽然我没见到有这个- -)

需要sar4:3
这是变形分辨率，由于人眼对横向分辨率不如纵向敏感，所以电视信号采用变形分辨率减小数据量的同时又不怎么影响质量。这种视频不要改变分辨率，直接在x264的参数中加入 --sar 4:3
就可以了。压完后的分辨率不变，播放器会根据文件头的sar比例重采样显示出正确的dar。sar计算方法自己百度。也有相应的小程序专门计算sarI

就看这两张图吧 怎么才能压出上面的效果呢
I

DirectShowSource("D:\视频源\[jksky.co.kr]Fin.K.L-Fin.K.L(Mnet.Japan)\123.ts", fps=29.970, audio=false, convertfps=true).AssumeFPS(30000,1001)
LoadPlugin("C:\Users\hzy\Desktop\MeGUI\MeGUI\MeGUI-2112-cn-ERC\MeGUI\tools\avisynth_plugin\TomsMoComp.dll")
TomsMoComp(-1,5,1)
#crop
#resize
#denoise
ConvertToYV12()
I

要理解ivtc就要先了解什么是帧，什么是场。每帧画面都是由两个场组成。分为奇数场和偶数场，奇数场在前是tff，偶数场在前是bff。我们现在的液晶显示器都是帧显示器，而以前的crt都是场显示器。所以同样的隔行视频在液晶上看有条纹，在crt上看就很完美。
交卷过带就是为了让crt完美播放把逐行视频通过拆场变成隔行视频，拆场重排的过程中会在五帧中复制一个重复帧。所以帧率就由23.976变成了29.970。ivtc反胶卷过带就是把交卷过带逆向操作，把场拆开做场匹配，匹配后的每5帧中都有一个重复帧，删去就完成了ivtc。帧率也由29.970还原回23.976I

DirectShowSource("D:\视频源\Fin.K.L(Mnet.Japan).ts", fps=29.970, audio=false, convertfps=true).AssumeFPS(30000,1001)
ConvertToYV12()
QTGMC(Preset="Fast").SelectEven()

#deinterlace#
crop
#resize#
denoise
不写ConvertToYV12() 就会出现下图错误
I

顺便话说，h.264i的TS，可以试试重新封装进mkv以后挂lwlibav