[FFmpeg-devel] [PATCH] libmodplug wrapper

Jai Menon jmenon86
Fri Jul 10 15:24:27 CEST 2009

On Fri, Jul 10, 2009 at 8:55 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
> On Fri, Jul 10, 2009 at 03:30:52AM +0000, Jai Menon wrote:
>> On Fri, Jul 10, 2009 at 2:18 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
>> > On Thu, Jul 09, 2009 at 03:07:44PM +0000, Jai Menon wrote:
>> >> Hi,
>> >>
>> >> I found $attached useful, and maybe some sceners might also ;)
>> >> If someone feels it should be in FFmpeg, I can provide relevant doc patches.
>> >
>> > this definitly is a nice to have feature but demuxer?
>> The reason for doing it as a demuxer is that I have a few patches for
>> libmodplug which improve the seeking behavior (done through a single
>> api call) there (seeking in tracked music is still iffy though, there
>> might be loops etc and due to the nature of some effects, we can't
>> seek precisely). As and when that is included upstream, I assumed
>> adding seeking would be simplified. Or can this be achieved
>> differently?
> I wish i knew ...
> my knowledge of these formats is shallow, if you have a link to some spec/doc
> of some representative one so i can get a better feeling of what would be
> needed for seeking that link would be appreciated ...

Try ftp://de.hornet.org/pub/demos/code/audio/docs/fmoddoc.zip
I wrote a protracker renderer in 16bit asm once based on that, and its
pretty verbose.

I'll again summarise the issues here :

libmodplug requires the entire file to be buffered into memory so we
have to read the entire contents of the file. If this was split into a
decoder and demuxer, the demuxer would have to do this somehow, which
i think would be ugly.

Assuming we go that route, the next problem is adding seek support.
Seeking through libmodplug is using the api call ModPlug_Seek and the
demuxer will also need to link to libmodplug. This seems like a bad
approach to me. After all, the primary reason for such factoring into
demuxer and decoder (other than clarity) is to allow for separation
between lavfo and lavc, isnt it? In this specific case, a user won't
be able to do mod decoding in the absence of either lavfo or lavc.

Thats kinda the reason current patch implements the whole thing in lavfo.



More information about the ffmpeg-devel mailing list