- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 10 May 2011 19:16:27 +1000
- 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. Silvia. 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