[FFmpeg-devel] MOD support for FFmpeg (My GSoC 2010 task starts tomorrow)

[Michael Niedermayer]

On Fri, May 28, 2010 at 01:50:04PM +0200, Sebastian Vater wrote:
> Ronald S. Bultje a ?crit :
> > Hi,
> >
> > I had something similar in mind, we (Vitor, me and Sebastian)
> > discussed this on IRC earlier. However, we'd like to more-or-less keep
> > the mod format even in "decoded" samples.
> >
> > - write demuxers that can "parse" mod files. These would be small,
> > like raw demuxers. The output is AVMEDIA_TYPE_AUDIO with
> > CODEC_TYPE_S3M/XYZ etc.
> > - write decoders that can "decode" mod file b{it,yte}streams into
> > collections of notes, etc. The output would be SAMPLE_FMT_MOD or
> > SAMPLE_FMT_COMPOSER. Mans wants it to be called SAMPLE_FMT_KITTEN.
> > - the "tracker" would then be a converter in the style of
> > audioconvert.c, which converts from SAMPLE_FMT_KITTY to
> > SAMPLE_FMT_S16/U8/FLOAT
> >   
> 
> I doubt that Mans meant SAMPLE_FMT_KITTEN really serious. ;-)
> Regarding the name I dislike SAMPLE_FMT_MOD, though, because the MOD
> engine can also be used for MIDI support (playback of .MID files), like
> OpenCubicPlayer does. It loads the MIDI samples from the GUS patches or
> a similar instrument bank, convert the note data from .MID files into
> it's internal MOD playback engine and let's rock then...

> But I have another idea for a name of it: SAMPLE_FMT_SEQ (for SEQUENCER)...

_SEQ sounds good to me (be that a sample_fmt codec_id or otherwise in the
implementation


> 
> > - a FIXME here's is how a user would choose the samplerate, maybe a
> > AVCodecContext.request_sample_rate in the style of channel_mask?
> > - Vitor had another bunch of comments here but I forgot what it was
> > exactly. Vitor?
> >   
> 
> Why not simply using actual fields for samples stuff that is already in
> AVCodecContext?

> For setting the mixing routine output rate, just set avctx->sample_rate
> to the desired value.
> To precise a bit:
> If it's set to 0, the mixing rate is choosen by FFmpeg depending on the
> target hardware (query AVDevice?), 

the code will likely not be able to querry the hardware as that can be
behind one of dozends of different APIs (SDL, ALSA, OSS, ...)
but we surely can use the sample_rate of the available sound samples
as a hint toward what sample rate the output at least needs to sound good


[...]
> 
> > where-ever he wants, but the code will eventually live in FFmpeg SVN
> > and thus go through full review here. He'll probably need a ff-soc
> > repo account to put his work-in-progress because keeping track of 100
> > patches will make us dizzy.
> >   
> 
> I guess 100 patches would not only make us dizzy... ;)
> It would be enough though, for the first time, that I get only rights to
> commit to /libavcomposer/* (or how we will call that finally), if we

i dont think limiting commit rights to some directory makes sense
if you need commit access to ffmpeg svn then you should have normal
write access to it


> finally choose the new library approach. And later when it's finished
> enough to be usable we start integrating that into lavc. This way,
> development is in first stage completely independent of remaining and we
> don't harm much by changing structures within /libavcomposer/*.

> BTW, what about calling this libavsequencer?

if we agree to have a seperate lib then the name is fine

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- 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/20100611/bf2e9e58/attachment.pgp>