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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: cajbir, Assigned: cajbir)
References
Details
Attachments
(1 file)
(deleted),
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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 | ||
Comment 1•16 years ago
|
||
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)
Updated•16 years ago
|
Attachment #345529 -
Flags: superreview?(bzbarsky)
Attachment #345529 -
Flags: superreview+
Attachment #345529 -
Flags: review?(bzbarsky)
Attachment #345529 -
Flags: review+
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
> 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.
Assignee | ||
Comment 5•16 years ago
|
||
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 6•16 years ago
|
||
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?
Comment 7•16 years ago
|
||
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 :|
Comment 8•16 years ago
|
||
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
Updated•16 years ago
|
Status: REOPENED → NEW
Comment 10•16 years ago
|
||
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.
Comment 11•16 years ago
|
||
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 12•16 years ago
|
||
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)
Comment 13•16 years ago
|
||
Uff, sorry for that.
Assignee | ||
Comment 14•16 years ago
|
||
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.
Comment 15•15 years ago
|
||
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).
Assignee | ||
Comment 16•15 years ago
|
||
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.
Comment 17•15 years ago
|
||
So, shouldn't component of this bug be changed accordingly?
Assignee | ||
Comment 18•15 years ago
|
||
This bug should be closed since it's fixed, and a new bug raised for the byte request/cache issue.
Comment 19•15 years ago
|
||
(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 ago → 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•