AtTheAsylum
Well-Known Member
Thread Starter
- Joined
- Jan 17, 2008
- Messages
- 56
- Likes
- 0
Hi all,
For the last couple of hours I've been experimenting with mencoder from the command line - trying out a few options encoding to H264 AVC video.
One thing I discovered was that x264 codec accepts a 'threads' parameter - so I tried a couple quick of experiments
I used a short DVD segment (1 chapter from the movie Solaris 2 mins 19 secs long) and encoded on my laptop (Core 2 Duo 1.83 Ghz).
Default settings (ie: very similar to PS3 profile in CD-M):
Time to encode: 1 min 17 secs.
CPU usage (Windows Task Manager): 50%
Threads (Windows Task Manager): 1
Frames per sec: 50.
2 threads:
Time to encode: 37 secs.
CPU usage: 90%+
Threads: 2
Frames per sec: 95
Auto threads:
Time to encode: 37 secs
CPU usage: 90%+
Threads: fluctuates between 1 and 5.
Frames per sec: 95
I don't have access to a full DVD at the moment so I can't perform a 'real' test but these results look very interesting. When you consider that currently it can take upwards of 8 hours to encode a DVD to H264 AVC.
Also, this seems (on my system anyway) to work a whole lot better than the 'threads' option when creating DivX's (using lavc). There is a definite speed increase when using x264, whereas there is no speed increase when using lavc (although, as pointed out by 'profcolli', the 'threads' option in lavc does spread the load a lot more evenly across cores).
Another point - the encoding speed (in my quick tests) approached that of DivX and XviD. 125 and 110 frames per sec respectively.
Note: Since this is the first pass all the examples above dump the output to NUL (ie: no output file is created). Second pass, where output is dumped to and AVI, achieve the same results (ie: encode times are the same as above).
The problem is that if I add the 'threads' option to the '-x264encopts' in an appropriate profile in CD-M it seems to be ignored
My request to the developers: please enable the 'auto' threads option by default when encoding to H264 AVC using the x264 codec.
Fantastic product BTW - Licensed my copy today
Edit: Ran some more tests on my sample using a higher bitrate (3000) and resolution (852x480). I still saw a two-fold increase in performance using threads=2 when encoding to H264 AVC - 10 fps (1 thread) versus 20 fps (2 threads). At the same resolution DivX achieved 75 fps and Xvid 25 fps. All results are from the second pass.
For the last couple of hours I've been experimenting with mencoder from the command line - trying out a few options encoding to H264 AVC video.
One thing I discovered was that x264 codec accepts a 'threads' parameter - so I tried a couple quick of experiments
I used a short DVD segment (1 chapter from the movie Solaris 2 mins 19 secs long) and encoded on my laptop (Core 2 Duo 1.83 Ghz).Default settings (ie: very similar to PS3 profile in CD-M):
Code:
mencoder.exe dvd:// -dvd-device d:\demodvd -af volume=10 -aspect 16:9 -of avi -noodml -ovc x264 -x264encopts bitrate=1000:level_idc=41:bframes=3:frameref=2:nopsnr:nossim:pass=1 -vf scale=320:180,harddup -info name="TEST" -alang en -oac copy -o NUL -passlogfile x264pass.logTime to encode: 1 min 17 secs.
CPU usage (Windows Task Manager): 50%
Threads (Windows Task Manager): 1
Frames per sec: 50.
2 threads:
Code:
mencoder.exe dvd:// -dvd-device d:\demodvd -af volume=10 -aspect 16:9 -of avi -noodml -ovc x264 -x264encopts bitrate=1000:level_idc=41:bframes=3:frameref=2:nopsnr:nossim:pass=1:threads=2 -vf scale=320:180,harddup -info name="TEST" -alang en -oac copy -o NUL -passlogfile x264pass.logTime to encode: 37 secs.
CPU usage: 90%+
Threads: 2
Frames per sec: 95
Auto threads:
Code:
mencoder.exe dvd:// -dvd-device d:\demodvd -af volume=10 -aspect 16:9 -of avi -noodml -ovc x264 -x264encopts bitrate=1000:level_idc=41:bframes=3:frameref=2:nopsnr:nossim:pass=1:threads=auto -vf scale=320:180,harddup -info name="TEST" -alang en -oac copy -o NUL -passlogfile x264pass.logTime to encode: 37 secs
CPU usage: 90%+
Threads: fluctuates between 1 and 5.
Frames per sec: 95
I don't have access to a full DVD at the moment so I can't perform a 'real' test but these results look very interesting. When you consider that currently it can take upwards of 8 hours to encode a DVD to H264 AVC.
Also, this seems (on my system anyway) to work a whole lot better than the 'threads' option when creating DivX's (using lavc). There is a definite speed increase when using x264, whereas there is no speed increase when using lavc (although, as pointed out by 'profcolli', the 'threads' option in lavc does spread the load a lot more evenly across cores).
Another point - the encoding speed (in my quick tests) approached that of DivX and XviD. 125 and 110 frames per sec respectively.
Note: Since this is the first pass all the examples above dump the output to NUL (ie: no output file is created). Second pass, where output is dumped to and AVI, achieve the same results (ie: encode times are the same as above).
The problem is that if I add the 'threads' option to the '-x264encopts' in an appropriate profile in CD-M it seems to be ignored
My request to the developers: please enable the 'auto' threads option by default when encoding to H264 AVC using the x264 codec.
Fantastic product BTW - Licensed my copy today
Edit: Ran some more tests on my sample using a higher bitrate (3000) and resolution (852x480). I still saw a two-fold increase in performance using threads=2 when encoding to H264 AVC - 10 fps (1 thread) versus 20 fps (2 threads). At the same resolution DivX achieved 75 fps and Xvid 25 fps. All results are from the second pass.
Last edited:
