It's currently only used to ensure transport-cc is enabled for the format in question. It might be used to toggle more things in future.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2669583002
Cr-Commit-Position: refs/heads/master@{#16514}
Reason for revert:
The reason for reverting was false alarm.
Original issue's description:
> Revert of Avoid calling PostTask in audio callbacks (patchset #6 id:100001 of https://codereview.webrtc.org/2663383004/ )
>
> Reason for revert:
> Speculative revert to see if this CL caused a change in performance tests.
>
> See https://bugs.chromium.org/p/chromium/issues/detail?id=689919 for details.
>
> Original issue's description:
> > Avoid calling PostTask in audio callbacks.
> >
> > We have seen that PostTask can consume some CPU and the way we used it
> > before (logging only) in the ADB is not worth the cost we see when
> > profiling.
> >
> > This CL simply moves frequent (trivial) stat updates from the task queue
> > to the native threads to avoid calling PostTask in each callback.
> > The reason for doing so before was to avoid locks but we can live without
> > them since races are benign here.
> >
> >
> > BUG=webrtc:7096
> >
> > Review-Url: https://codereview.webrtc.org/2663383004
> > Cr-Commit-Position: refs/heads/master@{#16429}
> > Committed: 77ce9a5541
>
> TBR=solenberg@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7096
>
> Review-Url: https://codereview.webrtc.org/2684913003
> Cr-Commit-Position: refs/heads/master@{#16490}
> Committed: fd8f102a84TBR=solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2687573003
Cr-Commit-Position: refs/heads/master@{#16497}
Reason for revert:
Speculative revert to see if this CL caused a change in performance tests.
See https://bugs.chromium.org/p/chromium/issues/detail?id=689919 for details.
Original issue's description:
> Avoid calling PostTask in audio callbacks.
>
> We have seen that PostTask can consume some CPU and the way we used it
> before (logging only) in the ADB is not worth the cost we see when
> profiling.
>
> This CL simply moves frequent (trivial) stat updates from the task queue
> to the native threads to avoid calling PostTask in each callback.
> The reason for doing so before was to avoid locks but we can live without
> them since races are benign here.
>
>
> BUG=webrtc:7096
>
> Review-Url: https://codereview.webrtc.org/2663383004
> Cr-Commit-Position: refs/heads/master@{#16429}
> Committed: 77ce9a5541TBR=solenberg@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2684913003
Cr-Commit-Position: refs/heads/master@{#16490}
canceller 3
This CL adds code to the all the delay estimation functionality that is
available for the first version of echo canceller 3. The code completes
the class EchoPathDelayEstimator.
Note that this code does not yet include any handling of clock-drift so
there will be upcoming versions of this code.
Also note that the CL includes some minor changes in other files for
echo canceller 3.
BUG=webrtc:6018
Review-Url: https://codereview.webrtc.org/2644123002
Cr-Commit-Position: refs/heads/master@{#16489}
This is not implemented yet in any of the decoders.
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2649133005
Cr-Commit-Position: refs/heads/master@{#16475}
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}
This was causing some apps that include WebRTC to be rejected from the
app store.
BUG=webrtc:6382
Review-Url: https://codereview.webrtc.org/2679913002
Cr-Commit-Position: refs/heads/master@{#16462}
That would simplify their usage in tests where perfomance is not critical.
BUG=None
Review-Url: https://codereview.webrtc.org/2675713005
Cr-Commit-Position: refs/heads/master@{#16461}
Also fixes a bug where RTCP transport feedback was sent even though RTCP was disabled.
May affect perf numbers since the behavior of the send-side BWE differs a lot from the recv-side BWE.
BUG=webrtc:7111
Review-Url: https://codereview.webrtc.org/2669413003
Cr-Commit-Position: refs/heads/master@{#16451}
AEC3 and AEC2 are separate submodules in APM. This CL ensures that AEC3
deactivates AEC2 if both are active at the same time.
BUG=webrtc:6018
Review-Url: https://codereview.webrtc.org/2675863004
Cr-Commit-Position: refs/heads/master@{#16443}
The timer is only used for logging purposes and we can save CPU by
checking the volume less often.
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2669323003
Cr-Commit-Position: refs/heads/master@{#16430}
We have seen that PostTask can consume some CPU and the way we used it
before (logging only) in the ADB is not worth the cost we see when
profiling.
This CL simply moves frequent (trivial) stat updates from the task queue
to the native threads to avoid calling PostTask in each callback.
The reason for doing so before was to avoid locks but we can live without
them since races are benign here.
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2663383004
Cr-Commit-Position: refs/heads/master@{#16429}
As it is, the test fails to compile on some downstream compilers with the following error:
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:25: error: lambda capture 'kPayloadLength' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:41: error: lambda capture 'kFirstSequenceNumber' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:63: error: lambda capture 'kFirstTimestamp' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:317:25: error: lambda capture 'kFirstReceiveTime' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
kFirstReceiveTime](const SdpAudioFormat& format,
BUG=webrtc:7107
Review-Url: https://codereview.webrtc.org/2672823002
Cr-Commit-Position: refs/heads/master@{#16422}
Since we can't know when a H264 frame really starts we instead group all packets together by timestamp when a frame seems to be complete (only in the case of H264).
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2675693002
Cr-Commit-Position: refs/heads/master@{#16419}
Adds ignore for all lint errors in Chromium code. Changes minimum SDK for
instrumentation tests to 16 from 14. Adds TargetApi annotations.
BUG=webrtc:6597
Review-Url: https://codereview.webrtc.org/2670473004
Cr-Commit-Position: refs/heads/master@{#16412}
BUG=webrtc:7097
TEST=Set "ptime=120", try WebRTC calls over custom build Chromium with and without Opus 120ms. Try both Chromium w <-> Chromium w and Chromium w <-> Chromium w/o
Review-Url: https://codereview.webrtc.org/2668633004
Cr-Commit-Position: refs/heads/master@{#16408}
Useful if bitrate probing is to be used with audio streams.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2652893004
Cr-Commit-Position: refs/heads/master@{#16404}
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}
(Or, in less flattering terms, fixing a performance issue introduced
a few months ago by me).
In GN release mode (is_debug = false), the version of the mixer code
before this CL generated code that multiplied each sample (tens of
thousands/second for each input stream) with a floating point number.
This number is almost always exactly 1.0f. The only situation when it's
not 1 is when an audio steam is added or removed.
For one input stream early return leads to a 30% improvement of audio
mixing time profiled on x86-64 under a release build (is_debug = false,
enable_profiling, enable_full_stack_frames_for_profiling) with 16kHz and no
APM limiter. There can be up to 3 streams.
BUG=chromium:687502
Review-Url: https://codereview.webrtc.org/2659423002
Cr-Commit-Position: refs/heads/master@{#16396}
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}
If the frame buffer is cleared while the decoding thread is waiting to acquire
the lock in order to return the |next_frame_it| will be invalidated.
BUG=chromium:679306
Review-Url: https://codereview.webrtc.org/2668743002
Cr-Commit-Position: refs/heads/master@{#16384}
We read past the end of the initialized part of the buffer, seemingly
on purpose (no one knows the details of this code anymore). The right
thing to do is probably to zero that part of the buffer.
(The *right* right thing to would be to rewrite this so that it was
easier to see what data was supposed to be where when, but
priorities...)
BUG=chromium:683040
Review-Url: https://codereview.webrtc.org/2659383002
Cr-Commit-Position: refs/heads/master@{#16365}
This allows controllers to do internal logic upon the network metric changes, e.g., filtering.
BUG=webrtc:6303
Review-Url: https://codereview.webrtc.org/2643133003
Cr-Commit-Position: refs/heads/master@{#16363}
