Upstream commit: https://webrtc.googlesource.com/src/+/301e546a689020320f919a660591759e993ef051
Remove SequenceCheckerImpl::valid_system_queue_
As pointed out in issue webrtc:15146 this Mac/iOS specific variable,
makes the SequenceChecker behave incorrectly on those platforms.
The variable was introduced in a CL that merged the previous checker
classes, ThreadChecker and SequencedTaskChecker, but curiously neither
one of them had such a variable. So I'm not exactly sure what problem
was being solved. Hence I'm wondering if we actually need it.
Reference: https://webrtc-review.googlesource.com/c/src/+/129721
Bug: webrtc:15146
Change-Id: Ia7a9eb17b993c4f8a1e8204c658bf0b3dbdaa1e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304401
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40019}
Differential Revision: https://phabricator.services.mozilla.com/D177875
Upstream commit: https://webrtc.googlesource.com/src/+/3da04a93cd18dc7b65c6756910cc8a9cbf20fb8c
Allow SequenceChecker to be initialized detached.
The motivation for this is to not have to implement this pattern:
foo.h:
class Foo {
public:
Foo();
private:
SequenceChecker checker_;
};
foo.cc:
Foo::Foo() {
checker_.Detach();
}
And instead be able to do this inline in the .h file:
class Foo {
public:
Foo();
private:
SequenceChecker checker_{SequenceChecker::kDetached};
};
Bug: none
Change-Id: Idd7ca82d15c2f77f3aaccf26f1943a49f4b40661
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298445
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39616}
Differential Revision: https://phabricator.services.mozilla.com/D177874
It brings, among other things, support for MSVC 2022. It also fixes a
number of issues we had local patches for, but we still need to apply
the patches from bug 1628954 and bug 1722540.
Differential Revision: https://phabricator.services.mozilla.com/D178240
This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
Upstream commit: https://webrtc.googlesource.com/src/+/a09331a6038bb6191c7662680d8928940463a099
Don't write TransmissionOffset when capture time is not set
RTX padding packets sent before media packets can legitimately have no
timestamps set (they are 0). Writing the TransmissionOffset extension
with capture time 0 will overflow once current time exceeds ~3 minutes.
Bug: webrtc:15172
Change-Id: I4dd1f341802d45016549b330f0e08cd3a00cfa19
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305020
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40055}
Differential Revision: https://phabricator.services.mozilla.com/D178007
Upstream commit:
PipeWire capturer: fix fcntl call when duplicating a file descriptor
The fcntl() call has variable arguments, therefore we need to pass 0 to
specify there are no other arguments for this call, otherwise we might
end up with an argument that is random garbage.
Bug: webrtc:15174
Change-Id: I34f16a942d80913b667d8ade7eed557b0233be01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305120
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40060}
Differential Revision: https://phabricator.services.mozilla.com/D178009
Set a default journal_size_limit, so journals are always truncated to a sensible
max size. Change existing consumers to just use the default, but Places that is
using a larger 4MiB limit.
Change auxiliary files (-shm, -journal, -wal, ...) persistance on disk, to
avoid the cost of creating and removing them. Since there is a journal_size_limit
they will be truncated instead of deleted.
Differential Revision: https://phabricator.services.mozilla.com/D172185
It doesn't seem to have had any useful purpose back when the file was
added in bug 792188, and it sure doesn't have any right now, except
subtly breaking things by removing any `inline` from system headers,
with consequences on the definition of what should be COMDATs,
ultimately leading to link failure.
This is, in fact, very similar to bug 918943, which hid the #define in
some configurations.
Differential Revision: https://phabricator.services.mozilla.com/D177710
Prior to this patch timestamps are not adjusted when they are 0, and they are 0
when the packet sequencer has not yet seen a media packet. Code and comments in
PacketSequencer and RTPSender::GeneratePadding make it clear that rtx padding
packets are allowed prior to seeing a media packet, and therefore the 0
timestamp case has to be handled.
For rtx the padding packets do not need to have the same timestamp as any media
packets, like plain padding packets do -- because they can only be part of a media
frame, so a media packet has to be known.
With this patch both rtp timestamps and capture timestamps are set to current
time when sequencing rtx padding packets without having seen a media packet.
This fixes a DCHECK failure in TransmissionOffset::Write.
Differential Revision: https://phabricator.services.mozilla.com/D177306
Upstream commit: https://webrtc.googlesource.com/src/+/b1a174041ddf3057f5d6d2f87affa0f11f9413df
Relax VideoCaptureImpl::IncomingFrame size check
When testing manually with gstreamer and v4l2loopback, the incoming
buffer is often larger than the expected size. This change allows
such frames, while still logging the error.
Bug: webrtc:14830
Change-Id: I399aa55af6437d75b50830166a667547f6d144d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291530
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39972}
Differential Revision: https://phabricator.services.mozilla.com/D177230
Emilio Cobos Álvarez
Erich Gubler
Paul Adenot
Eemeli Aro
Andreas Pehrson
Michael Froman
Butkovits Atila
Tiaan Louw
Updatebot
Cosmin Sabou
Mike Hommey
Natalia Csoregi
John Schanck
Sebastian Hengst
Tom Marble
Marco Bonardo
Jan-Erik Rediger
serge-sans-paille
nicklas boman
Shravan Narayan