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.
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.
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.
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.
This patch worked for me. Samsung II, running the patch.
https://hg.mozilla.org/mozilla-central/rev/fa1259597f60 (Merged by Ed Morley)