[FFmpeg-soc] [soc] libavsequencer [PATCH 03/08] Order list public API header file.

[Vitor Sessak]

On 07/10/2010 11:24 PM, Sebastian Vater wrote:
> Vitor Sessak a écrit :
>> On 07/10/2010 08:02 PM, Sebastian Vater wrote:
>>> Vitor Sessak a écrit :
>>>> On 07/07/2010 10:47 PM, Sebastian Vater wrote:
>>>>> diff --git a/libavsequencer/order.h b/libavsequencer/order.h
>>>>> new file mode 100644
>>>>> index 0000000..ac48db2
>>>>> --- /dev/null
>>>>> +++ b/libavsequencer/order.h
>>>>> +typedef struct AVSequencerOrderList {
>>>>> +    /** Integer indexed tree root of order list data used by this
>>>>> +       channel with AVTreeNode->elem being an
>>>>> AVSequencerOrderData.  */
>>>>> +    AVTreeNode *order_data;
>>>>> +
>>>>> +    /** Number of order list data entries to use for this
>>>>> channel.  */
>>>>> +    uint16_t length;
>>>>> +
>>>>> +    /** Repeat start order list data number for this channel.  */
>>>>> +    uint16_t rep_start;
>>>>> +
>>>>> +    /** Volume level for this channel (defaults to 255).  */
>>>>> +    uint8_t volume;
>>>>> +#define AVSEQ_ORDER_LIST_VOLUME 255
>>>>> +
>>>>> +    /** Sub-volume level for this channel. This is basically channel
>>>>> +       volume divided by 256, but the sub-volume doesn't account
>>>>> +       into actual mixer output (defaults 0).  */
>>>>> +    uint8_t sub_volume;
>>>>> +#define AVSEQ_ORDER_LIST_SUB_VOLUME 0
>>>>
>>>> Dividing an uint_8 by 256? Does not give much information...
>>>
>>> Dividing (volume<<   8) + sub_volume by 256. I mean with that the
>>> sub_volume is internally used for accuracy sliding but not outputted to
>>> the mixing engine.
>>
>> Why don't you have just a single var for (volume<<  8) + subvolume?
>
> I already thought quite a long time about this, long before starting
> GSoC. But then I noticed that I mostly access only volume without
> sub-volume. Sub-volume is practically only used for the volume slide
> commands, etc.
>
> For the rest, I just access the 8-bit volume value. Maybe an union would
> be an alternative idea? But that probably looks more ugly can current
> implementation.
>
> Anyway there is no actual reason, why the sub-volume slides couldn't
> take in to account into actual output (it would make volume depth 16-bit
> and therefore much smoother like switching from 8-bit sample to 16-bit),
> since sub-slides are an unique feature of TuComposer so far which I
> invented because TuComposer uses 16-bit data for the effects instead of
> just 8-bit ones.
>
> But it would require a lot of changes (esp. in the playback engine),
> which I would prefer doing after GSoC when we have everything ready so
> that FFmpeg can actually play and convert mod files already.

So subvolume is not actually needed to describe a song?

> Changing the internal logic of the playback engine will require testing
> it, which is not possible at the current state, I just want to get it
> working at all, i.e. at least having the same audio output as TuComposer
> had.

I agree of letting it as-is for now.

-Vitor