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 receivers. "Semantics" means the definition of a field in a specification, while "syntax" is the actual bit-stream structure of the field and surrounding data. 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 ATSC-land.) 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 channel) 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 http://www.etherguidesystems.com/Help/SDOs/ATSC/syntax/tablesections/MGT.asp 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 (http://www.etherguidesystems.com/Help/SDOs/ATSC/syntax/tablesections/tvcT.a 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 backwards-compatible. 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 present) * 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. Regards Craig ---------------------------------------------------------------------- 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.