- From: <bugzilla@jessica.w3.org>
- Date: Tue, 30 Oct 2012 22:31:56 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788 David Dorwin <ddorwin@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrianba@microsoft.com, | |strobe@google.com, | |watsonm@netflix.com --- Comment #1 from David Dorwin <ddorwin@google.com> --- Possible Solution One option might be to change how we think about the two scenarios. This might make implementations more difficult but would resolve some of these issues. * The first algorithm would be “First Time a Key Reference is Encountered.” Each container would need to specify what this means. For example, ISO BMFF/CENC might define this as encountering a PSSH even if the PSSH does not explicitly reference a key. For WebM, this might be when ContentEncryption/ContentEncKeyID is parsed. For a container without such headers, it might be the first time each key ID is encountered (i.e. in a block). * The second algorithm would continue to be "Encrypted Block Encountered" with the change that the Key Presence step does not fire an event or an error in the case where the needed key is not available. Note that this may or may not occur at the same time as the first reference to a specific key (the first algorithm). The first algorithm would be the only one that sends an event, and the second one would describe the behavior of playback (see bug 18515). Applications would not be informed that a key is needed for decrypting a current block. They shouldn’t really need to know for key-related reasons, but are there other reasons? Would/should existing events (i.e. stalled?) cover any such needs? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 30 October 2012 22:31:58 UTC