RE: URI Requirements
From: Davis, Rob - MTVN (rob@mtvmail.com)
Date: Mon, Nov 23 1998
Message-ID: <32D524CD9FC0D111A02600A0C9AB2B6E02CFD33B@mail1.mtvnodn.com>
From: "Davis, Rob - MTVN" <rob@mtvmail.com>
To: Warner ten Kate <tenkate@natlab.research.philips.com>, "Davis, Rob - MTVN" <rob@mtvmail.com>
Cc: "'www-tv@w3.org'" <www-tv@w3.org>, "DASE E2E Team (E-mail)" <e-e@toocan.philabs.research.philips.com>
Date: Mon, 23 Nov 1998 11:52:29 -0500
Subject: RE: URI Requirements
Warner,
Thank you for your informative response.
You are right about contradictions involving commercial notification. We
certainly do not want a "skip" feature, but we do need to know about the
breaks to handle content needs.
I know my initial comments went beyond the scope of this project, but it is
increasing hard for me to look at the components when it seems so few people
are looking at the big picture. I appreciate the fact that you and others on
the list have an eye toward that big picture, and I thank you all for this
opportunity to comment.
Rob
PS: Once again, I must state that the content of this e-mail does not
represent the thoughts of MTV Networks.
R o b D a v i s
Executive Producer
of Convergence Applications
M T V N e t w o r k s
phone: (212) 846-7515 / / fax: (212) 846-6497
e-mail: <mailto:rob@mtvmail.com> rob@mtvmail.com
-----Original Message-----
From: Warner ten Kate [SMTP:tenkate@natlab.research.philips.com]
Sent: Monday, November 23, 1998 7:47 AM
To: Davis, Rob - MTVN
Cc: 'www-tv@w3.org'; DASE E2E Team (E-mail)
Subject: Re: URI Requirements
Davis, Rob - MTVN wrote:
>
> Excuse me for jumping in midstream. I hope you all find my
comments useful.
> I've been lurking for awhile and figured it is time to add a
broadcaster's
> point of view. I work with convergence projects at MTV Networks.
Of course,
Thanks for your comments. I found them quite useful.
Sorry for responding a little delayed.
I am not sure whether in our current requirements document
we have touched the proper requirements to fulfill the needs
you describe. Maybe a little discussion can bring us further.
Below I suggest an improvement in the requirements list.
> Of course, the EPG doesn't tell you the one thing everyone will
need to
> know, which is "When is the commercial break?" The reality of the
TV
> business world is that some resources we send during content may
not be
> appropriate for use during commercials, and some commercials may
require
> their own resources. Therefore, whatever system we use for
resource ID must
> also consider the commercials as "segments."
You confuse me. This sounds like a contradiction.
I always understood that content providers wanted:
A: don't provide a mechanism to indicate the commercials
(such that they can be skipped), the so-called
commercial killer.
I understand the above as:
B: do provide a mechanism to indicate commercial breaks
(such that resources can be retrieved).
(Btw. DVB-SI provides a lite mechanism to signal commercial
breaks; it is an optional feature, though. It is not used
as far as I am aware, because of reason A above.)
>
> What is comes down to is that all broadcasters need a direct an
accurate
> connection between on-air and the resources being sent. Right now
that data
> exists at the head-end in real time.
This is not an URI requirement,
but a transport system/protocol requirement.
You can use DSM-CC to solve that. You need an application document
to express how the various resources (media) are composed together,
eg. HTML. In your case the program application is interrupted with
a commercial application (another HTML page), each using different
resources, modeled in DSM-CC as separate namespaces.
DSM-CC also provides the accurate timing you need. DSM-CC provides
a so-called NPT (Normal Playing Time) which locks to the system
clock of 27 MHz. You can trigger resources with that accuracy.
I suppose that fulfills your need (I don't know the accuracy of
the LMS):
>
> If we really want to solve the problem, we would develop a system
that puts
> a continuous trigger signal in the video feed so that we can ID at
any time
> exactly what is on, where we are in it, and so forth.
>
> Without that, the LMS is as good as it gets.
The URIs are declared in the application document (HTML page).
They should point in the corresponding namespace, which is existing
for at least the time period the commercial is up.
The precise synchronization in presenting your resources is
expressed in the application document (HTML), not in the URI.
The application listens to the events from your transport stream
and synchronizes the presentation of the resource, indentified
by the URI, in relation to that event. (So, with DSM-CC you
have 27 MHz accuracy.)
The URI should only indicate that the resource is available
in the channel. It is up to the service provider to take care
that the resource and the application calling the resource are
scheduled in proper synchronization. (You need your LMS for that.)
--
If information from the commercial stays longer in the
transmission channel than the application, I would model that
as a data broadcasting service, having its own channel/service ID,
not that of the regular program.
[I am not sure whether the term 'data broadcasting' has the same
interpretation in EU and USA. In EU we think of a stand-alone
service, providing data to (subscribed) users. The receiver is
not a TV per se. Pushing Web-pages is an example, stock quotes
another.]
--
Triggered by your comment I changed the fourth requirement.
I hope that reflects your needs.
o Given a URI, it must be possible for a receiver to determine
the time period(s) within which the resource can be retrieved
from the (also resolved) location. The accuracy of the time
period should correspond with the event's granularity as
provided by the service signaling system.
[Note: the time period in which the resource is valid/meaningful
is controlled by the lifecycle of the application calling the
resource. That application also controls the synchronization
of the time period in which the resource is presented. The URI
indicates the time period within which the resource is
available.]
Warner ten Kate.
--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax: +31 4027 44648 tenkate@natlab.research.philips.com