W3C home > Mailing lists > Public > public-html-a11y@w3.org > January 2015

[Bug 27054] Accessibility Concerns

From: <bugzilla@jessica.w3.org>
Date: Mon, 19 Jan 2015 10:57:49 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-27054-3290-IxrO2zSIqN@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27054

--- Comment #11 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to David Dorwin from comment #10)
> (In reply to Henri Sivonen from comment #9)
> > (In reply to David Dorwin from comment #7)
> > > Good point. What restrictions do we need to place on the media? 
> > 
> > As long as the spec e.g. allows non-CENC encryption inside MP4, I think it's
> > not useful to band the theoretical possibility of instead putting the
> > encryption outside MP4. In other words, pretending that restricting
> > encryption to inside the container would in itself be an interop win when
> > there remain multiple ways to do encryption inside the container seems
> > illusory.
> 
> If I understand correctly, you are saying we should NOT restrict encryption
> to inside the container because the spec theoretically allows MP4 protection
> schemes other than CENC. (The same applies to the potential to support any
> other container.) Is that right?

Yes, and by looking at WebKit source, this doesn't seem to be in the
"theoretically" category.

> This is not about increasing interoperability - it is about stating
> assumptions about the media that the spec, as written, supports. The
> assumption that the container is not encrypted is currently fundamental to
> some of the spec algorithms. The most obvious case is initData extraction,
> which would not be possible if the container is encrypted (ignoring some
> type of nested containers). The processing of the media data, including the
> Encrypted Block Encountered algorithm, also make this assumption.

OK. In that case, it's worthwhile to state the assumption.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 19 January 2015 10:57:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 January 2015 10:57:53 UTC