Closed Bug 761762 Opened 12 years ago Closed 12 years ago

Audio playback garbled for Mp4

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla16
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: onecyrenus, Assigned: cajbir)

References

Details

(Whiteboard: [qa+])

Attachments

(1 file)

http://cd.pn/t2/

Playback of the audio from an h264 encoded video sample is garbled on B2G Devices.

logcat output seems to indicate unknown stream type. 

E/AudioPolicyManagerBase( 2251): unknown stream type
E/AudioPolicyManagerBase( 2251): unknown stream type
E/AudioPolicyManagerBase( 2251): unknown stream type
E/AudioPolicyManagerBase( 2251): unknown stream type
Please nom first, do not set the blocker bug flag until the k9o + flag is set.
No longer blocks: k9o-web-platform
blocking-kilimanjaro: --- → ?
It's caused by libstagefright returning an incorrect channel count. When we read the metadata the channel count returned is '1'. We initialize the audio system with that but the channel count is acutally '2', which is returned by later calls to retrieve it once the media is playing.
Assignee: nobody → chris.double
OS: Android → Gonk
Blocks: 748351
No longer blocks: 759945
No longer blocks: b2g-product-phone
blocking-basecamp: --- → ?
No longer blocks: 748351
Hardware: x86 → ARM
Attached patch FixSplinter Review
This patch refactors the audio reading code in the omx plugin. It now reads the initial audio frame during metadata decoding to see if it has channel/samplerate information. If it does, the decoder uses these values. If it does not, it queries the metadata from the container. It saves this audio buffer so that it can use it during the first audio read.

All the existing test files play with this fix:

http://cd.pn/b
http://cd.pn/b2
http://cd.pn/a
http://cd.pn/t2
http://cd.pn/t3

Before this patch 't2' and 't3' played with bad audio.
Attachment #630447 - Flags: review?(eflores)
Blocks: 761814
k9o+ and basecamp+.

(In reply to Jason Smith [:jsmith] from comment #1)
> Please nom first, do not set the blocker bug flag until the k9o + flag is
> set.

I would actually prefer to have people set the blocker bug so that it's clear which requirement they are targeting. We can always remove the blocker bug if we decide to k9o-. In this case there is a specific bug for H.264/AAC and MP3 playback to block on: bug 748351.
Blocks: 748351
blocking-basecamp: ? → +
blocking-kilimanjaro: ? → +
This patch worked for me. 

Samsung II, running the patch.
Attachment #630447 - Flags: review?(eflores) → review+
Blocks: 762366
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa1259597f60
Target Milestone: --- → mozilla16
https://hg.mozilla.org/mozilla-central/rev/fa1259597f60

(Merged by Ed Morley)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: