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
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 : dcf61b2c43a7c030a0265979d75d18c63a3c41d0
extra : intermediate-source : 62e5895d3684b6fd00df7703156af5ea1f08bef3
extra : source : 09683d9ffe477c27164769dc93e9eb9ee0af21bd
to avoid uninitialized read in WebAudioUtils::ConvertAudioTimelineEventToTicks()
MozReview-Commit-ID: GHPGIrc0T2h
--HG--
extra : rebase_source : 3b6e482cbab07b30a05c1156f95ab6965a59d545
The session update triggered from the second LoadEME may come later than the end of playback.
MozReview-Commit-ID: K1vOaztbx4v
--HG--
extra : rebase_source : 81cdda75a8b88cf8ef712a57a149733069d04af1
Since MDSM won't treat EOS as an erorr now, so we could revert bug1359058 p2.
MozReview-Commit-ID: JqkIrOiBu8v
--HG--
extra : rebase_source : acaa7bff0f9c6ac86f5b1456eb72d95b4e2a1519
This will force a re-run of the VP9 benchmark.
MozReview-Commit-ID: 533NpQWrHDS
--HG--
extra : rebase_source : ffdefc4600545a27e3188f81a53db5680f4c550f
The DXVA decoder might hit some error because of the hardware device status.
This patch try to pass the error code to the decoder promise object to
deal with the error.
MozReview-Commit-ID: IAj8gzKGF3j
Adding tests that would have shown the issue fixed in Bug 1405940.
If the answer during a renegotiation has modified ICE credentials,
it should cause an error. These tests check for that error.
MozReview-Commit-ID: 9u8GGpslDdK
--HG--
extra : rebase_source : 6b204cefa96e95abd61d9a57ddd643dd81a41254
For now we dump debug info when the whole test case finishes. However, it
would be harder to relate the debug info to the timed out test when there
are multiple test timeouts.
Note we don't call |this.finished(token)| until v.mozDumpDebugInfo() is done
because |this.finished(token)| might finish the whole test case and clean up
the page which might change the output of v.mozDumpDebugInfo().
MozReview-Commit-ID: BrdZ0EVpaBQ
--HG--
extra : rebase_source : ee5d20c3ab605568e7fe895f14b8e9468fffd5ab
extra : source : 1288e105a94ac05fc3a978b7287dd45ecdfb6e8d
It doesn't matter that this is traversed by the cycle collector when the track is live and playing.
It prevents cycle collection of any number of MediaStreams that contain (thus consume) this track.
MozReview-Commit-ID: GvdLfWDTVQQ
--HG--
extra : rebase_source : 29e65d25bd7cdf03e32ff4aa736b0ff762ebf1c1
Sebastian Hengst
JW Wang
Andrea Marchesini
James Cheng
Narcis Beleuzu
Ryan VanderMeulen
Jesse Ruderman
Kilik Kuo
Margareta Eliza Balazs
Karl Tomlinson
bechen@mozilla.com
Alfredo.Yang
Alastor Wu
Chris Pearce
Jean-Yves Avenard
Csoregi Natalia
JerryShih
Bob Clary
Jon Coppeard
Michael Froman
Andreas Pehrson
Andreas Pehrson