[FFmpeg-devel] [PATCH] libmodplug wrapper

[Michael Niedermayer]

On Tue, Jul 14, 2009 at 04:18:26PM +0530, Jai Menon wrote:
> On Mon, Jul 13, 2009 at 2:01 PM, Michael Niedermayer<michaelni at gmx.at> wrote:
> > On Sun, Jul 12, 2009 at 11:57:07PM +1000, Peter Ross wrote:
> >> On Sat, Jul 11, 2009 at 04:27:23AM -0700, Baptiste Coudurier wrote:
> >> > Hi Peter,
> >> >
> >> > On 07/11/2009 02:38 AM, Peter Ross wrote:
> >> >> On Sat, Jul 11, 2009 at 06:11:29AM +0300, Kostya wrote:
> >> >>> On Sat, Jul 11, 2009 at 02:04:08AM +0200, Michael Niedermayer
> >> >>> wrote:
> >> >>>> On Fri, Jul 10, 2009 at 01:24:27PM +0000, Jai Menon wrote:
> >> >>> [...]
> >> >>>> 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
> >> >>> Err, you can legally kill anybody trying to make such perverted
> >> >>> format (i.e. Matroska devs).
> >> >>
> >> >> My reaction is completely the opposite.
> >> >>
> >> >>>> From my experience (several MOD-like and Adlib tracker formats in
> >> >>>> DOS
> >> >>> times), you can represent tracker as two parts: samples and notes.
> >> >>> For a bit modern people - like MIDI file with its own soundfont. So
> >> >>> usually you have hundreds of kilobytes or more of samples (which
> >> >>> may be treated as extradata) and less than 1KB of notes which
> >> >>> define what to play. Also notes are grouped into patterns and
> >> >>> subpatterns which may be repeated certain number of times, with
> >> >>> speed changes that results in each part playing time very greatly
> >> >>> varying. This makes it an awful sound format for generic
> >> >>> container.
> >> >>
> >> >> This suggests to me that FFmpeg's generic container format isn't
> >> >> generic enough.
> >> >
> >> > I don't recall FFmpeg having a generic container format. What do you
> >> > have in mind ?
> >>
> >> What I intended to say that the current libavformat/libavcodec API
> >> targets the use of "generic container formats" comprising streams
> >> and time-stamped packets.
> >>
> >> MOD-files do not adhere to this generic format. They contain
> >> instrument samples, patterns, and a pattern ordering table.
> >
> > There are 2 ways to map mod to ffmpegs system,
> > 1. instrument samples & patterns are extradata, pattern ordering are packets
> >
> > 2. instrument sampes are extradata, patterns are packets and the mod muxer
> > ? would compress patterns using pattern ordering tables
> 
> Actually, thats how most mod renderers work. They map a
> mod/s3m/it/xm/whatever to an internal representation and use generic
> playback code. But i don't think we should reinvent the wheel when
> there are already high-quality (in terms of effect reproduction) mod
> playback libraries out there, which implement a wide range of tracker
> formats. Native implementations are desirable but I doubt there will
> be interest in such high volume of work for formats which don't
> represent the mainstream media use case. I say "high volume" because
> we'll have to come up with a common representation, write loaders for
> most mod formats and finally playback code (which would involve
> implementing all massively used effects, and of course tuning them by
> ear). Someday maybe....but i suggest a wrapper till we find people who
> are willing to take this up ;)

Ive not suggested to write a native implementation though wouldnt mind
if someone did.
what iam saying is that the decoding doesnt belong in the demuxer
if all else fails, one still can at least put the whole mod in extradata
and let the decoder load that through te lib


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/20090714/367cd796/attachment.pgp>