The webrtc::VideoStreamDecoderInterface was basically created as a public version of FrameBuffer2, but to hide the complexity of FrameBuffer2 it was also combined with decoding so that the public API could be reasonably simple to use. FrameBuffer3 has a simple API with a clear purpose, so its API can be exposed directly.
Bug: webrtc:14026
Change-Id: I81dc84b869e4d16c5e02feb5c876fbcede3d4a25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261181
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36781}
The features have two safety fallbacks:
- multichannel config has a killswitch WebRTC-Aec3SetupSpecificDefaultConfigDefaultsKillSwitch
- stereo detection has a killswitch WebRTC-Aec3StereoContentDetectionKillSwitch
Both features are enabled by default in the AEC3 config.
Tested: Bitexact on a large number of aecdumps.
Bug: chromium:1295710
Change-Id: I340cdc9140dacd4ca22d0911eb9f732b6cf8b226
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258129
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36482}
This explores the theory that targets that have no files, just
dependencies, are unnecessary.
Bug: webrtc:13805
Change-Id: I1feb50cf3886128031af8970eae361e35fb052c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256974
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36363}
This patch takes a stab at modules/video_coding,
but reaches only about half.
Bug: webrtc:10335
Change-Id: I0d47d0468b818145470c51ae4e8e75ff58d499ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256112
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36335}
The problem was fixed by implementing the methid PacketDuration() in
AudioDecoderG722StereoImpl, which catches the issue in
AudioDecoder::Decode().
Bug: chromium:1280851
Change-Id: I31f974b9999f3c1c62b0e5dc39bb3e56a9a9388d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251842
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36034}
This emulates behaviour from frame buffer 2, but does not handle stats.
In contrast to frame buffer 2, all work happens on the same task queue.
FrameBuffer3Proxy encapsulates FrameBuffer3 and scheduler behind
a field trial WebRTC-FrameBuffer3.
This separates frame scheduling behaviour into a few components,
VideoReceiveStreamTimeoutTracker
* Handles the stream timeouts.
FrameDecodeScheduler
* Manages the scheduling and cancelling of frames being sent to the
decoder.
FrameDecodeTiming
* Handles the timing and ordering of frames to be decoded.
Other changes
* Adds CurrentSize() method to FrameBuffer3
* Move timing to a separate library
* Does a thread check for Receive statistics as this is now
on the worker thread.
* Adds `FlushImmediate` method to RunLoop so that
video_receive_stream2_unittest can pass when scheduling is happening
on the worker thread.
Change-Id: Ia8d2e5650d1708cdc1be3631a5214134583a0721
Bug: webrtc:13343
Tested: Ran webrtc_perf_tests, video_engine_tests, rtc_unittests forcing frame buffer3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241603
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35847}
This makes fuzzer test cases fail if there's an assert failure in
the helper functions called by the test.
Bug: None
Change-Id: Ic187d72b8d4e016659a68a7bdcaadb78ab2aab05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246400
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35804}
Important: This change does not in any way affect echo cancellation or standardized stats. The user audio experience is unchanged. Only non-standard stats are affected. Echo return loss metrics are unchanged. Residual echo likelihood {recent max} will no longer be computed by default.
Important: The echo detector is no longer enabled by default.
API change, PSA: https://groups.google.com/g/discuss-webrtc/c/mJV5cDysBDI/m/7PTPBjVHCgAJ
This CL removes the default usage of the residual echo detector in APM.
It can now only be used via injection and the helper function webrtc::CreateEchoDetector. See how the function audio_processing_unittest.cc:CreateApm() changed, for an example.
The echo detector implementation is marked poisonous, to avoid accidental dependencies.
Some cleanup is done:
- EchoDetector::PackRenderAudioBuffer is declared in one target but is defined in another target. It is not necessary to keep in the API. It is made an implementation detail, and the echo detector input is documented in the API.
- The internal state of APM is large and difficult to track. Submodule pointers that are set permanently on construction are now appropriately marked const.
Tested:
- existing + new unit tests
- audioproc_f is bitexact on a large number of aecdumps
Bug: webrtc:11539
Change-Id: I00cc2ee112fedb06451a533409311605220064d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239652
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35550}
FrameBuffer3 keep track of order, decodability and continuity of the inserted frames. Compared to FrameBuffer2 which schedule frames for decoding and is thread safe, FrameBuffer3 does not schedule decoding and is thread unsafe.
Change-Id: Ic3bd540c4f69cec26fce53a40425f3bcd9afe085
Bug: webrtc:13343
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238985
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35494}
This was a remenant leftover from a previous design, which was no longer
valid after the switch to TaskQueues. ReturnReason::kStopped was not
used at all, and so Timeout or FrameFound can be inferred from whether
the frame is null or not.
Bug: webrtc:13343, webrtc:13346
Change-Id: Ib0f847b1e1192e32ea11208e48f5a3892703521e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239651
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35490}
Only used in unit tests and a duplication of what `capture_output_rms_`
already does.
This CL also removes `AudioProcessingStats::output_rms_dbfs`, which is
now unused.
Bug: webrtc:5298
Fix: chromium:1261339
Change-Id: I6e583c11d4abb58444c440509a8495a7f5ebc589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235664
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35246}
Also stop using ApplyConfig() and in [1] fix the build errors when
WEBRTC_EXCLUDE_AUDIO_PROCESSING_MODULE is defined.
[1] modules/audio_processing/test/audio_processing_builder_for_testing.cc
Bug: webrtc:5298
Change-Id: I50dc5668b952e7ca7fa83c7a5182c013e928c450
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235365
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35228}
Unlike ReadBits, ConsumeBits doesn't limit number of bits it may advance,
and thus should work when that number is close to the integer limit
Bug: chromium:1250730
Change-Id: Ia7847869ef9d3fc16450d572c9e2be6e1aa36741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232332
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35042}
Thanks to the elimination of `ExperimentalNs`, there is no need anymore
to pass `webrtc::Config` to build APM.
Hence, `AudioProcessingBuilder::Create(const webrtc::Config&)` is also
removed.
Bug: webrtc:5298
Change-Id: I0a3482376a7753434486fe564681f7b9f83939c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232128
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35025}
This is tested by a simple unit test and a new fuzzer that verify that all that can be parsed also can be written.
Bug: webrtc:12000
Change-Id: I461aedf97d3dec6e8916e72110fa097c3b31c27f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231642
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34986}
The VP9 encoder may drop a frame internally which will not advance the
frame pattern. Consider the following scenario where only spatial layer
0 and temporal layer 0 is active:
1. Key frame encoded
2. Spatial layer 1 is activated
3. Delta T0 dropped
4. Delta T0 encoded
No S1T0 frame is encoded in (1) since it's not active. When
NextFrameConfig is called in (3) it will say that future frames may
reference T0 on both S0 and S1, but it's then dropped.
On step (4), the SVC controller essentially thinks it's encoding a new
picture and will happily reference the T0 on what it thinks is the first
delta frame. However, this is actually still the key frame and since
there was no S1T0 frame produced it will reference an invalid buffer.
To fix this, only say it's possible to reference a T0 frame after it has
been successfully encoded.
Bug: webrtc:11999, webrtc:13142, chromium:1178444
Change-Id: Iab3d2042ce0b3fa7d952b2831d1a36b1a6613a86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34982}
With the new SVC controller this will hopefully help uncover more subtle
bugs.
Bug: webrtc:11999
Change-Id: Iab76d38b3fb8dfbbeb269f4ba1e74f6f425501f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231694
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34981}
