On Jul 9, 2013, at 5:10 PM, "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx> wrote: > Don't forget that you read it here first. Yup. We've been talking about these issues on OpenDTV for several years. The article is informative, but not completely accurate. It also points to the many barriers to success should a broadcaster choose to move exclusively to OTT. A more likely scenario would be to continue to supply MPEG-2 streams to local cable systems, and DBS systems that rare willing to host these signals, and rely on OTTY only for the limited number of homes that currently rely on FOTA broadcasts. > > Not sure that the broadband bandwidth requirement is quite as big as the > article implies. I think 3 Mb/s down would be more than adequate for a couple > or three simultaneous streams, actually. And more so when H.265 or VP9 become > implemented. h.264 is likely to remain the focus for the next few years. h.265 could become a factor several years out, VP-9 is not likely to be a factor because it is proprietary. > > The point about multiple standards having to be supported, thanks to Apple in > large measure, is a fact of life that broadcasters are already dealing with. > It's not all homogenous as it was in the OTA/cable-only days. Consumer > devices should already have been available for this. That's the aggravating > part of it. This information is largely incorrect. I am not aware of any current devices that do not support h.264 and HTTP live streaming. There is one major exception - brain dead HDTVs that are locked into ATSC/MPEG-2; but you can add a $99 device to solve this problem. And I agree with Bert, that almost everyone, including broadcasters, are dealing with this. As the article notes, it is likely a station would use a CDN to deliver the streams, and these companies already support a range of codecs, streaming protocols and bit rates. > The analysis on live streams is not valid, however, because ISPs would most > likely adopt IP multicasting for live streams. Why wouldn't they? There's no > problem creating IP multicast groups, even with IPv4, within an ISP's own > network. The only problem is inter-network IPv4 multicast. So an ISP with > self-preservation instinct would use IP multicast for anything that's popular > and live. Of course, it may have to be more than just one stream, thanks to > those companies that don't understand how to support popular standards. Yes, IP multicast would be essential if a station continues to operate as they do today with a time slot oriented broadcast schedule. But this begs several questions. First, why would you force people to watch a program at a specific time if you move to OTT? This would only make sense for live programming, which makes up a small percentage of the broadcast day. And if a station decides to sell its spectrum and move to OTT, they may well lose network affiliations that now deliver these live programs. Even with local news, one might question the need for live newscasts. It is more likely that they would move to a new portal approach where viewers can access the stories they want on demand, as many of us are doing already. As an aside, I wonder if IP multicasting is being used to deliver these live programs OTT today, to all of the devices that are now enabled to watch these streams by virtue of an MVPD subscription? > The rights to stream content that doesn't belong to the local broadcast > station is obviously a major issue in all of this, at least from the point of > view of *that local broadcaster*. Not from the point of view of whether or > not that content can get on the Internet, though. Bert failed to mention the geo blocking portion of the article, which is a major issue. Perhaps this is because he sees little value in our market based broadcast system, unlike the politicians. 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.