Chromium Code Reviews| Index: cc/layers/video_frame_provider.h |
| diff --git a/cc/layers/video_frame_provider.h b/cc/layers/video_frame_provider.h |
| index 45e6c4110c5364ec5deb36e2e1a7504fcbbf007d..be06be8580a0035d6d6f38fb56fed0328fbb7573 100644 |
| --- a/cc/layers/video_frame_provider.h |
| +++ b/cc/layers/video_frame_provider.h |
| @@ -6,6 +6,7 @@ |
| #define CC_LAYERS_VIDEO_FRAME_PROVIDER_H_ |
| #include "base/memory/ref_counted.h" |
| +#include "base/time/time.h" |
| #include "cc/base/cc_export.h" |
| namespace media { |
| @@ -14,27 +15,35 @@ class VideoFrame; |
| namespace cc { |
| -// Threading notes: This class may be used in a multi threaded manner. |
| -// Specifically, the implementation may call GetCurrentFrame() or |
| -// PutCurrentFrame() from the compositor thread. If so, the caller is |
| -// responsible for making sure Client::DidReceiveFrame() and |
| -// Client::DidUpdateMatrix() are only called from this same thread. |
| +// VideoFrameProvider and VideoFrameProvider::Client define the relationship by |
| +// which video frames are exchanged between a provider and client. |
| +// |
| +// Threading notes: This class may be used in a multithreaded manner. However, |
| +// if the Client implementation calls GetCurrentFrame()/PutCurrentFrame() from |
| +// one thread, the provider must ensure that all client methods are called from |
| +// that thread (typically the compositor thread). |
| class CC_EXPORT VideoFrameProvider { |
| public: |
| - virtual ~VideoFrameProvider() {} |
| - |
| class CC_EXPORT Client { |
| public: |
| - // Provider will call this method to tell the client to stop using it. |
| + // The provider will call this method to tell the client to stop using it. |
| // StopUsingProvider() may be called from any thread. The client should |
| // block until it has PutCurrentFrame() any outstanding frames. |
| virtual void StopUsingProvider() = 0; |
| + // Notifies the client that it should start or stop making regular Render() |
| + // calls to the provider. No further calls to Render() will be made after |
| + // StopRendering() returns. Clients should handle redundant calls. |
| + virtual void StartRendering() = 0; |
| + virtual void StopRendering() = 0; |
| + |
| // Notifies the provider's client that a call to GetCurrentFrame() will |
| // return new data. |
| + // TODO(dalecurtis): Nuke this once VideoFrameProviderClientImpl is using a |
| + // BeginFrameObserver based approach. http://crbug.com/336733 |
| virtual void DidReceiveFrame() = 0; |
| - // Notifies the provider's client of a new UV transform matrix to be used. |
| + // Notifies the client of a new UV transform matrix to be used. |
| virtual void DidUpdateMatrix(const float* matrix) = 0; |
| protected: |
| @@ -45,18 +54,29 @@ class CC_EXPORT VideoFrameProvider { |
| // that the provider is not destroyed before this call returns. |
| virtual void SetVideoFrameProviderClient(Client* client) = 0; |
| - // This function places a lock on the current frame and returns a pointer to |
| - // it. Calls to this method should always be followed with a call to |
| - // PutCurrentFrame(). |
| - // Only the current provider client should call this function. |
| + // Called by the client on a regular interval. Returns true if a new frame is |
|
xhwang
2015/04/03 07:00:13
nit: s/is/will be/ ?
DaleCurtis
2015/04/07 00:40:51
Done.
|
| + // available via GetCurrentFrame() which should be displayed within the |
| + // presentation interval [|deadline_min|, |deadline_max|]. |
|
xhwang
2015/04/03 07:00:13
So I assume the "interval" will be the vsync inter
DaleCurtis
2015/04/03 17:14:52
Yup, you can see what the mostly complete algorith
|
| + virtual bool Render(base::TimeTicks deadline_min, |
| + base::TimeTicks deadline_max) = 0; |
|
xhwang
2015/04/03 07:00:13
bikeshedding on naming: This really is something l
DaleCurtis
2015/04/03 17:14:52
Yeah... I went back and forth on this: Either keep
DaleCurtis
2015/04/07 00:40:51
Done.
|
| + |
| + // Returns the last frame that was rendered during Render(). A call to this |
| + // method does not ensure that the frame will be rendered. A subsequent call |
| + // to PutCurrentFrame() will be made if the frame is rendered. |
| virtual scoped_refptr<media::VideoFrame> GetCurrentFrame() = 0; |
| - // This function releases the lock on the video frame. It should always be |
| - // called after GetCurrentFrame(). Frames passed into this method |
| - // should no longer be referenced after the call is made. Only the current |
| - // provider client should call this function. |
| - virtual void PutCurrentFrame( |
| - const scoped_refptr<media::VideoFrame>& frame) = 0; |
| + // Indicates that the frame returned via GetCurrentFrame() was rendered. Must |
| + // only occur after a previous call to GetCurrentFrame(). |
| + virtual void PutCurrentFrame() = 0; |
|
xhwang
2015/04/03 07:00:13
Here we have GetCurrentFrame/PutCurrentFrame. Then
DaleCurtis
2015/04/03 17:14:52
The compositor is what I'd call a two-phase proces
xhwang
2015/04/03 19:18:27
Let me make sure I understand "dropped frame" coun
DaleCurtis
2015/04/03 19:59:16
Yes this is correct. I'd be okay with renaming it.
|
| + |
| + // Called by the client when the visibility of the output layer changes. The |
| + // client will not issue any Render() calls while the output layer has no |
| + // visibility. It will not start any Render() calls before notifying the |
|
xhwang
2015/04/03 07:00:13
What about using web canvas to manipulate video? I
DaleCurtis
2015/04/03 17:14:52
Sunny, can you clarify on this? It's my expectatio
xhwang
2015/04/03 19:18:27
What if the JS app draw the video into a canvas, g
DaleCurtis
2015/04/03 19:59:16
I think if we update every say 100ms that should b
|
| + // provider of visibility. |
| + virtual void SetVisible(bool visible) = 0; |
| + |
| + protected: |
| + virtual ~VideoFrameProvider() {} |
| }; |
| } // namespace cc |