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

On Wed, 20 Apr 2011 20:36:55 +0200, Eric Carlson <eric.carlson@apple.com>
wrote:

>
> 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?

One kind of quite likely error is that people try to draw the videos to a  
canvas in the loadedmetadata event handler. Most of the time this will  
work because of the very narrow window between HAVE_METADATA and  
HAVE_CURRENT_DATA. However, for those elements that are still actually in  
HAVE_METADATA, nothing will be painted per the drawImage spec: "if the  
image argument is an HTMLVideoElement object whose readyState attribute is  
either HAVE_NOTHING or HAVE_METADATA, then the implementation must return  
without drawing anything." If readyState is racy, then of course such  
scripts will fail randomly, but if such failure is rare enough, some sites  
will inevitably come to depend on readyState being HAVE_CURRENT_DATA in  
the loadedmetadata event handler, which would make HAVE_METADATA and  
HAVE_CURRENT_DATA completely redundant.

>> 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?

These are race conditions that I or people I work with have actually  
tripped on:

* When removing the autoplay attribute in any of the loadstart,  
loadedmetadata, loadeddata or canplay event handlers, it's racy whether or  
not the media element will actually play.

* When registering a loadeddata event handler in the loadedmetadata event  
handler, it's racy whether or not that event handler will run. The same is  
true of any other pair of events that depend on readyState or networkState  
transitions. Having this not be racy would be useful when writing tests,  
e.g. to catch the first canplaythrough event after the seeked event.

* For preload=metadata, when checking networkState in a progress event  
handler, it's racy between NETWORK_LOADING and NETWORK_IDLE. This makes it  
impossible to test if we follow the spec on fast networks.

Some other (more theoretical) scenarios:

* When currentTime is set in the loadstart event handler, it's racy  
whether or not it will actually seek (fails if readyState is HAVE_NOTHING).

* When the loop attribute is present and you pause() in the ended event  
handler, it's racy if you end up paused at the beginning or the end.

It's always possible to be careful to avoid the race conditions, but we  
can't rely on everyone writing scripts to have a perfect understanding of  
this.

Prediction: If we don't address at least most of the raciness before  
<video> reaches widespread use, then we will be forced to address it  
retroactively by specifying whatever the most common outcome of various  
race conditions are. This will be more inconsistent and confusing than if  
we are deliberate about the design.

>>> 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 ;-)

A priori, I would of course give more weight to developer requests than  
the absence of them. Do you have any examples of sites or demos that are  
actually using .played as implemented in WebKit? That would be a (to me)  
more convincing reason to implement it than "the spec says so", "it's not  
very hard" or "something with ads".

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 21 April 2011 10:52:40 UTC