Because we need the parseContent function return "document fragment" or "div" or "pseudo cue div" or "pseudo region div" ...
It's better to use enumerate instead boolean flag.
MozReview-Commit-ID: 5zmwXiYreqS
--HG--
extra : rebase_source : 57706a7fbf36b2c65fa93362dbfbf9a30d2d7418
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
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
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
When shutting down we shut modules down in the order of
[media, gfx, cycleCollector].
At the same time we rely on destructors to clean up resources for MediaStreams
and MediaStreamTracks, but these objects may be held until cycleCollector
shutdown. Gfx resources are not allowed to be released after gfx shutdown, which
is where we this approach hits a wall.
This patch will signal them through the three available listener types to clean
up during media shutdown.
MozReview-Commit-ID: FwsG3ukV29P
--HG--
extra : rebase_source : 554ec29a43b7551b3b5570577b0559285e36d4fd
The return value is unchecked in MediaDecoder, and we only ever returned
NS_OK anyway. And we if the dispatch fails, we can't really do anything;
dispatching an "error" event probably won't work.
MozReview-Commit-ID: 67K6Mjft6tY
--HG--
extra : rebase_source : ad644e8b97fc11488983bc05e18c9941b3c5b062
Evicting the block will result in a gap in the current cached range starting
from mStreamOffset to mChannelOffset. Then we have
|GetCachedDataEndInternal(mStreamOffset) < mChannelOffset| and MediaCache
will open a new channel to fill the gap which is bad.
This is exactly the issue described in bug 1347174 where we limit the readahead
size to prevent the problem above from happening.
However bug 1347174 is indeed a workaround instead of a fix. It works around
the issue by suspending the download before the cache is full and has to evict
some blocks to allow new data to come in.
We should let MediaCache suspend the channel if it is full or evict played
blocks if possible.
MozReview-Commit-ID: HuUsZLdHGuh
--HG--
extra : rebase_source : cdd9bdb5bc63589550bafd49f6e313244037d8dd
extra : intermediate-source : 90aaf942dfbfdff98ef3df412ed49141f3f50e55
extra : source : fc8bc1c456677b92884c80ecfe4d5074a610f81a
Update to upstream commit id e87fb2378f01103d5d6e477a4ef6892dc714e614
from a couple of weeks ago to pick up changes.
MozReview-Commit-ID: H7H69A7qFXD
--HG--
extra : rebase_source : dee676da15b65e4eea612d20529c4fb312bbddfb
Using flag PR_LD_LOCAL causes PR_LoadLibraryWithFlags to fail, and there should be no difference with PR_LD_GLOBAL anyway on Android.
MozReview-Commit-ID: DAduV8yg8Sx
--HG--
extra : rebase_source : 83f28e6b74dcc7d58bf780ad1451153c4c447a0a
The behaviour of the system decoder is unpredictable.
MozReview-Commit-ID: FubvCm0xyiL
--HG--
extra : rebase_source : 4ac49f1c6fc575e361520598de413f7439a05d0e
Android audio backend only supports S16 audio sample, so configure ffmpeg audio decoder to output 16 bits audio by default. Adding format conversions as necessary.
MozReview-Commit-ID: J6N4rbMZ3Ug
--HG--
extra : rebase_source : 7a8a72a7e9cd3dde2c8659d363875c6d5072b6b2
We don't want MediaCache to use a half-initialized stream.
MozReview-Commit-ID: LjPLOYwy0Wd
--HG--
extra : rebase_source : a52a23fc6dce2a87ef2829254dcabe8176b2c28c
extra : intermediate-source : eb9c3d068ff4c3496831d80398012daebe8a5d52
extra : source : d980eb79f7a5219651ef710630cdf6dc3bd96195
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
Note we will fix bugs required to run Update() off the main thread
in the following patches.
MozReview-Commit-ID: CYwT5kDjD9R
--HG--
extra : rebase_source : edef59353b5f56d5aecb6d58f5cc2a8dfb09c317
extra : intermediate-source : 995a34fb6af54d3f4ad2de479d7777860a957f98
extra : source : 8d86a14f877cf83584cf1e57020568037a35154a
mCallback->GetMediaOwner() now is always called before Close() and won't
return null. So is owner->GetMediaElement().
MozReview-Commit-ID: HbxbyuogYAB
--HG--
extra : rebase_source : 28e6ccf104fea9dba9885974f77e19535de84f54
extra : intermediate-source : 15cfa511119ce07e3ede692dc8b14ae177dd388a
extra : source : 9ce161facd920a0efeaf8260ea75f13f1679b24e
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
Using a single-function MozPromise::Then, and capturing a UniquePtr (using
C++14 initialized lambda captures), the PromiseHolder cannot leak anymore.
Also using C++ initialized lambda captures for other variables, to avoid
unnecessary constructions and copies.
MozReview-Commit-ID: DVxyuJNa8YX
--HG--
extra : rebase_source : a7169d616da36597854bf37616228eb72636f2b7
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
We have already early returned by checking nalLenSize == 4. So there is no need to check it again, delete the deadcode.
MozReview-Commit-ID: GEcPGHDslON
--HG--
extra : rebase_source : 78102d946499f5908d7cb20c7bc148cb2fc87821
Set Box::mParent to nullptr as a default value.
MozReview-Commit-ID: E14dPzpFtcd
--HG--
extra : rebase_source : 32999215e789729b54d7ac25d11075a480eb4ae0
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
In AppleCMLinker.cpp, Logging.h and PlatformDecoderModule.h are needed for the LOG macro.
In AppleATDecoder.cpp VideoUtils.h is needed because FramesToTimeUnit() is called in ::DecodeSample().
MozReview-Commit-ID: 2guOwAsYJF1
--HG--
extra : amend_source : e1e98650060f8946361823b5e634d5bf51709a0f
Remove AndroidJNIWrapper. It was primarily used by JNI.jsm and WebRTC.
Usages in WebRTC are replaced with equivalent uses of JNI templates.
MozReview-Commit-ID: DPSeMOtH2wF
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
MediaCache::Update() depends on mStreamOffset to make decision whether to
read streams or not. It is important to update mStreamOffset before releasing
the monitor so Update() won't make wrong decisions based on the stale value.
MozReview-Commit-ID: 40jUk5xd6GR
--HG--
extra : rebase_source : 40f4a64d0b66886b3a12c374f1bda874f8853750
extra : intermediate-source : 20ad1ad39a1e0c128ffd16e3fa669c9db1bb9c98
extra : source : 04f82ee89d93d5c008e51746c9686b4298e5f44f
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
1. Add assertions to functions that shouldn't be called after Close().
2. Early return if closed from Suspend/Resume/Seek which are called asynchronously by the cache.
MozReview-Commit-ID: KZOJer36o77
--HG--
extra : rebase_source : 0c18418062d432a1ff2adbd3226a84cb0e37aa70
extra : source : 3c7dc961721ab975ac6751754d2a8d97e1c4eaff
A FLAC packet may have a size as small as 11 bytes. We should parse as much data as we can and not make assumptions on when to stop early.
MozReview-Commit-ID: 9skvwbt15MY
--HG--
extra : rebase_source : e428ba40fb71a4607af5d3be7f7d61ae98631522
It is unknown if an av_parser is usable after having been drained. So to be certain, we simply tear it down and re-create it.
MozReview-Commit-ID: 6NFMHbRMwxs
--HG--
extra : rebase_source : c31db990ef04ec2586d965b9a08be47532bd87a2
Per FFmpeg documentation: to signal EOF to the av_parser, input length should be 0 (so that the last frame can be output).
MozReview-Commit-ID: F22RcRnT3HS
--HG--
extra : rebase_source : f704e33526347244d38d1ab0b7fa1e5a0cda84cb
The spec [1] defines what's the init segment, and the parser would return error
if the format is not correct.
[1] https://w3c.github.io/media-source/webm-byte-stream-format.html
MozReview-Commit-ID: 3nFHHdn5b89
--HG--
extra : rebase_source : 66fe592958801c4f9e2115f7729df2b9ece55ac3
The spec [1] defines what's the media segment, and the parser would return error
if the format is not correct.
[1] https://w3c.github.io/media-source/webm-byte-stream-format.html
MozReview-Commit-ID: 4hq59Pywz2t
--HG--
extra : rebase_source : 1136d2a673f11d612e0eb711db6affdce42bb525
The spec [1] defines that
"Timecode (e7) MUST appear before Block (a1) or SimpleBlock (a3)".
[1] https://www.matroska.org/technical/specs/index.html
MozReview-Commit-ID: 7g8lgckuNif
--HG--
extra : rebase_source : 4945dc4b0ab4b7480bf9c6416f9776fd6313c1e1
CacheClientSeek() will call Seek() asynchronously and should be used by MediaCache only.
ChannelMediaResource::Resume() runs on the main thread and can call Seek() directly.
Note this is a missing change from bug 1411504 P3.
MozReview-Commit-ID: I2X1Rk5HoDV
--HG--
extra : rebase_source : 66dce75aefc4bfebecf69ebe107e9b4c9286f3a5
extra : source : 20e5463e15049095a941f501acd3fa7dd4e9b1db
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
mManager would be accessed in both main thread and task queue, and be set on task
queue, so we need to make sure it's thread-safe.
MozReview-Commit-ID: m76KeEsDgB
It would only be accessed on task queue now, so we don't need to lock it.
MozReview-Commit-ID: 6jd36TQW4aA
--HG--
extra : rebase_source : e8bb53a226154312496149ab8f6b00dead49a3b6
Now DecoderTraits doesn't need to depend on ChannelMediaDecoder.
MozReview-Commit-ID: D4AUiV2eGWy
--HG--
extra : rebase_source : 38e6c4cdd0f7e32473c6945550bca6fd0cc72bf2
CreateDecoder is the only caller of InstantiateDecoder, and all CreateDecoder
does is call InstantiateDecoder.
MozReview-Commit-ID: KwwL2el8L4x
--HG--
extra : rebase_source : bff225558fd2de535c2cb010eb35b95c6d9469e5
Replace with conditional compilation enabled for Linux targets.
MozReview-Commit-ID: GjD0Ix8aeJW
--HG--
extra : rebase_source : 18dd93eda0a9ebc1846a876caa4f5d27d8b75909
Adding partial support for 10/12-bit video images seems to have
broken the native pixel-stride support we were using to pass
8-bit AV1 frame data formatted in 16-bit pixel values, resulting
in vertical green lines.
Revert to the earlier behaviour of always downsampling to 8 bit data.
This is slower for the demo stream, but at least displays correctly.
MozReview-Commit-ID: 8kSd9kph9DE
--HG--
extra : rebase_source : 040795b4d99a2001397c0021f34d39535aa4aa2d
The value by which we pre-roll is inconsequential, so long as we seek to the previous packet than the one we want. So 80ms will do.
MozReview-Commit-ID: 8iPOtjReZnb
--HG--
extra : rebase_source : 42908c6afc84cf783356fb7311ffe99b4ec76d96
mTaskQueue is only read on the main thread, but read and written on the demuxer's taskqueue. We need to ensure that accesses are synchronised.
MozReview-Commit-ID: Gbc15iYgZOe
--HG--
extra : rebase_source : 006ff3f73c9895fa2f29e56123e690cdf66fe2c5
Removed non-eager DDLogValue() functions, too confusing for not much value;
users should use macros first anyway.
Changed `EagerLogValue(..., const char (&aLiteral)[N])` to take `const char*`,
it's cleaner and simpler.
MozReview-Commit-ID: J7xcoPkp6Nf
--HG--
extra : rebase_source : 41040c98b89c3035c823a4a9775e727038c07590
The use of the TrackBuffersManager once detached is explictly forbidden, as such
OnTaskQueue() can only be used before the DetachTask ran: we now strongly assert
as such.
MozReview-Commit-ID: ycOI4QRElb
--HG--
extra : rebase_source : ecce8ac75587470c15268ab729b068f049702a8a
Ensure the TBM would always be detached from demuxers, before calling
TBM::detach().
MozReview-Commit-ID: DLWZHB3M3GG
--HG--
extra : rebase_source : 9e455022ba9360fb549222e9ad1238a3ae9d88ad
From [1], the task was executed after finished detach task. It would be caused
by queuing two detach tasks in the task queue.
If the previous detach task is still waiting in the task queue when we're calling
the second detach(), then we might have two detach tasks in the queue.
[1] https://treeherder.mozilla.org/logviewer.html#?job_id=134315866&repo=try&lineNumber=2540
MozReview-Commit-ID: HohgKqeZy0s
--HG--
extra : rebase_source : 0d20f1b8648acaf2ed8e75b2631e905629c2abaf
Should never access the TrackBuffersManager once the SourceBuffer has been detached.
MozReview-Commit-ID: EgVINj9B1vZ
--HG--
extra : rebase_source : 4b4dc3e5c4b507fe4cc40e80f507b575a8b87eb3
After detaching TBM, we should not access it anymore. So we should finish all
other related detaching process, before detaching TBM.
MozReview-Commit-ID: 8bNzqXVHVyy
--HG--
extra : rebase_source : e135eb3d0fd4e5c41bbac4ebfc8d6fcbd1b32d5b
bechen@mozilla.com
Noemi Erli
Margareta Eliza Balazs
JW Wang
James Cheng
Andreas Pehrson
Sebastian Hengst
Andrea Marchesini
Narcis Beleuzu
Ryan VanderMeulen
Jesse Ruderman
Kilik Kuo
Karl Tomlinson
Alfredo.Yang
Alastor Wu
Chris Pearce
Jean-Yves Avenard
Csoregi Natalia
JerryShih
Bob Clary
Jon Coppeard
Michael Froman
Andreas Pehrson
Nico Grunbaum
Ralph Giles
Nika Layzell
Munro Mengjue Chiang
Alex Chronopoulos
Gerald Squelart
Coroiu Cristina
Philippe Normand
Jim Chen
Joel Maher
Attila Craciun
Bevis Tseng
Bryce Van Dyk
Nathan Froyd
Nils Ohlmeier [:drno]
Yoshi Huang
Paul Adenot
Makoto Kato
Jed Davis
Masatoshi Kimura
Tyson Smith
Matthew Gregan
Dan Glastonbury
Alex Gaynor
Phil Ringnalda
Randell Jesup
Boris Zbarsky
Dan Minor
Ethan Lin
Kris Maglione
Dan Banner
Chung-Sheng Fu
Tom Ritter