Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
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
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : a2f4b7c68b73ecc4c7525d4e41e834f4caf85707
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : 3ed71273da24f8f0c8bc24ceede49afa7775650d
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : cdc122a11a648f2451d2983df42597d8274ac9fb
It is not needed since we are already in the right context.
MozReview-Commit-ID: 6QXxLMQHavv
--HG--
extra : rebase_source : d7a80d3e3d6583bd1732a4048f40576603e83872
extra : source : d700cc52ce2a50a784601f7cff7f63eaff3efced
We also need to call GetOwner()->UpdateReadyState() since mCanPlayThrough might
have changed.
MozReview-Commit-ID: C5djzu1sXqV
--HG--
extra : rebase_source : 1037cb7e1bf3a32fa60451e9a2a64ce63d06b8c2
extra : intermediate-source : 373c47f094dfb85ca2576d18a302d9ceb4e82ed5
extra : source : b710ff5026c18ac851be56ac9a369fe69b1d5b5d
PinForSeek() is called only when playback reaches the end. In other words,
it is not called for most cases of seeking. It should be OK not to call it at
all during seeking.
MozReview-Commit-ID: 1xXX1321bO7
--HG--
extra : rebase_source : df8ba3f59da2a337b456546af4b54abaddfe38a9
extra : intermediate-source : 0a70419f9ce639ac0784a0632db4598d6be511f8
extra : source : bfddad9b922386c91fcfa7657a7ac274991d15f4
GetOwner()->DownloadProgressed() will update readyState of the media element
which will need to read mCanPlayThrough.
MozReview-Commit-ID: EDHlLJjKDoL
--HG--
extra : rebase_source : df4ffabc02f9e6b4b20e5fa6c9be6988570a9974
extra : intermediate-source : 371a6509c04bf89edb07b3437a41a9b36dba25ff
extra : source : 227ffb87de637994baefab6b178afeae4673a2ef
Note we cache the result of GetStatistics().CanPlayThrough() which is needed
by CanPlayThroughImpl().
MozReview-Commit-ID: QYNqk1pUN5
--HG--
extra : rebase_source : e4ce549f1069fd3106da4f68dcb429afa291aa5d
extra : intermediate-source : 9d7c532bdad7733bc3f9e725feecd83bea1ab156
extra : source : b552dad39a644026eb0d62e7e975c4120e550447
Usually mDecoderPosition and mPlaybackPosition are in the same cached range so
GetCachedDataEnd(mDecoderPosition) and GetCachedDataEnd(mPlaybackPosition) will
give the same result.
It also makes more sense to pass the playback position instead of decoder
position since 'canplaythrough' is about playback instead of decoding.
MozReview-Commit-ID: Kk1uUeSFTCI
--HG--
extra : rebase_source : 1f40adce4b93dbcf55cb3de9f5c16fdd6d0b6bee
extra : source : 9c77dddb2faca84bd8cf09fc2007e18986e62f64
Mostly-mechanical replacement of MOZ_LOG with DDMOZ_LOG, usually just removing
the class name and `this` pointer (as they are already implicitly recorded).
Some files needed a bit more work when logging was done from helper classes or
static functions.
MozReview-Commit-ID: IeJJmzYqWMQ
--HG--
extra : rebase_source : 94200838dcdaf6c3bda9de30042ce2d307237eef
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
It should be called explicitly for anyone that wants its side effect.
MozReview-Commit-ID: EHiPjklV6oZ
--HG--
extra : rebase_source : bb7b0138698448f1064e90b0318637db969b1527
So it won't have to call GetStatistics() again.
MozReview-Commit-ID: 1tRnRHAiX4L
--HG--
extra : rebase_source : 4e2d3c4eb6f149fded9c9ba05872a72c55fad05b
We calculate 'canplaythrough' in ChannelMediaDecoder::DownloadProgressed() and
send updates to MDSM.
MozReview-Commit-ID: KAeDciPAUKs
--HG--
extra : rebase_source : 64d7705fb5ca6b1003664ac313ad1ae0ab1bbea6
We want to remove the side effect of ComputePlaybackRate(). Anyone who wants
the side effect (updating mPlaybackBytesPerSecond/mPlaybackRateReliable)
should call it explicitly.
MozReview-Commit-ID: 8oHvCl5pewz
--HG--
extra : rebase_source : 3ee54ea32d2d2d7185d9a65c6658a3e700f1fb71
Usually mDecoderPosition and mPlaybackPosition are in the same cached range so
GetCachedDataEnd(mDecoderPosition) and GetCachedDataEnd(mPlaybackPosition) will
give the same result.
It also makes more sense to pass the playback position instead of decoder
position since 'canplaythrough' is about playback instead of decoding.
MozReview-Commit-ID: Kk1uUeSFTCI
--HG--
extra : rebase_source : 354fe5b4a6fb73a477ded40bf5fb91979a2c2a8a
Otherwise mPlaybackBytesPerSecond will always be zero before playback is
stopped for the 1st time. This is important for a live stream where playback
rate can't be calculated from the duration and resource length (-1).
MozReview-Commit-ID: GEojREzHVEz
--HG--
extra : rebase_source : 6f770b54597abb303631da8e41c3199d92ebda6e
The original code accumulates bytes as the underlying decoder moves on which is wrong.
MozReview-Commit-ID: 72hTwOHwKRh
--HG--
extra : rebase_source : 68b62543314c7ecc823473a8dbf14e17d2a6eb7b
shindli
Chris Pearce
Tarek Ziadé
Andreea Pavel
Noemi Erli
Jean-Yves Avenard
Sylvestre Ledru
Csoregi Natalia
Narcis Beleuzu
Ryan Hunt
Emilio Cobos Álvarez
Paul Adenot
Nicholas Nethercote
Margareta Eliza Balazs
Dorel Luca
JW Wang
Ryan VanderMeulen
Gerald Squelart