X-QuaSaT - x264 settings quality/speed/bitrate analysation tool (download)

[mogobime]

Hi guys,

i coded a small tool to fully automatic change parameters of x264 settings to test them for speed, filesize and the resulting quality.
The tool changes parameters by itself within the ranges you define:

--->>> X-QuaSaT <<<---
[x264 Quality and Speed analyse Tool]

X-QuaSaT is a tool for automatic analysation of speed and quality that
different constellations of x264 settings result in, that shall help you to
find your optimal x264 settings.
The idea is to continuously let it raise the parameters of the x264-settings
- quantization
- reference-frames
- b-frames
- motion estimation
- Psy-rate distortion/trellis
in loop.

All of those settings can (if you want to, depends on your settings)
automatically be tested in all thinkable parameter-constellations with a
bunch of test-clips you put in X-QuaSaT's "VIDEOFILES" folder.
It will create a statistic-file, that shows you the effects of the combinated
parameters to:
- SSIM
- PSNR
- bitrate
- encoding speed
- quantitative usage of B-frames (BF_USED)
- quantitative usage of P-frames (PF_USED)
- quantitative usage of I-frames (IF_USED)
- effective usage of the CPU

It will build the average out of all used test clips and log every
parameter-constellation in one line.

You can also keep the temporary generated videos, to have a closer look on
some of them after having a look to the statistic file.

Other configurable parameters are:
- Pixel motion
- Pixel search range
- Trellis quantization
- Encodingmode
- Adaptive quantization mode
- Adaptive quantization strength

I added a screenshot of the main menue because a picture can say more than a thousand words



DOWNLOAD HERE:
http://forum.selur.de/topic193-xquasat-x264-settings-quality-speed-analyse-tool-download-here.html

Greetz to Selur and thanks for his testing-support and suggestions in the time of developing

Would be happy to get some feedback,

Cu

mogobime

[mogobime]

Changelog 1.06.07 (19.07.2012):

- quantitative usage of P+I-frames are shown in statistic-file
- start time in recover mode is now shown correctly
- some code optimizations

[mogobime]

I added a netload-link because some user replied, that he couldn't use the ftp-link. But the ftp-link still works and is faster.

[mogobime]

Changelog 1.6.10 (28.10.2012):

- Added 32 bit x264 support
- CPU-load measurement will now terminate correctly under Windows XP
- some more x264 errors will be detected

[mogobime]

NEWS 31.10.2012:

Some diagrams and graphical worked up x-QuaSaT statistics can be viewed at my new website:
http://x-quasat.redirectme.net
The Open Office ods-source tables and the csv-files they were created from are available, too.

[mogobime]

NEWS 02.11.2012:
Pooh, this was some hard work for me and my pc.
By the way, the big trellis comparison with html-tables and diagrams, based on X-QuaSaT statistic is ready on my website!
the diagrams and tables refer to quantizer 19+20 with trellis 0-2 (respectively reference-frames 5-9 and b-frames 3-11).
I marked at least the best three candidates with the help of a estimation matrix depending on quality, speed and bitrate.
Additionally there are bar diagrams showing quality / speed / bitrate of all tested combinations. Combinations that for example achived high quality because of a bitrate higher than average were ignored (they're marked grey in the tables).

I hope somebody has some usage for this.

Cu

mogobime

[mogobime]

Argh! I made a really bad mistake with the html tables and diagrams on the website. They were displayed unreadable inside the frame they were clicked.
Problem is solved now:
http://x-quasat.redirectme.net

[Mephesto]

Neat. My friend and I wrote a similar CLI script in the past, shoehorning several existing tools to automate quality comparison. But the results have already been conducted by MSU and Doom9 so there's little use in yet more tools like these. I'm not particularly interested in the most mathematically-correct efficient settings either way, if a codec takes 50% longer for 25% more quality with an extra parameter, I'll use that parameter.

[mogobime]

What do you wan't me to say? You didn't show a link to your script nor explain it exactly.
The current results on my website are only some examples.

Did/does your tool change parameters in loops, too?

All I can find on doom9 is a codec comparison from 2005.

This is a x264 benchmark tool which can be used by everybody to find out the personal x264 settings considering cpuload + quality + bitrate and speed (which is important for most people, too).

At present it raises the parameters subme, quantizer, b-frames, reference-frames and psy-rd automatically within defined limits and logs all resulting combinations, which can be hundreds if you want to.
Also the encoded clips can be kept to have a look on interesting results in the statistics-file.

[Mephesto]

It's somewhere deep in my old dusty archives, I don't have it at hand currently.

It did auto-tune the parameters in a cycle and report the metadata, SSIM and encoding speed.

I've tried your tool quickly and it refused to write to the .stats file if I remember right, complained of some sharing conflict, so I can't really evaluate it.

All I can find on doom9 is a codec comparison from 2005.

**** doom9, look at MSU's website. Here's their codec settings results:

http://www.compression.ru/video/codec_comparison/x264_options_analysis_08_en.html

Point is, this has already been done and x264 is nearing the end of its usefulness with H.265 about to be born.

[mogobime]

I've tried your tool quickly and it refused to write to the .stats file if I remember right, complained of some sharing conflict, so I can't really evaluate it.

That is really too bad, did you run it with admin rights and not use curious folder names with ! & in the name?
Next point is that if the statsfile is opened by some programs like openoffice, while the script tries to write to it, it will fail.

**** doom9, look at MSU's website.

I will do.

Point is, this has already been done and x264 is nearing the end of its usefulness with H.265 about to be born.

I don't think that you're right. It will take years to establish a new standard (and nobody knows if h.265 will really be very useful at first). Probably the most popular codec for ripping still is xvid...

[Mephesto]

That is really too bad, did you run it with admin rights and not use curious folder names with ! & in the name?

Yes and no. Screenshot attached.

Next point is that if the statsfile is opened by some programs like openoffice, while the script tries to write to it, it will fail.

statistics.log file to be exact, I had to redownload your tool and try again. Why would MS Office be locking a .log file?

I don't think that you're right. It will take years to establish a new standard (and nobody knows if h.265 will really be very useful at first).

The standard is already established, and an encoder is due in a couple months.

Probably the most popular codec for ripping still is xvid...

Because people are morons. I give no damn shit what's popular. I always use the latest and greatest.

To expand on your point, MPEG-2 will never die either and lots of people still use that, mainly porn sites. Flesh hustlers do tend to suck with the technical shit, go figure.

The biggest problem in the beginning of H.265 will be that the quality increase will not be OBVIOUS ENOUGH. It took 7 years after the release of x264 before at least HALF these hapless techno-gimps started to realize how much time they're wasting. YouTube itself was dipshit enough to operate at a loss of half a billion a year hosting GARBAGE QUALITY videos for almost half a decade.

And I still get to hear idiots even on this site talk about XviD being "warmer" quality.

[mogobime]

Yes and no. Screenshot attached.

Hmm shit... If i run the script from the "program files" folder access to logfile is denied.
If I execute a cmd window with admin rights and navigate to that folder all runs fine.
if i try to execute the script with "right click" -> "run as admin" it crashes immediately and at the moment i have no idea why.

Best solution I have at the moment is to run it from desktop with an admin user account...

Why would MS Office be locking a .log file?

you can switch the output file format to .csv table format, which can be read by ms excel/openoffice for a better overview.

I always use the latest and greatest.

Oh. A Windows 8 beta tester

The biggest problem in the beginning of H.265 will be that the quality increase will not be OBVIOUS ENOUGH.

and nobody knows about the hardware resources it will need. Possibly it will need a new cpu generation to be really useful. We will see.

[Mephesto]

Access is denied for me no matter which folder I run it from.

and nobody knows about the hardware resources it will need. Possibly it will need a new cpu generation to be really useful.

Naw, H.265 is aimed at lower computational complexity. Encoding will be faster. Decoding will be slower, but considering most i7 cpus today can playback 1080p in realtime with only one core (50% on mine) I really doubt twice the power for playback will be a problem.

I think last-generation CPUs will handle h.265 just fine.

Oh. A Windows 8 beta tester

Windows 8 sucks... -_-

[mogobime]

Access is denied for me no matter which folder I run it from.

does statistic.log exist or not?
Which OS (language-version?) do you use?

I'm parsing the dir command to compare filesize before and after writing - maybe in your language version the dir command differs from mine in a unexpected way?!?

Would be nice if you could copynpaste dir statistic.log>debug.txt in a cmd window opened at x-quasat directory and attach debug.txt here.

[Mephesto]

does statistic.log exist or not?

Affirmative.

Which OS (language-version?) do you use?

XP English-SP3

Don't know what you need this for, but here you go:

 Volume in drive C is X
 Volume Serial Number is X

 Directory of C:\Documents and Settings\Admin\Desktop\X-QuaSaT_1610

11/22/2012  04:27 PM               773 STATISTIC.LOG
               1 File(s)            773 bytes
               0 Dir(s)  920,548,306,944 bytes free

[mogobime]

Thx, i identified the problem.

the problem is how i'm parsing line 6 where the filesize is printed. In the german version the output of "dir" looks like this:

Datentr„ger in Laufwerk C: ist WINXP
Volumeseriennummer: X

Verzeichnis von C:\x-quasat

23.11.2012 18:54 275 statistic.log
1 Datei(en) 275 Bytes
0 Verzeichnis(se), 6.077.235.200 Bytes frei

"PM" is the problem in the us-version

EDIT:
New version on x-quasat.redirectme.net

Cu

mogobime

[mogobime]

Changelog 1.6.11 (23.11.2012):

- bugfix: statistic file write error isn't reported falsely anymore in non-german windows versions.