Bug 1386489 means that ended is not reliably set in relation to the test
seeking machinery. This results in the following behaviour being possible:
- seekToNextFrame seeks to last frame
- the seek promise resolves and invokes check to see if video has ended
- ended is not yet set (race), so another seekToNextFrame is setup
- onended handler is invoked at some point (1st time)
- seekToNextFrame seeks again, remains at last frame
- oneended handler is invoked again due to the seek (2nd time)
- finish() has been called twice
This changeset should bandaid the above being possible.
MozReview-Commit-ID: BkskWUnaJQ9
--HG--
extra : rebase_source : 0108cf82a805136a87752d0128c1c0f2e7997ff6
Otherwise Seek() will continue to call OpenChannel() and hit null-deref for
mChannel is null.
MozReview-Commit-ID: 4nhbF9lUOSR
--HG--
extra : rebase_source : cb58448ddd9e68314b07e6160354d7be9ea2809a
extra : source : 4d50e2d60a4f9a5ababaaa5100b170dd64c73dbc
This is a fix to P3.
Since seek is performed asynchronously by CacheClientSeek(), it is possible
for OnStopRequest() to come before Seek(). Changing mChannelOffset will
cause MediaCacheStream::NotifyDataEnded() to update mStreamLength incorrectly.
mChannelOffset should only be changed in response to channel activities such
as NotifyDataStarted() and NotifyDataReceived().
However, if MediaCache::Update() calls CacheClientSeek() without updating
mChannelOffset, next Update() might make a wrong decision and call CacheClientSeek()
again which is bad. So we add a member mSeekTarget to track if there is a pending
seek on which the stream reading decisions will be made.
MozReview-Commit-ID: VWP0vdlEYM
--HG--
extra : rebase_source : ea0d85bcbcc5d14f1554ebff3d10981a5b17e18a
extra : source : 339b9323b583849ac88e39da19670f6b26772877
For it is not safe to access mStreams without the lock off the main thread.
MozReview-Commit-ID: DjVlhxgjVj5
--HG--
extra : rebase_source : b584fe59712430acd4528e6b6cd01ae86dc5761f
extra : source : d7fd550934bfe6967638e42acb076882611792dd
SetTransportSeekable() is always called after NotifyDataStarted().
This is slightly more efficient for we don't acquire the lock twice.
MozReview-Commit-ID: 9myolomriIQ
--HG--
extra : rebase_source : f33c3be978edacf45d8144af43f45c8ad5e7b53e
extra : source : 2cefaeb1adae7238b77d5e2d1287ae0d96d9f671
Capturing |this| only if |self| needs to appear more than twice in a lambda.
MozReview-Commit-ID: 38iYDznjgBH
--HG--
extra : rebase_source : 9471fd4519c5c5be6e6e10eb11db8eeb041327d1
According to FFmpeg documentation, the out parameter is "set to size of parsed buffer or zero if not yet finished. " however this is only the case if no error occurred; otherwise it is left untouched.
We want the invalid content to generate a decoding error, so we set size to inputSize to ensure decoding failed later.
MozReview-Commit-ID: FZeiZUdUtLG
--HG--
extra : rebase_source : 2e81d730bacaea5bb968f704a36b403117dafcba
We queried 'loadingprincipal' attribute on the common call path, however
this should be queried if it's loaded by System Principal.
Also rename loadingprincipal to triggeringprincipal
This also brings in and convert some utilities we have in Gecko, that will ease
porting more tests.
MozReview-Commit-ID: 2yPZQO504kH
--HG--
rename : dom/media/webaudio/test/test_analyserNodeOutput.html => testing/web-platform/tests/webaudio/the-audio-api/the-analysernode-interface/test-analyser-output.html
extra : rebase_source : 0a9c9c336b1b53120010a081da131c76f103a838
The delegate property of NSSpeechSynthesizer doesn't seem to add refcount from 10.13, so we have to keep SpeechDelegate object until speech is finished.
MozReview-Commit-ID: EVtMOPytkjR
--HG--
extra : rebase_source : f2a6d97942c19990a16dd68555328ed36280eb4a
The reverts to accepting ownership of the monitor regardless of the thread, as
accepted prior to
https://hg.mozilla.org/mozilla-central/rev/e3f39de40209#l1.25
As indicated in the SetCurrentDriver() documentation, it can be called on the
main thread during Revive() before another graph thread is started.
At that point mLifecycleState = LIFECYCLE_RUNNING, and so it is not easy to
adjust AssertOnGraphThreadOrNotRunning() to accept this situation without
making it much more liberal.
An alternative would be to change the Revive() methods to set mDriver
directly, but that would differ from the usual driver-switching pattern.
MozReview-Commit-ID: 9O5qakPVML9
--HG--
extra : rebase_source : 82115938ccd164863ddf6f983e7900705844d0ed
For webrtc, the most important part of the code had already been removed in bug 1355048 and could no longer be called
MozReview-Commit-ID: Fx9XI0zR1gn
--HG--
extra : rebase_source : 360996760abab650684440fbeea258b43dccfd83
This was used to support cross-architecture NPAPI plugins on OS X, but
we stopped supporting that in 54 (bug 1339182).
MozReview-Commit-ID: 2BcWYD6mguY
--HG--
extra : rebase_source : 6e509a3cc1f356ccd24f1459c43bc8fb66d7b0f4
