567085 - Media cache should preload more eagerly (esp. in full screen)

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Henri Sivonen (:hsivonen)]

Build id: 32-bit Mac nightly around 11th of May.

Reproducible: Didn't try.

Steps to reproduce:
 1) Start loading http://videos.mozilla.org/serv/air_mozilla/firefox4.ogg on a reasonably performant Mac using a reasonable connection. I used a 2009 Mac Mini with 4 GB of RAM and a 10/10M connection.
 2) Take the video to full screen from the context menu.
 3) Play the video.

Actual results:
The video played fine for about 22 minutes. Thereafter, it played ahead less than a second, stopped, played ahead less than a second, stopped, etc. The controller indicated that the video hadn't been fully loaded, but the current time didn't reach the end of the available buffer indicator--not even close. Had to stop watching. Downloaded the video in less than 10 minutes and continued watching using a standalone player.

Expected results:
Since it was possible to download the video in less than 10 minutes, expected the video to be fully downloaded and buffered 22 minutes in. When the computer has enough *RAM* to buffer the whole thing (and disk, too), expected the media cache to eagerly preload the whole video when the user's intention clearly is to watch the video. (If pressing play isn't enough, surely going to full screen is intentional enough.)

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Blizzard saw this bug too.

For the WebM builds we worked around it by bumping the size of the media cache to 500MB. We should probably do something like that on trunk too (except that Blizzard noticed our FILE_DELETE_ON_CLOSE cache files are not, in fact, deleted when we crash :-( ).

But yes, there is also some other kind of bug here, probably two, since a) the media cache shouldn't be closing and reopening HTTP connections constantly and b) the media cache should keep reading way ahead of the playback position, so even if it's closing and opening connections that shouldn't affect playback.

Comment 2

[Christopher Blizzard (:blizzard)]

The sizes seem to indicate to me that once we fill up the media cache and stop reading from the server we play until we get to that point.  Then once we need to go and get more data, we always get it on small chunks.  The 500MB limit will hide the problem for a few days, but I'll bet once you get to 500MB the same problem will appear.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #2)
> The sizes seem to indicate to me that once we fill up the media cache and stop
> reading from the server we play until we get to that point.

OK, that's simply a media cache bug. We should restart reading long before playback reaches that point. I'll look into it.

Comment 4

[Justin Dolske [:Dolske]]

(In reply to comment #0)

> When the computer
> has enough *RAM* to buffer the whole thing (and disk, too), expected the media
> cache to eagerly preload the whole video when the user's intention clearly is
> to watch the video. (If pressing play isn't enough, surely going to full screen
> is intentional enough.)

I think the immediate bug-at-hand is that the media cache is broken (comment 1), but if you really want this behavior it should be spun off to a separate bug. I don't think we'd want to buffer to ram (people already watch memory size more than they should), and we should be very careful about downloading large media files too aggressively... But it's seems like an interesting idea to have the amount of pre-cached data scale with, say, the length of time you've been watching the video.

Comment 5

[Daniel C]

(In reply to comment #1)
> Blizzard noticed our FILE_DELETE_ON_CLOSE cache files are not, in fact, deleted
> when we crash :-( ).

Bug number?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Filed bug 572579

Comment 7

[Damon Sicore (:damons)]

ttp://bit.ly/cQ4sSL

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

The main problem in my tests is that the estimated playback rate is not being set correctly; in fact, it's stuck at its default/minimum of 10000 bytes per second, which is about 1/12 of the true value for the test video I'm looking at (http://tinyvid.tv/file/2kekxr73akx2t.ogg). This means that the media cache thinks that the data we've buffered ahead represents a lot more playback time than it really does, so the media cache only decides to start fetching more data just before we run out, and that's often too late.

This patch adds missing calls to UpdatePlaybackRate so it gets called whenever the duration changes.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

This has needed landing since late June. Bumping to beta3+, but we should really get it in the day after we freeze for beta2.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It actually just landed.

http://hg.mozilla.org/mozilla-central/rev/e176352bdcd0