media: scaffolding and plumbing for MojoRenderer{Impl, Service}

media/mojo/interfaces/media_types.mojom

 // 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.
 
 module mojo {
 
+// See media/base/buffering_state.h for descriptions.
+// Kept in sync with media::BufferingState via COMPILE_ASSERTs.

[scherkus (not reviewing), 2014/09/09 20:35:32]

mojo development question: is it perhaps better to use mojo for defining enums
once instead of keeping copies? it creates a dependency on mojo IDL ... but
seems like less maintenance

this would be similar to using protobufs for creating simple POD classes instead
of writing a lot of boilerplate code

[tim (not reviewing), 2014/09/10 23:08:28]

I asked an analogous question to mojo-dev about structs here,
https://groups.google.com/a/chromium.org/d/msg/mojo-dev/DeyYqV2wvVA/qp0H0Sc9visJ

I agree it's a burden to keep both in sync. But from that thread I kind of got
the impression that using mojom types in client code, while supported, wasn't
really the goal or intent. It's more cumbersome for structs, though, so perhaps
for enums it makes sense. In general I think it's up to the client (media in
this case) and not mojo... but I would caution the desire to change everything
over right now given that this mojo stuff is very much experimental...

 enum BufferingState {
-  // Indicates that there is no data buffered.
-  //
-  // Typical reason is data underflow and hence playback should be paused.
   HAVE_NOTHING,
+  HAVE_ENOUGH,
+};
 
-  // Indicates that enough data has been buffered.
-  //
-  // Typical reason is enough data has been prerolled to start playback.
-  HAVE_ENOUGH,
+// See media/base/audio_decoder_config.h for descriptions.
+// Kept in sync with media::AudioCodec via COMPILE_ASSERTs.
+enum AudioCodec {
+  UNKNOWN = 0,
+  AAC = 1,
+  MP3 = 2,
+  PCM = 3,
+  Vorbis = 4,
+  FLAC = 5,
+  AMR_NB = 6,
+  AMR_WB = 7,
+  PCM_MULAW = 8,
+  GSM_MS = 9,
+  PCM_S16BE = 10,
+  PCM_S24BE = 11,
+  Opus = 12,
+  // EAC3 = 13,
+  PCM_ALAW = 14,
+  MAX = PCM_ALAW,
+};
+
+// See media/base/channel_layout.h for descriptions.
+// Kept in sync with media::ChannelLayout via COMPILE_ASSERTs.
+// TODO(tim): The bindings generators will always prepend the enum name, should
+// mojom therefore allow enum values starting with numbers?

[scherkus (not reviewing), 2014/09/09 20:35:32]

good question ... yeah this seems kind of gross

+enum ChannelLayout {
+  k_NONE = 0,
+  k_UNSUPPORTED = 1,
+  k_MONO = 2,
+  k_STEREO = 3,
+  k_2_1 = 4,
+  k_SURROUND = 5,
+  k_4_0 = 6,
+  k_2_2 = 7,
+  k_QUAD = 8,
+  k_5_0 = 9,
+  k_5_1 = 10,
+  k_5_0_BACK = 11,
+  k_5_1_BACK = 12,
+  k_7_0 = 13,
+  k_7_1 = 14,
+  k_7_1_WIDE = 15,
+  k_STEREO_DOWNMIX = 16,
+  k_2POINT1 = 17,
+  k_3_1 = 18,
+  k_4_1 = 19,
+  k_6_0 = 20,
+  k_6_0_FRONT = 21,
+  k_HEXAGONAL = 22,
+  k_6_1 = 23,
+  k_6_1_BACK = 24,
+  k_6_1_FRONT = 25,
+  k_7_0_FRONT = 26,
+  k_7_1_WIDE_BACK = 27,
+  k_OCTAGONAL = 28,
+  k_DISCRETE = 29,
+  k_STEREO_AND_KEYBOARD_MIC = 30,
+  k_MAX = k_STEREO_AND_KEYBOARD_MIC
+};
+
+// See media/base/sample_format.h for descriptions.
+// Kept in sync with media::SampleFormat via COMPILE_ASSERTs.
+enum SampleFormat {
+  UNKNOWN = 0,
+  U8,
+  S16,
+  S32,
+  F32,
+  PlanarS16,
+  PlanarF32,
+  Max = PlanarF32,
+};
+
+// This defines a mojo transport format for media::AudioDecoderConfig.
+// See media/base/audio_decoder_config.h for descriptions.
+struct AudioDecoderConfig {
+  AudioCodec codec;
+  SampleFormat sample_format;
+  ChannelLayout channel_layout;
+  int32 samples_per_second;
+  uint8[]? extra_data;
+  int64 seek_preroll_usec;
+  int32 codec_delay;
 };

[xhwang, 2014/09/10 00:00:52]

I understand these are required to serialize a media::AudioDecoderConfig through
mojo MessagePipe. But this looks like a LOT of boilerplate code to me (see all
the ASSERT_ENUM_EQ code below).

Can we support a mode where the class itself (e.g. media::AudioDecoderConfig)
provides it's own way of serializing and deserializing, so that we don't need to
redefine a lot of stuff in mojo?

[tim (not reviewing), 2014/09/10 23:08:28]

Hm, well, the only real point to using mojo is that you get serialization /
deserialization and IPC for free.  I think in the future it might make sense (as
Andrew alluded to above) to use mojo enums as the truth and maybe in some cases
structs. But note even here, |extra_data| will generate a mojo::Array. Although
mojo::Array was made to be mostly interchangeable with std::vector, this still
has implications on the surrounding code... so I might advise waiting for dust
to settle a bit more before deciding on a unified format.

 
 // This defines a mojo transport format for media::DecoderBuffer.
 struct MediaDecoderBuffer {
   // See media/base/buffers.h for details.
   int64 timestamp_usec;
   int64 duration_usec;
 
   // The number of bytes in |data|.
   uint32 data_size;
 
@@ skipping 10 matching lines @@
   int64 splice_timestamp_usec;
 
   // The payload.
   // TODO(tim): This currently results in allocating a new, largeish DataPipe
   // for each buffer. Remove this once framed data pipes exist, but using this
   // for now for prototyping audio.
   handle<data_pipe_consumer> data;
 };
 
 }  // module mojo