[FFmpeg-devel] [PATCH] libmodplug wrapper

[Peter Ross]

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

Agree, but the horse has already bolted. A proof-of-concept ProTracker
muxer/demuxer is in the pipeline...

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090714/e69e8a5c/attachment.pgp>