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}
This is a reland of 3097008de03b6260da5cfabb5cbac6f6a64ca810
Patchset 1 is a pure reland. Patchset 2 contains a bugfix plus a test
covering that case.
Bug: webrtc:12354, chromium:1230448
Original change's description:
> Rename vp9::FrameInfo to vp9::UncompressedHeader and add more fields.
>
> These fields will be used for bitstream validation in upcoming CLs.
> A new vp9_constants.h file is also added, containing common constants
> defined by the bitstream spec.
>
> Bug: webrtc:12354
> Change-Id: If04256d83409069c8bee43ad41aed41c3707dfd3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226060
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Philip Eliasson <philipel@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34476}
Bug: webrtc:12354
Change-Id: Ibd301eb458a6104b562cefbc0e616c39b54fb38b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229060
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34789}
This reverts commit 9e09831767995531ae1c2804e1c15fa2be4053f2.
Reason for revert: The "fuzzer_test" GN template expanded by
"webrtc_fuzzer_test" still ignores the "configs" and another
field needs to be used.
Original change's description:
> Make webrtc_fuzzer_test use //:common_config.
>
> Before this CL, the GN template webrtc_fuzzer_test was using a build
> config that was different from the one used by other WebRTC's targets.
>
> We discovered this in [1] where we detected that RTC_DCHECK_IS_ON had
> different values across translation units (1 everywhere and 0 in the
> one of the .cc file owned by the webrtc_fuzzer_test).
>
> This was because webrtc_fuzzer_test was not including the default
> config //:common_config in its "configs".
>
> [1] - https://webrtc-review.googlesource.com/c/src/+/226465
>
> Bug: None
> Change-Id: I5635d90281769c23c5d86ebc8cb494da029c2e85
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226540
> Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34509}
TBR=mbonadei@webrtc.org,landrey@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Iec13b411e7f027e78e731e3242e0557b6de38a2b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226541
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34510}
Before this CL, the GN template webrtc_fuzzer_test was using a build
config that was different from the one used by other WebRTC's targets.
We discovered this in [1] where we detected that RTC_DCHECK_IS_ON had
different values across translation units (1 everywhere and 0 in the
one of the .cc file owned by the webrtc_fuzzer_test).
This was because webrtc_fuzzer_test was not including the default
config //:common_config in its "configs".
[1] - https://webrtc-review.googlesource.com/c/src/+/226465
Bug: None
Change-Id: I5635d90281769c23c5d86ebc8cb494da029c2e85
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226540
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34509}
Making a copy of that information takes noticable amount of time
causing fuzzer timeout for larger inputs, but that extra information
is not even used.
Bug: chromium:1217944
Change-Id: Icf9d43ae4b8feddda972daf3a4743fb73f7766d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221962
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34271}
