Cast: IPC glue between cast library transport and encoders.

media/cast/transport/cast_transport_config.h

Index: media/cast/transport/cast_transport_config.h
diff --git a/media/cast/transport/cast_transport_config.h b/media/cast/transport/cast_transport_config.h
index 16ab143b0c738ffdf2d8d7b99b68dbd990b1fa9c..3cc419137f362ce30f4744cbe3b4612409c645b9 100644
--- a/media/cast/transport/cast_transport_config.h
+++ b/media/cast/transport/cast_transport_config.h
@@ -121,7 +121,7 @@ struct RtcpSenderFrameLogMessage {
   uint32 rtp_timestamp;
 };
 
-typedef std::list<RtcpSenderFrameLogMessage> RtcpSenderLogMessage;
+typedef std::vector<RtcpSenderFrameLogMessage> RtcpSenderLogMessage;
 
 struct RtcpSenderInfo {
   RtcpSenderInfo();
@@ -155,6 +155,16 @@ struct RtcpDlrrReportBlock {
   uint32 delay_since_last_rr;
 };
 
+// This is only needed because IPC messages don't support more than
+// 5 arguments.
+struct SendRtcpFromRtpSenderData {
+  SendRtcpFromRtpSenderData();
+  ~SendRtcpFromRtpSenderData();
+  uint32 packet_type_flags;
+  uint32 sending_ssrc;
+  std::string c_name;

[palmer, 2014/02/11 00:50:04]

What is the intended structure of this string?

Can the recipient validate that structure somehow?

[hubbe, 2014/02/12 00:54:24]

Apparently, the CNAME comes from RFC 3550 page 46, and should be on the form
user@host or just host if no user is available. It is generally treated as an
opaque identifier and is never decoded anywhere.

+};
+
 inline bool operator==(RtcpSenderInfo lhs, RtcpSenderInfo rhs) {
   return lhs.ntp_seconds == rhs.ntp_seconds &&
       lhs.ntp_fraction == rhs.ntp_fraction &&