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

[D Richard Felker III]

On Sat, Sep 11, 2004 at 09:59:49AM +0200, Roberto Ragusa wrote:
> > if it's a 300 mhz p2 (not celeron) or a xeon (did xeons that slow even
> > exist? i'm not sure), then it probably has a plenty cache. even if
> > not, you'll be playing a smaller movie (typically 640x288 or 512x384)
> > since a box that slow can never play dvd resolution.
> 
> So you're saying that a CPU can basically play only movies with frames
> fitting its cache, because overflowing the cache destroys the performance
> and if when the cache is small the raw power of the CPU is probably also
> limited enough to not be able to make the deadlines.
> 
> OK, it could be true (partially al least).

that's not necessarily what i'm saying. all i know with regards to
this is that mplayer is very optimized, and you still can't play full
resolution movies on a system this slow. i suspect you'd have a
problem even if the frames would fit in the cache...

> > if you want to compare, try playing a really big movie that won't fit
> > in your cache, first with cache, then with cache disabled in the bios
> > setup... :)
> 
> Nice try :-)
> but this is not fair, you're also uncaching all the code and then
> we are talking about accidental cache thrashing not 100% miss rate.

:)

> > > 3) fast CPU have a (perhaps) big enough cache
> > > doesn't a strategy assuming big caches only help fast CPUs?
> > 
> > re-read what i just said about snow. snow already requires an insanely
> > fast cpu....in fact at present it can't be decoded realtime on _any_
> > cpu. this will change once we get some more optimization but it's
> > still going to be intensive.
> 
> In my ignorance, I'm hearing about snow for the first time and will
> search information about that. I think we're currently lacking a seriously
> powerful codec at the moment.

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.

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

> > basically, if decoding movies is only taking 3-6% cpu time, it's time
> > to design a new codec that's a lot more space-efficient, because the
> > old speed restrictions don't apply anymore.
> 
> 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.

> > > 3) playing a 25fps video at 50fps deinterlaced is not possible
> > 
> > this is a fundamental problem in the video filter layer and the main
> > loop structure. again it has nothing to do with being non-threaded.
> > mplayer g2 can do full-rate deinterlacing just fine, because it runs
> > the filter chain in the correct order (pulling from the end).
> 
> 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.

> Maybe I shouldn' have focused my comments on threads.
> What I was rally proposing is a modularization of the processing blocks
> with well defined interfaces eliminating subtle side effects (such as,
> calling this before this will not work...).
> A good approach could be (you said you already know how to design a good
> architecture, but let me have a try too) a main loop consisting of
> basically a scheduler, it keeps info about all the functional blocks
> and knows who has "something to do", decides who to run based on a
> deadline strategy. When that abstraction is in place you can add
> threads if you want (2 threads with 2 CPUs will certainly be better).
> 
> But I think that without a more threaded approach the problem
> "I have to display a frame in 2ms, but if I try to process other data
> in the mean time I will miss the deadline" has no solution, because of
> the preemptive/cooperative multitasking similarity I used before.

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

rich