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 18:51:40 +1000
Message-ID: <BANLkTi=xFpjo6A_qd3JcchgZqF7OsL32cw@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>, Chris Double <cdouble@mozilla.com>
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! :-)

Received on Tuesday, 10 May 2011 08:52:27 UTC

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