Add video-rendering to mojo media pipeline.

media/mojo/services/mojo_renderer_factory.h

 // Copyright 2014 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 MEDIA_MOJO_SERVICES_MOJO_RENDERER_FACTORY_H_
 #define MEDIA_MOJO_SERVICES_MOJO_RENDERER_FACTORY_H_
 
 #include <memory>
 
 #include "base/macros.h"
 #include "media/base/renderer_factory.h"
 #include "media/mojo/interfaces/renderer.mojom.h"
-
-namespace mojo {
-namespace shell {
-namespace mojom {
-class InterfaceProvider;
-}
-}
-}
+#include "mojo/shell/public/interfaces/interface_provider.mojom.h"

[xhwang, 2016/04/12 19:40:37]

Why this change? Don't we prefer forward declaration?

[alokp, 2016/04/19 00:16:07]

restored.

 
 namespace media {
+class GpuVideoAcceleratorFactories;
 
 // The default factory class for creating MojoRendererImpl.
 class MojoRendererFactory : public RendererFactory {
  public:
   explicit MojoRendererFactory(

[xhwang, 2016/04/12 19:40:37]

nit: no explicit

[alokp, 2016/04/19 00:16:07]

Done.

+      GpuVideoAcceleratorFactories* gpu_factories,

[xhwang, 2016/04/12 19:40:37]

You probably want GetGpuFactoriesCB as used in DefaultRendererFactory.

[alokp, 2016/04/19 00:16:07]

I am curious why this callback exists. Does it need to run on a particular
thread? FWIW ContentRendererClient::CreateMediaRendererFactory does not use this
callback - GpuVideoAcceleratorFactories is passed directly.

[xhwang, 2016/04/20 16:58:47]

Good point. It seems this is the reason:

https://chromium.googlesource.com/chromium/src/+/0c2f582f1c68259ea17d2e95141f...

Details: Instead of passing a GpuVideoAcceleratorFactories to the
DefaultRendererFactory, and thus always using the same one for a given
media player instance, pass a getter callback instead. Now
DefaultRendererFactory can get the latest GpuVideoAcceleratorFactories
instance each time a VideoDecoder is constructed.

+sandersd for questions:
- Shall we use the callback for all Renderer implementations?
- Shall we have some comments that clients should always call GetGpuFactories()
to get the latest one if possible?
- Or can we actually hide this in RenderThreadImpl or RenderFrameImpl such that
when we use the factory to do something, we'll always use the latest factory?

[sandersd (OOO until July 31), 2016/04/20 18:50:06]

Any Renderer that needs GpuFactories should use this callback.
Sounds reasonable. The interaction isn't quite as simple as 'always use the
latest', but as used by Renderers that's probably correct.

The precise instructions would be to use the callback for each distinct
'session', where within one session we expect to always use the same GPU channel
/ command buffer.
I don't think that makes sense without a redesign of the whole structure (which
is a good idea, but likely a lot of work).

Notably, the DefaultRenderer only uses the GpuFactories for VDAs, and that will
go away after VDAv2 replaces VDAv1 (could be a while to fully deprecate VDAv1
though).

[xhwang, 2016/04/20 21:33:39]

I guess this is the easiest way to do for now. Can you file a bug so we also fix
other Renderers?
 
What's the definition of a "session"?

Does it make sense to replace GetGpuFactories() with GetGpuFactoriesCreationCB()
so that it won't be misused? Basically I think media/ shouldn't need to worry
about details in GPU.
 
Sadly acked.

[sandersd (OOO until July 31), 2016/04/20 21:48:05]

Sorry, I was imprecise. I believe that in the general case for Renderers, they
just need the result of this callback. RendererFactories, OTOH need to be more
careful.

This is based on the assumption that a single Renderer won't span multiple
"sessions" as discussed below.
As it turns out, media does need to worry about this, because GL contexts can be
lost at any time, and a given factory stops working when that happens. It's
especially bad for zero-copy VDAs, because in those cases we can't just
re-upload the current VideoFrame into a new context.

The precise details are these:
  - After a context loss, you can keep using a factory (and its command buffer)
forever. It just doesn't *do* anything.
  - If you want to have a working factory/command buffer, you need to request a
new one after context loss.
  - The current implementation only recovers from context loss by creating a new
renderer (which happens when resuming from suspend). We don't recover from other
situations yet, but some day we should.

       mojo::shell::mojom::InterfaceProvider* interface_provider);
   ~MojoRendererFactory() final;
 
   std::unique_ptr<Renderer> CreateRenderer(
       const scoped_refptr<base::SingleThreadTaskRunner>& media_task_runner,
       const scoped_refptr<base::TaskRunner>& worker_task_runner,
       AudioRendererSink* audio_renderer_sink,
       VideoRendererSink* video_renderer_sink,
       const RequestSurfaceCB& request_surface_cb) final;
 
  private:
+  GpuVideoAcceleratorFactories* gpu_factories_;
   mojo::shell::mojom::InterfaceProvider* interface_provider_;
 
   DISALLOW_COPY_AND_ASSIGN(MojoRendererFactory);
 };
 
 }  // namespace media
 
 #endif  // MEDIA_MOJO_SERVICES_MOJO_RENDERER_FACTORY_H_