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

[Peter Ross]

On Fri, May 28, 2010 at 01:16:00PM +0200, Sebastian Vater wrote:
> Peter Ross a ?crit :
> > Hi,
> >
> >   
> > 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 guess OGG Vorbis for samples is valid, too. ;)

Cool.

> > [..]
> >
> >   
> > 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.)
> >   
> 
> Yes, I also want to start with porting the heading the header files of
> TuComposer to FFmpeg, since they're all public, they should be reviewed
> carefully.
> Once that is set in stone, actual port of TuComposer can be started.
> 
> > * 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.
> >   
> 
> How far did you advance by your approach? And what issues you
> encountered? Just to be aware of them, if they appear with our final
> approach, too.

I got as far as writing a ProTracker demuxer and muxer, and writing a Pattern
decoder that printed the Patterns to av_log().

Issues with this approach was

* high coupling between libavcodec and libavformat. As the pattern data structures
  'evolved', I then had to sync the muxer, demuxer and pattern decoder across
  lavformat and lavcodec.

* I had the demuxer outputting packets containing the order/pattern number.
  This worked okay for ProTracker, may not for all module formats.

* The ProTracker format has a very simple 'samples library' scheme using
  PCM samples. The pattern decoder was incomplete, so I didnt bother to use
  samples. Need to figure out how to handle compressed samples
  (and should these be decoded at init() time, or as-needed).

> >> 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...
> >   
> 
> Would somebody else then like to do this as a parallel work?

I will put my hand up if noone else does.

-- 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/20100529/ed97d1fb/attachment.pgp>