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

Received on Tuesday, 17 November 1998 12:55:53 UTC