[opendtv] Re: FCC CHAIRMAN PROPOSAL TO UNLOCK THE SET-TOP BOX: CREATING CHOICE & INNOVATION

  • From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
  • To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
  • Date: Sun, 21 Feb 2016 01:21:36 +0000

Craig Birkmaier wrote:

WOW!!!!  I did not expect Bert to walk into this trap.

Because I didn't. I explain how things work, instead of having a vague notion 
of what's going on.

TCP/IP is part of the Internet stack used to support applications.
The application we are discussing here is streaming a TV program.
The ACTUAL data that makes up that program is compressed audio,
compressed video, and perhaps some metadata. How the packets that
deliver that data are delivered is handled by lower layers of the
stack. For OTT services that use the Internet, TCP/IP is used to
link the server and device, and regulate the flow of packets. For
OTA broadcasting, MPEG-2 transport handles the packet data.

Fewer words, and more understanding of the subject matter, Craig. TCP is 
carrying the streaming packets, in most cases (UDP could be used too, but then 
it wouldn't be a stream from a web server, right Craig?), and TCP is a point to 
point, two-way protocol. Which means, the adjustment of the codec settings, to 
match your own link speed, and the controls like fast forward and reverse, are 
all part of that streaming protocol, which uses TCP. Even if UDP is used, it 
too would carry the streaming packets, and normally would also be unicast.

The one-way broadcast medium doesn't have, cannot have, any of those features. 
you cannot control the broadcast stream from your set, Craig. Even if it's 
digital broadcast. The best you can do is record it, and then control the 
recording in playback. Do I really have to explain this?

As to what you call "actual data." The streaming protocol MAY use MPEG-2 TS for 
synchronization, although most do not, but do much the same thing in other 
ways. And the codecs MAY be identical, carrying the same MPEG packets. So that 
part has always been the same, or very similar. Always, Craig. I know you feel 
offended that the ATSC adopted a "Table 3," but honestly, when you are limited 
to a one-way broadcast medium, it's PERFECTLY acceptable to limit the choices.

Bottom line, however, there is nothing stopping broadcasters
from continuously updating the application layer technologies
used to deliver TV content, exactly as has happened with the
Internet.

Nonsense. The biggest obstacle is that TV sets aren't upgradeable remotely. 
Sure, the broadcasters could hand out free HDMI sticks, and irritate people who 
just want to watch good old broadcast TV. Another obstacle is that this is a 
one-way broadcast medium. A lot of updates to streaming protocols have to do 
with the controls, e.g. in making interactive ads. Doesn't work with one-way 
broadcast. Another obstacle is that no one cares. TV is a mature medium.

Instead of me trying to guess what your misunderstandings are give us some 
examples of whiz bang new features you'd want from a one-way broadcast medium. 
Then I'll pick them apart.

If you have more flexibility of choice over the Internet, that's
because it ain't broadcast.

Pure crapola Bert. There is NOTHING different at the application
level.

The hell it isn't. Once again, rather than me trying to figure out the gaps in 
your understanding, give me examples of what you would want from broadcasters.

Garbage response. DTV is just another data pipe.

Just the kind of vague nonsense we've come to expect, Craig. A one way pipe 
cannot support the same "apps" as two-way pipes. It's that simple. And the 
small aspects that can be the same, or very similar, i.e. the stream of MPEG 
packets, ALREADY ARE. And have been, from day 1.

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: