[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-codec-devel
Subject:    Re: [codec-devel] Low-complexity models for images or video?
From:       Michael Niedermayer <michaelni () gmx ! at>
Date:       2004-07-14 19:02:00
Message-ID: 200407142102.00404.michaelni () gmx ! at
[Download RAW message or body]

Hi

On Wednesday 14 July 2004 20:09, Jim Leonard wrote:
> A long-standing hobby of mine has been experimenting with new video methods
> for extremely low-CPU-power machines; my current favorite is the original
> IBM PC (CGA, 4.77MHz 8088, 1981).  I've done straight format conversion,
> delta packing, motion estimation, RLE, etc. and now I'm beginning to think
> my assembler skills are high enough to attempt something meatier.  Does
> anyone have any suggestions for very low complexity models/representation I
> should be looking into?  (Note that I am only talking about *playback* --
> actual compression will be done on an Athlon :-)
>
> One idea I had was vector quantization... I know that Cinepak (vector
> quantization, YUV colorspace conversion optimized for speed at expense of
> quality) works well on low-power machines; I've successfully experienced
> 160x120 @ 10fps playback on a 386/16 running Windows 3.1, and my Sega CD
> has a few titles that show off 80x60 @ 30fps (!) so it seems possible to
> some degree. MS-CRAM (created by Media Vision, licensed by Microsoft as "MS
> Video 1") is another VQ scheme I could look into...
>
> Another idea was block slant transforms or Haar transforms, but I don't
> have enough information on those -- are block slant and Haar the same?  If
> not, where can I find more information, preferably example code (in any
> language)?
>
> Any other ideas?
maybe the biorthogonal 5/3 wavelet would be interresting, its very simple, and 
should have much better quality/bitrate then the haar transform

the 1D transform for encoding is simply:
d[2i+1]-=(d[2i  ] + d[2i+2]    )>>1;
d[2i  ]+=(d[2i-1] + d[2i+1] + 1)>>2;

and decoding:
d[2i  ]-=(d[2i-1] + d[2i+1] + 1)>>2;
d[2i+1]+=(d[2i  ] + d[2i+2]    )>>1;

note: d must be large enough to avoid overflows, so if the source is 8bit d 
would need to be 16bit or it wont work very well, the second line also uses 
the result from the first as input in case its not obvious, and yes the 
transform is numerically invertible so it can be used for lossless 
compression

these transforms are simply applied horizontally & vertically, then again on 
the low frequency samples (the ones with even indexes both horizontally and 
vertically) which are just 1/4 as many
so if u do this 4 times u need to process x + x/4 + x/16 + x/64 samples

if the filtering would need a sample outside the filetred area 
(block/image/...) then the index is mirrored at the boundary:
image:   ABCD
source: BABCDC

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
xine-codec-devel mailing list
xine-codec-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-codec-devel
[prev in list] [next in list] [prev in thread] [next in thread]