- From: <bugzilla@jessica.w3.org>
- Date: Mon, 19 Jan 2015 10:57:49 +0000
- To: public-html-bugzilla@w3.org
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 the QA Contact for the bug.
Received on Monday, 19 January 2015 10:57:53 UTC