ADTS raw AAC format not supported in Music app

RESOLVED DUPLICATE of bug 807361

Status

()

RESOLVED DUPLICATE of bug 807361
6 years ago
3 years ago

People

(Reporter: dhylands, Unassigned)

Tracking

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

Firefox Tracking Flags

(blocking-basecamp:-, b2g-v2.2 affected)

Details

(Whiteboard: [dependency: marketplace-partners])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Nom'd blocking-basecamp because 807361 is blocking-basecamp
(Reporter)

Updated

6 years ago
Component: General → Video/Audio
Product: Boot2Gecko → Core
(Reporter)

Comment 1

6 years ago
Created attachment 678864 [details] [diff] [review]
Recognize .aac extension as mimetype audio/aac-adts
(Reporter)

Comment 2

6 years ago
Created attachment 679258 [details] [diff] [review]
v2 - Recognize .aac extension as mimetype audio/aac-adts
Attachment #678864 - Attachment is obsolete: true
Attachment #679258 - Flags: review?(chris.double)

Updated

6 years ago
Attachment #679258 - Flags: review?(chris.double) → review+
(Reporter)

Comment 4

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

6 years ago
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.
blocking-basecamp: ? → -
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

6 years ago
(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.
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

6 years ago
The most common container format is mp4, so I agree this should be minus'ed for v1.
(Reporter)

Updated

6 years ago
Assignee: dhylands → nobody
Duplicate of this bug: 913236
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?
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.
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

5 years ago
(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.
Do other browser's on mobile and desktop support ADTS?

Comment 16

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

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

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

5 years ago
(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.
(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?
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

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

5 years ago
What browser ships with AAC enabled for content?
> 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

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

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

Updated

5 years ago
Blocks: 949077
Duplicate of this bug: 952398

Updated

5 years ago
Blocks: 956203

Comment 32

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

Thanks,
Eagle

Comment 33

4 years ago
(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.
Also, can bug 807361 is now closed. Since it was the same discussion, what was the resolution there?

Comment 35

4 years ago
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
Whiteboard: [dependency: marketplace-partners]
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
status-b2g-v2.2: --- → affected
Whiteboard: [dependency: marketplace-partners] → [dependency: marketplace-partners],[v2.2-nexus-5-l]
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.
Whiteboard: [dependency: marketplace-partners],[v2.2-nexus-5-l] → [dependency: marketplace-partners]
Depends on: 1169212
Component: Audio/Video → Audio/Video: Playback
Can we close this?
Flags: needinfo?(dhylands)
Priority: P1 → P2
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.
Priority: P2 → --
(Reporter)

Comment 40

3 years ago
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).
Flags: needinfo?(dhylands)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 807361
You need to log in before you can comment on or make changes to this bug.