VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 18 of 18
Thread
  1. 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
    Last edited by mogobime; 19th Oct 2012 at 08:21.
    Quote Quote  
  2. 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
    Quote Quote  
  3. 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.
    Quote Quote  
  4. 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
    Quote Quote  
  5. 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.
    Last edited by mogobime; 2nd Nov 2012 at 16:25.
    Quote Quote  
  6. 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
    Quote Quote  
  7. 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
    Quote Quote  
  8. 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.
    Quote Quote  
  9. 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.
    Last edited by mogobime; 11th Nov 2012 at 06:15.
    Quote Quote  
  10. 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.
    Quote Quote  
  11. 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...
    Quote Quote  
  12. Originally Posted by mogobime View Post
    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.
    Image Attached Thumbnails Click image for larger version

Name:	xstaterr.PNG
Views:	132
Size:	12.4 KB
ID:	14806  

    Quote Quote  
  13. 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.
    Quote Quote  
  14. 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... -_-
    Quote Quote  
  15. 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.
    Quote Quote  
  16. 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:
    Code:
     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
    Quote Quote  
  17. 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
    Last edited by mogobime; 24th Nov 2012 at 07:03.
    Quote Quote  
  18. Changelog 1.6.11 (23.11.2012):

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



Similar Threads