- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 10 May 2011 19:06:51 +1000
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Media Fragment <public-media-fragment@w3.org>, Chris Double <cdouble@mozilla.com>
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