Should mStreamLength be > 2^32, we could have overflowed leading to false positive test.
Differential Revision: https://phabricator.services.mozilla.com/D6235
--HG--
extra : moz-landing-system : lando
Prior bug 1416085, reads were clamped to the content's duration (if known). It appears that the new code relied on MediaCacheReadBlockFromCache to properly account for the end of content.
However, this was not the case, the MediaCache always reads (and write) one full block at a time regardles of the size requested (a block is 32768 bytes).
Rather than clamping in the Read() method as it used to be, we clamp in ReadBlockFromCache as such safety will benefit other callers that would have otherwise also returned garbage reads.
Differential Revision: https://phabricator.services.mozilla.com/D5964
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Bug 1415090 attempted to remove the need to access from the MediaResource members of MediaCacheStream from the main thread.
However, by doing so the logic flow for resuming the channel changed from a synchronous access to an asynchronous one.
This changed some assumptions and allowed the ChannelMediaResource to be used before the Seek call completed.
For now, re-add a cross thread access to the MediaCacheStream. A more elegant fix will be worked on in bug 1464045
MozReview-Commit-ID: 2xBTjDEqrkI
--HG--
extra : rebase_source : 0aa3cfcb8371d5147cbed746d9200dd22df4821b
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
It is possible that download is suspended after all bytes are received but
before OnStopRequest is notified. In that case, we will fail to wake up the
readers waiting to read the partial block and cause bug 1412737 comment 30.
MozReview-Commit-ID: GUk4lXO6Upk
--HG--
extra : rebase_source : 2fc277fa54842e434c3f69a474c44fb4c58c976e
Per bug 1412737 P2 changes, a reader will always read data from the cache or
from the last block in the memory. NotifyDataReceived() will be slightly more
efficient if we don't wake up readers unnecessarily when there are no new blocks
committed to the cache.
MozReview-Commit-ID: Afcy5OOeIk3
--HG--
extra : rebase_source : 64916432081d23234e4cc923c343a9724d6c77db
Note we add mClient->CacheClientSuspend() so the network state of the element
is changed to IDLE because we have no channel to fetch data initially.
MozReview-Commit-ID: DgJbMxvJBzH
--HG--
extra : rebase_source : 69a3ef35d4b5faaaa645fabe02246d49aebce22e
extra : source : 61ec40ce378a444ec0f74d474c28b6a9db3aa830
Since we now never take the lock on the main thread, we can safely do file IO
while holding the lock without blocking the main thread.
This reverts the change of Bug 1354389 P1.
MozReview-Commit-ID: EhEwTjINQIT
--HG--
extra : rebase_source : 7eca1226d53a26025188e01837de645a1c879d7b
It is bad to modify the array while iterating it.
MozReview-Commit-ID: JbpoRmM7GqP
--HG--
extra : rebase_source : 92523a0741aa6014808b182954f653fce54161fd
So we won't need to take the cache monitor on the main thread.
MozReview-Commit-ID: FavZKcfaHn8
--HG--
extra : rebase_source : 8a0483a5db9db3d39dccf110ba363144f5e9b6dd
extra : intermediate-source : 214edc1ef96cc2f8b60a86ce068cb8b0593cb1f7
extra : source : ce13b43e884185a988205d0f3e860cf823458b37
We should call ChannelMediaResource::CacheClientNotifyDataReceived() no matter
new data is coming from the channel or copied from the original cache stream
so the decoder has a chance to compute 'canplaythrough' and buffer ranges.
MozReview-Commit-ID: I4cLow2VzJg
--HG--
extra : rebase_source : ede936c94a6d728cf6c596863e45aa45d2617d45
It must be infallible for there is no way to propagate the error back to the
main thread when part of the init functions run on another thread. It is OK to
clone a stream that ends abnormally as long as we don't copy the error status
of EOS. The cloned stream will open a new channel when necessary.
Note we also copy the partial block from the original stream to get as much
data as possible and thus reducing the chance of reopening the channel.
MozReview-Commit-ID: 37iYQonFdBU
--HG--
extra : rebase_source : 6bb9983bc8d1f2675557a14acf1824dba4a98fff
extra : intermediate-source : a20ff9a873db93c85750bb2af5bf05c27c9da3c3
extra : source : 0763fb0e7b4ed1096e406dadccb3ca698f39b207
Note we offload MediaCache::CloseStreamsForPrivateBrowsing() to another thread
so we don't need to take the cache monitor on the main thread.
MozReview-Commit-ID: 9hYszHZ0OJJ
--HG--
extra : rebase_source : 652b4ca783a52d28b0948e81d7b54ed79094230d
extra : intermediate-source : 46316625deb99585c42026010d994fa22b5b3dca
extra : source : 8c9e8ac739eb347b3b8ba24229cafcf2a3e3c4cd
We want to init as many members as possible before taking the cache monitor.
This makes it easier to move part of the init functions to another thread.
MozReview-Commit-ID: 6mmO356nCyQ
--HG--
extra : rebase_source : 0e5093e01227e2008200cc1fa02aaac445833614
extra : intermediate-source : 2a6bf63954734d0c6470b425a9a8a77f8a805dc3
extra : source : 782ebf089ec17570650ce1635a591c3a9838d7a3
So we won't take the cache lock on the main thread.
MozReview-Commit-ID: KYSB0vonOZ2
--HG--
extra : rebase_source : 142884bb450a5469b2634a676ce2d4f3c1790954
extra : intermediate-source : 0911c55511374cd19719743531c136fc122e4ab0
extra : source : 2f46a7eddea484fc5dec773d9d57896e524e014d
We will offload MediaCacheStream::Close() to another thread and need to access
mClosed off the main thread.
MozReview-Commit-ID: 891rzC8dOON
--HG--
extra : rebase_source : 5cf18c4cdfe32dcc1894d5849b74a16582dcde51
extra : intermediate-source : 77febb3f2ca53cd5bb4834b110a4ff44a21556b0
extra : source : b4513de1038e6413477d09ef531f076ecb3955b3
In MediaCacheStream::NotifyResume(), it will not reopen the channel if
|mChannelOffset==mStreamLength && 0 <= mSeekTarget < mStreamLength| while we should.
MozReview-Commit-ID: 2knkgy6FEVw
--HG--
extra : rebase_source : 28e7910572bd25d189b942f9961f77ec336dea19
So we won't access mStreamLength/mChannelOffset (which are protected by the
cache monitor) on the main thread.
MozReview-Commit-ID: 2pKEttZOfB9
--HG--
extra : rebase_source : a683d7297e241f2aeaf60ba9ad558763d17ee094
extra : intermediate-source : 0a6c10e10d1e558b19799b720935bbdaa56728bf
extra : source : 282de2a9189e5e05f5f817174ebcffe1b592bb1a
So it is callable from non-main thread.
MozReview-Commit-ID: atYmz4u2c9
--HG--
extra : rebase_source : 2e10064730b3e7e1ecb1a4fd65cf2e2da0390290
extra : source : 5680a6942f6985f9c6bbf284a9768ab910b37804
We always read metadata when decoding starts. This allows us to remove the call
to mResource->SetReadMode(MediaCacheStream::MODE_METADATA) in ChannelMediaDecoder::Load().
MozReview-Commit-ID: AQMq4HxDZdT
--HG--
extra : rebase_source : 141c43bb93f274d8320a270b5c7289bd1eab134d
extra : source : 7de3d88ddb5c99352f4b5bd0b5e648a52a4a67a5
See comment 0 for the detail.
We will replace ReentrantMonitor with Monitor in the future.
MozReview-Commit-ID: 63ygEFWXHZd
--HG--
extra : rebase_source : 71d1049663e5af5ca178402f84fabdc4ab0f8758
extra : intermediate-source : 20d349df7c16227b6fa1cd3c1d38b1065c93da8c
extra : source : 9cdcfd446686eace7258d18262d8dd92c0f70331
For it is used internally by CacheClientNotifySuspendedStatusChanged() only.
MozReview-Commit-ID: 8XVUHhdERYR
--HG--
extra : rebase_source : 60b97821b3e1c13bf1ba706ad1431b9e323df319
extra : intermediate-source : 6891fae737691efcf0885ff90fc7af777f9493d8
extra : source : 8c49a2fbc12f59c83809d233c9c0e9fa404cdd21
A truth table is listed to illustrate all conditions of length/offset/reopen.
The original code doesn't handle the following cases correctly:
1. length == offset == 0, shouldn't reopen the channel for there is no data to download.
2. length == -1 && offset > 0, should reopen the channel if seekable.
MozReview-Commit-ID: IisnrA8hK4M
--HG--
extra : rebase_source : c5826f314b09b2ae9c3e7f2cc1f6ce285fc612df
The server might send us fewer bytes than requested. So we also need
"reopen on error" in this case as well.
MozReview-Commit-ID: Fi82x4h1TZ0
--HG--
extra : rebase_source : 3a19838de9c11545f00778623735c7e9a5cb1439
Ryan Hunt
Sylvestre Ledru
Jean-Yves Avenard
Chris Peterson
Andi-Bogdan Postelnicu
Nicholas Nethercote
Sebastian Hengst
Tristan Bourvon
JW Wang