Marco Simonelli authored 2 years ago and Pier Angelo Vendrame committed 1 year ago

- fixes required to build dom/media/systemservices

Marco Simonelli authored 2 years ago and Pier Angelo Vendrame committed 1 year ago

- fixes required to build dom/media/webrtc

Differential Revision: https://phabricator.services.mozilla.com/D178074

Bug 1830206 - Add an arbitrary limit to the number of audio channels a media can have. r=alwu, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D177644

Differential Revision: https://phabricator.services.mozilla.com/D175018

Bug 1812498 - Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems in VideoBridgeParent::OnChannelError(). r=lsalzman, a=RyanVM

Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().

The patch includes Bug 1817674 fix.

Differential Revision: https://phabricator.services.mozilla.com/D172764

Differential Revision: https://phabricator.services.mozilla.com/D172637

Bug 1812498 - Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems in VideoBridgeParent::OnChannelError(). r=lsalzman, a=dsmith

Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().

The patch includes Bug 1817674 fix.

Differential Revision: https://phabricator.services.mozilla.com/D172764

This patch adds the ability for Windows on ARM to launch either x86 or
ARM Widevine plugins. It also adds the ability for Windows on x86 to
refuse ARM binaries in case, for example, a profile is transferred
between machines.

Overall this should be a non-functional change for users at the time of
landing. It does however allow us to ship the ARM Widevine plugin to
Windows ARM users to workaround a plugin crash with the x86 Widevine
plugin. This only affects Windows 10 users (Windows 11 works fine).

Differential Revision: https://phabricator.services.mozilla.com/D167634

Differential Revision: https://phabricator.services.mozilla.com/D171485

Differential Revision: https://phabricator.services.mozilla.com/D170086

Includes fix for bug 1803268.

Differential Revision: https://phabricator.services.mozilla.com/D164356

Bug 1752559 - Test that a screencapture track can be encoded by all supported codecs. r=bwc, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D164239

Differential Revision: https://phabricator.services.mozilla.com/D161700

Differential Revision: https://phabricator.services.mozilla.com/D156605

Differential Revision: https://phabricator.services.mozilla.com/D155365

Bug 1767360 - use correct image size retrieved from the output type to create video frames buffer. r=media-playback-reviewers,jolin a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D154310

Bug 1781063 don't use tainting for cross-origin check on document media resource loads r=chunmin a=RyanVM

When the media resource is loaded as a document, the response from the initial
document load gets reused, as an optimization, as an emulated load for the
resource of the media host element in the generated HTML document.
https://searchfox.org/mozilla-central/rev/5644fae86d5122519a0e34ee03117c88c6ed9b47/dom/html/VideoDocument.cpp#114
https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media

Depends on D154041

Differential Revision: https://phabricator.services.mozilla.com/D154042

Bug 1781759 use media element node principal instead of channel loading principal for cross-origin resource test r=padenot a=RyanVM

When the media resource is loaded as a document, the response from the initial
document load gets reused, as an optimization, as an emulated load for the
resource of the media host element in the generated HTML document.
https://searchfox.org/mozilla-central/rev/5644fae86d5122519a0e34ee03117c88c6ed9b47/dom/html/VideoDocument.cpp#114
https://html.spec.whatwg.org/multipage/browsing-the-web.html#read-media
The loadingPrincipal of the initial channel comes from the parent document,
and so is not useful to determine whether the response is cross-origin with
the media element.

This change makes the cross-origin test on the initial document load
consistent with subsequent requests on the same resource and non-document
loads, which already use the node principal for the loadingPrincipal.
https://searchfox.org/mozilla-central/rev/1061fae5e225a99ef5e43dbdf560a91a0c0d00d1/dom/media/ChannelMediaResource.cpp#750
https://searchfox.org/mozilla-central/rev/4f2984be127d2e7c788cf1848d63dca63022beec/dom/html/HTMLMediaElement.cpp#1708

Depends on D154039

Differential Revision: https://phabricator.services.mozilla.com/D154040

Differential Revision: https://phabricator.services.mozilla.com/D154039

Bug 1779036 - Account for the fact that the ended promise might already have been resolved in GetPosition, during shutdown. r=ng, a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D151592

Bug 1768809 - Fix library preloading for the OpenH264 plugin. r=media-playback-reviewers,alwu, a=dmeehan

The workaround added in bug 1725828 was intended to be applied to any
plugin that may have been linked against a different version of glibc
than the browser; i.e., everything except clearkey, which is built and
shipped along with the browser.  Unfortunately, the change was made in a
function used only for the Widevine CDM, so we're now having the same
problem with OpenH264.  This patch corrects that oversight and preloads
the (potentially) needed libraries for every applicable plugin.

Differential Revision: https://phabricator.services.mozilla.com/D149446

Bug 1773223 - Make the GN processor an independent script. r=firefox-build-system-reviewers,mjf,ahochheiden a=RyanVM

The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.

Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.

Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.

And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.

Differential Revision: https://phabricator.services.mozilla.com/D149210

Bug 1773223 - Move some json fixups into the GN processor. r=firefox-build-system-reviewers,andi a=RyanVM

As we're shortly going to stop producing the intermediate json files,
we want the fixups to happen in the GN processor.

Ideally, we'd move them all, but cleaning up -isysroot is more involved,
while we won't need it once we don't use intermediate json files, so we
leave the -isysroot cleanup in fixup_json.py for now.

While here, `gn_out["targets"][target_fullname]` doesn't need to be set
on every iteration of the loop.

Differential Revision: https://phabricator.services.mozilla.com/D149209

Bug 1773223 - Generate webrtc moz.builds for all platforms at once. r=mjf,firefox-build-system-reviewers,ahochheiden a=RyanVM

The current script requires to be run on 4 different host platforms each
of which would handle a subset of a total of 32 mozconfigs. That is not
sustainable, and there are already missing configs that break tier-3
platforms.

This replaces the current setup with one that handles all platforms in
one go, although we still keep the internal sequence of GcConfigGen ->
fixup_json -> GnMozbuildWriter.

The downside is that because this relies on the upstream webrtc build
system supporting cross-compilation, and that it actively rejects some
configurations, we need some local hacks to make it work on Linux and
Mac, but for now, we have to leave out Windows, which requires more
work.

For some reason, that removes some duplicated include directories in the
json files, which moves things a little in one moz.build file.

We also remove the mozconfigs we don't use anymore.

Differential Revision: https://phabricator.services.mozilla.com/D149205

They don't appear necessary when generating the gn-derived moz.build
files.

Differential Revision: https://phabricator.services.mozilla.com/D149203

Differential Revision: https://phabricator.services.mozilla.com/D149673

Bug 1773067 - Test that getStats on closed peer connection rejects and doesn't hang. r=jesup,jrmuizel a=RyanVM

Depends on D148562

Differential Revision: https://phabricator.services.mozilla.com/D148563

Bug 1773067 - Restore previous behavior of rejecting getStats if invoked on closed peer connection. r=jesup,jrmuizel a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D148562

It's not doing anything useful and only adds noise to our moz.build files.

Differential Revision: https://phabricator.services.mozilla.com/D148630

Differential Revision: https://phabricator.services.mozilla.com/D149187

Differential Revision: https://phabricator.services.mozilla.com/D149279

Fixes an issue where AV1 test videos on twitch.tv would be unable to play.

Differential Revision: https://phabricator.services.mozilla.com/D148844

Differential Revision: https://phabricator.services.mozilla.com/D148123

Bug 1773067 - Test that getStats on closed peer connection rejects and doesn't hang. r=jesup,jrmuizel a=RyanVM

Depends on D148562

Differential Revision: https://phabricator.services.mozilla.com/D148563

Bug 1773067 - Restore previous behavior of rejecting getStats if invoked on closed peer connection. r=jesup,jrmuizel a=RyanVM

Differential Revision: https://phabricator.services.mozilla.com/D148562

Differential Revision: https://phabricator.services.mozilla.com/D146926