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

Vladimir Pantelic vladoman
Sun Jul 18 10:28:51 CEST 2010


Sebastian Vater wrote:
> Vladimir Pantelic a ?crit :
>>  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.

I was referring to the "other" proposal, not the 2nd one which I think is
better.

>>  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.

I think it does not matter what the actual timebase is...

> 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).

dito.

> 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.

As a module file describes its own playback in a deterministic way, so there
should be some way to skip the processing up to time X and call that a
seek to X. More so given the fact that the BSS is already loaded fully in
memory and not a lengthy >4GB file that needs to be parsed at seek time.
(I might be wrong if the BSS turns out to be turing complete though...)

> 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.

yes, and hence the approach that hides it from a lavf/lavc user as much
as possible is what I prefer. BSS == compressed data, feed it to lavc and
get PCM back...




More information about the ffmpeg-devel mailing list