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.)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
