[Ffmpeg-devel] channel ordering and downmixing

[Michael Niedermayer]

Hi

On Thu, Apr 05, 2007 at 04:47:56AM -0400, Justin Ruggles wrote:
> Hi,
> 
> Justin Ruggles wrote:
> > I need some advice on a channel ordering and downmixing framework.  I've
> > been trying to figure out the best solution for a while and keep running
> > into road blocks.
> 
> After spending too much time just pondering different ideas, I decided
> to give it a go and try one out.
> 
> The attached patch isn't really meant to be a working patch, but more of
> a conceptual sketch of a basic design.  I want to get ideas and comments
> before taking the time to implement it in full.
> 
> The general concept is:
> 
>  - add an AVChannelLayout struct to AVCodecContext
>  - have the muxer set its preferred channel layout in read_header()

muxers dont read headers demuxers do, muxer write headers ...


>  - have the decoder override the channel layout if it wants to
>  - user-level API: av_channel_mix_init(), av_channel_mix(),
>                    av_channel_mix_close()
>  - the encoder can set the channel layout in encode_init or just set the
>    number of channels and set the mask to CHANNEL_MASK_NONE to let the
>    muxer decide
>  - if avctx->channel_layout.mask is CHANNEL_MASK_NONE, the muxer should
>    set the channel layout

i think the AVCodec encoder should have a list of supported layouts and
the user app should choose one


> 
> Any suggestions/critiques would be great. :)

id say first get rid of the floats
then there are no ff_/av_ prefixes on non static things

now to the actual design
i think downmix coeffs are not a part of the channel layout
the channel layout is rather location and type of speakers, that could be
simply right, left, front, ... or x,y / x,y,z coordinates or direction in
radians or something

from that you can then somehow ;) find the default mixing coeffs to convert
from layout X to Y, hardcoding them all is not a good idea, as there are too
many as soon as you consider more then mono / stereo as target

i also would strongly suggest to make AVChannelLayout a pointer in
AVCodecContext, otherwise we can NOT add a field to AVChannelLayout
in the future
this also allows us to simple make this point to a static const
AVChannelLayout

one choice would be

typedef struct AVChannelLayout{
    /**
     * direction (0 is front, 1<16 is right, 2<<16 is back, 3<<16 is left).
     * the number of channels can be found in AVCodecContext.channels
     */
    int *azimuth;
    /**
     * direction (0 is front, 1<16 is up, -1<<16 is down).
     * the number of channels can be found in AVCodecContext.channels
     */
    int *elevation;
}AVChannelLayout;

anoter would be

typedef struct AVChannelLayout{
    /**
     * x(-left->+right), y(-back->+front), z(-down->+up) position.
     * the number of channels can be found in AVCodecContext.channels
     */
    int (*position)[3];
}AVChannelLayout;


[...]

> +const AVChannelLayout mono_channel_layout = {
> +    .channels = 1,
> +    .mask     = CHANNEL_MASK_MONO;
> +    .layout   = { CHANNEL_CENTER, },
> +    .mono_downmix   =   { 1.000, },
> +    .stereo_downmix = { { 1.000, },
> +                        { 1.000, } },

this looks wrong IMHO, 2 speakers sound louder then 1 so it shouldnt be
all 1.000


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070405/3602fd43/attachment.pgp>