[opendtv] Re: Broadcast and other topics
- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 3 Jul 2015 00:58:39 +0000
Craig Birkmaier wrote:
This is getting old and I am not going to keep playing Bert's
game.
It certainly is getting old, Craig. You seem to knee jerk disagree, which would
be fine if you could substantiate your disagreement. But you *never* do. Never.
Instead of substantiating, you proclaim. Makes you sound (a) distracted, and
(b) like you don't even know how to use a search engine. Even something as
trivial as finding an example of non-neutral MVPD behavior, with respect to HBO
Go. Why would you expect that to be spoon-fed to you twice, Craig, when you
should have searched it out on your own before claiming it doesn't happen? I
even gave you what to type into your search engine. Amazing. If you disagree,
on what basis? No basis? Just whatever comes to your mind at the time?
As for ATSC 3.0, the standard is still being developed, so we
cannot assume that it will simply mirror existing Internet
standards.
Yes, work in progress. When I posted that link the first time, I did not expect
to have to explain it in full detail, Craig. I expected that you would read the
information and discover that indeed, ATSC 3.0 is very emphatically pursuing
models that depend on 2-way network service, **and** that they were proposing
their own 2-way network. Of course it's still early days. But as it says way up
front, ATSC 3.0 has to justify being a non-backward-compatible scheme, by
adding lots of new features. Which says right there, hardly another warmed over
broadcast scheme. And then it reinforces that point over and over again, all
throughout the presentation. Hardly just a fluke phrase that might have been
misinterpreted.
You may ultimately be correct that there is a tooth fairy, Craig. Until then,
if you want to convince anyone, you have to provide evidence.
If broadcasters want to build out a 2-way cellular network in
the spectrum they control, they do not need a new standard from
the ATSC. The standards already exist for LTE,
What Craig is missing is that LTE is a generic 2-way pipe, covering ISO/OSI
layers 1 and 2, and using IP for layers 3 and 4 and higher. ATSC 3.0 is
obviously taking this all the way up to the application layer, specifically
designed for TV content delivery. LTE by itself could *certainly* be part of
the solution, but not the whole solution. And ATSC 3.0 may also want to tweak
LTE for its own service. Just one trivial example, mentioned by Mark Aitken: if
ATSC 3.0 is to be optimized for TV delivery, rather than for voice or other
very low latency interactivity, it may trade off some extra delay for better
robustness.
So it is absurd to say that the ATSC is primarily working on
a 2-way OTA standard,
What is absurd is Craig's unbelievable obstinacy. Based on pure vapor.
So, Craig, explain to us what, in the above paragraph, leads
you to believe that this only applies to broadcast? In detail,
please.
It is their stated requirements for the physical layer of the
standard they are creating.
I repeat: in detail. Explain why that "stated requirement" implies one-way
broadcast, in your mind. Substantiate your claims. Here is the paragraph you
thought did so:
"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."
Tell us all what you see in there that supports your view. I don't know how
many other ways to ask this simple question, before you'll answer.
Do you expect the IETF to develop a broadcast standard?
Do you expect **anyone** to be pursuing a one-way broadcast standard here,
Craig? What makes you think that, for heaven's sake. If you think you can
answer just based on some "gut feel," suspect indigestion.
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.
Sorry, but you are absolutely wrong.
Craig proclaiming again. Craig, you are completely wrong. End of story.
Everything they propose can be supported by using existing
2-way networks for the back channel signaling.
Not quite. You still can't seem to grasp that interactive service to thousands
or millions of people cannot rely on a broadcast channel "and a back channel."
It needs a 2-way network. I explained this to you countless times, for years.
Think "scale." The broadcast channel offers very little, in the greater scheme
of things. I did the numbers for you, Craig. Do some math for the rest of us.
You are providing interactive service, with on demand streams, to 10,000
simultaneous viewers. Tell us how much downlink each one will get, from a 6
MHz, market-wide broadcast channel.
So leaving that aside, I also covered that ATSC 3.0 **could** use the Internet,
for unicast interactivity or live multicast, plus some additional old school
broadcast net. **Could** being the operative word. And I said the
broadcast-only service will go increasingly into disuse. And I said that ATSC
1.0 was perfectly adequate for that role.
But that's NOT what the ATSC is saying! So, did you read slide 29 (link below)?
What does it say, Craig? Tell us all, in great detail, what Slide 29 tells you.
Alternatively, show some evidence that this presentation is totally scrapped,
and ATSC 3.0 has become just another one-way broadcast scheme.
http://pbs.bento.storage.s3.amazonaws.com/hostedbento-prod/filer_public/TechCon2014/TC14%20Presentations/Chernock_ATSC3_1_v05.pdf
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:
