Re: [1.2T-LC] Comments on Last Call WD of SVG T1.2 (ISSUE-2145)

Hi, Cyril-

(Note: Cyril sent this to me offlist, so I'm including www-svg for the
public record.)

As a high-level comment, I'll just note that you and I have slightly
different interpretations of the SMIL spec, but that you're probably
right.  However, as you note, the SMIL spec is clear enough where the
SVG spec is a little vague; as you acknowledge below, this is sufficient
for the SVG 1.2 Tiny spec, but we should revisit and clarify it for SVG
2.0 Core.  We should bring the SYMM WG into the larger discussion.

Comment inline...

Cyril Concolato wrote (on 11/3/08 5:35 AM):
> Hi Doug,
>
> Doug Schepers a écrit :
>> 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.
>
> I would have expected the former to be consistent with the behavior of
> media and 'timelineBegin' which says:
> "In that case, the beginning of the actual playback of the media will be
> delayed, but the media begin time in the document timeline will remain
> as specified. " That is why I thought that the UA had to adjust the
> playback.

I can see both readings, but I'm not religious about this point.


>>> 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]
>
> I don't understand what you mean by "synchronization of pacing". The
> terms 'pace' or 'pacing' are not used in the SMIL spec you reference. It
> is my understanding that when timelines are locked it is as if there was
> a single timeline. See the following quote from the SMIL spec:
> "the syncBehavior attribute controls whether the media element can slip
> while the rest of the document continues to play, or whether the time
> container must also wait until the media delivery catches up."
> 
> On this problem, the SVG spec is not wrong, it is just unclear but the
> SMIL spec is actually clear, so I can live with the SVG spec as is.

Ok, cool.


>>> 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.
>
> Thank you.

Yup.


>>> 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?
>
> I meant here "Is the document timeline paused?", not locked. But I think
> you understood me.

Yup.


>> 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.
>
> This is not my interpretation of the SMIL spec you point. If you look at
> the 'speech' example. It says that if either the audio or video element
> is paused, then the entire 'speech' (i.e. the entire 'par' time
> container, similar to the 'svg' time container) is paused.
> Again, the SVG Spec is not wrong. I can live with it as is.

Ok.


>>> 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.
>
> Thanks.

No problem.


>>> 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.
> 
> Here we have 2 main options:
> A) the media time line cannot be controlled (broadcast)
> B) the media time line can be controlled
> For A), there is nothing we can do. If you change the xlink:href from,
> say Broadcast Channel 1 to Broadcast Channel 2, you get the media time
> that's being broadcasted.
> For B), there are 2 sub-options:
>  B.1) the media time line is locked to the document time line
>  B.2) the media time line is independent from the document time line
> 
> In B.1), you can compute the media time as the difference between the
> current document time and the begin time. So changing the xlink:href
> cannot have an effect on the media time and this is a good thing. I
> think we can illustrate this on the problem of keeping synchronization
> upon stream switching
> Example:
> At document time = X,
>  <animation syncBehavior="locked" begin="0" xlink:href="subtitle_fr.svg"/>
> At document time = X + 10, you change xlink:href to subtitle_en.svg,
> your internal document is equivalent to:
>  <animation syncBehavior="locked" begin="0" xlink:href="subtitle_en.svg"/>
> At document time = X + 20, you revert to subtitle_fr.svg, your internal
> document is equivalent to:
>  <animation syncBehavior="locked" begin="0" xlink:href="subtitle_fr.svg"/>
> 
> You don't want the subtitle to restart from 0 each time you change the
> xlink:href because this would loose the synchronization. You cannot do
> it via scripting (with only one animation element) because SVG does not
> have an API to query the media time of a timed element.
> In B.2), indeed the media time line needs to be restarted.
> 
> Concerning your editing, I don't understand the added wording:
> "If the media timeline cannot be controlled, then it will continue from
> the first available time."
> Given the additional comments above, I think you'd better say:
> "When the value of this attribute is animated or otherwise modified, if
> the media timeline can be controlled, then the media timeline is
> restarted *only if the syncBehavior attribute is set to 'independent'*.
> If the media timeline cannot be controlled, then the media timeline is
> unaffected by such modification."

That is a sensible argument, and I agree that your wording is better
than mine.  I have made this change, as requested.


>>> 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.
>
> That's fine.

Cool.

Since you've stated that you can live with the spec as it is, modulo the
change you've requested above (which I've made), I am going to close
this issue, and indicate your satisfaction in our Disposition of
Comments.  Please let us know if this doesn't work for you.

Note that I agree we should reopen this issue for further clarification
in the near future.  Thanks for all your insightful analysis.

Regards-
-Doug

Received on Monday, 3 November 2008 18:08:48 UTC