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?<dtv 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

Received on Tuesday, 17 November 1998 22:45:33 UTC