Removes calls to the win32k API.
Replaces hardware and event timers with waitable timers.
Removes handling various task objects through the thread message queue.
Removes ProcessQueuedMessages, CancelTimers functions.
Adds event handle for stopping the TaskQueue thread.
Adds ReplyHandler class as an in between for TaskQueue objects to post tasks to each other without worrying if the other TaskQueue remains valid.
Adds rtc::CriticalSection's for timer_tasks_.
Removes ThreadState scoped class.
Differential Revision: https://phabricator.services.mozilla.com/D43480
--HG--
extra : moz-landing-system : lando
PhysicalSocketServer isn't currently used by Mozilla's WebRTC
integration, but just in case, let's make sure that this array index is
bounds-checked in actual use, not just in debug builds (which tend to
never see realistic test conditions).
Differential Revision: https://phabricator.services.mozilla.com/D52745
--HG--
extra : moz-landing-system : lando
The use of select() was leading to crashes when the file descriptor value was
larger than FD_SETSIZE. Recent versions of glibc have checks in the FD_CLR(),
FD_SET() and FD_ISSET() macros that will abort() the program instead of doing
an out-of-bounds access. poll() doesn't have limitations on the file
descriptor values and provides behavior that is otherwise identical to
select() thus solving the problem.
Differential Revision: https://phabricator.services.mozilla.com/D50798
--HG--
extra : moz-landing-system : lando
The code for handling backwards wraps left shifts num_wrap_ - 1. If
num_wrap_ is zero, this results in a left shift of a negative value which
is undefined behaviour. This modifies the code to avoid the shift at the cost
of an extra multiplication.
Differential Revision: https://phabricator.services.mozilla.com/D49609
--HG--
extra : moz-landing-system : lando
These have already been fixed upstream. The upstream comment was: "Negative
overflow is permitted here, because this is auto-regressive filters, and the
state for each batch run is stored in the "negative" positions of the output
vector."
Differential Revision: https://phabricator.services.mozilla.com/D48884
--HG--
extra : moz-landing-system : lando
Left shifting a negative value results in undefined behaviour. It is safer to
multiply in this case.
Differential Revision: https://phabricator.services.mozilla.com/D48751
--HG--
extra : moz-landing-system : lando
There is a window inside of SendPacket where the critical section is released
which means that other code could set paused_. This would lead to us hitting
the assertion at the top of SendPacket. Checking paused_ in the while loop
will avoid this. Upstream has fixed this problem in a similar way, but the
code has changed there enough that it doesn't make sense to try to bring in
their fix directly.
Differential Revision: https://phabricator.services.mozilla.com/D48540
--HG--
extra : moz-landing-system : lando
This is a partial cherrypick of https://webrtc.googlesource.com/src/+/f89110d67902e787f6745ad2b52f7f09fc808512.
The cropping changes in that revision are problematic on our version of webrtc.org and
result in distorted video, which looks as though there is a stride problem. This takes
the change to try to use PW_RENDERFULLCONTENT and to fall back to the current code if
that fails. This fixes capturing Chrome windows and allows Firefox to properly capture
its own window.
Using PW_RENDERFULLCONTENT can adversely affect performance. Using the
CroppingWindowCapturer can avoid using the WindowCapturer in some circumstances and so
result in better performance. Bug 1586071 tracks switching to the
CroppingWindowCapturer.
Differential Revision: https://phabricator.services.mozilla.com/D48108
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the windows part.
Differential Revision: https://phabricator.services.mozilla.com/D46274
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the OSX part.
Differential Revision: https://phabricator.services.mozilla.com/D46273
--HG--
extra : moz-landing-system : lando
Video capture used to provide device change notifications for audio and video devices. From now on, CubebDeviceEnumerator will provide audio device change notifications thus video capture is updated to notify only changes of the video device. This is the Linux part.
Differential Revision: https://phabricator.services.mozilla.com/D46272
--HG--
extra : moz-landing-system : lando
After Bug 1581193 devicechange notifications were triggered with any device change, not just video and audio devices. This patch limits down the notifications to only video and audio input devices change.
Differential Revision: https://phabricator.services.mozilla.com/D46147
--HG--
extra : moz-landing-system : lando
This restores the code for generating devicechange events that was
accidentally removed as part of updating the Windows video capture code
in Bug 1552755.
Differential Revision: https://phabricator.services.mozilla.com/D46033
--HG--
extra : moz-landing-system : lando
In OnIncomingFrame() we check if the capture has started by calling
CaptureStarted() which holds a lock. If StopCapture() is called on the
control thread after we check CaptureStarted() it is possible that
_captureCapability will be zeroed out prior to frame being delivered because
the lock has been released. This would result in an unknown video type in
CalcBufferSize() and trigger an assertion there. This creates a local copy of
_captureCapability with the lock held to ensure it is not zeroed out when the
frame is delivered.
Differential Revision: https://phabricator.services.mozilla.com/D42338
--HG--
extra : moz-landing-system : lando
A few small changes are required to backport the updated windows capture code
to our version of webrtc.org. These are largely path changes, but
DetachFromThread has been renamed to Detach, and they seem to have a working
overload for ostream operator<< for VideoType that I have not been able to
track down. It is also necessary to add our local modification for pid_t back
to the GetDeviceName method, but it is not used for video capture anyways.
Depends on D33337
Differential Revision: https://phabricator.services.mozilla.com/D33338
--HG--
extra : moz-landing-system : lando
This was added in commit 74395345e8d2fecd504cb687eb79deee4ef394c3, but this
only cherry picks the ToHex part of that commit.
Depends on D33336
Differential Revision: https://phabricator.services.mozilla.com/D33337
--HG--
extra : moz-landing-system : lando
This updates just video_capture/windows to the tip of webrtc.org, from commit
8581877121f58435d683c2a39a73e72e5dcd558a.
This removes the locking which was leading to the deadlock in Bug 1552755. It
also removes the reliance upon the DirectShow example code which lead to our
local implementations of BaseFilter, BaseInputPin, BasePin, and MediaType.
These can now be removed.
Differential Revision: https://phabricator.services.mozilla.com/D33336
--HG--
extra : moz-landing-system : lando
This is a cherry pick of upstream commit c1187ab34bdf836bd33f7f050d525184eba4cd20.
Differential Revision: https://phabricator.services.mozilla.com/D32826
--HG--
extra : moz-landing-system : lando
This removes all references to application capture except from MediaSourceEnum.
That was left in place so as to not change the enumerated values used
for WEBRTC_GET_USER_MEDIA_TYPE telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D28089
--HG--
extra : moz-landing-system : lando
This removes references to abseil which is not yet used by the version of
webrtc.org in tree. It also removes a duplicate definition of a kBytesPerPixel,
which is probably results from our use of unified builds.
With these changes and some hacking of moz.build files I was able to get the
pipewire support to compile but not link. I don't have an environment set up
to build and test this properly, so I didn't take it any further.
Depends on D27373
Differential Revision: https://phabricator.services.mozilla.com/D27374
--HG--
extra : moz-landing-system : lando
This define is not set in the current gn generated json and moz.build files.
If I rerun gn, this define ends up being set, and the build will fail with
a variety of link time errors.
My guess is that enable_iterator_debugging was not set when I last ran gn for
x64 Linux, and that it was subsequently enabled without regenerating the gn
files and noticing that it causes problems.
Differential Revision: https://phabricator.services.mozilla.com/D27367
--HG--
extra : moz-landing-system : lando
We've hit a number of problems with handling of RGB24 video capture on
Windows. This adds a check that will ignore any RGB24 capture capabilities
when determining a best match if there are other capabilities available to
workaround the problems.
Differential Revision: https://phabricator.services.mozilla.com/D25449
--HG--
extra : moz-landing-system : lando
In the past we relied upon ViEEncoder::OnFrame to set the render time for
frames. With the branch 64 update, this code moved to
VideoStreamEncoder::OnFrame, and only sets the timestamp if it is greater than
the current time. This results in broken rtp timestamp estimates in the rtcp
sender report, which causes problems for Meet and possibly other services
that rewrite rtp timestamps based upon the sender report.
This patch explicitly sets the timestamp in MediaPipeline. This should give us
the same behaviour that we had before the branch update without requiring local
modifications to upstream code. This leaves the rtp timestamp as zero as that
was not being set before.
This also removes an unused overload of the VideoFrameConverted method.
Differential Revision: https://phabricator.services.mozilla.com/D20517
--HG--
extra : moz-landing-system : lando
RTP audio jitter stat is not updating because the playout frequency isn't being set
Differential Revision: https://phabricator.services.mozilla.com/D20530
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
In the past we relied upon ViEEncoder::OnFrame to set the render time for
frames. With the branch 64 update, this code moved to
VideoStreamEncoder::OnFrame, and only sets the timestamp if it is greater than
the current time. This results in broken rtp timestamp estimates in the rtcp
sender report, which causes problems for Meet and possibly other services
that rewrite rtp timestamps based upon the sender report.
This patch makes VideoStreamEncoder::OnFrame always set the timestamp. In a
follow on bug, we'll move this behaviour to VideoConduit so we don't have to
maintain a local modification of the upstream code.
Differential Revision: https://phabricator.services.mozilla.com/D17413
--HG--
extra : moz-landing-system : lando
