Add content type information to encoded images and corresponding rtp extension header

webrtc/api/video/video_content_type.h

Index: webrtc/api/video/video_content_type.h
diff --git a/webrtc/test/constants.h b/webrtc/api/video/video_content_type.h
similarity index 58%
copy from webrtc/test/constants.h
copy to webrtc/api/video/video_content_type.h
index 1b5b0cb1050089ce062232b4ce597408856513f4..8091fbaf2a1dc23356ca1522c52545c6d073d1a6 100644
--- a/webrtc/test/constants.h
+++ b/webrtc/api/video/video_content_type.h
@@ -1,5 +1,5 @@
 /*
- *  Copyright (c) 2015 The WebRTC project authors. All Rights Reserved.
+ *  Copyright (c) 2017 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
@@ -8,12 +8,16 @@
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
+#ifndef WEBRTC_API_VIDEO_VIDEO_CONTENT_TYPE_H_
+#define WEBRTC_API_VIDEO_VIDEO_CONTENT_TYPE_H_
+
 namespace webrtc {
-namespace test {
 
-extern const int kTOffsetExtensionId;
-extern const int kAbsSendTimeExtensionId;
-extern const int kTransportSequenceNumberExtensionId;
-extern const int kVideoRotationExtensionId;
-}  // namespace test
+enum class VideoContentType {
+  kDefault = 0,

[nisse-webrtc, 2017/04/03 12:07:18]

If these are the numerical values that are intended to go onto the wire, I think
that deserves a comment. Or maybe the on-the-wire values should be defined
elsewhere.

I think it would be good to think a bit more about what types make sense and
what they mean. "kDefault" doesn't make much sense to me. I think something like
kUnknown, kCameraFeed, kScreenshare would make more sense. And "unknown" could
be represented with extension absent.

And then, what content type should we have for a screenshare capturing a live
camera?

Or if we intend this to be used only for stats, we don't need to specify any
semantics, the sending endpoint could just set distinct numerical values for
whatever types of content they like to separate in the stats.

[ilnik, 2017/04/03 14:03:42]

These are intended only for stats. Some kind of values are chosen because they
have to be fixed explicitly at end-points. kDefault makes sense, as unspecified
content type. It's set like that if no extension is present. It means: not
separated in a different prefix in UMA. Maybe kUnspecified may be better?

[ilnik, 2017/04/05 11:24:16]

Nisse, so, what are you thoughts on that? Should I rename kDefault to
kUnspecified?

[nisse-webrtc, 2017/04/05 11:46:36]

On the wire, would it make sense to represent "unspecified" as an absent
extension? Then change from screenshare to non-screenshare would be a key frame
with the extension missing.

For the enum, I prefer kUnspecified or kUnknown over kDefault.

[ilnik, 2017/04/05 11:58:02]

It makes sense to not send the extension for unspecified content_type. I will
change that shortly. I will also rename the first value in the enum. However, we
still need this value in the enum, because something have to be stored in the
encoded_image. Having there a separate flag would be a bad design. Also, for the
future, there is 1-byte value sent in the extension. That's in case we will add
additional content types in the future. And also I don't think it will work with
0 value bytes in the extension.

[danilchap, 2017/04/05 12:16:52]

Yes, it is not possible to send extension of size 0.

+  kScreenshare = 1,
+};
+
 }  // namespace webrtc
+
+#endif  // WEBRTC_API_VIDEO_VIDEO_CONTENT_TYPE_H_