[FFmpeg-devel] [PATCH] libmodplug wrapper

Jai Menon jmenon86
Tue Jul 14 15:20:55 CEST 2009


On Tue, Jul 14, 2009 at 1:10 PM, Peter Ross<pross at xvid.org> wrote:
> 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...

It is ?! :)
It would be awesome if we could peek at WiP code or something? Also,
could you do Screamtracker next ;)

Anyway, as i said earlier, my patch was what a lazy person would do to
get the feature ;)

-- 
Regards,

Jai



More information about the ffmpeg-devel mailing list