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

[Attila Kinali]

On Sat, Sep 11, 2004 at 09:59:49AM +0200, Roberto Ragusa wrote:
 
 
> So "the requirement is 10ms", which I estimated from 40ms frame durations
> at 25fps.

10ms is the minimum to get a smooth pic. Note that MPlayer uses some
tricks to get around the 100Hz timer limit. Also try older kernels which
had a very coarse sleep() resolution which could sleep easily 20ms
instead of 10ms and thus on these kernels the video looked a bit "shaggy".

> > > 100ms is not far from 10ms (only a factor 10)
> > 
> > 100ms is several frames' duration. 10ms is less than one frame. HUGE
> > difference.
> 
> Maybe I confused you by saying "not far", because I considered 10ms and
> 100ms near.

100ms is a factor 10 away from 10ms, and if you really coded some time
critical applications you should know that a factor of 10 is a damn lot.

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

No, this is not a nice try, this is exactly what happens if a data
element overflows the cache. It will overwrite all the existing data,
nothing will be left clean (unless you use write trough), thus you will
have to reaload everything from RAM.

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

snow is going to be this powerfull codec :)

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

For these cases you still need specialy designed HW to run them real
time on todays resolution+fps.

 
 
> > > 4) playing real time streams without overflows/underflows is not possible

Unlike most of the other probs this is not a design issue but an issue
of proper timer handling. The way to do this is to 1) extract a timer
from the dvb stream (best from the card directly in form of a counter).
2) implement a PLL in software to a) smooth out phase jitters and b) have
an arbitrary frequency. 3) resample audio bassed on the clock comming
from the PLL.
It just needs someone to code it.
(ok, the realy optimal solution would be to change the clock of the
sound card, but none of the cards i know allow this)

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

The problem here is, if you try to process other data, you will destroy
cache coherency. Also it is not that important whether you miss a
deadline once or twice if it doesnt happen too often. If you cannot
handle a frame in a display time you are lost anyways (unlike most other
data processing on a PC this here is stream processing thus caching of
data inbetween doesnt really help)

 
 				Attila Kinali