The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
The only difference between ShutdownLoaders and ShutdownFinal was an observer service shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D18389
--HG--
extra : moz-landing-system : lando
aarch64 ABI supports NEON as default, so we should turn on NEON code for
aarch64. Also, libopus's NEON code doesn't support MSVC yet.
Differential Revision: https://phabricator.services.mozilla.com/D17332
--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
To use NEON on Linux/aarch64 and Android/aarch64, I would like to add it to
libvpx. libvpx has a configuration as arm64-linux-gcc.
Differential Revision: https://phabricator.services.mozilla.com/D15400
--HG--
extra : moz-landing-system : lando
We weren't checking this value and it was causing compiler warnings. Instead
this change means we check the value and log an error if init has failed.
Differential Revision: https://phabricator.services.mozilla.com/D15519
--HG--
extra : moz-landing-system : lando
Not much changed in the interface:
- CDM initialization takes a use hardware codecs arg, we pipe this through, but
don't do anything more with it in the clearkey CDM.
- The CDM should call the hosts OnInitialized() when it's initialized. This is
done is now done in the clearkey CDM once the session management is ready, as
that is the last thing done during init.
Aside from the above, it's just updating interface usage. While the new CDM
interface adds support for different encryption schemes, this is not handled
here and will be done in follow up bug 1516673.
Differential Revision: https://phabricator.services.mozilla.com/D15518
--HG--
extra : moz-landing-system : lando
Bug 1502899: Allow provisional transceiver level assignments to be recovered by rollback.
Differential Revision: https://phabricator.services.mozilla.com/D10290
--HG--
extra : moz-landing-system : lando
This also moves the corresponding ASFLAGS from moz.build to python
configure.
Differential Revision: https://phabricator.services.mozilla.com/D16320
--HG--
extra : moz-landing-system : lando
This adds a way to simulate failed network connections, allowing the addition of test coverage that would otherwise not be available. This is used in the Downloads tests to ensure that failures at the network level are handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D15522
--HG--
extra : rebase_source : 2597b27de5213b0322520cefafe10a197d0d3b83
This also removes some unused member variables.
Differential Revision: https://phabricator.services.mozilla.com/D25056
--HG--
extra : rebase_source : ec18c54b81dc96850e6d2b5e1673dea5ed6bb949
extra : source : 1ffa990b25e37691e53fdef6604411bb5241b03d
extra : histedit_source : cb3b5b526b6aa4ccfca1c789612b3cdc8a2b6716
This was added during the branch 64 update, but was not documented at that time.
Differential Revision: https://phabricator.services.mozilla.com/D25054
--HG--
extra : rebase_source : 49d7be8d1db97edcd601ff3a0e502521c21e87ad
extra : source : 6c4544bfbe7262555ca7154f3367ad24d7b55669
extra : histedit_source : baa8da9d12766ff9ea133aed356832f273de8431
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
libpng has NEON support using intrinsics, not assembler, so we should use it
even if aarch64.
MSVC build still turns off NEON since libpng doesn't support it on stable
version although upstream has it.
Differential Revision: https://phabricator.services.mozilla.com/D15462
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Removes RTP stat field isRemote and adds the new types remote-inbound-rtp, and remote-outbound-rtp
Differential Revision: https://phabricator.services.mozilla.com/D15068
--HG--
extra : moz-landing-system : lando
Removes RTP stat field isRemote and adds the new types remote-inbound-rtp, and remote-outbound-rtp
Differential Revision: https://phabricator.services.mozilla.com/D15068
--HG--
extra : moz-landing-system : lando
There's only really one place where it's used, and we can "inline" it
there.
Depends on D14947
Differential Revision: https://phabricator.services.mozilla.com/D14948
--HG--
extra : moz-landing-system : lando
There aren't any, and the code to actually convert them from .asm to gas
that is expected by the moz.build is not even there, so if there were
assembly sources, it would fail to build.
Depends on D14946
Differential Revision: https://phabricator.services.mozilla.com/D14947
--HG--
extra : moz-landing-system : lando
It is only used in one place, where it is redundant with VPX_AS_CONVERSION.
Depends on D14945
Differential Revision: https://phabricator.services.mozilla.com/D14946
--HG--
extra : moz-landing-system : lando
This initializes a one of the stats that lost its default initialization when it was changed from an Atomic to a plain old int.
Differential Revision: https://phabricator.services.mozilla.com/D14978
--HG--
extra : moz-landing-system : lando
In libavcodec 58 and later, the old avcodec_decode_video2 is broken and only return the first visible frame found after a VP9 super-frame.
This resulted in some YouTube videos for about 10% of the frames to never be returned.
Only the new API properly behaves so we upgrade our code to use it.
Differential Revision: https://phabricator.services.mozilla.com/D14682
--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
CreateEncoderStreams is called from VideoStreamEncoder::ReconfigureEncoder
which does not check that at least one stream is returned prior to accessing
one of the streams. This would most likely result in a runtime check failing
in ReconfigureEncoder. This adds a runtime assertion in CreateEncodeStreams
that will check that at least one stream is created. This is better than
undefined behaviour in ReconfigureEncoder.
Differential Revision: https://phabricator.services.mozilla.com/D14281
--HG--
extra : moz-landing-system : lando
The RTCP timestamps have different timebases and reporting sources, this makes the source and timebase the same for all RTCP stats
Differential Revision: https://phabricator.services.mozilla.com/D7354
--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
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--HG--
extra : moz-landing-system : lando
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--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
Port restriction is delegated to the io service. Port 0 is explicitly
unrestricted.
NS_CheckPortSafety emits a warning which pollutes the gtests a bit. It is only
tested if the port is not 0.
Differential Revision: https://phabricator.services.mozilla.com/D13187
--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
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Make a cleaner distinction between having a recv stream that is inactive, and no recv stream at all. Requires some modification to local RTC extension configuration, because of a test-case that assumed StopReceiving/StartReceiving would re-create the recv stream as opposed to simply restarting it.
Differential Revision: https://phabricator.services.mozilla.com/D12936
--HG--
extra : moz-landing-system : lando
Replace README_MOZILLA with moz.yaml, various fixups for update.py, and create
a missing patch file from Bug 1491848.
Differential Revision: https://phabricator.services.mozilla.com/D11891
--HG--
extra : moz-landing-system : lando
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
This allows DecodedStream to accurately track how many samples have been
appended to a track, even with resampling enabled.
Differential Revision: https://phabricator.services.mozilla.com/D12272
--HG--
extra : moz-landing-system : lando
Bug 1489040 - P1 - Update WebRTC ICE candidate stats field ipAddress to new name, address
Bug 1489040 - P2 - adjust WebRTC stats mochitest for new stat name 'address'
Bug 1489040 - P3 - add test for legacy WebRTC stat names
Differential Revision: https://phabricator.services.mozilla.com/D5560
--HG--
extra : moz-landing-system : lando
This makes Init and DeleteChannels virtual and mRecvChannelProxy and
mSendChannelProxy protected. This will allow unit test code to override
the creation of channels so that we can use a mocked ChannelProxy instead.
Depends on D12016
Differential Revision: https://phabricator.services.mozilla.com/D12017
--HG--
extra : moz-landing-system : lando
Rather than returning an error, the channel proxies have asserts that the
underlying calls to the channel objects succeeded.
Depends on D12015
Differential Revision: https://phabricator.services.mozilla.com/D12016
--HG--
extra : moz-landing-system : lando
This was regressed by the branch 64 update. The parameter is used in
audio_encoder_opus.cc.
Depends on D12014
Differential Revision: https://phabricator.services.mozilla.com/D12015
--HG--
extra : moz-landing-system : lando
Packet size and rate are no longer configured inside AudioConduit, so there is
no reason to continue to define them here. We now take the defaults provided
by webrtc.org.
Depends on D12012
Differential Revision: https://phabricator.services.mozilla.com/D12013
--HG--
extra : moz-landing-system : lando
With the branch 64 update we no longer configure packet size and rate
ourselves. Instead, we use the defaults provided in acm_codec_database.cc.
This removes the unused fields from AudioCodecConfig, the next commit does the
same thing for JsepAudioCodecDescription.
Differential Revision: https://phabricator.services.mozilla.com/D12012
--HG--
extra : moz-landing-system : lando
Includes changes to support nasm's stricter include paths.
Supports falling back to yasm if nasm is missing.
Differential Revision: https://phabricator.services.mozilla.com/D9972
--HG--
extra : moz-landing-system : lando
Add moz.yaml and update `update.sh` to match other media libraries.
Note after upstream's switch from SVN to git the RSC headers have changed,
however, these changes have not yet been committed. I've updated the patch
that had hunks with context extending into the RSC header so it continues to
apply after pulling from git.
Differential Revision: https://phabricator.services.mozilla.com/D11975
--HG--
extra : moz-landing-system : lando
This replaces the tunnel using a new nr_socket implementation. Proxy detection
code is still done in the peer connction. However, the result is only used to
detect a proxy. The result is unused. Address resolution is done by necko code
in the parent process. The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation. This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.
This adds a protocol for Necko to manage, WebrtcProxyChannel. This new protocol
serves as a pipe for a CONNECT tunnel. It is only used in WebRtc and not built
in no WebRtc builds.
--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
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
All gn-configs were generated on a single FreeBSD amd64 machine:
- DragonFly and NetBSD have is_clang=false, so differ only in target_os/OS_TARGET
- FreeBSD and OpenBSD have is_clang=true, so differ only in target_os/OS_TARGET
- x86 (i386) configs are from 32-bit chroot on x86_64 (amd64)
- arm (armv7) and arm64 (aarch64) configs are from qemu-user chroot
- qemu-user can't run rustc atm, so configure was hacked to work without
- qemu-user crashes with gn 68 on aarch64, so gn 65 was used
--HG--
extra : rebase_source : fb05d660c299851de6226fb23c6873bdfc34237f
This updates the gn generated json files for tier-1 platforms, and removes
the outdated configurations for remaining platforms.
--HG--
extra : rebase_source : bccb7a5476d5d0a66aa90657f839cea5e49ff4ce
The VP8SimulcastAdapter automatically handles cropping to accomodate
constraints on VP8 simulcast streams that each stream have exactly half the
width and height of the higher resolution stream before it.
This also adjusts min_bitrate_estimate in
test_peerConnection_simulcastOddResolution.html to compensate for changes in
the simulcast resolutions chosen by the webrtc.org code.
Differential Revision: https://phabricator.services.mozilla.com/D7482
--HG--
extra : rebase_source : b7ea403f7c9d6175a34eb11c7af17dd12ee55c31
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
Upstream has added an assertion in video send stream that prevents using
ReconfigureVideoEncoder if the content type has changed. This adds a
mActiveCodecMode member and uses it to prevent calling that method if the
codec mode has changed.
Differential Revision: https://phabricator.services.mozilla.com/D7475
--HG--
extra : rebase_source : d6af217ae501163f6ee742f2ad48f1f22d2869b4
This is no longer necessary as we do not use the webrtc.org audio device
implementations anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7450
--HG--
extra : rebase_source : b0fb79e68885b42afa1418c77bc6d24527803e9c
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
Nils Ohlmeier [:drno]
Byron Campen [:bwc]
Cosmin Sabou
Dan Minor
Adrian Wielgosik
Alex Gaynor
Alex Chronopoulos
Noemi Erli
Mike Hommey
Razvan Maries
Matthew Gregan
Csoregi Natalia
Sylvestre Ledru
Thomas Daede
Makoto Kato
Andrew Osmond
Ehsan Akhgari
Nico Grunbaum
Bryce Van Dyk
Paolo Amadini
Nathan Froyd
Andreas Pehrson
Emilio Cobos Álvarez
Peter Van der Beken
Narcis Beleuzu
David Major
arthur.iakab
Jean-Yves Avenard
Dorel Luca
Jan-Ivar Bruaroey
Andreea Pavel
Paul Vitale
Gabriele Svelto
Coroiu Cristina
byron jones
Dan Horák
Margareta Eliza Balazs
Chris Manchester
Brindusan Cristian
Jan Beich