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

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. These open bugs are about race conditions with  
readyState and networkState:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11981
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12175
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

These open bugs are about other readyState issues:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12195
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12529

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.

>> > | 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.
>
> Ok, added.

See below.

>> One more question turned up today: is there any means in which we could
>> possibly create @controls (with track menu and all) for the combined
>> resource? Maybe they could be the same controls on all the elements that
>> have a @controls active, but would actually be driven by the
>> controller's state rather than the element's? Maybe the first video
>> element that has a @controls attribute would get the full controller's
>> state represented in the controls? Could there be any way to make
>> @controls work?
>
> The UA is responsible for this, but the spec requires that the UI
> displayed for a control that has a controller control the controller.
>
>
> 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.

> On Tue, 12 Apr 2011, Silvia Pfeiffer wrote:
>>
>> 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.
>
> We had looping in the spec before, but I took it out due to  
> implementation
> burden concerns.

Thanks :)

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 20 April 2011 08:49:57 UTC