[opendtv] Re: New Thread: What becomes of Legacy Analog Equipment

  • From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
  • To: <opendtv@xxxxxxxxxxxxx>
  • Date: Mon, 26 Nov 2007 10:10:46 -0800

Oh, boy.  I don't know where to begin to respond.  Pardon me if I'm snippy,
but I live and breathe this stuff.

First for the global considerations.  Even after FSTV analog sunsets in the
United States, Honduras, Mexico and Canada (at the least) are ATSC countries
that will be broadcasting in analog.  In addition, there will be analog and
digital LPTV stations in the U.S., and some of them will be broadcasting
PSIP for both analog and digital.  Mexico will cease analog broadcasting
beyond 2018.  The others haven't even announced a date for the cessation of
analog.  Changing the semantic definition of PSIP fields before their
cessation of analog will -- at the very least -- break all existing

"Semantics" means the definition of a field in a specification, while
"syntax" is the actual bit-stream structure of the field and surrounding

ATSC is an international organization, not a national one.  It's standards
are used in a variety of nations.  (I do not include South Korea in this
analysis as their PSIP system is different than that in use in the rest of

System Information (in the ATSC context, PSIP and MPEG-2 Program Specific
Information or PSI) is signaling and announcement.  Generally, humans use
the announcements, and receivers use the signaling.  There are NO ELEMENTS
IN System INFORMATION indicating the size of the coded video frame; this is
always contained in good, old-fashioned MPEG-2 video metadata.  As a result,
there is no mechanism for indicating the coded video frame, except for what
is currently being transmitted.  I'm not sure that there is a need to
indicate this in advance, since the broadcaster might need to change video
size to maintain program schedules in the face of changed conditions.
(Think about showing scheduled programming on one virtual channel while
presenting a breaking news story on a previously unscheduled virtual

PSIP is defined in ATSC A/65; you cite A/69, which is a recommendation on
the use of PSIP and is not a standard.  Oddly enough, I have never read A/69
-- or even glanced at it.  I'll get around to it some day.

You say "the easiest would be to place something like HD or (H) at the
beginning for the Event Description Field in the Master Guide."

Here is the syntax for the Master Guide Table
x  You will note that there is no "event description" field.  There was a
different syntax in use in the A/55 specification, but that went by the
boards last century.

The service_type field in the Terrestrial Virtual Channel Table
spx) , as I explained above, can't be used as you suggest.  There is an
additional consideration in that it's not the right context, since the
context for video size is a video stream, and the virtual channel applies to
audio, video and possibly data broadcasting streams.

There is no need and strong reasons to not use your scheme to redefine the
service_type field to deal with signaling and announcement of data services;
those are already in ATSC specifications.  If the data service exists by
itself (no associated audio or video), it is announced as it's own service,
otherwise, signaling is in the context of the MPEG-2 program map table
(PMT).  Announcement in both of these contexts can be handled in Data Event
Tables (DET) to the extent they need to.

Since all ATSC specifications have -- as a result of the Grand Alliance
agreement and FCC rulings -- to be backwards-compatible, it is hard to
understand how your ideas would work, since they are clearly not

It might be possible to put an (HDTV) or some such in the (optional)
Extended Event Text Table (EETT).  This means that in all TV sets that
display event descriptions, the event would appear as (title) "Everybody
Loves Raymond" (description) "(HDTV) Raymond and his mother discuss ..."

I've already addressed the fact that a scheduled event may need to be bumped
down to cover extenuating circumstances.  In addition, "(HDTV)" is six ASCII
characters, while screen size can be expressed explicitly in just a few
bits.  It's also not clear to me if (HDTV) is enough detail.  But, screen
size and scan type can be expressed explicitly in fewer than 48 bits, and
there are existing means to do so, but they are only used in video
elementary stream metadata.

Private means could be used to transmit this information, but I'm not sure
that would be particularly useful.

John Willkie

-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Craig Birkmaier
Enviado el: Monday, November 26, 2007 4:47 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: New Thread: What becomes of Legacy Analog Equipment

At 5:03 PM -0800 11/25/07, John Willkie wrote:
>I don't know of a way to indicate in advance in PSIP whether a 
>program (event, actually) is broadcast in HD.  TMS has that data 
>available, but it's not necessarily a technical term, more like a 
>marketing term.

I can think of several ways to indicate that a program is in HDTV.

The easiest would be to place something like HD or (H) at the 
beginning of the Event Description Field in the Master Guide. This 
would eat up a few of the characters available, but would be very 
easy to understand and to implement.

A more complex way to indicate that a program is in HD is to use the 
Extended Text Message table to provide more info about the event 
including whether it is HD, ED or SD.

For the long haul, I would suggest an amendment to A-69 to change the 
values for the Service_type descriptor.

The current values that are permissible for this field are:

* 1 denotes an NTSC analog service
* 2 denotes an ATSC full digital TV service including video, audio 
(if present) and data (if
* 3 denotes an ATSC audio and data (if present) service
* 4 denotes a ATSC data service

After the analog stations are turned off, there will no longer bee a 
need for value #1.

We could change this to ATSC HD, or come up with additional values to 
denote other levels of source quality.

If we did not add any values it would probably NOT break existing 
receivers, although they might indicate NTSC if value 1 is used.


You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: