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
Attachment #8522900 - Flags: review?(edwin) → review+
Attachment #8522900 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.