| cr88192 2004-06-24, 6:55 pm |
| some time recently I have been playing around with video compression (yes, I
know, a fairly pointless endevor given existing codecs, which are both
better looking and compress better, but whatever...).
comment on whether any of this makes any sense would be helpful.
I have played with a few algo's, with varying success.
two were based on difference between "miplevels" (dunno a better term, this
is just what I know).
eg: I half-sample the image some number of times (eg: 4 or 6) and determine
whether pixels fall within a certain "distance" of the value interpolated
between 2 points in each level, using the value in the coarsest matching
level.
each value is recorded in a "map" along with a few adjacent pixels so that
interpolation works ok in decompression. a value of "pure black" is used for
holes in the map.
typically I would yuv-encode (8 bits/sample, planar) the data and then run
it through an rle compressor.
typically special colors are treated specially by the yuv converter.
quality and compression seem "decent", and sharp details remain (most of the
compression occures in fairly flat areas), just in many cases things can
come out "splotchy" (eg: if the clamp values are high).
I had also tried combining this with delta compression, which I had tried in
2 forms:
1. I black out parts of the input image which did not change between frames,
which compresses better but can lead to issues (eg: "dark artifacts");
2. I record differences between maps of each frame, which does not seem to
offer signifigant compression over just using the maps for the whole frame
(I needed to use a different value to mark "unchanged" areas, which need to
be distinguished from "holes" lest weird artifacting occures).
another possibility could be something like a differential rle compressor
(spans of repeating values and spans of unchanged values), however this
would likely be thrown by minor differences between the frames.
3. I had also tried a more simplistic delta compressor. eg: I just record
the signifigant differences between the frames, filling the rest with black
(other minor things were done however, eg: using a buffer to accumulate
difference values between frames to allow some amount of artifacts to be
cleared up over time, allowing larger clamp values).
I then yuv-encode and rle-compress the results.
supprisingly, this gives compression apparently beating out 2 (this is
weird, before 1 and 2 seemed to be doing a lot better...), but a very much
better quality image (it has a very different look though, the former
becomes splotchy where as this one gets an effect more like tv static...).
the clips used did not involve a lot of motion, primarily just bits from a
webcam (mine gets a decent quality and framerate, eg: 640x480 ~15fps or
320x240 ~30fps), mostly involving me wandering about my room and such. the
clips were about 320x240x15fps...
usually I was compressing to and decompressing from buffers located in
memory, eg, so that I know the algo is roughly working...
1. typically around 20-40kB/frame;
2. often about 40-80kB/frame;
3. around 8-40kB/frame, varying a fair amount based on how much movement
there is in the frame (1 and 2 weren't effected that much).
don't really put much trust in my numbers though, weird crap seems to go on
with them...
full frames are about 230kB(RGB) or about 115kB(yuv).
ok, I know this problably sucks for the resulutions I am dealing with...
or something.
--
cr88192 at hotmail dot com
http://sourceforge.net/projects/bgb-sys/
http://bgb-sys.sourceforge.net/
|