Sean Carolan wrote: >> The size of the file doesn't make much difference. What matters is the >> resolution and framerate of the vide > > For a back-of-the napkin calculation can we not assume that data equal > to the entire size of the file will be streamed to the client during > playback? I understand that frame rate, etc. are important as well > but I do not need exact figures, just a general idea of what size > tube** is required on the viewer's side to see the video without > skipping. > > ** The internet is not really made of tubes. Unless you're from Alaska. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos Yes, you're right. You did define the length of the clip, after all...:> I'm just use to streaming wild, not off of an existing file. That being said, you may want to look at H.264 as a possible compression codec. It looks pretty good. For example, on one of our streamers, we are streaming 640x480 at 24fps, using H.264 compression, and seeing the bandwidth usage fluctuating around 800kb/sec, depending on video content. The compression setting is "best", which means lightest compression. (We use quicktime broadcaster to feed Darwin Streaming Server on a Centos 5.x box.) Sorry I didn't pay more attention to the OP. I must keep my hands off the keyboard... Later, Monty