Re: to be effcient or not to be efficient

Attila Kinali wrote:

>>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 
>>DShow interface for the same functionality but extended). There would 
>>have been 0 problem if the struct was in EBML (or similar). As you said, 
>>you can't design known for an unknown future. But you can make it clean 
>>for the future.
> 
> 
> Yes, but if you seek extendability, you still don't need ebml.
> You can do this just with normal structs, w/o any overhead beside
> some pointer arithmetic, which is are 1-3 asm instructions compared
> to a few hundred to thousand you need for ebml parsing.

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.

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

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

>>Also my point is to have a very low latency system. Between 5ms and 
>>20ms. Which is far smaller than the duration of a video frame.
> 
> 
> Trough a filter ? or to the output modules ?
> If you mean the output modules, than you should reconsider it.

OK, my point is for an audio-only application that would use that API 
we're discussing about.

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

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

>>>at all. Beside, a filter that takes a lot of time to do its work
>>>will have an impact anyways as it will delay the picture.
>>
>>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.
> 
> 
> Why should a filter in the chain have a lower priority than others ?
> The data must go trough it, no matters what.

That was a bad idea. But the example is still valid.

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

> 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