Note we remove the call to mChannel->SetContentType() from RecreateChannel().
The hint never works as expected for [1] is the only caller to
nsIChannel::GetContentType() and MediaResource::Create() always happens
before any reads from the resource.
[1] http://searchfox.org/mozilla-central/rev/b425854d9bbd49d5caf9baef3686e49ec91c17ec/dom/media/MediaResource.cpp#1500
MozReview-Commit-ID: 1n4yHEouCjC
--HG--
extra : rebase_source : 9a7345c29b985ddee7a90a94191e9d526e2a0a67
extra : source : 054d9ffaf21eb937a6349df76228269ad2d7dc2c
Also remove CanClone() overrides that are identical to that of the base class.
MozReview-Commit-ID: A0Q5ychQtso
--HG--
extra : rebase_source : 3369558a8e6bc9f86ab6dcdc39fe40f686041001
Bug 1368837 (Add lockless cache to MediaResourceIndex) used
MediaResource::ReadFromCache when trying to fill its local cache. But this
meant that these reads would not count as "real reads" for the MediaCache,
which could lead to unexpected states, e.g. "Played block after the current
stream position?"
To solve this, this patch reverts to using normal ReadAt() calls, which let
the MediaCache update itself properly.
While still trying to read more than what is requested (to hopefully fulfill
future reads from the local cache), we don't want to be reading so much that
we block waiting for data past the caller-expected point.
To do this, MediaResourceIndex::UncachedRangedReadAt() is called to try and
read as much as could fill the local cache, but if a single
MediaResource::ReadAt() ends before we can fill the local cache, but *after*
the minimum caller-requested size, we stop trying to read, as such extra read
is at risk of blocking (assuming that the caller knows not to read too far.)
MozReview-Commit-ID: 6fGvJpmkuLz
--HG--
extra : rebase_source : bf8e9f20599a05c8f3f221b55d678f0b5da447a9
MediaReadAt() accesses only public members of MediaResource. It doesn't have
to be a member of MediaResource.
MozReview-Commit-ID: D7ByCLiAF4X
--HG--
extra : rebase_source : a25cdee55882c1a5da5816a21f600aab6d4491b3
extra : source : ecbf4d9750d7c0e34fe55208903f0712b4759023
The difference is the sub-class override doesn't call DispatchBytesConsumed().
It doesn't make sense not to call that after you do consume some data.
For callers that want silent reads, they should call ReadFromCache() instead.
MozReview-Commit-ID: J3dn8qgWKoL
--HG--
extra : rebase_source : 45f465e45ef3d67f989a3235dc1ddd76b11f1a81
extra : source : 9daf21e4c588e6cf13f3b28d8ffd8719573158c0
This hint will inform readers if caching is discouraged (e.g., for
SourceBufferResource) or recommmended (e.g., for MediaCache-backed
ChannelMediaResource).
MozReview-Commit-ID: 7hopNS0s5tE
--HG--
extra : rebase_source : 681646cc904229e8513adb148baa085254508049
This allows us to init mChannelStatistics in the constructor and
remove the possibility where we deref a null mChannelStatistics.
MozReview-Commit-ID: 9ZIRu0VXpd6
--HG--
extra : rebase_source : 741c8220e7e451b870aa9edd7d4006fd5c83eec4
extra : intermediate-source : 3cfd983577294749d85a4403724b42689f648df9
extra : source : a3f466b63da03a4989c799c169666bf0df937917
8KB by default, otherwise using the next power of two from the given
media.cache.resource-index (but staying within 32B-128KB).
'0' means we don't want to use caching.
MozReview-Commit-ID: 8LmS15Ft2MA
--HG--
extra : rebase_source : 992f377a07b7ab173a64fcfbfe45df1da87df31e
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
We don't want to trigger download when calculating buffer ranges since download
changes buffer ranges.
MozReview-Commit-ID: Be8qFUQ5PpR
--HG--
extra : rebase_source : 4fd77e031577332d9d112faef869cd935275b1af
Continuing the work of replacing MIME strings with MediaContainerType, starting
from MediaResource and following the dependencies.
Most changes are mechanical: Just change ns*String into MediaContainerType, and
MIME string literals into MEDIAMIMETYPE("a/b").
Some checks for empty/invalid strings and lowercase comparisons can go, thanks
to the always-valid always-lowercase-MIME invariants of MediaContainerType.
One special case in is MediaSourceResource, which used to have an empty string
as its type (because its own type is not relevant, but its SourceBuffers carry
types). Because the inherited GetContentType *must* be overridden, and must
return a MediaContainerType, we needed a valid type even though it should not
be seen in the real world. I've chosen "application/x.mediasource" for that.
MozReview-Commit-ID: 1aCH75Kh2e6
--HG--
extra : rebase_source : 0d9cd9b69c264e5dcfc3845f80ee107f4bcbcd9a
Slightly less than half (93 / 210) of the NS_METHOD instances in the codebase
are because of the use of NS_CALLBACK in
nsI{Input,Output,UnicharInput},Stream.idl. The use of __stdcall on Win32 isn't
important for these callbacks because they are only used as arguments to
[noscript] methods.
This patch converts them to vanilla |nsresult| functions. It increases the size
of xul.dll by about ~600 bytes, which is about 0.001%.
--HG--
extra : rebase_source : c15d85298e0975fd030cd8f8f8e54501f453959b
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
MediaResource::ReadAt() requires to loop several times to ensure that all data has been read as it may return less data than requested.
This will allow to remove the handling of this particular shortcoming in MediaResources' users.
