Re: E-E: URL: Comments on TV URI reqs I-D
From: Craig A. Finseth (fin@finseth.com)
Date: Tue, Nov 17 1998
Date: Tue, 17 Nov 1998 21:45:31 -0600 (CST)
Message-Id: <199811180345.VAA07634@isis.visi.com>
From: "Craig A. Finseth" <fin@finseth.com>
To: gomer@lgerca.com
Cc: www-tv@w3.org, e-e@toocan.philabs.research.philips.com
Subject: Re: E-E: URL: Comments on TV URI reqs I-D
(3) The second requirement refers to "components" and "fragments"
of a program. We need to define what those terms mean. In my
original draft I used the word "component" to refer essentially
to an elementary stream in a DTV broadcast. It could also be used
to refer to the video track, audio track, or "extended data
track" (VBI line 21 encoded data) in an NTSC broadcast, I
suppose. I'm not sure what you mean by "fragments". Is that a
time segment of an event? -- for example an ad segment, or the
first quarter of a basketball game?
I suggest that URLs be able to identify any discrete piece of data
needed by an application at roughly the equivalent of a "file" level.
This usage would be similar to that of the current http: protocol.
Thus, it must be able to identify data carousel modules, elementary
streams, and higher level items.
If that is what you mean, then the statement that fragments are
outside the scope will be somewhat controversial. In particular,
some members of DASE think that one should be able to reference a
commercial within an event, since advertisers may in some
circumstances want to publicize and point to the appearance of an
ad -- for example, the famous Apple Computer ad during the
SuperBowl a few years ago. My initial reaction was serious
skepticism about the utility and feasibility of doing this.
However, on thinking it over, I can see some value in it, and
maybe it not very difficult. See my comments in (4) below.
I believe everyone agrees that we must be able to identify _that_ a
commercial is within an event.
The differences arise when attempting to identify an exact showing of
a commercial within an event. In particular, the standard usage
within an ATSC receiver is limited to the EIT resolution of one
minute. (Non-ATSC environments may not have this limitation.) We may
have to introduce a sub-event descriptor in the EIT to cover this
case.
Note that the widespread use of such a descriptor would assist
"commercial killers," which is probably enough to discourage its use.
Note also that the EIT is not used for the actual data coming down the
tuned event stream: that information is carried by the SDT, DIT,
etc. and is as accurate as the transmitter wishes.
(4) In the fourth requirement we need to specify what kind of
time granularity is intended. In my mind there are three possible
levels of granularity: (A) event, (B) fragment (as described
above), and (C) tiny, where "tiny" refers to the precise time(s)
at which a resource such as an MPEG-2 frame or a JPEG file or an
HTML page is being broadcast.
Note that any references to MPEG time _must_ use the PTS references
and thus are not carriable with URLs.
We certainly want a TV URI to support time granularity at the
event level -- although in an ATSC context at least we may need
to add the event_id to the channel information in the VCT so that
it is possible to determine what event is currently showing
without relying on the EITs being kept 100% up to date in the
face of schedule shifts, etc.
Probably a good idea.
...
We should definitely make it clear that "tiny" is outside the
scope of the URI.
Agreed!
To the extent there is concern with identifying a specific
resource within an MPEG-2 transport stream when the transport
stream has been recorded on a local storage system, I think the
appropriate URI would be something like file://x.y.z? uri>,
where file://x.y.z gets you to the file on the storage system
which contains the transport stream. This is much the same
approach you would have to take if you took a collection of files
from a web server, packaged them up into a ZIP file, and stored
the ZIP file in a storage system.
Actually, the _same_ URL should be used to identify the stored
(cached) version as the live one. That's the whole point!
To the extent there is concern with runtime resolution of
references between components of an MPEG-2 transport stream which
has been stored on a local file system, the file system is no
longer relevant once the stream starts playing. What you now have
is a transport stream coming into a receiver. It looks like a
broadcast, although possibly with a considerable time shift, and
typically coming from a different physical channel than the one
it originally came from. This is somewhat comparable to taking
the entire file system from one web server and moving it to
another web server. Whether the cross links still work or not
depends on whether the authors consistently used relative URIs.
It turns out that the URI translation mechanism I proposed last
week probably does deal with this situation correctly, as long as
the entire transport stream has been recorded, but I don't think
this should be a requirement.
In my view, relative URLs should be avoided. While DTV URLs may
_look_ like regular http URLs, they are very different things and
"relativeness" can be very confusing.
So long as URLs are not relative, recording and playback of streams
should simply work fine.
To the extent there is concern with a situation where there are
cross links between a live broadcast and a stored event, or
between two stored events, or between a web server and a stored
event, there is no magic. If one moves a bunch of files from one
web server to another, this will "break" references to these
files from other files on the web server which have not been
moved. The URI translation mechanism I proposed last week
probably does deal with this situation correctly when the stored
stream/s is/are played into a DTV receiver, but I don't think
this should be a requirement.
Again, just use non-relative URLs and it is fine.
Craig