Date: Tue, 17 Nov 1998 21:45:31 -0600 (CST) Message-Id: <199811180345.VAA07634@isis.visi.com> From: "Craig A. Finseth" <email@example.com> To: firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org 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