Last Comment Bug 761762 - Audio playback garbled for Mp4
: Audio playback garbled for Mp4
Status: RESOLVED FIXED
[qa+]
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: ARM Gonk (Firefox OS)
: -- normal (vote)
: mozilla16
Assigned To: cajbir (:cajbir)
:
:
Mentors:
Depends on:
Blocks: 748351 761814 762366
  Show dependency treegraph
 
Reported: 2012-06-05 12:57 PDT by dclarke@mozilla.com [:onecyrenus]
Modified: 2012-06-08 08:13 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
+


Attachments
Fix (7.79 KB, patch)
2012-06-05 22:19 PDT, cajbir (:cajbir)
edwin: review+
Details | Diff | Splinter Review

Description dclarke@mozilla.com [:onecyrenus] 2012-06-05 12:57:05 PDT
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
Comment 1 Jason Smith [:jsmith] 2012-06-05 13:32:48 PDT
Please nom first, do not set the blocker bug flag until the k9o + flag is set.
Comment 2 cajbir (:cajbir) 2012-06-05 13:44:49 PDT
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.
Comment 3 cajbir (:cajbir) 2012-06-05 22:19:57 PDT
Created attachment 630447 [details] [diff] [review]
Fix

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.
Comment 4 Lawrence Mandel [:lmandel] (use needinfo) 2012-06-06 09:00:41 PDT
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.
Comment 5 dclarke@mozilla.com [:onecyrenus] 2012-06-06 14:01:53 PDT
This patch worked for me. 

Samsung II, running the patch.
Comment 7 Graeme McCutcheon [:graememcc] 2012-06-08 04:18:03 PDT
https://hg.mozilla.org/mozilla-central/rev/fa1259597f60

(Merged by Ed Morley)

Note You need to log in before you can comment on or make changes to this bug.