[原创]dshow2raw工具发布专用帖（更新至2011-11-25）

之前有rc-lookahead 50的限制，刚刚忘了这个限制用了60也没问题，是不是新版本没这个限制了?

引用

最初由 zjhray 发布
之前有rc-lookahead 50的限制，刚刚忘了这个限制用了60也没问题，是不是新版本没这个限制了?

这个限制和线程数和bframe数也有关系
60保证在开超线程的i7+16 bframe的极端情况下依然不出问题

貌似限制是threads*3 + bframe + rc-lookahead <= 128

你怎么判断是vfr的？输出mp4然后用MediaInfo看？
这个是MediaInfo的bug，它看到的不是真正的fps，不过几句话说不清楚

引用

最初由 roozhou 发布
【x264中的新参数(仅在dshow模式下有效)】

引用

最初由 roozhou 发布
如果你用avs作为输入就不要用我这个版本了，所有的新功能都是无效的

原来如此，再次感谢，不过那片源是rmvb，哎，不知道该如何resize了

引用

最初由 ssnake 发布
ffdshow做resize

恩，谢谢啊
刚发现原来ffdshow里也有rv解码，以前没注意一直以为没有:cool:

最好不要用ffdshow的rv30/rv40解码，b帧的deblocking有严重问题。
你还是用real alternative的rv解码，然后ffdshow的raw video选成all supported就可以resize了。

引用

顺便，用了deldup后能不能知道砍掉了哪些帧？

只能知道数量，具体哪些帧我的滤镜并没有统计。编码时会显示已编码帧数和时间，计算一下就知道了。
不过rmvb在编码时已经砍掉了很多帧，所以deldup可以不开。但如果你用avs的话，avs会把砍掉的帧补回来，而且rmvb文件头里的帧率往往和实际帧率不同，比如实际帧率23.976，文件头里写的是23。avs为了凑文件头里的帧率会无端的砍掉很多帧，造成视频不流畅和码率的浪费。所以尽量不要用directshowsource + convertfps=true来处理rmvb文件

引用

最初由 bsgb666 发布
不知道加了dedup后这个abr是怎样的算法
比如我用bitrate 450，然后又用了deldup
这样出来的视频，是最终vfr的平均码率为450，还是除却timecode后的cbr的平均码率为450

2pass的话是最终码率
1pass的话是设定好的fps对应的cfr码率

x264在设计时并没有考虑vfr，我现在只是实现了2pass时根据1pass得到的视频长度和总帧数把vfr码率“换算成”cfr码率，所以用1st pass crf + 2nd pass bitrate是比较好的选择。

貌似rv10和M$的wmv/vc1编码器的码率控制都是基于时间戳的，所以不存在这个烦人的问题。