4 Commits

Author	SHA1	Message	Date
trav90	4b50ae13c8	Release internal drain monitor before calling Flush() ... The DrainComplete() caught with mWaitForInternalDrain still won't necessarily be from the internal Drain(), but all we need is that one DrainComplete() is caught for the internal Drain() because one more will be generated if there is a Drain() in progress. What protecting mWaitForInternalDrain access with the monitor provides here is that the compiler won't use its address for storage of other data meaningless in the context of mWaitForInternalDrain and so, for example, two DrainComplete() calls won't unintentionally think that they are both for one internal drain.	2018-07-25 06:52:39 +08:00
trav90	fc907f06c6	Always read SDM::mWaitForInternalDrain while holding monitor	2018-07-25 06:52:36 +08:00
trav90	870eefecb1	Don't wait for a drain complete that will never happen ... This prevents a deadlock that is due to the HTMLMediaElement calling MediaDecoder::NotifyOwnerActivityChanged() , attempt to grab the monitor, which is held by the SharedDecoderManager which is waiting for SetIdle() to complete.	2018-07-25 06:52:35 +08:00
trav90	538539f5c3	Move PlatformDecoderModule outside fmp4	2018-07-25 01:29:11 +08:00