clang-cl defines it on its own, although the value is slightly different
from __FUNCSIG__ (it doesn't contain the ABI, which doesn't really
matter). We've only been setting it this was on clang-cl by extension of
setting it for msvc.
Depends on D19616
Differential Revision: https://phabricator.services.mozilla.com/D19617
--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
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
Add a test file that was used to test mp4 parser telemetry to the general suite.
This file was added in the revision before this, and is also useful to provide
further coverage for other tests.
Differential Revision: https://phabricator.services.mozilla.com/D19387
--HG--
extra : moz-landing-system : lando
Add a gtest to cover the new telemetry probes which collect info on sample
description entries.
Add a new init segment to those already in our gtests. This segment has data for
one video track, and covers the case where multiple sample description entries
are present for a single track. In this case, because separate sample
description entries are used for unencrypted and encrypted samples.
For reference, the test init segment was created from our existing bipbop using
shaka-packager via the following command (non-init segments were discarded and
the output was renamed):
packager-win.exe
in=bipbop.mp4,stream=video,init_segment=bipbop_cbcs_video_init.mp4,segment_template=bipbop_cbcs_video_$Number$.m4s
--protection_scheme cbcs --enable_raw_key_encryption --keys
label=:key_id=7e571d047e571d047e571d047e571d21:key=7e5744447e5744447e5744447e574421
--iv 11223344556677889900112233445566 --generate_static_mpd --mpd_output
bipbop_cbcs.mpd
Depends on D14426
Differential Revision: https://phabricator.services.mozilla.com/D19386
--HG--
extra : moz-landing-system : lando
This patch adds telemetry to help us determine if mp4s with certain structures
can occur in the wild. Specifically:
- How often do mp4s have multiple entries in the sample description box?
- Do we ever see mp4s with multiple codecs in the sample description box?
- Do we ever see mp4s with multiple sets of crypto info in the sample
description box?
This information is collected each time we parse mp4 metadata.
Remove some diagnostic asserts now that we're gracefully gathering info.
Reshuffle of DecoderData function order to align with the order in the header.
Differential Revision: https://phabricator.services.mozilla.com/D14426
--HG--
extra : moz-landing-system : lando
Changing the units roundTripTime is reported in from milliseconds to seconds
Differential Revision: https://phabricator.services.mozilla.com/D19544
--HG--
extra : moz-landing-system : lando
The MoofParser didn't have logging on its normal code paths. This patch
implements such logging, covering entry and exit to many functions. Such verbose
logs are helpful for diagnosing failures and the specific file structure leading
to such failures. This should help improve our debugging experience if we can
get logs from end users which is particularly useful for cases where they can't
provide us with media due to geoblocking/proprietary media issues.
Differential Revision: https://phabricator.services.mozilla.com/D19021
--HG--
extra : moz-landing-system : lando
- Use different log levels in MoofParser. Generally Error is used for out of
memory, while warnings are used for bad mp4s.
- Add some new logs for parsing sample description entries.
- Add logs for when we can't find a Moof or fail to read a Moov.
- Have logs be more specific for the Box they're in where possible rather than
just log 'Moof'. E.g., when parsing the stsd box, we now log against that box,
not 'Moof'.
- Log instead of asserting if we're given multiple encrypted sample description
entries. This is valid per the spec, and can happen (though we don't expect
it), so we shouldn't assert.
Differential Revision: https://phabricator.services.mozilla.com/D19020
--HG--
extra : moz-landing-system : lando
From the following table, we can know the feature policy have no any effect for the autoplay result.
That is, if the document has been gesture activated, we want to playback, regardless of the status of the feature policy.
If the site has denied autoplay permission via feature policy, if the user gesture activates (clicks play) we still want to be able to play.
Therefore, we can remove `feature-policy` checking.
| gesture activated | autoplay feature policy status | allowed to play |
|-------------------|--------------------------------|-----------------|
| activated | allowed | true |
| not activated | not allowed | false |
| activated | not allowed | true |
| not activated | allowed | false |
Differential Revision: https://phabricator.services.mozilla.com/D18098
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Similar to what we do for H264 and for vp9 in webm, we parse the VP9 bytestream and check if a frame is a keyframe there instead.
Differential Revision: https://phabricator.services.mozilla.com/D18790
--HG--
extra : moz-landing-system : lando
VideoInfo.mImageRect is typically only used for VP8/VP9 content, however the Windows decoder use a common code between H264 and VP8/VP9 decoding and use this data to determine the image size. So we end up with conflicting image size and image rect (which contains cropping data).
Differential Revision: https://phabricator.services.mozilla.com/D18976
--HG--
extra : moz-landing-system : lando
This patch would try to start a blocked AudioContext when it creates a MediaStreamAudioSourceNode which has an active input stream or when a node's inactive stream becomes active, which means someone is feeding input data to AudioContext.
Therefore, we can do the similar thing like what we did for AudioScheduledSourceNode and MediaElementAudioSourceNode, to start AudioContext if current autoplay policy has allowed AudioContext to start.
Differential Revision: https://phabricator.services.mozilla.com/D18576
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--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
Check that we can resume after appening a partial media segment header and calling abort().
Depends on D18651
Differential Revision: https://phabricator.services.mozilla.com/D18762
--HG--
extra : moz-landing-system : lando
The helper stream which is created by the AudioParam can't be directly got from the AudioNode, which means that we can't suspend/resume all streams related with the AudioNode.
Therefore, we should also append these streams when AudioContext requires all streams.
Differential Revision: https://phabricator.services.mozilla.com/D18296
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
The logic was redundant with the next step that will already remove all until the next keyframe.
Depends on D18321
Differential Revision: https://phabricator.services.mozilla.com/D18322
--HG--
extra : moz-landing-system : lando
Per spec:
https://w3c.github.io/media-source/#sourcebuffer-coded-frame-removal
Step 3 of the Coded Frame Removal Interval:
"Remove all media data, from this track buffer, that contain starting timestamps greater than or equal to start and less than the remove end timestamp. "
So to decide if a frame should be removed from a track buffer, its start time is the only information to be used.
Differential Revision: https://phabricator.services.mozilla.com/D18321
--HG--
extra : moz-landing-system : lando
