The initial telemetry collection was done in NotifyDataLength() because that
was the first point where the length was introduced; but some extra code was
needed to ensure that were collecting the first length.
Now that this initial length is passed directly to Init(), we can report that
number instead.
In the "worst" case, it will actually be a bit more correct about what we
initially wanted to report, i.e., the initial length given by the HTTP
response header; and it's what we really want to know, now that we are using
this number to make a decision about which MediaCache to use.
MozReview-Commit-ID: 11Th8pensZt
--HG--
extra : rebase_source : 97a6d2dcbfad6c9b37819bfe6471baff2ec7e335
This will give enough information (for now) for GetMediaCache to decide whether
to use the (one global shared) file-backed MediaCache, or a discrete memory-
backed MediaCache.
(Note that GetMediaCache doesn't use this length yet in this patch.)
MozReview-Commit-ID: 5B2E3sIsc4k
--HG--
extra : rebase_source : 940e782665bf2c3640bbe7389fca02ea7c1482cd
This is the new recommended way to create&initialize the file-backed
MediaCache.
In future patches, this will also allow the creation of memory-backed
MediaCache objects.
MozReview-Commit-ID: 6RUlNW2eBPP
--HG--
extra : rebase_source : 0b3e6fae71207076812b5cb9172d4497d3e68ea2
MediaCacheFlusher constructs itself when needed by the first MediaCache, and
destroys itself when the last MediaCache unregisters itself.
Some MediaCache member functions had to be made non-static, so they could be
called for each instance.
MozReview-Commit-ID: 5Dh9mEKbZHg
--HG--
extra : rebase_source : 1570e30787ba486f9436b4b05aa3cfa0329d1ee7
Capture each media stream's length (as provided, otherwise as actually
downloaded), to gauge whether keeping media in memory would have a significant
impact.
MozReview-Commit-ID: 4yUQrbgLcGG
--HG--
extra : rebase_source : bed0ea1d58f864463926478b0f8ea59e7084c4af
Capture each media stream's length (as provided, otherwise as actually
downloaded), to gauge whether keeping media in memory would have a significant
impact.
MozReview-Commit-ID: 4yUQrbgLcGG
--HG--
extra : rebase_source : bed0ea1d58f864463926478b0f8ea59e7084c4af
block->mOwners might be empty if all streams for the resource id are
closed. We don't bother write the data to the cache since there is no
stream to use it.
MozReview-Commit-ID: KKiyZqLBjim
--HG--
extra : rebase_source : 7fa0a6d841dff91dd7142aac5a336b950342ac67
UniquePtr<uint8_t[]> has the same alignment as UniquePtr<int64_t[]> for the
underlying buffer. It also allows us to remove some reinterpret_casts.
MozReview-Commit-ID: 8V1lZdayFQv
--HG--
extra : rebase_source : 61f1943b9f3e464b47865fb0fff2742125f4c688
extra : intermediate-source : 329adb8a4414f32e2f83ba79af06d288d7b25705
extra : source : ba967b187b9dbc8f402db90272f55b9ee9d92692
This allows us to save copies in combining 2 bufffers into one before calling
FileBlockCache::WriteBlock().
MozReview-Commit-ID: 62kQIxp3Ju0
--HG--
extra : rebase_source : a64c160b9ab3d7bbd724be053fea6358ae7885df
extra : source : f699fdb6fdaf1fd5b4dfeb394928c95e33853a53
No change is needed for MediaCacheStream::Read() which calls |mon.Wait()|
and has handled changes when dropping the monitor.
MozReview-Commit-ID: 40h0cHn1WFx
--HG--
extra : rebase_source : 5447339ed7751f3171458d8e5fb1e5f6fe3a786e
We don't want to do IO while holding the monitor which might be acquired
on the main thread in MediaCache::Update().
MozReview-Commit-ID: 4cHM35K8Twb
--HG--
extra : rebase_source : 5a00332933abd1812f64fa57c9f5e2947ec979ae
In bug 1346987 we're attempting to remove uses of the
NS_OpenAnonymousTemporaryFile() in the content process as it sends a
synchronous IPC to the parent process on the main thread, which can cause UI
jank. This patch makes the MediaCache use the async anonymous temporary file
creation function added in bug 1346987.
The file descriptor is held by the FileBlockCache. This object buffers data
passed to it in memory, and defers writing of said data to another thread. I
added the async wait for the file descriptor to be inside that async "defer to
other thread" step.
This means that while the content process is waiting for the file descriptor to
come down from the parent process, we'll buffer media data being streamed in
memory. Given that our MSE implementation will buffer up to 100MB of media data
in memory anyway, it seems that more buffering in the src=url case while we
wait for an async IPC to do a round trip to the main process is acceptable.
MozReview-Commit-ID: 3OTBTWw5pr0
--HG--
extra : rebase_source : 56e0a1f1473db3c9722330254f7a4bf3a1f5caa3
It is safe to call Tell() on the main thread because it won't block the main thread like Read() does.
MozReview-Commit-ID: 64B41l8fe1
--HG--
extra : rebase_source : b5fc0ec44e8c238841c4f4329d14a0e476f7e422
extra : source : 3d229e2cc659d262ce04c4b09b3484b6524af4b4
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
