[whatwg] Issue when Video currentTime used for seeking.

[Ian Hickson]

On Wed, 12 Nov 2008, Biju Gm at il wrote:
>
> I see a problem while using video_element.currentTime instead of 
> video_element.start
> 
> ie, recent firefox nightly build removed video_element.start before that 
> we could do following to make a movie with new URL start from 10th 
> second frame
> 
> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
> video_element.start=10;
> video_element.play();
> 
> 
> Now to achieve same effect I tried
> 
> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
> video_element.currentTime=10;
> video_element.play();
> 
> This gives a problem.
> ie, I can not set .currentTime immediately after .src changed
> it throughs error (may be it is waiting to load metadata)
> 
> So can we have a method .seek() or .skip() or something.

The seek method is setting currentTime. Your request seems to be to allow 
seeking into times that are not known to be in the allowed duration.

You can work around the lack of this by doing:

   video_element.src = "http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
   video_element.ondurationchange = function () {
     video_element.currentTime=10;
     video_element.play();
     video_element.ondurationchange = null;
   };

...which isn't much worse than just saying video_element.start = 10.


On Wed, 12 Nov 2008, Chris Double wrote:
> 
> You can use:
> 
> v.src = "foo.ogg";
> v.addEventListener("loadedmetadata", function() { v.currentTime=10;
> v.play(); }, false);

That also works.


On Thu, 13 Nov 2008, Biju Gm at il wrote:
> 
> Yes we can use JS to have a work around. But there will be other 
> problems. Example, the above code make all the subsequent assignment of 
> url to v.src make movie start from 10th second. So again we need to add 
> code to remove the event listener.

Yes, it is a few lines of extra code. Not much though.

The problem is that we can't really allow seeking before the media is 
available because then the error handling becomes really hard to define 
and understand.


On Fri, 14 Nov 2008, Silvia Pfeiffer wrote:
>
> I still feel rather dubious about the currentTime attribute of the video 
> element.
> 
> When it is used to tell a server about starting at an offset rather than 
> a the beginning, I'd prefer we rather use media fragment URIs (once they 
> are standardised by the W3C media fragment working group). It will then 
> be obvious that the user is actually asking for a subpart of the 
> resource to be displayed only. This is controlled by the author of the 
> Web page.

The initial start offset is orthogonal to this (and the media fragment URI 
syntax is supported by <video>, at least in theory).


> When it is used to change the current play pointer during watching of a 
> video, i.e. is controlled by the user of the Web page, it should really 
> be done through an event and javascript. Maybe the onclick event can be 
> defined for the video element here and it could call a seek javascript 
> function?

I don't really understand what that means.


On Wed, 12 Nov 2008, Chris Double wrote:
>
> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
> > toKeyFrame - optional, boolean, default false. if true indicates goto
> > the nearest keyframe of the value provided in secondsToSeek.
> > this is to improve performance while avoiding  bug
> > https://bugzilla.mozilla.org/show_bug.cgi?id=463358
> 
> Good question. Should seeks go to the previous keyframe to the requested 
> time, the next keyframe after the time, the closest keyframe, or the 
> exact frame requested?

Per spec, the exact frame.


> Regarding that bug, I think it should be going to the last keyframe then 
> decoding up to the point of the requested frame so it can display 
> non-garbage data. But is there a requirement to be able to identify 
> keyframes from JavaScript? I suspect not but don't know.

I don't really see why there would be.


> > .seek() will return the time to which it is seek-ed to.
> 
> What time is that exactly? Is that the time of the actual frame the seek 
> ended on? Seek can take some time if it requires multiple http byte 
> range requests to find the right location, and to search for the 
> keyframe. You wouldn't want this to be a blocking call but it would need 
> to be if you want to return the time.

Between currentTime, onseeked, and ontimeupdate, I think we already have 
this.


On Wed, 12 Nov 2008, Eric Carlson wrote:
>
> Seeks should end up as close to the requested time as possible, the 
> behavior wrt keyframes should be an implementation detail. I say "as 
> close as possible" because it is not always possible to know the file 
> location of an exact time unless all of the media data up to that time 
> has already been downloaded.

Indeed, this seems like a quality-of-implementation issue.


On Thu, 13 Nov 2008, Biju Gm at il wrote:
> 
> The idea for toKeyFrame argument came from some flash video controls ie, 
> when we silde the duration slider, these flash controls flips through 
> frames quickly. At that time it dont really matter exactly which frame, 
> it can be before or after which ever is EASY to find.

Script can use the "buffered" DOM object to work out what would be easy 
for the UA to find.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'