Re: to be effcient or not to be efficient

On Wed, 07 Jan 2004 14:03:32 +0100
Steve Lhomme <[email protected]> wrote:

> 
> Consider this :
> struct _blah {
> 	uint16 Size;
> 	uint8  FieldA;
> 	uint32 FieldB;
> 	char   FieldC[30];
> };
> 
> Now (after a few years) you realise that you need FieldA to be on 2 
> octets instead of 1. You simply can't. And you can with EBML.

Yes, but you can foretell whether there could be a need to extend
a field as you already know what kind of information is available.
Beside, i would consider a new version of the API if such a change
is needed.

 
> > I can't give you that, because i don't know it myself.
> > I've read Richs design, asked him a lot of questions why
> > he did it like this an not otherwise. But still, i dont
> > understand more than 80-90% of it, because i lack a lot
> > of experiance of writing video filters and codecs which he has.
> 
> Rich Felker ? OK...

Yes, Richard Felker.


> > And your argument with multiprocessor machines is unfortunately void
> > as just a few freaks have more than one processor. The normal PC 
> > is something between a PII 400 and a PIII 1.5GHz and even lower
> > clock frequencies if you go to east europe, asia or africa.
> 
> Freaks as you say will be the major league soon. Apple already has 
> already dual on-chip CPU. Intel has HyperThreading. And I think AMD is 
> also thinking about a similar feature... That's IMO the best way to 
> continue to grow the computing power without too much problems.

You dont really gain a second CPU with Hyperthreading. It is used
by Intel as a marketing gag IMHO. The sense behind is to use the
time you wait to get data from the RAM on processing other data
you have already in your cache. The problem with this is to
have something to process. 
I dont know yet about PPCs dual on-chip CPUs, have to read about it.
But i dont think that dual CPUs will be common any soon. You forget
that around PCs everything musst be as cheap as possible. Beside
the main bottle neck isnt the CPU, it's the mainboard with its
limited I/O.


> > A video player wants as much buffer from the hardware as it can get
> > because it doesn't cost anything to use it (unlike self build buffers
> > in RAM). A interactive application on the other hand wants to minimize
> > overall delay and thus keeps those buffers small. IMHO the amount
> > of buffer in the output modules should be controlled by the application
> > and not by the API.
> 
> Yes. I came to the same conclusion when thinking about a very-low 
> latency architecture that would have no drop-out (as long as the system 
> can handle the worst case).

I would leave the latency control, especialy of the output
to the application.

 
> > 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.
> 
> OK, so what would you use ? The output pulls the data (no lock needed) ? 
> The input pushes the data (lock needed while data are not needed yet) ? 
> How is seeking handled ? When you're in the middle of decoding an I 
> frame for example ?

Can't say. I know mplayer G1 and vlc use a push system while
mplayer G2 will use a pull system (Rich/Arpi said that there are
some problems with push systems that can be circumvented with pull
systems), but i lack to much experience to decide this.


> >>>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...
> > 
> > 
> > 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.
> 
> Yes, but then the worst case is "integrated" (in the mathematical sense) 
> into the rest of the processing. The cache is there while you're still 
> processing a long task.

Yes, that's exactly Nicks argumentation and i can follow it.
But as i said, this will gain you only something in a small
range where you have just enough power to handle the stream
but fail at some "peaks" where you are below this limit.
And there is a traid off between, direct rendering, and
keeping a cache of precomputed frames.
Former is well established, later is only used by mplayerxp sofar.
 
> > 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.
> 
> ACK

Hey! we finaly agreed on somehting :)

			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu