887517 - Android: Audio's canPlayType() fails for MP3 if codec is supplied

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Ian Gilman [:iangilman]]

This is a followup to bug 838331 and bug 841239, which fixed this issue for Firefox OS and Windows, respectively. :cpearce has said we'll need to fix it separately on each affected platform, so I'm filing bugs for each.

At any rate, the issue is that (new Audio()).canPlayType('audio/mpeg; codecs="mp3"') should return "probably", whereas it currently returns "". See bug 838331 for more info. 

I'm particularly interested in this platform, due to my work on the JavaScript API for Rdio and our mobile support. Can anyone point me to the right place in the code to make the change?

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

This bug impacts site compatibility wrt the ability to play MP3 files. (See bug 899748 for an example.) Can we please get this bug on the Firefox for Android roadmap?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Hey Lawrence, best way to get to get bugs like this on our radar is to request tracking-fennec

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

Chris, Ian is looking for a pointer to the code above

Comment 4

[cajbir (:cajbir)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #3)
> Chris, Ian is looking for a pointer to the code above

Looks like content/media/DecoderTraits.cpp in the MOZ_MEDIA_PLUGINS define blocks.

Comment 5

[Ian Gilman [:iangilman]]

Chris, that's where the patch for bug 838331 landed. My understanding was that that was for Firefox OS, not Android. The information I'm looking for is where the Android version of that same check is located. In other words, if I wanted to port that fix from Firefox OS to Android, where would I look to make the Android fix?

Or was I mislead in thinking content/media/DecoderTraits.cpp (in mozilla-central) is for Firefox OS? If that code is for Android instead (and other platforms?), then perhaps this issue is already fixed?

Comment 6

[cajbir (:cajbir)]

That file contains the code for most of the backends for detecting codec support. The MOZ_OMX_DECODER blocks are B2G which is where I see the support for the 'mp3' codec. The MOZ_MEDIA_PLUGINS blocks are for Android.

Comment 7

[Ian Gilman [:iangilman]]

Oh, I see! Thank you for clearing that up. I'll make the fix.

Comment 8

[Ian Gilman [:iangilman]]

Ok, I've had a chance to take a look at it now, and it looks to be beyond my capabilities.

In DecoderTraits::CanHandleMediaType() in content/media/DecoderTraits.cpp it calls MediaPluginHost::FindDecoder() (located in content/media/plugins/MediaPluginHost.cpp) to get the codecs array. FindDecoder() grabs the codecs array out of the plugin that handles the media type, so to make this fix we have to go into the plugin for audio/mpeg.

I suppose if someone can point me to its code, I can take a look, but otherwise someone else may need to write this patch.

Comment 9

[Felix Niklas]

This bug is crippling the music-players on several band websites I built.
I need the mp3-support-detection to fallback to flash in desktop-Firefox.

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 12

[Hallvord R. M. Steen [:hallvors]]

P5? This breaks real sites..

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Hallvord R. M. Steen from comment #12)
> P5? This breaks real sites..

It was just a mass-change on unprioritized bugs, hoping to get the critical bugs noticed. And it worked!

Comment 14

[Mike Taylor [:miketaylr]]

I think this has already been fixed. gMpegAudioCodecs is no longer behind a MOZ_WIDGET_GONK ifdef, and (new Audio()).canPlayType('audio/mpeg; codecs="mp3"'); returns "probably" in Fennec Nightly. So, thanks person who fixed this, whoever you were.