[FFmpeg-devel] [PATCH] libmodplug wrapper

[Jai Menon]

On Sat, Jul 11, 2009 at 12:04 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
> On Fri, Jul 10, 2009 at 01:24:27PM +0000, Jai Menon wrote:
>> 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.
>
> The primary reason for the seperation in this case is so we can watch
> avi/mkv/nut files that have h264 video and mod/s3m/... audio

I would say that this should not be done, because a module is not just
another audiostream. Its like comparing a flash tweened animation and
a bunch of pngs. Yes, I know of retarded things like ogg-in-avi etc.
Maybe (and I doubt someone ever doing this), we can leave it to
demuxer chaining code ;)

-- 
Regards,

Jai