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}
Timing information is gathered in EncodedImage,
starting at encoders. Then it's sent using RTP header extension. In the
end, it's gathered at the GenericDecoder. Actual reporting and tests
will be in the next CLs.
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2911193002
Cr-Commit-Position: refs/heads/master@{#18659}
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}
Reason for revert:
Re-land, reverting did not fix bug.
https://bugs.chromium.org/p/webrtc/issues/detail?id=7465
Original issue's description:
> Revert of Implemented the GetSources() in native code. (patchset #11 id:510001 of https://codereview.webrtc.org/2770233003/ )
>
> Reason for revert:
> Suspected of WebRtcApprtcBrowserTest.MANUAL_WorksOnApprtc breakage, see
>
> https://bugs.chromium.org/p/webrtc/issues/detail?id=7465
>
> Original issue's description:
> > Added the GetSources() to the RtpReceiverInterface and implemented
> > it for the AudioRtpReceiver.
> >
> > This method returns a vector of RtpSource(both CSRC source and SSRC
> > source) which contains the ID of a source, the timestamp, the source
> > type (SSRC or CSRC) and the audio level.
> >
> > The RtpSource objects are buffered and maintained by the
> > RtpReceiver in webrtc/modules/rtp_rtcp/. When the method is called,
> > the info of the contributing source will be pulled along the object
> > chain:
> > AudioRtpReceiver -> VoiceChannel -> WebRtcVoiceMediaChannel ->
> > AudioReceiveStream -> voe::Channel -> RtpRtcp module
> >
> > Spec:https://w3c.github.io/webrtc-pc/archives/20151006/webrtc.html#widl-RTCRtpReceiver-getContributingSources-sequence-RTCRtpContributingSource
> >
> > BUG=chromium:703122
> > TBR=stefan@webrtc.org, danilchap@webrtc.org
> >
> > Review-Url: https://codereview.webrtc.org/2770233003
> > Cr-Commit-Position: refs/heads/master@{#17591}
> > Committed: 292084c376
>
> TBR=deadbeef@webrtc.org,solenberg@webrtc.org,hbos@webrtc.org,philipel@webrtc.org,stefan@webrtc.org,danilchap@webrtc.org,zhihuang@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=chromium:703122
>
> Review-Url: https://codereview.webrtc.org/2809613002
> Cr-Commit-Position: refs/heads/master@{#17616}
> Committed: fbcc5cb386TBR=deadbeef@webrtc.org,solenberg@webrtc.org,philipel@webrtc.org,stefan@webrtc.org,danilchap@webrtc.org,zhihuang@webrtc.org,olka@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:703122
Review-Url: https://codereview.webrtc.org/2810623003
Cr-Commit-Position: refs/heads/master@{#17621}
Reason for revert:
Suspected of WebRtcApprtcBrowserTest.MANUAL_WorksOnApprtc breakage, see
https://bugs.chromium.org/p/webrtc/issues/detail?id=7465
Original issue's description:
> Added the GetSources() to the RtpReceiverInterface and implemented
> it for the AudioRtpReceiver.
>
> This method returns a vector of RtpSource(both CSRC source and SSRC
> source) which contains the ID of a source, the timestamp, the source
> type (SSRC or CSRC) and the audio level.
>
> The RtpSource objects are buffered and maintained by the
> RtpReceiver in webrtc/modules/rtp_rtcp/. When the method is called,
> the info of the contributing source will be pulled along the object
> chain:
> AudioRtpReceiver -> VoiceChannel -> WebRtcVoiceMediaChannel ->
> AudioReceiveStream -> voe::Channel -> RtpRtcp module
>
> Spec:https://w3c.github.io/webrtc-pc/archives/20151006/webrtc.html#widl-RTCRtpReceiver-getContributingSources-sequence-RTCRtpContributingSource
>
> BUG=chromium:703122
> TBR=stefan@webrtc.org, danilchap@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2770233003
> Cr-Commit-Position: refs/heads/master@{#17591}
> Committed: 292084c376TBR=deadbeef@webrtc.org,solenberg@webrtc.org,hbos@webrtc.org,philipel@webrtc.org,stefan@webrtc.org,danilchap@webrtc.org,zhihuang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:703122
Review-Url: https://codereview.webrtc.org/2809613002
Cr-Commit-Position: refs/heads/master@{#17616}
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}
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}
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}
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}
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}
Reason for revert:
Reland after fixing broken perf tests.
Original issue's description:
> Revert of Set scaling limit at 320 * 180 for all implementations. (patchset #2 id:20001 of https://codereview.webrtc.org/2709153002/ )
>
> Reason for revert:
> Looks like webrtc_perf_test started failing on linux, mac and windows after this cl landed.
>
> Example failure:
>
> https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/1386/steps/webrtc_perf_tests/logs/stdio
>
> [ RUN ] CallPerfTest.ReceivesCpuOveruseAndUnderuse
> ../../webrtc/call/call_perf_tests.cc:522: Failure
> Value of: Wait()
> Actual: false
> Expected: true
> Timed out before receiving an overuse callback.
> [ FAILED ] CallPerfTest.ReceivesCpuOveruseAndUnderuse (120056 ms)
>
>
> Original issue's description:
> > Set scaling limit at 320 * 180 for all implementations.
> >
> > The MediaCodec decoder on android has trouble decoding video at
> > so low resolutions. We set the limit a bit higher for all implementations
> > pending a robust software fallback implementation for MediaCodec.
> >
> > BUG=webrtc:7206
> >
> > Review-Url: https://codereview.webrtc.org/2709153002
> > Cr-Commit-Position: refs/heads/master@{#16798}
> > Committed: 560ddb7321
>
> TBR=magjed@webrtc.org,sprang@webrtc.org,kthelgason@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7206
>
> Review-Url: https://codereview.webrtc.org/2711913007
> Cr-Commit-Position: refs/heads/master@{#16839}
> Committed: 37510bf094TBR=magjed@webrtc.org,sprang@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2718013002
Cr-Commit-Position: refs/heads/master@{#16853}
Reason for revert:
Looks like webrtc_perf_test started failing on linux, mac and windows after this cl landed.
Example failure:
https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/1386/steps/webrtc_perf_tests/logs/stdio
[ RUN ] CallPerfTest.ReceivesCpuOveruseAndUnderuse
../../webrtc/call/call_perf_tests.cc:522: Failure
Value of: Wait()
Actual: false
Expected: true
Timed out before receiving an overuse callback.
[ FAILED ] CallPerfTest.ReceivesCpuOveruseAndUnderuse (120056 ms)
Original issue's description:
> Set scaling limit at 320 * 180 for all implementations.
>
> The MediaCodec decoder on android has trouble decoding video at
> so low resolutions. We set the limit a bit higher for all implementations
> pending a robust software fallback implementation for MediaCodec.
>
> BUG=webrtc:7206
>
> Review-Url: https://codereview.webrtc.org/2709153002
> Cr-Commit-Position: refs/heads/master@{#16798}
> Committed: 560ddb7321TBR=magjed@webrtc.org,sprang@webrtc.org,kthelgason@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2711913007
Cr-Commit-Position: refs/heads/master@{#16839}
The MediaCodec decoder on android has trouble decoding video at
so low resolutions. We set the limit a bit higher for all implementations
pending a robust software fallback implementation for MediaCodec.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2709153002
Cr-Commit-Position: refs/heads/master@{#16798}
The only implementation which used a nullptr was a mock used in tests,
so add a dummy instance there instead.
Remove tests for stats_proxy_ in vie_encoder and just dcheck in the
constructor instead.
BUG=None
Review-Url: https://codereview.webrtc.org/2695643002
Cr-Commit-Position: refs/heads/master@{#16577}
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}
Also mark the render_time_ms getter function and the ntp timestamp
as deprecated.
BUG=webrtc:6977
Review-Url: https://codereview.webrtc.org/2633493002
Cr-Commit-Position: refs/heads/master@{#16354}
