Mojom updates for Motown.

mojo/services/media/control/interfaces/media_player.mojom

Index: mojo/services/media/control/interfaces/media_player.mojom
diff --git a/mojo/services/media/control/interfaces/media_player.mojom b/mojo/services/media/control/interfaces/media_player.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..f2497c0fd4afa2fd7229c1bdc06aaf2dbb82a806
--- /dev/null
+++ b/mojo/services/media/control/interfaces/media_player.mojom
@@ -0,0 +1,37 @@
+// Copyright 2015 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.
+
+[DartPackage="mojo_services"]
+module mojo.media;
+
+import "mojo/services/media/common/interfaces/media_metadata.mojom";
+import "mojo/services/media/common/interfaces/media_state.mojom";
+import "mojo/services/media/common/interfaces/rate_control.mojom";
+
+// Plays media.
+interface MediaPlayer {
+  // Starts playback.
+  Play();
+
+  // Pauses playback.
+  Pause();

[johngro, 2015/12/10 21:46:03]

Shouldn't the player expose a RateControl interface instead?  We could keep
these around as convince methods, but it seems like the underlying mechanism for
rate control should be a rate control interface.

This is a design question; no action is requested here.  Let's put it on the
list of stuff to discuss moving forward.

[dalesat, 2015/12/10 22:33:38]

Yes, rate control isn't supported yet.

+
+  // Gets the status. To get the status immediately, call GetStatus(0). To
+  // get updates thereafter, pass the version sent in the previous callback.
+  GetStatus(uint64 version_last_seen) =>
+      (uint64 version, MediaPlayerStatus status);
+};
+
+// MediaPlayer status information.
+struct MediaPlayerStatus {
+  // Current state of the player.
+  MediaState state;
+
+  // Transform translating local time to presentation time. Reverse translation

[johngro, 2015/12/10 21:46:03]

presentation time == media time?  I'm confused because, in my mind, presentation
time is a property of a piece of media, not a timeline.  IOW - this frame of
video is presented at time X on the media timeline.  Because of current clock
transformations, that means it will be presented at time Y on the local
timeline, or time Z on the GPS timeline, and so on...

[dalesat, 2015/12/10 22:33:38]

Sounds like we need to revisit timeline terminology again. I thought there were
objections to 'media time'. I tend to use the term 'time' to mean 'timeline' as
in this comment. My problem with 'presentation timeline' was that media isn't
always presented in a given scenario. I came around to being OK with that with
the understanding that media is intended to be presented, whether it's actually
presented in a given scenario or not.

+  // (presentation time to local time) is only valid when media is playing.
+  TimelineTransform? timeline_transform;
+
+  // Describes the media.
+  MediaMetadata? metadata;
+};