Add media Remoter mojo interface and RendererWMPDelegate accessor.

media/mojo/interfaces/remoter.mojom

+// Copyright 2016 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.
+
+module media.mojom;
+
+interface Remoter {

[Ken Rockot(use gerrit already), 2016/07/27 22:31:15]

Rather than use a client ID, an idiomatic design would have a unique Remoter
pipe per client. In this model, your interfaces could look more like:

interface RemoterProvider {
  GetRemoter(Remoter& request, RemoterClient client);
};

interface PipeControl {
  // Assuming the signature here is wrong, but I'm mimicking
  // SendBufferToRemote from your CL
  ForwardBufferToRemote(int32 num_bytes);

  DiscardPendingBuffers();
};

interface Remoter {
  // NOTE: need for Deregister() - the client can simply close its
  // Remoter pipe to signal that it's done using it. The impl side
  // can trivially detect this and treat it as a deregistration.

  // Any reason for the pipe handles to really be optional?
  // Also the impl could signal failure by simply closing the Remoter
  // pipe and the client can detect this. There's usually no need for
  // a bool "success/fail" reply.
  StartMedia(handle<data_pipe_consumer> audio_pipe,
             PipeControl& audio_pipe_control,
             handle<data_pipe_consumer> video_pipe,
             PipeControl& video_pipe_control);
  StopMedia(string? reason);

  SendMessageToRemote(array<uint8> message);
};

// RemoterClient looks good as-is

[miu, 2016/09/02 22:13:29]

Great ideas. I reworked the Mojo interfaces here pretty much as you suggested
(and there were some other name/interface changes made in the meantime too).
Suffice it to say, I've eliminated all the use of IDs.

+  // Register a new client that is to be notified when remote media services are
+  // available/gone, and for lifecycle events. The caller provides a distinct
+  // |client_id| to reference the client. More than one client may exist.
+  RegisterClient(uint32 client_id, RemoterClient client);

[DaleCurtis, 2016/07/27 21:09:59]

Mojo is typically a way to avoid needing id's like this. RemoterClient can
already be uniquely identified implicitly via |client| without the id I thought?

[miu, 2016/09/02 22:13:29]

Done. (See reply to rockot's comment above.)

+
+  // Called to notify the Remoter that the client has gone away.
+  DeregisterClient(uint32 client_id);
+
+  // Called to start remote media services. If |success| is true in the result,
+  // calls to SendMessageToRemote() and SendBufferToRemote() can be made, and
+  // any messages from the remote will be forwarded back to the client via
+  // RemoterClient.OnMessageFromRemote().
+  //
+  // |audio_pipe| and |video_pipe| provide handles to the consumer end of a data
+  // pipe. These data pipes are used for the transport of the demuxed bitstream
+  // data. The Remoter is instructed to read from these pipes and send the
+  // bitstream data to the remote whenever SendBufferToRemote() is called.
+  StartMediaServices(uint32 client_id,
+                     handle<data_pipe_consumer>? audio_pipe,
+                     handle<data_pipe_consumer>? video_pipe) =>
+      (bool success, uint32 audio_pipe_id, uint32 video_pipe_id);

[DaleCurtis, 2016/07/27 21:09:59]

Again, generally we should be able to avoid ids by returning actual objects.

+
+  // Called to stop remote media services. Messages in both directions will be
+  // dropped after this point, and the consumer end of the data pipes passed to
+  // StartMediaServices() will be closed. If the optional |error_reason| is
+  // missing, this is a normal stop command; otherwise, |error_reason| contains
+  // a human-readable string indicating the failure(s) that forced remoting to
+  // be stopped.
+  StopMediaServices(uint32 client_id, string? error_reason);
+
+  // Forward |message| to the remote endpoint. |message| is a serialized
+  // protobuf from src/media/remoting/remoting.proto.
+  SendMessageToRemote(uint32 client_id, array<uint8> message);
+
+  // Forward |buffer| to the remote endpoint. Before this is called, the client
+  // must write |num_bytes| bytes into one of the data pipes. |pipe_id| selects
+  // which data pipe will be read from.
+  SendBufferToRemote(uint32 client_id, uint32 pipe_id, uint32 num_bytes);
+
+  // Discard all buffers currently queued for sending to the remote. This is
+  // used to optimize seeking.
+  DiscardPendingBuffers(uint32 client_id, uint32 pipe_id);
+};
+
+interface RemoterClient {
+  // Called to notify the client that remote media services are now
+  // available. The client will decide whether/when to begin remoting, and later
+  // will call Remoter.StartMediaServices() to initiate that.
+  //
+  // TODO(miu): In a later change, also pass information about the remote's
+  // capabilities (e.g., codec support, DRM keysystem support, etc.).
+  OnRemoteServicesAvailable();
+
+  // Called to notify the client the remote media services are no longer
+  // available. Note that this is different from OnMediaServicesStopped() in
+  // that it does not indicate active remoting of media services has been
+  // stopped.
+  OnRemoteServicesGone();
+
+  // Called while remoting is active to pass a |message| from the remote media
+  // services back to the local media stack. The |message| consists of a
+  // serialized protobuf from src/media/remoting/remoting.proto.
+  OnMessageFromRemote(array<uint8> message);
+
+  // Called when remote media services have terminated. This may or may not be a
+  // response to a Remoter::StopMediaServices() call, as external events may
+  // have caused remoting to end. If |error_reason| is present, this indicates
+  // remoting was ended due to a fatal error and the string provides a
+  // human-readable reason message.
+  OnMediaServicesStopped(string? error_reason);
+};