Hi > On 14 May 2018, at 6:53 pm, Boris Zbarsky <bzbar...@mit.edu> wrote: > > 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: > We’re 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=vp9” 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… We haven’t fully implemented those because as canPlayType is a synchronous API, doing so properly with our asynchronous backend is hard. > > 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. I would invite you to submit such bug and concern you have on the wicg site: 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’ve been raising frequently, that there’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’t set in stone, and I’m 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’s a dedicated circuit (even if for some there’s a limit on how many decoders can be used at the same time). > > 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). 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? JY
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
