I talked about 13 Mbps in the last post. Having reviewed that, i’m happy with it.
The things that need to be added to it are the recording of input for later use, multiple concurrent inputs and monitoring.
Time-shifting, unfortunately, requires a doubling of the input if you are to retain quality. Although it might be a possibility to obtain the input over a longer period for a lower bandwidth (it doesn’t need to be recorded real-time) the trend is actually to record things at a faster rate that real time (ripping a CD, downloading a movie for example.) So lets double the bandwidth requirement at this point
We’re at 26 Mbps now.
Multiple concurrent inputs will also require multiplying the bandwidth. Although we could be talking about picture-in-picture and background music (which arguably could be at lower bandwidths) we could also be talking about providing occasional second inputs for other people (although in theory, we’d be borrowing bandwidth from the second person for this activity.) I don’t feel we need to double the requirement for a second concurrent input so i’m going to set it at 50% of a normal input. 50% of 13 Mbps. (i’m not including time-shifting in this equation). This gives us an extra 7.5 Mbps.
We’re at 33.5 Mbps now.
And finally, lets add monitoring. Its a low-bandwidth background activity. Even the video aspect would only require 2 Mbps. A few remote cameras feeding into your monitoring equipment wouldn’t require much more than that.
So that brings us to 34.5 Mbps. Lets call it 35 Mbps.
This is a top-whack figure. In practice i’d argue that through advances in technology and a reduction in the need to time shift (as most broadcast data is going to be available on-demand from suppliers in the future) we are only going to need 25 Mbps per person.
That’s it. Assuming that it would be at a cost where it wouldn’t affect the choice, 25Mbps per person is all that’s required.
