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
This uses sync groups in the receive stream configs for the conduits rather
than establishing sync through direct calls. When the streams are created
in call.cc, ConfigureSync is called, which results in SetSync being called
on the video stream which is the replacement for SetSyncChannel in branch 57
of webrtc.org.
With the current code, a video stream can only be synchronized to a single
audio stream. Using sync groups enforces a stronger constraint that only one
pair of audio and video streams can be synchronized for each sync group. The
comments in call.cc imply this is what is supported by webrtc.org, it seems
safer to also follow this constraint rather than circumvent it by calling
directly into the underlying code.
Differential Revision: https://phabricator.services.mozilla.com/D7445
--HG--
extra : rebase_source : fa8b1d301398edcedc6e488c51009b6667792f45
We went through a lot of trouble to plumb the CPULoadState down to
MediaOptimization, but the value is not actually used for anything, at least
since the Branch 57 update. This removes the plumbing, since it seems we are
getting along ok without it.
Differential Revision: https://phabricator.services.mozilla.com/D7443
--HG--
extra : rebase_source : e8f7c8b313d37ea3383a9eb16a6cc573844762cd
The only use of Mid in the current webrtc.org code is in the unit tests.
RtpStreamReceiverController only allows adding sinks using SSRCs. Because
of this, we'll end up dropping packets in the RtpDemuxer with the current
code as none of our Mids will be recognized.
Tip of webrtc.org fully supports using Mids, so we'll be able to enable this
code again after the next update.
Differential Revision: https://phabricator.services.mozilla.com/D7442
--HG--
extra : rebase_source : 89d0f100bfa8bf7c050f6176f21dc2c829503d82
