However, the EME spec [1] says:
   If the user agent does not recognize one or more parameters, continue to the next iteration.

[1] https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type

Complicating this is there are (at least) 2 implementations that parse MIME types in the blink code. 

network/mime/ContentType.cpp, which is used mostly by media code, has limited functionality, and searches for parameters by simply looking for the name somewhere in the MIME type (so it could get confused if the parameter name was used inside a different parameter, e.g. foo=codecs, codecs="avc1.4d401e"). Since it does not parse the full string, it has no list of parameters included in the MIME type, making detection of unrecognized parameters impossible.

network/ParsedContentType.cpp, which is used elsewhere, parses the full MIME type, so it does have a list of parameter names (although not exposed publicly). However, the parameter search is case-sensitive ( issue 689731 ), which is a problem.

I tried a test where ContentType is simply a wrapper on ParsedContentType, to see if there is any impact. The only tests that fail:
    media/media-source/mediasource-is-type-supported.html
    media/encrypted-media/encrypted-media-requestmediakeysystemaccess.html
Both files include case-insensitive tests (e.g. CODECS=), which explains the reason they fail.

I will also note that ContentType::type() is a trivial implementation (returns the part of the MIME type before ; if it is found, otherwise the whole string), while ParsedContentType::mimeType() has to parse the complete MIME type first. The latter is not used, while the former is used a lot. As there are a significant number of "ContentType(type).type()" calls, there might be a performance hit having to parse |type| every time and/or unexpected failures due to parsing the parameters which aren't needed/checked.

Updating title to reflect that the capability should be skipped if unrecognized parameters are detected, in order to match the EME spec.

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

commit 59882b5e4f6cdfbaa6b818a29de7212eb8abbf4c
Author: jrummell <jrummell@chromium.org>
Date: Tue Mar 07 21:50:15 2017

[eme] Ignore capabilities with unrecognized parameters

The EME spec notes that if "the user agent does not recognize one or more
parameters" in a capability, skip over it. So if additional parameters are
present, the capability should be ignored.

BUG= 487392 , 690131 
TEST=new tests pass

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

[modify] https://crrev.com/59882b5e4f6cdfbaa6b818a29de7212eb8abbf4c/third_party/WebKit/LayoutTests/media/encrypted-media/encrypted-media-requestmediakeysystemaccess.html
[modify] https://crrev.com/59882b5e4f6cdfbaa6b818a29de7212eb8abbf4c/third_party/WebKit/Source/modules/encryptedmedia/NavigatorRequestMediaKeySystemAccess.cpp