Add 'audio/aac' mimetype support

Add 'audio/aac' mimetype support

In old implementation, 'audio/aac' is not supported when using
IsSupportedMediaMimeType to check. That will block aac audio to play.

BUG=394681
Committed: https://crrev.com/7f7ef67cfe4ba1198a82db04ff8ca52ad416e627
Cr-Commit-Position: refs/heads/master@{#314952}

[jiajia.qin, 2015-02-05 06:35:08]

jiajia.qin@intel.com changed reviewers:
+ asanka@chromium.org

[jiajia.qin, 2015-02-05 06:35:09]

Hi, asanka
  I find 'audio/aac' is not in proprietary_media_types list which will result
this kind of audio can't be played. But it seems that if we add this type into
proprietary_media_types list. The playback works well. Forgive my ignorance, is
there special reason we can't support this type?

[asanka, 2015-02-05 16:09:10]

asanka@chromium.org changed reviewers:
+ scherkus@chromium.org

[asanka, 2015-02-05 16:13:15]

On 2015/02/05 at 06:35:09, jiajia.qin wrote:
> Hi, asanka
>   I find 'audio/aac' is not in proprietary_media_types list which will result
this kind of audio can't be played. But it seems that if we add this type into
proprietary_media_types list. The playback works well. Forgive my ignorance, is
there special reason we can't support this type?

+scherkus for media/OWNERS which I think is where the media related capabilities
are slated to be moved. This isn't a //net decision.

jiajia.qin: Please open a bug for this and add the appropriate labels
(Cr-Internals-Media-Audio ?) so that the correct folks can provide feedback.
It's best if the issue of whether this should be added or not is hashed out on
the issue tracker. Once a decision is made, I can then rubberstamp the CL.

[scherkus (not reviewing), 2015-02-05 21:02:47]

scherkus@chromium.org changed reviewers:
+ dalecurtis@chromium.org
- scherkus@chromium.org

[scherkus (not reviewing), 2015-02-05 21:02:54]

scherkus@chromium.org changed reviewers:
+ scherkus@chromium.org

[scherkus (not reviewing), 2015-02-05 21:02:55]

-> dalecurtis@

[DaleCurtis, 2015-02-05 21:07:50]

lgtm per
http://www.w3.org/2013/12/byte-stream-format-registry/mpeg-audio-byte-stream-...

[asanka, 2015-02-05 21:13:41]

lgtm

[jiajia.qin, 2015-02-06 01:55:57]

The CQ bit was checked by jiajia.qin@intel.com

[commit-bot: I haz the power, 2015-02-06 01:57:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/895523002/1

[commit-bot: I haz the power, 2015-02-06 03:33:29]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-06 03:35:34]

Patchset 1 (id:??) landed as
https://crrev.com/7f7ef67cfe4ba1198a82db04ff8ca52ad416e627
Cr-Commit-Position: refs/heads/master@{#314952}

[ddorwin, 2015-03-26 01:57:59]

It does not appear a BUG was opened (asanka's first comment). It's not clear
which use cases this fixes. Please file a bug explaining the scenario you were
trying to fix and note that we need more tests. For example, I think this means
we support "audio/aac" in canPlayType() and <source>, but a) we don't have tests
and b) I'm not sure if that is intended. Also, it's unclear if we expect/allow
codecs to be specified with this container type.

https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc
File net/base/mime_util.cc (right):

https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc#newcod...
net/base/mime_util.cc:362: "audio/aac",
This is not MP3.

[jiajia.qin, 2015-03-26 07:22:30]

On 2015/03/26 01:57:59, ddorwin wrote:
> It does not appear a BUG was opened (asanka's first comment). It's not clear
> which use cases this fixes. Please file a bug explaining the scenario you were
> trying to fix and note that we need more tests. For example, I think this
means
> we support "audio/aac" in canPlayType() and <source>, but a) we don't have
tests
> and b) I'm not sure if that is intended. Also, it's unclear if we expect/allow
> codecs to be specified with this container type.

I searched the current bugs. I think issue 394681 is related with this CL. 

> https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc
> File net/base/mime_util.cc (right):
> 
>
https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc#newcod...
> net/base/mime_util.cc:362: "audio/aac",
> This is not MP3.

OK. I just want to put audio/mpeg and audio/aac together. You can send another
CL
to correct it:)

[asanka, 2015-03-26 17:50:21]

ddorwin, dalecurtis and others: If there was insufficient discussion about this
and there are unresolved issues, then I believe it's best that we revert this
change until such time that we feel confident in its inclusion. FWIW, my review
was a rubberstamp of dalecurtis' since I believe the media folks should claim
ownership of the media related code. There are efforts on the way to move this
bit of code elsewhere so that this ownership is reflected in our OWNERS files.

On 2015/03/26 07:22:30, jiajia.qin wrote:
> On 2015/03/26 01:57:59, ddorwin wrote:
> > It does not appear a BUG was opened (asanka's first comment). It's not clear
> > which use cases this fixes. Please file a bug explaining the scenario you
were
> > trying to fix and note that we need more tests. For example, I think this
> means
> > we support "audio/aac" in canPlayType() and <source>, but a) we don't have
> tests
> > and b) I'm not sure if that is intended. Also, it's unclear if we
expect/allow
> > codecs to be specified with this container type.
> 
> I searched the current bugs. I think issue 394681 is related with this CL. 
> 
> > https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc
> > File net/base/mime_util.cc (right):
> > 
> >
>
https://codereview.chromium.org/895523002/diff/1/net/base/mime_util.cc#newcod...
> > net/base/mime_util.cc:362: "audio/aac",
> > This is not MP3.
> 
> OK. I just want to put audio/mpeg and audio/aac together. You can send another
> CL
> to correct it:)

[DaleCurtis, 2015-03-26 17:59:12]

I think this is fine to leave in. There are no codecs which should be specified
with this mime type since it's always aac. It'd be nice to add some
canPlayType() tests though.