Bug 1244639: P1. Don't assume MP3 decoding always starts at 0. r=cpearce

This remove the MP3 workaround for the mac decoder that was added in bug 1194080.
This commit is contained in:
Jean-Yves Avenard 2016-02-03 11:44:17 +11:00
parent 23b3423e06
commit 5ed283f651
2 changed files with 6 additions and 9 deletions

View File

@ -28,11 +28,6 @@ public:
bool IsSeekable() const override;
void NotifyDataArrived() override;
void NotifyDataRemoved() override;
// Do not shift the calculated buffered range by the start time of the first
// decoded frame. The mac MP3 decoder will buffer some samples and the first
// frame returned has typically a start time that is non-zero, causing our
// buffered range to have a negative start time.
bool ShouldComputeStartTime() const override { return false; }
private:
// Synchronous initialization.

View File

@ -1571,15 +1571,12 @@ MediaFormatReader::GetBuffered()
if (!mInitDone) {
return intervals;
}
int64_t startTime;
int64_t startTime = 0;
if (!ForceZeroStartTime()) {
if (!HaveStartTime()) {
return intervals;
}
startTime = StartTime();
} else {
// MSE, start time is assumed to be 0 we can proceeed with what we have.
startTime = 0;
}
// Ensure we have up to date buffered time range.
if (HasVideo()) {
@ -1602,6 +1599,11 @@ MediaFormatReader::GetBuffered()
intervals = Move(videoti);
}
if (!intervals.Length() ||
intervals.GetStart() == media::TimeUnit::FromMicroseconds(0)) {
// IntervalSet already starts at 0 or is empty, nothing to shift.
return intervals;
}
return intervals.Shift(media::TimeUnit::FromMicroseconds(-startTime));
}