Re: [media] progress on multitrack api - issue-152

On Mon, 18 Apr 2011 13:46:47 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Mon, Apr 18, 2011 at 6:59 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> Thanks for compiling this, Silvia, I'll do my best to point out where I
>> disagree and why.

>>> (5) more events should be available for combined multitrack:
>>>
>>> The following events should be available in the controller:
>>>
>>> * onloadedmetadata: is raised when all slave media elements have
>>> reached at minimum a readyState of HAVE_METADATA
>>>
>>> * onloadeddata: is raised when all slave media elements have reached
>>> at minimum a readyState of HAVE_CURRENT_DATA
>>>
>>> * canplaythrough: is raised when all slave media elements have reached
>>> at minimum a readyState of HAVE_FUTURE_DATA
>>
>> This should be HAVE_ENOUGH_DATA. (HAVE_FUTURE_DATA is a useless state  
>> that
>> indicates that two frames (including the current frame) are available.  
>> The
>> associated event, canplay, doesn't mean that one can actually play in  
>> any
>> meaningful sense.)
>
> Ups, well spotted. Thanks.
>
>
>>> * onended: is raised when all  slave media elements are in ended state
>>>
>>> or said differently: these events are raised when the last slave in a
>>> group reaches that state.
>>>
>>> These are convenience events that will for example help write combined
>>> transport bars. It is easier to attach just a single event handler to
>>> the controller than to attach one to each individual slave and make
>>> sure they all fire. Also, they help to maintain the logic of when a
>>> combined resource is loaded. Since these are very commonly used
>>> events, their introduction makes sense.
>>>
>>> Alternatively or in addition, readyState could be added to the  
>>> controller.
>>
>> I would like to see more discussion of the actual use cases. When would  
>> it
>> be useful to know that all slave media elements have reached
>> HAVE_CURRENT_DATA, for example? For HAVE_ENOUGH_DATA, the main use case
>> seems like it would be to autoplay, but you also suggested adding an
>> explicit autoplay.
>>
>> My reluctance comes from not-so-happy experience with readyState and the
>> related events on HTMLMediaElement. Most of the states and events are
>> borderline useless and it's also necessary to lie about them in order to
>> avoid exposing race conditions to scripts. Without very compelling use
>> cases, I'd prefer pushing the burden over on scripts, until we see what  
>> it's
>> going to be used for.
>
> Onloadedmetadata is a very very important event. Any time that I want
> to do something in JavaScript with a video or audio resource I have to
> wait until they reach that state before I can do anything sensible on
> them, such as seek to a particular offset, or pause the video and play
> a pre-roll ad, or determine the displayed width and height to do
> something with.
>
> Onloadeddata is used before I can feed an image into a canvas to grab
> the pixels and analyse them.
>
> Canplaythrough is useful to put the video loading into the background
> and display something else during that time such as an ad, and then
> fade to the poster.
>
> Onended is important to do something once the video or audio resource
> is finished playing, such as display related videos, or display a
> post-roll ad.
>
> I'm sure I can come up with more use cases if need be. ;-)

I grudgingly admit that your use cases are completely sane and realistic.

If an aggregate readyState is added, we must make sure that we don't add  
yet more race conditions to the spec. Specifically, when an aggregate  
loadedmetadata event is fired, it should be guaranteed that all of the  
slave elements have already fired loadedmetadata and are still in  
HAVE_METADATA, not allowing their readyState to reflect the real state of  
the decoding that is going on asynchronously. Otherwise, the readyState of  
the slaves will not only be unpredictable, they might also not even be  
different from slave to slave.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 19 April 2011 11:12:32 UTC