Introduce media::RendererFactory interface.

content/public/renderer/content_renderer_client.h

Index: content/public/renderer/content_renderer_client.h
diff --git a/content/public/renderer/content_renderer_client.h b/content/public/renderer/content_renderer_client.h
index 9a6c695d5df5f0bea350beaa205d6919a6439fcd..1402ad6789ddd4eb9c5b461632a7b4e7a63181b5 100644
--- a/content/public/renderer/content_renderer_client.h
+++ b/content/public/renderer/content_renderer_client.h
@@ -53,7 +53,7 @@ struct WebURLError;
 }
 
 namespace media {
-class Renderer;
+class RendererFactory;
 struct KeySystemInfo;
 }
 
@@ -257,11 +257,9 @@ class CONTENT_EXPORT ContentRendererClient {
   // Returns true if the page at |url| can use Pepper MediaStream APIs.
   virtual bool AllowPepperMediaStreamAPI(const GURL& url);
 
-  // Allows an embedder to create a media::Renderer. The caller owns the
-  // returned renderer.
-  virtual scoped_ptr<media::Renderer> CreateMediaRenderer(
-      RenderFrame* render_frame,
-      const scoped_refptr<base::SingleThreadTaskRunner>& task_runner);
+  // Allows an embedder to provide a media::RendererFactory.
+  virtual scoped_ptr<media::RendererFactory> GetMediaRendererFactory(

[gunsch, 2014/12/09 04:26:09]

naming nit: I think "Get..." usually implies a single instance, returning a raw
pointer, and ContentRendererClient maintaining ownership; since this is used to
create a new factory with every WMPI (with caller taking ownership), I think
"Create..." is more semantic.

[jam, 2014/12/09 17:14:19]

if this is switched to a factory now, why do we need to create a new factory
each time? seems like the factory should be long lived.

[xhwang, 2014/12/09 18:05:51]

I felt using scoped_ptr makes the lifetime/ownership easier to follow. 

For example, if we have a long lived factory, then we need to make sure the
factory is destroyed after |render_frame| is destructed. I don't see an easy way
to do this now. (Unless we add a RenderFrameDeleted() call in this interface?)

Also, we have other places a RendererFactory could be created (e.g. in
RenderFrameImpl). In that case, if we pass along a raw pointer (instead of a
scoped_ptr), we also need to manage the lifetime of that RendererFactory
instance so that it will outlive the consumer of the RendererFactory.

Another option is to use scoped_refptr, which will solve all the issues above.
But in media code we like to avoid scoped_refptr unless necessary, because
scoped_refptr makes it even harder to track the lifetime of an object.

Last, typically the RendererFactory implementation is a pretty small class. So
allocating one for each call shouldn't be a big problem performance-wise...

Let me know what you think of it. Thanks!

[xhwang, 2014/12/09 18:05:52]

Done.

[jam, 2014/12/10 20:14:46]

Is this factory per render frame? or is there one factory per renderer process?
It seems the latter? if so, then we don't need to worry about lifetime.
well in general, factories in the renderer process live for the lifetime of the
process so raw pointer is fine.

[xhwang, 2014/12/10 20:22:54]

For now, the factory is per render frame. We may be able to get rid of it in the
future, but not now.
ditto

+      RenderFrame* render_frame);
 
   // Gives the embedder a chance to register the key system(s) it supports by
   // populating |key_systems|.