[whatwg] Using <video> as a source for canvas.drawImage

[Ian Hickson]

On Tue, 19 Aug 2008, Robert O'Callahan wrote:
>
> Thanks to Anne for pointing this out...
> 
> We've implemented using <video> elements as an image source in
> canvas.drawImage:
> https://bugzilla.mozilla.org/show_bug.cgi?id=448674
> The extension is very obvious. Unlike animated images, which always draw the
> first or poster frame, we draw the current frame of the video. This lets you
> do things like make a thumbnail timeline.
> 
> It'd be nice to have this in the spec.

This is now in the spec.


On Mon, 18 Aug 2008, Oliver Hunt wrote:
>
> Cool -- I wonder though if it would be better if it were placed in a 
> different method, drawFrame or something (very much an up in the air 
> sort of question)

On Tue, 19 Aug 2008, Robert O'Callahan wrote:
> 
> drawImage is already overloaded, so why not carry on with that, unless we
> change the API as you suggest below.

On Mon, 18 Aug 2008, Oliver Hunt wrote:
>
> I'm  not sure that drawImage overloading was a good idea in the first place
> *but* canvas and image are fairly similar in both image-like, whereas video is
> quite clearly different.  I was also thinking it would work better given the
> additional frame argument, however...

On Mon, 18 Aug 2008, Oliver Hunt wrote:
> 
> One other thing that I would consider would be requiring the frame# to 
> be specified explicitly as that would make things like "chapter" 
> previews (or whatever) work in a way that is perhaps cleaner.  
> Otherwise you have to record the current location in the video stream, 
> then scan to each location you want to blit, draw, and then return to 
> the original position.  Which could easily result in weird visual 
> behaviour for the user (as the video element flickers a few random 
> frames while you do your previews or whatever).

On Tue, 19 Aug 2008, Robert O'Callahan wrote:
> 
> AFAIK we'd basically have to implement that by creating a second video 
> stream, seeking it and then capturing the frame, and you really don't 
> want to do that synchronously! Then we'd want to cache that stream so 
> that another drawFrame with a nearby frame index was efficient ... ick. 
> So I suggest not offering that API. Authors can always use a second, 
> hidden video element to achieve the same effect.

On Mon, 18 Aug 2008, Oliver Hunt wrote:
>
> ... I had failed to consider streaming content (where random seeking may 
> not be possible) :-/
> 
> I still think it would be useful to be able to specify an exact frame, 
> but as you say it may not be really feasible

I just used drawImage(), for the reasons roc gave.

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