Look at any of the posts proposing a solution and you'll notice that they describe (or assume) a 3 step process: Capture the video, encode/compress the video, store the encoded video.
This is not a new problem. In fact, the problem has been around since before TV. Consider a parallel 3 part system:
1) gather information
2) convert the information to a more convienent/succint data format (this would also strip out miscellaneous info.)
3) store this data.
This describes the problems of inventoring, chronicling, and surveying people.
Once we have described the necessary system, we must apply constraints. You have already defined the first 2 parts of the system . . . or have you?
Consider that the 90MB that you want to store each second as the information that you are gathering (not the video) as the input to the system. That is the real system you are looking for. The first constraint is how will the system gather the information (or in what ways can you provide the 90MB/s?)
Fiber optic cable?
Printed on paper at high resoultion?
Tapped out like Morse code?
The second constraint is how acccurate must the data be when it comes back out of the system. Since you've already compressed the data and many compression algorithms cannot deal with even one bit of inaccurate data, we'll assume that the data is as succint as possible and nothing can be removed. That will garuntee that this part of the system has a 1 to 1 mapping and therefore the system is invertible (it can be undone.) However, this does not mean the data cannot be converted to a more convient format.
There are a couple constraints on the final storage. There is a maximum amount of space it can consume per amount of data and whatever the storage element is made of must be in great supply. (The ideal storage element would take up zero space and be in infinite supply, and you aren't gonna find that . . . at least not on a limited budget.)
So let's say we were provided with definite values for all these constraints. All you would need to do is design a conversion mechanism, with the input being the 90MB/s stream of data, that perhaps applys some transform to the data and then impresses the transformed data upon the storage element. If you can design all that within your given budget, congratulations!
If not then there is one final solution: shutdown all the TV networks, movie studios, and security companies. Then go around and destory every camera, burn every videotape, smash every DVD and delete all that porn lying around on your computer. No more video means no more video to archive:o)
Slashdot Mirror
It's a fantastic book, and would probably serve as a useful guide. Introduces a lot of common administrative items.
Look at any of the posts proposing a solution and you'll notice that they describe (or assume) a 3 step process: Capture the video, encode/compress the video, store the encoded video.
:o)
This is not a new problem. In fact, the problem has been around since before TV. Consider a parallel 3 part system:
1) gather information
2) convert the information to a more convienent/succint data format (this would also strip out miscellaneous info.)
3) store this data.
This describes the problems of inventoring, chronicling, and surveying people.
Once we have described the necessary system, we must apply constraints. You have already defined the first 2 parts of the system . . . or have you?
Consider that the 90MB that you want to store each second as the information that you are gathering (not the video) as the input to the system. That is the real system you are looking for. The first constraint is how will the system gather the information (or in what ways can you provide the 90MB/s?)
Fiber optic cable?
Printed on paper at high resoultion?
Tapped out like Morse code?
The second constraint is how acccurate must the data be when it comes back out of the system. Since you've already compressed the data and many compression algorithms cannot deal with even one bit of inaccurate data, we'll assume that the data is as succint as possible and nothing can be removed. That will garuntee that this part of the system has a 1 to 1 mapping and therefore the system is invertible (it can be undone.) However, this does not mean the data cannot be converted to a more convient format.
There are a couple constraints on the final storage. There is a maximum amount of space it can consume per amount of data and whatever the storage element is made of must be in great supply. (The ideal storage element would take up zero space and be in infinite supply, and you aren't gonna find that . . . at least not on a limited budget.)
So let's say we were provided with definite values for all these constraints. All you would need to do is design a conversion mechanism, with the input being the 90MB/s stream of data, that perhaps applys some transform to the data and then impresses the transformed data upon the storage element. If you can design all that within your given budget, congratulations!
If not then there is one final solution: shutdown all the TV networks, movie studios, and security companies. Then go around and destory every camera, burn every videotape, smash every DVD and delete all that porn lying around on your computer. No more video means no more video to archive