Fix potential crash bug in debug builds

The call to |interframe_delay_max_moving_.Add()| below depends on |now|
non decreasing in consequtive calls. However, if two threads are
competing for the lock it may happen that current thread calculates |now|
before the other thread, yet it will get the lock later. This will result
in decreasing local time in consecutive calls and trigger a DCHECK.

The same also applies to |timing_frame_info_counter_|.

Bug: none
Change-Id: I3376d88d4448c2c105e9227a445b11cd6ba8d341
Reviewed-on: https://webrtc-review.googlesource.com/7861
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20217}
This commit is contained in:
Ilya Nikolaevskiy 2017-10-10 11:18:49 +02:00 committed by Commit Bot
parent ae81975bd3
commit 3f670e07fe

View File

@ -564,8 +564,8 @@ void ReceiveStatisticsProxy::OnFrameBufferTimingsUpdated(
void ReceiveStatisticsProxy::OnTimingFrameInfoUpdated(
const TimingFrameInfo& info) {
int64_t now_ms = clock_->TimeInMilliseconds();
rtc::CritScope lock(&crit_);
int64_t now_ms = clock_->TimeInMilliseconds();
timing_frame_info_counter_.Add(info, now_ms);
}
@ -628,10 +628,10 @@ void ReceiveStatisticsProxy::DataCountersUpdated(
void ReceiveStatisticsProxy::OnDecodedFrame(rtc::Optional<uint8_t> qp,
VideoContentType content_type) {
uint64_t now = clock_->TimeInMilliseconds();
rtc::CritScope lock(&crit_);
uint64_t now = clock_->TimeInMilliseconds();
ContentSpecificStats* content_specific_stats =
&content_specific_stats_[content_type];
++stats_.frames_decoded;