This is the core of this bug:
- We try to read past the end of the requested range, and save a block-full of
cached data. ("Block" is a memory range, with an alignment and size being a
power of two, to match existing caching happening in MediaCache and
FileBlockCache, and to play nice with the memory allocator.)
- If part of a requested read touches the existing cache, we can just read from
the cache, which means we don't involve any of the locking and IOs that normal
reads use.
The small extra work needed to cache more data in some reads is largely offset
by all the lock&IO-heavy reads that we can subsequently avoid.
UncachedReadAt, which is used internally by CachedReadAt, is left public
because it could be useful if the caller knows for sure that a particular read
is isolated.
(Note: The printfs, and comparison code in ReadAt, will be removed in later
patches. Also the block size will be later controlled by a pref.)
MozReview-Commit-ID: GFiaP5Io7Hf
--HG--
extra : rebase_source : 2bebcdb7854989b55f2026e92338a00ac29a5376
When the WaveTrackDemuxer is given a MediaResourceIndex, it's only really
interested in the MediaResource pointer, so we should just pass that, and
WaveTrackDemuxer can construct its own MediaResourceIndex from it.
Also, MediaResourceIndex will become non-copyable soon.
MozReview-Commit-ID: H0VGSxpAGkP
--HG--
extra : rebase_source : 174422a9b3add0bc18b671e2613476cc1a97c0bb
`fread(buf, count, 1, f)` meant that exactly one object of size `count` could
be read.
Changing that to `fread(buf, 1, count, f)` now reads up to `count` size-1
objects (aka bytes) up to `count` and returns that number of bytes read, which
is usually what we want from a read, i.e. as much as possible even if it's less
than requested.
MozReview-Commit-ID: 3Lgvws19SFd
--HG--
extra : rebase_source : e5b89a7073d2a5a0365c6fe6aa938bd17cf37935
If the requested cached-data offset is out of range, we should just return the
same offset, as it signals that the actual cached range is 0 bytes, without
having to deal with -1.
MozReview-Commit-ID: D0rXO0S0mss
--HG--
extra : rebase_source : 39784ff39d12d416358a181f0245ec2129c6992d
MediaResourceIndex caching requires GetCachedDataEnd and ReadFromCache.
Implementing SourceBufferResource::GetCachedDataEnd is trivial, as it's just a
buffer from 0 to GetLength(), so if the requested cached-data offset is inside
the buffer, we can just return the total length as known cached data.
MozReview-Commit-ID: 1DO0PzDnjQp
--HG--
extra : rebase_source : e7a652622221c04e77dc3a3b7707f22e1db25599
This is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
The Flash sandbox (which is the only thing this variable is used for) is stable
at this point, and for testing purposes we still have MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 6sxb1tx7oA9
--HG--
extra : rebase_source : d960c5a7afb04b90f098516f955b5fd00628b6a8
- Added new chrome-only webidl methods to be used by browser UI and WebExtensions
- Implemented bitmasked group visibility for VR sessions to enable switching
between chrome and regular content presentations.
- Implemented throttling mechanism to avoid runaway, unthrottled render loops
for VR sessions that are hidden by group visibility bitmasks or due to
lower level platform VR events, such as during the Oculus
"Health and Safety Warning".
- Simplified the PVRManager IPC protocol while extending it to support
VR session groups and later WebVR content performance profiling API's.
- Removed the last WebVR related sync IPC call.
MozReview-Commit-ID: BMEIPyYeEbq
--HG--
extra : rebase_source : 47d3682cad3d913504175b7d4c3e9d992236f097
There's no way to verify locally the while loop will execute and set the return value, so we get an uninitialized variable warning.
Initialize it at declaration time to failure, relying on the later code to override with success.
Actually, it doesn't matter what we initialize it to, since the while loop will never terminal if GetNextPacket somehow returns success without pushing a new packet onto the sample array. But this silences the warning.
MozReview-Commit-ID: 20rh1OGpR1E
--HG--
extra : rebase_source : 599a6d1bf0d38077bddfcec975e514eb8e5ee67e
This is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
On Android, the life cycle of graphic buffer is equal to Android's codec, and
it would be released immediately if we shutdown the decoder.
Since the buffer has been release, the memory we access is totally meaningless.
The result is we would render the black image on the screen.
In addition, I suspect this issue might be one of the root cause which results
in lots of timeout for media mochitest, so I would like to land this patch first,
and then do the follow-up in bug1367983.
MozReview-Commit-ID: 5eZph6MItZs
--HG--
extra : rebase_source : 99036cd087bf758c8a70be686c40fa2d84d7f6c1
Gerald Squelart
Chris Pearce
Ryan VanderMeulen
Fernando Jimenez Moreno
Chris H-C
Sebastian Hengst
Alex Gaynor
Kearwood Gilbert
Jean-Yves Avenard
Brad Werth
Carsten "Tomcat" Book
Christoph Kerschbaumer
Tim Taubert
Bevis Tseng
Andrea Marchesini
Markus Stange
Alfredo Yang
Alastor Wu