Re: Temporal media fragment for HTML media questions

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
>

Received on Tuesday, 10 May 2011 09:07:38 UTC