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

[Sebastian Vater]

Vitor Sessak a écrit :
> 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.
>

New patch attached.

-- 

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

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