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
NotifyDataEnded() runs off the main thread which might set mChannelEnded
wrongly after NotifyChannelRecreated reset it on the main thread.
We should reset the flags in NotifyDataStarted() which indicate a new load has begun.
MozReview-Commit-ID: Gi6PFXwMJqc
--HG--
extra : rebase_source : 85bb2c25a55cce4b3c3f023bf4c02fe5d1de7552
extra : source : 2f8c5518bf615f9190f87032568fc53037bc6fc1
There are some works to do when we allow a stream whose download ends abnormally
to continue sharing the resource:
1. Abort Read() when download error happens. We might still have a chance to
get all the data successfully. However, it doesn't really matter since
the stream data is incomplete and we will encounter decode errors sooner
or later.
2. Update() needs to check mChannelEnded since an ended stream will not
download data needed by other streams.
MozReview-Commit-ID: LGCecQ5rpzq
--HG--
extra : rebase_source : 17a91a1cfd145344c3c0a29b80665cb99ce20746
extra : source : 0947c12b035acc9fba02e89dc87b3a17f84cf2e5
Since NotifyDataEnded() run its code asynchronously, it is possible that a new
channel is created and NotifyDataStarted() is called before NotifyDataEndedInternal()
has a chance to run. We check the load ID to exit the function if necessary.
We also need to fix data races when running NotifyDataEndedInternal() off the
main thread in next patches.
MozReview-Commit-ID: IIAc7dxHike
--HG--
extra : rebase_source : 58e45f924058a986b8d86bfaeff2791ee8a5f4bc
extra : intermediate-source : b2a7fa7514723e214b8da40cfc0ec40b1de9a345
extra : source : 1ff93dc8f8c451b804133c780cedef2ee3d348e5
We will need to modify these members off the main thead while IsAvailableForSharing()
is a main thread only function.
InitAsClone() will return an error if the original stream ends abnormally.
MozReview-Commit-ID: 1qRyboca2YZ
--HG--
extra : rebase_source : 4617a911a1de052833bd0085b883a8ae4d639c7d
This will remove the need to retry reading for the callers.
Note since data is usually downloaded faster than being consumed, we don't
benefit much in reading data from a partial block in the memory. Chances are
we still need to wait for the block to commit to the cache so the reader can
continue. So we change the code to always read data from the cache or from
the last block when it is completed (reaching EOS).
This change allows up to somewhat optimize NotifyDataReceived() which won't
have to wake up readers if no blocks are committed to the cache.
MozReview-Commit-ID: KwgNSOawuAE
--HG--
extra : rebase_source : af29b9f5d8b7ee1ed41bda5d23e1e94209e323b7
extra : intermediate-source : 863cb113d20b9cc1222de001bacbefa7eb8ac5c1
extra : source : 09683d9ffe477c27164769dc93e9eb9ee0af21bd
So it doesn't need to call mCacheStream.IsTransportSeekable() which needs to
take the lock and might block the main thread.
MozReview-Commit-ID: 99QVcSxzjCz
--HG--
extra : rebase_source : be71b065ce0334987efbfb67a5cf010ab0373d80
extra : source : 2de3f0baf1475e8ae3228a33cf4cf139cf923c37
Per 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: 3UWHbvtEUmu
--HG--
extra : rebase_source : d8c97d275ca5df7deb56447ef55092ac3d110e7f
extra : source : 8acc253fb322c4b6defb03bbc5489b5b1877f375
JW Wang
Sebastian Hengst
Narcis Beleuzu