Implementation owned by call, and passed to VideoSendStream and
AudioSendStream.
BUG=webrtc:6847, webrtc:7135
Review-Url: https://codereview.webrtc.org/2685673003
Cr-Commit-Position: refs/heads/master@{#17389}
The test is failing due to libvpx roll which will be fixed in future roll.
It wasn't discovered at trybots since webrtc_perf_tests doesn't run
on Mac because of webrtc:7322.
BUG=webrtc:7401
TBR=marpan@webrtc.org
Review-Url: https://codereview.webrtc.org/2774973002 .
Cr-Commit-Position: refs/heads/master@{#17377}
The C++ part of the test uses CallTest to set up an audio-only call. It reads an audio file, plays it through a FakeAudioDevice which transfers data through a FakeNetworkPipe for another FakeAudioDevice to receive it and write it to a file. Information about these files is printed to stdout.
The test cases are meant to try different network and audio configs (more are planned in the future).
The Python part of the test runs the C++ part and scans stdout for tests to perform, runs the pairs of files (original and degraded) through the PESQ tool to receive a score and writes that to perf dashboard.
BUG=webrtc:7229
NOTRY=True
Review-Url: https://codereview.webrtc.org/2694203002
Cr-Commit-Position: refs/heads/master@{#17356}
This was causing the QualityScaler to be reconstructed each time
the resolution changes and thus the fast_rampup logic was not working
as intended. We now properly change the checking period to 5 seconds
after a downscale.
BUG=b/36457883
Review-Url: https://codereview.webrtc.org/2766513003
Cr-Commit-Position: refs/heads/master@{#17335}
In ViEEncoder, try to reduce framerate instead of resolution if the
current degradation preference is maintain-resolution rather than
balanced.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2716643002
Cr-Commit-Position: refs/heads/master@{#17327}
New class ReceiveSideCongestionController, extracted from CongestionController, and responsible for the
OnReceivedPacket processing.
Rest of the CongestionController moved to a new class
SendSideCongestionController.
To avoid breaking applications, CongestionController is redefined
as a union of these two classes, with no intended change in behavior.
With one exception: CongestionController::SetBweBitrates used to call
remote_bitrate_estimator_.SetMinBitrate, but after remote_bitrate_estimator_ was moved to ReceiveSideCongestionController,
it no longer does this.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2752233002
Cr-Commit-Position: refs/heads/master@{#17321}
Add tests for inital probing and mid-call probing by reconfiguring max bitrate.
BUG=none
Review-Url: https://codereview.webrtc.org/2760623002
Cr-Commit-Position: refs/heads/master@{#17316}
It depends on RTCP RPSI and SLI messages, which are being deleted.
TBR=stefan@webrtc.org # TODO comments added to common_types.h
BUG=webrtc:7338
Review-Url: https://codereview.webrtc.org/2753783002
Cr-Commit-Position: refs/heads/master@{#17314}
- Reduced flakyness by switching to a packetization format that has
PictureID.
- Removed the explicit send-side BWE enabling from ULPFEC and FlexFEC
tests, since that is now on by default.
BUG=webrtc:7047
Review-Url: https://codereview.webrtc.org/2753253002
Cr-Commit-Position: refs/heads/master@{#17310}
This is one step towards separation of send-side and receive-side
processing.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2740163002
Cr-Commit-Position: refs/heads/master@{#17306}
Reason for revert:
Reverting this as it had no effect.
Original issue's description:
> Don't set the priority of the decoder to 'high' on Android.
> Doing so competes with the actual decoding that happens on a different thread.
>
> BUG=695438
>
> Review-Url: https://codereview.webrtc.org/2745813003
> Cr-Commit-Position: refs/heads/master@{#17184}
> Committed: ca37cf6691TBR=stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=695438
Review-Url: https://codereview.webrtc.org/2757733005
Cr-Commit-Position: refs/heads/master@{#17297}
Fix reduced frame-rate on Mac and Android.
Also enable huge full-stack test Largeroom_50thumbs on Windows.
BUG=webrtc:7301
Review-Url: https://codereview.webrtc.org/2760583003
Cr-Commit-Position: refs/heads/master@{#17288}
The implementation behind this method has been a noop for a long time.
BUG=none
Review-Url: https://codereview.webrtc.org/2757843002
Cr-Commit-Position: refs/heads/master@{#17286}
Reason for revert:
Changes to frame-generator resulted in reduced fps on android and Mac on all tests.
Original issue's description:
> Reland of write frame generator capturer to use TaskQueue instead of EventTimeWrapper (patchset #1 id:1 of https://codereview.webrtc.org/2748643002/ )
>
> Reason for revert:
> Reland with fixes to the failing perf tests.
>
> Original issue's description:
> > Revert of rewrite frame generator capturer to use TaskQueue instead of EventTimeWrapper (patchset #2 id:90001 of https://codereview.webrtc.org/2744003002/ )
> >
> > Reason for revert:
> > CallPerfTest.ReceivesCpuOveruseAndUnderuse perf test fails due to this CL. It requires very accurate frame rate, which may not be so accurate now.
> >
> > Original issue's description:
> > > Reland of rewrite frame generator capturer to use TaskQueue instead of EventTimeWrapper (patchset #1 id:1 of https://codereview.webrtc.org/2743993002/ )
> > >
> > > And enable large full-stack test depending on that change (Reland of https://codereview.webrtc.org/2741823003/)
> > > TBR=stefan@webrtc.org,tommi@webrtc.org
> > > BUG=webrtc:7301,webrtc:7325
> > >
> > > Review-Url: https://codereview.webrtc.org/2744003002
> > > Cr-Commit-Position: refs/heads/master@{#17196}
> > > Committed: 8c0a5896d1
> >
> > TBR=stefan@webrtc.org,tommi@webrtc.org,sprang@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7301,webrtc:7325
> >
> > Review-Url: https://codereview.webrtc.org/2748643002
> > Cr-Commit-Position: refs/heads/master@{#17198}
> > Committed: 382a72a0d3
>
> BUG=webrtc:7301,webrtc:7325
>
> Review-Url: https://codereview.webrtc.org/2750473002
> Cr-Commit-Position: refs/heads/master@{#17253}
> Committed: 2549ad4fefTBR=sprang@webrtc.org,tommi@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7301,webrtc:7325
Review-Url: https://codereview.webrtc.org/2751063005
Cr-Commit-Position: refs/heads/master@{#17276}
Bad changes are from CL 2745523002.
These changes were originally done by Sprang@. Sometimes, when encoder is failed to be configured on release build it causes a crash at vie_encoder.cc:451. That changes look like they are not important to other changes. This CL is simply reverting them.
BUG=chromium:701526
Review-Url: https://codereview.webrtc.org/2747403002
Cr-Commit-Position: refs/heads/master@{#17241}
* The _receiveCallback member of VCMDecodedFrameCallback does actually not require locking now that the threading model is slightly clearer. Documentation and checks have been added.
* UserReceiveCallback() never returns null and must always be called on the decoder thread. Checks have been added and the two test suites that were failing to set this callback, have been fixed and a new mock class added. (looks like sakal@ may have hit some issues with flaky tests there).
* Changed VcmPayloadSink to use move semantics which I suspect was the intention at the time the code was written (when we didn't have move semantics).
* Added thread checker to a couple of classes and started adding thread checks for known behavior. There's more to be done there.
* Remove the |_decoder| member variable in VideoReceiver. It is not needed and as it could be used, left us open to a race.
* TODOs added for places where we can reduce locking. I suspect that we can get away with not needing a lock around _codecDataBase in VideoReceiver once we've got a clear picture of the threading model and ensured that all adhere to it.
BUG=webrtc:7328
Review-Url: https://codereview.webrtc.org/2744013002
Cr-Commit-Position: refs/heads/master@{#17226}
Turns out temporal_layer_thresholds_bps doesn't work quite as expected.
It's for instance not honored at all for normal VP8 video. We need to
take a pass over this in general.
BUG=chromium:700297
Review-Url: https://codereview.webrtc.org/2744823002
Cr-Commit-Position: refs/heads/master@{#17199}
Doing so competes with the actual decoding that happens on a different thread.
BUG=695438
Review-Url: https://codereview.webrtc.org/2745813003
Cr-Commit-Position: refs/heads/master@{#17184}
Reason for revert:
This depends on another patchset, which causes problem and will be reverted too.
Original issue's description:
> Enable big largeroom fullstack tests on Windows
>
> BUG=webrtc:7301
>
> Review-Url: https://codereview.webrtc.org/2741823003
> Cr-Commit-Position: refs/heads/master@{#17169}
> Committed: 15939e7775TBR=sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7301
Review-Url: https://codereview.webrtc.org/2738353006
Cr-Commit-Position: refs/heads/master@{#17172}
Use of FlexFEC is known when streams are created in
WebRtcVideoChannel2, so this replaces the code in Call to infer
FlexFEC config of video streams from the configuration of the FlexFEC
stream(s). This also allows us to switch to a more logical creation
order, where media streams are created before the FlexFEC stream.
This is done in preparation for a larger refactoring of the RTP
demuxing done in Call.
BUG=None
Review-Url: https://codereview.webrtc.org/2712683002
Cr-Commit-Position: refs/heads/master@{#17143}
Added thumbnail streams functionality to video quality test.
Changed simulcast full-stack tests to be 30fps instead of 50 to
better reflect real usecases (expect all kind of perf metrics to
improve).
BUG=webrtc:7095, webrtc:7301
Review-Url: https://codereview.webrtc.org/2733943003
Cr-Commit-Position: refs/heads/master@{#17092}
Reason for revert:
webrtc_perf_tests crashes on android and windows due to too large test.
Original issue's description:
> Added large room scenario to full-stack tests. Added thumbnail streams functionality to video quality test.
>
> Changed simulcast full-stack tests to be 30fps instead of 50 to better reflect real usecases (expect all kind of perf metrics to improve).
>
> BUG=webrtc:7095
>
> Review-Url: https://codereview.webrtc.org/2730073002
> Cr-Commit-Position: refs/heads/master@{#17068}
> Committed: d8bd1b1d82TBR=sprang@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7095
Review-Url: https://codereview.webrtc.org/2734753004
Cr-Commit-Position: refs/heads/master@{#17071}
Changed simulcast full-stack tests to be 30fps instead of 50 to better reflect real usecases (expect all kind of perf metrics to improve).
BUG=webrtc:7095
Review-Url: https://codereview.webrtc.org/2730073002
Cr-Commit-Position: refs/heads/master@{#17068}
Add extra checks to it to simplify diagnostic should it fail again.
BUG=webrtc:7292
Review-Url: https://codereview.webrtc.org/2728103002
Cr-Commit-Position: refs/heads/master@{#16999}
This makes a few things a lot clearer when looking at perf trace data:
* What module instances (where they were created) are called
* On what thread
* How frequently
* For how long
ProcessThread will be replaced by TaskQueue moving forward and this is a step towards understanding the behavior of the affected code.
BUG=webrtc:7219
Review-Url: https://codereview.webrtc.org/2729053002
Cr-Commit-Position: refs/heads/master@{#16998}
This CL fixes two issues. The first is a tsan complaint about a data
race. The test had a fix to make it deterministic but the race still
existed, so this adds locks around the critical section to appease
the sanitizer.
The second, more annoying issue, is that occasionally the test would
start before the encoder had been configured, as this happens
asynchronously on a task queue. This would cause frames to be queued
up and dropped, but not where we expected them to be dropped.
This was causing some tests to fail very occasionally. I've added
a synchronisation mechanism by posting a barrier task on the queue
and not proceeding with the tests until it finishes.
BUG=webrtc:7217, webrtc:7232, webrtc:7260
Review-Url: https://codereview.webrtc.org/2722183004
Cr-Commit-Position: refs/heads/master@{#16995}
