W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2011

Re: Temporal media fragment for HTML media questions

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 10 May 2011 11:03:24 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Media Fragment" <public-media-fragment@w3.org>, "Chris Double" <cdouble@mozilla.com>
Message-ID: <op.vu9crycvsr6mfa@localhost.localdomain>
Since navigating to a media resource directly silently creates a <video>  
element with src set to the address navigated to, the two are mostly  
equivalent. The exception is when changing the fragment component in the  
address bar, which would have to be hooked up in some way (or ignored).

Philip

On Tue, 10 May 2011 10:51:40 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> Hi Chris, Philip,
>
> Nice work on media fragment URIs, awesome!
> Is this for URLs pasted in the browser or for URLs in the <video>
> element? Or maybe both?
>
>
> On Tue, May 10, 2011 at 6:08 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> Hi Chris,
>>
>> On Tue, 10 May 2011 03:52:11 +0200, Chris Double <cdouble@mozilla.com>
>> wrote:
>>
>>> I'm working on Mozilla bug 648595 to implement temporal media
>>> fragments on the HTML video and audio elements:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=648595
>>>
>>> I have basic support working but have some questions regarding
>>> behaviour and events. This is how I've currently implemented things:
>>>
>>> 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?
>>
>>> 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().
>>
>>> 3) When the media is paused due to reaching the end time and then
>>> 'play()' is called, playback continues ignoring the media fragment
>>> times.
>>
>> Agreed.
>>
>>> 4) What do I do with 'loop'? Loop the fragment?
>>
>> This has pretty much been discussed to death. IMO, there are basically 3
>> options:
>>
>> 1. Treat #t as a "cropping" operation so that entire timeline is that  
>> of the
>> fragment. Then loop, ended, etc can be treated as usual.
>>
>> 2. Make the fragment somehow stateful so that looping works until one  
>> seeks
>> outside the fragment. I quite dislike this approach because it would
>> probably be confusing to users why looping sometimes works and sometimes
>> not.
>>
>> 3. Don't support looping.
>>
>> I think option 3 is the least horrible option.
>>
>>> Currently authors fake looping in the absence of the attribute support
>>> by doing something like:
>>>
>>>  <video onended='video.play()'></video>
>>>
>>> This workaround won't work with fragments as I've implemented them. I
>>> don't raise the ended event. And if I did, 'play()' resumes after the
>>> fragment.
>>>
>>> There doesn't seem to be a way to detect 'hit end of fragment', or to
>>> get the fragment start/end times using the DOM without the author
>>> parsing the URL themselves. Is this likely to be a problem in
>>> practice?
>>>
>>> 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?
>
> That equals option 2 above for looping IMO, i.e. the "zoom in" on the
> fragment is removed as soon as the user interacts with the timeline.
>
> The whole handling of media fragments depends indeed on the model that
> we associate with it. Originally, cropping seemed the right approach
> to me. But we are using #-fragments and not a new resource, so from a
> URI POV there is still the "main" resource which is the full resource.
> The thing is: if we deal with fragments with rendering @controls, then
> we can make it behave in option2 and how Chris is handling point 5).
> If we turn off @controls at that stage, we still get to display the
> "cropped" resource and the Web developer can decide to do with the
> controls what they like.
>
>
>>> Any feedback appreciated. If other implementors could comment on what
>>> they plan to do (or have already done) in this area I'd appreciate at
>>> it so I can make sure the Firefox implementation is compatible.
>>
>> Please have a look at  
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723
>> and weigh in with whatever you think makes sense.
>>
>> Finally, whatever you end up implementing, I would very much appreciate  
>> if
>> you take the time to ensure that it ends up in the specs as well,  
>> either MF
>> of HTML. When the time comes for me and other browsers to implement  
>> this, we
>> shouldn't have to refer to the email archives for implementation
>> requirements :)
>
> I agree! :-)
>
> Cheers,
> Silvia.


-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 10 May 2011 09:03:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:43 GMT