<video> decode in hardware!

webkit/media/webvideoframe_impl.h

Index: webkit/media/webvideoframe_impl.h
diff --git a/webkit/media/webvideoframe_impl.h b/webkit/media/webvideoframe_impl.h
index f82c4d77cb236ec6ab8f7905f298ee8b3ad3c1dd..bb315dc7fb300abed488bb76e5e18a5793826581 100644
--- a/webkit/media/webvideoframe_impl.h
+++ b/webkit/media/webvideoframe_impl.h
@@ -25,6 +25,7 @@ class WebVideoFrameImpl : public WebKit::WebVideoFrame {
   virtual unsigned planes() const OVERRIDE;
   virtual int stride(unsigned plane) const OVERRIDE;
   virtual const void* data(unsigned plane) const OVERRIDE;
+  virtual unsigned textureId() const OVERRIDE;

[scherkus (not reviewing), 2011/12/06 00:27:44]

instead of stuffing two image types (hardware and software surface) into a
single class I've contemplated having a separate interface that's dedicated for
hardware decode+render

does the hw rendering path require anything other than texture id?

I'd like to see you dig into the VideoLayerChromium code to see what we can
tease out into HW-decoded frames versus SW-decoded frames and what impact that
has on the WebVideoFrame and WebMediaPlayer interfaces

[Ami GONE FROM CHROMIUM, 2011/12/07 00:03:04]

HW path requires only texture id & size info.  It would be great to have the HW
and SW paths of VideoLayerChromium separated, esp. b/c the HW path would just be
PluginLayerChromium (suitably renamed).  Unfortch this isn't possible b/c WK's
(current) architecture requires the type of FooLayerChromium to be decided on at
<video>-creation time, long before the type of the video stream is ascertained,
much less whether a HW decoder can be applied to it is known.
I'm discussing this with jamesr@ in
https://bugs.webkit.org/show_bug.cgi?id=73043#c22
If we find a better solution for the LayerChromium side, then it'll carry over
to this class as well (after all it wouldn't make much sense to feed a
FooVideoBlarg frame to a {Plugin,External}LayerChromium).  Until then I don't
think there's anything for me to do here.

 
  private:
   scoped_refptr<media::VideoFrame> video_frame_;