Contact emails
chcunn...@chromium.org, mlam...@chromium.org, hben...@chromium.org
Spec
https://wicg.github.io/media-capabilities/
Summary
New encryption configuration inputs have been added to the decodingInfo() API. The trial will expose these, so sites using encrypted media (EME) can make optimal decisions when selecting media streams.
We previously shipped mediaCapabilities.decodingInfo() for unencrypted media.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/bBUZGuJ4VfY/yBfMs4d0DAAJ
Link to Chrome launch bug (Origin trial is approved)
Goals for experimentation
Validate that the API provides sufficient and reliable enough information for encrypted video serving sites using it to deliver an improved user experience (example signals: fewer dropped frames, higher watch time). This will be measured by video sites that join the origin trial and choose to share their internally measured results and feedback.
Experimental timeline
These features are available beginning in M75. Origin trial can begin with the approval of this I2E. Hopefully July 2019.
We'd like to run the trial for 4 months. Assuming start in July 2019, we can conclude in October with the stable release of M78.
Any risks when the experiment finishes?
No significant risks - content providers can fall back to their current behavior in case we need to disable the origin trial.
Ongoing technical constraints
None
Debuggability
The main failure path is when providing invalid input. The API will emit helpful console messages when this occurs.
Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
Yes
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5765900795904000Not sure whether the idea could be used to avoid unnecessary format conversion for media streaming (Hangouts/Duo)
Best Regards
Yongnian
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6eSqF-wO9AK%3DozUOQHoMPaQmHBw9ShFhK1sVTf1KO5VEYkw%40mail.gmail.com.
Wouldn't that require to know the configurations that the peers support too? I thought WebRTC was looking into APIs to handle this.On Mon, 1 Jul 2019 at 02:29, Le, Yongnian <yongn...@intel.com> wrote:Not sure whether the idea could be used to avoid unnecessary format conversion for media streaming (Hangouts/Duo)
Best Regards
Yongnian
From: Chris Cunningham [mailto:chcunn...@chromium.org]
Sent: Thursday, June 27, 2019 3:17 AM
To: blink-dev <blin...@chromium.org>
Cc: Mounir Lamouri <mlam...@chromium.org>; Husain Bengali <hben...@chromium.org>
Subject: [blink-dev] Intent to Experiment: MediaCapabilities: encrypted (EME) decodingInfo()
Summary
New encryption configuration inputs have been added to the decodingInfo() API. The trial will expose these, so sites using encrypted media (EME) can make optimal decisions when selecting media streams.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH8vw6DeqoXRDemifsUrWkZ8orGaiZ3ks%2B-H%2B7tHmn47QA%40mail.gmail.com.
From the I2I, this is the relevant part of the explainer, right? I.e. concretely this is about the presence of 'keySystemInformation' in MediaDecodingConfiguration? Or are there other API changes as well?
What can you share about which specific sites have expressed a desire for this API?