Intent to Experiment: MediaCapabilities: encrypted (EME) decodingInfo()

瀏覽次數:134 次
跳到第一則未讀訊息

Chris Cunningham

未讀,
2019年6月26日 下午3:17:462019/6/26
收件者:blink-dev、Mounir Lamouri、Husain Bengali

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)

http://crbug.com/961885


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/5765900795904000

Le, Yongnian

未讀,
2019年7月1日 凌晨2:29:562019/7/1
收件者:Chris Cunningham、blink-dev、Mounir Lamouri、Husain Bengali

Not 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.

Mounir Lamouri

未讀,
2019年7月1日 上午11:50:202019/7/1
收件者:Le, Yongnian、Chris Cunningham、blink-dev、Husain Bengali
Wouldn't that require to know the configurations that the peers support too? I thought WebRTC was looking into APIs to handle this.

Rick Byers

未讀,
2019年7月3日 下午3:31:052019/7/3
收件者:Mounir Lamouri、Le, Yongnian、Chris Cunningham、blink-dev、Husain Bengali
On Mon, Jul 1, 2019 at 11:50 AM 'Mounir Lamouri' via blink-dev <blin...@chromium.org> wrote:
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()

 


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?

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.


What can you share about which specific sites have expressed a desire for this API? 

Chris Cunningham

未讀,
2019年7月3日 下午3:43:462019/7/3
收件者:Rick Byers、Mounir Lamouri、Le, Yongnian、blink-dev、Husain Bengali
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?

Can confirm, that is the relevant part of the explainer. The concrete change is the additional input you mentioned + an additional output of MediaKeySystemAccess (inside the MediaDecodingInfo object) whenever the EME configuration is supported.
 
What can you share about which specific sites have expressed a desire for this API? 

Netflix has expressed a desire. Also, YouTube is already using the non-EME parts of the API - we expect they'll be interested to use these new inputs for their pay-for content. I will reach out to similar sites when OT enrollment opens up.

Rick Byers

未讀,
2019年7月3日 下午4:09:392019/7/3
收件者:Chris Cunningham、Mounir Lamouri、Le, Yongnian、blink-dev、Husain Bengali
Thanks! LGTM
回覆所有人
回覆作者
轉寄
0 則新訊息