[FFmpeg-devel] Integrating the mod engine into FFmpeg - what is the best design approach?

[Sebastian Vater]

Vladimir Pantelic a ?crit :
> Vitor Sessak wrote:
>
>> And your first idea did not have this problem. Since it is not a bad
>> idea either, I'd like to explain it to see what the rest of the
>> community think. In Sebastian's original approach, the demuxer would
>> decode the file to a BSS an output it in an AVPacket. It would them
>> define a CODEC_ID_SEQUENCER, and the decoder would be just a wrapper to
>> libavsequencer to make the BSS ->  PCM conversion.
>
> as a lavf/lavc user, I would expect the PCM to be the result of calling
> the decoder, having to now call lavseq would be kinda new and disruptive.

For pure playback you would not have to call lavseq, lavseq is solely
for tracker writers, so the users can edit pattern data, etc. and pass
the edited stuff to FFmpeg which handles that all internally.

>
> for this approach how do we handle:
>
> 1) decode call cannot output ALL pcm at once, do we call it several times
> without new input data to get all the PCM "decoded"?
>
> 2) how do we seek? since the BSS is one avpacket, how do timestamps work?

MODs use ticks, which is based upon BpM in most trackers, to convert BpM
to Hz use the formula: Hz = BpM*2/5, i.e. a module with 125 BpM will
call the playback engine with a rate of 50 Hz.

This means that one AVPacket would fill up sample data of 50 Hz, i.e.
for a mixing rate of 44100 Hz will fill 44100 * sizeof (int32_t) / 50
bytes (the mixer in TuComposer always rendered to 32-bit sample bit
depth, which my converted mixer for FFmpeg also does).

For seeking, we could use simply one frame as one tick. We should care
though, that a module can change the tempo in the middle, so we would
probably build up a timestamp <=> pattern/row/tick LUT when loading (and
calculating the total playback of) the original module.

>
>> The advantage of this approach is that the concept of demuxing/decoder
>> does not make much sense for these formats, so this avoid the artificial
>> distriction. Moreover, it makes a nice distinction of transcoding from
>> one MOD format to other (with -acodec copy) to decoding it to PCM. The
>> disadvantages is that API-wise it's less clear for external applications
>> to get the BSS data (reading the AVPacket payload).
>
> atm, no external apps exists that knows anything about BSS, so I don't
> see
> any issue...

The BSS is, as said above, just interesting for people want to use
FFmpeg as a base for tracker GUIs, normal players will simply use the
same approach like for other demuxers/decoders.

-- 

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