drm-next-3.14.0-20140407.patch.xz available

New patch against 3.14 which backports drm from 3.15-rc1-pre:

http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

A new screenshots comparator and loads of new x264 x265 vp8 vp9 tests

hobbit_1-756kbps--x264_x265_vp8-ssim_analysisI bought the Blu-ray of “The Hobbit: An Unexpected Journey” (which is considered to be a reference for video quality) and I decided to do more codec tests. If you want to know something about my methodology please read my previous article. I ripped a scene from the Blu-ray and I cropped it to 1920×800, then I compressed it using x264 LOSSLESS compression. Except for the crop it is bit identical with the Blu-ray.

I will not go in the details because I already explained everything, also I coded a new screenshot comparator which eases the job: use it to find the details about sources, codecs, etc.. like the exact command line with the parameters I used. It also allows you to download the sample videos. It took quite a while to code it, it uses XML to store data and it quickly grown to ~200 lines of code so please let me known if something’s wrong. I know, the graphic sucks but I hate web programming :)

Just some considerations… First of all: where is VP9? There isn’t. Why? Because after a whole week it still didn’t finish encoding. Seriously, using a wooden abacus would be faster! If someone wants to waste his cpu cycles to encode it, please send me the resulting files. You can download the source video using the screenshot comparator and encode it with this command:

ffmpeg -v 0 -i hobbit_lossless.mkv -threads 4 -vsync 0 -an -pix_fmt yuv420p -f yuv4mpegpipe - | ./vpxenc - -o hobbit.vp9 --codec=vp9 --cpu-used=0 --best --target-bitrate=756 -p 2 --pass=1 --fpf=vp9.stat; ffmpeg -v 0 -i hobbit_lossless.mkv -threads 4 -vsync 0 -an -pix_fmt yuv420p -f yuv4mpegpipe - | ./vpxenc - -o hobbit.vp9 --codec=vp9 --cpu-used=0 --best --target-bitrate=756 -p 2 --pass=2 --fpf=vp9.stat

Also, someone ranted because of lack of PSNR/SSIM graphs. Who needs SSIM when you can use your eyes? Anyway, here is the shiny graph and here is how I created it:

./qpsnr --ignore-fps -a avg_ssim -o blocksize=16:fpa=24 -r hobbit_lossless.mkv hobbit_crf28_756kbps.h265 hobbit_756kbps.h264 hobbit_756kbps.vp8 > ssim-fpa24.csv

Then you can use Libreoffice Calc to make the graph.

Some notes about the graph: yeah this is a completely different scenario from the previous test and x265 wins hand down. But beware, this is just with a VERY low bitrate. I encoded the source with x265 using CRF 28 which resulted in a 756 kbps bitrate, then I two pass encoded using x264 and vp8 with a 756 kbps target bitrate: this is the resulting SSIM graph. If you raise the bitrate there are no such big advantages using x265 over x264 which is a pity. Link. Source vs x265.

I did another encoding starting with x265 CRF 23 which resulted in a 1733 kbps bitrate. Link. Source vs x265.

Finally I did two more tests with x265 16 bit variables CRF 28 and 23: 943 kbps and 1186 kbps. I used x264 hi10p to match the file size. I just discovered “16bpp” doesn’t mean high bit depth in x265, anyway it’s bugged and shouldn’t be used right now.

Here is the SCREENSHOT COMPARATOR. Press F11 to switch your browser to the full screen mode.

Who washed my video? x264 vs x265 ‘placebo’ comparison

I wanted to know something about the actual x265 development state and since I didn’t find anything up to date I decided to do my own tests.
First of all I compiled a recent snapshot of x265:

./x265 --version
x265 [info]: HEVC encoder version 0.7+259-5e2043f89aa1
x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX

x264 –version
x264 0.142.2389 956c8d8
built on Feb 21 2014, gcc: 4.8.2
configuration: –bit-depth=8 –chroma-format=all
x264 license: GPL version 2 or later

This is my 112s / 216MB test video:
https://mega.co.nz/#!eQhSjJQR!EEe8-taN5IspIu-RW0WQzmvKzc5fkCn282kS5ugZ_as

Let’s encode it using x265 first:

ffmpeg -v 0 -i ~/PlanetEarthBirds.mkv -threads 4 -vsync 0 -an -pix_fmt yuv420p -f yuv4mpegpipe - | ./x265 - --y4m --preset placebo --crf 28 -o prova.h265

As you can see I used ffmpeg to decode the video and then I piped the raw stream to the x265 encoder. I did a quality based encoding with the default crf (28) which gives low quality but low size output files (considering my source isn’t lossless this is exactly what I want to easily spot differences with x264).

Then I generated a file of the very same size using two pass encoding with x264:

ffmpeg -v 0 -i ~/PlanetEarthBirds.mkv -threads 4 -vsync 0 -an -pix_fmt yuv420p -f yuv4mpegpipe - | x264 - --demuxer y4m --preset placebo -o prova.h264 --pass 1 --bitrate 3310
ffmpeg -v 0 -i ~/PlanetEarthBirds.mkv -threads 4 -vsync 0 -an -pix_fmt yuv420p -f yuv4mpegpipe - | x264 - --demuxer y4m --preset placebo -o prova.h264 --pass 2 --bitrate 3310

Here is the result:

-rw-r--r-- 1 niko niko 46094455 22 feb 04.19 prova.h264
-rw-r--r-- 1 niko niko 46238768 21 feb 21.26 prova.h265

As you can see prova.h264 is 46094455 bytes (~45MB) while prova.h265 is 46238768 bytes (~45MB). The video encoded with x264 is just 0.14MB smaller which is a 0.3% difference.

Using the placebo presets I used the slowest settings which are supposed to give the best quality for both encoders.
Having to use two pass encoding for x264 to make a meaningful comparison there is no sense comparing encoding speed, so I will not do it.

Here are the encoded files:
prova.h264
prova.h265

Anyway we can compare DECODING speeds :)
Let’s decode them as fast as we can using ffh264 (FFmpeg H.264) and ffhevc (FFmpeg HEVC / H.265):

mplayer -benchmark -nosound -lavdopts threads=16 prova.h264 -vo null 2> /dev/null

BENCHMARKs: VC: 5.640s VO: 0.003s A: 0.000s Sys: 0.333s = 5.976s
BENCHMARK%: VC: 94.3730% VO: 0.0482% A: 0.0000% Sys: 5.5788% = 100.0000%

mplayer -benchmark -nosound -lavdopts threads=16 prova.h265 -vo null 2> /dev/null

BENCHMARKs: VC: 26.936s VO: 0.003s A: 0.000s Sys: 0.360s = 27.300s
BENCHMARK%: VC: 98.6680% VO: 0.0123% A: 0.0000% Sys: 1.3197% = 100.0000%

As you can see the video encoded with x264 took 5.976s to decode while the x265 one took 27.300s.
h265 actually takes 4.6x more time than h264 to decode. Not bad, really.

Let’s take some screenshots:

mplayer -lavdopts threads=16 -nosound -benchmark -fps 23.976 -vf framestep=275 -vo png:z=9 prova.h264; for i in `ls -l *png | awk '{ print $9 }' | grep -v h26 | grep -v source`; do mv $i x264-test1-$i; done
mplayer -lavdopts threads=16 -nosound -benchmark -fps 23.976 -vf framestep=275 -vo png:z=9 prova.h265; for i in `ls -l *png | awk '{ print $9 }' | grep -v h26 | grep -v source`; do mv $i x265-test1-$i; done
mplayer -lavdopts threads=16 -nosound -benchmark -fps 23.976 -vf framestep=275 -vo png:z=9 ~/PlanetEarthBirds.mkv; for i in `ls -l *png | awk '{ print $9 }' | grep -v h26 | grep -v source`; do mv $i source-test1-$i; done

Finally, let’s compare them:

x264 vs x265
http://files.linuxsystems.it/functions/comparison.php?test=test1&codec1=x264&codec2=x265&number=1
http://files.linuxsystems.it/functions/comparison.php?source=planetearthbirds&bitrate1=3310&codec1=x265-0.7-259-5e2043f89aa1-8bpp-placebo&bitrate2=3310&codec2=x264-0.142.2389-956c8d8-8bpp-placebo&n=10&current=1

source vs x265
http://files.linuxsystems.it/functions/comparison.php?test=test1&codec1=source&codec2=x265&number=1
http://files.linuxsystems.it/functions/comparison.php?source=planetearthbirds&bitrate1=source&codec1=x265-0.7-259-5e2043f89aa1-8bpp-placebo&bitrate2=3310&codec2=x265-0.7-259-5e2043f89aa1-8bpp-placebo&n=10&current=1

Press F11 to switch your browser to the full screen mode and click on the image to switch from the x265 screenshots to source or x264. I also put some previous/next buttons (there are 10 png screenshots in total).

I don’t want to be critical because x265 is still in early stages of development, but as you can see it completely washed the video: details are gone. Sometimes x265 did a better job but overall x264 definitely wins.
Keep up the good work devs ;)

drm-next-3.13.0-20140130.patch.xz available

New patch against 3.13 which backports drm from 3.14-rc1-pre:
http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

drm-next-3.13.0-20140121.patch.xz available

New patch against 3.13 which backports drm from 3.14-rc1-pre:
http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

drm-next-3.12.0-20131117.patch.xz available

New patch against 3.12 which backports drm from 3.13-rc1-pre:
http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

drm-next-3.12-20131109.patch.xz available

New patch against 3.12 which backports drm from 3.13-rc1-pre:
http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

raspbian wheezy 20130923 available

I updated my Raspbian Wheezy minimal image, raspbian_wheezy_20130923.img.7z is available here:
http://www.linuxsystems.it/raspbian-wheezy-armhf-raspberry-pi-minimal-image/

- New kernel.
- New firmware.
- Fixed an issue when booting without network.
- Fixed an issue with vc libs.
- Added mouse input in console.

New section: Linux DRM graphic stack backports

You can find my patches to apply on top of the latest stable kernel here:
http://www.linuxsystems.it/linux-drm-graphic-stack-backports/

raspbian wheezy 20130917 available

I finally updated my Raspbian Wheezy minimal image, raspbian_wheezy_20130917.img.7z is available here:
http://www.linuxsystems.it/raspbian-wheezy-armhf-raspberry-pi-minimal-image/