- Watch for if a proxy shuts down during init and if so, shutdown the CDM parent
that is being initialized.
- Make ChromiumCDMParent only store a pointer to a ChromiumCDMProxy when it has
successfully initialized. This avoid the lopsided relationship where a if a
ChromiumCDMParent fails to initialize it may keep a pointer to a proxy, but
the proxy will never have a reference to that CDM parent.
Differential Revision: https://phabricator.services.mozilla.com/D26208
--HG--
extra : moz-landing-system : lando
This code is calling other code that expects to be on the main thread, and
having this on the main thread (now that the main thread is a serial event
target) makes it easier to reason about this and other main thread code. I.e.
this cannot be running during other main thread code.
Differential Revision: https://phabricator.services.mozilla.com/D26206
--HG--
extra : moz-landing-system : lando
This gives us greater flexibility in using the main thread member to run
promises.
The site where we obtain the main thread returns a serial event target, so we're
not doing much more work here, we're just keeping the serial event target
interface, rather than converting to an event target interface.
Differential Revision: https://phabricator.services.mozilla.com/D26205
--HG--
extra : moz-landing-system : lando
Also remove unneeded MOZ_COUNT_[CTOR|DTOR] macros. We already get similar
functionality from NS_INLINE_DECL_THREADSAFE_REFCOUNTING.
Differential Revision: https://phabricator.services.mozilla.com/D26204
--HG--
extra : moz-landing-system : lando
EME key system constants are used with UTF-8 functions where ASCII functions would do
Differential Revision: https://phabricator.services.mozilla.com/D25730
--HG--
extra : moz-landing-system : lando
Because multiple ChromiumCDMProxy object may exist during a browser lifetime,
logging the value of `this` in their logs is useful for disambiguating log
statements, as well as matching ChromiumCDMProxy objects to pointers held by
other objects.
Update formatter usage in logs to prefer PRIu32 over %u when the underlying type
is uint32_t.
Differential Revision: https://phabricator.services.mozilla.com/D21980
--HG--
extra : moz-landing-system : lando
The macros in these classes are used to output class names in logs.
Differentiating them helps make logs clearer.
Differential Revision: https://phabricator.services.mozilla.com/D21979
--HG--
extra : moz-landing-system : lando
Use GMPLog.h in GMPContentPareant. Add logging to most functions. This logging
was added to aid in diagnosing a shutdown crash, but should be generally useful
to have.
Driveby touchup of arg name to ChromiumCDMDestroyed to match header.
Differential Revision: https://phabricator.services.mozilla.com/D21978
--HG--
extra : moz-landing-system : lando
These functions already specify the override keyword. This change also makes
them more consistent with the overloaded versions of the same functions in these
classes.
Depends on D21968
Differential Revision: https://phabricator.services.mozilla.com/D21975
--HG--
extra : moz-landing-system : lando
Bug 1352924 removed the usage of this class, so we can safely remove the dead
code.
Differential Revision: https://phabricator.services.mozilla.com/D21968
--HG--
extra : moz-landing-system : lando
There's a lot of duplication in the code to generate host files, particularly
in the MacOS code. So refactor out the common code into helpers, and make the
code higher level and easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D21508
--HG--
extra : source : b379017fa026dbec2f326073db45083c880bf006
extra : histedit_source : 74805393e69dba5c47c8e5971046ce7b72468fd2
On Windows on ARM64 we will run the x86 Widevine DLL in an x86
plugin-container.exe with an x86 xul.dll. We therefore should also pass the
paths to these binaries to the CDM in the host files instead of the aarch64
plugin-container.exe. We should still pass the aarch64 xul.dll to the CDM,
as that's in use by the aarch64 firefox.exe.
Differential Revision: https://phabricator.services.mozilla.com/D21507
--HG--
extra : source : 4c22ddbf15b579a57d1790c1b4f6290e661da346
extra : histedit_source : 8f1f76f36c3a18681e8aa373e7cd117c41c11815
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
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
Refcounted objects should be put into refptrs when they are created.
This patch also moves the crash helper out of the object early in
Init, to maybe reduce the chance of a leak if it fails early.
This field is only used to pass in a value to the Init() method. It
can't be passed in directly because on Android there are two
implementations of CDMProxy, and MediaDrmCDMProxy doesn't take a crash
helper.
Differential Revision: https://phabricator.services.mozilla.com/D17707
--HG--
extra : moz-landing-system : lando
This field is only used to pass a pointer from the ctor to the Init()
method. Instead, just pass in the crash helper directly.
This avoids some problems with the existing code where the crash
helper is not AddRefed immediately after creation, which could lead to
leaks in some error cases.
Differential Revision: https://phabricator.services.mozilla.com/D17707
--HG--
extra : moz-landing-system : lando
Note, we only pass the relevant IV across the IPC boundry. I.e. if the crypto
scheme is cenc we do not pass a constant IV (this is only used by cbcs), and
only pass per sample IVs. For cbcs we do the converse. This means in the CDM
child we're only receiving one IV, which should be appropriate for whatever
scheme (this is similar to how Chromium handle IVs being passed to the CDM).
The CDM child side now writes pattern information to samples it's preparing for
CDM.
With these changes we should be passing all the information required to handle
cbcs to the CDM.
Differential Revision: https://phabricator.services.mozilla.com/D16459
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec: the scheme implies mode. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec --
possibly if the isProtected flag which we were tracking with mMode, is
ever changed to be more than a bool in the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec of implementation. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--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.
Adds log statements for all the reasons that GMPVideoEncoderParent::Encode can fail
Differential Revision: https://phabricator.services.mozilla.com/D15051
--HG--
extra : moz-landing-system : lando
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
Bug 1494178 added code to mark samples with 0 encrypted ranges as unencrypted
before they were fed to the CDM. This was to catch issues where we could mark
such unencrypted samples as encrypted. However, the CDM expects certain samples
that are clear to still be marked as encrypted.
Specifically, WebM samples should be marked as encrypted if they are from an
encrypted track and have the signal byte's encryption bit set (a marker for if
the packet is encrypted), even if they have no encrypted ranges.
The WebM demuxer is already doing this. Further inspection and testing of the
mp4 demuxer shows it is behaving in line with Chromium's current mp4 parser,
which we can expect prepares its data sensibly for Widevine.
As the code removed here was added as a safety fallback, but is causing issues,
and as the demuxers already appear to be doing the right thing, the fallback
code can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D8024
--HG--
extra : moz-landing-system : lando