The MediaCache reads content by block of BLOCK_SIZE bytes (currently 32kB). As such, if a content being fetched is less than BLOCK_SIZE, it will always be fully read from offset = 0. We can then seek within this buffered content regardless of the underlying HTTP connection supporting request-range or not.
test_bug686942.html is ultimately testing a racy behaviour: it attempts to seek into a resource that isn't always seekable (http.js doesn't report Range -Request support for small files). The seekable range becomes then the buffered range which at the time of loadedmetadata may not be set yet.
Differential Revision: https://phabricator.services.mozilla.com/D3028
--HG--
extra : moz-landing-system : lando
I'm seeing intermittent failures of test_midflight_redirect_blocked. In this
test, our custom server responds to Firefox's 0- HTTP Byte Range request with a
[0,200] response. When Firefox requests 200-, the server responds with a cross
origin redirect, and then the remainder of the resource.
However sometimes while running test_midflight_redirect_blocked the MP4 demuxer
reads through all 200 bytes while trying to parse metadata before the redirect
has occurred and fed more data into the cache, and so the demuxer thinks it's
hit end of stream, and reports a failure. The demuxer thinks it's hit end of
stream, because we initialize the MediaCacheStream length in
ChannelMediaResource::Open() with the value of the Content-Length HTTP header.
But in an HTTP byte range response, the Content-Length header tells you the
length of the range returned, not the length of the entire resource. The length
of the resource is in the Content-Range header, we need to use that if
available.
So to fix this intermittent test failure, we need to also parse the
Content-Range header in ChannelMediaResource::Open(), and use the length from
that if available.
MozReview-Commit-ID: 29pPRsUvxag
--HG--
extra : rebase_source : ba1ef03d65ebd22698a29d8385f36b4c747ccf43
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
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
Note SharedInfo contains an array to store the original and cloned resources.
This allows us to iterate over resources on the main thread without taking the
cache monitor.
MozReview-Commit-ID: K3gcPYbf72Z
--HG--
extra : rebase_source : eaa070a889797c29d2599b4c3d2507f440d476e7
extra : source : 5dc420815d7a26771c176cdc7b6a87a1c2278da8
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
So it is callable from non-main thread.
MozReview-Commit-ID: atYmz4u2c9
--HG--
extra : rebase_source : 2e10064730b3e7e1ecb1a4fd65cf2e2da0390290
extra : source : 5680a6942f6985f9c6bbf284a9768ab910b37804
For it is used internally by CacheClientNotifySuspendedStatusChanged() only.
MozReview-Commit-ID: 8XVUHhdERYR
--HG--
extra : rebase_source : 60b97821b3e1c13bf1ba706ad1431b9e323df319
extra : intermediate-source : 6891fae737691efcf0885ff90fc7af777f9493d8
extra : source : 8c49a2fbc12f59c83809d233c9c0e9fa404cdd21
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
We want to suspend/resume a channel only after OnStartRequest()
and before OnStopRequest().
MozReview-Commit-ID: 4QNRdsVvyAK
--HG--
extra : rebase_source : 6514ffe15247892042581df51decbaba4fb756b7
extra : intermediate-source : 930c31e1a06c70b69060f9f0079be186c2f2793b
extra : source : 42fb27a7fb2b3b0bea9d5e4fa0d5ba07f6fa1d3e
http://searchfox.org/mozilla-central/rev/ed212c79cfe86357e9a5740082b9364e7f6e526f/dom/media/ChannelMediaResource.cpp#727-729
mReopenOnError is a flag to reopen the channel when resume fails.
It makes more sense to associate this member with the channel we are resuming.
MozReview-Commit-ID: DwKUyvyzWdi
--HG--
extra : rebase_source : 430b51545106c10a9c53592063aed72433336111
extra : intermediate-source : 9d315280bcc755664001b5dd4d37eb52c5166b82
extra : source : e87e3cc8f9da47f2880d1e817f80638988409498
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
By mirroring the suspend status of the client, Update() is able to make
decisions on reading streams without calling mClient->IsSuspended().
MozReview-Commit-ID: G4gS2VGiMjj
--HG--
extra : rebase_source : bcdc1010fce47965c999df61666983c87e189670
extra : intermediate-source : 9dd8cfb80e29677e8cae866b2326dfb0aec5b6ae
extra : source : d20f640bf99478c9ba581e4979ec8091ef94e0f3
Seek() can't create a new channel if the resource is still suspended. we need
to store the seek offset specified by the cache so we know where to seek when
the resource is resumed.
Otherwise the new channel will download data at the wrong position and the
cache will need to run Update() and call CacheClientSeek() again which is
a waste.
MozReview-Commit-ID: 9OJ3FRnKitT
--HG--
extra : rebase_source : 562a1503640e1e25672bf3e693698ecc8ff29db6
extra : intermediate-source : e4945cc86c4c2b31fa3f20a32331db4ca1875c38
extra : source : a65982e09035f4aea7b4dcbde25b2a42565d932f
So we can check this member without calling mCacheStream.IsClosed() which need
to acquire the lock and might block the main thread.
MozReview-Commit-ID: 4SPooaprrOw
--HG--
extra : rebase_source : 36cbb2d02c29737a6b2060d588f4919cb9d55c05
extra : intermediate-source : 213f6fef98475069d2719ec6c9d1afaacb8a80ed
extra : source : 63200b22f2be79d6f0ff158e5b0c8f5b49849bf1
These listeners will be AddRefed/Released off the main thread when
OMT data delivery is enabled.
MozReview-Commit-ID: CSOBgNNf3OW
--HG--
extra : rebase_source : d9085c6447e51d3aa9cad79fa1e25d986fdee792
extra : intermediate-source : 21be6f0003e6d3ccf4448e6574ea5d3122665155
extra : source : 8ce13766af359b5e55524e47ea74bcfc0e0133f8
This means MediaResource.cpp now only contains the stuff for the MediaResource
super class, and MediaResourceIndex.
MozReview-Commit-ID: 5xFxibn0aJ4
--HG--
extra : rebase_source : 4cb940008abb62c43759689cdc9e034d25b7e36f
This means we can simplify MediaResource.h to only include the abstract
interface, and MediaResourceIndex.
I also had to add a few includes here and there to fix the non-unified build.
MozReview-Commit-ID: 4R7LTXq25dm
--HG--
rename : dom/media/MediaResource.h => dom/media/BaseMediaResource.h
extra : rebase_source : edef4a65df4dcb92f8536052d170d78f95315753
It currently resides in MediaResource.h, but it's only used in a
ChannelMediaDecoder and ChannelMediaResource, so it doesn't need to be in the
abstract header.
MozReview-Commit-ID: GskE5mjMav1
--HG--
extra : rebase_source : b42321ddcb1966d4de7203f04852c14f6d271acd
See comment 0 for the rationale. We check |aRequest != mResource->mChannel|
to know if a new channel is being loaded and the call should be aborted.
MozReview-Commit-ID: 6G1x7cXNvAq
--HG--
extra : rebase_source : 3114979192346e257f5d8040b8e0ffffa419d3f5
extra : source : eeb067bc2905dfa6fb5764fd42ebb78e1b71a61d
The load ID works as follows:
1. A load ID is passed to MediaCacheStream::NotifyDataStarted()
when loading a new channel.
2. Each MediaCacheStream::NotifyDataReceived() call is also associated
with a load ID from which the data is received.
3. If |mLoadID != aLoadID| tests to be true in NotifyDataReceived(), it means
the data is from an old channel and should be discarded.
4. MediaCache::Update() reset mLoadID for the stream before calling
CacheClientSeek() to prevent data from the old channel from being
stored to the wrong position.
MozReview-Commit-ID: 9kBoublLlln
--HG--
extra : rebase_source : 58e6d3fe40ec7a549cabc70b30db8006b49c0563
Andrea Marchesini
Sylvestre Ledru
Jean-Yves Avenard
Chris Pearce
JW Wang
Gerald Squelart
Phil Ringnalda
Sebastian Hengst