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 (-:
diff --git a/libavsequencer/order.h b/libavsequencer/order.h
index ac48db2..853984d 100644
--- a/libavsequencer/order.h
+++ b/libavsequencer/order.h
@@ -23,7 +23,6 @@
#define AVSEQUENCER_ORDER_H
#include "libavsequencer/track.h"
-#include "libavutil/tree.h"
/**
* Song order list structure, This structure is actually for one channel
@@ -34,9 +33,12 @@
* version bump.
*/
typedef struct AVSequencerOrderList {
- /** Integer indexed tree root of order list data used by this
- channel with AVTreeNode->elem being an AVSequencerOrderData. */
- AVTreeNode *order_data;
+ /** Array of pointers containing all order list data used by this
+ channel. */
+ AVSequencerOrderData **order_data;
+
+ /** Number of order list data used for this channel. */
+ uint16_t orders;
/** Number of order list data entries to use for this channel. */
uint16_t length;
@@ -82,13 +84,13 @@ typedef struct AVSequencerOrderList {
each order list which needs this, this will define new
flags which tag the player to handle it to that special
way. */
- int8_t compat_flags;
+ uint8_t compat_flags;
/** Order list playback flags. Some sequencers feature
surround panning or allow initial muting. which has to
be taken care specially in the internal playback engine.
Also sequencers differ in how they handle slides. */
- int8_t flags;
+ uint8_t flags;
#define AVSEQ_ORDER_LIST_FLAG_CHANNEL_SURROUND 0x01 ///< Initial channel surround instead of stereo panning
#define AVSEQ_ORDER_LIST_FLAG_TRACK_SURROUND 0x02 ///< Initial track surround instead of stereo panning
#define AVSEQ_ORDER_LIST_FLAG_MUTED 0x04 ///< Initial muted channel
@@ -138,7 +140,7 @@ typedef struct AVSequencerOrderData {
playback), mark synchronization points or temporary
change volume), which has to be taken care specially
in the internal playback engine. */
- int8_t flags;
+ uint8_t flags;
#define AVSEQ_ORDER_DATA_FLAG_END_ORDER 0x01 ///< Order data indicates end of order
#define AVSEQ_ORDER_DATA_FLAG_END_SONG 0x02 ///< Order data indicates end of whole song
#define AVSEQ_ORDER_DATA_FLAG_NOT_IN_ONCE 0x04 ///< Order data will be skipped if you're playing in one-time mode
@@ -169,10 +171,6 @@ typedef struct AVSequencerOrderData {
divided by 256, but the sub-volume doesn't account
into actual mixer output (this overrides AVSequencerTrack). */
uint8_t sub_volume;
-
- /** This is just a data field where the user solely
- decides, what the usage (if any) will be. */
- uint8_t *user_data;
} AVSequencerOrderData;
#endif /* AVSEQUENCER_ORDER_H */
_______________________________________________
FFmpeg-soc mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
