- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 29 Oct 2008 23:32:27 -0400
- To: cyril.concolato@telecom-paristech.fr
- CC: www-svg@w3.org
Hi, Cyril- Thanks for your comment. Cyril Concolato wrote (on 10/13/08 7:03 AM): > > * Section 12.1.1 Media timeline and document timeline > The specification says that media elements which are loaded only when > they become visible for the fist time may introduce delay. In that case, > what document time corresponds to the beginning of the media timeline ? > The begin value or the begin value + the delay ? The latter. > Is it correct to say > that assuming timelines are locked, then the UA has to adjust playback > to cope with the load time (similarly to a timelineBegin=onStart)? When timelines are locked, it is with regards to synchronization of pacing, not a single absolute timeline. See the SMIL spec for more details. [1] > Replace: > "the value of the 'syncBehavior' attribute are replaced from the default > one ('default', interpreted as 'locked' in that case since the > 'syncBehaviorDefault' is not specified) to 'independent'." > with: > "the value of the 'syncBehavior' attribute are set to 'independent'." > The current wording 'interpreted as locked' is ambiguous. The actual > interpretation of 'default' is implementation specific and the spec > seems to imply that it should be interpreted as locked all the time. Yes, you seem to be correct. [2] This would ideally be specified more definitively, but that's up to SMIL. I have removed the offending passage. > Could you clarify what the exact locking behavior is ? If a media > timeline is locked to the document timeline and if the video is paused, > what happens ? Is the document timeline locked? This is defined in SMIL [1], but the short answer seems to be that pausing the media (or more precisely, the media time container) is independent of the document timeline (which is the master time container). Media that has been paused and then restarted will sync with the pace of the document, not the elapsed time. > The xlink:href of audio and video says: > "When the value of the attribute is animated or otherwise modified, if > the media play time can be controlled, then the media timeline is > restarted. " > First, the term 'play time' is not defined. I suggest changing "media > play time" to "media timeline". Yes, thanks, we've changed all instances to match your suggestion. > But if the media timeline is locked, > changing the xlink:href to a new value, without changing the begin > value, will not restart the media timeline (or it will restart it but at > time = the document time when the change happened). What happens if the > media timeline cannot be controlled? I have added wording to address when the media timeline cannot be controlled. > The specification should say what happens when a video/audio element > points to a file or a set of streams containing multiple audio tracks > (english and french, or AAC and AC3) or multiple video tracks. That's a good suggestion, and if this is not already covered by SMIL, we will define this behavior in SVG 2.0 Core. For now, this will have to be implementation-specific, and we will look at implementations to inform how we specify it later. Please let us know as soon as possible if these corrections and clarifications satisfy your comments. [1] http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#adef-syncBehavior [2] http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#adef-syncBehaviorDefault Regards- -Doug
Received on Thursday, 30 October 2008 03:32:39 UTC