Native opus decoder does not remove padding at start

[Julian Chennales]

Summary of the bug:

The native opus decoder does not remove padding at start of file

How to reproduce:

Using a 10s mono 44k sine wave wav file split in two. The files are encoded as opus and then decoded back to wav. When using the native (default) decoder the second file has a clear silence at the beginning which results in an audible glitch if played right after the first file.
When forcing libopus as the decoded this does not happen and the files join perfectly (albeit some understandable encoding artifacts at the split point)

ffmpeg -i sine01.wav -vn -c:a libopus -b:a 64k -vbr on -compression_level 10 sine01.opus.ogg
ffmpeg -i sine02.wav -vn -c:a libopus -b:a 64k -vbr on -compression_level 10 sine02.opus.ogg
 
ffmpeg -i sine01.opus.ogg sine01.deopus.wav
ffmpeg -i sine02.opus.ogg sine02.deopus.wav

ffmpeg -c:a libopus -i sine01.opus.ogg sine01.deopus_libopus.wav
ffmpeg -c:a libopus -i sine02.opus.ogg sine02.deopus_libopus.wav


ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20181017
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100

[Carl Eugen Hoyos]

Please test current FFmpeg git head before reporting issues here.

[Julian Chennales]

While I understand the concept of not dealing with bug reports on "old" versions I am not inclined to do my own build of ffmpeg. I am using the latest readily available binary distribution and the steps to reproduce are very clear. Hopefully there is value in such a report and someone who already has easy access to building ffmpeg can test it at some point.
Maybe there is some intermediate status worth having before "invalid", something like "needs to be reproduced in HEAD version"
Anyway, not looking for controversy. Hope this helps.

[Hendrik]

This is probably fixed in 18aea7bdd96b320a40573bccabea56afeccdd91c, can only be verified by using a master build.

[Carl Eugen Hoyos]

Replying to jchennales:

While I understand the concept of not dealing with bug reports on "old" versions I am not inclined to do my own build of ffmpeg. I am using the latest readily available binary distribution

Where did you get this binary?

[Elon Musk]

This should be marked as duplicate of #5258.

[Julian Chennales]

I got it from this site: ​https://ffmpeg.zeranoe.com/builds/

My bad, I had downloaded the latest "release" binary but they do also offer the nightlies. I redid the test and can confirm it does not happen in this version:

ffmpeg version N-92657-ga271025215

Sorry for the confusion!