[opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2008 09:43:50 -0700
I can't disagree on your points, David.
However, non-carriage of PSIP is my issue, not how the FCC's rules limit the
bandwidth cable must devote to PSIP.
And, the bandwidth limits are probably more than adequate to carry much more
than 12 hours.
My first customer airs PSIP - currently limited to static PSIP until he
finishes a simple interface from his radio-centric traffic system. We air
15 hours of listings for seven virtual channels. To wit, Master Guide Table
(once every 144 ms), Terrestrial Virtual Channel Table (once each 332 ms),
Channel Extended Text Tables for 7 virtual channels, and 35 separate
instances of Event Information Tables and 35 separate instances of Event
Extended Text Tables. EIT-0's and EETT-0s every 500 ms, with EIT-1s and
EETT1s sent each 1000 ms .
Total bit rate: is 89k to 106k per second. Subtract out the Master Guide
Table (7 per second) , TVCT and CETT instances, and you are talking about a
maximum of less than 80k.
I doubt that there are few U.S. terrestrial broadcasters that use as much
bandwidth for PSIP as does KYES-DT. And, the sad fact is that, unless a
broadcaster uses EtherGuide Emissary or has very expensive test and
measurement gear, they don't even know how many bits are involved with PSIP.
I know broadcasters that reserve 1.5 mb/seconds for PSIP. (EtherGuide
Emissary gives a front-panel readout of the PSIP/PSI bit rate in real-time.)
80k is much better than 0 k, and the FCC will make this requirement move
explicit in due course.
John Willkie
_____
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de David Broberg
Enviado el: Tuesday, March 11, 2008 9:27 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
Actually, the PSIP carriage requirements for multisystem operators (MSOs)
are defined by TITLE
<http://a257.g.akamaitech.net/7/257/2422/16nov20071500/edocket.access.gpo.go
v/cfr_2007/octqtr/47cfr76.640.htm> 47, Sec. 76.640. Furthermore MSOs are
only required to carry event information (EITs) describing a 12-hour period,
and that may be further limited to defined bandwidth caps of 80 kbps or 115
kbps for the combined total PSIP stream of all services within the
multiplex. If a broadcaster's PSIP stream is verbose, the MSOs are able to
drop excess data as needed to comply.
(iv) For each digital transport stream that includes one or more
services carried in-the-clear, such transport stream shall include
virtual channel data in-band in the form of ATSC A/65B: ``ATSC Standard:
Program and System Information Protocol for Terrestrial Broadcast and
Cable (Revision B)'' (incorporated by reference, see Sec. 76.602), when
available from the content provider. With respect to in-band transport:
(A) The data shall, at minimum, describe services carried within the
transport stream carrying the PSIP data itself;
(B) PSIP data describing a twelve-hour time period shall be carried
for each service in the transport stream. This twelve-hour period
corresponds to delivery of the following event information tables: EIT-
0, -1, -2 and -3;
(C) The format of event information data format shall conform to
ATSC A/65B: ``ATSC Standard: Program and System Information Protocol for
Terrestrial Broadcast and Cable (Revision B)'' (incorporated by
reference, see Sec. 76.602);
(D) Each channel shall be identified by a one- or two-part channel
number and a textual channel name; and
(E) The total bandwidth for PSIP data may be limited by the cable
system to 80 kbps for a 27 Mbits multiplex and 115 kbps for a 38.8 Mbits
multiplex.
-David Broberg
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Adam Goldberg
Sent: Tuesday, March 04, 2008 8:18 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
The requirements on MSOs to pass through PSIP, if provided, is in 97-80.
I thought you made a PSIP generator? Are you selling to MSOs, too?
Adam Goldberg
adam_g@xxxxxxxxx
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Tuesday, March 04, 2008 7:13 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
In the R&O in MB Dkt 07-91 (release December 31, 2007), the commission
mentioned this aspect and said in the cable companion proceeding (MB Dkt
07-120?) that they would address this issue. I'd add "again."
The FCC is learning in this respect. A few years back, they thought they
"made clear" that stations need to transmit EPG information in Event
Information Tables. As an Gomer Thomas at Triveni Digital first pointed out
to me, the language ACTUALLY only mandated the transmission of Event
Information Tables. As you and I know, one can transmit Event Information
Tables, per ATSC A/65, that have no events listed, so they left a
work-around. (Triveni Digital units, judging by my transport stream
captures, do just this in the absence of EPG information.)
My PSIP generator does something quite different. When there is no EPG
information, it presents the "default event" and "default description" for
that channel. The default event title might be "Regular KXXX-HD
programming" and the "default description" could include information about
the channel.
The new rules will require accurate program listings, including sports
overruns. This is a big deal; it technically mandates that every station
have a live connection between automation and the PSIP generator, or have an
operator ready to make real-time EPG changes.
Even network-owned station groups will have issues with this new rule. I
suspect that many won't 'get real' until the FCC imposes fines.
It would be a bad idea, methinks, for me to "report" prospects and customers
of other vendors to the FCC. In other words, it doesn't put me in a good
position to sell them things in the future. But "you could be fined
otherwise" is a good reason to upgrade your PSIP generator.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Adam Goldberg
Enviado el: Tuesday, March 04, 2008 3:52 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
The operators are required to pass through PSIP, when received from the
broadcaster. If you find any systems that aren't doing that, it should be
reasonably easy to complain to the MSO and/or FCC.
Adam Goldberg
adam_g@xxxxxxxxx
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Tuesday, March 04, 2008 1:59 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
Point taken. So, the argument from stripping PSIP out of the multiplex --
which the FCC explicitly requires cable to pass on -- is _____?
In terms of bit-budget, My first customer has six virtual channels, each
with 15 hours of titles and descriptions. Bit budget? Circa 100 kilobits
per second.
If the argument is that "some" broadcasters don't know what they're doing
(announcing sap audio but not offering it), I'd say that there are worse
cases of that around, and I trust things will get better as broadcasters
focus on making money with DTV.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Adam Goldberg
Enviado el: Tuesday, March 04, 2008 7:56 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
I was getting ready to write "First of all, "every bit" is a bit of
hyperbole. AFD takes 6 /bytes/ per frame."
But then a buddy of mine called, who is a senior engineering type at a very
large MSO and has a big hand in creating the multiplexes they send to each
head-end. I asked him about stripping AFD. His response was: "That's the
craziest thing I've ever heard".
In fact, he said, he has several channels where SAP was supposed to be
provided but isn't, so it's provisioned but not supplied. If he were to go
looking to save a few hundred kbps, he'd start unprovisioning the SAPs, not
worrying about 1440bps of AFD. He then went on to say that they'd like
there to be MORE AFD supplied so they can actually use it.
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Monday, March 03, 2008 6:00 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
I'm almost willing to make a bet that it will be common for cable systems to
do this: they fight over every bit. They take out 20%-50% of the video
content, (and fight for the right to do so) and still call it HDTV.
The less it makes sense, the more they are likely to do it. Why, oh, why,
despite FCC rules, do they strip out PSIP? So their users can use
lower-quality, lower-utility, hard to use cable EPGs.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Adam Goldberg
Enviado el: Monday, March 03, 2008 2:10 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
> The AFD or pan-scan/bar data mechanism can support carrying the data
through
> to TV sets; AFD is more robust in that regard, but at this moment, cable
> isn't required to pass on AFD, if present. (That should change shortly.)
Cable may not be required to, but in order to remove it they'd have to edit
the picture user data on-the-fly. IMHO, they're unlikely to do that.
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Monday, March 03, 2008 3:38 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
Facility:
You can pass (I don't know at this moment if it's a published standard, cd
or fcd at SMPTE) for this type of encoding. I can't remember if it's in the
VANC or HANC (I think it might be in both.) I am speaking of a standard,
not a vendor-specific solution.
BXF (SMPTE 2021, a full committee draft at this moment) supports the
functionality Martin mentioned. (I'm not sure that it goes all the way back
to sales, but it certainly can.) This article in the most recent issue of
BE covers BXF and PMCP.
http://broadcastengineering.com/storage_networking/building_better_epgs_801/
index.html
Transmission
The AFD or pan-scan/bar data mechanism can support carrying the data through
to TV sets; AFD is more robust in that regard, but at this moment, cable
isn't required to pass on AFD, if present. (That should change shortly.)
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Shutt
Enviado el: Monday, March 03, 2008 12:25 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: News: DIGITAL TV OPENS UP TWO-WAY OPPORTUNITIES
----- Original Message -----
From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
> The problem is in marking the materials to be shown in the "run list" or
> automation process and inserting the data into the video stream. Can you
> carry the input of this data all the way back to the beginning of the
> ingest
> process or even sales?
John,
My point exactly, and I'm glad to see the industry also agrees with me.
What I said is that there is no standard way of identifying material as
anamorphic 16:9 or 4:3.
Come up with a SMPTE standard to pass along AFD within the VANC data of
SD-SDI, do so in a way that any company's cross converter can understand and
automatically follow, and then we can start mixing and matching formats
within the server.
As things stand right now, it is up to a traffic database to keep track of
such things, and a station automation system to change modes on a cross
converter. Too dicey and too limited in usefulness.
There needs to be a standard that hard encodes the AFD into the video that
survives any and all processing in the production and distribution chain
from initial acquition to final home viewing, just as closed captioning and
V-chip information remains preserved. It can even live inside the CC/V-Chip
data area to make sure it will survive all processing.
But there has to be an agreed upon standard first. Right now there is no
standard, just a bunch of different proposals or specialized solutions.
John
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
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:
