Returning UniquePtr is nicer than returning raw pointers, and has the
nice side effect of forcing us to clean up the uses of nsAutoPtr that
were hanging about.
This will resolve several intermittments that were occuring because we would
occasionally get unlucky and have a jitter midpoint of 0, making an unstarted
AudioContext report a CurrentTime of 100us (or 1ms - whatever our clamp value
was.)
MozReview-Commit-ID: 45zXLbB93wP
--HG--
extra : rebase_source : 23ea5964dc49543c2b4ca45890c4c08456e75c73
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : 652d311cb69e6c3ed3b1ba91719e79acb0a4bb9c
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
