Lair Of The Multimedia Guru

The default wavelet used by the snow codec in ffmpeg is a symmetric biorthogonal compact 9/7 wavelet with rational coefficients with properties very similar to the famous biorthoginal daubechies 9/7 wavelet, it was found by bruteforce search with the goal of having a simple lifting implemenattion and having many vanishing moments or almost vanishing moments, the daubechies wavelet has (4,4) our wavelet has (4,2) vanishing moments
The lifting coefficients are:

The resulting wavelet and scaling functions look like:

One thing which is still annoying is the 4/5, while this can be approximated pretty well by a multiplication and a shift right but this tends to overflow so something like

x += x+x;
x += x>>4;
x += x>>8;
x >>= 2;

is needed, this one only differs from 4/5 by a factor of ~0.00001, alternatively the 4/5 can be merged into the unquantization step so that

\ | /|\ | /|\ | /|\ | /|\
 \|/ | \|/ | \|/ | \|/ |
  +  |  +  |  +  |  +  |   -15/32
 /|\ | /|\ | /|\ | /|\ |
/ | \|/ | \|/ | \|/ | \|/
  |  +  |  +  |  +  |  +   -4/5
\ | /|\ | /|\ | /|\ | /|\
 \|/ | \|/ | \|/ | \|/ |
  +  |  +  |  +  |  +  |   +1/16
 /|\ | /|\ | /|\ | /|\ |
/ | \|/ | \|/ | \|/ | \|/
  |  +  |  +  |  +  |  +   +3/2
is changed to
\ | /|\ | /|\ | /|\ | /|\
 \|/ | \|/ | \|/ | \|/ |
  +  |  +  |  +  |  +  |   -3/8
 /|\ | /|\ | /|\ | /|\ |
/ | \|/ | \|/ | \|/ | \|/
 (|  + (|  + (|  + (|  +   -1
\ + /|\ + /|\ + /|\ + /|\  +1/4
 \|/ | \|/ | \|/ | \|/ |
  +  |  +  |  +  |  +  |   +1/16
 /|\ | /|\ | /|\ | /|\ |
/ | \|/ | \|/ | \|/ | \|/
  |  +  |  +  |  +  |  +   +3/2

Now lets compare quality between the snow and daubechies 9/7 wavelets, this comparission has been done with JasPer with this change and tinypsnr (from ffmpeg) The used test image was the 256×256 lena grayscale image

A while ago searching around on ebay for geeky/nerdy toys i found some Thermoelectric coolers/peltiers for around 2$ with free shipping. So i bought a few of them …

They all worked fine, one had a hole in its silicon sealant though which ive “fixed” with hot glue (first heated the element up to reduce moisture inside then re-sealed it), i dont remember why i didnt use silicon …

I experimented a bit around with 1 and 2 stage TECs on a old heat-sink + fan that was laying around, the best combination interestingly was 2 stages first at 12V 2nd at 5V. though the gain for 2 stages over 1 stage was disappointingly small, IIRC a little over 10°C. Its also interesting to note that my chinese IR thermometer was not able to measure the temperature of the frosted top, it displayed way too low values. Actual real lowest value achieved was measured with a Type K thermocouple, frozen onto the TEC in a drop of water and frosted over for a while (the snowy stuff that forms should provides some extra isolation).

The 2 TECs in above are attached with cable ties, which was very limiting in what could be placed on top

For some reason yesterday i decided to test using the TECs for heating instead of cooling by reversing the input polarity.
That indeed worked and the same device happily boiled drops of water. I didnt think too deep about what the maximum temperature for the TECs was, i didnt expect failure below 180°C, but the top element died at probably around 120-130°C (K type thermocouple in drop of oil on top).
Not entirely believing the apparent facts, i picked another unused separate TEC1-12706 and retried, heating it to 160°C
which seems to have done no harm to it. Though i used the IR thermometer for measuring the 160°C, i should retry this probably with both thermometers but then according to the ebay article page they are max 70°C ;)

Breaking my TEC cooler toy i took it and the failed TEC element apart, Its failure mode was that it showed >10megohm resistance. Cutting its sealant away, it looked like this:

And separating it further with a tiny bit of heat and force (probably only heat was needed)

Also interestingly none of the remaining individual elements tested open, they all had low resistance. I know nothing about TEC failure modes but i wonder if one little part had just cracked from the heat and maybe mechanical stress. They are all in series so one cracking the wrong way should show similar symptoms …

To rebuild the TEC2-toy now ver2, i placed a piece of aluminum on top and tried to attach it with cable ties, but this proofed frustratingly unstable

My next idea of fixing it with screws, bolts, nuts or such wasnt an option as i lacked parts of sufficient length with non ridiculous diameter. So i cut 2 pieces of the same aluminum stuff and fixed it with 4 springs created out of a single larger spring separated by some foamy stuff for isolation:

In action:

Also i tested cooling and heating of a glass container with a liquid. (for cooling a drop of water was used as thermal component between glass and aluminum for heating a drop of minnaral oil). Without isolation, the temperature fell to +9.5°C in 1 hour and with some isolation to prevent the warm air from the fan hitting the container, to +2°C in another hour. Iam quite sure sub zero is achievable with a real attempt to prevent coolness loss but i kind of lost patience.
on the hot side i achieved 67°C with the TEC itself being at around 100°C, so if one would risk damaging the unit it might be possible to boil water in a container with it.

What has happened in the last ehm week since the previous weekly news, well alot …

• some ffserver-IPv6-linux fix by Nicolas George
• some ffserver-IPv6-macosx fix by Ronald S. Bultje
• flv files with invalid headers work again after a fix by me
• a vorbis decoder crash after “floor0 dec: booknumber too high” has been fixed by me
• make ffmpeg stop if writing fails instead of continuing by me
• split adx into adxenc.c and adxdec.c by aurel
• improvements to the mpeg-ps detection which fix several mp3 files which where misdetected as mpeg-ps, by me
• make the NellyMoser decoder use our generic mdct, finding out how to do this and doing it by fabrice
• Electronic Arts XAS ADPCM decoder by peter ross and aurel
• Electronic Arts .cdata demuxer by peter ross and aurel
• RICE2 entropy coding and variable block size for flac support by Josh Coalson
• reorder codec registration to prefer native implementations by diego
• Warn user if bitrate parameter is too low by ramiro (using 100 instead of 100k was a pretty common cause of silly bug reports …)
• List enabled code in configure output by ramiro
• Remove libvorbis Vorbis decoding support by diego (our vorbis decoder IS bugfree :) at least as far as we know)
• fix interlaced_frame flag for h.264 by jeff downs and Reinhard Nissl
• dont send hundreads of RTCP packets by luca abeni
• adpcm-ima encoder bugfix by Timofei V. Bondarenko
• some of the MMS patches by Björn Axelsson hit svn, still quite a few to go
• various h.264 fixes by Jeff Downs
• Musepack SV8 demuxer and decoder by kostya
• a-law/mu-law/16bit PCM support in SDP by luca abeni
• ipv6/ipv4 udp cleanup by luca abeni
• MPEG2 in RTP muxer support by luca abeni
• split audio and video grabbing code into libavdevice by luca abeni
• split wmv2 in its own files by aurel
• intrax8 decoder by “someone”, now finally we can decode all wmv2 files
• export top_field_first flag for h.264 by Reinhard Nissl
• our own ogg muxer written by Baptiste, now finally you can store your music and videos in the worst container ever designed without having to depend on libogg
• remove libogg support by Baptiste
• 44.1kHz support and various other small improvements for our nellymoser decoder by alex
• flv v9 32bit pts support by alex
• remove important functions from snow by diego
• mpegts demuxer segfault fix by jeff
• Optimize memory management and some cleanup of the rm demuxer by roberto
• remove perror() usage and take meassures against its reintroduction by luca abeni
• dynamically allocate ByteIOContext in AVFormatContext so changes to it dont break the ABI by Björn Axelsson
• VC-1 MMX DSP functions by Christophe GISQUET
• part of the RV30/RV40 patchset from kostya hit svn, the rest should likely hit svn soon as well assuming i and kostya arent too lazy
• pcm_s16le_planar support for electronicarts files by aurel
• some stuff needed for OS/2 support by Dave Yeo
• split vc1dsp_mmx out into its own compilation unit by aurel
• MLP/TrueHD parser by Ian Caulfield
• pause/play/seek support for the protocol API by Björn Axelsson
• wma sound artefact fix by reimar
• change british english to amerikan by diego and others, yes we all hate british english :)
• make our rm muxer generate files playable by realplayer by kostya, i guess this once worked already in the past …
• dnxhd 720p encoding and decoding support by baptiste
• improvments to the mp3 detection by me
• fix asf muxer so that asf files work better on win ce by me
• Adpcm_swf regressions tests by benjamin
• several segfault fixes in the mov demuxer by baptiste and takis
• Many small fixes by various people ive been too lazy to list

Missing things, duplicated entries and wrong entries as well as spelling errors are unintended, if you find anything missing/wrong/duplicated tell me and ill fix it, dont bother telling me that every second word contains a typo i do know that already :)

I always wanted to write my own general purpose compressor, a short while ago i actually did. Its based on the BWT + MTF variant described in yesterdays blog post + snows/ffv1s range coder with a state transition table borrowed from bbb/paq8 source code under GPL is of course available too.

compressed file sizes of the Canterbury Corpus

Time needed to compress

time needed to decompress

Options used where -9 for bzip2, -mx=9 for 7zip, f for bbb to use fast but memory hungry mode (this doesnt affect compression rate for bbb). The benchmark score are just single run based no proper mean so dont take them too serious, and i hope ive not messed up the file order ;)

Patches are welcome!

FFmpeg supports iterative motion estimation, but only for snow. It would be interresting to implement/port this code to the generic mpeg framework (motion_est.c/mpegvideo.c/h) in ffmpeg

This task requires:

1. Reading and understanding the generic motion estimation code
2. Reading and understanding the iterative motion estimation code in snow.c
3. Porting/Implementing iterative ME for the generic code

The advantage of iterative ME is higher quality per bitrate (but at higher computational cost).

Normal motion estimation tries to optimize each motion vector so as to minimize the weighted sum of the distortion (difference to the input picture) and the rate (bits for the motion vector). And after doing that for vector i, its done with i+1, then i+2 and so on, where all past vectors are held constant and all future ones are ignored. This is of course not correct, iterative motion estimation OTOH does not ignore any vectors but rather considers the bits of the future vectors too and performs several passes over all blocks until no further improvement is achived (=the search found a local minimum)

Ive added some -vf uspp (PP by (mis)using the snow codec) based images to pp vs. spp filters, the reason for uspp=6 instead of higher values is that higher ones wake the OOM-killer :-) the reason for the lack of pp=ac/ha/va based samples is that they look identical to the pp=de/hb/vb