Re: E-E: AW: URI Requirements

Good suggestion.
These are all abbreviations for features of the Advanced Television Systems Committee (ATSC) Program and System Information Protocol (PSIP)
specification and Data Broadcasting specification.

A copy of the PSIP specification can be obtained from the ATSC web site, http://www.atsc.org, document A/65.

A copy of the draft Data Broadcasting specification can be obtained from the web site of the ATSC data broadcast subcommittee (T3/S13),
http://toocan.philabs.research.philips.com/misc/atsc/t3s13/.

EIT is Event Information Table. It gives information about "events" (TV programs in usual terminology).
VCT is Virtual Channel Table. It gives information about "virtual channels" (TV channels in usual terminology)
EPG is Electronic Program Guide. This is an on-screen television program guide, especially an interactive guide. Such EPGs are likely to be
built-in features of most digital TV sets.
SDT is Service Description Table. It gives information about specific resources which form part of a data service in a digital TV broadcast.

Henning Timcke wrote:

> LMS is library management system (LMS)
> by the way what is EIT
> by the way what is VCT
> by the way what is EPG
> by the way what is SDT
> by the way what about writing each abbreviation first in full and then
> abbreviated within brackets ?
> This might invite new readers to get into more comfortable touch with
> the context.
>
> Henning
>
> -----Ursprüngliche Nachricht-----
> Von:    Gomer Thomas [SMTP:gomer@lgerca.com]
> Gesendet am:    Dienstag, 17. November 1998 18:56
> An:     rob@mtvmail.com; Ted.Wugofski@otmp.com; gadams@spyglass.com; www-tv@w3.org; e-e@toocan.philabs.research.philips.com; Petr Peterka
> Betreff:        Re: URI Requirements
>
> I just sent out to www-tv and DASE e-e some comments on Warner ten Kate's
> Internet-Draft on TV URI requirements. Buried in there are solutions to some of
> the problems you are discussing here.
>
> I think it will be difficult for broadcasters to keep EITs constantly up to date
> with schedule adjustments. It will be much easier to keep the VCT up to date. The
> key point is that the relevant portion of the VCT can be prepackaged with each
> program, and it is a purely mechanical process to collate these portions into the
> full VCT as the programs are multiplexed into the transport stream. If a schedule
> slips, this affects which programs are fed when into the multiplexor, but the
> prepackaged VCT information does not need to be changed. In contrast, the EITs
> contain start time and duration. If a schedule is shifted, the content of the EITs
> need to be changed, and in cases of incremental slip, it is often not clear what
> to change it to.
>
> Thus, to maintain a definitive real-time view of what event is playing, and
> optionally what segment of that event, an event_id descriptor should be included
> in the inner descriptor loop of the VCT, and optionally a segment_name descriptor.
> (E.g., if the Coke people really want to identify an ad, they could insert a
> segment name "Super Coke Ad", but they would not have to.)
>
> The problem with using the SDT for this sort of thing is that the SDT only appears
> when there is a data service. One might want to do this kind of identification for
> pure video events.
>
> By the way, what is "LMS"?
>
> Gomer
>
> Craig A. Finseth wrote:
>
> >    Of course, the EPG doesn't tell you the one thing everyone will need to
> >    know, which is "When is the commercial break?" The reality of the TV
> >    business world is that some resources we send during content may not be
> >    appropriate for use during commercials, and some commercials may require
> >    their own resources. Therefore, whatever system we use for resource ID must
> >    also consider the commercials as "segments."
> >
> > But, of course, they can't be identified as such (directly or
> > indirectly) or we've just created a "commercial killer."  Not good
> > (for some people).
> >
> >    What is comes down to is that all broadcasters need a direct an accurate
> >    connection between on-air and the resources being sent. Right now that data
> >    exists at the head-end in real time.
> >
> >    If we really want to solve the problem, we would develop a system that puts
> >    a continuous trigger signal in the video feed so that we can ID at any time
> >    exactly what is on, where we are in it, and so forth.
> >
> > In my opinion, this is going the wrong way.
> >
> > As more people have access to more channels, it becomes harder to
> > locate desirable content.  The only resource available is the EPG
> > (printed guides can't be updated).  I expect viewers to rely more on
> > this source and increase their expectations for its accuracy.
> >
> > After all, if you're going to shuffle your schedule and not tell
> > anyone, you can't expect people to find your programming, can you?
> >
> >    Without that, the LMS is as good as it gets.
> >
> > And why can't this be fed into the EPG?
> >
> > Craig
>
> --
> Gomer Thomas
> LGERCA, Inc.
> 40 Washington Road
> Princeton Junction, NJ 08550
> phone: 609-716-3513
> fax: 609-716-3503
>
> --------
> To unsubscribe, send a message to
> majordomo@toocan.philabs.research.philips.com
> with
> unsubscribe e-e <your-email-address>
> in the body of the message (remove the angular brackets
> around your email address, please)



--
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
phone: 609-716-3513
fax: 609-716-3503

Received on Tuesday, 17 November 1998 13:57:03 UTC