[Bug 26372] Report issues/events not related to a specific method call

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372

--- Comment #14 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #13)
> (In reply to David Dorwin from comment #12)
> > (In reply to Joe Steele from comment #11)
> > > (In reply to David Dorwin from comment #10)
> > > Assuming the answer is no, this sounds reasonable to me. I would like to
> > > include "downscaling" as one of the options (perhaps as a subset of output
> > > protection).
> > 
> > That would potentially address bug 25092.
> > 
> > However, it would imply that downscaling means that a key is "not usable",
> > which could be confusing since the CDM is actually using it for decryption.
> 
> I don't think it implies that. I think it is "less usable", but still
> usable. The ability to include a status with the usableKeys gives us a scale
> of usability - from completely unfettered, to usable but with restrictions,
> to completely unusable. 

I was referring to the key's removal from the array returned by
getUsableKeyIds(). A keyschange event implies that the list has changed. Firing
keyschange just to report an enum value does not seem appropriate.

> This is the only example of "less usable" that I know I would use, but I can
> imagine others. For example, the CDM could report that output protection is
> required or that the expiration of the key is immanent. Those could be
> useful to the application when deciding how to handle errors.

Wouldn't output protection required and not present result in an unusable key?
I don't believe "imminent expiration" should be handled by this mechanism. We
already have the expiration attribute, and we'd have to define "imminent."


Reporting downscaling with just an enum wouldn't be future-proof. Today,
downscaled probably means the application should fetch a 480p stream instead,
but what if there were multiple levels of downscaling? (See bug 25092#c21 for
another possible solution.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 8 September 2014 21:08:22 UTC