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

Hi Doug,

I am satisfied with the changes you made and I think this was my last comment. I'm done. Thanks.

Cyril

Doug Schepers a écrit :
> 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
> 


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat

Received on Tuesday, 4 November 2008 07:52:09 UTC