Closed Bug 1098637 Opened 10 years ago Closed 10 years ago

FFmpeg/AAC: do not consider that the decoder didn't output an audio frame as error

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: jya, Assigned: jya)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file, 1 obsolete file)

Currently, the FFmpeg AAC decoder considers that avcodec_decode_audio4 doesn't return an audio frame immediately as an error.

This is an incorrect assumption. A decoder can queue a frame internally and not always return a decoded frame immediately.

A particular example can be seen in http://demo.unified-streaming.com/video/ateam/ateam.ism/ateam.mpd stream.

This causes the MP4Reader to abort playback.
Follow FFmpeg API's guidance:
Some decoders may support multiple frames in a single AVPacket. Such decoders would then just decode the first frame and the return value would be less than the packet size. In this case, avcodec_decode_audio4 has to be called again with an AVPacket containing the remaining data in order to decode the second frame, etc... Even if no frames are returned, the packet needs to be fed to the decoder with remaining data until it is completely consumed or an error occurs.
got_frame_ptrZero if no frame could be decoded, otherwise it is non-zero. Note that this field being set to zero does not mean that an error has occurred. For decoders with CODEC_CAP_DELAY set, no given decode call is guaranteed to produce a frame.

Also, fix a compilation warning and fix Drain() which really didn't do anything before.
Attachment #8522900 - Flags: review?(edwin)
Assignee: nobody → jyavenard
Status: NEW → ASSIGNED
Rebase..
Attachment #8522900 - Attachment is obsolete: true
Keywords: checkin-needed
Blocks: MSE
https://hg.mozilla.org/mozilla-central/rev/b1d9d24148b0
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.