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

services/media/framework/parts/null_sink.cc

Index: services/media/framework/parts/null_sink.cc
diff --git a/services/media/framework/parts/null_sink.cc b/services/media/framework/parts/null_sink.cc
new file mode 100644
index 0000000000000000000000000000000000000000..634808f6271916ab77f424ad70689ce0636fb107
--- /dev/null
+++ b/services/media/framework/parts/null_sink.cc
@@ -0,0 +1,34 @@
+// 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.
+
+#include "services/media/framework/parts/null_sink.h"
+
+namespace mojo {
+namespace media {
+
+NullSink::NullSink() {}
+
+NullSink::~NullSink() {}
+
+bool NullSink::must_allocate() const {
+  return false;
+}
+
+Allocator* NullSink::allocator() {
+  return nullptr;
+}
+
+void NullSink::RegisterDemandCallback(
+    DemandCallback demand_callback) {
+  demand_callback(Demand::kNeutral);

[johngro, 2016/01/26 23:47:29]

You are making a demand callback inside the RegisterDemand call for an
ActiveSink; is this OK?  I thought that the model was that the initial demand
got expressed when the engine called Prime on all of the participants at
startup.

Seems like the demand callback instance should be stored in the sink and called
once during prime.

While we are on the subject, shouldn't ActiveSink have a protected
demand_callback_ member and implement RegisterDemandCallback itself?  The method
could be made virtual if a derived class had custom work to do during the
registration/link-up phase, but it feels like this is really just bookkeeping,
and that any startup actions should take place during Prime.

[dalesat, 2016/01/28 18:49:16]

Good catch re Prime. I missed that when I added Prime to sinks in general. I
accommodate calling the callback in RegisterDemandCallback, but perhaps I
shouldn't.

As for doing this in the base class, we don't know in general when demand should
transition away from kNegative or whether it should transition to kNeutral or
kPositive. If we did know that, I'd rather implement that default behavior in
the stage and leave the model pure virtual. The models are the framework's
contracts with 'part' developers, and the behavior of model implementations
should be entirely the business of those developers.

[johngro, 2016/02/01 22:38:16]

Acknowledged.

+}
+
+void NullSink::Prime() {}
+
+Demand NullSink::SupplyPacket(PacketPtr packet) {
+  return Demand::kNeutral;
+}
+
+} // namespace media
+} // namespace mojo