[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Opendivx digest, Vol 1 #13 - 6 msgs



Send Opendivx mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.projectmayo.com/mailman/listinfo/opendivx
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opendivx digest..."


Today's Topics:

   1. Re: wavelets (Carlo Daffara)
   2. Re: wavelets (John Funnell)
   3. Re: wavelets (Carlo Daffara)
   4. Re: documentation, mpeg4 divx etc... (Nick Feamster)
   5. linux mmx decore... (Arpi)
   6. Re: linux mmx decore... (John Funnell)

--__--__--

Message: 1
Date: Thu, 1 Feb 2001 16:19:31 +0100 (MET)
From: Carlo Daffara <[email protected]>
Cc: [email protected]
Subject: Re: [Opendivx] wavelets

Well, wavelets get much of their superiority from the fact that they tend
not to show blocking effects (but they have a much worse ringing). If you
use a good dct implementation (with adaptive quantization matrices) and a
postprocessing filter you get exactly the same visual quality of wavelets
on static images. When you use motion prediction methods (and
differentials as a way to produce error images) wavelets no not have any
advantage over dct for inter-frame coding. In fact, the use of wavelets
is mainly for low bit rate coding, when compressing in the mid rate
(400-900 kbit/s for 24/25 frames/sec, film like sources) the visual
difference with dct is not perceptible.
It is better to:

- prefilter material to make the artifacts more acceptable, or to spread
the error over different frames (warning- it seems that this is patented
somehow) (approximate compression gain: 10%-15% depending on the material)
- use a sophisticated motion matching algorithm; it is better *not* to use
the block that minimize the RMS error, but to choose a block that does
follow the optical flow of the moving sequence (there is a nice library
from Intel that does it). Also, estimating the optical flow can be used
for prefiltering (direction-oriented smoothing using constraint-based
diffusion is used for this) (appr. gain: 15%)
- use a postfilter to reduce the error created by the quantization step
(there are several, good adaptive systems for that) (appr. gain: 20%)
- if the material is to be seen from CDs or from broadband sources, you
can allow a much larger VBR extension (appr. gain: 10%)
DCT+Postfilter is roughly equivalent to DCT; there is an advantage thanks
to hardware DCT implementation common in many graphic cards or thanks to
the highly optimized libraries available for dct (there are none for
wavelet).
cheers
						Carlo Daffara
						Conecta Telematica

On Thu, 1 Feb 2001, ridaas syncprodz.com wrote:

> i have very few knowledge about video coding since my proper job is more focused on transport-layer of mpeg standard (the so called mpeg2-TS).
> i am not sure if mpeg4 standard talk or not about wavelets, maybe is possible than more then one coding techinique is allowed.
> what i know is this:
> 
> -wavelet is based on subband coding, the wavelet transform scheme combine transform coding with subband coding
> 
> -wavelet is supposed to be very good for I-frame coding (same as jpeg coding) and for low-bitrate videos (12-48kbps) the I-frame coding takes about 40-70% of the bit used in the stream, this means that for very low bitrate you save a lot respect typical dct.
> 
> -wavelet is supposed to be more cpu intensive, i checked some article and it seems the coder (on a dsp implementation) has 50% less framerate.
> 
> -the problem with video and wavelet-based coding scheme is find a mechanism to exploit the temporal redundancies and here i found 3 proposals:
> 1) extensions of the 2-D wavelet-based scheme to 3-D subband coding (3-D SBC)
> 2) use of a multiresolutional motion compensation (MRMC) in the wavelet domain
> 3) so-called overlapped block motion compensation
> 
> now don't ask me details cause i am not in this things at all :(
> 
> good references can be found (where i found them, but there are lotsa of article cited there) in this article:
> "Very low bit-rate video coding using wavelet-based techniques" by D.Marpe H.Cycon (IEEE Transactions on circuits and system for video technology vol.9 feb 1999)
> 
> i will check this wavelet things and mpeg4 and divx code (if i can manage it) and will try to post my 2 cents when i will know more :)
> 
> federico
> ps: i thought divx was the microsoft hacked mpeg4 encoder btw..:)



--__--__--

Message: 2
From: "John Funnell" <[email protected]>
To: "Carlo Daffara" <[email protected]>
Cc: <[email protected]>
Subject: Re: [Opendivx] wavelets
Date: Thu, 1 Feb 2001 14:16:58 -0000

Carlo, thanks for your enlightening post:
one thing... your percentages, when multiplied come to around 54% (I assume
you're meaning bitrates).  So, equivalent quality in half the size?  This
would incredible if we could do this :-)

John

----- Original Message -----
From: Carlo Daffara <[email protected]>
Cc: <[email protected]>
Sent: Thursday, February 01, 2001 3:19 PM
Subject: Re: [Opendivx] wavelets


> Well, wavelets get much of their superiority from the fact that they tend
> not to show blocking effects (but they have a much worse ringing). If you
> use a good dct implementation (with adaptive quantization matrices) and a
> postprocessing filter you get exactly the same visual quality of wavelets
> on static images. When you use motion prediction methods (and
> differentials as a way to produce error images) wavelets no not have any
> advantage over dct for inter-frame coding. In fact, the use of wavelets
> is mainly for low bit rate coding, when compressing in the mid rate
> (400-900 kbit/s for 24/25 frames/sec, film like sources) the visual
> difference with dct is not perceptible.
> It is better to:
>
> - prefilter material to make the artifacts more acceptable, or to spread
> the error over different frames (warning- it seems that this is patented
> somehow) (approximate compression gain: 10%-15% depending on the material)
> - use a sophisticated motion matching algorithm; it is better *not* to use
> the block that minimize the RMS error, but to choose a block that does
> follow the optical flow of the moving sequence (there is a nice library
> from Intel that does it). Also, estimating the optical flow can be used
> for prefiltering (direction-oriented smoothing using constraint-based
> diffusion is used for this) (appr. gain: 15%)
> - use a postfilter to reduce the error created by the quantization step
> (there are several, good adaptive systems for that) (appr. gain: 20%)
> - if the material is to be seen from CDs or from broadband sources, you
> can allow a much larger VBR extension (appr. gain: 10%)
> DCT+Postfilter is roughly equivalent to DCT; there is an advantage thanks
> to hardware DCT implementation common in many graphic cards or thanks to
> the highly optimized libraries available for dct (there are none for
> wavelet).
> cheers
> Carlo Daffara
> Conecta Telematica
>
> On Thu, 1 Feb 2001, ridaas syncprodz.com wrote:
>
> > i have very few knowledge about video coding since my proper job is more
focused on transport-layer of mpeg standard (the so called mpeg2-TS).
> > i am not sure if mpeg4 standard talk or not about wavelets, maybe is
possible than more then one coding techinique is allowed.
> > what i know is this:
> >
> > -wavelet is based on subband coding, the wavelet transform scheme
combine transform coding with subband coding
> >
> > -wavelet is supposed to be very good for I-frame coding (same as jpeg
coding) and for low-bitrate videos (12-48kbps) the I-frame coding takes
about 40-70% of the bit used in the stream, this means that for very low
bitrate you save a lot respect typical dct.
> >
> > -wavelet is supposed to be more cpu intensive, i checked some article
and it seems the coder (on a dsp implementation) has 50% less framerate.
> >
> > -the problem with video and wavelet-based coding scheme is find a
mechanism to exploit the temporal redundancies and here i found 3 proposals:
> > 1) extensions of the 2-D wavelet-based scheme to 3-D subband coding (3-D
SBC)
> > 2) use of a multiresolutional motion compensation (MRMC) in the wavelet
domain
> > 3) so-called overlapped block motion compensation
> >
> > now don't ask me details cause i am not in this things at all :(
> >
> > good references can be found (where i found them, but there are lotsa of
article cited there) in this article:
> > "Very low bit-rate video coding using wavelet-based techniques" by
D.Marpe H.Cycon (IEEE Transactions on circuits and system for video
technology vol.9 feb 1999)
> >
> > i will check this wavelet things and mpeg4 and divx code (if i can
manage it) and will try to post my 2 cents when i will know more :)
> >
> > federico
> > ps: i thought divx was the microsoft hacked mpeg4 encoder btw..:)
>
>
> _______________________________________________
> Opendivx mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx



--__--__--

Message: 3
Date: Thu, 1 Feb 2001 17:14:49 +0100 (MET)
From: Carlo Daffara <[email protected]>
To: John Funnell <[email protected]>
Cc: [email protected]
Subject: Re: [Opendivx] wavelets

No joking. The problem is that the work is not easy :-)
For example, there are many postprocessing filters, but only a few can be
implemented in realtime (all the POCS-projection onto convex sets, for
example; regularization- based filters, or the wonderful coding-recoding
dct filter are not realtime)
There is a lot of work on better dct coding;
for example:
- an algorithm that builds directly a postprocessed idct:
http://citeseer.nj.nec.com/details/wu98additive.html (very good artiocle
by the wonderful Gersho)
- enhanced dct coding, spreading error:
http://sipi.usc.edu/~ortega/Thesis.html
http://www-ise.Stanford.EDU/class/ee392c/demos/kesavan/
http://www-ise.Stanford.EDU/class/ee392c/demos/anna_alvin_gomata/
- pocs postprocess:
http://www.en.polyu.edu.hk/~enyhchan/c_98csvt.ps
http://www-ise.Stanford.EDU/class/ee392c/demos/galo/
http://www.en.polyu.edu.hk/~enyhchan/c_97spl.ps

Motion estimation:
http://www.eurasip.org/eusipco96/abstract/all.htm#me_9
it is easy to see why motion estimation is important; if you get
"near perfect" matches you end up with a differential image with very high
frequency content and difficult to dct encode. Since P and B (predicted)
images are the majority, it is important to code efficiently those. In my
experiments, I discovered that it's better to start with a very high
quality I frame, and adapt the motion estimation algorithm of the encoder
depending on the image content (also see:
http://www.research.ibm.com/journal/rd/434/gonzales.html)

Preprocessing:
anisotropic diffusion is the most common method:
http://vision.ece.ucdavis.edu/ftp/cipic/reports/92/02/demo/node3.html
also:
http://vision.ece.ucdavis.edu/scripts/reportPage?95-04
There is not much research on using motion to do preprocessing (apart some
expert that says that's not good, but that applys only to best match
motion estimation). You need to use a robust optical flow estimator, and
use the motion vectors from the optical field to do directional smooting
using anisotropic diffusion.

Iterative encoding: let's say that you have all the time you want to do
the encoding. You do:
1- estimate scene changes
2- extract subscenes between changes
3- encode them with different encoding parameters, choosing the result
with the lowest total error.
(this is done by some high end compression bureaus, I know that one of
them are using a Maspar MPP parallel machine)
As you see, it's a lot of work. But if you use all of them you can get
around 50% (I think something more, thanks to the sinergy between
preprocessing and motion estimation).
ciao
						Carlo Daffara

On Thu, 1 Feb 2001, John Funnell wrote:

> Carlo, thanks for your enlightening post:
> one thing... your percentages, when multiplied come to around 54% (I assume
> you're meaning bitrates).  So, equivalent quality in half the size?  This
> would incredible if we could do this :-)
> 



--__--__--

Message: 4
Date: Thu, 1 Feb 2001 10:03:01 -0500 (EST)
From: Nick Feamster <[email protected]>
To: "ridaas syncprodz.com" <[email protected]>
Cc: <[email protected]>
Subject: Re: [Opendivx] documentation, mpeg4 divx etc...

I compiled a list for video streaming, it should go up on the projectmayo
video streaming page when it is launched.

Nick

On Thu, 1 Feb 2001, ridaas syncprodz.com wrote:

> i would love to make a page on the web with updated links to any documentation related to mpeg4 and divx that can be useful to anyone want to enter the field of video-coding.
> i tried to look around but didn't found any good docs or tutorial on this.
> i think it's good to have some coding documentation for the people who will implement the opendivx stuff but it woiuld be nice to have references for people who already know about coding in general but maybe lack knowledge about video.
> expecially some docs about putting the things in a right contest (where divx come from, which are the liasons with mpeg4 standard, which are the difference, where we are moving..)
>
> anybody know good urls already?
>
> federico
> ---
> http://www.syncprodz.com
> (free mp3 since 1997)
> ___________________________________________________________________________
> Visit http://www.visto.com/info, your free web-based communications center.
> Visto.com. Life on the Dot.
>
>
> _______________________________________________
> Opendivx mailing list
> [email protected]
> http://lists.projectmayo.com/mailman/listinfo/opendivx
>



--__--__--

Message: 5
Date: Thu, 1 Feb 2001 17:34:13 -0600 (CST)
From: Arpi <[email protected]>
To: [email protected]
Subject: [Opendivx] linux mmx decore...

Hi,

What about this:  (I've just found at the forum)

http://magicwb.free.fr/dev/divx.html

It's the mmx implementation of idct and motion comp. code!
(unfortunately no mmx/sse postprocessing yet)

He used nasm under linux, so code is still in intel syntax.
Discovering this, I got an idea:
What about using nasm for both (linux+win+bsd+...) versions?
nasm is a real OS-independent x86 compiler, and using
separated .c and .asm files (instead of inline asm) allow
us to use same .asm code for all x86 platforms. 
And while m$ VC doesn't support SSE instructions,
nasm does!!! (prefetch...)


A'rpi / Astral & ESP-team

--
mailto:[email protected]
http://esp-team.scene.hu


--__--__--

Message: 6
From: "John Funnell" <[email protected]>
To: "Arpi" <[email protected]>, <[email protected]>
Subject: Re: [Opendivx] linux mmx decore...
Date: Thu, 1 Feb 2001 16:57:14 -0000

This is a good idea.  Only (minor) problem is that you need a leading
underscore on every symbol for Windows and not for Gnu.

Could you Windows guys on the list cope with installing nasm and entering a
custom build step into your project? ;-)


Here's a summary of the three approaches for using assembler in our project
(let's ignore gas .s files):


(1) ** C with inline Intel-syntax **
In Windows Windows:  easy, use M$'s compiler
In Gnu/linux: you have 4 options
a. use wine to run cl.exe (or perhaps icl.exe though i haven't tried it yet)
b. run the code through intel2gas then use gcc/gas
c. wait for gcc to support inline intel syntax
d. hope that intel ports their compiler to linux
e. import a .o file compiled by someone who has one of the above!!


(2) ** C with inline gas (AT&T) syntax ** (I believe this is obsolescent)
In Windows:  use cygwin/gcc
In Gnu/linux:  use gcc


(3)** nasm format assembler files **
In Windows:  use nasm
In Gnu/linux:  use nasm


For now option (1), C with inline Intel-syntax, is the projectmayo prefered
option.  I'm sure everyone understands that is very important that we know
where the master, best, fastest MMX/SSE code is.  Ideally we should have
code that will build on any x86 platform.  nasm looks like that it might be
that utopia.....

Thoughts?

John





--__--__--

_______________________________________________
Opendivx mailing list
[email protected]
http://lists.projectmayo.com/mailman/listinfo/opendivx


End of Opendivx Digest


Reply To Poster

Local References / HOW-TO / FAQs