<video> decode in hardware!

webkit/media/webvideoframe_impl.h

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef WEBKIT_MEDIA_WEBVIDEOFRAME_IMPL_H_
 #define WEBKIT_MEDIA_WEBVIDEOFRAME_IMPL_H_
 
 #include "base/compiler_specific.h"
 #include "media/base/video_frame.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebVideoFrame.h"
 
 namespace webkit_media {
 
 class WebVideoFrameImpl : public WebKit::WebVideoFrame {
  public:
   // This converts a WebKit::WebVideoFrame to a media::VideoFrame.
   static media::VideoFrame* toVideoFrame(
       WebKit::WebVideoFrame* web_video_frame);
 
   WebVideoFrameImpl(scoped_refptr<media::VideoFrame> video_frame);
   virtual ~WebVideoFrameImpl();
   virtual WebVideoFrame::Format format() const OVERRIDE;

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

re: discussion on chromium-dev I think we actually want to remove OVERRIDE from
these methods so we don't break the upstream WebKit builds when interfaces
change

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

Done.

   virtual unsigned width() const OVERRIDE;
   virtual unsigned height() const OVERRIDE;
   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_;
   DISALLOW_COPY_AND_ASSIGN(WebVideoFrameImpl);
 };
 
 }  // namespace webkit_media
 
 #endif  // WEBKIT_MEDIA_WEBVIDEOFRAME_IMPL_H_