Interestingly, recently a few columns were added to the "ffmpeg -codecs" output that might be of interest to you.
Thanks for the tip. I will definitely download the last version. Mine (December 2011) doesn't have that information.
It would be interesting to compare console output for mp4 versus libx264, it's possible that one is giving poorer quality which would help explain why it's faster.
I agree quality is a parameter I also considered. I am not sure how you can compare quality based on the console output, but I can post some of them if you would like to look at them. What I do to compare quality is to run the ssim filter in avisynth comparing the original with the compressed version. ssim = 100 means identical.
I have been a little slow putting my tests and my thoughts together, but here it is.
Here is a summary of the tests, where I show, for the various codecs:
- the value 'n' of the '-threads n' option,
- the cpu use, as seen (approximately) on Windows Task Manager,
- the number of frames processed per second (fps) by the codec,
- a quality option: constant rate factor (crf) for libx264, the encoding bitrate in kbps for xvid,
- and the ssim ratio in % calculated with the avisynth SSIM() function, which performs a subjective comparison between the original clip, and the compressed version.
Tests run on Intel Core2 Quad Q9000 @2.00GHz, Win7. Using ffmpeg version N-36193-gf514695, Copyright (c) 2000-2011 the FFmpeg developers built on Dec 26 2011 17:50:37 with gcc 4.6.2 (Zeranoe static build)
Note that cpu usage percentage takes the average of the four processors: for example, 24% usage may mean one processor at 96% and three processors at 0%.
libx264 (four processors always working at similar load)
-threads 6, cpu use: ~93%, fps=54 crf=22 ssim=77.85
-threads 4, cpu use: ~85%, fps=44 crf=22 ssim=77.87
-threads 2, cpu use: ~52%, fps=32 crf=22 ssim=77.84
-threads 0, cpu use: ~98%, fps=54 crf=22 ssim=77.85
-no thread cpu use: ~98%, fps=54 crf=22 ssim=77.85
-threads 4, cpu use: ~78%, fps=55 crf=24 ssim=75.21
-threads 4, cpu use: ~71%, fps=65 crf=26 ssim=73.40
-threads 6, cpu use: ~83%, fps= 9 bitrate = 650K ssim=72.14 (same load for each cpu)
-threads 4, cpu use: ~78%, fps=11 bitrate = 650K ssim=72.14 (same load for each cpu)
-threads 2, cpu use: ~52%, fps= 7 bitrate = 650K ssim=72.14 (cpu 3 ~80%)
-threads 0, cpu use: ~24%, fps= 4 bitrate = 650K ssim=72.14 (cpu 2-3 ~40%)
-no thread cpu use: ~24%, fps= 4 bitrate = 650K ssim=72.14 (cpu 3 ~75%)
-threads 6, cpu use: ~57%, fps=106 bitrate = 650K ssim=72.04 (similar load)
-threads 4, cpu use: ~70%, fps=109 bitrate = 650K ssim=72.09 (similar load)
-threads 2, cpu use: ~45%, fps= 79 bitrate = 650K ssim=72.09 (cpus 1-2 ~60%)
-threads 0, cpu use: ~53%, fps=102 bitrate = 650K ssim=72.05 (similar load)
-no thread, cpu use: ~24%, fps= 50 bitrate = 650K ssim=72.05 (cpu 2 ~60%)
-threads 4, cpu use: ~63%, fps= 92 bitrate =1000K ssim=72.99(similar load)
-threads 4, cpu use: ~69%, fps= 70 bitrate =2000K ssim=73.35(similar load)
Regarding the effect of the '-threads n' option, it really depends on the codec used:
- - libx264 works faster with a number of threads greater than the number of processors, or with 0 or no -threads option. So, the worst case is to put '-threads n' with n <= number of processors. Better not use the -threads option.
- On the other hand, libxvid runs best with n = number of processors, but this codec is VERY SLOW.
- mpeg4 for xvid is very fast, and also works best with n = number of processors
As far as quality is concerned: If I reduce the quality (by increasing crf to 24 and 26) of the libx264 encoding to bring it closer to libxvid or mpeg4, the frames per seconds go up and the cpu usage go down (seems normal, less processing needed). If I increase the quality (higher bitrate) for the mpeg4 encoding, the fps goes down (seems normal) and the cpu stays the same or goes down.