Avoid creating receiver_time outliers in the VideoAnalyzer.

Avoid creating receiver_time outliers in the VideoAnalyzer.

Prior to this change, the receiver_time metric had huge outliers
whenever FlexFEC was enabled. This was due to a measurement problem,
where the time of the incoming packet was incorrectly set to zero.
This happened for packets that were lost in transit, but recovered
through FEC.

This CL fixes this problem by simply not recording samples where the
incoming packet time is undefined. The CL also removes the possibility
of timestamp collisions in the data structures.

TESTED=Ran './webrtc_perf_tests --gtest_filter="*ForemanCifPlr5H264Flexfec*" | grep receiver_time' locally 10 times, without experiencing any outliers.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2596793002
Cr-Commit-Position: refs/heads/master@{#15735}
Committed: https://chromium.googlesource.com/external/webrtc/+/504b95eff8e1941d3775d65c5065abccc131d503

[brandtr, 2016-12-21 09:23:44]

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

[åsapersson, 2016-12-21 09:58:50]

lgtm

[brandtr, 2016-12-21 10:07:49]

The CQ bit was checked by brandtr@webrtc.org

[commit-bot: I haz the power, 2016-12-21 10:07:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-21 10:09:41]

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

[commit-bot: I haz the power, 2016-12-21 10:09:42]

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

[brandtr, 2016-12-21 10:20:22]

The CQ bit was checked by brandtr@webrtc.org

[commit-bot: I haz the power, 2016-12-21 10:20:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-21 10:54:36]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1482315622177090, "parent_rev":
"f9891d51f84892fa49859cae9412e320bb6d9d93", "commit_rev":
"504b95eff8e1941d3775d65c5065abccc131d503"}

[commit-bot: I haz the power, 2016-12-21 10:54:37]

Description was changed from

==========
Avoid creating receiver_time outliers in the VideoAnalyzer.

Prior to this change, the receiver_time metric had huge outliers
whenever FlexFEC was enabled. This was due to a measurement problem,
where the time of the incoming packet was incorrectly set to zero.
This happened for packets that were lost in transit, but recovered
through FEC.

This CL fixes this problem by simply not recording samples where the
incoming packet time is undefined. The CL also removes the possibility
of timestamp collisions in the data structures.

TESTED=Ran './webrtc_perf_tests --gtest_filter="*ForemanCifPlr5H264Flexfec*" |
grep receiver_time' locally 10 times, without experiencing any outliers.
BUG=webrtc:5654
==========

to

==========
Avoid creating receiver_time outliers in the VideoAnalyzer.

Prior to this change, the receiver_time metric had huge outliers
whenever FlexFEC was enabled. This was due to a measurement problem,
where the time of the incoming packet was incorrectly set to zero.
This happened for packets that were lost in transit, but recovered
through FEC.

This CL fixes this problem by simply not recording samples where the
incoming packet time is undefined. The CL also removes the possibility
of timestamp collisions in the data structures.

TESTED=Ran './webrtc_perf_tests --gtest_filter="*ForemanCifPlr5H264Flexfec*" |
grep receiver_time' locally 10 times, without experiencing any outliers.
BUG=webrtc:5654

Review-Url: https://codereview.webrtc.org/2596793002
Cr-Commit-Position: refs/heads/master@{#15735}
Committed:
https://chromium.googlesource.com/external/webrtc/+/504b95eff8e1941d3775d65c5...
==========

[commit-bot: I haz the power, 2016-12-21 10:54:38]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/504b95eff8e1941d3775d65c5...