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. `._.-(,_..'--(,_..'`-.;.'
