I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
Patch set 1 is a reland + trivial rebase.
Patch set >= 2 contains bug fixes.
> Original issue's description:
> > Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
> >
> > That however exposes a bunch of failed test, so this CL also fixed a few other things:
> > * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> > * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> > * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> > * Fix test
> >
> > BUG=7664
> >
> > Review-Url: https://codereview.webrtc.org/2883963002
> > Cr-Commit-Position: refs/heads/master@{#18473}
> > Committed: 6431e21da6
BUG=webrtc:7664
Review-Url: https://codereview.webrtc.org/2953053002
Cr-Commit-Position: refs/heads/master@{#18782}
Currently there is a hard limit for the estimated captured frame
interval of 45ms. As the encoder utilization is calculated as
(input frame interval)/(encode time), overuse signals can be triggered
even though there is plenty of time to go around if the fps is low.
However, in order to avoid falsly estimating low encode usage in case
the capturer has a dynamic frame rate, set the frame interval based on
the actual current max framerate.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2918143003
Cr-Commit-Position: refs/heads/master@{#18610}
A balance of framerate reduction and resolution down-scaling is used on degrades.
BUG=webrtc:7607
Review-Url: https://codereview.webrtc.org/2887303003
Cr-Commit-Position: refs/heads/master@{#18583}
Reason for revert:
Looks like there's still one failing perf test:
RampUpTest.UpDownUpTransportSequenceNumberPacketLoss
Original issue's description:
> Reland of Periodically update codec bit/frame rate settings. (patchset #1 id:1 of https://codereview.webrtc.org/2923993002/ )
>
> Reason for revert:
> Create reland cl that we can patch with fix.
>
> Original issue's description:
> > Revert of Periodically update codec bit/frame rate settings. (patchset #8 id:140001 of https://codereview.webrtc.org/2883963002/ )
> >
> > Reason for revert:
> > Breaks some Call perf tests that are not run by the try bots....
> >
> > Original issue's description:
> > > Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
> > >
> > > That however exposes a bunch of failed test, so this CL also fixed a few other things:
> > > * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> > > * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> > > * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> > > * Fix test
> > >
> > > BUG=7664
> > >
> > > Review-Url: https://codereview.webrtc.org/2883963002
> > > Cr-Commit-Position: refs/heads/master@{#18473}
> > > Committed: 6431e21da6
> >
> > TBR=stefan@webrtc.org,holmer@google.com
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=7664
> >
> > Review-Url: https://codereview.webrtc.org/2923993002
> > Cr-Commit-Position: refs/heads/master@{#18475}
> > Committed: 5390c4814d
>
> TBR=stefan@webrtc.org,holmer@google.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=7664
>
> Review-Url: https://codereview.webrtc.org/2924023002
> Cr-Commit-Position: refs/heads/master@{#18497}
> Committed: cdafeda1cbTBR=stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=7664
Review-Url: https://codereview.webrtc.org/2926283002
Cr-Commit-Position: refs/heads/master@{#18500}
Reason for revert:
Create reland cl that we can patch with fix.
Original issue's description:
> Revert of Periodically update codec bit/frame rate settings. (patchset #8 id:140001 of https://codereview.webrtc.org/2883963002/ )
>
> Reason for revert:
> Breaks some Call perf tests that are not run by the try bots....
>
> Original issue's description:
> > Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
> >
> > That however exposes a bunch of failed test, so this CL also fixed a few other things:
> > * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> > * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> > * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> > * Fix test
> >
> > BUG=7664
> >
> > Review-Url: https://codereview.webrtc.org/2883963002
> > Cr-Commit-Position: refs/heads/master@{#18473}
> > Committed: 6431e21da6
>
> TBR=stefan@webrtc.org,holmer@google.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=7664
>
> Review-Url: https://codereview.webrtc.org/2923993002
> Cr-Commit-Position: refs/heads/master@{#18475}
> Committed: 5390c4814dTBR=stefan@webrtc.org,holmer@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=7664
Review-Url: https://codereview.webrtc.org/2924023002
Cr-Commit-Position: refs/heads/master@{#18497}
Reason for revert:
Breaks some Call perf tests that are not run by the try bots....
Original issue's description:
> Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
>
> That however exposes a bunch of failed test, so this CL also fixed a few other things:
> * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> * Fix test
>
> BUG=7664
>
> Review-Url: https://codereview.webrtc.org/2883963002
> Cr-Commit-Position: refs/heads/master@{#18473}
> Committed: 6431e21da6TBR=stefan@webrtc.org,holmer@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=7664
Review-Url: https://codereview.webrtc.org/2923993002
Cr-Commit-Position: refs/heads/master@{#18475}
That however exposes a bunch of failed test, so this CL also fixed a few other things:
* FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
* FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
* Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
* Fix test
BUG=7664
Review-Url: https://codereview.webrtc.org/2883963002
Cr-Commit-Position: refs/heads/master@{#18473}
Add AdaptCounter class which holds the number of downgrade counts per degradation way (resolution/fps) and reason (cpu/quality).
BUG=webrtc:7607
Review-Url: https://codereview.webrtc.org/2871623002
Cr-Commit-Position: refs/heads/master@{#18156}
When degradation preference is kDegradationDisabled, do not update WebRTC.Video.CpuLimitedResolutionInPercent.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2807133002
Cr-Commit-Position: refs/heads/master@{#17757}
The stats will be used in an upcoming cl to track the rate of adapt changes.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2775173004
Cr-Commit-Position: refs/heads/master@{#17528}
Reason for revert:
Seem to be a flaky test rather than an issue with this cl. Creating reland, will add code to reduce flakiness to that test.
Original issue's description:
> Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #8 id:410001 of https://codereview.webrtc.org/2781433002/ )
>
> Reason for revert:
> This has resulted in failure of CallPerfTest.ReceivesCpuOveruseAndUnderuse test on the Win7 build bot https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1780
>
> Original issue's description:
> > Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2764133002/ )
> >
> > Reason for revert:
> > Found issue with test case, will add fix to reland cl.
> >
> > Original issue's description:
> > > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #14 id:250001 of https://codereview.webrtc.org/2716643002/ )
> > >
> > > Reason for revert:
> > > Breaks perf tests:
> > > https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1679
> > > https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20%28L%20Nexus5%29/builds/2325
> > >
> > > Original issue's description:
> > > > Add framerate to VideoSinkWants and ability to signal on overuse
> > > >
> > > > 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}
> > > > Committed: 72acf25261
> > >
> > > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@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:4172
> > >
> > > Review-Url: https://codereview.webrtc.org/2764133002
> > > Cr-Commit-Position: refs/heads/master@{#17331}
> > > Committed: 8b45b11144
> >
> > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,skvlad@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:4172
> >
> > Review-Url: https://codereview.webrtc.org/2781433002
> > Cr-Commit-Position: refs/heads/master@{#17474}
> > Committed: 3ea3c77e93
>
> TBR=ilnik@webrtc.org,stefan@webrtc.org,asapersson@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:4172
>
> Review-Url: https://codereview.webrtc.org/2783183003
> Cr-Commit-Position: refs/heads/master@{#17477}
> Committed: f9ed235c9bR=ilnik@webrtc.org,stefan@webrtc.org
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2789823002
Cr-Commit-Position: refs/heads/master@{#17498}
WebRTC.Video.QualityLimitedResolutionInPercent is reported as zero for calls when the quality scaler is off (and the degradation preference allows scaling).
Update SetResolutionRestrictionStats to specify if quality scaler is enabled.
BUG=webrtc:7432
Review-Url: https://codereview.webrtc.org/2783213002
Cr-Commit-Position: refs/heads/master@{#17487}
Reason for revert:
This has resulted in failure of CallPerfTest.ReceivesCpuOveruseAndUnderuse test on the Win7 build bot https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1780
Original issue's description:
> Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2764133002/ )
>
> Reason for revert:
> Found issue with test case, will add fix to reland cl.
>
> Original issue's description:
> > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #14 id:250001 of https://codereview.webrtc.org/2716643002/ )
> >
> > Reason for revert:
> > Breaks perf tests:
> > https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1679
> > https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20%28L%20Nexus5%29/builds/2325
> >
> > Original issue's description:
> > > Add framerate to VideoSinkWants and ability to signal on overuse
> > >
> > > 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}
> > > Committed: 72acf25261
> >
> > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@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:4172
> >
> > Review-Url: https://codereview.webrtc.org/2764133002
> > Cr-Commit-Position: refs/heads/master@{#17331}
> > Committed: 8b45b11144
>
> TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,skvlad@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:4172
>
> Review-Url: https://codereview.webrtc.org/2781433002
> Cr-Commit-Position: refs/heads/master@{#17474}
> Committed: 3ea3c77e93TBR=ilnik@webrtc.org,stefan@webrtc.org,asapersson@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:4172
Review-Url: https://codereview.webrtc.org/2783183003
Cr-Commit-Position: refs/heads/master@{#17477}
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}
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}
The test aims to synchronize by waiting for the last sent frame, using
sink_.WaitForEncodedFrame(). Then it stops the vie_encoder instance and
finally reset the SendStatsProxy to trigger UMA stats to be registered.
The problem is that the callback that triggers WaitForEncodedFrame() to
release will call FrameSent() on the overuse detecter just after that,
and so it may try to update the stats proxy while it is being deleted.
To prevent this, simply destroy the vie_encoder instance too, so that
we know that the task queue has been stopped.
BUG=None
Review-Url: https://codereview.webrtc.org/2720183004
Cr-Commit-Position: refs/heads/master@{#16914}
The flaky test was introduced in ad9010c9836, and is essentially a race
where the ViE Encoder has already configured the quality scaler on the
encoder thread before we've updated the ScalingSettings. This CL adds
a forced reconfiguration of the quality scaler to avoid this issue.
BUG=None
TBR=sprang@webrtc.org
Review-Url: https://codereview.webrtc.org/2695873004
Cr-Commit-Position: refs/heads/master@{#16612}
Updated comment.
Don't call AdaptUp/AdaptDown in tests without first emitting a frame.
Handle frame received precondition in AdaptUp/AdaptDown with DCHECK
instead of return.
BUG=webrtc:4172, webrtc:6850
Review-Url: https://codereview.webrtc.org/2690023002
Cr-Commit-Position: refs/heads/master@{#16572}
The current method with max_pixel_count and max_pixel_count_step_up,
where only one should be used at a time and this first signaling an
inclusive upper bound and other other an exclusive lower bound, makes
for a lot of confusion.
I've updated this to have a desired target and a maximum instead. The
source should select a resolution as close to the target as possible,
but no higher than the maximum.
I intend to also add similar frame rate settings in an upcoming cl.
BUG=webrtc:4172,webrtc:6850
Review-Url: https://codereview.webrtc.org/2672793002
Cr-Commit-Position: refs/heads/master@{#16533}
Reason for revert:
Perf test broke as it made assumptions that quality scaling was turned off. This turns out not to be the case. Fixed by turning quality scaling off for the tests.
Original issue's description:
> Revert of Drop frames until specified bitrate is achieved. (patchset #12 id:240001 of https://codereview.webrtc.org/2630333002/ )
>
> Reason for revert:
> due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
>
> Original issue's description:
> > Drop frames until specified bitrate is achieved.
> >
> > This CL fixes a regression introduced with the new quality scaler
> > where the video would no longer start in a scaled mode. This CL adds
> > code that compares incoming captured frames to the target bitrate,
> > and if they are found to be too large, they are dropped and sinkWants
> > set to a lower resolution. The number of dropped frames should be low
> > (0-4 in most cases) and should not introduce a noticeable delay, or
> > at least should be preferrable to having the first 2-4 seconds of video
> > have very low quality.
> >
> > BUG=webrtc:6953
> >
> > Review-Url: https://codereview.webrtc.org/2630333002
> > Cr-Commit-Position: refs/heads/master@{#16391}
> > Committed: 83399caec5
>
> TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2666303002
> Cr-Commit-Position: refs/heads/master@{#16395}
> Committed: 35fc2aa82fTBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,minyue@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2675223002
Cr-Commit-Position: refs/heads/master@{#16473}
Use AdaptDown/AdaptUp instead of ScaleDown/ScaleUp, since we may want to
adapt using other means than resolution.
Also, extend vie_encoder with unit test that actually uses frames scaled
to resolution as determined by VideoAdapter, since that seems to be the
default implementation.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2652893015
Cr-Commit-Position: refs/heads/master@{#16402}
Reason for revert:
due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
Original issue's description:
> Drop frames until specified bitrate is achieved.
>
> This CL fixes a regression introduced with the new quality scaler
> where the video would no longer start in a scaled mode. This CL adds
> code that compares incoming captured frames to the target bitrate,
> and if they are found to be too large, they are dropped and sinkWants
> set to a lower resolution. The number of dropped frames should be low
> (0-4 in most cases) and should not introduce a noticeable delay, or
> at least should be preferrable to having the first 2-4 seconds of video
> have very low quality.
>
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2630333002
> Cr-Commit-Position: refs/heads/master@{#16391}
> Committed: 83399caec5TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2666303002
Cr-Commit-Position: refs/heads/master@{#16395}
This CL fixes a regression introduced with the new quality scaler
where the video would no longer start in a scaled mode. This CL adds
code that compares incoming captured frames to the target bitrate,
and if they are found to be too large, they are dropped and sinkWants
set to a lower resolution. The number of dropped frames should be low
(0-4 in most cases) and should not introduce a noticeable delay, or
at least should be preferrable to having the first 2-4 seconds of video
have very low quality.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2630333002
Cr-Commit-Position: refs/heads/master@{#16391}
Currently, parameters are periodically updated, but the TargetBitrate
message is only sent if a new bitrate is set. It should be sent
periodically to indicate the signaled bitrate is valid and to prevent
stale values due to loss of RTCP packets.
BUG=webrtc:6897
Review-Url: https://codereview.webrtc.org/2616393003
Cr-Commit-Position: refs/heads/master@{#16096}
The MultithreadedFakeH264Encoder is a derived class from FakeEncoder
and FakeH264Encoder, and these should thus also be thread safe.
TESTED=Ran "out/Tsan/video_engine_tests --gtest_filter="*Multithreaded*" --gtest_repeat=100" with is_debug=false, dcheck_always_on=true, is_tsan=true.
BUG=webrtc:6943
Review-Url: https://codereview.webrtc.org/2604403003
Cr-Commit-Position: refs/heads/master@{#16093}
Moves webrtc/common_video/rotation.h and parts of
webrtc/common_video/include/video_frame_buffer.h and
webrtc/video_frame.h, and adds to a new GN target api:video_frame_api.
BUG=webrtc:5880
Review-Url: https://codereview.webrtc.org/2517173004
Cr-Commit-Position: refs/heads/master@{#15993}
Reason for revert:
Fixed perf tests.
Original issue's description:
> Revert of Bump up scaling limit for MediaCodec. (patchset #3 id:40001 of https://codereview.webrtc.org/2566533002/ )
>
> Reason for revert:
> Failed on the perf tests.
>
> Original issue's description:
> > Bump up scaling limit for MediaCodec.
> >
> > Wait until MediaCodec is better tested at these low
> > resolutions, and until some fallback mechanism is in place
> > before lowering this threshold.
> >
> > BUG=webrtc:6837
> >
> > Committed: https://crrev.com/3e9b1330467edf6b5af609b375c15efb9e6b4933
> > Cr-Commit-Position: refs/heads/master@{#15498}
>
> TBR=magjed@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6837
>
> Committed: https://crrev.com/1cd0a0ab43846072b1e2f37c953ecd770feb5963
> Cr-Commit-Position: refs/heads/master@{#15500}
TBR=magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6837
Review-Url: https://codereview.webrtc.org/2567613002
Cr-Commit-Position: refs/heads/master@{#15505}
Reason for revert:
Increase in encode time larger than expected.
Original issue's description:
> Turn off error resilience for VP9 if no spatial or temporal layers are configured and NACK is enabled.
>
> Error resilience is currently always enabled for VP9 which reduces quality.
>
> BUG=webrtc:6783
>
> Committed: https://crrev.com/4eb03c76fa2320534d669fda2aabf800e7a6f579
> Cr-Commit-Position: refs/heads/master@{#15390}
TBR=stefan@webrtc.org,marpan@webrtc.org,mflodman@webrtc.org,marpan@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6783
Review-Url: https://codereview.webrtc.org/2554403006
Cr-Commit-Position: refs/heads/master@{#15501}
Reason for revert:
Failed on the perf tests.
Original issue's description:
> Bump up scaling limit for MediaCodec.
>
> Wait until MediaCodec is better tested at these low
> resolutions, and until some fallback mechanism is in place
> before lowering this threshold.
>
> BUG=webrtc:6837
>
> Committed: https://crrev.com/3e9b1330467edf6b5af609b375c15efb9e6b4933
> Cr-Commit-Position: refs/heads/master@{#15498}
TBR=magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6837
Review-Url: https://codereview.webrtc.org/2562963002
Cr-Commit-Position: refs/heads/master@{#15500}
Wait until MediaCodec is better tested at these low
resolutions, and until some fallback mechanism is in place
before lowering this threshold.
BUG=webrtc:6837
Review-Url: https://codereview.webrtc.org/2566533002
Cr-Commit-Position: refs/heads/master@{#15498}
Error resilience is currently always enabled for VP9 which reduces quality.
BUG=webrtc:6783
Review-Url: https://codereview.webrtc.org/2532053002
Cr-Commit-Position: refs/heads/master@{#15390}
When starting from 720p this is necessary to achieve acceptable
quality at low bitrates.
BUG=webrtc:6495
Review-Url: https://codereview.webrtc.org/2538913003
Cr-Commit-Position: refs/heads/master@{#15356}
This brings QualityScaler much more in line with OveruseFrameDetector.
The two classes are conceptually similar, and should be used in the
same way. The biggest changes in this CL are:
- Quality scaling is now only done in ViEEncoder and not in each
encoder implementation separately.
- QualityScaler now checks the average QP asynchronously, instead of
having to be polled on each frame.
- QualityScaler is no longer responsible for actually scaling the frames,
but has a callback to ViEEncoder that it uses to express it's desire
for lower resolution.
BUG=webrtc:6495
Review-Url: https://codereview.webrtc.org/2398963003
Cr-Commit-Position: refs/heads/master@{#15286}
This is yet another reland of https://codereview.webrtc.org/2434073003/
including two fixes:
1. SimulcastRateAllocator did not handle the screenshare settings properly for numSimulcastStreams = 1. Additional test case was added for that.
2. In VideoSender, when rate allocation is updated after setting a new VideoCodec config, only update the state of the EncoderParameters, but don't actually run SetRateAllocation on the encoder itself. This caused some problems upstreams.
Please review only the changes after patch set 1.
Original description:
Extract bitrate allocation of spatial/temporal layers out of codec impl.
This CL makes a number of intervowen changes:
* Add BitrateAllocation struct, that contains a codec independent view
of how the target bitrate is distributed over spatial and temporal
layers.
* Adds the BitrateAllocator interface, which takes a bitrate and frame
rate and produces a BitrateAllocation.
* A default (non layered) implementation is added, and
SimulcastRateAllocator is extended to fully handle VP8 allocation.
This includes capturing TemporalLayer instances created by the
encoder.
* ViEEncoder now owns both the bitrate allocator and the temporal layer
factories for VP8. This allows allocation to happen fully outside of
the encoder implementation.
This refactoring will make it possible for ViEEncoder to signal the
full picture of target bitrates to the RTCP module.
BUG=webrtc:6301
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2510583002 .
Cr-Commit-Position: refs/heads/master@{#15105}
