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
_______________________________________________
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
