Closed Bug 462378 Opened 16 years ago Closed 15 years ago

Video/Audio playback should download the resource to the cache

Categories

(Core :: Audio/Video, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cajbir, Assigned: cajbir)

References

Details

Attachments

(1 file)

When a <video> or <audio> is being downloading during playback it is not stored in the cache. Subsequent playback re-downloads the resource. 

The download should be stored in the cache, and read from there when re-played. Ideally seeking, buffering ranges, etc could make use of the cached file as well.
Assignee: nobody → chris.double
Status: NEW → ASSIGNED
Attachment #345529 - Flags: superreview?(roc)
Attachment #345529 - Flags: review?(roc)
Comment on attachment 345529 [details] [diff] [review]
Set flag to cache as file (checked in)

Boris is really the right reviewer here.
Attachment #345529 - Flags: superreview?(roc)
Attachment #345529 - Flags: superreview?(bzbarsky)
Attachment #345529 - Flags: review?(roc)
Attachment #345529 - Flags: review?(bzbarsky)
Attachment #345529 - Flags: superreview?(bzbarsky)
Attachment #345529 - Flags: superreview+
Attachment #345529 - Flags: review?(bzbarsky)
Attachment #345529 - Flags: review+
Comment on attachment 345529 [details] [diff] [review]
Set flag to cache as file (checked in)

Looks ok, though I don't think you need to do the fromCache check.

Also not that SetCacheAsFile can fail, in which case you're not going to get cached as a file.
> Also not that SetCacheAsFile can fail, in which case you're not going to get
> cached as a file.

Caching as a file is really only an optimisation at this stage so it's not a problem if it doesn't actually cache. Later on, in a future bug, we'd like to use the file to improve seeking performance, so I'll revisit the error checking then.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Hmm, I wonder if this might have some undesirable side effects... Video files tend to be large, so does this make it likely that viewing a video will evict large swaths of whatever's currently cached?
I'm not sure if anyone is still watching this, but 3.5b4 as shipped on Fedora still exhibits this behaviour.  Visiting http://macslow.net/ and refreshing re-downloads them, consuming my precious bandwidth. 

I filed a bug there with Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=507353

Should I open a new one here?  I actually cannot afford the bandwidth this month to download a recent snapshot from Firefox to test this, and will probably end up paying overages already :|
Could somebody reopen this, please? I can perfectly reproduce with Mozilla binary from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-firefox-3.5.x/ and http://macslow.net/?p=320
Reopened.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
For <http://en.design-noir.de/mozilla/fullscreen-video/>, I'm opening the video in a new window and tried to carry over the currentTime, expecting that the already-downloaded material would be available immediately. This didn't seem to work.
Steps to reproduce:

1) Go to site with a lot of <video> elements (that macslow page is a good one)
2) Run any video on the page
3) Reload the page
3) Run the same video again

Looking at the network monitoring applet on your system, you can see that substantial amount of download (approximately same in both cases) happens whenever you run the video.
Comment on attachment 345529 [details] [diff] [review]
Set flag to cache as file (checked in)

Martin: Going from REOPENED to NEW is wrong in this case. It makes it look like the reviewed patch just needs to land.
Attachment #345529 - Attachment description: Set flag to cache as file → Set flag to cache as file (checked in)
Uff, sorry for that.
On initial play the video is in the cache. On the second play we do a byte range request to find the duration of the video. Our network stack doesn't cache or use the cache for byte range requests. This is the network traffic you are seeing. We then seek back to the first frame, which is also a byte range request, and thus doesn't use the cache.

The server can send an X-Content-Duration header with the video that tells us the duration. If it does this we don't do that initial seek and byte range requests to get the duration and can cache the file.

You can see that this caching works by visiting a site that supports X-Content-Duration. For example, this video:

http://tinyvid.tv/show/1kn0rtfbcf5m

Let it load/play all the way through. Close the browser. Open it again and view that page. You'll see it is cached.
Yeah, but wasn't one of the selling points of <video> elements its simplicity ... “just the file somewhere on standard http server, put this element to your page and everything works". Now you do, and without fixing your http server (which is quite often out of your contorl) you make a lot of people quite unhappy (I guess, you as kiwi, could appreciate our downstream reporter).
I'm not saying it's not a problem - I'm explaining what's causing what you see. I think it should be filed under a different bug (if it isn't already) that the network stack doesn't cache byte range requests. When that's fixed, this problem goes away.
So, shouldn't component of this bug be changed accordingly?
This bug should be closed since it's fixed, and a new bug raised for the byte request/cache issue.
(In reply to comment #18)
> This bug should be closed since it's fixed, and a new bug raised for the byte
> request/cache issue.

Does bug 476371 cover that? Otherwise, could you please file that bug with the right technical details?
Status: NEW → RESOLVED
Closed: 16 years ago15 years ago
Resolution: --- → FIXED
Blocks: 499255
You need to log in before you can comment on or make changes to this bug.