W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

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

From: Oliver Hunt <oliver@apple.com>
Date: Mon, 18 Aug 2008 18:48:58 -0700
Message-ID: <DC7163B9-0CB4-4515-91D1-64E3E46B1A10@apple.com>

On Aug 18, 2008, at 5:58 PM, Robert O'Callahan wrote:

> On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <oliver at apple.com>  
> 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)
>
> drawImage is already overloaded, so why not carry on with that,  
> unless we change the API as you suggest below.
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...
>
> 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.
... 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

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080818/f7b586af/attachment.htm>
Received on Monday, 18 August 2008 18:48:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:04 UTC