On 03/07/2012 04:10 PM, Robert O'Callahan wrote:
On Wed, Mar 7, 2012 at 1:55 PM, Ashwin Rao
<[email protected] <mailto:[email protected]>> wrote:
> Our media cache already calls suspend/resume "as needed" to throttle
> downloading when the cache fills up. It is a blunt hammer :-).
>
The media cache size is 500MB. If your video is smaller than that,
you won't see any throttling.
Try setting media.cache_size to say 50MB, preload a 200MB video,
you should see downloading pause after approximately 50MB has been
loaded. Then start playing, and eventually you should see
downloading resume; the download will pause and resume to keep a
window of data ahead of the play point.
(I wouldn't call this "rate throttling", since it's not explicitly
based on rate.)
Necko internally would be doing rate throttling using the same
suspend/resume mechanism--that's all TCP gives us. So it's not so much
a less-blunt hammer than one that we can swing more quickly (i.e the
socket transport thread can keep track of the bandwidth coming in and
throttle it w/o the overhead/noise of thread events being sent back and
forth to the main thread from the video cache). I'm not sure how much
difference that makes in practice, though--there's a good chance it'd be
smoother . AFAICT this avoidance of event latency, plus a better sense
of "bottleneck bandwidth" are the only 2 advantages of doing this in
necko. That might be reason enough, or it might make sense to do a
1st version of this using suspend/resume from the media cache with a
<500MB buffer.
> Patrick wrote:
>
> The problem isn't the buffered video but the IP level buffering that
happens on big tcp downloads... that's why I filed it against
networking first
I don't follow--the OS buffers for a TCP socket are much smaller than
the media cache's buffer. Or are you talking about clogging router
buffers? I still don't see how necko doing the suspend/resume vs the
media cache makes a difference here.
Jason
A work by Don Towsley suggests that the rate of up to 2 times the
median encoding rate is sufficient for smooth playback [
http://dl.acm.org/citation.cfm?id=1027735 ]. About the buffering I did
some measurements on YouTube where I observed that YouTube begins a
streaming session (for Flash videos) by buffering 40 seconds of
playback data before limiting the download rate to 1.25 times the
video encoding rate. The details of the results are available at [
http://hal.inria.fr/inria-00638063/en/ ].
Either of those could be implemented in Gecko pretty easily I guess,
although as I said before, I'm not sure pausing and resuming the Necko
download is adequate to hit a smooth target rate.
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
