This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
This is a workaround to fix bug 687972. It should be OK now to remove
it since we have fix bug 1108960 where MediaCache failed to run the
update loop to update the suspend status of the stream.
MozReview-Commit-ID: MbInehhScs
--HG--
extra : rebase_source : 94345a00af31834db8b9858cdf5a9e889044156a
extra : source : 70f626894c3a15c8077f70425a97004478caa9e1
It would be less accurate to call SetReadMode(MediaCacheStream::MODE_PLAYBACK)
in ChannelMediaDecoder::MetadataLoaded() instead of DecodeMetadataState::OnMetadataRead()
because MDSM might have started decoding by the time 'metadata loaded' event arrives
in the main thread. However this little inaccuracy should be fine since it only
affects a small amount of data concerning the eviction algorithm.
MozReview-Commit-ID: JoQMGr5Fvge
--HG--
extra : rebase_source : 3663a028522cc8b973964f62e59d7568a5eba10a
extra : source : 359b4454633432d3334a106aedb267a2451afb45
So we reduce the number of unimplemented methods in the sub-classes of MediaResource.
MozReview-Commit-ID: EAmUEv9WQk8
--HG--
extra : rebase_source : deed5fd089e8c42a5a6ab0546e0781d0061591e5
1. we move clone related methods to BaseMediaResource which is the only cloneable sub-class of MediaResource.
2. add CanClone() to ChannelMediaDecoder to reduce the dependency on MediaResource for HTMLMediaElement.
MediaResource should be internal details to MediaDecoder.
MozReview-Commit-ID: Hl2nAiuyTO0
--HG--
extra : rebase_source : 43dd9ee33ef2ef2e9093eb6b264dc174379d61d2
extra : source : 978ded48a90f2c407c4545486243acabf492736a
Now we can store a more specific resource type in ChannelMediaDecoder.
MozReview-Commit-ID: EzXC547O7aR
--HG--
extra : rebase_source : eea1872eeeee9b5964fcc767c79b0315bf277602
extra : source : 84011bf4847bbed26e89af0b831aded93522f7ac
Also check that the offset doesn't overflow during reads.
MozReview-Commit-ID: DT5neeZuMZu
--HG--
extra : rebase_source : 1f0de82916ebf770a0ea2570161d607216232dfa
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