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

services/media/framework/parts/reader.h

Index: services/media/framework/parts/reader.h
diff --git a/services/media/framework/parts/reader.h b/services/media/framework/parts/reader.h
new file mode 100644
index 0000000000000000000000000000000000000000..991a6c700ef875c631683325c5bfad8ef8fe3d7b
--- /dev/null
+++ b/services/media/framework/parts/reader.h
@@ -0,0 +1,53 @@
+// 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_PARTS_READER_H_
+#define SERVICES_MEDIA_FRAMEWORK_PARTS_READER_H_
+
+#include <memory>
+
+#include "services/media/framework/result.h"
+#include "url/gurl.h"
+
+namespace mojo {
+namespace media {
+
+class Reader;
+
+typedef std::shared_ptr<Reader> ReaderPtr;
+
+// Abstract base class for objects that read raw data on behalf of demuxes.
+// This model is synchronous, because that's how ffmpeg works.

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

Is ffmpeg going to be the only client of this interface?

I sort of feel like synchronous I/O is going to be actively harmful to the
pipeline.  So although individual codecs might expect to be able to pull content
using some kind of synchronous API, ultimately the input to that codec should be
driven asynchronously through a suitable adaptation layer.

As you're building this, remember that everything is going to be coming from
some other process over IPC.  There probably won't be a local filesystem or
anything.  To make sure you're ready for that, I'd recommend ripping most of
this out in the near future and using the network service to open up URLs and
get data pipes and whatever else you need.

In other words, I don't see this Reader class as embodying a truly essential
concern of your pipeline.  Maybe it's more of a helper for shimming synchronous
input over asynchronous channels but I would hope that that is kind of rare...

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

I agree. There are comments to this effect elsewhere and TODOs to resolve it.

+class Reader {
+ public:
+  // Creates a Reader object for a given url.
+  static Result Create(const GURL& gurl, ReaderPtr* reader_out);
+
+  virtual ~Reader() {}
+
+  // Initializes the reader.
+  virtual Result Init(const GURL& gurl) = 0;
+
+  // Reads the given number of bytes into the buffer and returns the number of
+  // bytes read. Returns -1 if the operation fails.
+  virtual int Read(uint8* buffer, int bytes_to_read) = 0;

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

Use size_t or ssize_t for buffer sizes, etc.

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

Done in another CL.

+
+  // Gets the current position or -1 if the operation fails.
+  virtual int64 GetPosition() const = 0;

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

Don't you mean int64_t?

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

Yes. Done.

+
+  // Seeks to the given position and returns it. Returns -1 if the operation
+  // fails.
+  virtual int64 SetPosition(int64 position) = 0;
+
+  // Returns the file size. Returns -1 if the operation fails.
+  virtual int64 GetSize() const = 0;

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

What if the size isn't known?

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

Added to comment.

+
+  // Returns true if this object supports seeking, false otherwise.
+  virtual bool CanSeek() const = 0;
+};
+
+}  // namespace media
+}  // namespace mojo
+
+#endif // MOJO_SERVICES_MEDIA_READER_H_