ffmpeg fails to decode opus test vectors correctly

[Christoph Anton Mitterer]

taken from ​https://trac.ffmpeg.org/ticket/5238#comment:3

ffmpeg fails to decode opus test vectors correctly, in especially:
​http://people.xiph.org/~greg/opus_testvectors/correctness_trimming_nobeeps.opus

even using ffmpeg git:

$ ./ffmpeg -i correctness_trimming_nobeeps.opus correctness_trimming_nobeeps.wav  
ffmpeg version N-78622-g2b5b001 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.3.1 (Debian 5.3.1-9) 20160220
  configuration: --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv --enable-version3 --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libvo_amrwbenc
  libavutil      55. 18.100 / 55. 18.100
  libavcodec     57. 24.105 / 57. 24.105
  libavformat    57. 26.100 / 57. 26.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 34.100 /  6. 34.100
  libavresample   3.  0.  0 /  3.  0.  0
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, ogg, from 'correctness_trimming_nobeeps.opus':
  Duration: 00:00:12.72, start: 0.000000, bitrate: 40 kb/s
    Stream #0:0: Audio: opus, 48000 Hz, mono, fltp
    Metadata:
      ENCODER         : Xiph.Org Opus testvectormaker
      TESTDESCRIPTION : Beeps at the beginning and end of this stream MUST be hidden by preskip and end-trimming.
                      : If the beeps are heard the decoder is broken.
Output #0, wav, to 'correctness_trimming_nobeeps.wav':
  Metadata:
    ISFT            : Lavf57.26.100
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s16, 768 kb/s
    Metadata:
      TESTDESCRIPTION : Beeps at the beginning and end of this stream MUST be hidden by preskip and end-trimming.
                      : If the beeps are heard the decoder is broken.
      encoder         : Lavc57.24.105 pcm_s16le
Stream mapping:
  Stream #0:0 -> #0:0 (opus (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
size=    1193kB time=00:00:11.35 bitrate= 860.4kbits/s speed= 211x    
video:0kB audio:1193kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.006388%

the resulting WAV files still contains the beep

[vk85]

This issue is still present as of commit ad94f1c8abe68a2b38536cc96a31327c6be7b105.
It specifically affects ffmpeg's native opus decoder, libopus is not affected.
The native encoder ignores side data indicating the amount of initialization/padding samples to skip at the beginning of the stream.
This allows them to enter the output as though they were audio samples, the length of the stream is also miscalculated as a result.

Since this means the native encoder isn't spec compliant, I'd suggest changing the default decoder to libopus, if available, until this issue is resolved.
In the meantime, you can try to work around this by seeking to timestamp 0 (-ss 0), as opus streams encoded by libopus will have the first real audio sample at timestamp 0 under most circumstances.

[Rostislav Pehlivanov]

This affects all codecs which can signal a preskip. This also only affects the ffmpeg.c program, API users are fine (as they handle preskip themselves).
No, we will not change the default decoder, never, period. Built-in decoders are better in every way. Its not a decoder's job to handle pre-skip either.
Also you're confusing encoders and decoders.

[Carl Eugen Hoyos]

Fixed by Paul in 18aea7bdd96b320a40573bccabea56afeccdd91c

[Christoph Anton Mitterer]

I've just checked git master (with no configure options, i.e. not using system libs) and all the three correctnes-test-files from ​https://people.xiph.org/~greg/opus_testvectors/ "play back" (that is decode) as they should.

As far as I understood comment 4, the fix for this should also work when e.g. distros use the system libopus, right?

I'd at least guess so, as playing the test vectors with mpv (which uses ffmpeg libs) from Debian sid which has ffmpeg 4.1.1 already plays them correctly.