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 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