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@xxxxxxxxxx
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
