Add NetEq delay plotting to event_log_visualizer

webrtc/tools/event_log_visualizer/analyzer.h

Index: webrtc/tools/event_log_visualizer/analyzer.h
diff --git a/webrtc/tools/event_log_visualizer/analyzer.h b/webrtc/tools/event_log_visualizer/analyzer.h
index 988f2cb482151aaa87288cf27ef119c7e5f38527..67edcb55c5211a3292de0544ce9dcdc1dc8c2712 100644
--- a/webrtc/tools/event_log_visualizer/analyzer.h
+++ b/webrtc/tools/event_log_visualizer/analyzer.h
@@ -100,6 +100,9 @@ class EventLogAnalyzer {
   void CreateAudioEncoderEnableFecGraph(Plot* plot);
   void CreateAudioEncoderEnableDtxGraph(Plot* plot);
   void CreateAudioEncoderNumChannelsGraph(Plot* plot);
+  void CreateAudioJitterBufferGraph(const std::string& replacement_file_name,
+                                    int file_sample_rate_hz,
+                                    Plot* plot);
 
   // Returns a vector of capture and arrival timestamps for the video frames
   // of the stream with the most number of frames.
@@ -163,6 +166,12 @@ class EventLogAnalyzer {
 
   std::map<StreamId, std::vector<LoggedRtcpPacket>> rtcp_packets_;
 
+  // Maps an SSRC to the timestamps of parsed audio playout events.
+  std::map<uint32_t, std::vector<uint64_t>> audio_playout_events_;
+
+  // Stores the timestamps for all log end events found.
+  std::vector<uint64_t> log_end_events_;

[terelius, 2017/06/09 14:48:36]

std::vector<std::pair<uint64_t, uint64_t>> log_segments;
to store both begin and end times together?

[hlundin-webrtc, 2017/06/12 07:15:08]

I did something, but I'm not sure what assumptions we can make about the order
of these events. For instance, do we know that we always have an alternating
sequence like (start, stop, start, stop, ...), or could we have multiple start
or stop events in sequence? Also, will we always have a start event at the
beginning, and a stop event at the end?

[terelius, 2017/06/13 15:16:26]

Yes, we write a LOG_START event whenever we start logging to file. 
https://cs.chromium.org/chromium/src/third_party/webrtc/logging/rtc_event_log...

We attempt to write a LOG_END event whenever we stop logging to file, but there
is a small risk that the event can't be written if the file is full already.
https://cs.chromium.org/chromium/src/third_party/webrtc/logging/rtc_event_log...

If a second LOG_START or EOF is encountered when LOG_END was expected, I'd
suggest artificially adding a LOG_END with the largest timestamp found so far. I
don't think we need to handle LOG_END without matching LOG_START. WDYT?

[hlundin-webrtc, 2017/06/14 12:09:12]

Done. That seems like a good solution.

+
   // A list of all updates from the send-side loss-based bandwidth estimator.
   std::vector<LossBasedBweUpdate> bwe_loss_updates_;