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
This brings the changes from Bug 1286429 that were made to the older
mac/avfoundation video capture code to the newer objc video capture
code.
Depends on D15196
Differential Revision: https://phabricator.services.mozilla.com/D15197
--HG--
extra : moz-landing-system : lando
This code is no longer used and has been removed upstream. We can remove
it as well.
Differential Revision: https://phabricator.services.mozilla.com/D15196
--HG--
extra : moz-landing-system : lando
The value for mozAvSyncDelay has been broken since the branch 57 update
(Bug 1341285). We added SetCurrentSyncOffset() but never called it from
anywhere.
In the future we should be getting stats from AudioReceiveStream rather than
modifying the channel code, the delay_estimate_ms field provides almost the
same information.
Since we're attempting to get rid of moz prefixed stats, it makes sense to just
remove this code rather than fix it. The associated telemetry code has been
broken since Bug 1341285 as well so I think it is safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D14462
--HG--
extra : moz-landing-system : lando
The affected functions are only used by VCMJitterBuffer, which is the older
jitter buffer that is no longer in use. We can safely remove these
modifications.
Differential Revision: https://phabricator.services.mozilla.com/D14485
--HG--
extra : moz-landing-system : lando
This ends up calling VCMReceiver::Reset() which resets the
state of the VCMJitterBuffer. We no longer use VCMJitterBuffer,
which is the old jitter buffer implementation, so this code
no longer has any effect and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D14185
--HG--
extra : moz-landing-system : lando
In Bug 919979 we added 100 bytes to the size returned by CalcBufferSize
to work around an error with the calculated buffer size with small
resolutions. I verified that this extra buffer is no longer required with
a modified mochitest. Given the age of the bug this was working around,
I don't think a permanent test is required to prevent regressions from
upstream.
Differential Revision: https://phabricator.services.mozilla.com/D14076
--HG--
extra : moz-landing-system : lando
These modifications are made to code which we do not use and so
can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D13989
--HG--
extra : moz-landing-system : lando
This removes disable_composition_ and instead uses the value of
composition_func_ to determine whether or not composition is
disabled. This is what is done by upstream webrtc.org.
We call options.set_disable_effects(false) in desktop_capture_impl.cc.
Differential Revision: https://phabricator.services.mozilla.com/D13839
--HG--
extra : moz-landing-system : lando
This test started failing after the 57 update and started passing
again after the 64 update, so we might as well enable it.
Differential Revision: https://phabricator.services.mozilla.com/D13803
--HG--
extra : moz-landing-system : lando
PlatformUIThread is only used by the video_engine code, so it makes sense to
move it there rather than maintain it as a diff against upstream webrtc.org.
Differential Revision: https://phabricator.services.mozilla.com/D13531
--HG--
extra : moz-landing-system : lando
This code was added by Bug 1196542 to fix a permanently failing test on our
Windows test machines. After this landed, upstream added a check for empty
windows in window_captuer_win.cc, so this should no longer be a problem on
Windows. As far as I know, this was never a problem on the other platforms,
so this code can be safely removed.
Differential Revision: https://phabricator.services.mozilla.com/D13448
--HG--
extra : moz-landing-system : lando
Assertions in NetEqImpl::SetSampleRateAndChannels prevent us from requesting
tones at 44100 Hz, so this code can be safely removed.
Differential Revision: https://phabricator.services.mozilla.com/D12982
--HG--
extra : moz-landing-system : lando
This enables support for the DirectX screen capturer. We use the default
DesktopCaptureOptions which do not set the option to use the DirectX screen
capturer so this change will have no effect with the current code.
For what it's worth, I tested enabling the DirectX option and it worked fine on my
system, but I don't see any reason to not follow the defaults provided by
webrtc.org in this case.
Differential Revision: https://phabricator.services.mozilla.com/D13303
--HG--
extra : moz-landing-system : lando
Historically this code was part of webrtc.org but has since been removed
from upstream. Rather than maintaining it as a local diff against upstream,
we should just move it to where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D13092
--HG--
rename : media/webrtc/trunk/webrtc/video_engine/browser_capture_impl.h => dom/media/systemservices/video_engine/browser_capture_impl.h
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.cc => dom/media/systemservices/video_engine/desktop_capture_impl.cc
rename : media/webrtc/trunk/webrtc/video_engine/desktop_capture_impl.h => dom/media/systemservices/video_engine/desktop_capture_impl.h
extra : moz-landing-system : lando
Summary:
The current default stack size of 1M results in intermittent OOMs on win32
builds while running web-platform tests. The value of 256k was chosen for
consistency with the default value used elsewhere in Gecko, which is defined in
nsIThreadManager.idl.
Reviewers: bwc
Tags: #secure-revision
Bug #: 1376873
Differential Revision: https://phabricator.services.mozilla.com/D11090
--HG--
extra : rebase_source : 9039a5c4ac25c227ee65b0321fdffdecd81d085c
This fixes a bug in the upstream code introduced when they removed the
ConvertToI420 helper method from webrtc_libyuv.cc. The buffer size is
passed into libyuv::ConvertI420 incorrectly when rotation is applied, which
causes bad rendering and instabilities.
Differential Revision: https://phabricator.services.mozilla.com/D7478
--HG--
extra : rebase_source : d6910e01ebd81a626b6924f04b31f37b87900a66
Windows ASAN builds complain about attempting to cast away the const qualifier
in FunctionThatDoesNothing, so this makes the argument const.
Differential Revision: https://phabricator.services.mozilla.com/D7477
--HG--
extra : rebase_source : dbfa0a48f50c30afa5a41b81af32bd9744a31511
