[x264-devel] Re: JM 9.6 vs. x264 rev 228: results

Tuukka Toivonen tuukkat at ee.oulu.fi
Thu May 19 15:36:19 CEST 2005


On Thu, 19 May 2005, Tom Jacobs wrote:

>  by settings the -q switch does this make the encoder encode to a
> specific psnr?

No. -q sets just the QP value, and then it depends on the video what will 
the PSNR be.

I'll copy, paste & edit a piece from a report I wrote:

>>>
Each test sequence was encoded with nine different fixed quantization 
parameter levels between 20 and 36. At each quantization parameter level 
the absolute bitrate and peak signal to noise power ratio (PSNR) was saved 
into log file, yielding rate-distortion graph, which is the leftmost image 
of each image pair at the web page (or the snapshot.png).

To compare the bitrates between the two encoders at the same PSNR, cubic 
interpolating splines were used to find out bitrates corresponding to the 
other encoder at the PSNRs obtained for it. When the bitrate for each 
benchmarked encoder is known at the same PSNR, the relative bitrate can be 
easily calculated at the nine sample points and shown in a graph at the 
right side of the image pair.

After the interpolated relative bitrate graphs (at right column) have been 
generated for each of the test image sets, the graphs are averaged. This 
produces another graph shown at the top of the page.

The bitrate change is more useful measure of a compression method than 
PSNR, because PSNR is not always a good measure of the subjective image 
quality, although the testing methodology still assumes that a given fixed 
PSNR corresponds roughly to the same image quality.
<<<

A wrote a set of shell/perl scripts to do the tests:
http://www.ee.oulu.fi/%7Etuukkat/mplayer/tests/x264test3/test-jm.sh
http://www.ee.oulu.fi/%7Etuukkat/mplayer/tests/x264test3/test-x264.sh
http://www.ee.oulu.fi/%7Etuukkat/mplayer/tests/x264test3/plot-bitred.pl
http://www.ee.oulu.fi/%7Etuukkat/mplayer/tests/x264test3/plot-results.sh
http://www.ee.oulu.fi/%7Etuukkat/mplayer/tests/x264test3/plot.sh
They contain various stuff including the spline
interpolation routines, but there isn't documentation...

> and then you just look at the size of the resulting file to
> see the bitrate?

Actually, I use the bitrate that x264/JM reports at the end.
But it corresponds to the file size.

> bits/pixel simple calculated from the file size / total
> pixels   (sounds a stupid question now ive wrote it)

Basically, yes. Or more actually,
   bits/pixel = bitrate / (pixels per second)
   pixels per second = width * height * fps
   width = 352
   height = 288
   fps = 30

>forgot to ask on last post but where can i get hold of all of them video
>sequencies?

I don't know any single place or remember any place where to get them..
try using google... or if there is an ftp place where I can upload
the sequences (around 2 GB total)... I'm not sending them by email, anyway 
=)

> i have coastguard, foreman, mobile, paris from your list and
>three additional ones container, garden, hall_monitor. ive got varrious

I don't have garden... I'd like to have it :)

>others like rotating_city and snowfall in seperate ppm files have just got
>to work out the command in 'convert' to change them into one big yuv file.

ppm files store images in RGB and if you convert them to YUV, there will
be a quality loss, which is a bad thing (mainly because
if other people use slightly different formula for conversion,
they could get different results).

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list