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