The default bug view has changed. See this FAQ.

Audio playback garbled for Mp4

RESOLVED FIXED in mozilla16

Status

()

Core
Audio/Video
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: onecyrenus, Assigned: cajbir)

Tracking

(Blocks: 1 bug)

unspecified
mozilla16
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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

5 years ago
Blocks: 759945, 715784, 746388
Please nom first, do not set the blocker bug flag until the k9o + flag is set.
No longer blocks: 746388
blocking-kilimanjaro: --- → ?
(Assignee)

Comment 2

5 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

5 years ago
Assignee: nobody → chris.double
(Assignee)

Updated

5 years ago
OS: Android → Gonk
(Reporter)

Updated

5 years ago
Blocks: 748351
No longer blocks: 759945
(Reporter)

Updated

5 years ago
No longer blocks: 715784

Updated

5 years ago
blocking-basecamp: --- → ?
(Reporter)

Updated

5 years ago
No longer blocks: 748351
(Assignee)

Updated

5 years ago
Hardware: x86 → ARM
(Assignee)

Comment 3

5 years ago
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.
Attachment #630447 - Flags: review?(eflores)
(Assignee)

Updated

5 years ago
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: ? → +
(Reporter)

Comment 5

5 years ago
This patch worked for me. 

Samsung II, running the patch.
Attachment #630447 - Flags: review?(eflores) → review+
(Assignee)

Updated

5 years ago
Blocks: 762366
(Assignee)

Comment 6

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.