求助！！关于解码器！！(已解决)

[eternalzack]

今天玩SVP那个东西装了几个软件，用MEGUI压片（片源MKV h264）的时候的发现速度慢了好多，解码速度跟不上编码速度了，cpu使用率也不高，装了好多解码器，虽然用有些解码器速度快了点，但还是跟以前差了好多，求帮助啊！！！

我系统是WIN7 64位 还发现装了64位解码器没法用，默认的还是32位的

[-o-o-304-o-o-]

LZ建议先改标题吧，标题党啥的这……真别贴吧化了……

问题可能是avs上得mvtool单线程成瓶颈了吧，想部分解决的话可以选择mp pipeline活着手工分avs跑ffv1

另外想用64bit的插件请用64bit的avs…

[eternalzack]

把一堆东西卸了重新装了下ffdshow...........不知道为啥好了..........

[upyzl]

如果你使用的编码器不是64bit的话，当然全程走32bit路线
从你的描述来看，应该是avs(DSS)+x264, 且avs和x264都是32bit的

之前SVP会大慢，应该解码是有走ffdshow的，且raw video由disable变成了all support，然后ffdshow的avisynth也打开，并且载入了SVP的相关脚本

其余的就是304说的了

说实话avs的DSS要慎用。。megui现在应该也是首推ffms才对，而且压mkv h264显然avs ffms比avs DSS更保险
如果没用其他滤镜，用x264自带的ffms就行了，avs都不需要

如果要用DirectShow方式解码压片，建议用direct264(见我签名)

最后，现阶段h264解码最快的应该是这个
http://www.nmm-hd.org/newbbs/viewtopic.php?f=17&t=431

[06_taro]

mkv的话如果DS设置没问题的话DSS2也挺保险的
毕竟mkv这种内置cue的格式除非文件坏掉否则一般不会出现frame inaccurate的情况

而像m2ts这种格式ffms也不比DSS2保险，毕竟它对m2ts的index默认仍然是靠Haali的，和DSS2没啥区别（个人怀疑比DSS2更不靠谱……x264内置时略好些，因为x264内置的ffms默认是使用FFMS_SEEK_LINEAR_NO_RW的方式做seek的，只有在有--seek参数时才会为了速度使用FFMS_SEEK_NORMAL（此时和和avs用的ffms2默认一样）模式，所以如果走ffms裸压的或还是推荐用x264内置的ffms，或者（对m2ts）avs里做index时手动指定lavf做demuxer，并且seekmode设为0或者-1（FFMS_SEEK_LINEAR_NO_RW就是-1，理论上是最安全的模式）。

[upyzl]

mkv的话如果DS设置没问题的话DSS2也挺保险的
毕竟mkv这种内置cue的格式除非文件坏掉否则一般不会出现frame inaccurate的情况

主要是我以前二压某1080p的视频，用DSS2卡死到80%左右，当时不信邪又用DSS2再压一遍，还是卡死到相同地方（卡死的意思是，x264的编码突然不动了，fps数值也卡死了，没有任何error信息）；当时换DSS反而能压完视频（不过帧数可能错了，我当时也没注意）…… 所以对DSS2有阴影了 故一般不拿DSS2来说事（貌似只有我遇到过这种RP情况的样子？）

edit:找到了：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=212

而像m2ts这种格式ffms也不比DSS2保险，毕竟它对m2ts的index默认仍然是靠Haali的，和DSS2没啥区别（个人怀疑比DSS2更不靠谱……x264内置时略好些，因为x264内置的ffms默认是使用FFMS_SEEK_LINEAR_NO_RW的方式做seek的，只有在有--seek参数时才会为了速度使用FFMS_SEEK_NORMAL（此时和和avs用的ffms2默认一样）模式，所以如果走ffms裸压的或还是推荐用x264内置的ffms，或者（对m2ts）avs里做index时手动指定lavf做demuxer，并且seekmode设为0或者-1（FFMS_SEEK_LINEAR_NO_RW就是-1，理论上是最安全的模式）。

TS系的ffms自然就不能保证靠谱性了, 毕竟LZ说mkv h264, 所以我就那样说了……
另感谢taro大后面的说明，又学到了

[-o-o-304-o-o-]

mkv的话如果DS设置没问题的话DSS2也挺保险的
毕竟mkv这种内置cue的格式除非文件坏掉否则一般不会出现frame inaccurate的情况

主要是我以前二压某1080p的视频，用DSS2卡死到80%左右，当时不信邪又用DSS2再压一遍，还是卡死到相同地方（卡死的意思是，x264的编码突然不动了，fps数值也卡死了，没有任何error信息）；当时换DSS反而能压完视频（不过帧数可能错了，我当时也没注意）…… 所以对DSS2有阴影了 故一般不拿DSS2来说事（貌似只有我遇到过这种RP情况的样子？）

edit:找到了：http://www.nmm-hd.org/newbbs/viewtopic.php?f=8&t=212

而像m2ts这种格式ffms也不比DSS2保险，毕竟它对m2ts的index默认仍然是靠Haali的，和DSS2没啥区别（个人怀疑比DSS2更不靠谱……x264内置时略好些，因为x264内置的ffms默认是使用FFMS_SEEK_LINEAR_NO_RW的方式做seek的，只有在有--seek参数时才会为了速度使用FFMS_SEEK_NORMAL（此时和和avs用的ffms2默认一样）模式，所以如果走ffms裸压的或还是推荐用x264内置的ffms，或者（对m2ts）avs里做index时手动指定lavf做demuxer，并且seekmode设为0或者-1（FFMS_SEEK_LINEAR_NO_RW就是-1，理论上是最安全的模式）。

TS系的ffms自然就不能保证靠谱性了, 毕竟LZ说mkv h264, 所以我就那样说了……
另感谢taro大后面的说明，又学到了

DSS2卡住的问题我这也遇到过，99%连续2次卡在相同的一个位置，但是奇怪的是跑ffv1就能跑完而且没啥问题，不解中……

同样拜谢taro大

[pureland]

如果原檔是mkv的話,記得要先將Video分離出來才去跑x264
要不然x264跑到99%就會停止不動了~
這是因為DirectShowSource2無法讀取Audio檔的緣故~
不過原檔是mp4的話倒是沒問題~
以上小弟淺見不知對否

[06_taro]

有frame accurate问题的是DSS而不是DSS2，所以想走DS的话对cfr可以用DSS2载入视频，然后DSS载入音频再AudioDub。嘛当然其实音频是不应该用avs处理的……

[jasonwang]

这种标题档太可恨了，管理员有空置底了吧。