[FFmpeg-devel] [PATCH v2 14/18] avcodec/avcodec, avformat/movenc: support embedding channel layout to stream side data

[Erkki Seppälä]

Hello!

On 08/31/2016 05:00 PM, Carl Eugen Hoyos wrote:
> Are you using this feature already (internally) or did you just feel like it is
> missing? (Sorry, it is not meant offending.) I wonder if all this complexity
> really has a real-world use-case...
We may or may not be using this functionality internally. Maybe the 
signed off-tag gives a hint where :).
> How is "chnl" related to "chan"? I thought I remember that "chan" already
> offers possibilities for custom channel layouts.
> Can both be used in the same file?
To me it seems these two tags are probably historically connected, chan 
being a precursor to chnl, though there seem to be some big differences 
in the range of options, if not in practical functionality. For example, 
the predefined layouts are completely different - mov_chan.c mentions 85 
predefined channel layouts whereas channel_layouts_isoiec23001_8.h has 20.

The conversions in mov_chan.c seem a bit lossy, though, for example:

     { MOV_CH_LAYOUT_MPEG_4_0_A,         AV_CH_LAYOUT_4POINT0 }, // L, 
R, C, Cs
     { MOV_CH_LAYOUT_MPEG_4_0_B,         AV_CH_LAYOUT_4POINT0 }, // C, 
L, R, Cs
     { MOV_CH_LAYOUT_AC3_3_1,            AV_CH_LAYOUT_4POINT0 }, // L, 
C, R, Cs

Is this not losing the channel order? It doesn't seem like it's 
compensated anywhere.

I doubt the two tags can be used in the same track in a way that it 
makes sense. Perhaps more so in the same file, with alternative audio 
tracks where audio tracks originate from different sources?

It seems the mov_chan.c approach would be applicable to these layouts as 
well, except the mapping between existing FFmpeg layouts might be 
error-prone and one wouldn't want to have duplicate layouts meaning the 
same thing. Also mov_chan.c seems to have code for indicating speaker 
positions (by their coordinates) in ff_mov_read_chan, but it just throws 
them away (it doesn't even try to write anything complicated in 
mov_write_chan_tag).

The trickiest parts in my opinion would be:

1) The same channels can be in different order in the same file in 
different channel layouts. Doesn't FFmpeg throw away this permutation 
information? Does some higher level care about that?

2) There is no API or internals for dealing with speakers at arbitrary 
azimuth/elevation.

I'm of course just selling this patch, but it does seem less risky to 
have a side-data-based implementation in first ;-). (Perhaps even by 
adding a suffix _EXPERIMENTAL to the side data, but it seems FFmpeg 
hasn't done that so far.)