- From: <bugzilla@jessica.w3.org>
- Date: Tue, 05 Jun 2012 19:57:58 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202 Mark Watson <watsonm@netflix.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |watsonm@netflix.com --- Comment #1 from Mark Watson <watsonm@netflix.com> 2012-06-05 19:57:58 UTC --- (In reply to comment #0) > While the algorithms probably cover this, it would be helpful to explicitly > state how keys may be shared. We want to prevent different behavior that could > lead to pages that make assumptions that are not true for all implementations. > > The current intent is that keys/licenses are shared for all streams (i.e. audio > and video) in a single media element but are NOT shared between media elements > (whether in a given page or different pages). CDMs should ensure that keys > don't leak between elements. > > Bug 16615 proposes a specific scenario where sharing might be allowed. There are certainly scenarios where keys/licenses should be shared across elements slaved to a MediaController (as in 16615). For example two video elements showing different video tracks from the same src (main video and sign language, for example). I'm not sure if the use of MediaController is the right test to enable/disable sharing, though. Is it possible that two elements with the same src that are not slaved to the same MediaController might share keys/licenses ? It's common for all the resources associated with some presentation to share the same keys, since this avoids the need for multiple or compound key/license requests. I'm not sure we should rule this out for presentations where the component resources are not synced with a MediaController, although I can't think of any good examples of such presentations. What's the disadvantage if we allow keys/licenses to be shared by all elements on the page ? -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 5 June 2012 19:58:01 UTC