Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
You demonstrate you have no understanding of what the word 'feasable' means.
OK, but we actually did this as a commercial service on analogue TV and we deliver non picture data on digital TV (satellite and terrestrial) today, it's just not USENET data.
One _cannot_ do this with 'modern' digital TV trasmission, because the _end-to-end_ technolgy does not support it.
Apologies for disagreeing, but this is exactly what the modern technology does. Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a multiplex of a number of independent data streams that can be data, video or audio. That is carried end to end. We do this now with other data - http://en.wikipedia.org/wiki/BBC_Red_Button It'd be trivial for us to display USENET directly to read on your TV or deliver it to the STB ethernet port
OTOH, if the signal originates as a digital stream, while it may be "possible" to multiplex in an additional data stream, said data stream will *NOT* survive _intermediate_ transcoding to an analog video stream before transmission to the end-user.
Indeed but that is not a digital TV system.
And, even if the actual digital stream is delivered to the end-user, a *STANDARD* digital TV receiver has no means to deliver that 'additional' information to the end-user in any usableform.
Standard DTV PVR with an ethernet port are a few hundred dollars. For the people who would actually receive this the box cost is trivial they just some software. If you have a USB or PCI DTV rx it is trivial to do whatever you like with the data. brandon
On Thu, 26 May 2011 02:08:04 BST, Brandon Butterworth said:
One _cannot_ do this with 'modern' digital TV trasmission, because the _end-to-end_ technolgy does not support it.
Apologies for disagreeing, but this is exactly what the modern technology does.
Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a multiplex of a number of independent data streams that can be data, video or audio. That is carried end to end.
When Stargate stuck (say) 10% more data into TBS's analog signal by stashing it in retrace and blanking intervals and the like, TBS's bandwidth requirement went up zero. Zip. Zilch. How much does your bandwidth usage on your new miracle boxes go up if you stick another 10% data stream in there? Probably a measurable amount more than zero.
Date: Thu, 26 May 2011 02:08:04 +0100 (BST) From: Brandon Butterworth <brandon@rd.bbc.co.uk> Subject: Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
You demonstrate you have no understanding of what the word 'feasable' means.
OK, but we actually did this as a commercial service on analogue TV and we deliver non picture data on digital TV (satellite and terrestrial) today, it's just not USENET data.
One _cannot_ do this with 'modern' digital TV trasmission, because the _end-to-end_ technolgy does not support it.
Apologies for disagreeing, but this is exactly what the modern technology does.
NAME five consumer-grade commercial off the shelf products
Digital TV (ATSC in your case, DVB-T & DVB-S in our case) has a multiplex of a number of independent data streams that can be data, video or audio. That is carried end to end.
That is *VERY* RARELY true in the U.S., in point of actual fact, as soon as a 'cable TV' carrier/distributer gets involved. *THEY*, the cable companies, de-multiplex the streams from the originator's composite signal, and *selectively* re-encode the streams they wish to propogate on _separate_ QAM channels. Proof: go to Titantv.com, select the 'digital cable' channel line-up for 'Comcast areas 1, 4 & 5' in zipcode 60640 (chicago north side, lakefront). and check the comcast channels in the range 340-379. These are all cable-company _de-multiplized_ video streams extracted from the multiplexed stream from the originator. The 'primary' (only!) HD video streams for those channels can be found, mostly, on channels in the range, 187-194. I'll simply ask, _which_ of those channels will have that extra data stream that the head-end inserted? That the cable compmany doesn't know, or care, about, and *how* does it survive the de-multiplexing and re-coding that the cable company did?
We do this now with other data -
http://en.wikipedia.org/wiki/BBC_Red_Button
It'd be trivial for us to display USENET directly to read on your TV or deliver it to the STB ethernet port
You might be able to do it, if you control everything from the point of rigin -through- the STB.
OTOH, if the signal originates as a digital stream, while it may be "possible" to multiplex in an additional data stream, said data stream will *NOT* survive _intermediate_ transcoding to an analog video stream before transmission to the end-user.
Indeed but that is not a digital TV system.
Tell that to all the U.S. cable companies that do _exactly_ that, and sell it as 'digital' TV -- because they have re-encoded each derived analog video stream as a QAM "digital" channel.
And, even if the actual digital stream is delivered to the end-user, a *STANDARD* digital TV receiver has no means to deliver that 'additional' information to the end-user in any usableform.
Standard DTV PVR with an ethernet port are a few hundred dollars.
For the people who would actually receive this the box cost is trivial they just some software. If you have a USB or PCI DTV rx it is trivial to do whatever you like with the data.
You apparently have no idea how 'digital TV' is delivered by all the major cable companies in the U.S. -- demultiplexed, and transcoded to QAM with each video stream on a separate QAM channel. I don't see any _possible_ way for an additional data stream to survive _that_, without explicit intervention/support from the cable company.
participants (3)
-
Brandon Butterworth -
Robert Bonomi -
Valdis.Kletnieks＠vt.edu