我原来用DirectShowSource导入照相机拍摄的MJPEG的AVI视频，可是发现颜色不对头，普遍发暗，细节消失。后在本论坛经高人指点改用ffmpegsource2，颜色就正常了，截图如下：
第一张是直接播放MJPEG原始AVI，后一张是在AVS里用DirectShowSource导入视频，可见细节已经丢失了。
我的CPU是I5 5470，3.2G，4核心，8G内存。鉴于强大的硬件配置，于是用WIN7 64，压缩方面当然也可以沿用32bit软件，但是为了追求最大效率，所以在寻找全64bit的压缩方案。
最终找到了Vapoursynth，64位Vapoursynth+64位Python+64位ffms2插件+x264_64应该可以构建全64bit的压缩环境了。 可是关于Vapoursynth有太多不懂的地方了，相当于重头学一遍AVS脚本。
其实我基本都是裸压，不用任何的修剪和画面润色，所以刚刚学了一下x264命令行，代码如下：
x264 --crf 24 --tune film --preset medium --b-pyramid none -o 1.mkv 1.avi
此代码执行无误，可以输出1.MKV，但就是画面右边的情况，画面发暗，跟用DirectShowSource是一样的效果。
可是我看到的资料是x264已经加入了ffms，怎么还会是这样，难道内部还是DSS导入，抑或是ffms，而不是ffms2么？
为了避免此情况，只有用64bit的ffms2，可这又需要Avisynth，32bit的Avisynth我不想用，64bit的据说性能很不好，Avisynth已经老矣，不能发挥4核心的最高性能。
剩下的选择就是64位Vapoursynth+64位的ffms2+X264_64了，可是Vapoursynth的语法。。。。哎，纠结呀。
另外请教一下，我看到的资料，X264会自动判断输出文件的类型并自动封装，可为何不能输出MP4，如果输出文件改成1.MP4就会提示：
X264 [error]: not compiled with MP4 output support
最后一个问题，大家可否发现x264。nl已经被转向到videolan了，难道这个新站点将是x264的发布平台么？
谢谢！

自己瞎用dss怪avs有问题? 呵呵

人家双路E5都用着32位的AVS呢...i5就别自大了...

裸压的话直接用tmod的x264版本一般不会有什么问题的。
我写了一个GUI直接利用tmod的，裸压视频avi的ts的也没碰到啥问题，但是音频不要用这个x264处理， 所以要加--acodec none 参数，音频单独用ffmpeg命令行来处理。

额，好吧，就算x264解码比较容易有问题，avs光做个解码也不是什么瓶颈嘛

原来的E6550压缩速度是个位数，i5 5470变成了52fps。

现在L-SMASH成为官方x264 MP4 muxer备选之一，且configure的优先级比GPAC高，videolan编译版还是不鸟。

应该是YU12转RGB32的过程中损失了颜色。
原因已经找了，我用MPC-HC做实验，用WIN7系统解码器MJPEG解码器的时候就正常，用MPC-HC的LAV解码器就不正常了。现在MPC已经全面转向LAV，包括分离器和解码器（MPC叫做源滤镜和转换滤镜）。
另外回复一下8楼，我发现在本版有种不好的风气，就是骂人，我记得有个叫CCTV9的人写了一个X264命令行入门贴，结果被一顿骂，说其“班门弄斧”，论坛本身就是一个开放的讨论组，各种水平的人都有，不要因为自己有2把刷子就瞧不起别人。
我的CPU是i5 4570，错写成了5470。对于这样高端的系统，用WIN7-64,如果再加上合适的优化，包括64位的压缩工具和滤镜，充分发挥64位的优势，速度超过未经优化的i7/E5的32位系统是可能的。
而且就算超不过又如何，进入64位的世界，重新学习知识，把64位的潜力发展到极限，这就是对技术的追求。高端机器却不加任何优化的使用32位软件当然也可以压制，但是未达到机器的最高效率，这恰恰是需要改正的缺点。

据我所知，YV12是YUV 4:2:0的另一个称呼，x264领域的YUV实际上就是YCrCb，也就是数字色差分量。

ffmpeg系的解码器解MJPEG会直接输出YV12或YV16，MS系的一般都输出RGB。但是JPEG通常用full range，所以压制的时候要转limited range。不过YUV->RGB->YUV会损失质量，所以还是用ffmpeg系的好。

乖乖，我的好久远的帖子，也被人找到了