Re Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company
bonomi at mail.r-bonomi.com
Thu May 26 06:23:27 UTC 2011
> Date: Thu, 26 May 2011 02:08:04 +0100 (BST)
> From: Brandon Butterworth <brandon at 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_
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 -
> 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.
More information about the NANOG