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

On 12/04/2011, at 6:08 PM, Philip Jägenstedt <philipj@opera.com> wrote:

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


Gapless playing also works when all media data is loaded and you reset current time when reaching ended.

To me the feature of looping is to restart from the beginning, whether gap or not. Browsers make a best effort. And I don't really see that being different for multitrack, in particular since it works for in-band multitrack. The in-band behavior is also the one to mirror, so I don't think that's trying to be particularly 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.

I can agree that readyState may not need to be aggregated, but onmetadataloaded would be really useful to avoid having to set an event handler on each of the media elements.



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

Yeah, I am not fussed about this one.

Cheers,
Silvia.

Received on Tuesday, 12 April 2011 09:40:30 UTC