Time-Shifting and background input

I talked about 13Mbps 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 possiblt to obtain the input over a longer period for a lower bandwidth (it doesnt need to be recorded real-time) the trend is actually to record things at a faster rate that real time (riping a CD, downloading a movie for example.) So lets double the bandwidth requirement at this point

We're at 26Mbps now.

Multiple concurrent inputs will also require multiplying the bandwith. 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 dont 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 13mbps. (i'm not including time-shifting in this equation). This gives us an extra 7.5Mbps.

We're at 33.5Mbps now.

And finally, lets add monitoring. Its a low-bandwidth background activity. Even the video aspect would only require 2Mbps. A few remote cameras feeding into your monitoring equipment wouldnt require much more than that.

So that brings us to 34.5Mbps. Lets call it 35Mbps.

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 25Mbps per person.

Thats it. Assuming that it would be at a cost where it wouldnt affect the choice, 25Mbps per person is all thats required.