W3C home > Mailing lists > Public > public-html-media@w3.org > January 2014

Re: EME: Rendering behavior undefined

From: Hans Schmucker <hansschmucker@gmail.com>
Date: Mon, 13 Jan 2014 12:32:55 +0100
Message-ID: <CAMtPrS94twPNigKMw9i7=eJL9=C_dvY_onprL+mKhZz-rMyG6w@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Cc: "public-html-media@w3.org" <public-html-media@w3.org>
Ah, thank you Henri,

I wasn't aware that Netflix was already deploying their solution (we don't
have it in Germany). So, we can conclude that describing a plugin-like
behavior is unnecessary, outside the scope of the spec and not in line with
current behavior.

I think that makes it very clear: The paragraphs suggesting this kind of
behavior are unnecessary and dangerous (as was my suggestion... I did
assume the worst, much worse than what had actually happened).

In summary, they should be removed and at best be replaced with a note
saying that usage of a CDM does not change the behavior of the video
element in any way. Correct?

--hans


On Mon, Jan 13, 2014 at 11:52 AM, Henri Sivonen <hsivonen@hsivonen.fi>wrote:

> On Fri, Jan 10, 2014 at 4:18 PM, Hans Schmucker <hansschmucker@gmail.com>
> wrote:
> > 1. EME-protected content rendering happens in a separate frame, which
> > overlays any HTML, SVG or other content that the user-agent may be able
> to
> > process. However, a user-agent may display its own controls above the
> > EME-protected content.
>
> Netflix's EME-based player overlays both custom subtitles/captions and
> custom controls over the video frame. What you suggest would break
> this.
>
> It seems to me that being able to composite other content over EME
> content is already a de facto requirement. Section 2.3 of the draft
> indeed isn't particularly useful for interoperability, but, then
> again, the whole purpose of the draft is at odds with the sort of
> interoperability that one would expect from a Web spec.
>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>
Received on Monday, 13 January 2014 11:33:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:44 UTC