Re: to be effcient or not to be efficient

On Wed, Jan 07, 2004 at 01:39:09PM +0100, Attila Kinali wrote:

[start of threads discussion skipped]
> > So yes, 
> > any performance impact has to be minimized as much as possible. But I 
> > highly doubt this is the case for threads. 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 ?).
> 
> LOL, consider that windows didn't even have a proper multitasking
> for until recently.
> Well, threads, like all techniques, should be used there where they
> make sense. If i'm going to write a GUI for something, i'll write
> it as a frontend/backend system with threads. If i'm going to write
> a video application i'll put everything in the critical path between
> input (file/stream read) and ouptut (graphics, soundcard or file)
> into one thread/task as i believe that it threads aren't worth
> the overhead they have.

here you go: two developers - two opinions. that's why i suggest to keep
the actual media access / codec API minimal and not concerned with the
playback implementation. then every CS student will be able to learn on
practice how right or wrong his assumptions about software design and
computer power are and at the same time be able to use any of the
supported by the media access library inputs / containers / codecs.
Hopefully results of some of these experimentations will be nice new
open source media applications.

> > 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...
> 
> Yes i asume that there is enough CPU and I/O power to handle the
> stream at realtime. Because otherwise i can clearly forget to 
> watch a movie. If you think about preprocess the images and store
> them until they are showed you go the same way as Nick Kurshev with
> mplayerxp. IMHO it's a good idea and may help in cases where no
> direct render is available and you are at the edge of the needed
> computation power, ie you have enough cpu/io to process the stream
> but at some scenes you're slightly under powered. But, you also
> lose the power of direct rendering and get a lot of io by the
> additional memcpy you have to do.

"caching" will be useful for nonlinear editing. but it's not of the
media access API's concern. 

> > My point here is that dropping frames and even more, dropping audio 
> > samples is *no* option to me. 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).
> 
> For a player, dropping audio samples is a clear no-no. Even a few
> dropped samples can be clearly heard. But dropping a frame once
> in a while is not necessarily noticable.

in real time video effects we drop frames all the time ;) imagine VJ
wants to mix several full pal movies on speeds twice the original - he
doesn't care if some frames are dropped. 

you can't really cache the stuff there - he controls the parameters of
the effects and mixing and decides on sources in realtime. 

and, try to cache live camera input :)

when streaming over long "distances" [netwise] some frames are dropped
because they arrive too late [if at all]. 

so, frame dropping is not evil ;)

-- 
gr{oe|ee}t{en|ings}
artm