Implement googContentType GetStats metric reported on receive side.

webrtc/call/video_receive_stream.h

 /*
  *  Copyright (c) 2013 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
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 69 matching lines @@
     rtc::Optional<uint64_t> qp_sum;
 
     int current_payload_type = -1;
 
     int total_bitrate_bps = 0;
     int discarded_packets = 0;
 
     int width = 0;
     int height = 0;
 
+    // "screen" vs "realtime".

[tommi, 2017/08/30 15:03:27]

if these are fixed constants, can we use const char* instead of allocating
memory and make construction/destruction slightly more complex?  Alternatively,
can this be an enum?

[ilnik, 2017/08/30 15:30:24]

Enum is absolutely not suitable here, as we want it to be flexible. Also,
another enum for ContentType is annoying.

char* is problematic for the same reasons. What if we decide to put additional
information in here (like simulcast layers and experiment id).

[tommi, 2017/08/30 17:54:42]

Since stats gathering is a notoriously performance sensitive process, can you
clarify what you mean with 'annoying'? :)

Does it cause problems at the upper javascript layers?  In my mind, it would be
much less desirable to have to compare a string in chrome to some other
definition of "screen" vs "realtime" vs whatever else might be introduced. 
Further still, if one value gets removed or modified, it would be much better to
catch that as a build break rather than a string mismatch that silently makes it
into production.  And then there are cycles, locks and code bytes to consider :)

[ilnik, 2017/08/30 18:12:18]

If we introduce a second enum, it will be quite error prone to add new values to
all the relevant enums and there's a copy-paste. If we use a content type enum
from api/video_codecs it's a strange dependency we will need to put both in pc
and ortc. 

Finally, old GetStats is ultimately reporting all values as strings. This means,
that string conversion will still happen at the end. By using enums here we will
just delay that to the later moment. But now, at the cost of a single additional
string copy at each GetStats call (at most 10 calls per second in some
experiments. Default is 0.1 call per second) I get a code, arguably easier to
maintain. This is mainly because if i decide to change something about the
content type reporting value, all the changes will be contained in the
ReceiveStatisticsProxy, which my team is responsible for and it will be fast and
easy to make them.

[tommi, 2017/08/31 07:28:48]

Sorry for being slow but I'm still not fully underrstanding. Does "all the
relevant enums" mean individual values in the enumeration or other enum types?
Would it not be possible to have an enum type at the same place as "screen" and
"realtime" are today?

If it's a requirement that multiple values need to be encoded in the string,
then I'm wondering if this is the appropriate representation. Ideally these
values should eventually be standardized so we should not be adding/removing
'goog' stats without thinking those things through. This affects code and
databases in many places.
The old getStats API is being removed partially because of excessive string
copying and lack of strong types.

[ilnik, 2017/08/31 07:51:11]

Ok, I've made it enum everythere. Converting to string code now is in the
api/video_content_type.cc. I sure don't want to introduce another enum for
content type.

Again, main reason i wanted to leave it as a string was that all the logic was
in the place it could be easy modify later. Maybe it's too selfish. Of course,
quality of codebase is more important here.

+    std::string content_type;
+
     int sync_offset_ms = std::numeric_limits<int>::max();
 
     uint32_t ssrc = 0;
     std::string c_name;
     StreamDataCounters rtp_stats;
     RtcpPacketTypeCounter rtcp_packet_type_counts;
     RtcpStatistics rtcp_stats;
   };
 
   struct Config {
@@ skipping 141 matching lines @@
   virtual void AddSecondarySink(RtpPacketSinkInterface* sink) = 0;
   virtual void RemoveSecondarySink(const RtpPacketSinkInterface* sink) = 0;
 
  protected:
   virtual ~VideoReceiveStream() {}
 };
 
 }  // namespace webrtc
 
 #endif  // WEBRTC_CALL_VIDEO_RECEIVE_STREAM_H_