Cast: Provide more meaningful stats.

media/cast/logging/proto/raw_events.proto

 // Copyright 2014 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.
 
 // Protocol for audio messages.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
@@ skipping 33 matching lines @@
   VIDEO_PACKET_SENT_TO_PACER = 20;
   AUDIO_PACKET_SENT_TO_NETWORK = 21;
   VIDEO_PACKET_SENT_TO_NETWORK = 22;
   AUDIO_PACKET_RETRANSMITTED = 23;
   VIDEO_PACKET_RETRANSMITTED = 24;
   // Receiver-side packet events.
   AUDIO_PACKET_RECEIVED = 25;
   VIDEO_PACKET_RECEIVED = 26;
   DUPLICATE_AUDIO_PACKET_RECEIVED = 27;
   DUPLICATE_VIDEO_PACKET_RECEIVED = 28;
+  // Sender-side generic event.
+  AUDIO_RTCP_PACKET_RECEIVED = 29;
+  VIDEO_RTCP_PACKET_RECEIVED = 30;
 }
 
 // Each log will contain one |LogMetadata|.
 message LogMetadata {
   // |true| if the events are related to audio. |false| if they are related to
   // video.
   optional bool is_audio = 1;
 
   // Used as a reference for all event entries.
   // i.e. the original RTP timestamp for each event will be
   // |first_rtp_timestamp| + |relative_rtp_timestamp|.
   optional uint32 first_rtp_timestamp = 2;
 
   // Number of AggregatedFrameEvent's.
   optional int32 num_frame_events = 3;
 
   // Number of AggregatedPacketEvent's.
   optional int32 num_packet_events = 4;
 
   // The internal timestamp value in milliseconds that represents the time
   // of the Unix epoch. This is used for relating the timestamps in the events
   // to a real time and date.
   optional int64 reference_timestamp_ms_at_unix_epoch = 5;

[miu, 2014/04/18 00:02:03]

For reasons given in my comments for stats_event_subscriber.h/.cc, I'm concerned
that the precision of all these time values is in milliseconds and not
microseconds.  Seems like we're throwing away significant precision here.

[imcheng, 2014/04/18 18:20:27]

For raw events, we are sacrificing precision of timing of events in return for a
significant savings in space (30%) due to variable length encoding in proto and
possibly difference encoding achieving better results in the gzip algorithm. It
is a tradeoff I made in order to have more logs under the size limit.

When we start uploading stats, we can use it (which have better precision) to
complement the raw events in generating certain graphs / summary in the backend.
A frame-level timeline will use raw events and will have millisecond precision.

 }
 
 message AggregatedFrameEvent {
   optional uint32 relative_rtp_timestamp = 1;
 
   repeated EventType event_type = 2 [packed = true];
   
   // The internal timestamp value in milliseconds. Use
   // LogMetadata.reference_timestamp_ms_at_unix_epoch to relate to a real time
   // and date.
@@ skipping 17 matching lines @@
   // LogMetadata.reference_timestamp_ms_at_unix_epoch to relate to a real time
   // and date.
   repeated int64 event_timestamp_ms = 3 [packed = true];
 }
 
 message AggregatedPacketEvent {
   optional uint32 relative_rtp_timestamp = 1;
   repeated BasePacketEvent base_packet_event = 2;
 };