[FFmpeg-devel] [PATCH] libmodplug wrapper

[Jai Menon]

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

-- 
Regards,

Jai