809186 - ADTS raw AAC format not supported in Music app

Status: RESOLVED DUPLICATE of bug 807361

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

Description

[Dave Hylands [:dhylands]]

Add support to recognize .aac files as mimetype audio/aac-adts

Nom'd blocking-basecamp because 807361 is blocking-basecamp

Comment 1

[Dave Hylands [:dhylands]]

Attachment: Recognize .aac extension as mimetype audio/aac-adts

Comment 2

[Dave Hylands [:dhylands]]

Attachment: v2 - Recognize .aac extension as mimetype audio/aac-adts

Comment 3

[Dave Hylands [:dhylands]]

Pushed to inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/e655c9d59704

Comment 4

[Dave Hylands [:dhylands]]

Backed out change from inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/92684bd694ed

until we decide (over in bug 807361) that we really want this.

Comment 5

[Doug Turner (:dougt)]

minus-ing for now.  It isn't clear that we want to support raw aac.  Please renom, if we do want to block for this.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This needs to be brought to the newsgroup. We spent a year debating if we were going to add mp3/h264 support to the web. Adding AAC deserves more attention than a simple bug.

Comment 7

[cajbir (:cajbir)]

(In reply to Jonas Sicking (:sicking) from comment #6)
> Adding AAC deserves more attention than a simple bug.

We support AAC already. AAC in an MP4 container should just work. It's whether AAC outside of MP4 should be supported.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't know what implications that has really (like, is the container where copyright enforcement lives? Are there patents covering the container format?), but it still seems to me like this is still best discussed in the newsgroups.

Comment 9

[Chris Lee [:clee]]

The most common container format is mp4, so I agree this should be minus'ed for v1.

Comment 11

[(not reading bugmail) Nick Desaulniers [:\n]]

So a third party developer, TuneIn, is looking to create an app for Firefox OS, but there is a significant number of their internet radio streams that are AAC encoded outside of the MP4 container.  If you try and load an AAC encoded song for an audio object's src property, you'll get the following error in adb logcat on device:

E/GeckoConsole(  472): [JavaScript Warning: "HTTP "Content-Type" of "audio/aac" is not supported. Load of media resource http://174-37-58-160.webnow.net.br/greenfm.aac failed." {file: "http://10.250.21.77:8000/index.html" line: 0}]

It's not practical to ask every single internet radio streamer who's serving AAC encoded files to transcode to the MP4 container.  Is it more practical for us to implement AAC container support, or tell them we can't support raw AAC outside of MP4?

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

I think it's reasonable that we support ADTS given that we already support AAC in MP4. There are patents covering both AAC codec and the MP4 container, but we're using the system decoding (and demuxing) libraries on B2G, so this is not an issue.

Comment 13

[(not reading bugmail) Nick Desaulniers [:\n]]

Also Roc's comment in this (duplicate?) bug has confused me [0].  The MIME type error that I'm seeing is for 'audio/aac' but the patch in this bug looks like 'audio/aac-adts'.  The final comment in the duplicate bug looks like the bug was closed because there was no need for aac-adts, should I open a new bug for audio/aac, or reopen the duplicate?

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=807361#c27
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=807361#c38

Comment 14

[cajbir (:cajbir)]

(In reply to Nick Desaulniers [:\n] from comment #13)
> Also Roc's comment in this (duplicate?) bug has confused me [0].

Bug 807361 is in a restricted group so probably isn't the best for public discussion of supporting AAC - which is why this bug exists I guess.

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

Do other browser's on mobile and desktop support ADTS?

Comment 16

[cajbir (:cajbir)]

(In reply to Chris Pearce (:cpearce) from comment #15)
> Do other browser's on mobile and desktop support ADTS?

IE on Windows Phone 8 does.

Comment 17

[Chris Pearce [:cpearce (Not reading bugmail)]]

On Windows 8:
Chrome tries to load that stream with a quicktime plugin. IE11 tries to download it. 

If I save part of that stream to file, that file does not play in IE11 or chrome with mimetype audio/aac or audio/aac-adts. Firefox can play the file if I serve it using audio/mpeg (Windows Media Foundation must be handling, this wasn't a deliberate decision) but the stream must be HE-AAC with implicitly signalled SBR, as it suffers from bug 875644.

Test page: http://people.mozilla.com/~cpearce/adts.html

Comment 18

[cajbir (:cajbir)]

(In reply to Chris Pearce (:cpearce) from comment #17)
> 
> Test page: http://people.mozilla.com/~cpearce/adts.html

IE on WP8 gives "Invalid Source" for this page. It does stream AAC files if you go to the AAC file directly, probably downloading and passing it to the system player.

Comment 19

[Chris Pearce [:cpearce (Not reading bugmail)]]

people.mozilla.com is serving that file with mime type audio/mpeg, which is why you'll be able to play that file if you load it directly (Firefox on Windows can play it using that mime type using the system player too).

Or did you mean that you can load http://174-37-58-160.webnow.net.br/greenfm.aac in IE on WP8 and it plays?

Comment 20

[cajbir (:cajbir)]

(In reply to Chris Pearce (:cpearce) from comment #19)
> 
> Or did you mean that you can load
> http://174-37-58-160.webnow.net.br/greenfm.aac in IE on WP8 and it plays?

Yes, this plays using the system player.

Comment 21

[Mike Kaply [:mkaply]]

Can someone please explain:

(In reply to Dave Hylands [:dhylands] from comment #4)
> Backed out change from inbound:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/92684bd694ed
> 
> until we decide (over in bug 807361) that we really want this.

Bug 807361 is a protected bug, so I have no idea what that means.

Why was such a simple change backed out?

We're working on a web radio for Firefox and would love to have this.

Comment 22

[cajbir (:cajbir)]

(In reply to Mike Kaply (:mkaply) from comment #21)
> Can someone please explain:
> 
> Why was such a simple change backed out?
> 
> We're working on a web radio for Firefox and would love to have this.

It was backed out because at the time it wasn't decided whether AAC outside of MP4 container would be supported.

Comment 23

[Mike Kaply [:mkaply]]

(In reply to Chris Double (:doublec) from comment #22)
> (In reply to Mike Kaply (:mkaply) from comment #21)
> It was backed out because at the time it wasn't decided whether AAC outside
> of MP4 container would be supported.

I guess this is a pure political issue? What is bug 807361?

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll leave it up to the media team to choose what codecs to support where. However do remember that we have the choice of enabling some codecs only to privileged apps as to prevent the codec from spreading to the web at large.

Comment 25

[Andreas Gal :gal]

I am ok with enabling AAC for privileged apps only. We want to avoid proliferation on the Web. For parity with native apps this makes sense for privileged apps.

Comment 26

[Mike Kaply [:mkaply]]

(In reply to Andreas Gal :gal from comment #25)
> I am ok with enabling AAC for privileged apps only. We want to avoid
> proliferation on the Web. For parity with native apps this makes sense for
> privileged apps.

It's already proliferated on the web for streaming.

http://www.shoutcast.com/

Not supporting it makes sure that you'll never have full Web Radio support in the Firefox browser.

And why do people keep ignoring this statement:

> I guess this is a pure political issue? What is bug 807361?

Is there some secret cabal?

Comment 27

[Andreas Gal :gal]

What browser ships with AAC enabled for content?

Comment 28

[Mike Kaply [:mkaply]]

> What browser ships with AAC enabled for content?

Well, Safari. But in this case, the AAC is played through WinAMP or other non browser players.

What would be nice is if these streams could be played in Firefox.

Comment 29

[cajbir (:cajbir)]

(In reply to Jonas Sicking (:sicking) from comment #24)
> I'll leave it up to the media team to choose what codecs to support where.
> However do remember that we have the choice of enabling some codecs only to
> privileged apps as to prevent the codec from spreading to the web at large.

I'm fine with AAC support where we have platform decoder support for it. This was also discussed in bug 914408 comment 2 but that bug was closed due to other browsers not supporting it. Given that, privileged apps only seems a good start.

Comment 30

[cajbir (:cajbir)]

(In reply to Mike Kaply (:mkaply) from comment #26)
> And why do people keep ignoring this statement:
> 
> > I guess this is a pure political issue? What is bug 807361?
> 
> Is there some secret cabal?

It's a confidential bug unfortunately so I'm not sure what can be said about it. I'm not sure why it's confidential though since it's basically the same discussion as this one.

Comment 32

[Eagle Cui]

Hello, is there any update/action to move forward to enable AAC for privileged apps?

Thanks,
Eagle

Comment 33

[Leonard]

(In reply to Mike Kaply (:mkaply) from comment #26)
> (In reply to Andreas Gal :gal from comment #25)
> > I am ok with enabling AAC for privileged apps only. We want to avoid
> > proliferation on the Web. For parity with native apps this makes sense for
> > privileged apps.
> 
> It's already proliferated on the web for streaming.
> 
> http://www.shoutcast.com/
> 
> Not supporting it makes sure that you'll never have full Web Radio support
> in the Firefox browser.

I agree with this statement. We need audio/aac in firefox because this seems to be the only way aac could be provided in http audio streams using icecast or shoutcast. So not only privileged apps, but firefox itself.

Comment 34

[Mike Kaply [:mkaply]]

Also, can bug 807361 is now closed. Since it was the same discussion, what was the resolution there?

Comment 35

[Leonard]

It seems that Chrome now supports aac-adts streams. Just another reason firefox shouldn't stay behind:
https://code.google.com/p/chromium/issues/detail?id=275681

Comment 36

[Alissa（leave from Mozilla）]

This issue has been failed verified on nexus5 2.2 and flame 2.2, nexus5 3.0
Reproducing rate: 3/3
step:
Add some aac audio file to device and launch music, aac audio file cannot be loaded.
N5_2.2
Build ID               20150309162503
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/9ae4bcc9b5f2
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150309.195940
Firmware Date          Mon Mar  9 19:59:53 EDT 2015
Bootloader             HHZ12d

Flame 2.2:
Build ID               20150309002506
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/91b7aa6a3243
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150309.040114
Firmware Date          Mon Mar  9 04:01:25 EDT 2015
Bootloader             L1TC000118D0

N5_3.0
Build ID               20150309160227
Gaia Revision          4ef1fa9b2870499fc9c77cac4a15f62e12a3ad2c
Gaia Date              2015-03-09 02:53:49
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/23f1f0369df5
Gecko Version          39.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150309.193257
Firmware Date          Mon Mar  9 19:33:14 EDT 2015
Bootloader             HHZ12d

Comment 37

[Hermes Cheng (inactive after July 27, 2015)]

From previous discussion, I think we don't support acc for now.
So, we don't need to verify this bug now.
Clear N5 tracking keyword.

Please correct me if my understanding is incorrect.

Comment 38

[Ralph Giles (:rillian)]

Can we close this?

Comment 39

[Chris Peterson [:cpeterson]]

Dave, are there any partners still asking for audio/aac-adts? Bug 807361 was WONTFIX'd two years ago. The Media Playback team does not want to support AAC outside of MP4 containers because we're trying to limit the use of AAC.

Comment 40

[Dave Hylands [:dhylands]]

I honestly don't know. I originally coded this because Andreas Gal told me at a work week that it was urgent that I do it (and I had only just started at Mozilla a few months before this).