[FFmpeg-devel] [PATCH] libmodplug wrapper

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090711/e32d5c3d/attachment.pgp>