RE: WebVR and DRM

Hello All!

As Brandon mentioned, the mechanism to extend support for Video would be through the VR layers.  The particular attributes of these layers are yet to be decided, but would effectively dictate what kind of projections would be supported and how the video would be blended together with the other, WebGL based, layers.

I agree we should support the most common / standard projections natively; however, there could be options to support application specific mappings eventually.

Some approaches for the arbitrary mappings:
- The video layer could be given a WebGL rendered texture containing UV indices and alpha values per-pixel, describing the way the video would be mapped to screen and blended.
- Some geometry could be passed, with UV values interpolated across the vertices.  This could be depth-tested against the other WebGL layers if they also include depth buffers.

Would you be able to share more details about what kind of use cases the DRM video would be used in to help inform the spec discussions?

Cheers,
- Kearwood “Kip” Gilbert

From: Brandon Jones
Sent: July 10, 2017 1:08 PM
To: Florian Bösch; Kieran Farr
Cc: David Singer; Bassbouss, Louay; public-webvr@w3.org; Pham, Stefan
Subject: Re: WebVR and DRM

Jim: when I say limited layouts I'm referring to the format of the source video. Things like Equirectangular 360, side by side stereo, etc. Nothing to do with lens distortion. All it really means is that we'll have to dictate which layouts we can support, which will inevitably end up being a lowest common denominator set. This will prevent your app from taking advantage of whatever experimental packings Facebook or Google come up with unless they become standardized.

On Mon, Jul 10, 2017, 12:29 PM Florian Bösch <pyalot@gmail.com> wrote:
Just for reference of what I'm talking about. Google got hit with a record $1.1b fine for an infarction. That's about 0.1% of their market cap, 1.2% of their annual revenue and 11% of their profit.

Extending the time of violation by the content industry by 500%, the region of impact by 1000% and projecting onto an estimated $300 billion or so revenue, that means fines in the region of $200b or so would not be disproportionate.

On Mon, Jul 10, 2017 at 9:06 PM, Florian Bösch <pyalot@gmail.com> wrote:
Oh and I forgot to add 360° video for instance. Which youtube (and others) implement with WebGL of course. It's never a terribly good idea to put a a byzantine consortium making technical decisions in the way of those who want to create good and innovative things. The inevitable effect is that good and innovative things don't happen. Eventually the law will catch up to the fact that DRM is just used to stifle innovation, erect barriers to entry and exclude the competition. And when it does, all those who signed those contracts will be as much on the hook as the content industry who pushed DRM on everybody in the first place. I would be pretty uneasy if there was a possibility my company could be found liable for an antitrust violation of epic proportions, even if only a tiny fraction of that liability would stick to any one defendant.

On Mon, Jul 10, 2017 at 8:54 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Mon, Jul 10, 2017 at 8:22 PM, Kieran Farr <kieran.farr@gmail.com> wrote:
• The concept of a restricted Video Layer that supports existing web-based video DRM schemes would be a reasonable solution for most legacy publishers looking to get their "feet wet" with VR. I think this is a great idea and would kickstart many WebVR enabled sites -- especially if it can piggyback nicely off of the HTML5 video element's existing "goodness". Those that wish to make use of more advanced WebVR / 3D pipeline features would need to weigh that against their contractual rights for content access.
I think that's pretty useless, for the same reasons that Facebook/Oculus felt it was pretty useless, and a few reasons on top of that.
• No mipmapping (hurts viewing fidelity overall, but also disables ambient light effects)
• No anisotropy (hurts viewing fidelity)
• No syncing of video content and WebVR content
• No audio integration with anything attempting to do spatial audio
• No way to handle subtitles and the like in a VR friendly fashion (at a proper place maybe outside the video frame, with a proper VR oriented text rendering solution)
• No shading/integration with the rendering pipeline. That also means no effects on the video surface used for UI or aesthetic reasons
For anybody unfamiliar with the need to read out textures for rendering, please see this WebGL experiment: http://alteredqualia.com/three/examples/webgl_deferred_arealights_texture.html

Ultimately, if you want good applications, those applications need to be able to work with the data they're supposed to operate with. If you can't, what you get is crap. This is a recurring trend throughout all DRM. It degrades user-experience for legitimate uses, while it does nothing to prevent illegitimate uses. The race to "ultimate DRM" is a race to quality rock bottom.