scm007

Looking for a chart of video resolution/encoding in relation to bandwidth. I.e.

.wmv 640x480 --- 1 mb/s

etc.

DaWei

Your question is essentially meaningless. The resolution and length of the material will affect the size of the file, but there's nothing that says you can't transfer it at 1 byte per hour if you have enough time on your hands.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

scm007

What I meant is... when played at normal viewing speed, what is the bandwidth requirement. I thought that was obvious..

DaWei

If it were obvious, I'd just have multiplied the resolution by the number of bytes per pixel by the frame rate.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

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.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick