Re: Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company

[Robert Bonomi <bonomi () mail r-bonomi com>]

> 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.