I put together a self-contained x264 video encoding benchmark. Techarp kindly agreed to host the file and results at this URL.
Basically, you run the test encode and it will report back frames-per-second values for your machine @ it's clock/overclock level. You can run it at your stock settings and at your overclock settings to see how your machine compares to others in the database.
The database is small right now (as of 08-sep), but as you guys report in results, I will populate it. My goal is to have a representative set of data for many different chips and chipsets. Hopefully, we'll get some Penryn and Phenom data when they become available. Also, if anyone out here has some of the high end AMD chips, please contribute. Instructions and the file are at that url.
Also, please report your results here in this thread. I will keep the data at that url to keep things simple.
Thanks all.
x264 video encoding benchmark
It all depends on video bitrate, if my bitrate is 11.71 Mbps I will process the video way waaay faster then someone with way stronger cpu and with video bitrate 27.11 Mbps.
The test doesnt make sence at all, ok i get it collect data for what purpose ?You still can be at your stock speed and with proper plugins you can beat someone who OCed his cpu 1000mhz+.
The test doesnt make sence at all, ok i get it collect data for what purpose ?You still can be at your stock speed and with proper plugins you can beat someone who OCed his cpu 1000mhz+.
To be human is to choose.
It is better to die on your feet
than to live on your knees.
- Emiliano Zapata
It is better to die on your feet
than to live on your knees.
- Emiliano Zapata
@Rivas - It depends on the video bitrate true, but it also depends on many different factors affecting quality. The whole point of the benchmark is to hold all of them constant (i.e. everyone uses the same set of x264 parameters for the test). This way, people can look at the results and see which not only how their system compares to other systems with the same processor, but how their system compares to other systems with different processors.
Does that make sense?
Does that make sense?
as posted over @ [H]................
AMD opty 170 @ 250 x 10, 2GB @250 3.0-4-4,windows XP pro sp2 32bit
---------- RUN1PASS1.LOG
encoded 1749 frames, 66.12 fps, 1850.89 kb/s
---------- RUN2PASS1.LOG
encoded 1749 frames, 67.11 fps, 1850.89 kb/s
---------- RUN3PASS1.LOG
encoded 1749 frames, 66.59 fps, 1850.89 kb/s
---------- RUN4PASS1.LOG
encoded 1749 frames, 67.11 fps, 1850.89 kb/s
---------- RUN5PASS1.LOG
encoded 1749 frames, 67.27 fps, 1850.89 kb/s
---------- RUN1PASS2.LOG
encoded 1749 frames, 15.94 fps, 1826.26 kb/s
---------- RUN2PASS2.LOG
encoded 1749 frames, 15.97 fps, 1826.37 kb/s
---------- RUN3PASS2.LOG
encoded 1749 frames, 16.01 fps, 1826.37 kb/s
---------- RUN4PASS2.LOG
encoded 1749 frames, 16.07 fps, 1826.37 kb/s
---------- RUN5PASS2.LOG
encoded 1749 frames, 16.04 fps, 1826.37 kb/s
AMD opty 170 @ 250 x 10, 2GB @250 3.0-4-4,windows XP pro sp2 32bit
---------- RUN1PASS1.LOG
encoded 1749 frames, 66.12 fps, 1850.89 kb/s
---------- RUN2PASS1.LOG
encoded 1749 frames, 67.11 fps, 1850.89 kb/s
---------- RUN3PASS1.LOG
encoded 1749 frames, 66.59 fps, 1850.89 kb/s
---------- RUN4PASS1.LOG
encoded 1749 frames, 67.11 fps, 1850.89 kb/s
---------- RUN5PASS1.LOG
encoded 1749 frames, 67.27 fps, 1850.89 kb/s
---------- RUN1PASS2.LOG
encoded 1749 frames, 15.94 fps, 1826.26 kb/s
---------- RUN2PASS2.LOG
encoded 1749 frames, 15.97 fps, 1826.37 kb/s
---------- RUN3PASS2.LOG
encoded 1749 frames, 16.01 fps, 1826.37 kb/s
---------- RUN4PASS2.LOG
encoded 1749 frames, 16.07 fps, 1826.37 kb/s
---------- RUN5PASS2.LOG
encoded 1749 frames, 16.04 fps, 1826.37 kb/s
7950x~64GBGskill6000~asusx670e~rx6800~2TBNvme-OS drive~4TB-Nvme-scratch~500GB-SSD-thrash~10TB storage~Windows 10
Yes I do understand, but not everyonce is using same scripts/filters.graysky wrote:@Rivas - It depends on the video bitrate true, but it also depends on many different factors affecting quality. The whole point of the benchmark is to hold all of them constant (i.e. everyone uses the same set of x264 parameters for the test). This way, people can look at the results and see which not only how their system compares to other systems with the same processor, but how their system compares to other systems with different processors.
Does that make sense?
The higher bitrate the higher quality. Does it make sence? Obviously not to you.
I have done 3000+ encodes (TV shows), starting with DSR, HDTV, HR.HDTV and x264 720p.
The next thing is what you use for cutting out the commercials, ProjectX? Videoredo, HDTV to MPEG (not recommended the audio/video is always out of sync) ?
WHat about cropping ?
Yes you can write it or use dgindex ...anyway I think we both made our points.
It's not ONLY about cpu it's script war, the better one always wins, how come "censored" is done 5-8 minutes after the show ends? 720p ! The first one takes the crown and the rest of them are nuked.
Or even before (ya some .ca stations do air before .us networks and vice versa)
I hope you see my point, I'm not trying to put you down AT ALL.
Proof?
http://forum.doom9.org/archive/index.php/f-33.html
http://forum.doom9.org/showthread.php?t=122960
http://avisynth.org/warpenterprises/#other
http://avisynth.org/tsp/
To be human is to choose.
It is better to die on your feet
than to live on your knees.
- Emiliano Zapata
It is better to die on your feet
than to live on your knees.
- Emiliano Zapata
No, that's only true if he was planning to meGUI. This benchmark will run without it.Rivas wrote:you need .net framework
@lopp2kil: There are three major reasons why this might be the case. The solution to all three of them can be found in the instructions on the previous page.
1) You didn't unRAR the file to c:\work2
2) You didn't install AVISynth 2.5.7
3) You forgot to copy the "DGDecode.dll" to your c:\Program Files\AviSynth 2.5\plugins directory.
As of 20-Sep-2007, we have data on over 100 Intel-based systems and on over 40 AMD-based systems. There are a few trends I picked-up on while browsing through the database. I put them into a single table and color coded them to make them easier to see. If you see a trend I missed, lemme know and I'll add it to the table.
Request: we don't have a single example of a machine that has both WinXP and WinVista on it. If you have a dual-boot setup, it would be cool to see the difference the O/S makes. Another missing trend is a 32-bit O/S vs. the same O/S that's 64-bit.
On to the table:
Yellow: Nearly 1:1 increase by adding an additional processor to a dual-chip MB
Orange: Some operating systems seem to handle x264 more efficiently than others
Red: Insignificant gain by upping the DRAM speed by 50 %
Blue: For the most part, these chips scale in a pretty linear fashion
Green: Tighter/looser memory timings have a pretty insignificant effect
Purple: Keeping the same over-all clock speed using a different combo of multiplier and FSB can give pretty insignificant gains
Again, I only gave this a once-over look; please point out any trends you see that I missed and also don't forgot about the O/S request!
Thanks again to all who contributed!
Request: we don't have a single example of a machine that has both WinXP and WinVista on it. If you have a dual-boot setup, it would be cool to see the difference the O/S makes. Another missing trend is a 32-bit O/S vs. the same O/S that's 64-bit.
On to the table:
Yellow: Nearly 1:1 increase by adding an additional processor to a dual-chip MB
Orange: Some operating systems seem to handle x264 more efficiently than others
Red: Insignificant gain by upping the DRAM speed by 50 %
Blue: For the most part, these chips scale in a pretty linear fashion
Green: Tighter/looser memory timings have a pretty insignificant effect
Purple: Keeping the same over-all clock speed using a different combo of multiplier and FSB can give pretty insignificant gains
Again, I only gave this a once-over look; please point out any trends you see that I missed and also don't forgot about the O/S request!
Thanks again to all who contributed!
Updated the tables with another 45 nm chip: the QX9650 -- both at stock levels and @ overclocked to 4.2 GHz! With it, and the others (Xeon E5330 (Dual board), Q9550, and Q9350) there is now data on 4 different 45 nm chips.
One thing that I found striking about these new chips is that they are only marginally faster than their 65 nm counterparts when encoding x264 (about 5-6 % faster with all other factors being equal or close to equal). Have a look at the general trends table for the Kentsfield vs. Yorkfield comparison at the official host.
One thing that I found striking about these new chips is that they are only marginally faster than their 65 nm counterparts when encoding x264 (about 5-6 % faster with all other factors being equal or close to equal). Have a look at the general trends table for the Kentsfield vs. Yorkfield comparison at the official host.
First off, thanks to all who contributed data.
24-Feb-2008 - Finally updated the data tables on the x264 benchmark page. They are now html based (not .gif images) which makes my life updating them much easier and I will keep this tables up-to-date daily as people post results. Have a look at the 'Data Tends' table that contains a look at the Phenom quad vs. both Kentfield and Yorkfield quads. There are also some comparisons of Wolfdale dual vs. Conroe dual, and some other good stuff.
24-Feb-2008 - Finally updated the data tables on the x264 benchmark page. They are now html based (not .gif images) which makes my life updating them much easier and I will keep this tables up-to-date daily as people post results. Have a look at the 'Data Tends' table that contains a look at the Phenom quad vs. both Kentfield and Yorkfield quads. There are also some comparisons of Wolfdale dual vs. Conroe dual, and some other good stuff.
shouldn't a Q6600 @ 3.0 get much faster results than this?
this is my task manager , notice the *32 deal,whatdoes that mean ?
running XP64 bit here for now.
---------- RUN1PASS1.LOG
encoded 1442 frames, 62.31 fps, 3905.42 kb/s
---------- RUN2PASS1.LOG
encoded 1442 frames, 61.61 fps, 3905.42 kb/s
---------- RUN3PASS1.LOG
encoded 1442 frames, 61.86 fps, 3905.42 kb/s
---------- RUN4PASS1.LOG
encoded 1442 frames, 62.23 fps, 3905.42 kb/s
---------- RUN1PASS2.LOG
encoded 1442 frames, 16.78 fps, 3952.85 kb/s
---------- RUN2PASS2.LOG
encoded 1442 frames, 16.82 fps, 3952.85 kb/s
---------- RUN3PASS2.LOG
encoded 1442 frames, 16.80 fps, 3952.85 kb/s
---------- RUN4PASS2.LOG
encoded 1442 frames, 16.78 fps, 3952.85 kb/s
this is my task manager , notice the *32 deal,whatdoes that mean ?
running XP64 bit here for now.
---------- RUN1PASS1.LOG
encoded 1442 frames, 62.31 fps, 3905.42 kb/s
---------- RUN2PASS1.LOG
encoded 1442 frames, 61.61 fps, 3905.42 kb/s
---------- RUN3PASS1.LOG
encoded 1442 frames, 61.86 fps, 3905.42 kb/s
---------- RUN4PASS1.LOG
encoded 1442 frames, 62.23 fps, 3905.42 kb/s
---------- RUN1PASS2.LOG
encoded 1442 frames, 16.78 fps, 3952.85 kb/s
---------- RUN2PASS2.LOG
encoded 1442 frames, 16.82 fps, 3952.85 kb/s
---------- RUN3PASS2.LOG
encoded 1442 frames, 16.80 fps, 3952.85 kb/s
---------- RUN4PASS2.LOG
encoded 1442 frames, 16.78 fps, 3952.85 kb/s
@Mark - Yeah, my guess is that you actually downloaded and run the HD x264 benchmark. This thread that you posted to is the "older" SD benchmark. The video size is smaller on the SD version. Your results are inline with other Q6600 systems running the HD benchmark.
The * in your taskmanager is normal and means it's a 32-bit application. x264.exe is not 64-bit native nor is avisynth.
Thanks for the results; I'll add them to the table shortly if you can give me some additional hardware details:
# Your multiplier and FSB settings for the test
# Your motherboard's chipset
# Your memory timings (just the first 4) and the speed at which you're running your memory
# Also let me know if it's DDR2 or DDR3
# Your operating system
You can get all the info from CPUz.
The * in your taskmanager is normal and means it's a 32-bit application. x264.exe is not 64-bit native nor is avisynth.
Thanks for the results; I'll add them to the table shortly if you can give me some additional hardware details:
# Your multiplier and FSB settings for the test
# Your motherboard's chipset
# Your memory timings (just the first 4) and the speed at which you're running your memory
# Also let me know if it's DDR2 or DDR3
# Your operating system
You can get all the info from CPUz.