[请教]Vista64下,怎么进行x264压制|『影音数码技术学习交流』 - 『漫游』酷论坛

『漫游』酷论坛>『影音数码技术学习交流』>[请教]Vista64下,怎么进 ..

roozhou@2008-10-24 16:36

引用
最初由 MeteorRain 发布
就如我说的，其实你应该考虑考虑ffmpeg in x264，并且如果把ffmpeg模块做成脚本读取的话，就可以完美替代avs脚本了。

比如我们有一个.ffmpeg的脚本
avisource('xxx.avi')
trim(100,500)+trim(700,1000)
outputvideo('x264', 'mp4', 'xxx_v.mp4')
outputaudio('aac', 'mp4', xxx_a.mp4')

然后这么让x264一读，parse出处理顺序，然后就很爽了。

filter可以自己移植开源的代码，也可以模拟avs环境让filter本地跑。

嗯，我继续爬doom9的帖子 =v=

这个想法我也考虑过，但有很多问题
1）其他平台滤镜向avisynth移植一般都不难（少数vfr的除外），但avisynth滤镜移植到其他平台很难，毕竟C++ -> C非常困难，而且avisynth本身接口复杂，其他平台不一定有相应功能。

2）脚本用起来很不方便，而ffdshow,dscaler,avidemux这样的界面更友好且便于批量。

3）各位大大被avs洗脑严重，按帧trim很麻烦而且可读性极差实现困难，改成按时间trim可读性大增，并可以省掉index的时间。毕竟没有哪个播放器是按帧数seek的，也没有哪种封装格式是按帧数设定index的。

引用

MeteorRain@2008-10-24 19:17

引用
最初由 roozhou 发布

这个想法我也考虑过，但有很多问题
1）其他平台滤镜向avisynth移植一般都不难（少数vfr的除外），但avisynth滤镜移植到其他平台很难，毕竟C++ -> C非常困难，而且avisynth本身接口复杂，其他平台不一定有相应功能。

2）脚本用起来很不方便，而ffdshow,dscaler,avidemux这样的界面更友好且便于批量。

3）各位大大被avs洗脑严重，按帧trim很麻烦而且可读性极差实现困难，改成按时间trim可读性大增，并可以省掉index的时间。毕竟没有哪个播放器是按帧数seek的，也没有哪种封装格式是按帧数设定index的。

1) 若是限定colorspace在yv12，然后将源代码C&P过来的话，是否有可能将常用功能都移植过来？是否有可能加入中间层以执行C++代码？

2) 脚本也可反复使用，linux下不是cli就是conf。cli一次性调用，conf可长期使用。avs的脚本方式本身就是一个很好的参照。首先文本是可控的，肉眼便能看到详细参数；其次文本也可以进行include这样的局部参数导入。例如可以分别存放多个x264的参数profile，仅需指定bitrate或qp即可自动以psp或者ipod模式压制，等等。仅仅是引入一个x264psp_prof或者x264ipod_prof。如果是ffdshow的话，首先平台相关，其次你一遍压片一遍放片，放片时突发奇想改了个参数，回头一看你压的片里也顺着你参数压了，这多惨

3) 按帧数控制我认为是更好的方法。帧数是整数，时间是小数，还受到fps、浮点数精度等的问题。第6帧就是第6帧而没有二义性。若是拿出个0:00:06.22704这种时间戳，就很容易让人发狂了。当然了，若是同时提供2种输入能力的话，就更好了。

还有什么问题我一会儿到doom9去发帖讨论好了。

引用

MeteorRain@2008-10-24 19:28

另外我建议你先把一些重要的bugfix做成diff提交给他们，merge到git tree里先……

引用

ssnake@2008-10-24 19:46

ffmpeg最多用7线……8线以上就会很莫名的crash或输出失败……

在某集群上做的测试……

引用

海波湛蓝@2008-10-24 22:15

…很弱地再问,持有大内存的大大们是怎么捣鼓x264的？

引用

qyqgpower@2008-10-24 22:27

内存和x264有什么关系，除了fft3dgpu会狂吃内存之外，根本不可能有其他东西能让x264跑过4G的commit charge

引用

uc0083@2008-10-24 22:37

fft3dgup在什么情况下狂吃内存，我似乎同时压4个时也没发现啊

引用

qyqgpower@2008-10-24 23:03

跑4个？
随便找个1920x1080的东西
FFT3DGPU(plane=4,precision=2)

打开两个，不用跑x264，就能爆8G内存

对付BD，不加任何额外滤镜，SetMemoryMax(256)后，用比较节省的内存的CoreAVC做directshowsource，8G内存最多只能同时跑三个x264，此时的commit charge大约在7.8G左右

引用

海波湛蓝@2008-10-25 00:17

唔，QYQ大是什么系统？

引用

uc0083@2008-10-25 01:51

引用
最初由 qyqgpower 发布
跑4个？
随便找个1920x1080的东西
FFT3DGPU(plane=4,precision=2)

打开两个，不用跑x264，就能爆8G内存

对付BD，不加任何额外滤镜，SetMemoryMax(256)后，用比较节省的内存的CoreAVC做directshowsource，8G内存最多只能同时跑三个x264，此时的commit charge大约在7.8G左右

我是640x480四个，偶尔试了一下觉得跑两个差不多了，2个就够有效利用cpu了，而且1个切成4个太麻烦了

引用

qyqgpower@2008-10-25 10:42

同时跑多个片子是好主意，把一个片子切成多个就太蛋痛了

@ 海波湛蓝