Comments on: DVDinosaur http://blog.germuska.com/2004/08/26/dvdinosaur/ "Hey, I'm just happy to be here..." Sun, 08 Nov 2009 11:11:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Joe http://blog.germuska.com/2004/08/26/dvdinosaur/comment-page-1/#comment-111 Joe Fri, 27 Aug 2004 23:27:15 +0000 http://www.akwaabasound.com/golb/?p=407#comment-111 <p>Right, but internet over cable is generally faster than 100 K per sec. Of course, cable TV itself has even more bandwidth, but it would probably be cost-prohibitive to re-purpose the current cable infrastructure to change the balance between data and video throughput. Still, with a model like this, you could probably reclaim several marginally popular channels and use the bandwidth to service on-demand content. The same content would be available, it just wouldn't be broadcast. Kind of like the savings the city of Chicago tried to realize when it turned off all the free-flowing water fountains. Of course, <a href="http://abclocal.go.com/wls/news/080204_ns_waterfaucets.html" rel="nofollow">they had to turn them back on</a> because the water tasted so bad. </p><p> Heck, Cuban (or people like him) could just send a fresh rack of hard drives to your local cable operator every month with new content. When you get down to the head-end level, I'm sure you could calibrate a balance between "broadcasting" that which is most popular locally (instead of sending a huge number of simultaneous unicast streams) and then supporting nearly on-demand service for the other stuff. A PVR in your home that was a natural extension of the cable system could manage all this for you, sequencing back together those 18 GB while you sleep.</p> Right, but internet over cable is generally faster than 100 K per sec. Of course, cable TV itself has even more bandwidth, but it would probably be cost-prohibitive to re-purpose the current cable infrastructure to change the balance between data and video throughput. Still, with a model like this, you could probably reclaim several marginally popular channels and use the bandwidth to service on-demand content. The same content would be available, it just wouldn’t be broadcast. Kind of like the savings the city of Chicago tried to realize when it turned off all the free-flowing water fountains. Of course, they had to turn them back on because the water tasted so bad.

Heck, Cuban (or people like him) could just send a fresh rack of hard drives to your local cable operator every month with new content. When you get down to the head-end level, I’m sure you could calibrate a balance between “broadcasting” that which is most popular locally (instead of sending a huge number of simultaneous unicast streams) and then supporting nearly on-demand service for the other stuff. A PVR in your home that was a natural extension of the cable system could manage all this for you, sequencing back together those 18 GB while you sleep.

]]> By: Colin Davis http://blog.germuska.com/2004/08/26/dvdinosaur/comment-page-1/#comment-110 Colin Davis Fri, 27 Aug 2004 20:34:06 +0000 http://www.akwaabasound.com/golb/?p=407#comment-110 After chunking down a fair bit of $ to get an HDTV recently, these issues are constantly circiling my mind. <br /><br /> I think all of these things hold promise -- you would need to substantially up the bandwidth of the data pipes in order to get it to work right. For example, Return of the King in HDTV, a 1080i file, is about 18.5 gb, and over a fast DSL connection (100 K per sec) would take about 2 days to transfer with no interrupts or other disruptions. <br /><br /> I am so frustrated by the web of contracts that need to be signed to get it to work right (the tangle of FCC laws with must-carry rules and the local broadcaster issues casuing a multiplier effect on the amount of content needed to be carried is ridiculous) that it has even sent me to alt.binaries.hdtv to see if that would work, but I gave up, because there is no way i am going to try to sequence back 18.5 gb of data from many little packets. After chunking down a fair bit of $ to get an HDTV recently, these issues are constantly circiling my mind.

I think all of these things hold promise — you would need to substantially up the bandwidth of the data pipes in order to get it to work right. For example, Return of the King in HDTV, a 1080i file, is about 18.5 gb, and over a fast DSL connection (100 K per sec) would take about 2 days to transfer with no interrupts or other disruptions.

I am so frustrated by the web of contracts that need to be signed to get it to work right (the tangle of FCC laws with must-carry rules and the local broadcaster issues casuing a multiplier effect on the amount of content needed to be carried is ridiculous) that it has even sent me to alt.binaries.hdtv to see if that would work, but I gave up, because there is no way i am going to try to sequence back 18.5 gb of data from many little packets.

]]>