Motown in-proc streaming framework used to implement media services.

services/media/framework/models/active_sink.h

+// 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.
+
+#ifndef MOJO_MEDIA_MODELS_ACTIVE_SINK_H_
+#define MOJO_MEDIA_MODELS_ACTIVE_SINK_H_
+
+#include <memory>
+
+#include "services/media/framework/allocator.h"
+#include "services/media/framework/models/demand.h"
+#include "services/media/framework/packet.h"
+
+namespace mojo {
+namespace media {
+
+// Sink that consumes packets asynchronously.

[jeffbrown, 2016/02/02 05:35:47]

In general it's a little unclear what subclasses must do to implement this
contract.

[dalesat, 2016/02/02 21:46:39]

Yes, we need to provide more guidance for source/sink/transform developers
generally. I'm not prepared to write the manual at this point, given that we'll
probably change our minds about a ew things.

+class ActiveSink {
+ public:
+  using DemandCallback = std::function<void(Demand demand)>;

[jeffbrown, 2016/02/02 05:35:47]

Should this be defined next to Demand?

[dalesat, 2016/02/02 21:46:39]

I don't think so. Its exact signature is a function of what's needed here. It's
a coincidence that we're just passing Demand and nothing else...that could
easily change in the future.

I don't think I would, in general, define an XCallback for a type X adjacent to
the definition of X.

+
+  virtual ~ActiveSink() {}
+
+  // Indicates whether the sink must allocate.
+  virtual bool must_allocate() const = 0;

[jeffbrown, 2016/02/02 05:35:47]

Should be called MustAllocate because this method is virtual so doesn't meet the
special rule regarding property accessors.

[dalesat, 2016/02/02 21:46:39]

In that case, I don't understand the rules. From Google C++ style:

"Functions that are very cheap to call may instead follow the style for variable
names (all lower-case, with underscores between words). The rule of thumb is
that such a function should be so cheap that you normally wouldn't bother
caching its return value when calling it in a loop. A canonical example is an
inline method that just returns one of the class's member variables."

Is the concern that it's a virtual function?

+
+  // The consumer's allocator. Can return nullptr, in which case the default
+  // allocator should be used.
+  virtual Allocator* allocator() = 0;
+
+  // Registers a callback that signals demand asynchronously.
+  virtual void RegisterDemandCallback(DemandCallback demand_callback) = 0;

[jeffbrown, 2016/02/02 05:35:47]

Can there only be one callback?  If so, consider calling this SetDemandCallback.

[dalesat, 2016/02/02 21:46:39]

Done.

+
+  // Initiates demand.
+  virtual void Prime() = 0;
+
+  // Supplies a packet to the sink.
+  virtual Demand SupplyPacket(PacketPtr packet) = 0;
+};
+
+typedef std::shared_ptr<ActiveSink> ActiveSinkPtr;

[jeffbrown, 2016/02/02 05:35:47]

These typedefs are making it very hard to understand ownership semantics at
point of use.

[dalesat, 2016/02/02 21:46:39]

Yes, I've added a TODO elsewhere. I received feedback to the contrary.

+
+}  // namespace media
+}  // namespace mojo
+
+#endif // MOJO_MEDIA_MODELS_ACTIVE_SINK_H_