Define EncodedVideoSource and RtcCapturedEncodingVideoCapturer.

media/video/video_encode_types.h

Index: media/video/video_encode_types.h
diff --git a/media/video/video_encode_types.h b/media/video/video_encode_types.h
new file mode 100644
index 0000000000000000000000000000000000000000..b449fe4d2d72f2b018bee961b6e87f85fa30d90b
--- /dev/null
+++ b/media/video/video_encode_types.h
@@ -0,0 +1,51 @@
+// Copyright (c) 2013 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 MEDIA_VIDEO_VIDEO_ENCODE_TYPES_H_
+#define MEDIA_VIDEO_VIDEO_ENCODE_TYPES_H_
+
+#include <map>
+#include <ostream>
+#include <vector>
+
+#include "base/time.h"
+#include "media/base/video_decoder_config.h"
+#include "ui/gfx/size.h"
+
+namespace media {
+
+// Data to represent limitations for a particular encoder config.

[Ami GONE FROM CHROMIUM, 2013/06/08 00:18:01]

We're talking about shipping the EVS stuff on only an extremely narrow set of
platforms.  Do we really need the configurability implied by this file or can we
get away with a much smaller set of predefined configs (possibly just one)?

[hshi1, 2013/06/10 19:12:31]

I don't believe it is adding significant complexity to permit this kind of
configurability. Wouldn't you agree it is a bad idea to hard-coding encode
configs specific to a platform (especially if I can't even mention the specifics
of that platform in codereview)?

[Ami GONE FROM CHROMIUM, 2013/06/10 19:29:32]

This configurability requires in EVS:
Observer
AddCapabilitiesObserver
RemoveCapabilitiesObserver
StartFetchCapabilities
GetCapabilities
along with their attendant IPC surface.  Also, they require an unnecessary IPC
roundtrip.

None of this breaks the bank, I'm just not sure why bother in throwaway code.

+struct VideoEncodingConfig {
+  VideoCodec codec_type;
+  std::string codec_name;
+  gfx::Size max_resolution;
+  int max_frames_per_second;
+  int max_bitrate;
+};
+
+typedef std::vector<VideoEncodingConfig> VideoEncodingCapability;

[Ami GONE FROM CHROMIUM, 2013/06/08 00:18:01]

VideoEncodingCapability is a particularly unintuitive name choice.
Why not simply pluralize the type of which this is a vector of?

[hshi1, 2013/06/10 19:12:31]

Done.

+
+// Encoding parameters that can be configured during streaming without removing
+// the bitstream first.
+struct RuntimeVideoEncodingParameters {
+  int average_bitrate;

[Ami GONE FROM CHROMIUM, 2013/06/08 00:18:01]

s/average/target/?

[hshi1, 2013/06/10 19:12:31]

Done.

+  int max_bitrate;
+};
+
+// Generic video encoding parameters to be configured during initialization
+// time.
+struct VideoEncodingParameters {
+  std::string codec_name;
+  gfx::Size resolution;

[Ami GONE FROM CHROMIUM, 2013/06/08 00:18:01]

Is there a reason why resolution & frames_per_second are not
runtime-configurable?

[hshi1, 2013/06/10 19:12:31]

I have moved the frames_per_second into the runtime-configurable parameters as
you suggested. However, the resolution is probably not runtime-configurable as
it involves re-allocating all reference and decoded picture buffers, so most
likely a resolution change would require tearing down the current bitstream and
creating a new one.

Note that the "runtime configurable parameters" i.e. bitrate and frame rate do
correspond to the SetRates method of a webrtc::VideoEncoder object. Webrtc does
not define any method for dynamic resolution change.

+  int frames_per_second;
+  RuntimeVideoEncodingParameters runtime_params;
+};
+
+struct BufferEncodingMetadata {
+  base::Time timestamp;
+  bool key_frame;
+};
+
+}  // namespace media
+
+#endif  // MEDIA_VIDEO_VIDEO_ENCODE_TYPES_H_