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

[Vitor Sessak]

On 07/11/2010 12:58 AM, Sebastian Vater wrote:
> Vitor Sessak a écrit :
>> On 07/10/2010 11:31 PM, Sebastian Vater wrote:
>>> Vitor Sessak a écrit :
>>>>
>>>> It is still not good in github. Why duplicating the
>>>> AVFormatContext->metadata as AVSenquencerSynth->metadata?
>>>
>>> You surely meant AVSequencerModule->metadata not synth, right?
>>
>> Oops, there is a file metadata inside the synth data? I hope some
>> demuxer expert can tell how to set metadata in these cases...
>
> Yes, consider the following, you have a sample which contains a synth
> sound structure and you want to describe it someway, since there is also
> custom synth sound code possible, it might be a good idea, setting an
> artist (i.e. author of the code), some comments, etc.
>
>> 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.

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

>>>
>>> void ** or uint8_t ** would be better I think...each chunk is a pointer
>>> then. That way single chunks can be changed without recalculating
>>> everything else.
>>
>> Why do you think in chunks? They might be organized in a tree inside
>> the file or a circularly linked list, or etc. void * do not exclude
>> int8_t **...
>
> 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...

-Vitor