2023-01-30 10:51:01 +00:00
|
|
|
<!-- go/cmark -->
|
|
|
|
|
<!--* freshness: {owner: 'terelius' reviewed: '2021-06-02'} *-->
|
2021-06-03 10:19:17 +02:00
|
|
|
|
2023-01-30 10:51:01 +00:00
|
|
|
# RTC event log
|
2023-01-26 20:18:46 +00:00
|
|
|
|
2021-06-03 10:19:17 +02:00
|
|
|
## Overview
|
|
|
|
|
|
|
|
|
|
RTC event logs can be enabled to capture in-depth inpformation about sent and
|
|
|
|
|
received packets and the internal state of some WebRTC components. The logs are
|
|
|
|
|
useful to understand network behavior and to debug issues around connectivity,
|
|
|
|
|
bandwidth estimation and audio jitter buffers.
|
|
|
|
|
|
|
|
|
|
The contents include:
|
|
|
|
|
|
|
|
|
|
* Sent and received RTP headers
|
|
|
|
|
* Full RTCP feedback
|
|
|
|
|
* ICE candidates, pings and responses
|
|
|
|
|
* Bandwidth estimator events, including loss-based estimate, delay-based
|
|
|
|
|
estimate, probe results and ALR state
|
|
|
|
|
* Audio network adaptation settings
|
|
|
|
|
* Audio playout events
|
|
|
|
|
|
|
|
|
|
## Binary wire format
|
|
|
|
|
|
|
|
|
|
No guarantees are made on the wire format, and the format may change without
|
|
|
|
|
prior notice. To maintain compatibility with past and future formats, analysis
|
|
|
|
|
tools should be built on top of the provided
|
2021-07-22 15:40:44 +00:00
|
|
|
[rtc_event_log_parser.h](https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/logging/rtc_event_log/rtc_event_log_parser.h)
|
2021-06-03 10:19:17 +02:00
|
|
|
|
|
|
|
|
In particular, an analysis tool should *not* read the log as a protobuf.
|
|
|
|
|
|
|
|
|
|
## Visualization
|
|
|
|
|
|
|
|
|
|
Since the logs contain a substantial amount of data, it is usually convenient to
|
|
|
|
|
get an overview by visualizing them as a set of plots. Use the command:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
out/Default/event_log_visualizer /path/to/log_file | python
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This visualization requires matplotlib to be installed. The tool is capable of
|
|
|
|
|
producing a substantial number of plots, of which only a handful are generated
|
|
|
|
|
by default. You can select which plots are generated though the `--plot=`
|
|
|
|
|
command line argument. For example, the command
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
out/Default/event_log_visualizer \
|
|
|
|
|
--plot=incoming_packet_sizes,incoming_stream_bitrate \
|
|
|
|
|
/path/to/log_file | python
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
plots the sizes of incoming packets and the bitrate per incoming stream.
|
|
|
|
|
|
|
|
|
|
You can get a full list of options for the `--plot` argument through
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
out/Default/event_log_visualizer --list_plots /path/to/log_file
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
You can also synchronize the x-axis between all plots (so zooming or
|
|
|
|
|
panning in one plot affects all of them), by adding the command line
|
|
|
|
|
argument `--shared_xaxis`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Viewing the raw log contents as text
|
|
|
|
|
|
|
|
|
|
If you know which format version the log file uses, you can view the raw
|
|
|
|
|
contents as text. For version 1, you can use the command
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
out/Default/protoc --decode webrtc.rtclog.EventStream \
|
|
|
|
|
./logging/rtc_event_log/rtc_event_log.proto < /path/to/log_file
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Similarly, you can use
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
out/Default/protoc --decode webrtc.rtclog2.EventStream \
|
|
|
|
|
./logging/rtc_event_log/rtc_event_log2.proto < /path/to/log_file
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
for logs that use version 2. However, note that not all of the contents will be
|
|
|
|
|
human readable. Some fields are based on the raw RTP format or may be encoded as
|
|
|
|
|
deltas relative to previous fields. Such fields will be printed as a list of
|
|
|
|
|
bytes.
|