Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_stream.cc?rcl=1472584967&l=353)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.

Committed: https://crrev.com/a8c94029d82a86c2b16131f8fe6d05f874ac2667
Cr-Commit-Position: refs/heads/master@{#13991}

[skvlad, 2016-08-31 01:51:21]

Description was changed from

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
==========

to

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
==========

[skvlad, 2016-08-31 01:51:21]

skvlad@webrtc.org changed reviewers:
+ magjed@webrtc.org, mflodman@webrtc.org

[skvlad, 2016-08-31 01:51:51]

Please take a look; this is a trivial change to fix a flaky test
(https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/...)

[magjed_webrtc, 2016-08-31 09:36:55]

lgtm

[mflodman, 2016-08-31 09:43:17]

lgtm

[mflodman, 2016-08-31 09:50:18]

The CQ bit was checked by mflodman@webrtc.org

[commit-bot: I haz the power, 2016-08-31 09:50:26]

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-08-31 10:42:31]

Description was changed from

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
==========

to

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
==========

[commit-bot: I haz the power, 2016-08-31 10:42:34]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-08-31 10:42:42]

Description was changed from

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.
==========

to

==========
Fixed flaky test: WebRtcVideoChannel2BaseTest.GetStatsMultipleRecvStreams

This test has been failing on TSan lately:
  ../../webrtc/media/base/videoengine_unittest.h:519: Failure
  Value of: GetReceiverStats(i).frame_width
    Actual: 0
    Expected: DefaultCodec().width
    Which is: 640

The root cause for the failure appears to be that the stats update
(https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_receive_s...)
happens to be after the frame is passed to the renderer - while the test
is only waiting for the former.

The fix is to give it some extra time using EXPECT_EQ_WAIT instead.

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

[commit-bot: I haz the power, 2016-08-31 10:42:43]

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