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

[D Richard Felker III]

On Sun, Sep 12, 2004 at 02:00:35AM +0200, Roberto Ragusa wrote:
> 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.

yes, finally...

> > > 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.

that would make it a joke, wouldn't it? also with bad rate control (i
doubt dirac has fancy rate control like lavc or xvid) it will perform
much worse than mpeg4 in terms of compression/quality.

> > > 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)

with the motion paths in there, what would be a residue with
conventional codecs becomes just a part of the transformed data. so
yes, that works.

> 2) the transform has to output uncorrelated samples (for better compression)

yes, but it's also possible to do additional decorrelation of the
samples afterwards. that can be separate from the transform.

> 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).

i agree, that's why it should be a good approach.

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

it's not what i would call a linear process. when i say a filter is
linear, i mean it's a linear transformation from R^(w*h) (or in the 3d
wavelet case, R^(w*h*l) where l is the time window length) to some
other linear space. motion compensation is _highly_ nonlinear.

btw the motion-warped wavelet transform described above is linear from
(a fixed) motion-warped space to the coefficient space.

> > > 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?

not sure. it was abandoned but then arpi came back to the team and
said he was going to work on g2 again under lgpl. i haven't seen any
progress yet, but who knows...

> > 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.

hahah ok. :)

> Resolution should be checked, the man page talks about 10ms (100Hz
> timer) but it was written 11 years ago. 8-)

whatever the resolution, a thread-based approach would have the same
resolution. it's just dependent on the kernel timer interrupt rate.

btw another idea we had which is better but only works with slice
rendering: check the timer and call pageflip function from the slice
function. :)

rich