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

[Vitor Sessak]

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

>>> But I have another idea, we have a CONFIG_SMALL option right?
>>>
>>> We could do my idea, if CONFIG_SMALL is defined and when it's undefined
>>> we use your MAX_INSTRUMENTS approach?
>>
>> No, the whole point of a MAX_INSTRUMENTS is to make things simpler and
>> this would ruin it.
>
> Ok idea discarded. ;-)
>
>>>
>>> Remember that the unknown data is only unknown to TuComposer/FFmpeg, the
>>> GUI editor / whatever calling it might know (partially or fully) the
>>> data, but to find these, the data has to be organized some way. My
>>> thoughts on this were, that the applications search this list, match
>>> their identifier and then evaluate just their data.
>>
>> I don't really like to incentive the behavior of adding
>> application-specific data to the files...
>
> Unfortunately, some do this, and chunk based files like RIFF/IFF are
> especially designed for that. Expect to find this, even the IFF-ILBM
> most popular paint program (DPaint) did this.

If all the formats you know that support this has this software-specific 
data in chunks, uint8_t ** is ok.

-Vitor