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

services/media/framework/conversion_pipeline_builder.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 SERVICES_MEDIA_FRAMEWORK_CONVERSION_PIPELINE_BUILDER_H_
+#define SERVICES_MEDIA_FRAMEWORK_CONVERSION_PIPELINE_BUILDER_H_
+
+#include "services/media/framework/engine.h"
+#include "services/media/framework/packet.h"
+#include "services/media/framework/stream_type.h"
+
+namespace mojo {
+namespace media {
+
+// Attempts to add transforms to the given pipeline to convert in_type to a
+// type compatible with out_type_sets. If it succeeds, returns true, updates
+// *output and delivers the resulting output type via *out_type. If it fails,
+// returns false, sets *out_type to nullptr and leaves *output unchanged.
+bool BuildConversionPipeline(

[johngro, 2016/01/20 00:25:32]

re: style
We are not supposed to be passing mutable references (engine), only const
references.  In theory, we are supposed to pass pointers instead when using
in/out parameters.  Personally, I think that this requirements is silly since
the reference syntax makes it very difficult to misconstrue the intent of the
author and believe that a pointer parameter is optional and may be nullptr.  The
style argument is that C++ provides no way at the invocation site to know if you
are passing a value or a reference.  Either way, we are supposed to shift to a
pointer here instead of a ref.

re: design
It feels like I am missing something here... Why do we need in_type?  It's the
type of output's output stream which is going to be fed into the rest of the
constructed graph, yes?  If so, why do we need to specify it?  Shouldn't it be a
property of the output already?  Is it that the output might support multiple
output types and has not been configured for a particular one yet? 

[dalesat, 2016/01/25 17:47:29]

Regarding references, I understand and will comply. The benefit of using a
pointer for in/out is clear...not so much when the intent is to pass a mutable
object. I haven't disallowed engine copies, but I easily could, in which case
the intent of passing by non-const reference would be clear.

Regarding in_type, Engine knows nothing about StreamTypes, and I want to keep it
that way. The Engine::Part/Input/Output stuff provides no way to interrogate an
output for its type.

[dalesat, 2016/01/25 23:29:37]

Done.

+    const StreamTypePtr& in_type,
+    const StreamTypeSetsPtr& out_type_sets,
+    Engine& engine,
+    Engine::Output* output,
+    StreamTypePtr* out_type);
+
+}  // namespace media
+}  // namespace mojo
+
+#endif // SERVICES_MEDIA_FRAMEWORK_CONVERSION_PIPELINE_BUILDER_H_