Opened 5 months ago

Closed 5 months ago

#6446 closed defect (invalid)

Regression problem with opus audio (old api)

Reported by: ggarra13 Owned by:
Priority: important Component: avcodec
Version: git-master Keywords: opus regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by cehoyos)

I recently updated my ffmpeg to the latest revision and found that my viewer had problems decoding audio from a matroska (webm) video, which used the opus audio codec. This is with the old audio api (avcodec_decode_audio4). No other audio codecs seem to have a problem.
The error I get is that of a return value of less than 0 and the got_frame variable is 0. While decoding sometimes I get the following message:

Got unexpected packet size after a partial decode

I bisected the git log, and found the commit.

bddb2343b6e594e312dadb5d21b408702929ae04 (does compile and has the opus audio problem)

ffplay plays fine the opus audio, but it is using the new api (not sure if that has something to do with it). I tried switching to the new api, but I could not get it to work with any audio codec. Therefore, I would prefer to stay with the old api.

I am wondering what else can I try to find out why the opus codec fails decoding. Any help is appreciated.

Change History (5)

comment:1 Changed 5 months ago by heleppkes

My code still uses the old API for audio and all Opus samples I had decode fine. Maybe providing a sample that fails for you would help?

comment:2 Changed 5 months ago by ggarra13

I forgot to mention I am on Linux. Try the following:

comment:3 Changed 5 months ago by cehoyos

  • Description modified (diff)
  • Keywords regression added; webm matroska removed
  • Priority changed from normal to important

Are you using the parser?
Please explain how we can reproduce the issue you see.

comment:4 Changed 5 months ago by heleppkes

Your file still decodes fine for me, so its likely related to how you are using the API. It looks like the Opus decoder always consumes full packets as well, so it seems unlikely to cause any special issues.

Last edited 5 months ago by heleppkes (previous) (diff)

comment:5 Changed 5 months ago by ggarra13

  • Resolution set to invalid
  • Status changed from new to closed

I found out that a decoding of an empty packet when codec had CODEC_CAP_DELAY was the cause of the bad decoding.
Thank you very much for all the help.

Note: See TracTickets for help on using tickets.