FraKtus rants and fun videoz

At ArKaos we always fight to get the best out of current computer configuration regarding media playback.

When you are in the show industry and try to pick the best way to compress your content it’s still a little bit of black magic. While some codec do compress well video they are heavy to handle for the machines, even more, the codec that does the best job at compressing while keeping a good quality such as H264 are very bad when you need to scratch your media.

The best codec for artists that need to interact a lot with the content should allow to play forward and backward easily and should allow to jump into the content quickly.

Some have experimented with using a file format that is designed by the companies making the graphic chips of your computer. This file format is based on texture compression DXT1 DXT3 or DXT5.

I was wandering how hard it would be to add that file support to QuickTime inside a new codec. Being programing for the QuickTime API since it’s version 1.0 beta I was considering the challenge fun and interesting.

So I resuscitated an old sample code from 1999 on the apple web site and after a few hour I had a codec having my name and generating video files that could be played back by the QuickTime player.

I jumped then on the DXT texture compression problem and picked the squish library to handle texture compression. A few more hours and I had a working codec.

 

 

 

 

This codec when used by QuickTime is not efficient because the texture decompression is done on the CPU and so you don’t see the advantage of using the GPU to handle that texture format.

To demonstrate the speed up I used an experimental player I am working on and patched ffmpeg to handle that new codec I just created. Thanks to that I can leave the texture datas untouched and pass them to the GPU via the OpenGL extensions regarding texture compression.

When this was done I could enjoy the show and make some performance tests, file size is in MB and CPU load is taken from running top in the console:

name	resolution	data	H264	Photo JPEG	Dxt1	Dxt5	Dxt1 Compressed	Dxt5 Compressed
Alternate Rotate DI	640*480	File Size	9,3	14,3	22	43,9	17,5	19,7
Â	Â	CPU Load	31	30	7	9	15	18
Â	Â	Â	Â	Â	Â	Â	Â	Â
1920 HD	1920*1080	File Size	36,5	41,8	90	180	55,7	63,8
Â	Â	CPU Load	99	95	13	22	42	56
Â	Â	Â	Â	Â	Â	Â	Â	Â
T25 Random Twirls	1280*720	File Size	35,9	73,2	65,9	131,8	51,5	58,4
Â	Â	CPU Load	78	72	10	16	32	41
Â	Â	Â	Â	Â	Â	Â	Â	Â

If you are curious regarding frame quality here is a part of an original frame:

 

 

Here is the a part of the same frame using Dxt1

 

 

 

And here is a part of the same frame with Dxt5 compression:

 

 

 

The results of my test is that pure Dxt1 regarding CPU load is the best format, Dxt5 is better regarding quality but generate twice heavier files. Using Dxt1 I could play 7 HD loop at the same time with my laptop … if the data rate of my hard drive would allow it!

The problem with pure Dxt1 or Dxt5 files is that they are huge, 4 times bigger than photo jpeg or H264. To go around that I experimented with using data compression on the CPU because the CPU is now almost unused!

So using Dxt1 Compressed texture is the best solution regarding CPU usage and disk usage. The size is almost the same than photo jpeg and a little bit bigger than H 264. When using the CPU to decompress the texture data from disk the codec is still twice faster than any other codec I tested.

On my MacBook pro I can’t play a full HD loop and even at 1280*720 my machine is struggling. Using Dxt1 compressed I can play 2 HD layers and 3 720p layers.

I made available the test player I used and a set of video loops. This dmg file is for Mac OS X x86 only (no Power PC), so if you are curious here are the files:

CompressedTextureDemo.dmg (435 MB)

We will bundle that codec experiment in the next update of GrandVJ and MediaMaster, that’s for sure!