[FFmpeg-user] [BUG] libopus "mapping family" option breaks encoding of audio streams with more than 2 channels

Peter White peter.white at posteo.net
Sun Aug 7 19:33:54 EEST 2016


Apparently the -mapping_family option for the libopus encoder,
introduced by commit 3794187, breaks encoding of audio with more
than 2 channels. Encoding a 5.1 audio stream without any further
options errors out, because channel layout 5.1(side) is supposedly
invalid. OTOH, opusenc has no problem encoding such streams.

$ ffmpeg -y -i sample.flac sample.opus
ffmpeg version N-81293-g81fcd91 Copyright (c) 2000-2016 the FFmpeg 
developers
    built with gcc 4.9.2 (Debian 4.9.2-10)
    configuration: --extra-cflags='-march=native' --enable-gpl 
--enable-nonfree --enable-libfdk-aac --disable-runtime-cpudetect 
--enable-libx264 --enable-libvorbis --enable-gnutls --enable-opengl 
--enable-libopus --enable-libfreetype --enable-libfontconfig 
--enable-libfribidi --enable-libsoxr
    libavutil      55. 28.100 / 55. 28.100
    libavcodec     57. 51.100 / 57. 51.100
    libavformat    57. 46.100 / 57. 46.100
    libavdevice    57.  0.102 / 57.  0.102
    libavfilter     6. 50.100 /  6. 50.100
    libswscale      4.  1.100 /  4.  1.100
    libswresample   2.  1.100 /  2.  1.100
    libpostproc    54.  0.100 / 54.  0.100
Input #0, flac, from 'sample.flac':
    Metadata:
      ENCODER         : Lavf57.41.100
    Duration: 00:00:10.00, start: 0.000000, bitrate: 3094 kb/s
      Stream #0:0: Audio: flac, 48000 Hz, 5.1(side), s32 (24 bit)
[libopus @ 0x3799240] Invalid channel layout 5.1(side) for specified 
mapping family -1.
Output #0, opus, to 'sample.opus':
    Metadata:
      ENCODER         : Lavf57.41.100
      Stream #0:0: Unknown: none
      Metadata:
        encoder         : Lavc57.51.100 libopus
Stream mapping:
    Stream #0:0 -> #0:0 (flac (native) -> opus (libopus))
Error while opening encoder for output stream #0:0 - maybe incorrect 
parameters such as bit_rate, rate, width or height

Setting -mapping_family 1, which, according to the docs, should be the
correct setting for surround plus surround masking and LFE
optimizations enabled, results in the same error:

$ ffmpeg -y -i sample.flac -mapping_family 1 sample.opus
ffmpeg version N-81293-g81fcd91 Copyright (c) 2000-2016 the FFmpeg 
developers
    built with gcc 4.9.2 (Debian 4.9.2-10)
    configuration: --extra-cflags='-march=native' --enable-gpl 
--enable-nonfree --enable-libfdk-aac --disable-runtime-cpudetect 
--enable-libx264 --enable-libvorbis --enable-gnutls --enable-opengl 
--enable-libopus --enable-libfreetype --enable-libfontconfig 
--enable-libfribidi --enable-libsoxr
    libavutil      55. 28.100 / 55. 28.100
    libavcodec     57. 51.100 / 57. 51.100
    libavformat    57. 46.100 / 57. 46.100
    libavdevice    57.  0.102 / 57.  0.102
    libavfilter     6. 50.100 /  6. 50.100
    libswscale      4.  1.100 /  4.  1.100
    libswresample   2.  1.100 /  2.  1.100
    libpostproc    54.  0.100 / 54.  0.100
Input #0, flac, from 'sample.flac':
    Metadata:
      ENCODER         : Lavf57.41.100
    Duration: 00:00:10.00, start: 0.000000, bitrate: 3094 kb/s
      Stream #0:0: Audio: flac, 48000 Hz, 5.1(side), s32 (24 bit)
[libopus @ 0x3a04260] Invalid channel layout 5.1(side) for specified 
mapping family 1.
Output #0, opus, to 'sample.opus':
    Metadata:
      ENCODER         : Lavf57.41.100
      Stream #0:0: Unknown: none
      Metadata:
        encoder         : Lavc57.51.100 libopus
Stream mapping:
    Stream #0:0 -> #0:0 (flac (native) -> opus (libopus))
Error while opening encoder for output stream #0:0 - maybe incorrect 
parameters such as bit_rate, rate, width or height

For reference, the same file fed to opusenc:
$ opusenc sample.flac sample.opusenc.opus
Encoding using libopus 1.1.3 (audio)
-----------------------------------------------------
     Input: 48kHz 6 channels
    Output: 6 channels (4 coupled, 2 uncoupled)
            20ms packets, 320kbit/sec VBR
   Preskip: 312

Encoding complete
-----------------------------------------------------
         Encoded: 10.02 seconds
         Runtime: 1e-06 seconds
                  (1.002e+07x realtime)
           Wrote: 344242 bytes, 501 packets, 13 pages
         Bitrate: 272.683kbit/s (without overhead)
   Instant rates: 6kbit/s to 625.6kbit/s
                  (15 to 1564 bytes per packet)
        Overhead: 0.786% (container+metadata)

But the default -mapping_family -1 should work, just with surround
masking and LFE optimizations disabled. BTW, why disable those by
default with no way of manually enabling them? The way it is now, I
have two suboptimal choices:

1. Take advantage of autodetection of the channel layout and ffmpeg
selecting the appropriate mapping family but at the same time I lose
surround and LFE optimizations.

2. Select mapping family 1 for surround and get the above mentioned
optimizations but lose autosetting mapping family.

I find that a rather curious design choice. Could someone please
explain why it was made that way? Of course, 1. and 2. are
hypothetically speaking for the case when it actually works, which it
does not at the moment.

Plus, opusenc enables those optimizations by default. I cannot see, why
it would be desirable to disable them at all.

Also, I am pretty certain I had it working once. I wrote a mail to this
list, after I first discovered this new option. Then it must have
worked, because there was a noticeable difference in file size between
-mapping_family 1 and the default. But I cannot for the life of me get
back to that state with git. I have done this:

$ git checkout $(git rev-list -1 --before="Jul 18 2016 20:39" master)

because that date was just after I had tested different mapping family
settings. But maybe something in the surrounding environment changed or
I am doing something wrong with git, which still is rather difficult
for me to get my head around at times. So, any help on that front would
be greatly appreciated if your reply is "works for me".

Anyway, so far I could only git-bisect to the point when the mapping
family option was introduced, which is also the same commit which
causes above breakage (commit: 3794187). See attached git-bisect log.
As you can see by the above ffmpeg output my tests prior to writing
this mail were done with the most recent git master. So there is still
some possibility that the bug went away and came back between commits
3794187 and 81fcd91. But I wouldn't know how to easily find it by
bisecting or any other means, since I could only find two "bad" commits.

I have attached the full output of the two ffmpeg commands above with
-v 9 -loglevel 99 added. I think this way the mail stays reasonably
readable without losing any information.


Best,
Peter White

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapping_family_default.log
Type: text/x-log
Size: 4441 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20160807/fa1964a3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapping_family_1.log
Type: text/x-log
Size: 4533 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20160807/fa1964a3/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapping_family.git-bisect.log
Type: text/x-log
Size: 1921 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20160807/fa1964a3/attachment-0002.bin>


More information about the ffmpeg-user mailing list