Missing buffered attribute for <video>/<audio>

Missing buffered attribute for <video>/<audio>

BUG=16056
TEST=LayoutTests/media/video-buffered.html

The current implementation of the buffered attribute for <video> and <audio>
is broken. There are several problems around this attribute:

1. We don't have any caching on disk, so we only keep a recent range of bytes
   close to current playback position.
2. WebKit reports buffered as one range (0, max_time_buffered). But we only
   cache a short partial range which doesn't start with 0. The correct
   implementation is a list of ranges buffered. But this has to go into WebKit
   first.
3. We don't have an accurate mapping between byte offset < - > timestamp.

So the current implementation is to lie about what we have buffered. We always
say we have buffered everything before the current download position. And we
only report one range. The calculation of time is also based on scaling the
duration with current buffered bytes.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=22087

[scherkus (not reviewing), 2009-07-29 18:04:46]

unit test!

you can follow a similar pattern as the SetDuration helper (sync to tip of tree
and look at pipeline_impl_unittest.cc and bottom of mock_filters.h)

http://codereview.chromium.org/160300/diff/1002/1003
File media/base/pipeline_impl.cc (right):

http://codereview.chromium.org/160300/diff/1002/1003#newcode224
Line 224: return base::TimeDelta::FromMilliseconds(duration_.InMilliseconds() *
do we have to worry about integer division here?

should we convert to float then back to milliseconds?

[Alpha Left Google, 2009-07-30 01:45:07]

http://codereview.chromium.org/160300/diff/1002/1003
File media/base/pipeline_impl.cc (right):

http://codereview.chromium.org/160300/diff/1002/1003#newcode224
Line 224: return base::TimeDelta::FromMilliseconds(duration_.InMilliseconds() *
On 2009/07/29 18:04:46, scherkus wrote:
> do we have to worry about integer division here?
> 
> should we convert to float then back to milliseconds?

I think double would work better because size can easily be bigger than 32 bits.

[scherkus (not reviewing), 2009-07-30 01:50:52]

LGTM