Given mp2t shares codecs with mp4, the simplest way is to map "video/mp2t" to EME_CODEC_MP4_VIDEO_ALL and "audio/mp2t" to EME_CODEC_MP4_AUDIO_ALL, in kMimeTypeToCodecMasks. Any thoughts?

#2 makes sense to me.

No, I think it's a bit more nuanced than that. There are some differences between what's supported in mp2t and mp4. For example we support mp3 audio stream in mp2t containers, but AFAIK only AAC audio is supported in mp4. Also HEVC video is supported in mp4, but not in mp2t (see b/34110854). DV is another video codec supported in mp4, but not in mp2t (although currently it looks like DV is not properly marked as being supported in EME, +erickung@, we probably need to fix this).

Seems like we should split EmeCodec into 'codec' and 'container'?

Checking codec by mime util happens before 'eme codec' check. So the codecs supported by MP4 but not supported by mp2t should be fine.

What's the codec string for mp3?

And seems like the codec that can be encrypted in mp2t is avc1 and aac (EncryptionScheme is Unencrypted). Doug, can you confirm this?

Ah, yes, that's true, the codecs supported in mp4, but not in mp2t should be filtered out by the earlier IsSupportedMediaFormat check.
The mp3 codec ids supported for video/mp2t mime type are mp4a.69 and mp4a.6B (the audio/mp2t mime type is currently not supported).

I think JS will use something like 'video/mp2t; codecs="avc.xxx, mp4a.xxx"' when querying isTypeSupported. But EME doesn't like this mixed style. And is there any app using mp2t to deliver audio stream only?

In MimeUtil, we have made an effort to not support newer codecs with older MIME type strings (and containers). EME should be consistent.

The EME codec specification worked fine when types were simple, but it doesn't work well for code profiles, etc. chcunningham@ may have plans to change it as part of broader efforts.

I dislike the suggestion in #2. I much prefer to give MP2TS its own enum values. I recognize the codecs are somewhat repeated, but this is slight complexity compared to longterm gains in maintenance and readability.

> The EME codec specification worked fine when types were simple, but it doesn't work well for code profiles, etc. chcunningham@ may have plans to change it as part of broader efforts.

This is correct. I plan to introduce a separation of containers and codecs down the road to allow for more granularity in describing support for specific codec profiles. I am not planning to take this on in Q2, but feel free to explore separating codecs/containers if you think it simplifies things. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a26af12f05559a607d50c22d94135b18902167eb

commit a26af12f05559a607d50c22d94135b18902167eb
Author: yucliu <yucliu@chromium.org>
Date: Mon May 22 18:35:25 2017

Add EME contentType checks for mp2t

We don't have 'mp2t/audio' for audio streams. For video streams, stream
parser supports encrypted AVC stream. The patch adds the supporting for
mp2t avc.

BUG=708261
TEST=Test on chromecast and Android.

Review-Url: https://codereview.chromium.org/2881443002
Cr-Commit-Position: refs/heads/master@{#473633}

[modify] https://crrev.com/a26af12f05559a607d50c22d94135b18902167eb/media/base/eme_constants.h
[modify] https://crrev.com/a26af12f05559a607d50c22d94135b18902167eb/media/base/key_systems.cc