Re: WebVR and DRM

On Jul 12, 2017 12:24, "Florian Bösch" <pyalot@gmail.com> wrote:

On Wed, Jul 12, 2017 at 8:54 PM, Klaus Weidner <klausw@google.com> wrote:

> Florian: Please see
>  EXT_protected_textures.txt
> <https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_protected_textures.txt>
>


https://www.khronos.org/registry/OpenGL/extensions/
EXT/EXT_protected_textures.txt

This extension enables allocating standard GL textures as protected
> surfaces. Previously these textures would have had to have been created as
> special EGL surfaces. This allows use-cases such as depth, stencil, or
> mipmapped textures to be supported as destinations for rendering within a
> protected context.


and EGL_EXT_protected_content.txt
> <https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_protected_content.txt>


https://www.khronos.org/registry/EGL/extensions/EXT/
EGL_EXT_protected_content.txt

This extension introduces the concept of protected contexts and protected
> resources, specifically surfaces and EGLImages. Applications can choose at
> creation time whether a context, surface or EGLImage is protected or not.


They both concern what happens inside a protected context. They do not
concern what happens at the interaction of a protected context with an
unprotected context.


the extensions allow creating and using textures and images that are
> writable but not readable,
>
That is incorrect. These extensions define no interaction with unprotected
contexts, they only address what happens inside a protected context.


More specifically, you'd use a protected context to do final composition of
the image, i.e. combining the video texture with other 3D content that was
drawn separately in an unprotected context. The details are implementation
dependent. Usually the protected context supports some GL features such as
fragment shaders that can do texture sampling and color computations, but
is likely to lack features that would be needed to use it for arbitrary GL
drawing.

Compositing could for example be based on using the alpha channel of the
WebGL frame to decide where the video content that was placed separately in
3D space should be visible, or on indirect UV texture lookup or similar.



> So the application should be able to create an arbitrary surface that
> displays the content, and integrate it with the 3D scene in some ways. For
> example, doing occlusion via masking would be possible (i.e. allowing
> avatars to move around in front of the screen), and I think also
> postprocessing such as color changes,
>
This is incorrect. "Displaying" or "Color Change" or "masking" etc.
requires a texture lookup. If a texture lookup would work (it does not)
then...


> but doing general room illumination based on screen content would
> generally not work since you can't read the image in an arbitrary shader.
>
This also does not work as you correctly mention. The bottom line is that
you have no access to the texture whatsoever.


The protected context does have access. However, that is likely to be a
separate context from that used for WebVR drawing from JS.


The example you gave earlier of encoding metadata in pixels would not work
> as-is, but something similar should be possible by using multiple distinct
> tracks. For example, I think it is already supported to use a subtitle
> track alongside a protected video with synced timing.
>

To my knowledge no video format exists that allows to provide arbitrary
data to the user of the video stream at the frame frequency. Furthermore
since you don't get access to the texture, it is not you who displays it.
That means you have no fixed sync to the video frame, so any data you would
get, is likely as not a few frames off, and that's an extremely noticable
gap in synchronization (things would appear to "swim").



> There's no inherent hardware side restrictions as far as projections / 3D
> tracking etc are concerned.
>
Then how do you program them?


> The limitations mentioned earlier in the thread would generally be on the
> browser software/implementation side assuming that it just supports
> specific layer setups from an API point of view, but that would be
> modifiable without hardware changes.
>
Then where do you change what to make it happen?


That would be a change to the (as yet hypothetical) protected compositing
context implementation in the browser.



> Please keep in mind that all this would be intended as an additional and
> optional way to do a video layer. It should still be possible to do
> whatever you like with your own videos in plain WebGL.
>
That is not the point. The point is we'd like to avoid people opting for
inferior UX/aesthetics for the pure desire to support DRM'ed content. The
first concern of VR has been, and still is, and will continue to be,
quality. It has been the intent focus of Facebook/Oculus, and it should be
the focus of everyone who does VR. By offering a choice between
quality/innovation/aesthetics vs. DRM, you're setting up users to have a
subpar experience.

For instance, I'll paraphrase a potential future user of an oculus Netflix
clone for the web:

Hey this web player doesn't look as nice as the Facebook VR player. I
> suppose WebVR is just shit.


^ we don't want that.

If the direct video layer support doesn't do what you want you're free to
> completely ignore it. It's supposed to be a convenience to support simple
> use cases more easily (and possibly with improved efficiency if the browser
> can make assumptions about how the images get used), and the EME/DRM
> features are for use cases where content owners would not otherwise be
> willing to use web technology at all for providing their content.
>

I think at this point in VR, and particularly WebVR, it is better not to
offer subpar experiences if it can at all be avoided (it can be avoided).


> I assume that implementers will generally be open to reasonable
> suggestions how this could work better.
>

It works better without DRM, duh.

Personally I'd love it if it would be possible to build something like a
> shared video player that lets people watch a third-party-supplied movie
> together with custom interactions on top of it. I think this would
> potentially be technically possible via an EME-enabled video layer, though
> I expect that doing so in practice would be difficult to do in a way that
> satisfies all the stakeholders.
>

It's usually impossible for innovators to gain access to the content
catalog. It requires an up-front investment of at least $200'000 to go
trough the ratification process of your display technology (to ensure
everything is properly obfuscated). You then have to prove catalog
ingestion which is quite tricky as every one of the 4-5 sources uses a
completely different catalog delivery semantics. Of course you'll also have
to work out how to pay license fees for the content you'll want to display
(and usually the small players get the worst deals on that). All in all
it's very lovely indeed.