Re: to be effcient or not to be efficient

>>Each message (or most of it) will have some attached parameters. And 
>>these parameters will mostly be structures (a list of data). But to make 
>>the evolution of these structures backward/forward compatible the old C 
>>way is a bit limited. As if you add/remove something you can hardly know 
>>where is what.
> 
> 
> There is a limited amount of information anyways, so you can add
> 99% of it into the struct right now. If there will be any new
> kind of information that could be added we can talk about a new
> version of the api. And as it's really unlikely that elements
> are removed you can even keep the structs compatible by adding
> the new elements at the end.

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.

>>>I can fortell you that if you dont think about efficiency and
>>>only try to implement a nice structered interface that would
>>>please every CS professor, noone will ever use this API.
>>
>>As already mentioned some of us would like this API to be higly 
>>efficient for real-time processing (my DJing software but also some 
>>other video apps). Does any of the API you mentioned support that ? Or 
>>do they have points that, mixed together, could allow this ?
> 
> 
> Have a look at MPlayer G2s vp API (you have read my last mail, did you ?)

Sure, but I expected something else than RTFM. As you obviously know the 
answer.

>> > Multithreading:
>> > Multithreading is nice for Java, which is slow anyways.
>>
>>That's why Apache moved from process to threads...
> 
> 
> Yes, and Apache is a video aplication and we can use it as
> an example.

OK. So what is the most successful video application ? I would say 
DirectShow... But there is also Adobe Premiere or VirtualDub. I think 
all of them use threads. BTW, multi-processor systems are best used with 
threads, right ?

> LOL, you should go over your books again. I'm not mixing anything.
> You have context switches on both tasks and threads. The only
> difference is that you can share the page table between the
> different threads thus saving a TLB flush if you switch between
> threads of the same task (but not all threading implementations do this).
> Be also aware that most threading implementations map threads onto
> tasks.

Sorry but I'm not a computer science man. I've learned mostly by myself. 
So I don't any books like what you mentioned. And I still like to learn 
from other persons like you. Anyway I'm almost sure that the context 
switching for threads is faster than for process. It is equal in the 
very worst case.

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

> heh... The efficiency comes from this pushing and pulling.
> If you manage the buffers the right way you can pass the data
> right away trough filters that do not touch that part of the image

Sorry but this has nothing to do with push/pull/threads. This can be 
achieved in all cases.

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

> Forget the idea that you can have 2 tasks working on different
> frames, it will not gain you anything as the cpu is already
> working at its limit but you'll have 2 threads poisening
> each others cache.

I never said that.

>>Also you didn't mention caching. What do you think is a good caching 
>>policy ?
> 
> 
> 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...

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