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

services/media/framework/parts/file_reader.h

Index: services/media/framework/parts/file_reader.h
diff --git a/services/media/framework/parts/file_reader.h b/services/media/framework/parts/file_reader.h
new file mode 100644
index 0000000000000000000000000000000000000000..e8ba73483e97e933d9dc511f72ea1c751b081f7c
--- /dev/null
+++ b/services/media/framework/parts/file_reader.h
@@ -0,0 +1,44 @@
+// 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_FILE_READER_H_
+#define SERVICES_MEDIA_FRAMEWORK_PARTS_FILE_READER_H_
+
+#include "services/media/framework/parts/reader.h"
+
+namespace mojo {
+namespace media {
+
+class FileReader : public Reader {
+ public:
+  static ReaderPtr New() {
+    return ReaderPtr(new FileReader());
+  }
+
+  ~FileReader() override;
+
+  // Reader implementation.
+  Result Init(const GURL& gurl) override;
+
+  int Read(uint8* buffer, int bytes_to_read) override;
+
+  int64 GetPosition() const override;
+
+  int64 SetPosition(int64 position) override;
+
+  int64 GetSize() const override;
+
+  bool CanSeek() const override;
+
+ private:
+  FileReader() {}
+
+  FILE* file_;

[johngro, 2016/01/26 01:32:39]

I don't think that we should be using stdio FILE structure here.  If we are
going to continue to use them here, we should probably bury that fact using a
FileReader/FileReaderImpl pattern (where FileReaderImpl is declared in the .cc
file)

In general, I think we really want to...

1) be designing our classes to use the underlying Mojo services for things like
files and network access.
2) Design all of our I/O classes with an async IO model in mind, not a
synchronous one.

There are multiple ways to fake out ffmpeg's transport interfaces if we go this
route.  The simplest way would be to use a mojo service to get a data pipe and
then just use the data pipe in a synchronous.  There are other ways (which
usually involve a dedicated thread) to fake out ffmpeg so it feels that it is
accessing data synchronously when it is actually async underneath at the
transport implementation level.

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

Right...future CL?

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

Acknowledged.

Sure, please file a tracking issue or something so that it does not become
forgotten.

[dalesat, 2016/02/01 23:01:28]

Acknowledged.

+  int64 size_;
+};
+
+}  // namespace media
+}  // namespace mojo
+
+#endif // SERVICES_MEDIA_FRAMEWORK_PARTS_FILE_READER_H_