I think the fix would have RenderMediaClient grab KeySystem UmaInfo from ContentClient, following the same model it uses to get KeySystemProperties

Or... put the UMA name into the KeySystemProperties and eliminate this special API.

Yuchen, could you take a look?

I don't think this is causing issues today. What we hardcode is a pair of Wideivne key system to Widevine key system UMA name:

  key_systems_info_for_uma->push_back(media::KeySystemInfoForUMA(
      kWidevineKeySystem, kWidevineKeySystemNameForUMA));

We do this for Clear Key as well [1].

Then for a UMA report, we'll actually check the key system and go through the dictionary [2]. If a key system is not registered, it'll be reported as "Unknown".

So if Cast is actually using this for UMA reports, Cast should register PlayReady key system and UMA name in CastMediaClient::AddKeySystemsInfoForUMA().

Again, I feel it's a bit hacky to have CastMediaClient registering itself directly. We should probably look into how to refactor that part.

[1] https://cs.chromium.org/chromium/src/media/base/key_systems.cc?rcl=6a23306766d02a480c7992f91b51e9691d6511b8&l=325

[2] https://cs.chromium.org/chromium/src/media/base/key_systems.cc?rcl=6a23306766d02a480c7992f91b51e9691d6511b8&l=498

> If a key system is not registered, it'll be reported as "Unknown".

Ah I missed this! Downgrading to P2. 

> Cast should register PlayReady key system and UMA name in CastMediaClient::AddKeySystemsInfoForUMA().

I still think its weird to have a separate API for this. Would you be open to just adding the UMA name to KeySystemProperties? This should be simpler and more naturally extensible. I'm happy to do this work. 

> Again, I feel it's a bit hacky to have CastMediaClient registering itself directly. We should probably look into how to refactor that part.

Fixing that here:
https://codereview.chromium.org/2712983004/

Adding the UMA name to KeySystemProperties sgtm, thanks!

One detail to decide on is how to plumb for android. Android key system properties are a generic class that take in the key system name via constructor:

https://cs.chromium.org/chromium/src/components/cdm/renderer/android_key_systems.cc?l=153

We can easily take in the NameForUMA via constructor as well, but my question is where to source it from. As it stands, the name (not for UMA) is coming from the MediaClientAndroid. We can plumb this all the way from that point, or we can decide elsewhere in media/ that anytime we see the PlayReady name we will use a known PlayReadyForUMA name that is defined in media/ (for e.g. eme_constants.h). At this time, all playready usage is via chromecast/ ... thats probably how it will stay, so perhaps its fine to just have the playready UMA name live in chromecast/ and sent over via the IPC in the case of android tv. 

xhwang, any suggestions?

The UMA metrics are a fixed set of values, right? So we can only report key systems that we are aware of (and are recorded in histograms.xml). I don't think we have PlayReady there, and I'm not sure we want to add it as it will pollute the Chrome UMAs. We won't be able to do this for random platform Key Systems, though. I'm not sure that the platforms that support these use UMAs anyway.

Good point about random platform key systems - I no longer think decentralizing this UMA name makes sense. Will instead just centralize it into key_systems.cc

std::string KeySystemsImpl::GetKeySystemNameForUMA(
    const std::string& key_system) const {
  DCHECK(thread_checker_.CalledOnValidThread());

#if defined(WIDEVINE_CDM_AVAILABLE)
  if (key_system == kWidevineKeySystem)
    return kWidevineKeySystemNameForUMA;
#endif  // WIDEVINE_CDM_AVAILABLE

  if (key_system == kClearKeyKeySystem)
    return kClearKeyKeySystemNameForUMA;

  return kUnknownKeySystemNameForUMA;
}


Cast does use UMAs and I think Playready had enough usage now to get its own name. I won't tackle that right away. 

FYI: cast has a bug where EME UMAs are not currently reported.
b/36181497