Re: draft - minor issues

------- Forwarded Message

Return-Path: <tenkate@natlab.research.philips.com>
Received: from sophia.inria.fr by www45.inria.fr (8.8.8/8.8.5) with ESMTP id RAA27772 for <hoschka@www45.inria.fr>; Tue, 12 May 1998 17:46:41 +0200 (MET DST)
Received: from gw-nl1.philips.com by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id RAA23694 for <Philipp.Hoschka@sophia.inria.fr>; Tue, 12 May 1998 17:46:37 +0200 (MET DST)
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl1.philips.com with ESMTP id RAA27379;
          Tue, 12 May 1998 17:46:31 +0200 (MEST)
          (envelope-from tenkate@natlab.research.philips.com)
Received: from natlab.research.philips.com (prle.natlab.research.philips.com [130.139.161.112]) 
	by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with SMTP id RAA10544; Tue, 12 May 1998 17:46:31 +0200 (MET DST)
Received: by natlab.research.philips.com; Tue, 12 May 1998 17:46:30 +0200
Sender: tenkate@natlab.research.philips.com
Message-Id: <35586ED5.112@natlab.research.philips.com>
Date: Tue, 12 May 1998 17:46:29 +0200
From: Warner ten Kate <tenkate@natlab.research.philips.com>
Organization: Philips Research Laboratories
X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/735)
Mime-Version: 1.0
To: Philipp Hoschka <Philipp.Hoschka@sophia.inria.fr>
Cc: symm@w3.org
Subject: Re: draft - minor issues
References: <199805121521.RAA27639@www45.inria.fr>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Length: 3273

> >3a.
> >"....The clock may either give presentation time elapsed
> >since the effective begin, or it may give the media time
> >of the object."
> >
> >I thought it is essentially ONLY the latter (thus: remove
> >first part).
> >Implementations may let it be effectively the same.
> 
> It would be great if this was what current implementations did.
> 
> Unfortunately, it appears that plug-ins usually do not export
> the current "timestamp" as an event.
> 
> Therefore, neither CWI nor HPAS implement synchronization
> with media time. They both use the time elapsed since the
> effective begin.
> 
> So, implementation experience suggests that to rather drop
> synchronization with media time, than using the time elapsed
> since the effective begin :-)
> 
> The evidence we currently have is that SMIL implementations
> will exhibit "elapsed time" behaviour for a long time, so it's
> better to allow this in the standard, rather than confusing users
> with implementations that are non-compliant since SMIL makes
> non-realistic demands on synchronization accuracy.
> 

Then I still am in favor not to specify this, but find another 
escape for current practice.

What about something like (wording is not correct, but sufficient
to indicate the idea):
"implementations may let the media time be effectively the
same as presentation time, or use presentation time to estimate
media time."

In this way it is not part of the SMIL format specification,
such that we keep the concept formally clean,
while we allow vendors or other providers of player implementations 
to do what they think best (or can do).

Letting plug-ins to control our format specification doesn't 
sound as an attractive road to me.



> >
> >3b.
> >"It is an error .... greater than the effective duration of
> >the element generating the event."
> >
> >Should be "...the effective end..." (clock of element has
> >stopped continueing at the effective end), I would say.
> 
> The legal range of values that can occur in a "clock-val" value
> is determined by the effective duration of an object, not by
> the effective end of the object.
> 
> Consider the following example:
> 
> <seq>
>   <text dur="10s" .../>
>   <par>
>     <video id="v" ... /> <!-- 10s video -->
>     <img begin="id(v)(**)" ... />
>   </par>
> </seq>
> 
> The effective end of video v is 20s.
> 
> However, valid values that can occur in position ** are 0 to 10s (or any
> other syntax to express the same time-range) - 20s is not a valid value.

We misunderstand each other somewhere. I agree on your
conclusion that ** should be in 0-10 range. I thought 
effective end indicates the 10.

To me, 'effective duration' doesn't indicate a time *instance*.
You may wish to reword to 'effective begin + effective
duration', which is by definition 'effective end'.

- --

I am not sure if effective end indeed refers to the time 
instance I am thinking of. For example, consider the 
following case:

<par>
  <video id="v" end="10" dur="15" fill="freeze"/>
  <img begin="id(v)(**)" ... />
</par>

Now, in my opinion, ** is in 0-10, and may not be in 10-15:
The mediaclock of "v" has stopped 'ticking' at 10s.

(I assume intrinsic durations is of sufficient length, but 
that may also influence the allowed range. Etc.)


Warner.

------- End of Forwarded Message

Received on Sunday, 7 June 1998 05:11:21 UTC