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

[Vitor Sessak]

On 05/28/2010 02:28 PM, Sebastian Vater wrote:
> 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.

I disagree. One important thing to be reviewed will be your design of 
what should be in libavcodec and what should be outside it.

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

There might be a first time, but we don't usually accept code in the 
wrong dir to move it later in our main repository. We try to get it as 
right the first time as possible.

You could make in the soc repo:
soc/composer/libavcodec/avseq.h
soc/composer/libavcompose/whatever.h
etc...

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

Then I disagree with Ronald. For me #0 would be getting libavcodec/*.h 
committed (before adding anything whatsoever to libavcompose or lavf). 
But it can be done at the done in parallel with #1.

-Vitor