aboutsummaryrefslogtreecommitdiffstats
path: root/libavformat/ffmetadec.c
diff options
context:
space:
mode:
authorGaullier Nicolas <nicolas.gaullier@arkena.com>2014-06-25 10:29:30 +0000
committerMichael Niedermayer <michaelni@gmx.at>2014-06-26 01:01:22 +0200
commit3eae34d50fc52ff7b8367f9ade1cd189bfc1a221 (patch)
treefd95b6b3e3bed076248d064d5f7e528360b9c1c7 /libavformat/ffmetadec.c
parentb8255a4c7096ecddea68e12e067c7a9b2e14ed8d (diff)
downloadffmpeg-3eae34d50fc52ff7b8367f9ade1cd189bfc1a221.tar.gz
avformat/mxfenc: set/force channelcount in MXF D-10
There are interoperability issues with D-10 related to the channelcount property in the generic sound essence descriptor. On one side, SMPTE 386M requires channel count to be 4 or 8, other values being prohibited. The most widespread value is 8, which seems straightforward as it is the actual size of the allocated structure/disk space. At the end, it appears that some vendors or workflows do require this descriptor to be 8, and otherwise just "fail". On the other side, at least AVID and ffmpeg do write/set the channel count to the exact number of channels really "used", usually 2 or 4, or any other value. And on the decoding side, ffmpeg (for example) make use of the channel count for probing and only expose this limited number of audio streams (which make sense but has strong impact on ffmpeg command line usage, output, and downstream workflow). At the end, I find it pretty usefull to simply give ffmpeg the ability to force/set the channel count to any value the user wants. (there are turnaround using complex filters, pans, amerge etc., but it is quite boring and requires the command line to be adapted to the input file properties) Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com> Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Diffstat (limited to 'libavformat/ffmetadec.c')
0 files changed, 0 insertions, 0 deletions