Intent to ship: media-capabilities

--Apple-Mail=_6A25E61D-5BDF-4DC3-AD42-7C6C2B58C2E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Media Capabilities allow for web sites to better determine what content =
to serve to the end user.
Currently a media element offers the canPlayType method =
(https://html.spec.whatwg.org/multipage/media.html#dom-navigator-canplayty=
pe-dev =
<https://html.spec.whatwg.org/multipage/media.html#dom-navigator-canplayty=
pe-dev>) to determine if a container/codec can be used. But the answer =
is limited as a maybe/probably type answer.

It gives no ability to determine if a particular resolution can be =
played well/smoothly enough or be done in a power efficient manner (e.g. =
will it be hardware accelerated).

This has been a particular problem with sites such as YouTube that =
serves VP9 under all circumstances even if the user agent won't play it =
well (VP9 is mostly done via software decoding and is CPU itensive). =
This has forced us to indiscriminately disable VP9 altogether).
For YouTube to know that VP9 could be used for low resolution but not =
high-def ones would allow them to select the right codec from the start.

This issue is tracked in bugzilla 1409664  =
(https://bugzilla.mozilla.org/show_bug.cgi?id=3D1409664 =
<https://bugzilla.mozilla.org/show_bug.cgi?id=3D1409664>)

The proposed spec is available at =
https://wicg.github.io/media-capabilities/ =
<https://wicg.github.io/media-capabilities/>

Chrome has shipped it a while ago now and talking to several partners =
(including YouTube, Netflix, Facebook etc) , Media Capabilities support =
has been the number one request.

We intend to implement and ship this API very soon.

Early comment and feedback will be welcome.

Kinds regards
Jean-Yves=

--Apple-Mail=_6A25E61D-5BDF-4DC3-AD42-7C6C2B58C2E6
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJDCCBTYw
ggQeoAMCAQICEQCBSieaFmHJtubZY/a2JhCmMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCYxJDAiBgkqhkiG9w0BCQEWFWp5YXZlbmFyZEBtb3ppbGxhLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOt9s5pE1IsPSfvpowRfZN3jD+6Ki/wevXHp0PYL9Ko6dnZZDVbKolbV
Mc87X6KGNtGDBM2O0ojc9bQmohoEX+dBJevnxnTWBmGUqBN7g6lQIxqAlp2osCZy2GaqliowkBFq
ZUiBmzLQ3yf5tcoletYceH4NyRaBGgcCl1IP7VFITsAMplt65BsY1lSZdgQqegi6DB6NywfikLc6
+0K0z3uzmCnKTKpnoXtrAVebqcBwRLPWWf8bXkGsRmdBg5YrL/FOG6WHkVTCf1yfDpJ8woaZeBRN
a3mOJ7eQG2VQgrnBQxndVdxnGY+r9MUf2ssP1V+Ji0/CO8wtBN2SAwgAWTUCAwEAAaOCAeswggHn
MB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTkrzUBvD5lKF4LO+Ha
fJfJE0wcvTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcD
BAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC
AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT
MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJ
aHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRT
ZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAG
A1UdEQQZMBeBFWp5YXZlbmFyZEBtb3ppbGxhLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAJxnChKvx
dNNwyycLtwgfvLUwVsI2Nwtn1N4ZnHrD/TKbct+oc/AfvVhC0ixptvzGD+2v+peCbCCoyXUtltBi
IND7tZqC+RJqwqz0yvKF2aaeig/hLza6vDEDbflMM4IeOeCCBT4LYgxSREG2eKIJUiyrfNdidqPT
OMcigZCS7leZuTDEb19UGtggvMDHQzHhEVmFuFixUEXkNxDmbsaBwBaWB274Sw52IQmw04dOoo9i
D1TmpXr/HOgx5B4uorKZwhKHRT0s7l2A6Nx/XeD5z9nynTDCJ+7xCTNGCjRiD9SLv4DgzAjGiDwL
CkHn0JhCwLui51mII3bUNTw65TZf4TCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJ
KoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJD
T01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEw
OTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P
RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6c
pzEup/Y0dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDI
MypVpVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK
jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lB
oNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB
o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4
xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1Ud
IAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D
T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYB
BQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhc
soEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hK
ZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsj
k/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXij
nRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q
332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiG
GaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2
aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/G
qK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+8
5hFQzVxZx5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYID
ujCCA7YCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAgUon
mhZhybbm2WP2tiYQpjAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xODA1MTQxNTE5NTdaMCMGCSqGSIb3DQEJBDEWBBQKWjfs5d3cq3j0mzUG
IwfTy+cNbDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt
aXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIRAIFKJ5oWYcm25tlj9rYmEKYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIFKJ5oWYcm25tlj9rYmEKYwDQYJ
KoZIhvcNAQEBBQAEggEAoB993HW3wyDyZHQ1HfrVnI2iqfdZOeN0ZjmQr6y/0zYTR+2MyvrOL+GP
aB2Vv3mVHnh5pDUmeb3fIu/SPbEmdW1cHLfGq0tSssQ68EFqnEQD1ZZYCU30H2B5NLGi02twtQaj
dqb5iq9vRzVn/3se9KoGQ8kPPH/KSZ5sggImLGnZoRiWhCyOnCeDBtcoqv8ZF7XghjJN2LLRXRD5
dIjDvQ7CDYsTWfD12N1evwY/V3vOFNx7JD4+E1hn9CGk/mE6U2OlJhVKmdRxPuxgqJRrmz4l9b1T
SARu/d4RGMr4SL6wrBvN2LTQv+dQvAnxoa0qImD8UvGLPFV7wK9asUM1qAAAAAAAAA==
--Apple-Mail=_6A25E61D-5BDF-4DC3-AD42-7C6C2B58C2E6--
0
Jean
5/14/2018 3:19:56 PM
mozilla.dev.platform 6344 articles. 0 followers. Post Follow

3 Replies
10 Views

Similar Articles

[PageSpeed] 5

On 5/14/18 11:19 AM, Jean-Yves Avenard wrote:
> The proposed spec is available at https://wicg.github.io/media-capabilities/ <https://wicg.github.io/media-capabilities/>

I have some questions about this spec and our implementation:

1)  What are the fingerprinting implications?  What effect, if any, do 
our "resist fingerprinting" preferences have on our API implementation 
here?  The spec tries to address this but as usualy mostly handwaves 
around it.

2) It looks to me that given a MediaCapabilitiesInfo there is no way to 
figure out what configuration it represents.  Should there be such a 
way?  It seems like it would make it simpler to deal with asking for the 
capabilities for several configurations at once and then examining the 
results if you don't have to keep track of which returned promise 
corresponds to which passed-in configuration.  Doubly so if you 
Promise.race things (though why one would do that in this case is not so 
clear to me).

Note that even the example in section 5.1 of the spec gets this wrong: 
it uses result.contentType, but "result" is a MediaCapabilitiesInfo and 
doesn't have a .contentType property.

3) The booleans in MediaCapabilitiesInfo (apart from "supported") seem 
rather vaguely defined.  As a concrete example, if I am on 4-core (+ 
hyperthreading) "desktop"-level system with nothing running except the 
video, "smooth" should clearly be set to true.  Should it still be set 
to true on the same hardware but in a situation where I am heavily 
swapping and my load average is 150?  This is a bit of a caricature, but 
it seems to me that if people are going to treat this as a _reliable_ 
signal then it needs to be more clearly spelled out what things it does 
or does not take into account.

4) For the "change" event on Screen, does that apply to any property 
defined in any specification, not just the properties defined in this 
specification?  That would be a pretty significant monkeypatch in its 
own right.  It would be better if whatever specifications define 
properties also define what events fire if those properties change.

-Boris
0
Boris
5/14/2018 4:53:34 PM
--Apple-Mail=_2C174BBC-0B22-4489-9880-5D68045185A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi

> On 14 May 2018, at 6:53 pm, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>=20
> On 5/14/18 11:19 AM, Jean-Yves Avenard wrote:
>> The proposed spec is available at =
https://wicg.github.io/media-capabilities/ =
<https://wicg.github.io/media-capabilities/>
>=20
> I have some questions about this spec and our implementation:
>=20
We=E2=80=99re at an early stage in the implementation, and assuming the =
concerns of some, I wanted to present it early on.

> 1)  What are the fingerprinting implications?  What effect, if any, do =
our "resist fingerprinting" preferences have on our API implementation =
here?  The spec tries to address this but as usualy mostly handwaves =
around it.

The most obvious choice considered was to provide identical information =
to what the existing canPlayType information provide: that is not =
providing extra details.
so if canPlayType reports that "video/webm; codecs=3Dvp9=E2=80=9D is =
supported, then so will MediaCapabilities, but providing no difference =
then according to the resolution or the bitrate specified.
It is currently possible with canPlayType to query much deeper level of =
information, in particular bitrate, colorspace, HDR support, codec level =
etc=E2=80=A6 We haven=E2=80=99t fully implemented those because as =
canPlayType is a synchronous API, doing so properly with our =
asynchronous backend is hard.

>=20
> 2) It looks to me that given a MediaCapabilitiesInfo there is no way =
to figure out what configuration it represents.  Should there be such a =
way?  It seems like it would make it simpler to deal with asking for the =
capabilities for several configurations at once and then examining the =
results if you don't have to keep track of which returned promise =
corresponds to which passed-in configuration.  Doubly so if you =
Promise.race things (though why one would do that in this case is not so =
clear to me).
>=20
> Note that even the example in section 5.1 of the spec gets this wrong: =
it uses result.contentType, but "result" is a MediaCapabilitiesInfo and =
doesn't have a .contentType property.

I would invite you to submit such bug and concern you have on the wicg =
site:=20
https://github.com/wicg/media-capabilities/issues

Or I can do so if you prefer.


> 3) The booleans in MediaCapabilitiesInfo (apart from "supported") seem =
rather vaguely defined.  As a concrete example, if I am on 4-core (+ =
hyperthreading) "desktop"-level system with nothing running except the =
video, "smooth" should clearly be set to true.  Should it still be set =
to true on the same hardware but in a situation where I am heavily =
swapping and my load average is 150?  This is a bit of a caricature, but =
it seems to me that if people are going to treat this as a _reliable_ =
signal then it needs to be more clearly spelled out what things it does =
or does not take into account.

this is an issue I=E2=80=99ve been raising frequently, that there=E2=80=99=
s no way to determine if the capabilities change over time: receiving a =
notification when such temporary workload occurs would be of benefit.
The spec isn=E2=80=99t set in stone, and I=E2=80=99m hoping that a new =
event could be dispatched on the media element to indicate that the =
capabilities have changed.

Having said that, with hardware decoders, typically whatever you may be =
doing has no impact on performance: it=E2=80=99s a dedicated circuit =
(even if for some there=E2=80=99s a limit on how many decoders can be =
used at the same time).

>=20
> 4) For the "change" event on Screen, does that apply to any property =
defined in any specification, not just the properties defined in this =
specification?  That would be a pretty significant monkeypatch in its =
own right.  It would be better if whatever specifications define =
properties also define what events fire if those properties change.
>=20

I=E2=80=99m not sure I understand your question. onChange and the change =
event is only defined for the Screen interface =
(https://drafts.csswg.org/cssom-view/#the-screen-interface).
Or you=E2=80=99re suggesting that as the MediaCapabilities Screen =
extension is only about gamut and luminance, each should get its own =
event so that future extension to the Screen interface do no conflict?

JY=

--Apple-Mail=_2C174BBC-0B22-4489-9880-5D68045185A0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJDCCBTYw
ggQeoAMCAQICEQCBSieaFmHJtubZY/a2JhCmMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCYxJDAiBgkqhkiG9w0BCQEWFWp5YXZlbmFyZEBtb3ppbGxhLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOt9s5pE1IsPSfvpowRfZN3jD+6Ki/wevXHp0PYL9Ko6dnZZDVbKolbV
Mc87X6KGNtGDBM2O0ojc9bQmohoEX+dBJevnxnTWBmGUqBN7g6lQIxqAlp2osCZy2GaqliowkBFq
ZUiBmzLQ3yf5tcoletYceH4NyRaBGgcCl1IP7VFITsAMplt65BsY1lSZdgQqegi6DB6NywfikLc6
+0K0z3uzmCnKTKpnoXtrAVebqcBwRLPWWf8bXkGsRmdBg5YrL/FOG6WHkVTCf1yfDpJ8woaZeBRN
a3mOJ7eQG2VQgrnBQxndVdxnGY+r9MUf2ssP1V+Ji0/CO8wtBN2SAwgAWTUCAwEAAaOCAeswggHn
MB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTkrzUBvD5lKF4LO+Ha
fJfJE0wcvTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcD
BAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC
AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT
MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRp
Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJ
aHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRT
ZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAG
A1UdEQQZMBeBFWp5YXZlbmFyZEBtb3ppbGxhLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAJxnChKvx
dNNwyycLtwgfvLUwVsI2Nwtn1N4ZnHrD/TKbct+oc/AfvVhC0ixptvzGD+2v+peCbCCoyXUtltBi
IND7tZqC+RJqwqz0yvKF2aaeig/hLza6vDEDbflMM4IeOeCCBT4LYgxSREG2eKIJUiyrfNdidqPT
OMcigZCS7leZuTDEb19UGtggvMDHQzHhEVmFuFixUEXkNxDmbsaBwBaWB274Sw52IQmw04dOoo9i
D1TmpXr/HOgx5B4uorKZwhKHRT0s7l2A6Nx/XeD5z9nynTDCJ+7xCTNGCjRiD9SLv4DgzAjGiDwL
CkHn0JhCwLui51mII3bUNTw65TZf4TCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJ
KoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJD
T01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEw
OTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P
RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6c
pzEup/Y0dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDI
MypVpVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK
jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lB
oNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB
o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4
xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1Ud
IAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D
T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYB
BQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhc
soEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hK
ZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsj
k/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXij
nRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q
332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiG
GaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2
aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/G
qK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+8
5hFQzVxZx5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYID
ujCCA7YCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRD
T01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAgUon
mhZhybbm2WP2tiYQpjAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xODA1MTQxOTE4MTRaMCMGCSqGSIb3DQEJBDEWBBR6waOCZCyCrsga2ZWg
KinDykNWqjCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt
aXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIRAIFKJ5oWYcm25tlj9rYmEKYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIFKJ5oWYcm25tlj9rYmEKYwDQYJ
KoZIhvcNAQEBBQAEggEA4pw822VaIK80LwFCATB+Z+PnAHQeAvvYOShdYeKC1lIV87J3B5g8Tczf
92kjVVWH66nMkHt2KwGNT0Qk0AppriNj2BnR9UcVDe1UMtP23g0rm7zVlqt4X7195y+Yl6UDXyEN
v/cvHFRnv1LIgvdEPndx2QqtDn/oBcUzxbk0uFZfTwsknVDBZwetP2/nKIKfuLb1UWNzwAlhGKt5
LduOXDsoSoitavSx31EudkQLIeVSS4aqOxefzSMYyMhvfkL0h8I9LN78KO/ilmGHsND6LnBaGxP6
u06zHZacajvUpNCkV82B8FZ8djLN9dmIfVdZv7HkOQuy4G+ZYMc61/EvXwAAAAAAAA==
--Apple-Mail=_2C174BBC-0B22-4489-9880-5D68045185A0--
0
Jean
5/14/2018 7:18:13 PM
On 5/14/18 3:18 PM, Jean-Yves Avenard wrote:
> The most obvious choice considered was to provide identical information to what the existing canPlayType information provide: that is not providing extra details.

OK.  All I'm saying is that this needs to be sorted out before we ship.

> I would invite you to submit such bug and concern you have on the wicg site:
> https://github.com/wicg/media-capabilities/issues

I can do that, sure.  Figured I'd check whether these issues had been 
considered yet first.  Filed 
https://github.com/WICG/media-capabilities/issues/82

> Having said that, with hardware decoders, typically whatever you may be doing has no impact on performance: it’s a dedicated circuit (even if for some there’s a limit on how many decoders can be used at the same time).

Sure; the question is what happens when the decoders are not hardware.

>> 4) For the "change" event on Screen, does that apply to any property defined in any specification, not just the properties defined in this specification?  That would be a pretty significant monkeypatch in its own right.  It would be better if whatever specifications define properties also define what events fire if those properties change.
>>
> 
> I’m not sure I understand your question. onChange and the change event is only defined for the Screen interface (https://drafts.csswg.org/cssom-view/#the-screen-interface).

Yes...  For which properties of that interface?  For example, should it 
fire for changes to availWidth?  Changes to pixelDepth?

> Or you’re suggesting that as the MediaCapabilities Screen extension is only about gamut and luminance, each should get its own event so that future extension to the Screen interface do no conflict?

I don't have a strong opinion on that, though having a single "change" 
event mean "yeah, one of these N things changed" is not that great; then 
you have to re-poll all those N things to figure out which one changed. 
But my real objection is that the MediaCapabilities spec is currently 
saying that changes to _any_ property on Screen, defined by _any_ 
specification, necessitate a change event to be fired.  That is a pretty 
severe constraint on what other specifications can expose on Screen, no? 
  In particular exposing anything that the OS doesn't notify on changes 
for and is somewhat expensive (whatever that means) to query the OS for 
would suddenly become a non-starter.

-Boris
0
Boris
5/14/2018 10:25:52 PM
Reply: