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

Peter Ross pross
Thu May 27 13:56:37 CEST 2010


Hi,

On Thu, May 27, 2010 at 04:31:59AM +0200, Michael Niedermayer wrote:
> On Sun, May 23, 2010 at 11:27:37PM +0200, Sebastian Vater wrote:
> > Dear guys!
> > 
> > Since tomorrow my main GSoC task starts, I thought it would be a good
> > idea now to start discussing of MOD implementation in FFmpeg.

> > This is where MOD differs, with MOD you have freedom to integrate custom
> > samples to the note data, so you have a sound file which sounds always
> > the same (like MP3, WAV, etc.).

Nb: the most recent formats are much more advanced than this. Renoise
for example, is basically a ZIP file, containing an XML description of the
module patterns, and FLAC or MP3 files for samples.

[..]

> I dont think the 1. and. 2. are exclusive, it surely should be possible
> to have a seperate lib and at the same time provide "mod" decoding support
> through the existing APIs.
> And we need to support it through existing apis because anything else would
> be quite inconvenient for applications.
> I am a bit undecided though about seperate lib or no seperate lib

I toyed with ProTracker playback in FFmpeg last year, but misplaced the code
and gave up. My approach was a hybrid between the ones Sebastian listed, namely:

* treat a module as an AVMEDIA_TYPE_AUDIO stream containing CODEC_TYPE_PATTERN.

* add data structure(s) to AVCodecContext that describe the contents of a
sound pattern/module file. The structure must support concepts likes Patterns,
Notes, and Special Commands, etc. (TuComposer will have this already.)

* write demuxers for various module formats. The demuxer would read the file
and converts it into the AVCodecContext pattern data structure.

* write a libavcodec decoder called 'Pattern decoder', that takes CODEC_TYPE_PATTERN
as input. The decoder will process the AVCodecContext structure and outputs audio
samples (SAMPLE_FMT_xxx). Esentially this codec would invoke the TuComposer
functionality.

* write muxers. thus allowing conversion between alike-module formats.

> about the existing APIs i do think they are sufficient for basic playback
> and transcoding.

The approach described achieves this. Furthmore folks who dont want module
decoding in their FFmpeg can use the existing ./configure options to
disable the 'Pattern decoder'.

> For video transcoding (mpeg2 for example) we support reusing the motion
> vectors from the source if the user wants.
> This works as the decoder returns a AVFrame that contains an array of
> motion vectors and the encoder takes a AVFrame as input
> 
> I imagine that for mod something quite similar is possible to transcode
> them to another mod format.
> 
> Its also a long standing feature request to make encode/decode_audio() work
> with AVFrame or a similar structure instead of int16_t*

While a good idea, IMHO this is outside the scope of his GSoC project...

Cheers,

-- 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: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100527/83a8af80/attachment.pgp>



More information about the ffmpeg-devel mailing list