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

Re: Temporal media fragment for HTML media questions

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 10 May 2011 19:16:27 +1000
Message-ID: <BANLkTin21zXiOsMMc__zY7iPfDtopAVBBQ@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>, Chris Double <cdouble@mozilla.com>
Yup, that's what I meant.

On Tue, May 10, 2011 at 7:11 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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:17:14 UTC

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