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

[Sebastian Vater]

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.

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 could however, do the changes in TuComposer and try that out, but that
would effectively double the amount of time required, and thus slow down
the development in FFmpeg by the factor of 2, which I really don't want!

Remember, I already have decided to drop the old TuComposer completely
when the FFmpeg port works at least with the quality the original had.
So changing code in original TuComposer is just plain silly.

There is no reason anymore to have that as a separate project. The name
TuComposer will still remain to honor history though when everything is
in FFmpeg in the wxTuComposer project coming then, which will be the
first GUI for it using wxWidgets, but using FFmpeg instead. ;-)

This will also the point when I implement the remaining missing features
of TuComposer.

When all this is done, we can change such things without being worried
to break anything without knowing what was wrong.

Another point though, it seems that my documentation regarding volume /
sub-volume is misunderstandable regarding this, so I have for now at
least to change the documentation. Any good idea?

-- 

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