[MPlayer-dev-eng] Adding threaded functionality to mplayer NODAEMON

[Roberto Ragusa]

On Sat, 11 Sep 2004 05:26:15 -0400
D Richard Felker III <dalias at aerifal.cx> wrote:

> well snow is that codec, but it needs a lot more optimization and some
> bugfixes before it's ready for widespread use. at high quality it
> should use somewhere between 50% and 75% of the bitrate of mpeg4 at
> the same quality, and will do much better from a perceptual quality
> standpoint. at low quality the difference is even more extreme.

I didn't know about this codec, so wavelet codecs are finally coming out.
I have experience with wavelets and I know the potential they have.

> > Then there is dirac, where I'm afraid cache issues will be a problem.
> 
> basically dirac is considered a joke by all the people with video
> encoding expertise...

Why?
It is basically MPEG4 with wavelet instead of DCT and a motion compensation
with overlapped blocks. Do you think mpeg4 is also a joke?

Maybe the problem with dirac is that it is not able to heavily
outperform MPEG4 while being much much slower.

> > Yes, in fact I was discussing here a 3D (x,y,time) wavelet coder.
> > That would have multimegabyte "frames" (actually group of frames)
> > and it's possible that only GPUs can do it fast enough.
> 
> 3d wavelet is a joke in the form it's used in all current codecs. why?
> because video is aliased horribly (i.e. undersampled) in time. it
> doesn't look like a continuous signal for any sort of linear
> transformation; it just looks like noise.
> 
> i've mentioned before, there's a hypothesis that you could first
> estimate motion paths through your collection of frames (a highly
> nonlinear process) and then perform a 3d wavelet transform along the
> axes of the resulting deformed space. but i don't know of any real
> research on this.

You're right. I've been thinking for some time about how to introduce
motion compensation directly into the wavelet transform, that is to
create a new transform similar to wavelet but adapted to real world
videos.
There are two basic goal:
1) it has to been a transform (reversable), not a prediction (unreversable
without an additional residue)
2) the transform has to output uncorrelated samples (for better compression)

If you have motion compensation inside the "motcompwavelet", the signal is
sufficiently continous in the time axis: real world objects move around but
keep their shape. You have continuity and then sharp discontinuity: wavelet
are good in that situation (the worse it can happen is that a little fading
effect is added to scene changes).

Basically, when mpeg4 does mot comp and block prediction, it is using
a linear process (prediction is a simple linear transform).

> > Good. Is g2 already usable? I thought it was at a design stage.
> 
> it runs. usable, i would say no. my point was just that a proper flow
> of execution can be done without threads.

I studied the docs in g2 and it looks really good. So you were right,
good ideas are not lacking. :-)
Is it currently developed or pratically abandoned?

> posix has a nice feature called alarm(). call the page flip function
> from the signal handler. that's why i intend to do when i get around
> to working on this player with a good architecture...

Good idea. But the man page says time is measured in seconds.
Better chance with setitimer.
Resolution should be checked, the man page talks about 10ms (100Hz
timer) but it was written 11 years ago. 8-)

-- 
   Roberto Ragusa    mail at robertoragusa.it