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

[Sebastian Vater]

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

> [..]
>
>   
> 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.

>> 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?
Ideally while I'm porting the header files and while they get reviewed,
so when that's done I can start using en-/decode_audio with AVFrame. It
would be much better anyway, because TuComposer mixing engines always
output 32-bit signed samples for best quality (consider, for example
playback of a 16-bit sample with a volume of 1/256). If the actual
16-bit sample value is 0x0001 that get's 0x000001 (which needs 24-bit
precision).

-- 

Best regards,
                   :-) Basty/CDGS (-: