Closed
Bug 761762
Opened 12 years ago
Closed 12 years ago
Audio playback garbled for Mp4
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
FIXED
mozilla16
People
(Reporter: onecyrenus, Assigned: cajbir)
References
Details
(Whiteboard: [qa+])
Attachments
(1 file)
7.79 KB,
patch
|
eflores
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•12 years ago
|
Comment 1•12 years ago
|
||
Please nom first, do not set the blocker bug flag until the k9o + flag is set.
No longer blocks: k9o-web-platform
blocking-kilimanjaro: --- → ?
Assignee | ||
Comment 2•12 years ago
|
||
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 | ||
Updated•12 years ago
|
Assignee: nobody → chris.double
Assignee | ||
Updated•12 years ago
|
OS: Android → Gonk
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Updated•12 years ago
|
No longer blocks: b2g-product-phone
Updated•12 years ago
|
blocking-basecamp: --- → ?
Assignee | ||
Updated•12 years ago
|
Hardware: x86 → ARM
Assignee | ||
Comment 3•12 years ago
|
||
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)
Comment 4•12 years ago
|
||
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.
Reporter | ||
Comment 5•12 years ago
|
||
This patch worked for me. Samsung II, running the patch.
Attachment #630447 -
Flags: review?(eflores) → review+
Assignee | ||
Comment 6•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa1259597f60
Target Milestone: --- → mozilla16
Comment 7•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/fa1259597f60 (Merged by Ed Morley)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Whiteboard: [qa+]
You need to log in
before you can comment on or make changes to this bug.
Description
•