Re: to be effcient or not to be efficient

* Steve Lhomme <[email protected]> [2004-01-07 09:36:46 +0100]:

<snip>
> This problematic case occured to me just 2 days ago. Where I had to add 
> a boolean at the end of the structure. Hopefully for that structure 
> there is a Size parameter. Otherwise I should have used a new one (new 
Of course we need such structures, at least an interface version flag.
But this eats up one extra byte and some cmp+j(n)e if you need later
version's fields.

<snip>
> all of them use threads. BTW, multi-processor systems are best used with 
> threads, right ?
Well, I do not know many people who have multiprocessor machines. 
But on normal systems the second CPU has enough to do (filesystem, ...)

Okay, if you really want MT, you still can do it in the player application.
The API should not do much more than some decoding + filtering, nothing 
which influences process control.

<snip>
> At least on the Windows platform where threads are a key feature. I know 
> in the UNIX world things are just starting to move (probably some people 
> realised the power of threading ?).

Eh ?!

Unix is using clean and stable multiprocessing even long time before
windows learned to do more than one job at some time! MT is nothing more
or less than MP w/ shared memory and shared signals.

MT is good for cute user interfaces w/ much things moving around, etc.
But for our stuff I dont see where we should really _need_ it.

<snip>
> Not if it has lower priority or even equal priority than other threads. 
> If other similar threads have the same priority they will still have 
> processing time while the big thing is being done. This is not the case 
> with a 1 task/1 thread system. Each stage has to cache a lot in case 
> another stage is too hungry for a while.

On a MT system you either use pipes (or sth like that) - which _are_ 
caches - or you use resource locking (a filter having nothing to do
waits for a lock to become free and to continue work ...)

I dont see, where _require_ MT for this - this can also be achieved
in loops. A idle filter can simply raise a flag to be left out a cycle.

<snip>
> >Caching of what? Caching of pictures ? No need to do so.
> 
> IMO that's a bad design. You assume you always have enough CPU to 
> process everything. In reality that means that your system can handle 
> only the worst case (all stages take the max amount of time to process 
> incoming/outgoing data). And you'll always end up working under the 
> worst case...
eh ? if you're working in a pipe, you always have to process the first
element first. this only makes trouble on io devices which tend to have
quite large chunks or unstable io behaviour (i.e. network streaming).
for those cases we can introduce an interface for measurement of such
things and put additional cache-filters into the pipe.

BTW: on all these discussions we should have to keep in mind, that
our media-api should not be the whole media application, but "just"
provide the right interfaces for building most of them.

<snip>
> My point here is that dropping frames and even more, dropping audio 
> samples is *no* option to me. 
Why not ?
I've currently sitting in front of a machine, which is too slow to handle
the full frame rate. mplayer's frame dropping works fine here.

<snip>
> Image someone playing live and once in a while there is no sound. Just 
> because his system is fast enough for the general case but not enough 
> for the worst case... Caching data should make it possible to work even 
> in the worst case (to prepare data in advance).
In realtime applications you cannot do more computing than you have 
CPU time for. I've also some divx videos which my machine is tool slow for.
But therefore I can recode them to "faster" formats (thanks to mencoder)

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/