URL: Background & Reqs (ASCII)

Philipp Hoschka asked me to resend my "URL: Background and
Requirements" message in ASCII format, so here it is.

This note attempts to provide some background information on
digital TV (DTV) environments, and then some requirements for URL
schemes for DTV. If you are very familiar with the DTV standards,
skip the background.

BACKGROUND:

A DTV receiver may have no connection with the outside world
through any link other than a DTV broadcast signal coming from an
antenna, satellite, or cable feed. It may or may not have access
to the Internet. It may or may not have access to devices on a
home network (which may not be an IP network). For the moment I
wil ignore the home network issues.

The signal coming from an antenna, satellite, or cable feed will
typically have a number of RF bands on which DTV signals can be
received. When the receiver tunes to a particular RF band and
demodulates the signal there, it ends up with an MPEG-2 transport
stream. There are currently two competing standards for DTV, the
DVB standard developed in Europe, and the ATSC standard developed
in the United States. Among other things, they use different
methods for modulating the digital bit stream into the RF signal,
so in the near term at least most receivers will be able to
receive one or the other, but not both.

I am much more familiar with the ATSC standard than the DVB
standard, so the following explanations are oriented toward the
ATSC standards. Much of it, but not all, will be true for DVB as
well.

Each MPEG-2 transport stream has a transport_stream_id. There is
currently no guarantee of uniqueness of these IDs in the ATSC
world. However, the National Assn of Broadcasters (NAB) is
advocating that the FCC assign transport stream IDs to
broadcasters, associated with their broadcast license, so that
they would be guaranteed to be unique. In the meantime, they may
well be unique in practice.

Each MPEG-2 transport stream may contain multiple "programs" or
virtual channels. (The ATSC DTV standards use the term "event" to
describe what would be called a TV program in normal usage, and
they use the term "program" to describe what would be called a TV
channel in normal usage.) For example, a single transport stream
may contain one high definition TV (HDTV) program, or several
standard definition TV (SDTV) programs, along with a potentially
large number of pure data programs. Each virtual channel has
associated with it a program_number, a major and minor channel
number, and a source_id. All of  these are guaranteed to be
unique within the transport stream, but not across transport
streams. Each of these may also have associated with it a short
channel name. The number of programs in a single transport stream
may be as few as one, or as many as dozens, depending on the
bandwidth required for the programs. The number may vary over
time.

Each program may contain multiple elementary streams. For
example, a typical TV program would contain one video stream and
perhaps multiple audio streams in different languages. An
enhanced TV program might also contain multiple streams
containing data to support interactive applications to enhance
the viewing of the program -- for example, statistics on demand
during a baseball game, or biographical information on demand
during a talk show. There might be pure data programs which
contain only one or more elementary streams of data to support
some application, for example a stock ticker or news headline
ticker which runs across the bottom of the screen, independently
of what video program is being watched. Each elementary stream
has a packet_id and optionally an association_tag. These are
guaranteed to be unique within the program.

A question related to uniqueness is stability. If I tune to the
same RF frequency from the same broadcast station, will the
resulting transport stream always have the same ID? In terms of
guarantees, no, but in practice probably yes. If I look at
channel 17-2 (major-minor channel number) from the same station,
will it always have the same program_number and source_id? In
terms of guarantees, no in both cases. In practice, probably no
for the program_number and yes for the source_id. If I look at
the video for channel 17-2, will it always have the same
packet_id? Almost certainly not.

Another form of stability is what happens during the broadcasting
process. Typically the multiple programs which may appear in a
transport stream are assembled in the broadcast facility more or
less independently and are then multiplexed together into the
final transport stream. What happens to the various identifiers
during this multiplexing process? The program_number and
elementary stream packet_ids are likely to change. The others
will not.

Note also that the same network TV program, say from PBS, could
be broadcast by numerous local affiliate stations, and the RF
band, transport stream ID, major-minor channel number, and
channel name would be different for each affiliate. Thus,
receivers in different parts of the country would find the same
program (with exactly the same content) under different RF bands,
transport stream IDs, channel numbers, and channel names. It
might also be broadcast at different times -- not only different
local times, but different absolute times.

To complicate things further, when a program is picked up by a
cable or satellite operator and rebroadcast, nearly every single
one of the identifiers for the program may be changed -- RF
frequency, ts_id, program_number, major-minor channel number,
source_id, packet ids, possibly even association tags. Proably
the channel name will stay the same.

Each TV program (or "event") has an event_id. However, currently
these event_ids are only guaranteed to be unique within the set
of events in the same transport stream which appear in the same
3-hour interval (where each day is divided into eight standard
3-hour intervals, measured in GMT). A proposal has been submitted
to ATSC to make the event_ids unique within each source_id, but
this is being resisted by the broadcasters so far, due to certain
complexities it would introduce into their operations.

The ATSC Data Broadcast Specification (from T3/S13 subcommittee)
specifies a number of different protocols for including data in
an MPEG-2 broadcast stream:
    - DSM-CC bounded data carousels
    - DSM-CC unbounded data carousels
    - streaming data in PES packets
    - IP or other protocol datagrams encapsulated in PES or TS
packets
    - piped data in TS packets

There is a strong probability that at some point in the future
either the T3/S13 (Data Broadcast) or T3/S16 (Interactive
Applications) subcommittee will specify the use of DSM-CC object
carousels as well, but that does not appear likely to happen
right away.

In most cases this data can be:
    - asynchronous: presentation timing more or less arbitrary
    - synchronized: presentation timing tied to other streams,
such as audio/video
    - synchronous: presentation timing internally constrained

Even data which is essentially stable will usually be broadcast
repeatedly at fairly short intervals, to accommodate viewers who
tune into the middle of an event, or receivers which have little
or no caching capability.

The ATSC Data Broadcast Specification also specifies a Service
Description Table which is used to describe the applications
which make up a data event, and specify the files the
applications need and where to find them. Thus, within a given
event, an application_name and so-called tag_id can be used to
identify a data resource (file).

REQUIREMENTS:

A number of broadcasters will be broadcasting data enhancements
along with their video events, and even broadcasting pure data
events, of the sort described earlier in this note. In many cases
the data will be in the form of HTML pages, to be rendered onto
the TV screen by HTML engines in the receivers. Although we often
think of an HTML page as a single file, it usually requires a
number of files to render even a single page, just for the images
which appear in the page if nothing else. Moreover, an
application may often contain multiple inter-linked HTML pages.
All of these files will have to be included in the broadcast
stream, and the HTML engine will have to be able to find the
files from URLs which appear in the HTML pages.

To complicate things, the HTML pages for the application will
often be generated by some content creator far removed from the
eventual broadcast stations. It will then be sent to the network,
which will distribute it around to the different local affiliates
to include in their broadcast. Thus, all of the various
identifiers described in the background section of this note will
be unknown to the content creator.

The simplest case is that all of the inter-linked files appear in
the same elementary stream. The next simplest case is that they
all appear in the same program, but possibly in different
elementary streams.

Since a single transport stream may include four or so SDTV
programs, it is likely that at times there will be some
coordination of data applications across multiple virtual
channels within the same transport stream, so a URL which appears
in one program may reference data which appears in another
program.

Moreover, in the cable world there may often be a single
broadcaster controlling multiple transport streams. In fact, with
the increasing concentration in the communications industry, this
may happen in the not too distant future for terrestrial
broadcasts as well. Thus, there may be coordinated data
applications across multiple transport streams, so a URL which
appears in one program may reference data which appears in other
transport streams.

Then, of course, some DTV sets will have Internet access (and
some PCs will have TV access).

Thus, an HTML page contained in a broadcast may reference files
in the Internet, to give TV viewers access to additional
information beyond what is included in the DTV broadcast, or to
give TV viewers the ability to interact with web servers to order
products, etc.

Also, broadcasters and others will have web sites, where they
will want to reference broadcast programs. In some cases they may
want to reference broadcast video eventss to watch. In other
cases they may want to reference broadcast data events, or
individual files which are included in a broadcast data event.
For example, a stockbroker who wants to advertise a live TV stock
ticker data service might well provide a reference to it on
his/her web site. In the case of a TV event which is only
available at certain times, the URL must include a time component
of some sort.

All this leads to the following requirements for URL schemes for
DTV environments:
    - URLs must actually be URLs, not just URIs. Given a URL, it
must be possible for a receiver to actually locate the resource,
or conclude that it is not reachable. (Note that locating the
resource may require intermediate steps, analogous to a DNS
lookup on the Internet. ATSC T3/S8 document 253, URL Mapping,
submitted 26 Feb, 1998, by General Instrument, is a step in this
direction, but does not quite solve the problem.)
    - It must be possible for the resource referenced by a URL to
be an entire program/event, or just a single component of a
program/event.
    - It must be possible for a URL to contain an identification
of the date(s) and time(s) when the resource is available, either
through an explicit time designation, or through an event
designation.
    - The set of URL schemes for DTV should include audio/video
streams and all of the data broadcast protocols endorsed by the
ATSC Data Broadcast Specification.
    - A URL must be meaningful when interpreted from any of the
following locations relative to the resource being referenced:
        * From within the same elementary stream
        * From within the same program
        * From within the same transport stream
        * From within a different transport stream received by
the same receiver
        * From an arbitrary location in the Internet
The correct interpretation of this requirement is that a DTV
receiver should be able to obtain an HTML page from any of the
listed locations, and if the resource referenced by a DTV URL in
that page is available to that receiver in the broadcast streams
it can receive, it should be able to find the resource.

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

Received on Thursday, 29 October 1998 14:07:48 UTC