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

On Tue, 12 Apr 2011 03:45:12 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Apr 12, 2011 at 8:17 AM, Ian Hickson <ian@hixie.ch> wrote:
>> On Mon, 11 Apr 2011, Silvia Pfeiffer wrote:
>>>
>>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary

>> | a group should be able to loop over the full multitrack rather than a
>> | single slave
>>
>> Not sure what this means.
>
> We discussed the looping behaviour. To make it symmetrical with
> in-band multitrack resources, it would make sense to be able to loop
> over composed multitrack resources, too. The expected looping
> behaviour is that a loop on the composed resource loops over the
> composite as a whole. So, the question is then how to turn such
> looping on.
>
> The proposal is that when one media element in the group has a @loop
> attribute, that would turn the looping on the composite resource on.
> This means that when the loop is set and the end of the composite
> resource is reached (its duration), the currentTime would be reset to
> its beginning and playback of the composite resource would start
> again. Looping on individual elements is turned off and only the
> composite resource can loop.

The main benefit of declarative looping is that it can be gapless. Making  
that work for more than a single (usually audio) track requires that all  
tracks are exactly of equal length or doing something clever. Without  
compelling use cases, I strongly prefer not dealing with looping and not  
being clever :)

>> | readyState
>>
>> I could expose a readyState that returns the lowest value of all the
>> readyState values of the slaved media elements, would that be useful? It
>> would be helpful to see a sample script that would make use of this; I
>> don't really understand why someone would care about doing this at the
>> controller level rather than the individual track level.
>
> I think it makes sense, in particular when script is waiting for all
> elements to go to HAVE_METADATA state, which is often the case when
> you are trying to do something on the media resource, but have to wait
> until it's actually available.
>
> An example JS would be where you are running your own controls for the
> combined resource and want to determine the combined duration and
> volume for visual display, e.g.
>
>       video.controller.addEventListener("loadedmetadata", init, false);
>       function init(evt) {
>         duration.innerHTML = video.controller.duration.toFixed(2);
>         vol.innerHTML      = video.controller.volume.toFixed(2);
>       }
>
> So, I think a combined readyState makes sense in the way you described.

IMO, HTMLMediaElement.readyState is broken by design, a pain to implement  
and almost useless to scripts. Without very compelling use cases, I would  
prefer not combining it into another state.

>> | (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 am not aware of many scripts that use the readyState values directly
> for anything, even on the media elements themselves.

That would really amount to a combined readyState in order to track when  
all slaves have reached HAVE_METADATA.

>> | TimeRanges played
>>
>> Would this return the union or the intersection of the slaves'?
>
> That would probably be the union, because those parts of the timeline
> are what the user has viewed, so he/she would expect them to be marked
> in manually created controls.

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.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 12 April 2011 08:08:42 UTC