This isn't right, and it means that we can't assume at the top of
On{Audio,Video}{,Not}Decoded() that we're fresh out of promise dispatch, which
we want to do.
The duplication of the IsSeeking() checks before all the Request{Audio,Video}Data
callsites is ugly. We'll fix this in the next patch by applying the same disconnect
treatment to the seek promise.
This isn't right, and it means that we can't assume at the top of
On{Audio,Video}{,Not}Decoded() that we're fresh out of promise dispatch, which
we want to do.
YouTube will call endOfStream once the video has been entirely buffered.
When changing video quality, it will clear the entire source buffer,
following which it will append data once again which will reopen
the mediasource.
We don't want to consider a mediasource in ended state as not ever going to
receive more data in the future unless we're actually reached the end.
The MDSM really shouldn't be issuing these. The correct solution (which I'll
file a followup bug for) is to fix the MDSM to not do that. But rejecting the
promise with CANCELED is a lot safer, so we do that for now.
The comments indicate that they're supposed to be used for setting mDiscontinuity
on the samples, but that never actually happens (and appears to happen in
MP4Reader.cpp). Resetting them in Request{Audio,Video}Data doesn't make any sense
at all. So we repurpose them to track our seek stage.
mWaitingForSeekData is modified in NotifyTimeRangesChanged, which is
invoked on the main thread. One would hope that all of these other members
are only touched on the decode task queue.
Fixes a bug in the SourceBufferResource eviction code where it was
using the mOffset of the resource as the min bound for what to evict.
This offset is almost always zero though due to ReadFromCache being
used which never updates the offset. This prevented eviction from
happening in most cases.
Moves the code to remove old decoders so that it does this during
the same loop as that which remove data from existing decoders.
This more aggressively prunes old decoders and is more likely to
keep data in the current playing decoder around for seeking, etc.
Prevent removing any decoder that the MediaSourceReader is
currently using for playback to prevent RemoveDecoder crashes.
Add a threshold to subtract from the current time when working out
the time bound to evict before to make it less likely to evict
current data that is needed for current playback.
Remove all data from evicted decoders in the initial iteration then
iterate after to remove empty decoders to put the RemoveDecoder
logic in one place.
Iterate decoders in order that they were added rather than sorted
by time so the logic that removes entire decoders can do it only
to those old decoders that existed before the existing one was
created.
Keeps track of the time that was evicted from the current decoder
and uses that as the time to EvictBefore for all decoders in the
track buffer when doing MediaSource::NotifyEvict.
There isn't actually any initialization code that sets them at 0. Instead, we
currently rely on the fact that our first decoder ends up active regardless of
what its buffered range reports. So as long as invoking the first Request{Audio,Video}Data
is resolved, this ends up ok. But while that is usually the case, it isn't _always_
the case, especially in the case where the MP4Reader rejects with WAITING_FOR_DATA.
