The documentation says that the boolean return values from these methods
must be checked. We might as well make the compiler check these things
for us.
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : d6a68579e76f1eda651e38bec5a9ed17c9de3fa4
We don't want to skip all remaining steps. For now it just affects some logging,
but there may be new ones added in the future.
MozReview-Commit-ID: 7fBdgLNT780
--HG--
extra : rebase_source : dc5113298c1dbadd23c19127349a4a66cd460b4c
Test that play() on a media without audio called before
readyState >= HAVE_METADATA will still play.
MozReview-Commit-ID: 1FeDrEfCEum
--HG--
extra : rebase_source : be6d07905aad853ad028eac372e4e380bdeb1a49
extra : source : e98b4a7aaf020fa3d6d59cb0f53680ef6466d154
We have code in the MDSM to toggle on high resolution timers on Windows when we
start/stop playing because the VideoSink relies on being awoken by timers to
update the set of current frames in the compositor's queue, and on Windows 7 we
end up dropping frames due to the timer lag without this.
We assert in the MDSM's destructor that we've turned off high res timers (as
they cause needless battery drain, so we only want them on when we need them),
and the new test_mediarecorder_principals is hitting that assert on Windows. I
think we're missing turning them off when we create a new VideoSink for
outputting to the MSG. That affects the value returned by
MediaDecoderStateMachine->mVideoSink->IsPlaying(), which is what we use to
decide whether we should enable high resolution timers. We track whether we've
enabled high res timers in MDSM::mHiResTimersRequested, and that gets out of
sync with IsPlaying() when we re-create the MediaSink.
Rather than trying to handle all the permutations of places where we need to
turn off high resolution timers in the MDSM, we're better to move the code to
toggle high res timers into the VideoSink, as that's actually where we need to
be sure that we have high resolution timers enabled anyway. It's the VideoSink
after all that is relying on timers for frame update, not the MDSM.
Also remove the media.hi-res-timers.enabled pref, as we haven't needed it.
MozReview-Commit-ID: 9dNxcYxPDZH
--HG--
extra : rebase_source : 6e403d59bb5f1dd0241fe8298a823ba08b1670fb
I changed this test earlier in this set of commits to use
midflight-redirect.sjs so that we get more reliable and predictable cross
origin redirects during the download. Unfortunately this test now times out on
Windows.
This test times out on Windows because midflight-redirect.sjs redirects at 1/4
through the resource, whereas this test expects to be able to play through to
1/5 through the resource, and on Windows that seems to be not reached during
playback. This is likely due to decode latency being higher on Windows.
On top of that, the test's first case can sometimes call MediaRecorder.start()
before the redirect has happened, and before the principal has changed, and so
start() doesn't throw a SecurityError as expected, and the test intermittently
fails.
Additionally, the test's code could be clearer if we used async/await.
So rewrite the test to use async/await, and take advantage of
midflight-redirect.sjs's redirect being more predictable than the old
dynamic_redirect.sjs. Basically, we can be careful to wait for either
"loadedmetadata" or "error" on the media element in order to be more confident
the redirect has or hasn't happened yet.
We still can't be 100% sure that the redirect won't have already happened by
the time our "loadedmetadata" handlers run. It's quite possible that the
download has reached 1/4 through the resource by the time the loadedmetadata
handler has run, so we need to handle the "error" and "loadedmetadata" events
racing.
MozReview-Commit-ID: 8plMjkXgjYt
--HG--
extra : rebase_source : 7305598f40c09219494f3e7150799d8875b7c30e
I'm seeing intermittent failures of test_midflight_redirect_blocked. In this
test, our custom server responds to Firefox's 0- HTTP Byte Range request with a
[0,200] response. When Firefox requests 200-, the server responds with a cross
origin redirect, and then the remainder of the resource.
However sometimes while running test_midflight_redirect_blocked the MP4 demuxer
reads through all 200 bytes while trying to parse metadata before the redirect
has occurred and fed more data into the cache, and so the demuxer thinks it's
hit end of stream, and reports a failure. The demuxer thinks it's hit end of
stream, because we initialize the MediaCacheStream length in
ChannelMediaResource::Open() with the value of the Content-Length HTTP header.
But in an HTTP byte range response, the Content-Length header tells you the
length of the range returned, not the length of the entire resource. The length
of the resource is in the Content-Range header, we need to use that if
available.
So to fix this intermittent test failure, we need to also parse the
Content-Range header in ChannelMediaResource::Open(), and use the length from
that if available.
MozReview-Commit-ID: 29pPRsUvxag
--HG--
extra : rebase_source : ba1ef03d65ebd22698a29d8385f36b4c747ccf43
Problems here:
* The variable `to` is undefined for byte range requests to the end of
the resource, making the math fail. Firefox normally makes ranges requests like
this.
* The bytes.length/4 calculation may not be a whole number, so can
result in a byte range header part of the way between two bytes. We need to
round the length off.
* Instead of re-calculating the contentLength, we can just use the length of
the actual byterange substring being returned. That's clearer.
* test_midflight_redirect_blocked needs the redirect to happen
before metadata has completed loading, but other tests require the redirect to
happen *after* metadata is loaded. So add a redirectAt query parameter for the
requester to control when to redirect.
MozReview-Commit-ID: I6n1NqK0Uze
--HG--
extra : rebase_source : a6bd68fe75cfd4c46f63ca815c5a4e9390bd671a
We have two SJS files; midflight-redirect.sjs and dynamic_redirect.sjs,
which are very similar, but dynamic_redirect.sjs is buggy, so we should
just use midflight-redirect.sjs.
dynamic_redirect.sjs is buggy because it relies on the client doing multiple
HTTP requests to it in order to redirect, but we can't actually guarantee
this. Previously users of it would try things like setting a small MediaCache
size, or only using Ogg for which we expect a seek to the end to calculate
the duration, but I have observed the entire resource being downloaded in
one hit before the media element has finished loading metadata, meaning the
seek (in the Ogg case) can happen without another HTTP request. This is even
with a small MediaCache.
midfligh-redirect.sjs solves this problem by explicitly only returning a
partial response, so the client is forced to make another HTTP request,
which we will serve a redirect to.
MozReview-Commit-ID: 39imyayhnBG
--HG--
extra : rebase_source : 603532e4af0bf304c34739de5b0b243174e3831d
The original test is failing, as it assumed we'd not error when
origins were mixed without CORS, and the original test was using
outdated practises, so rewrite it.
MozReview-Commit-ID: KlOH83GUOk
--HG--
extra : rebase_source : 2c79691fddc93af0e04d8f23fa31ac8588a8d6e1
extra : amend_source : 2989317530f536915f011977c8f34e048410b018
Try to prevent Necko from caching the results of our SJS media responses, as
some of the test that use it rely on the server being hit and serving a
redirect. Sometimes the tests which rely on hitting a redirect in an SJS
where timing out without this, as Necko would cache the response and not
hit the server, and so not hit the redirect.
Also include a noise parameter to increase the likelihood that the URL is
unique, to further reduce the chance that Necko caches the result.
MozReview-Commit-ID: 3cLEiDoh4HG
--HG--
extra : rebase_source : 24c152d46540866f14211fae30f1e59c5d23b6d4
dynamic_redirect.sjs and midflight-redirect.sjs are serving files
with "Content-Type: video/ogg", which is incorrect and could lead
to problems given that we're not always asking it to serve Ogg
files. So include the type be to served as a query parameter.
MozReview-Commit-ID: 5f0PXy8lL3G
--HG--
extra : rebase_source : 757395a21317655422767efe3f7c1923a19c0114
Test that playback works if we don't block, doesn't if we do block, and does
if we do block and CORS is used.
MozReview-Commit-ID: 9PTZXLOdHIU
--HG--
extra : rebase_source : db7f0c61b64990623ef035b266cf052c45df1c76
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : a2f4b7c68b73ecc4c7525d4e41e834f4caf85707
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : f0784c0c5b2e39d2078a5aff72be03b52e413139
extra : intermediate-source : 635153e1dcdc442f8d72727b6fe504842b4ffa31
extra : source : bf011140459cc227c9435e3960770bafb3cecb8e
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
This creates a simulcast stream with an odd resolution. This previously would
have caused a runtime assertion failure and crash.
MozReview-Commit-ID: IsywVOu6UeV
--HG--
extra : rebase_source : 7ad1cbe7dd36ccdd7a05e0c0a83db98a36c8c416
The CanCallerAccess check in the "webidl" version of
nsGlobalWindowOuter::AddEventListener was pointless, because bindings never
call things on outer windows.
MozReview-Commit-ID: 1CGMJ277bPu
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
The code relied on a flag to be set to simply abort. However, that made the code workflow hard to read.
We split each runs so that there's no ambiguity.
MozReview-Commit-ID: LI7pL5p69zu
--HG--
extra : rebase_source : 6c912edf87c13fc6b10a9be6bd57d4ffbf1dfc39
Benchmark had never been intended to be able to process invalid content. However over time Benchmark class has been used extensively by the fuzzing team.
As such, it became necessary to handle errors of all kind.
MozReview-Commit-ID: E0YulHuoiq2
--HG--
extra : rebase_source : a8c5bf2e05d5b4e9c89723cb1e0d71e61f17d501
This allows static analysis to pass for AudioNodeExternalInputStream.cpp.
MozReview-Commit-ID: 9dvllnnODed
--HG--
extra : rebase_source : 0c7665a3240422d52b82c5c2eaa4942be522dcb9
When this test times out, one of the two videos in parallel takes
minutes to start.
MozReview-Commit-ID: AhXsQKDKwOD
--HG--
extra : rebase_source : 3d42329967204c201b9e882b13dafc3149247c79
Add two mochitests to provide coverage for getUserMedia when getting a cubeb
context fails.
- The first test checks that gUM fails with no audio devices returned. In normal
circumstances, without cubeb we do not expect devices to be available. Android
is a notable exception here, due to it having a number of different code paths
during enumaration, and the test attempts to accomodate this.
- The second test checks that if fake streams are enabled, gUM will still return
a stream and that this stream can be used.
MozReview-Commit-ID: Fn6rGi6W9hM
--HG--
extra : rebase_source : b22ccc11cb034242f1a8807cfcae05f5ac2daa05
Add a hidden pref, media.cubeb.force_null_context, that will force CubebUtils
to return a nullptr when asked for the cubeb context. This is to enable testing
of components, simulating the case cubeb were to fail.
MozReview-Commit-ID: Kd9Ksu0GfQJ
--HG--
extra : rebase_source : 0ac7837105dc1005dbd3b02f8768fb3ebf55c11e
Update head.js so that calls to the gUM helper will check the loopback and fake
device prefs and update the frequency output by test devices accordingly. This
should hopefully avoid issues where tests could change prefs, and the output
tone would no longer be correct for the new configuration.
No longer have audioDevice and videoDevice as globals, this way tests
explicitly fetch direct from prefs.
MozReview-Commit-ID: 9jhVScaBfTX
--HG--
extra : rebase_source : 64b17e44ef166983361f94cf7d287faed3c2cdc5
Update the DeviceEnumerationType enum to scoped style enum for safety and
consistency. Add extra logging to aid in debugging test issues.
MozReview-Commit-ID: cm5bdlIcEG
--HG--
extra : rebase_source : bfcae3d49f809edfd0ed6ab3e516b8be0c0d517e
Update head.js so that logic for fake audio and fake video is more granular.
Now code handles fake audio and fake video separately, and will set the fake
pref is either is needed. This allows for a single loopback device to be set
and fake used for the other. Previously both devices needed to be loopback or
fakes would be used.
MozReview-Commit-ID: K4blmPrSVeh
--HG--
extra : rebase_source : 369ea7f788d29a02db68e517d324977f251c9a98
With changes giving loopback devices higher precedence in testing, various tests
in dom/media/tests/mochitest have been updated to accommodate this. Many tests
just worked, but some require tweaks, or to explicitly request fake devices.
Also update webaudio's test_mediaStreamAudioSourceNodeGC test to explicitly use
fake devices. This test does not have the loopback tone exposed to it in JS, so
is unabel to adjust the loopback tone to suit its needs.
Various tests are updated to set fake device prefs instead of requesting via
gUM to move away from non-standard behaviour per bug 1436424.
MozReview-Commit-ID: 5GAVZFzF2hq
--HG--
extra : rebase_source : 27f39e3573eda321025ce0739e1d5f4101fc5d12
This changeset adds a gUM_support.js to dom/media/test/. This file provides
functions to setup prefs for loopback or fake device selection before gUM calls
are made. This is useful for configuring tests and providing an explicit point
of reference for settings, rather than the implicit ones provided by the
harness.
Updates tests so that the new helper functions are called before gUM. This
will result in loopback prefs being set if loopback device names are detected,
if not then fake devices will be used. This also removes the use of the fake
constraint in gUM calls.
Update touched tests to use some more modern JS. No behavioural changes were
made (except in minor cases, but functionality should be the same). These
changes are largely as follows:
- var -> let
- async is used in places where I felt it improved readability
- semicolons added to various event handler assignments
MozReview-Commit-ID: 1HuE8thBA6w
--HG--
extra : rebase_source : b866056b2821436cf34ea683421c200b4bb4e55f
Change the media manager so that if fake and loopback devices are requested,
loopback is preferred. With this change loopback and fake devices can also be
mixed. Since the fake flag is coarse, and does not specify fake audio or video,
we would previously just make everything fake. As loopback sets flags for video
and audio separately, we can now request a single loopback device, while also
setting the fake flag to get a mix. E.g. if we request a loopback audio device,
and set the fake flag, we should get loopback audio and fake video.
This change also attempts to somewhat consolidate where these settings take
place. Previously, EnumerateRawDevices did much of the loopback setup. However,
other steps around fingerprint resistance or fake devices were done in earlier
functions (EnumerateDevices and GetUserMedia). This changeset moves the loopback
setup so that it's more consolidated with the other setup code in these
functions.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 374a6fd0842a430e27c695bcf956e2e072a77fc3
Prior to this patch various bools are used to track if we requst fake or
loopback devices during enumeration. However, since the normal, fake, and
loopback cases are mutually exclusive, a enum can be used. This provides allows
for having descriptive enum values in code and makes clear that the settings are
mutually exclusive.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 498513bdc6673fa299080097364a6d0dff00a073
Stop us potentially keeping a stale device list when updating if we can't get a
cubeb context.
MozReview-Commit-ID: H6GdeNXObWV
--HG--
extra : rebase_source : 48fce949627fa17402336db824374847e1b439e6
Add logging to aid in debugging of our EME ADTS conversion path.
MozReview-Commit-ID: A7Wv8n31V8V
--HG--
extra : rebase_source : 13f20179aa29180047a37a127029d0e28a1c4f80
Update EMEDecoderModule to use 2 as profile number when the given profile is
less than 1 or greater than 4. The CDM doesn't appear to care what values are
given, but 2 was chosen as a safe fallback per discussion on the bug. This
addresses the use case where 0 values are stored in mProfile due to the use of
extended profiles (which are then stored in the mExtendedProfile field).
MozReview-Commit-ID: 5XgabNDsgdf
--HG--
extra : rebase_source : dd66a872aaac2acf4af55f06d3c24f53debe4e63
