1096790 - Optimize MSE reader switching logic to account for duration estimate and fuzz factor

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P5)

Description

[cajbir (:cajbir)]

Spun from bug 1089937 comment 18.

"It feels to me that the fuzz should be used as an acceptable tolerance, but
SelectReader() should prefer something closer to the expected, if available,
so as to avoid possibly skipping over available frames.  This can be a
separate bug if you like. 

I also suspect the fuzz should be applied in SelectReader() or other
SelectReader() callers will have similar problems.  It might be necessary now
however to find the closest available if applying the fuzz in SelectReader()."

Need to look at all usage of MediaSourceReader::SelectReader and apply the selection logic so it takes into account of the time fuzz factor introduced in bug 1089937.

Comment 1

[Karl Tomlinson (:karlt)]

There are 3 situations where SelectReader() is used, and it seems we may want different approaches for at least some of the different situations.

* On EOS

If the current reader has not played up to the beginning of the range for the
nearest next reader, then we can accept a gap up to some tolerance.

If the current reader has played up to the beginning of the range for the next
reader, but the current reader's buffered range says that the ranges overlap,
then there is the issue that selecting the reader for a target matching the
end of the last decoded interval may select the reader that has reached EOS.
Advancing the target to the end the current reader's range, past the start of
the range of the next reader, was the approach used to avoid this problem in
bug 1089937.  Perhaps another possible approach might be to use lower bounds
for the end times of buffered ranges, when selecting a reader on EOS.

If the current reader has played past the beginning of the range for the next
reader, and there is considerable overlap in the ranges of the readers, then
perhaps we need to seek into the next reader.

* On seeking.

If we are not sure whether one reader will provide data for a target time
(because of uncertainty in the end time) then perhaps we can just advance to
the next reader, if there is one close enough, or otherwise fail seek or
report end of stream, as appropriate.  That might be the easiest approach, and
is similar to the EOS case.

Alternatively, if we want to be more accurate, we could try the reader with
the earlier range and follow a process like that of EOS above to move to the
next reader only if the first reader fails to seek. 

* In RequestAudioData().

If we have a current reader, then we don't want to jump a gap to the next
reader as in the EOS case, unless it is EOS, and I assume we can let the EOS
code handle that.

If there is more recent data in another reader for the range of the current
reader, or "better" data, then we'd like to switch readers.  I don't know
whether better or more recent is more important, or specified.  We may need to
seek into the next reader, if ranges overlap.

Comment 2

[Jean-Yves Avenard [:jya]]

This has been fixed by bug 1127203 and bug 1125776