mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-05 22:25:55 +00:00
57ce0321c8
Original commit message from CVS:
Added a tarkin encoder/decoder plugin.
I moved the tarking CVS code in here temporarily until they have a
library (hence this plugin is in ext)
test with:
./gst-launch filesrc location=/opt/data/shihad.mpg ! mpegdemux video_00! { queue ! mpeg2dec ! colorspace ! tarkinenc bitrate=3000 ! disksink location=out.ogg }
./gst-launch filesrc location=out.ogg ! tarkindec ! colorspace ! xvideosink
62 lines
2.6 KiB
Plaintext
62 lines
2.6 KiB
Plaintext
|
|
This is deprecated. Take a look in the w3d/docs directory.
|
|
|
|
The command line semantics are changed. You have to call the test program
|
|
now like this:
|
|
|
|
./tarkin_enc ../clips/venuscubes-ppm/AnimSpace00%03d.ppm 5000 4 4
|
|
./tarkin_dec
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Hi,
|
|
|
|
this is a experimental 3d-integer-wavelet-video compression codec. Since the
|
|
integer wavelet transform is reversible and a reversible rgb-yuv conversion
|
|
is used (you can understand it as (1,2) integer wavelet transform, too), this
|
|
codec should be lossless if you transmit the whole bitstream.
|
|
The Y/U/V-bitstreams are embedded, thus you can simply get lossy compression
|
|
and shape the used bandwith by cutting bitstreams, when a user defined limit
|
|
is reached.
|
|
|
|
|
|
Here is how the current code works:
|
|
|
|
First we grab a block of N_FRAMES frames (defined in main.c) of .ppm files.
|
|
Then each pixel becomes transformed into a YUV-alike colorspace. Take a look in
|
|
yuv.c to see how it is done. Each component is then transformed into frequency
|
|
space by applying the wavelet transform in x, y and frame direction.
|
|
The frame-direction transform is our high-order 'motion compensation'.
|
|
At boundaries we use (1,1)-Wavelets (== HAAR transform), inside the image
|
|
(2,2)-Wavelets. (4,4)-Wavelets should be easy to add. See wavelet.c for details.
|
|
|
|
The resulting coefficients are scanned bitplane by bitplane and
|
|
runlength-encoded. Runlengths are Huffman-compressed and written into the
|
|
bitstreams. The bitplanes of higher-frequency scales are offset'ed to ensure a
|
|
fast transmission of high-energy-low-frequency coefficients. (coder.c)
|
|
The huffman coder is quite simple and uses a hardcoded table, this can be done
|
|
much better, but I wanted to get it working fast.
|
|
|
|
Decompression works exactly like compression but in reversed direction.
|
|
|
|
The test program writes for each frame the grabbed original image, the y/u/v
|
|
component (may look strange, since u/v can be negative and are not clamped to
|
|
the [0:255] range), the coefficients (look much more like usual wavelet
|
|
coefficients if you add 128 to each pixel), the coefficients after they are
|
|
runlength/huffman encoded and decoded, the y/u/v components when inverse wavelet
|
|
transform is done and the output image in .ppm format.
|
|
|
|
You can call the test program like this:
|
|
|
|
$ ./main 20000 5000 5000 ../clips/%i.ppm
|
|
|
|
which means: images are grabbed from directory ../clips/0.ppm, ../clips/1.ppm,
|
|
etc. The Y component bitstream is limited to 20000 Bytes, the U and V bitstreams
|
|
to 5000 Bytes. If the last argument is omitted, frames are taken from current
|
|
directory.
|
|
|
|
Good Luck,
|
|
|
|
- Holger <hwaechtler@users.sourceforge.net>
|
|
|