|
You have a number of factors. Most importantly are the video and audio bitrates; by summing these, you should be able to approximate the average total bitrate of the stream. For example, I have a 640x480 ASF file. The video in this particular file is 680kbps, and the audio is 160kbps, for a grand total of 840kbps. Thus, to view this video in real time, you'd need a connection speed greater than 840kbps (remember, there will be some overhead in the file format and network packet headers, among other things), unless other steps were taken. One of these steps is buffering; by deferring playback start until you've buffered enough data, you can play the video with low risk of interruption.
If you want to play the video without buffering, or with minimal buffering, you need to know if the video uses compression at a constant or variable bit rate. The idea with constant compression is it's easy to do the math; any given interval has the same amount of space allocated for the stream. However, depending on the material, it may or may not compress well. This means that with CBR compression, you are more likely to see compression artifacts (imaging low-quality JPEGs) in sequences with more dynamic content (more motion and image variety). Variable bit rate compression, on the other hand, allots a higher bit rate to the more dynamic parts of the stream, which generally produces an overall higher quality video. A similar phenomenon exists for audio compression, with VBR recordings giving generally better results.
What's the point of all this, you ask? Well, when using VBR, the bit rate that you see listed for the file is generally a mean (average) bit rate; while it is sometimes below this, it will likewise spike above this at times. Thus, even if you have what seems to be a fast enough connection, it may stutter when the bit rate rises, unless you buffer the data.
As for the math and if it's accurate, let's go back to my video example (it's an actual video on my Archos). 840kbps combined, and the video is 130 seconds long, for a total of 109200 kilobits. Divide by 8 to get kilobytes, and you've got 13650. That's very close to the actual file size of 13428KB, so it seems the math holds. You can divide the file size by its duration to get an average bandwidth requirement, and barring complications such as the CBR vs VBR issue, whether or not the user is willing to dedicate the entirety of their bandwidth to the video stream, and the variable nature of some internet connections (cable internet's variable bandwidth, for example), you can create your table of bandwidth requirements. Also, you should know that media designed for streaming has mechanisms in place to handle such variability; this typically manifests as dropped frames during the playback. If this isn't satisfactory for you, consider allowing the user to download the file in its entirety for local playback.
__________________
A man's knowledge is like an expanding sphere, the surface corresponding to the boundary between the known and the unknown. As the sphere grows, so does its surface; the more a man learns, the more he realizes how much he does not know. Hence, the most ignorant man thinks he knows it all. - L. Sprague de Camp
|