Ok this is kind of a goofy question but I want to make sure I get it right. Suppose we have a 25 mb video, that is 117 seconds long. If we wish for this streaming video to play smoothly with no compression, buffering or skipping, the following bandwidth requirements must be met:
25 megabytes = 204800 kilobits.
204800 kb / 117 seconds ~ 1750kb/s
Does that look right to you?
Sean:
Don't forget that the data speed != line speed. A line will only carry about 70% of the line speed as data because of packet overheads.
Neil
-- Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com Eliminate junk email and reclaim your inbox. Visit http://www.spammilter.com for details.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Sean Carolan Sent: Wednesday, November 05, 2008 3:47 PM To: CentOS mailing list Subject: [CentOS] Check my math please
Ok this is kind of a goofy question but I want to make sure I get it right. Suppose we have a 25 mb video, that is 117 seconds long. If we wish for this streaming video to play smoothly with no compression, buffering or skipping, the following bandwidth requirements must be met:
25 megabytes = 204800 kilobits.
204800 kb / 117 seconds ~ 1750kb/s
Does that look right to you? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Don't forget that the data speed != line speed. A line will only carry about 70% of the line speed as data because of packet overheads.
Thanks for pointing this out. I believe I have enough information to make my case. My guesstimate before seeing the actual file sizes was that this would never work with less than a 2Mb/s connection, turns out I was pretty close!
On Wed, Nov 05, 2008 at 03:59:34PM -0600, Sean Carolan wrote:
Don't forget that the data speed != line speed. A line will only carry about 70% of the line speed as data because of packet overheads.
Thanks for pointing this out. I believe I have enough information to make my case. My guesstimate before seeing the actual file sizes was that this would never work with less than a 2Mb/s connection, turns out I was pretty close!
Also compute the error recovery and lost packet detection and recovery issues in terms of buffering. In general you want a pad and flow control strategy. Some streams do well and others not.....
If you use a reliable stream you will depend on the protocol for error recovery. Reliable data streams may not match your data's data structures and may require larger buffers than an initial back of envelope computation will indicate.
see http://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome
Sean Carolan wrote:
Ok this is kind of a goofy question but I want to make sure I get it right. Suppose we have a 25 mb video, that is 117 seconds long. If we wish for this streaming video to play smoothly with no compression, buffering or skipping, the following bandwidth requirements must be met:
25 megabytes = 204800 kilobits.
204800 kb / 117 seconds ~ 1750kb/s
Does that look right to you?
add 5 or 10% for network protocol overhead. I generally figure, 25Mbyte == 250Mbits, so come up with 2.1 Mbit/sec.
Sean Carolan wrote:
Ok this is kind of a goofy question but I want to make sure I get it right. Suppose we have a 25 mb video, that is 117 seconds long. If we wish for this streaming video to play smoothly with no compression, buffering or skipping, the following bandwidth requirements must be met:
25 megabytes = 204800 kilobits.
204800 kb / 117 seconds ~ 1750kb/s
Does that look right to you? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sean,
The size of the file doesn't make much difference. What matters is the resolution and framerate of the video.
Depending on the resolution and framerate, you probably won't be able to stream realtime without some buffering and/or compression. And don't forget, it isn't just the size of your pipe to the internet, it is also the size of the recipient's pipe, and how many concurrent connections you will have at the same time, assuming you are hosting locally.
Lower framerate and resolution = lower bandwidth required.
HTH,
Monty
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.
on 11-5-2008 2:06 PM Sean Carolan spake the following:
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.
A lot of it is. Some of the tubes are copper, some are glass fiber.
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
Sean Carolan wrote:
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?
You can if you're using some of the fudge factors others have mentioned here. The headers for IP + UDP + RTP take at least 3.5% of the bandwidth for a network using a PMTU of 1500 bytes. If the smallest MTU between your system and the receiver is smaller, the percentage goes up. And, the percentage goes up anyway because those numbers only talk about the minimum overhead. RTP headers are flexible, as are most higher-level protocols, like TCP.
We're also ignoring any other traffic on the link. With RTP, for instance, there are usually RTCP and RTSP channels as well. Without these parallel data channels, the stream doesn't work.
You also have to account for retries and buffering. If your network link is exactly as big as it has to be for the ideal case, you will still have problems because the time it takes to deal with lost or damaged packets comes out of your bit rate budget. There's a limit to the effectiveness of prebuffering.
10% total overhead isn't unreasonable.
-
John R Pierce -
Monty Shinn -
Neil Aggarwal -
Nifty Cluster Mitch -
Scott Silva -
Sean Carolan -
Warren Young