Re: E-E: URL: Comments on TV URI reqs I-D

I agree with Craig that a URI should be able to identify discrete pieces
of data, such as modules in a data carousel or objects in an object
carousel. This was also intended to be included within the term
"component" which I used in my original draft requirements.

As far as fragments go, the possible solution I mentioned in my last email
message is that a "fragment" descriptor be defined for the VCT. This is
very comparable to the use of targets in HTML pages. The browser doesn't
know where in the page the target is going to occur until it receives the
page and looks through it. Similarly, the receiver wouldn't know in
advance where in the event the fragment is going to occur, but it can
recognize it when it gets to it. This gives very fine time resolution when
desired, since a new VCT version with the fragment descriptor could be
inserted into the broadcast stream at the microsecond when the fragment
begins. As Craig points out, such a descriptor would probably be used
infrequently for ads, so as not to enable ad killers.

When I referred to locally stored material, I was not thinking of the
caching situation. Caching should certainly be transparent, so a cached
resource should certainly be referenced by the same URI as the original.
It is up to the caching agent to manage the bookkeeping. I was thinking of
the situation where a copy has been consciously stored, with the intent of
keeping it for a prolonged time, e.g., recording a movie and adding it to
a personal video library.

Craig A. Finseth wrote:

>    (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



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

Received on Wednesday, 18 November 1998 10:36:36 UTC