Deletes all webrtc usage of this member. Next step is to delete
any downstream references, and when that's done, the member can be
deleted.
Bug: None
Change-Id: I3f3a94a063dccf56468a1069653efd3809875b01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/181201
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31911}
This way can double adapt right away instead of relying
on the qp scaler checking soon into the future.
Bug: webrtc:11830
Change-Id: I8e878168303cf6a4c3edcf3997dd8ac2413a4479
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/181060
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#31895}
This is a reland of 32ca95145c4636374266f5b5d4d1ac43658bc758
Fix includes not enabling the screenshare conference behavior on non
screenshare sources even if the flag is enabled.
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
Bug: webrtc:11310
Bug: chromium:1093819
Change-Id: Ic933f93a5c4bad20583354fe821f8a1170e911cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180802
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31847}
and do not generate redundancy for packets that are larger
than 1024 bytes which is the maximum size red can encode.
Bug: webrtc:11640
Change-Id: I211cb196eee2a0659f22a601a6dee4b7dd4e5116
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178781
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31846}
This change fixes two cases of encountered mutex re-entries.
Bug: webrtc:11821
Change-Id: Iaef730e4233a79b0d1b2bf6a17fe3f14e2558e98
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180800
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31831}
This reverts commit 32ca95145c4636374266f5b5d4d1ac43658bc758.
Reason for revert: Internal test failure
Original change's description:
> Only enable conference mode simulcast allocations with flag enabled
>
> Non-conference mode simulcast screenshares were mistakenly using the
> conference mode semantics in the simulcast rate allocator, which broke
> spec compliant usage in some situation.
>
> This behavior should only be used when explicitly using the SDP entry
> "a=x-google-flag:conference" in both offer and answer.
>
> Bug: webrtc:11310, chromium:1093819
> Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31828}
TBR=ilnik@webrtc.org,hta@webrtc.org,orphis@webrtc.org
Change-Id: I5ccb6e87594f491ba09fe6b837ee24d63db878ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11310
Bug: chromium:1093819
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180801
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31829}
Non-conference mode simulcast screenshares were mistakenly using the
conference mode semantics in the simulcast rate allocator, which broke
spec compliant usage in some situation.
This behavior should only be used when explicitly using the SDP entry
"a=x-google-flag:conference" in both offer and answer.
Bug: webrtc:11310, chromium:1093819
Change-Id: Ibcba75c88a8405d60467546b33977a782e04e469
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31828}
Internal counters in the RenderDelayBuffer can slip out of sync with external counters, leading to buffer misalignment.
This CL gives the RenderDelayBuffer an opportunity to update its counters.
Tested:
Passes: modules_unittests --gtest_filter=BlockProcessor.*
Fails as expected due to new unit test: modules_unittests --gtest_filter=BlockProcessor.* --force_fieldtrials="WebRTC-Aec3RenderBufferCallCounterUpdateKillSwitch/Enabled/"
audioproc_f with default AEC settings has been verified to be bit-exact on a large number of aecdumps.
Bug: webrtc:11803
Change-Id: I9363b834c8c8c934add0335013df60bf131da4bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180126
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31795}
The time precision of delayed tasks is one millisecond, so the
TaskQueuePacedSender makes sure that is the minimum sleep time, and
then allows sending prior data as if it was on time.
Furthermore, if there already exists a pending task within 1ms of a
new desired process time - we don't schedule a new one with the same
motivation as above.
These two facts clashes somewhat with how BitrateProber works, and
especially if they coincide it can result in scheduled ProcessPackets()
that is 2ms late. The default timeout set in BitrateProber is 3ms, so
there is a higher risk of probes timing out.
This CL changes the TaskQueuePacedSender to allow scheduling a
ProcesPackets() call as soon as possible if we are probing - even if
that means executing up to 1ms earlier than expected (the BitrateProber
will compensate for that). The PacingController is updated in order to
allow early execution in this one case.
Bug: webrtc:10809
Change-Id: Ia5097ddc39aa80c05ebfe56369310c94ef0e0baf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178901
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31778}
It is not longer needed by the rtp_rtcp module.
Bug: webrtc:6471
Change-Id: I89a4374a50c54a02e9f20a5ce789eac308aaffeb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179523
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31773}
i.e. when chain are used,
require each decode target to be protected by some chain.
where previously it was allowed to mark decode target as unprotected.
See https://github.com/AOMediaCodec/av1-rtp-spec/pull/125
Bug: webrtc:10342
Change-Id: Ia2800036e890db44bb1162abfa1a497ff68f3b24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178807
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31772}
No need to keep error_resilience 1 for layers in AV1
Bug: None
Change-Id: I6570d653a34ed2187307154ccdfd9e941ed8f917
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179742
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Commit-Queue: Jerome Jiang <jianj@google.com>
Cr-Commit-Position: refs/heads/master@{#31769}
A packet's capture time may be -1 to indicate an unset value. We need to
check that this is the case before adjusting it when generating padding.
Otherwise, invalid values will result.
Bug: webrtc:11615
Change-Id: Ibbeb959f1d4d37dd4d65702494b97246642b57d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176281
Commit-Queue: Dan Minor <dminor@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31766}
This avoids a difference in behaviour between mobile and
desktop platforms since the bitrate is now too low for
CELT mode.
BUG=webrtc:11643
Change-Id: I9ac1439bea0ccbbfee7388516932e30d6cb06bf4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179522
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#31757}
This CL adds a parameter to the BirateProber field trial config, which
allows the prober to actually discard probe cluster is pacer scheduling
is too delayed. Today it just keeps going at a too low rate.
Some refactoring was needed anyway, so also switch to using unit types
in more places.
Initially keeps legacy behavior default, to verify no perf regressions.
Bug: webrtc:11780
Change-Id: I9edd114773b10a8d86b54a1a0398a4052aab9dd5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179090
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31756}
This name change communicates that the recursive critical section
should not be used for new code.
The relevant files are renamed rtc_base/critical_section* ->
rtc_base/deprecated/recursive_critical_section*
Bug: webrtc:11567
Change-Id: I73483a1c5e59c389407a981efbfc2cfe76ccdb43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179483
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31754}
This change implements the GetSourceList and SelectSource APIs from the
DesktopCapturer interface for WindowCapturerWinWgc. No functional
changes were made as the WGC capturer is not in use yet.
I refactored the source enumeration functionality out of the GDI
capturer and into the utils file, so both of the capturers can share
the implementation.
This change also renames the window capturers to include Win in the
name, and updates some of the out dated code style.
I've tested these changes by running the related unit tests and
applying them to a Chromium enlistment and testing on
https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/
Bug: webrtc:9273
Change-Id: If0ca023cb13900ab2b897aec0f38333f75a1b748
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178960
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#31748}
instead reparse nalu boundaries from the bitstream.
H264 is the last use of the RTPFragmentationHeader and this would allow
to avoid passing and precalculating this legacy structure.
Bug: webrtc:6471
Change-Id: Ia6e8bf0836fd5c022423d836894cde81f136d1f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178911
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31746}
This is a reland of 44dd3d743517fe85212ba4f68bda1e78c2e6d7ec
Original change's description:
> Migrate modules/desktop_capture and modules/video_capture to webrtc::Mutex.
>
> Bug: webrtc:11567
> Change-Id: I7bfca17f91bf44151148f863480ce77804d53a04
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178805
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31681}
Bug: webrtc:11567
Change-Id: I03a32cb7194cffb9e678355c4af4d370b39384b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179093
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31716}
This change lays the foundation for the new DesktopCapturer
implementation which will use the Windows.Graphics.Capture API.
In line with the other platform specific DesktopCapturer
implementations, I've moved the actual implementations into the win/
subdirectory and repurposed window_capturer_win.cc to instantiate
the most appropriate implementation. This will be where the WebRTC
field trial (or similar mechanism) and Windows version checks will go
when we begin to roll out the new implementation.
I've verified that the existing window capture functionality still works
by dropping these changes into the third_party/webrtc folder of a
Chromium enlistment, going to
https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/
and stepping through this new path under a debugger, and running the
existing WindowCapturerTests.
The next change in this series will begin to add functionality to the
new window_capturer_win_wgc files.
Bug: webrtc:9273
Change-Id: Ifc36ec69aed19563b9c20ef022760fb9c45cae25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178403
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31690}
