> Date: Thu, 26 May 2011 02:08:04 +0100 (BST) > From: Brandon Butterworth <bran...@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.