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:11:12 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Media Fragment" <public-media-fragment@w3.org>, "Chris Double" <cdouble@mozilla.com>
Message-ID: <op.vu9c4yefsr6mfa@localhost.localdomain>
It would be possible to hook up, but I would very much like it to be  
implemented in terms of setting src on the video element. Thus, the key  
here is to define the behavior of dynamically modifying the src attribute,  
as we're discussing in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

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

> That's nice!
> Would fragment changes in the URL bar really be a problem? Browsers
> are already catching that for HTML pages and doing just a fragment
> offset on the already loaded resource, so they could catch that for
> media, too, and just change the start/end time for the fragment.
> Silvia.
> On Tue, May 10, 2011 at 7:03 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> 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

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 10 May 2011 09:11:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC