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

[Sebastian Vater]

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

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

-- 

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