[opendtv] Re: NTIA: National Broadband Map has Helped Chart Broadband Evol
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 15 Aug 2015 17:47:15 -0400
On Aug 14, 2015, at 8:50 PM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx> wrote:
First, that the article does not explain what "digital video" is. Am I
watching "digital video" or "traditional TV," when I watch full length
episodes at cbs.com?
Yes.
The author once again is taking liberties with language. In this case, I
believe he is calling anything delivered over the top to be digital video.
This is a common problem with such articles. And yes, the ratio is now 24-76,
according to this article, assuming we know what they are classifying as
"digital video." Which suggests that we're hardly decades away from being
able to do this for all TV content.
From a purely technical perspective, it is clear that we could see the delivery
of all TV content move to the Internet within a decade. All it would take is
additional investments in infrastructure. It is clear that these investments
will be made in urban areas and more affluent communities; less clear what it
will take to reach the underserved rural markets.
And there is the coming "war" between the cabled systems and the wireless
systems, both cellular and WiFi, las wireless data networks are growing in
capability to deal with the shift to mobile devices.
But the legacy video networks are not dead yet, especially the DBS systems. The
cabled nets can make a bunch of money selling broadband and video in bundles.
The DBS systems provide a nice complement to the wireless data sold by the
telcos.
Bottom line, legacy business have staying power, as we have seen with the
broadcast networks and their affiliates; it does not hurt that the MVPDs are
sending them big checks.
I mean the last mile of cabling Bert, not the ability of edge servers
to deliver bits over the local broadband networks to viewers. Why would
the cable companies keep building pons in neighborhoods, if the
bandwidth is already there?
The bandwidth is there, to each home, if you are connected via coax or fiber.
No need to touch cabling to those homes. What the telcos and the cablecos
have to do is restructure the upstream nodes. The amount of passive splitting
permissible is reduced, upstream. Recouping spectrum taken up by broadcast
MPEG-2 TS mitigates that problem, possibly by a whole lot.
Even the Fios systems are not built out to the level you suggest. And both
Verizon and AT&T are focusing their investments on wireless, not Fios. The coax
is great for the neighborhood, but the cablecos need fiber to neighborhood pons
to build out the bandwidth as I explained already.
So let's assume 200 homes per node. The typical HFS system using DOCSIS
2.0 has a potential throughput of 4.7 Gbps.
Okay, good data point here. Do the math,
I did. Apparently you did not read it or just ignored it.
Craig. Let's say that your PON, much like FiOS does, is still dedicating the
equivalent of just 120 6-MHz channels to broadcast MPEG-2 TS (256-QAM). If
that bandwidth is completely recouped, and provided for broadband, how many
homes could be fed with 20 Mb/s? You might be surprised. Do the numbers.
I did.
So perhaps, could you double the number of homes in the PON? Or feed each
home twice as much broadband capacity?
Problem is that most cabled systems have far more than 200 homes per node, so
they need to keep building out the fiber coax branching trees.
And I did the math. Even with DOCSIS 3.0 we are talking a theoretical 27.5 Mbps
if an entire 1 GHz HFS system with 200 home nodes, is dedicated only to
downstream data. But you need upstream too, and most systems never meet the
theoretical numbers.
As I explained the nodes may need to smaller - perhaps 100 homes.
But they complain about costs, and not without reason. That's where the CDNs,
funded by others, can step in. And not just that, but these distributed
servers can be fed from satellite signals, which would also be someone else's
concern than the ISP. They don't need to use the backhaul network owned by
the ISP. And the servers would choreograph shows like news, also outside the
purview of the ISP.
As I explained, the cable cos already have all the backhaul in place. They will
need to upgrade their MPEG-2 encoders which currently chew up lots of
bandwidth. Encoders that supply all the different files are not terribly
expensive, and most edge servers are updated during off peak hours with all the
files for popular programs.
If the cable system wants to offer a video bundle, they will need to put this
stuff on servers in their headend. They do have a small advantage in that they
can send a single program stream to a PON then deliver it to multiple homes in
that node. This is one of the reasons I have suggested that cabled MVPDs may
continue to use a big chunk of their bandwidth for the linear channels, even
after they move to more efficient encoding and IP packet routing. These streams
will not need to follow net neutrality rules.
Obviously there will be multiple CDNs looking for hosting at ISP sites. But
just as you suggest that broadcasters become CDN, the cable system can mirror
most of the linear programming that people will want to access on demand.
Comcast is doing that now.
Did they have the hardware accelerators implemented in their mobile device
tests? The article doesn't say. Kon already spoke on this, Craig. And more
importantly, does AppleTV have any such power starvation problems? Nope. Just
wanting to make life difficult, that's all.
Nobody was building hardware acceleration for Flash into their graphic chips -
Flash ran on the device CPU. I still remember how hot my laptop would get when
accessing Flash video files. The main reason that the GPU manufacturers adopted
h.264 acceleration was that it was an international standard, and unlike Flash
and MPEG-2, the cost to license the codec was very reasonable.
Apple TV uses the same chips as the other iOS devices, usually a generation or
two behind to keep the cost low. But that may change next month when the next
generation Apple TV (device) is introduced. It will have it's own App Store,
and is
likely to support multiuser games as well. I would expect a TV web browser as
well, which means the ability to access many of the (free) OTT sites you like.
And the rumors are it will come with a touchpad remote.
In any event, I'll repeat, it's not that Flash or proprietary should last
forever. It's that you don't drop something like a hot potato, when dealing
with industry standards such as these, and expect a smooth transition. You
make a royal pain in the rear of yourself, instead.
Flash was NOT an industry standard. Like many other technologies that the IETF
standardized after the value was proven, Flash was proprietary technology sold
by Adobe. The players were free, but Adobe made big bucks on authoring tools
and licensing components needed to make it work on web servers.
The only criticism of Apple I can support is that parts of HTML 5 were not
finished when they introduced the iPhone in 2008. So there was a period of time
when many Flash websites did not render well on iOS devices. I almost never see
them any more, although many companies have added HTML support in addition to
Flash.
I recently noticed this on my desktop computer. A legacy Flash video site was
stalling and stuttering. I directed the browser to the iOS site I access on my
tablet, and the problems went away. But to be fair, some of the Flash based UI
also went away.
Adobe has not suffered badly, as it was relatively easy to build bridges
between their authoring tools and HTML 5. But they did lose market share to new
companies like Wordpress that embraced HTML 5 early; Wordpress now powers 24%
of all websites via subscription authoring software and hosting services.
Regards
Craig
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts: