Comments on: ZMBV Tinkering http://multimedia.cx/eggs/zmbv-tinkering/ Topics On Multimedia Technology and Reverse Engineering Sun, 06 May 2012 18:52:47 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Kostya http://multimedia.cx/eggs/zmbv-tinkering/comment-page-1/#comment-105328 Kostya Sun, 11 May 2008 07:55:48 +0000 http://multimedia.cx/eggs/zmbv-tinkering/#comment-105328 First of all, Michael's code explained: he used table to estimate entropy (well, base term from the Shannon's theory of information) of the XOR'ed block. In other words, the higher count of the same symbols, the lower entropy and the better compression of the block. 0-th order means he didn't use context to estimate entropy. Arithmetic coding can enlight you more ;) As for the codec, my intent was to have lossless encoder especially for 8-bit videos, for FFmpeg could not code them efficiently. (Un)fortunately, ZMBV was not designed with extensibility in mind, so next version bitstream will be totally different from current one. So you can think up a totally new scheme. Some of my thoughts: * everybody ends up with block-based compression (well, not always, but exceptions are rare) * there are usually those methods applied to each block: totally new block, skipping, applying changes (with a mask), filling block with colour, filling block with N colours using some pattern (coded or one from the standard ones); motion compensation is a bit rare and so it quadtree encoding employed by KMVC * none of the fancy things like transform, spatial prediction and context-dependent coding have been tried. They are too slow for the supercool 386SX I guess. Also you may want to look at http://x264dev.blogspot.com/2008/05/introducing-photon.html Looks like a lot of developers want to create their own codec ;) And the last thing - I think skip frames can be coded as the single byte by ZMBV too if you skip compressing at all (and decoder should handle it too). First of all, Michael’s code explained: he used table to estimate entropy (well, base term from the Shannon’s theory of information) of the XOR’ed block. In other words, the higher count of the same symbols, the lower entropy and the better compression of the block. 0-th order means he didn’t use context to estimate entropy. Arithmetic coding can enlight you more ;)

As for the codec, my intent was to have lossless encoder especially for 8-bit videos, for FFmpeg could not code them efficiently.

(Un)fortunately, ZMBV was not designed with extensibility in mind, so next version bitstream will be totally different from current one. So you can think up a totally new scheme.

Some of my thoughts:
* everybody ends up with block-based compression (well, not always, but exceptions are rare)
* there are usually those methods applied to each block: totally new block, skipping, applying changes (with a mask), filling block with colour, filling block with N colours using some pattern (coded or one from the standard ones); motion compensation is a bit rare and so it quadtree encoding employed by KMVC
* none of the fancy things like transform, spatial prediction and context-dependent coding have been tried. They are too slow for the supercool 386SX I guess.

Also you may want to look at
http://x264dev.blogspot.com/2008/05/introducing-photon.html
Looks like a lot of developers want to create their own codec ;)

And the last thing – I think skip frames can be coded as the single byte by ZMBV too if you skip compressing at all (and decoder should handle it too).

]]>