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

[Michael Niedermayer]

On Thu, May 27, 2010 at 05:43:26PM +0200, Vitor Sessak wrote:
> On 05/27/2010 03:35 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, May 27, 2010 at 7:56 AM, Peter Ross<pross at xvid.org>  wrote:
>>> 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:
>>>> 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.
>>
>> 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.
>
> I'm still undecided of what is best, AVMEDIA_TYPE_AUDIO + 
> SAMPLE_FMT_COMPOSER or AVMEDIA_TYPE_COMPOSER. But the argument for 
> AVMEDIA_TYPE_AUDIO of having audioconvert.c do the PCM conversion in a way 
> that is transparent for caller apps is appealing.

AVMEDIA_TYPE_AUDIO is better but this does not neccessarily implicate
SAMPLE_FMT_SEQ
also 
CODEC_TYPE_S3M/XYZ is better than a single CODEC_TYPE_SEQ

whats open is IMHO if the decoder outputs SAMPLE_FMT_SEQ or
normal PCM and rather exports the "SAMPLE_FMT_SEQ" stuff through fields
of AVFrame
but i think the difference between these isnt all that large, and the
one choosen should maybe be what turns out more convenient in actual
implementation

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/b39b9ca7/attachment.pgp>