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@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@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