Make support() synchronous

[joeyparrish]

Based on feedback from @ddorwin and @leandromoreira, we should make support() synchronous.

According to w3c/encrypted-media#178 (comment) and w3c/encrypted-media#178 (comment), we should not be probing EME. Probing EME may result in lots of prompts on some browsers, leading to a bad UX. Since app devs don't really need this info anyway, it's fine to skip probing EME in support().

According to clappr/dash-shaka-playback#4 (comment), having an asynchronous support() call is inconvenient. Since the only asynchronous part of it is the EME probe, we can make things simpler for developers by removing that.

Since EME probes are still useful for platform diagnostics, we should move any EME probes to a separate method. That method should be named in such a way that it is clearly not to be used in production. In contrast, checking basic library support should definitely be done in production.

[TheModMaker]

I disagree about EME probing. I think this is a very real use-case to be able to determine key-system support early. In the demo app, we disable assets that the browser does not support. If we stopped EME probes, we would be unable to do this.

An app would need to wait until it tries to play a manifest before it could determine if the browser supported the key-system. Plus, it would need to listen to Player error events and have special code to check for the error code and do something different. As opposed to currently, where it can detect it before it even creates a Player.

I agree we should split up support() into a synchronous version and an async version. But, I think we should keep EME probes (for production). Maybe we should modify the way we do it. Instead of probing all key systems with empty configs, what about accepting an array of DrmInfo and using that to construct the EME query. This will mirror the query we will do later and allow apps to detect the exact support they want. Plus, the support method will only probe the key-systems that the app needs.

[joeyparrish]

It is very useful for our demo app to screen which assets are playable based on key system. However, I'm not sure this is a common scenario for most app developers.

A real application's content catalog is generally under their complete control, and is not likely to be segmented into pieces by key system. Our demo content is mostly third-party, and the content we encoded ourselves is not currently multi-DRM. So I don't think our demo app is representative of the needs of a typical video-streaming service.

I believe most real applications will be serving all content with the same key systems. For example, a catalog of DASH content may be all Widevine-encrypted, or all Playready-encrypted, or all multi-DRM using a specific set of DRM providers across all content.

[LucasPiffer]

worked like a charm. Did you think about create a gem for Shaka?

[joeyparrish]

What's a gem?

[LucasPiffer]

Rails Gem.

[joeyparrish]

Sorry, rails is not on our roadmap.

[LucasPiffer]

no problem, just curiousity. thanks again sir.