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
Using a variant more clearly indicates how MoofParser works: you cannot request
a specific track id and to parse all tracks. Callers must now explicitly select
one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D18135
--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
Clang 7 was making the pow => exp2 optimization for us, and for some reason clang 8 stopped doing so. This resulted in a surprisingly large regression in raptor numbers.
Differential Revision: https://phabricator.services.mozilla.com/D18148
--HG--
extra : moz-landing-system : lando
There's a strong cycle of references between SamplesWaitingForKey and
CDMProxy that does not get cleared unless keys actually come in. This
causes a leak. One way to avoid that leak is to clear the proxy
reference when the things holding the SamplesWaitingForKey is shut
down.
Differential Revision: https://phabricator.services.mozilla.com/D17960
--HG--
extra : moz-landing-system : lando
We reenable the corresponding tests unconditionally because we don't run
tests on the msvc builds anyways (and they're going to be retired soon).
Differential Revision: https://phabricator.services.mozilla.com/D18028
--HG--
extra : moz-landing-system : lando
This stops the use of some win32k calls during start-up that will fail and in
some cases cause a crash.
It also moves the MITIGATION_DYNAMIC_CODE_DISABLE to be enabled after start-up.
This is required because the hooks to fake the user32 and gdi32 initialization
are applied as the DLLs load and the dynamic code disable blocks that.
With the per-track pulling settings we have today it is clearly the intention
of the producer to start consuming a track that has pulling enabled, even if
there are other tracks where pulling is disabled.
This patch fixes that, so that when a stream has at least one pulled track it
will append null data to other tracks (commonly video) if they are lacking
data.
This means that we still block an entire stream if all tracks have pulling
disabled - to maintain the status quo for media element capture, which is
the only push-only producer of data.
Differential Revision: https://phabricator.services.mozilla.com/D17611
--HG--
extra : moz-landing-system : lando
Add a test file that has a moov with two tracks, but which has had the track
fragment headers removed for the second track. Created from bipbop.mp4 via:
`mp4box bipbop.mp4 -dash 5000 -subsegs-per-sidx -1 -segment-name
$Segment=bipbop_$$Init=bipbop_init$`, concatenating the init and segments
back into an mp4, then overwriting track 2's trafs with frees.
While we shouldn't expect people to create files such as this, it does simulate
if the MoofParser is fed metadata for multiple tracks, but then is not fed
fragments for one of these tracks. This appears to have been the case when bug
1519617 broke soundcloud.com, so we should have test coverage for this.
Depends on D17070
Differential Revision: https://phabricator.services.mozilla.com/D17071
--HG--
extra : moz-landing-system : lando
Test that an init segment for a video track that uses track_id 0 is correctly
parsed and that the MoofParser picks up the expected crypto data.
Depends on D17069
Differential Revision: https://phabricator.services.mozilla.com/D17070
--HG--
extra : moz-landing-system : lando
Add a copy of bipbop.mp4 that has been fragmented via `mp4box.exe bipbop.mp4
-dash 10000 -subsegs-per-sidx -1` and then hex edited the track_id for video to
be 0. Add this to our already existing MP4Metadata and MoofParser gtests.
Also construct a new gtest to ensure that requesting track 0 from the MoofParser
doesn't result in all tracks being parsed. Historically this would have happened
and could result in bad metadata if the caller expected just track 0 to be
parsed.
Differential Revision: https://phabricator.services.mozilla.com/D17069
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
The problem here is that the MediaStreamGraphImpl::mInputDeviceID is not reset after a device unplug. On a device-remove event of the active device MediaStreamGraphImpl::mInputDeviceID is reset when MediaStreamGraphImpl::CloseAudioInput is being executed. This method will not be executed if the new enumeration, on the MediaManager::OnDeviceChange, is returning the old outdated list of devices. This patch increases the wait time before the new enumeration in order to allow the system to update the provided device list.
Differential Revision: https://phabricator.services.mozilla.com/D17843
--HG--
extra : moz-landing-system : lando
HLSResourceCallbacksSupport::mDecoder is cleared on main thread too, so
the nullness check already ensures decoder methods won't be called after
shut down. In fact, for OnError() the lock is harmful because the task calls
MediaDecoder::NetworkError(), which triggers decoder shutdown and eventually
HLSResourceCallbacksSupport::Detach(), which tries to lock the mutex again
while the mutex is still locked.
Differential Revision: https://phabricator.services.mozilla.com/D16709
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
'NS_ERROR_DOM_MEDIA_WAITING_FOR_DATA' and 'NS_ERROR_DOM_MEDIA_CANCELED' are not decoding errors, so we should
treat them differently like what we did for 'NS_ERROR_DOM_MEDIA_END_OF_STREAM'.
Differential Revision: https://phabricator.services.mozilla.com/D16722
--HG--
extra : moz-landing-system : lando
We would only start the AudioContext blocked by our autoplay policy, won't resume AudioContext which is suspended explictly by page.
Differential Revision: https://phabricator.services.mozilla.com/D16613
--HG--
extra : moz-landing-system : lando
