Update to the RtcEventLog protobuf to remove the DebugEvent message.

Update to the RtcEventLog protobuf to remove the DebugEvent message.

This CL restructures the RtcEventLog protobuf format, by removing the DebugEvent message. This is done by moving the LOG_START and LOG_END events to the EventType enum and making a seperate message for audio playout events. In addition to these changes, some fields were added to the AudioReceiveConfig and AudioSendConfig messages, but these are for future use and are not currently logged yet.

This is a follow-up to CL 1340283002 which adds a SSRC to AudioPlayout events in the RtcEventLog.

BUG=webrtc:4741
R=henrik.lundin@webrtc.org, stefan@webrtc.org, terelius@webrtc.org

Committed: https://crrev.com/301aaed813b55e28c12e89bb58ae8f8d8136c47e
Cr-Commit-Position: refs/heads/master@{#10221}

[ivoc, 2015-09-16 13:17:25]

ivoc@webrtc.org changed reviewers:
+ henrik.lundin@webrtc.org, stefan@webrtc.org, terelius@webrtc.org

[ivoc, 2015-09-16 13:17:25]

ivoc@webrtc.org changed required reviewers:
+ henrik.lundin@webrtc.org, stefan@webrtc.org, terelius@webrtc.org

[ivoc, 2015-09-16 13:24:16]

Hi guys, please have a look at this small follow-up CL to remove the DebugEvent
message from the RtcEventLog protobuf, and add a few fields for audio config for
future use to the protobuf. Thanks!

[hlundin-webrtc, 2015-09-17 13:42:39]

lgtm

[terelius, 2015-09-21 15:18:26]

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.proto
File webrtc/video/rtc_event_log.proto (right):

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:213: // TODO(terelius): Add audio-receive
config.
As far as I am concerned you can remove these TODOs.

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:216: repeated RtpHeaderExtension
header_extensions = 1;
We definitely need ssrc to be able to distinguish the audio streams.

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:219: repeated DecoderConfig decoders = 2;
The encoder/decoder configs are not important to me at the moment. Assuming we
want to keep the AudioXConfigs minimalistic pending the new API and you don't
have any need for it, you might want to remove it.

[ivoc, 2015-09-25 08:02:06]

Sorry for the late reply, got a bit sidetracked by my Tachyon debugging
adventure.

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.proto
File webrtc/video/rtc_event_log.proto (right):

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:213: // TODO(terelius): Add audio-receive
config.
On 2015/09/21 15:18:26, terelius wrote:
> As far as I am concerned you can remove these TODOs.

Done.

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:216: repeated RtpHeaderExtension
header_extensions = 1;
On 2015/09/21 15:18:25, terelius wrote:
> We definitely need ssrc to be able to distinguish the audio streams.

I added some SSRC fields.

https://codereview.webrtc.org/1348113003/diff/1/webrtc/video/rtc_event_log.pr...
webrtc/video/rtc_event_log.proto:219: repeated DecoderConfig decoders = 2;
On 2015/09/21 15:18:26, terelius wrote:
> The encoder/decoder configs are not important to me at the moment. Assuming we
> want to keep the AudioXConfigs minimalistic pending the new API and you don't
> have any need for it, you might want to remove it.

We do want to eventually log that information, but you're right that it's
probably better to hold off for now until the new API is further along.

[terelius, 2015-10-02 09:42:02]

https://codereview.webrtc.org/1348113003/diff/20001/webrtc/video/rtc_event_lo...
File webrtc/video/rtc_event_log.proto (right):

https://codereview.webrtc.org/1348113003/diff/20001/webrtc/video/rtc_event_lo...
webrtc/video/rtc_event_log.proto:226: optional uint32 ssrc = 1;
Could you check if this should be repeated instead of optional? At least for for
video, there is a vector of ssrcs.

[ivoc, 2015-10-05 14:33:14]

https://codereview.webrtc.org/1348113003/diff/20001/webrtc/video/rtc_event_lo...
File webrtc/video/rtc_event_log.proto (right):

https://codereview.webrtc.org/1348113003/diff/20001/webrtc/video/rtc_event_lo...
webrtc/video/rtc_event_log.proto:226: optional uint32 ssrc = 1;
On 2015/10/02 09:42:02, terelius wrote:
> Could you check if this should be repeated instead of optional? At least for
for
> video, there is a vector of ssrcs.

Yes, I checked this with several team members, and it seems like a single SSRC
is sufficient for the audio stream.

[terelius, 2015-10-07 12:07:12]

lgtm

[stefan-webrtc, 2015-10-08 06:49:31]

lgtm

[ivoc, 2015-10-08 07:19:43]

The CQ bit was checked by ivoc@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-08 07:19:49]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1348113003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1348113003/20001

[commit-bot: I haz the power, 2015-10-08 07:20:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-08 07:20:53]

Dry run: Try jobs failed on following builders:
  android_clang_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_clang_dbg/build...)
  android_gn_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/6095)
  android_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_rel/builds/6131)
  ios64_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_dbg/builds/2493)
  ios_arm64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/4795)
  ios_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_dbg/builds/9929)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/8544)
  linux_compile_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_compile_dbg/build...)
  linux_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_gn_rel/builds/5955)
  linux_msan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_msan/builds/5150)
  linux_tsan2 on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_tsan2/builds/7187)
  mac_compile_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_compile_dbg/builds/335)
  mac_compile_x64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_compile_x64_dbg/bui...)
  mac_x64_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_x64_gn_rel/builds/4391)
  mac_x64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_x64_rel/builds/9674)

[ivoc, 2015-10-08 14:05:43]

The CQ bit was checked by ivoc@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-08 14:05:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1348113003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1348113003/40001

[commit-bot: I haz the power, 2015-10-08 16:04:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-08 16:04:19]

Dry run: This issue passed the CQ dry run.

[ivoc, 2015-10-08 16:07:58]

Committed patchset #3 (id:40001) manually as
301aaed813b55e28c12e89bb58ae8f8d8136c47e (presubmit successful).

[commit-bot: I haz the power, 2015-10-08 16:08:02]

Patchset 3 (id:??) landed as
https://crrev.com/301aaed813b55e28c12e89bb58ae8f8d8136c47e
Cr-Commit-Position: refs/heads/master@{#10221}