Fixed flaky VideoSendStreamTest::SupportsAbsoluteSendTime

This test failed on the memcheck bot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Memcheck/builds/6704/steps/video_engine_tests/logs/stdio

The test assumed that the absolute send time header extension can never
be zero. It's a timestamp truncated to 24 bits, and zero is not a
special value - so it can very rarely end up being precisely zero.

The fix makes the test wait for at least one packet having a non-zero send time.

I've considered changing the test to use a fake clock instead to ensure
that not only the value is non-zero, but that it indeed reflects the
system timestamp - but that involves changing a very large number of
files. Besides, other tests in this file don't verify values for header
extensions where zeroes are allowed.

NOTRY=true

Review-Url: https://codereview.webrtc.org/2307693002
Cr-Commit-Position: refs/heads/master@{#14056}
This commit is contained in:
skvlad 2016-09-02 13:23:46 -07:00 committed by Commit bot
parent 1afdf99f9c
commit c3f3515f8e

View File

@ -136,8 +136,16 @@ TEST_F(VideoSendStreamTest, SupportsAbsoluteSendTime) {
EXPECT_FALSE(header.extension.hasTransmissionTimeOffset);
EXPECT_TRUE(header.extension.hasAbsoluteSendTime);
EXPECT_EQ(header.extension.transmissionTimeOffset, 0);
EXPECT_GT(header.extension.absoluteSendTime, 0u);
observation_complete_.Set();
if (header.extension.absoluteSendTime != 0) {
// Wait for at least one packet with a non-zero send time. The send time
// is a 16-bit value derived from the system clock, and it is valid
// for a packet to have a zero send time. To tell that from an
// unpopulated value we'll wait for a packet with non-zero send time.
observation_complete_.Set();
} else {
LOG(LS_WARNING) << "Got a packet with zero absoluteSendTime, waiting"
" for another packet...";
}
return SEND_PACKET;
}