Re: Temporal media fragment for HTML media questions

On Tue, 10 May 2011 10:39:59 +0200, Chris Double <cdouble@mozilla.com>  
wrote:

> On Tue, May 10, 2011 at 8:08 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>>> 1) When a temporal fragment is given with a start time, when the
>>> loadedmetadata event on the resource is raised this is the currentTime
>>> of the resource.
>>
>> Do you mean that you internally seek when reaching HAVE_METADATA? That's
>> what I did, but care must be taken to not show the first frame of the  
>> video
>> before seeking. Also, should seeking events be fired at this point?
>
> I internally seek after I've read the metadata from the resource, then
> raise HAVE_METADATA when the seek is complete. I don't fire the
> seeking events. Would it be better to do HAVE_METADATA, then seek and
> raise the usual seeking events?

The HTML spec currently says in  
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#getting-media-metadata  
after setting readyState to HAVE_METADATA:

"If either the media resource or the address of the current media resource  
indicate a particular start time, then set the initial playback position  
to that time, seek to that time, and let jumped be true. Ignore any  
resulting exceptions (if the position is out of range, it is effectively  
ignored)."

That would mean that when the loadedmetadata event is fired, currentTime  
would still be 0, modulo race conditions. It also means that the  
seeking-related events are fired. Finally, it doesn't seem to guarantee  
that the first frame of the video is not displayed while seeking.

How would you change the spec to say what you were intending to implement?  
There's no mechanism for suppressing the seeking events currently, for  
example.

>>> 2) When an end time is given I do the equivalent of calling 'pause()'
>>> on the media element. I do not raise the 'ended' event.
>>
>> Is paused set to true, or is the element "paused for user interaction"?  
>> I
>> think the latter actually makes sense, but when I implemented MF as a  
>> quick
>> hack for FOMS I just called pause().
>
> It behaves exactly as if the 'pause()' method was called on the media
> element, so 'paused' is set to true. I think this makes it easier for
> controls to stay in sync with what's happening.

Good point. As another issue, it would be ideal if it behaved exactly as  
if one had used a cue range with the pauseOnExit flag, so that this logic  
can be shared in implementations and so that it's possible to emulate MF  
using cue ranges in browsers that only implement the latter.

>> 3. Don't support looping.
>>
>> I think option 3 is the least horrible option.
>
> I'll be doing this for the first implementation anyway since we don't
> yet support the loop attribute. I was curious for the case when we do
> support it though.
>
>>> 5) When a user seeks, or 'currentTime' is set on the DOM object then
>>> the media fragments are ignored. Is this the right approach? Or should
>>> seeks within the fragment range not remove the fragments?
>>
>> What does "remove the fragments" mean?
>
> By 'remove the fragments' I mean the resource no longer has the
> start/end range that playback is clipped too. The user interface no
> longer shows it, etc. Since there's no way to say 'play me only the
> fragment' once fragment play back is completed, or the user seeks
> outside of it, I thought I'd just remove any indicators of the
> fragment.

I'm quite skeptical of making the behavior stateful like this. If the user  
tries to seek to the beginning of the fragment but ends up right before it  
due to rounding errors, don't you think it would be annoying and confusing  
if the fragment stopped "working" from then on? IMO it would be better to  
always have the fragment present and always pause when reaching the end  
time. If the page author wants something more clever than that, they can  
use cue ranges and scripted UI to dynamically add and remove "pause  
points".

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 10 May 2011 09:24:48 UTC