- From: Henning Timcke <henning.timcke@werft22.com>
- Date: Mon, 26 Oct 1998 18:47:28 +0100
- To: "'Rob Glidden'" <robg@quadramix.com>, Simon Gibbs <simon@arch.sel.sony.com>
- Cc: "www-tv@w3.org" <www-tv@w3.org>, Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>, Rodger Lea <rodger@arch.sel.sony.com>, "djz@corp.webtv.net" <djz@corp.webtv.net>
Great idea to seek focus with basic application scenarios Here a basic solution (without superimpose) [>] For example, the "buy-me button" scenario: A Coke commercial comes on. During the commercial, a "buy-me button" appears on-screen. If the viewer selects it, further information appears about a local sale on Coke. When the commercial is over, the button disappears. Questions: How does the client know to launch the buy-me button? [>] The coke commercial has a PI to request the by-me button from http://buy.coke.com What is put in the cache, and how is it queried? [>] The buy me coke button is put in the cache or retrieved from cache How does the clent know to remove the buy-me button? [>] From the Synchronization part of the buy-me button What if the viewer tunes in halfway through the commercial? [>] Synchronization must allow to multiple request within an intervall What if the viewer wants to save the local store address? [>] The commercial must also send a "save address" button As you can see it's a matter of deciding at what exact time on a timeline what happens. So that something can happen in the right time: the commercial as well has to be made in a matter that allows interaction with the user. With superimpose all that is needed is a transparent imagemap. The client or viewer must be able to act like the early mosaic-browser. Cache can be within RAM (Basic Viewer) or on a PCMCIA like device (Personalized Viewer). I'd like to have my personal cache with me. Henning Requirements: Open-standard end-to-end solution Robust, stable, and deployable architecture Rob -----Original Message----- From: Henning Timcke <henning.timcke@werft22.com> To: 'Rob Glidden' <robg@quadramix.com>; Simon Gibbs <simon@arch.sel.sony.com> Cc: www-tv@w3.org <www-tv@w3.org>; Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>; Rodger Lea <rodger@arch.sel.sony.com>; 'djz@corp.webtv.net' <djz@corp.webtv.net> Date: Sunday, October 25, 1998 12:38 PM Subject: Conceptual requirements >Rob: >I propose to use XML Processing instructions (PIs). >All the cached data should report their statuses to an application. >This application checks the caches and computes their relevance >(distance to time, accuracy of information, time to live downloaded). >Another application should mark the cached data with approriate information) >What has to be worked out is the relevance of the delivery time. >How many caches have to be established by reasons of topology (bandwith needed). > >I think it is of importance to get some things on the same level of abstraction and to sort them out: >1. How TV is made >2. How TV is broadcasted >In the far future there will be no difference, but in the near future there will be many differences. For the present: we have to know on what level of differentiation the fileformats are. Is there a collection of all fileformats in use somewhere, beyond http://www.ora.com/centers/gff/specs.htm. >From a very conceptual point of view TV is only a Webpage (HTML or SMIL) with full screen resolution and zero net congestion. >For example an HTML Page with animated Gif's and with an embedded Realvideo or an MPEG Stream can look the same as an HTML Page with an MPEG 7 Stream. And an HTML Page with an Full Screen RealVideo can be just an MPEG Stream of Content made as a SMIL. > >A workaround might be to superimpose the signal of normal TV with the signal of a webbroswer. > >Simon wrote: >>Here are some of the things that I would like >>to see supported: > >>A URL/URI/URN that allows a browser to locate and access >>content obtainable from the following devices: > >>- consumer AV equipment (CD, MD, DV, DVD etc) >>- DTV receivers and set-top boxes > >>I'm also assuming that there is a network connection >>of some form between the browser and the device in question. >>This connection can carry both control information and content. > >>From my point of view all the contents can be addressed as URLs, all the data has a fileformat and a filename. Live streams can be addressed with a mechanism analog to the Real System, were a live stream has already an URL. > >And, of course it is true, when Dan Zigmond writes: > >World-Wide Web browsers are starting to appear on a variety of >consumer electronic devices, such as television sets and television >set-top boxes, which are capable of receiving television programming >from either terrestrial broadcast, satellite broadcast, or cable. On >these devices, some of the URL schemes described in [1] are >inappropriate. For example, many of these devices lack local storage, >so the "file" scheme is of little use. > >But, my TV (Monitor) and my VHS Recorder are not the same, conceptually, except they are both local devices. > >My TV cannot use the file scheme (no storage device!) but my VHS Recorder can (storage device!). > >Inapproriate is to locate content that has no filename and no fileformat. > >What my questions are: > >What, if we had a topology that allows to manage all existend content into URL conformance (e.g Regional Real Server Stations (TV within a cablenetwork works even without IP (VOD), we build such an environement (with DNS and IP) for Orbit'98 on MPEG and RS G2 and an additional MPEG hardware decoder) ) ?. > > >What happens to the content broadcasted ? > >Shall the content be storable on the client side at all ? > >If any broadcasted content was in the proposed scheme of tv:<broadacst> >what fileformat will be used ? > >Still I believe: if the content has a fileformat and a filename we need nothing else to build on than XML and UR*. > > > >Henning > > > >-----Ursprüngliche Nachricht----- >Von: Rob Glidden [SMTP:robg@quadramix.com] >Gesendet am: Mittwoch, 21. Oktober 1998 21:33 >An: Henning Timcke; Simon Gibbs >Cc: www-tv@w3.org; Philipp Hoschka; Rodger Lea >Betreff: Re: AW: work on url for television started > > >-----Original Message----- >From: Henning Timcke <henning.timcke@werft22.com> >To: 'Rob Glidden' <robg@quadramix.com>; Simon Gibbs ><simon@arch.sel.sony.com> >Cc: www-tv@w3.org <www-tv@w3.org>; Philipp Hoschka ><Philipp.Hoschka@sophia.inria.fr>; Rodger Lea <rodger@arch.sel.sony.com> >Date: Wednesday, October 21, 1998 11:12 AM >Subject: AW: AW: work on url for television started > > >>Rob: >>I will try >>Where do I find information about data carousels ? >>Henning > > >Conceptually -- data carousels are "constantly refreshed client-side caches >of broadcast data objects". Think of tuning in to a TV channel -- if it is >a web page -- how often does the web page have to be rebroadcast so you can >see it when you tune into it? Does all of the page have to be rebroadcast >every second? how about just the top level page more often, with images >refreshed every few seconds (for example..) > >For background > >ATSC Specialist Group T3/S16 for Interactive Service Protocols: > >http://toocan.philabs.research.philips.com/misc/atsc/t3s16/ > >A faq on DSM-CC is at >http://drogo.cselt.stet.it/mpeg/faq/faq_dsm-cc.htm > >An Introduction to Digital Storage Media - Command and Control (DSM-CC) >http://drogo.cselt.stet.it/mpeg/documents/dsmcc.htm > >Rob > > >> >> >> >>-----Ursprüngliche Nachricht----- >>Von: Rob Glidden [SMTP:robg@quadramix.com] >>Gesendet am: Mittwoch, 21. Oktober 1998 19:25 >>An: Henning Timcke; Simon Gibbs >>Cc: www-tv@w3.org; Philipp Hoschka; Rodger Lea >>Betreff: Re: AW: work on url for television started >> >>Henning: >> >>Yes, I think assistance would be helpful. Could you elaborate a little on >>how XML could meet these kinds of requirements? >> >>1) "referencing cache data" -- in transient caches and data carousels >> >>2) "querying caches" -- to determine what is currently in them and >>available >> >>3) "supporting session management" -- i.e. identifying, launching, >>subscribing, terminating multiple streaming sessions. >> >>I think a key challenge if finding the right level of abstraction -- some >>people think of all this a high-level, authoring issue, some think of it as >>low level exposing of the syntax of things like MPEG transport streams. >> >>Rob >> > >
Received on Monday, 26 October 1998 12:49:59 UTC