[opendtv] Re: Broadcast and other topics
- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 30 Jun 2015 01:54:30 +0000
Craig Birkmaier wrote:
The ONLY fact that is relevant here is that I was specifically
talking about the fact that ATSC 1.0 supported the broadcast of
multiple linear streams.
The only important part is that you need to shut off that TV droning in the
background, and concentrate. This is the exchange, June 25:
Use multicast if you have to reach masses of people
simultaneously, or use unicast if you have to reach few
people, even with live content. I already explained how this
can be done, Craig.
Semantics again Bert. Broadcast becomes IP multicast - no
problem
I was talking about a potential 2-way ATSC 3.0 OTA system here. IP multicast is
not the same as broadcast, for such a 2-way scheme. If you want to make
efficient use of even OTA spectrum, in this hypothetical 2-way cellular ATSC
3.0 net, they are quite different. But they will support "live streams" without
the need for any broadcast mode at all. But that's not the worst part. Then, on
June 26, you got really confused, in this exchange:
Okay so the first point is, "ATSC 3.0 will still support
big stick broadcasting/multicasting" is devoid of meaning,
when using the Internet definition of multicasting.
ATSC 1.0 supports multicasting Bert.
I made it super clear, "when using the Internet definition of multicasting,"
because I had been talking about a potential 2-way OTA ATSC 3.0. So we are
talking about LTE/IP type multicasting here. Your response? "Big deal, ATSC 1.0
already does this multicasting." Wow, Craig. Really on the ball, eh? Hello?
Hello?
ATSC IS another broadcast scheme Bert - please look at
the physical layer optionsplease look at the physical
layer options.
"The ATSC 3.0 physical layer is expected to provide a large range of possible
operating points for broadcasters, all of which are very close to the Shannon
limit (the theoretical limit of how much information can be carried over a
noisy channel) as illustrated in Figure 2, below. Basic operating tradeoffs
include selecting a lower data capacity/more robust service and/or higher data
capacity/less robust service, or points in-between."
So, Craig, explain to us what, in the above paragraph, leads you to believe
that this only applies to broadcast? In detail, please.
Connected TVs have everything to do with the TV content
distribution media being able to finally sunset any and
all actual "broadcast" streams, Craig
All TVs are connect Bert.
More absurd replies from Craig. The term "connected TVs" means "TVs with IP
receivers built in," Craig. I said specifically that it's all about
convenience. A little old lady may hold on to her legacy broadcast OTA viewing
or linear streams through the MVPD box, just because they're already there. But
with a proper connected TV, she wouldn't anymore, most likely. So that speeds
up the process of sunsetting broadcast mode.
Sorry Bert, but most of the services can be supported with
one way broadcast. You are not even close to being accurate.
This from someone who thinks ATSC 1.0 already supports IP multicast. I really
believe you, Craig. Here's the link again, and here's what proves you wrong:
http://pbs.bento.storage.s3.amazonaws.com/hostedbento-prod/filer_public/TechCon2014/TC14%20Presentations/Chernock_ATSC3_1_v05.pdf
Slide 5, top level mission statement: ATSC 3.0 must provide performance
improvement and additional functionality sufficient to warrant implementation
of a non-backward compatible system
Slide 7, describing changes since ATSC 1.0: Interactivity has become expected,
Delivery paths other than broadcast have become commonplace
Slide 8, what ATSC 3.0 must support: Hybrid broadcast + broadband delivery
Slide 14 on scenarios for ATSC 3.0: Hybrid Services,
Personalization/Interactivity
Slide 20 on skeleton architecture: downlink, uplink
Slide 29, on interactive services: Goal is to enable receivers connected to
MVPD distribution networks (e.g., cable, satellite, 3GPP) that may have access
to a subset of the ATSC 3.0 broadcast components to access missing components
via alternative networks (e.g., Broadcast or Broadband), to the extent possible.
Slide 32, on layers 6 and 7 of the ISO/OSI model: Interactivity,
personalization, alternative component selection, etc.
Slide 33. On the service model: Services - packages of content offerings from a
broadcaster, e.g., a linear channel or an OnDemand library
Slide 34, two types of services: Basically, TV as we know it today, and
Consumers access content on-demand via an app, Consumers choose what content to
access and when
Slide 35, features: Hybrid delivery (broadcast and broadband)
Slide 40, audio: Hybrid broadcast/broadband delivery is supported
Slide 41, runtime environment: HbbTV 2.0 tracking just ahead of ATSC 3.0
So in short, every single slide that mentions anything about services to be
supported makes it clear that a 2-way network is required for ATSC 3.0. And
slide 29 makes it abundantly clear that if some MVPD does not yet support all
of the necessary ATSC 3.0 components, the user will have to make use of a 2-way
network. Implication being, obviously, that ATSC 3.0 itself does include all of
the components necessary, to avoid having to depending on any additional
networks.
And is spite of this, Craig gets obstinate with: "most of the services can be
supported with one way broadcast" Show me where this is implied, Craig. Point
to the slides and quote what they say, to give you the impression that ATSC 3.0
is just another broadcast standard.
Concentrate, Craig. Shut off that racket in the background.
Bert
----------------------------------------------------------------------
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:
