- From: John Navil Joseph <navil@emuzed.com>
- Date: Tue, 27 Jul 2004 19:17:41 +0530
- To: "Sjoerd Mullender" <sjoerd@acm.org>
- Cc: www-smil@w3.org
Hi, Thanks a lot for helping me out with that one. I have one more similar problem, and I am not able to find out in the spec. where the exact behaviour is documented. Consider the following case in which negative offsets are applied to time container elements. <par begin="-40s"> <video id="video1" src="video1.mp4" repeatCount="10" /> </par> As per the specifications, playback should start from 40s into the active duration of "video1". If the Simple Duration of "video1" is not yet resolved, then how do I know which iteration of "video1" will have to be played next, and how much to seek into "video1"? Or, worse still the entire 10 iterations may have been over with in 40s, and nothing may have to be played. But this will not be known to me until Simple Duration of "video1" is resolved, which is possible only by playing the video atleast once. But if I do that, doesnt it change the synchronization behaviour that was intended by the author? I hope the question is clear, :) TIA, John On Fri, 23 Jul 2004 08:49:44 +0200, Sjoerd Mullender <sjoerd@acm.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > John Navil Joseph wrote: > | > | Hi, > | > | SMIL 2.0 supports fractional repeat counts (ex. repeatCount = "0.75"). > | > | Consider the following example. > | > | ... > | <video src="video1.mpg4" region="Region1" repeatCount="0.75" /> > | ... > | > | I suppose that the standard assumes that the intrinsic duration of > | "video1.mpg4" > | is available beforehand for this to work correctly. But on small hand > | held embedded > | devices it may be very expensive to calculate the exact intrinsic > | duration of the > | streams. (especially for elementary streams as that of MPEG4, AAC). > | > | How does the standard expect the SMIL players to deal with these > | situations in which > | the intrinsic duration of the media objects is simply "unknown"? > > I quote from the standard, take special note of the last sentence: > > "When repeatCount is specified, it is understood to represent a count of > iterations of simple duration. Each iteration of the simple duration may > be different, and so a simple multiplication of the repeatCount and a > given simple duration may not yield an accurate active duration. In the > case of a partial repeatCount and a simple duration that is not > resolved, the most recent simple duration should be multiplied by the > fractional part of the repeatCount to constrain the last simple > duration. If the last iteration of the simple duration otherwise ends > before this time, the repeatCount should be considered to be complete. > If a repeatCount is less than 1 and the simple duration is unresolved, > the repeatCount cannot be correctly respected, and will behave as though > a repeatCount of "1" were specified." > > In other words, in this case the repeatCount is effectively ignored. > > You can find this at > http://www.w3.org/TR/smil20/smil-timing.html#Timing-RepeatCountAndUnresolvedSimpleDur > > - -- > Sjoerd Mullender <sjoerd@acm.org> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iQCVAwUBQQC1Bz7g04AjvIQpAQHB9QQAlK6PzED3r/2s2S7oP78YDSnGYHaAxepE > IU9cAZZIeFFtwT2RF5hX8XmdmSj5VgoXFEIi6WGiu6FE9DAsEx6njIPapi55/vbd > e176W23FS98zfjdLxFoOoAZxbCWYmfDYCIM39EBof1KmfkdPmEN5ZSX+eh019uQL > k2EiQJ/5wp0= > =qjvm > -----END PGP SIGNATURE----- > -- John Navil Joseph Software Engineer, Systems eMuzed India Pvt Ltd. e-mail : navil@emuzed.com navil@mm.st Tel : +91 80 5252224 Ext : 504 Fax : +91 80 5203257 Mobile : +91 9845454524
Received on Tuesday, 27 July 2004 09:43:48 UTC