Re: to be effcient or not to be efficient

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

So what happens to the older apps ?

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

I read MPlayer G2 vp. Actually there is push/pull/in-place processing... 
I hope you don't have to implement all of them for each filter :/

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

Too bad you're surprised ;)