Re: Ratelimiting video to avoid buffer bloat

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.