Re: [media] issue-152: documents for further discussion

On Apr 20, 2011, at 1:49 AM, Philip Jägenstedt wrote:

> On Wed, 20 Apr 2011 02:51:00 +0200, Ian Hickson <ian@hixie.ch> wrote:
> 
>> On Tue, 12 Apr 2011, Silvia Pfeiffer wrote:
> 
>>> > | (this one is particularly important for onmetadatavailable events)
>>> >
>>> > The events are independent of the attributes. What events would you
>>> > want on a MediaController, and why? Again, sample code would really
>>> > help clarify the use cases you have in mind.
>>> 
>>> Maybe a onmetadatavailable event is more useful than a readyState then?
>> 
>> I've updated the spec to fire a number of events on MediaController,
>> including 'metadataavailable' and 'playing'/'waiting'.
> 
> This seems to make the race conditions in HTMLMediaElement.readyState slightly worse than they already were. At the point when the loadedmetadata event is fired on the MediaController, the readyState of the slaved media elements could be just about anything, and might not even be the same on all of them.

  Why is it a problem to have the readyState on slaved elements be different when the loadedmetadata event is fired on the MediaController as long as they are all at least at HAVE_METADATA?

> 
> I'd very much like to see at least the overall issue of race conditions resolved. For these aggregate events on MediaController, we would have to make sure that they are fired in the same task as the last media element changes its readyState and fires the corresponding event.
> 
  Firing it in the same task that the last media element fires the corresponding event seems reasonable, but I still don't understand why you think it will be helpful to freeze readyState until the event fires. Can you explain (maybe again) with a concrete example?

>> 
>> On Tue, 12 Apr 2011, Philip Jägenstedt wrote:
>>> 
>>> Since HTMLMediaElement.played seems almost useless I haven't implemented
>>> it in Opera. I still have hopes that it will be removed from the spec,
>>> but failing that let's not copy it around unless we have a good use case
>>> for it.
>> 
>> The use case Silvia suggests seems reasonable (marking on the timeline
>> what has been played), why is it not good?
> 
> I've boycotted HTMLMediaElement.played by not implementing it and so far I've never heard a single request for it. I've also never seen controls that expose what has already been played, only what is currently buffered. I know this has been discussed before, but I can't find it in the archives. Then the use case was something like showing or not showing ads depending on what had been watched, I think. IMO, in the absence of compelling use cases it should be removed from both HTMLMediaElement and MediaController. One thing speaking against that is that it's already implemented in WebKit, of course.
> 
  It was added to WebKit because of developer requests. Which counts for more, our requests or your lack of requests ;-)

eric

Received on Wednesday, 20 April 2011 18:37:23 UTC