[FFmpeg-soc] [soc] libavsequencer [PATCH 01/08] Music module public API header file.

[Sebastian Vater]

Michael Niedermayer a écrit :
> On Sun, Jul 11, 2010 at 01:27:20AM +0200, Vitor Sessak wrote:
>   
>> On 07/11/2010 01:17 AM, Sebastian Vater wrote:
>>     
>>> Vitor Sessak a écrit :
>>>       
>>>> On 07/11/2010 12:58 AM, Sebastian Vater wrote:
>>>>         
>>>>> Vitor Sessak a écrit :
>>>>>
>>>>>           
>>>>>> I don't know what typical values are, but is the folowing doable?
>>>>>>
>>>>>> #define MAX_INSTRUMENTS [... some value here ...]
>>>>>> AVSequencerInstrument *instrument_list[MAX_INSTRUMENTS];
>>>>>>
>>>>>> Everything access and insertion O(1) and both done in one line of
>>>>>> code...
>>>>>>             
>>>>> The limit almost always 64k, which would be quite large in that case.
>>>>>           
>>>> I don't mean the theoretical limit, I mean the biggest value ever used
>>>> in any actual file.
>>>>         
>>> Hmm, and how to determine that? Including all the future files that will
>>> ever be created?
>>>       
>> What was the biggest value you ever encountered? If it's 20, setting it to 
>> 100 might be safe. Those who want to try weird experiments with crazy files 
>> are free to increase it and recompile ;)
>>
>>     
>>> Another possibility would be simply stick to 2^n size, with a start
>>> let's say of 1, and if we add a new instrument which makes the list
>>> larger or equal to (2^n) + 1, we increase the size to 2^(n+1).
>>>
>>> Anyway, when the limit is 64k, we have at worst O(65535) which should
>>> even not a problem for 20 year old CPUs. And even if the user has to
>>> wait half a second here, we can accept this (in that case, the user
>>> would simply add 16 instruments at once to avoid the delay).
>>>       
>> That is not important now. If we can not set a maximum value for it we let 
>> to whatever code that is going to create this struct to alloc it using the 
>> best method for its particular problem...
>>     
>
> iam not sure if the MAX_INSTRUMENTS idea is all that great, considering how
> we are being hit by MAX_STREAMS currently. But i think an array of pointers
> thats allocated somewhere is a big improvent over the tree in terms of
> simplicity
> [...]
>   

Updated patch attached.

-- 

Best regards,
                   :-) Basty/CDGS (-:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: module.h_20100711.patch
Type: text/x-patch
Size: 6282 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20100711/850e9779/attachment.bin>