We believe the rate is constrained by the audio driver in practice,
but want to verify this assumption. The valid range 8-192 kHz covers
all sample rates in general use for audio data.
Note we must use an error return instead of an assertion since these
bounds are verified by unit tests, which do not catch MOZ_ASSERT().
Also, in order to prevent the MediaDecoderStateMachine to stall waiting for audio data,
feed back as many decoded audio frame as were first submitted to the decoder in one go.
Reopens the MediaSource when SourceBuffer::Remove is called on an Ended
MediaSource.
Only run the Range Removal algorithm when MediaSource duration is changed
instead of calling Remove on SourceBuffers.
Updates tests for the fact that update{start,end} can now be called
more than once due to DurationChange.
--HG--
extra : rebase_source : efe01de2f7c6be09b29e2e19d69d9943c9ab5e52
We believe the rate is constrained by the audio driver, but we
should verify this assumption. 8-192 kHz covers all sample rates
in general use for audio data.
Duplicating state is never great, but this lets the reader make calculations
using this immutable state variable without involving the state machine. We
could alternatively punch a hole from MediaDecoderReader to
MediaDecoderStateMachine and access it there, but that would create tighter
coupling, and weird relationships for MSE.
Reopens the MediaSource when SourceBuffer::Remove is called on an Ended
MediaSource. Only run the Range Removal algorithm when MediaSource
duration is changed instead of calling Remove on SourceBuffers.
Updates tests for the fact that update{start,end} can now be called more than once due to DurationChange.
2014-11-12 15:53:43 +13:00
Chris Double ext:(%20with%20tweaks%20by%20Karl%20Tomlinson%20%3Ckarlt%2B%40karlt.net%3E)
mLast{Audio,Video}Time differs from the actual end time because of
Bug 1065207 - the duration of a WebM fragment is an estimate not the
actual duration. In the case of audio time an example of where they
differ would be the actual sample duration being small but the
previous sample being large. The buffered end time uses that last
sample duration as an estimate of the end time duration giving an end
time that is greater than mLastAudioTime, which is the actual sample
end time.
Reader switching is based on the buffered end time though so we can't use
the actual sample end time for switching comparison.
For this reason we use the end time from the buffers to compare if we
should switch readers in this patch. We also add an EOS_FUZZ_US to allow
for the fact that it is an estimate and can differ slightly from actual times.
--HG--
extra : rebase_source : 47149609119c5dcd1ca7374501dd7c1e285469ef
