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

[Sebastian Vater]

Vitor Sessak a ?crit :
> On 05/28/2010 02:05 PM, Sebastian Vater wrote:
>> Vitor Sessak a ?crit :
>>>
>>> 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.
>>
>> Yes, since that also allows 24-bit audio output for soundcards
>> supporting it, etc.
>> Maybe we should summarize pros/cons of both approaches, so it's easier
>> to finally decide what's best.
>>
>>>
>>>> - a FIXME here's is how a user would choose the samplerate, maybe a
>>>> AVCodecContext.request_sample_rate in the style of channel_mask?
>>>
>>> Maybe "-sampler_flags" in the same way we have "-sws_flags"?
>>
>> In my eyes, we won't need that for the output PCM stuff, just use
>> avctx->bits_per_coded_sample, avctx->sample_rate, as we do for other
>> sample formats, too. Only the internal mixing engine has to be a bit
>> more configurable.
>>
>>>
>>>
>>> Yes, I'd say that a very important piece of code would be the data
>>> structures holding the decoded collection of notes, instruments, etc.
>>> This will be what the decoders will output (and what we mean by
>>> SAMPLE_FMT_COMPOSER). Since this should be able to describe all
>>> supported MOD formats, it should be pretty flexible. I think it should
>>> be part of libavcodec. Also, the caller app might want to known which
>>> instruments are being played and when and how, so this structs should
>>> be part of the public API (which implies tough review). IMHO, this
>>> should be the first thing to be reviewed and committed, since it
>>> blocks all the rest.
>>
>> I actually plan to start with porting the TuComposer header files (the
>> mod structure itself), then move on to mixing engine stuff (which more
>> "interferes" with lavc/lavf). My idea as discussed on IRC was like this:
>> tucomposer/tucomposer.h =>  libavsequencer/avseq.h
>> tucomposer/player.h, tucomposer/external/mixer.h => 
>> libavsequencer/player.h
>> tucomposer/module.h, song.h, position.h, track.h, instr.h, sample.h,
>> synth.h =>  libavsequencer/module.h
>
> Huh? Nothing in libavcodec?

I think it's better, we decide during review phase what's best to
move/add to lavc for that reason.  As said, then move on...;-)
For the beginning it's probably better to have all stuff in a single
directory, at least that's my 2 cent on it. ;)

This would also sastify Ronald's idea: First starting with #1 then move
up to #2 (which would add stuff to lavc), if I understood you all
correctly.

-- 

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