Add histogram stats for AV sync stream offset:

Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the latest played audio frame is measured per video frame. The average offset per received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493
Committed: https://crrev.com/f8cdd184d5299773dfb16063e8690aa2b5bad3ae
Cr-Commit-Position: refs/heads/master@{#11993}

[åsapersson, 2016-03-04 12:01:01]

Description was changed from

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

BUG=webrtc:5493
==========

to

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

BUG=webrtc:5493
==========

[åsapersson, 2016-03-04 13:16:52]

asapersson@webrtc.org changed reviewers:
+ pbos@webrtc.org, stefan@webrtc.org

[stefan-webrtc, 2016-03-04 14:32:17]

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
File webrtc/call/call_perf_tests.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
webrtc/call/call_perf_tests.cc:166: int64_t stream_offset = latest_audio_ntp -
latest_video_ntp;
If you also wire this new metric up to GetStats() on VideoReceiveStream we
should be able to call GetStats() here instead of accessing the VoEVideoSync
interface which should be hidden.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
webrtc/call/call_perf_tests.cc:387: EXPECT_EQ(1,
test::NumHistogramSamples("WebRTC.Video.AVSyncOffsetInMs"));
Can we also check that the sync offset is reasonable? Or simply wire up the sync
offset to GetStats() and use above, that way we will have a rough idea if it's
correct or not.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.cc:32: return false;
Maybe we should simply move this check into RtpToNtpMs and remove this new
function?

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.h (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.h:49: int64_t GetStreamSyncOffsetInMs(const
VideoFrame& frame);
Would it be reasonable to request a unittest here too?

[pbos-webrtc, 2016-03-04 14:34:28]

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/receive_stat...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/receive_stat...
webrtc/video/receive_statistics_proxy.cc:243:
render_sync_offset_counter_.Add(stream_sync_offset_ms);
Should we expose this in getStats as well?

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.cc:156: TRACE_COUNTER1("webrtc",
"SyncCurrentVideoDelay", current_video_delay_ms);
Can we store and use something based on these three or sync_->ComputeDelays
below? The querying looks complex?

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.h (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.h:48: // the current played out audio frame (or -1
on error).
-1 if not configured/in use?

[stefan-webrtc, 2016-03-04 14:38:55]

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.cc:156: TRACE_COUNTER1("webrtc",
"SyncCurrentVideoDelay", current_video_delay_ms);
On 2016/03/04 14:34:27, pbos-webrtc wrote:
> Can we store and use something based on these three or sync_->ComputeDelays
> below? The querying looks complex?

This is only called periodically, once per second. I think it's better to
compute the "true" sync offset for a frame as done below.

[åsapersson, 2016-03-09 14:22:37]

Patchset #8 (id:140001) has been deleted

[åsapersson, 2016-03-09 14:22:48]

Patchset #7 (id:120001) has been deleted

[åsapersson, 2016-03-09 14:22:55]

Patchset #6 (id:100001) has been deleted

[åsapersson, 2016-03-09 14:23:04]

Patchset #5 (id:80001) has been deleted

[åsapersson, 2016-03-09 14:38:30]

Description was changed from

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

BUG=webrtc:5493
==========

to

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493
==========

[åsapersson, 2016-03-09 15:41:40]

Patchset #7 (id:200001) has been deleted

[åsapersson, 2016-03-09 15:44:35]

PTAL

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
File webrtc/call/call_perf_tests.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
webrtc/call/call_perf_tests.cc:166: int64_t stream_offset = latest_audio_ntp -
latest_video_ntp;
On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> If you also wire this new metric up to GetStats() on VideoReceiveStream we
> should be able to call GetStats() here instead of accessing the VoEVideoSync
> interface which should be hidden.

Done.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
webrtc/call/call_perf_tests.cc:387: EXPECT_EQ(1,
test::NumHistogramSamples("WebRTC.Video.AVSyncOffsetInMs"));
On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> Can we also check that the sync offset is reasonable? Or simply wire up the
sync
> offset to GetStats() and use above, that way we will have a rough idea if it's
> correct or not.

Wired up to and tested through GetStats().

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/receive_stat...
File webrtc/video/receive_statistics_proxy.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/receive_stat...
webrtc/video/receive_statistics_proxy.cc:243:
render_sync_offset_counter_.Add(stream_sync_offset_ms);
On 2016/03/04 14:34:27, pbos-webrtc wrote:
> Should we expose this in getStats as well?

Done.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.cc:32: return false;
On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> Maybe we should simply move this check into RtpToNtpMs and remove this new
> function?

Done.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.cc:156: TRACE_COUNTER1("webrtc",
"SyncCurrentVideoDelay", current_video_delay_ms);
On 2016/03/04 14:38:55, stefan-webrtc (holmer) wrote:
> On 2016/03/04 14:34:27, pbos-webrtc wrote:
> > Can we store and use something based on these three or sync_->ComputeDelays
> > below? The querying looks complex?
> 
> This is only called periodically, once per second. I think it's better to
> compute the "true" sync offset for a frame as done below.

Acknowledged.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.h (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.h:48: // the current played out audio frame (or -1
on error).
On 2016/03/04 14:34:27, pbos-webrtc wrote:
> -1 if not configured/in use?

Done.

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.h:49: int64_t GetStreamSyncOffsetInMs(const
VideoFrame& frame);
On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> Would it be reasonable to request a unittest here too?

I will look into adding unittest for this class. Maybe in a separate CL?

[stefan-webrtc, 2016-03-09 15:59:30]

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
File webrtc/call/call_perf_tests.cc (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/call/call_perf_tes...
webrtc/call/call_perf_tests.cc:387: EXPECT_EQ(1,
test::NumHistogramSamples("WebRTC.Video.AVSyncOffsetInMs"));
On 2016/03/09 15:44:35, åsapersson wrote:
> On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> > Can we also check that the sync offset is reasonable? Or simply wire up the
> sync
> > offset to GetStats() and use above, that way we will have a rough idea if
it's
> > correct or not.
> 
> Wired up to and tested through GetStats().

Thanks a lot!

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
File webrtc/video/vie_sync_module.h (right):

https://codereview.webrtc.org/1756193005/diff/60001/webrtc/video/vie_sync_mod...
webrtc/video/vie_sync_module.h:49: int64_t GetStreamSyncOffsetInMs(const
VideoFrame& frame);
On 2016/03/09 15:44:35, åsapersson wrote:
> On 2016/03/04 14:32:17, stefan-webrtc (holmer) wrote:
> > Would it be reasonable to request a unittest here too?
> 
> I will look into adding unittest for this class. Maybe in a separate CL?

Sure no problem.

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/call/call_perf_te...
File webrtc/call/call_perf_tests.cc (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/call/call_perf_te...
webrtc/call/call_perf_tests.cc:11: #include <limits.h>
Just <limits>

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
File webrtc/video/video_receive_stream.cc (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
webrtc/video/video_receive_stream.cc:385:
stats_proxy_.OnSyncOffsetUpdated(sync_offset_ms);

Nice, thanks!

I wonder if we instead should expose the current playout time in NTP in
GetStats()? In that case it would be possible for the user to compute the sync
offset to any stream, instead of us choosing what (audio) stream to compare with
here. What do you think? I think that is probably a later improvement either
way, since that would require that we implement that stat for audio too...

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
File webrtc/video_receive_stream.h (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
webrtc/video_receive_stream.h:71: int sync_offset_ms = INT_MIN;
std::numeric_limits<int>::max()

[åsapersson, 2016-03-10 09:08:35]

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/call/call_perf_te...
File webrtc/call/call_perf_tests.cc (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/call/call_perf_te...
webrtc/call/call_perf_tests.cc:11: #include <limits.h>
On 2016/03/09 15:59:30, stefan-webrtc (holmer) wrote:
> Just <limits>

Done.

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
File webrtc/video/video_receive_stream.cc (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
webrtc/video/video_receive_stream.cc:385:
stats_proxy_.OnSyncOffsetUpdated(sync_offset_ms);
On 2016/03/09 15:59:30, stefan-webrtc (holmer) wrote:
> 
> Nice, thanks!
> 
> I wonder if we instead should expose the current playout time in NTP in
> GetStats()? In that case it would be possible for the user to compute the sync
> offset to any stream, instead of us choosing what (audio) stream to compare
with
> here. What do you think? I think that is probably a later improvement either
> way, since that would require that we implement that stat for audio too...

Sounds good. Maybe as a later improvement?

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
File webrtc/video_receive_stream.h (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
webrtc/video_receive_stream.h:71: int sync_offset_ms = INT_MIN;
On 2016/03/09 15:59:30, stefan-webrtc (holmer) wrote:
> std::numeric_limits<int>::max()

Done.

[stefan-webrtc, 2016-03-10 14:25:09]

lgtm

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
File webrtc/video/video_receive_stream.cc (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video/video_recei...
webrtc/video/video_receive_stream.cc:385:
stats_proxy_.OnSyncOffsetUpdated(sync_offset_ms);
On 2016/03/10 09:08:35, åsapersson wrote:
> On 2016/03/09 15:59:30, stefan-webrtc (holmer) wrote:
> > 
> > Nice, thanks!
> > 
> > I wonder if we instead should expose the current playout time in NTP in
> > GetStats()? In that case it would be possible for the user to compute the
sync
> > offset to any stream, instead of us choosing what (audio) stream to compare
> with
> > here. What do you think? I think that is probably a later improvement either
> > way, since that would require that we implement that stat for audio too...
> 
> Sounds good. Maybe as a later improvement?

Yes

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
File webrtc/video_receive_stream.h (right):

https://codereview.webrtc.org/1756193005/diff/220001/webrtc/video_receive_str...
webrtc/video_receive_stream.h:71: int sync_offset_ms = INT_MIN;
On 2016/03/10 09:08:35, åsapersson wrote:
> On 2016/03/09 15:59:30, stefan-webrtc (holmer) wrote:
> > std::numeric_limits<int>::max()
> 
> Done.

Or min if you wanted that. I didn't see it was MIN before.

[åsapersson, 2016-03-10 14:40:05]

The CQ bit was checked by asapersson@webrtc.org

[commit-bot: I haz the power, 2016-03-10 14:40:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1756193005/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1756193005/240001

[commit-bot: I haz the power, 2016-03-10 14:42:19]

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

[commit-bot: I haz the power, 2016-03-10 14:42:20]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/4047)

[åsapersson, 2016-03-10 14:47:07]

asapersson@webrtc.org changed reviewers:
+ mflodman@webrtc.org

[åsapersson, 2016-03-10 14:50:57]

On 2016/03/10 14:42:20, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   presubmit on tryserver.webrtc (JOB_FAILED,
> http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/4047)

Adding Magnus for owner approval for webrtc/system_wrappers.

[mflodman, 2016-03-14 08:32:11]

system_wrappers lgtm

[åsapersson, 2016-03-14 08:44:24]

The CQ bit was checked by asapersson@webrtc.org

[commit-bot: I haz the power, 2016-03-14 08:44:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1756193005/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1756193005/240001

[commit-bot: I haz the power, 2016-03-14 08:45:40]

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

[commit-bot: I haz the power, 2016-03-14 08:45:41]

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_compile_x64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x64_dbg...)
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)
  android_gn_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_dbg/builds/9487)
  android_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_gn_rel/builds/9579)
  ios32_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios32_sim_dbg/builds/5928)
  ios64_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_dbg/builds/5919)
  ios_arm64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/8259)
  ios_arm64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_rel/builds/8172)
  ios_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_dbg/builds/13454)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/12085)
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/13194)
  linux_baremetal on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_baremetal/builds/...)
  linux_compile_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_compile_dbg/build...)
  linux_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_rel/builds/13479)
  linux_tsan2 on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_tsan2/builds/10601)
  linux_ubsan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan/builds/482)
  linux_ubsan_vptr on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan_vptr/builds...)
  mac_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_asan/builds/13111)
  mac_baremetal on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/9805)
  mac_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_gn_rel/builds/7799)
  mac_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/13489)
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/4113)

[åsapersson, 2016-03-14 09:15:29]

The CQ bit was checked by asapersson@webrtc.org

[åsapersson, 2016-03-14 09:15:30]

The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org,
mflodman@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1756193005/#ps260001 (title:
"rebase")

[commit-bot: I haz the power, 2016-03-14 09:15:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1756193005/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1756193005/260001

[commit-bot: I haz the power, 2016-03-14 09:32:03]

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

[commit-bot: I haz the power, 2016-03-14 09:32:05]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/4114)

[åsapersson, 2016-03-14 09:51:19]

The CQ bit was checked by asapersson@webrtc.org

[åsapersson, 2016-03-14 09:51:20]

The patchset sent to the CQ was uploaded after l-g-t-m from stefan@webrtc.org,
mflodman@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1756193005/#ps280001 (title:
"mark constructor explicit")

[commit-bot: I haz the power, 2016-03-14 09:51:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1756193005/280001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1756193005/280001

[commit-bot: I haz the power, 2016-03-14 11:55:43]

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

[commit-bot: I haz the power, 2016-03-14 11:55:45]

Try jobs failed on following builders:
  win_baremetal on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_baremetal/builds/9728)

[åsapersson, 2016-03-15 07:27:44]

The CQ bit was checked by asapersson@webrtc.org

[commit-bot: I haz the power, 2016-03-15 07:27:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1756193005/280001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1756193005/280001

[commit-bot: I haz the power, 2016-03-15 08:00:51]

Description was changed from

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493
==========

to

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493
==========

[commit-bot: I haz the power, 2016-03-15 08:00:53]

Committed patchset #10 (id:280001)

[commit-bot: I haz the power, 2016-03-15 08:00:59]

Description was changed from

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493
==========

to

==========
Add histogram stats for AV sync stream offset:
"WebRTC.Video.AVSyncOffsetInMs"

The absolute value of the sync offset between a rendered video frame and the
latest played audio frame is measured per video frame. The average offset per
received video stream is recorded when a stream is removed.

Updated sync tests in call_perf_tests.cc to use this implementation.

BUG=webrtc:5493

Committed: https://crrev.com/f8cdd184d5299773dfb16063e8690aa2b5bad3ae
Cr-Commit-Position: refs/heads/master@{#11993}
==========

[commit-bot: I haz the power, 2016-03-15 08:01:02]

Patchset 10 (id:??) landed as
https://crrev.com/f8cdd184d5299773dfb16063e8690aa2b5bad3ae
Cr-Commit-Position: refs/heads/master@{#11993}