SMIL content for specific calendar time ranges

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SMIL content for specific calendar time ranges

Sanja C.
Hi,

we're considering a SMIL-based solution for stand-alone multimedia-presentations (i.e. digital signage) in our organisation, but are not sure how well it fits our needs with regards to integrating calendar time range specific content into the "normal flow" of a seq/par-driven presentation.

We'd be very grateful if some more SMIL-experienced people would comment on the following two scenarios:

__Scenario 1:__

Consider a presentation of the following form that continually loops through a number of multimedia pages:

<seq repeatCount="indefinite">
    <ref title="Page 1"/>
    <par>
        <ref title="Page 2"/>
        <ref title="specialOverlay"/>
    </par>
    <ref title="Page 3"/>
    <ref title="Page 4"/>
    ...
</seq>

Now, is it possible to add SMIL markup to this presentation that will enforce the following constraints, respectively:

   example A)  Only show the "specialOverlay" on [Sunday, 30. Mai 2010, 9am - 18am] (or any other specific calendar time range)
   example B)  Only show the "specialOverlay" on [Sunday, between 9am - 18am] (meaning: *every* sunday)
   example C)  Only show the "specialOverlay" on holidays (where the data about which days are holidays is supplied through an external file)

..without otherwise affecting the behaviour of the seq element?

__Scenario 2:__

Consider again a presentation continually looping through a fixed set of pages:

<seq repeatCount="indefinite">
    <ref title="Page 1"/>
    <ref title="Page 2"/>
    <ref title="Page 3"/>
    ...
</seq>

Imagine this presentation will run around-the-clock, all year long.
Now, is it possible to specify an alternative <seq></seq> section for a specific calendar time range so that at the beginning of this time range, the normal seq presentation is halted (no matter what it's currently showing), and the alternative <seq></seq> is shown, until the end of the time range, when the normal presentation is resumed? (Note: it would also be acceptable if the original presentation would then re-start at its beginning, instead of resuming exactly where it had left off.)

Is this kind of stuff possible with SMIL 3.0 markup?

Note that we *don't* want to use scripting, just XML-based markup (if this is not possible with plain SMIL, we'd rather develop a custom non-SMIL-based solution altogether, or our own SMIL-extension, or a "wrapper" that calls/terminates different SMIL presentation at different times).

We appreciate any help/advice!

Reply | Threaded
Open this post in threaded view
|

Re:

Jack Jansen
 
On 27 mei 2010, at 20:14, Sanja C. wrote:

> Hi,
>
> we're considering a SMIL-based solution for stand-alone multimedia-presentations (i.e. digital signage) in our organisation, but are not sure how well it fits our needs with regards to integrating calendar time range specific content into the "normal flow" of a seq/par-driven presentation.
>
> We'd be very grateful if some more SMIL-experienced people would comment on the following two scenarios:
>
> __Scenario 1:__
>
> Consider a presentation of the following form that continually loops through a number of multimedia pages:
>
> <seq repeatCount="indefinite">
>     <ref title="Page 1"/>
>     <par>
>         <ref title="Page 2"/>
>         <ref title="specialOverlay"/>
>     </par>
>     <ref title="Page 3"/>
>     <ref title="Page 4"/>
>     ...
> </seq>
>
> Now, is it possible to add SMIL markup to this presentation that will enforce the following constraints, respectively:
>
>    example A)  Only show the "specialOverlay" on [Sunday, 30. Mai 2010, 9am - 18am] (or any other specific calendar time range)
>    example B)  Only show the "specialOverlay" on [Sunday, between 9am - 18am] (meaning: *every* sunday)
>    example C)  Only show the "specialOverlay" on holidays (where the data about which days are holidays is supplied through an external file)
>
> ..without otherwise affecting the behaviour of the seq element?

Sanja,
the short answer is that this is not directly possible with SMIL 3.0. Wallclock timing (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-WallclockSyncValueSyntax) allows you to specify a single time, a single date or a single date+time. Unfortunately things like "every sunday" are not expressible.

The slightly longer answer is that it is possible by using a tiny external agent (or script). SMIL State (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-state.html) was specifically designed with this use in mind (among other things): the whole SMIL presentation is declarative, with some parts based on SMIL State variable(s). This variable is then changed by the external agent.

Your SMIL document would look something like this:
...
 <head>
  <state xmlns="">
   <data>
    <showSpecialOverlay>0</showSpecialOverlay>
   </data>
  </state>
 </head>
 ...
  <par>
   <ref title="Page 2"/>
   <ref expr="showSpecialOverlay"  title="specialOverlay"/>
  </par>
...

Now, specialOverlay will only be shown if, at the time it is eligible to play, the showSpecialOverlay variable is true. So, you would supply a script that sets/clears this variable depending on the date/time. Or you could make it depend on anything else you want (think: attach a camera with face recognition to your billboard and count the number of people watching it, to name something completely different:-).

You could also do things even more declarative, by having the script only filling in relevant parts of date and time, for example every hour, in a data structure like
  <state xmlns="">
    <data>
      <year/>
      <month/>
      <day/>
      <weekday/>
      <hour/>
    </data>
  </state>
your example B could now be coded as
   <ref expr="weekday=7 and hour &gt; 9 and hour &lt; 18" title="specialOverlay"/>

Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.

>
> __Scenario 2:__
>
> Consider again a presentation continually looping through a fixed set of pages:
>
> <seq repeatCount="indefinite">
>     <ref title="Page 1"/>
>     <ref title="Page 2"/>
>     <ref title="Page 3"/>
>     ...
> </seq>
>
> Imagine this presentation will run around-the-clock, all year long.
> Now, is it possible to specify an alternative <seq></seq> section for a specific calendar time range so that at the beginning of this time range, the normal seq presentation is halted (no matter what it's currently showing), and the alternative <seq></seq> is shown, until the end of the time range, when the normal presentation is resumed? (Note: it would also be acceptable if the original presentation would then re-start at its beginning, instead of resuming exactly where it had left off.)

This is easier, assuming single datetime begin and end points:

  <excl>
    <seq begin="0;wallclock(20100605T1800)" repeatCount="indefinite">... normal seq... </seq>
    <seq begin="wallclock(20100605T0900)" repeatCount="indefinite">...special seq...</seq>
  </excl>

This will play the normal sequence, repeatedly, except from 9AM to 6 PM on June 5th, 2010, when it plays the special sequence.
 
> Is this kind of stuff possible with SMIL 3.0 markup?
>
> Note that we *don't* want to use scripting, just XML-based markup (if this is not possible with plain SMIL, we'd rather develop a custom non-SMIL-based solution altogether, or our own SMIL-extension, or a "wrapper" that calls/terminates different SMIL presentation at different times).

If you decide on extending SMIL I would be more than happy to provide you with some ideas, the use case for richer specification of wallclock time constraints should be common for digital signage, and I think that it is an important area for SMIL. If you have the time (and inclination) to do this extension in a way that would ease possible integration into a next version of SMIL (if ever there is going to be one) that would be a boon!
--
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

RE:

Herlein Greg
PRN uses SMIL for our playlists on our newer generation digital signage systems.  We found that wallclock within the SMIL playlist was not suitable, partly since we wanted to essentially schedule playlists and not have to a) send wholly rebuilt playlists, or b) have to parse a large playlist just to get to a portion that applied to a certain day part, and c) we wanted to be able to replace portions of playlists scheduled independently.  We designed a schedule mechanism using XML that is SMIL-like but is not SMIL and use that to meet the discrete needs of digital signage.  We've share that publically with the POPAI Digital Signage Technical Standards group.  Sanja, contact me directly from your company and I'll see if we can work out a way to share it with you.

-- -- -- -- -- -- -- -- -- --
Greg Herlein |  Sr. Director, Engineering - Advanced Development Group
415 808 9753 direct   |  415 368 7546 mobile
600 Harrison St., 4th Floor, San Francisco CA 94107

Tomorrow's Network for Today's Shopper

http://www.prn.com

Think Green- please do not print this email unless necessary

This e-mail (including any attachments) is meant for only the intended recipient of the transmission, and may include confidential information. If you are not the intended recipient or you received this e-mail in error, any review, use, dissemination, distribution, or copying of this e-mail is strictly prohibited.  If you have received this message in error, please notify the sender immediately by telephone at (415) 808-3500 or by return e-mail and delete this e-mail, along with any attachments and copies, from your system.  Thank you.


 


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jack Jansen
Sent: Thursday, May 27, 2010 3:25 PM
To: Sanja C.
Cc: [hidden email]
Subject: Re:


 
On 27 mei 2010, at 20:14, Sanja C. wrote:

> Hi,
>
> we're considering a SMIL-based solution for stand-alone multimedia-presentations (i.e. digital signage) in our organisation, but are not sure how well it fits our needs with regards to integrating calendar time range specific content into the "normal flow" of a seq/par-driven presentation.
>
> We'd be very grateful if some more SMIL-experienced people would comment on the following two scenarios:
>
> __Scenario 1:__
>
> Consider a presentation of the following form that continually loops through a number of multimedia pages:
>
> <seq repeatCount="indefinite">
>     <ref title="Page 1"/>
>     <par>
>         <ref title="Page 2"/>
>         <ref title="specialOverlay"/>
>     </par>
>     <ref title="Page 3"/>
>     <ref title="Page 4"/>
>     ...
> </seq>
>
> Now, is it possible to add SMIL markup to this presentation that will enforce the following constraints, respectively:
>
>    example A)  Only show the "specialOverlay" on [Sunday, 30. Mai 2010, 9am - 18am] (or any other specific calendar time range)
>    example B)  Only show the "specialOverlay" on [Sunday, between 9am - 18am] (meaning: *every* sunday)
>    example C)  Only show the "specialOverlay" on holidays (where the data about which days are holidays is supplied through an external file)
>
> ..without otherwise affecting the behaviour of the seq element?

Sanja,
the short answer is that this is not directly possible with SMIL 3.0. Wallclock timing (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-timing.html#Timing-WallclockSyncValueSyntax) allows you to specify a single time, a single date or a single date+time. Unfortunately things like "every sunday" are not expressible.

The slightly longer answer is that it is possible by using a tiny external agent (or script). SMIL State (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-state.html) was specifically designed with this use in mind (among other things): the whole SMIL presentation is declarative, with some parts based on SMIL State variable(s). This variable is then changed by the external agent.

Your SMIL document would look something like this:
...
 <head>
  <state xmlns="">
   <data>
    <showSpecialOverlay>0</showSpecialOverlay>
   </data>
  </state>
 </head>
 ...
  <par>
   <ref title="Page 2"/>
   <ref expr="showSpecialOverlay"  title="specialOverlay"/>
  </par>
...

Now, specialOverlay will only be shown if, at the time it is eligible to play, the showSpecialOverlay variable is true. So, you would supply a script that sets/clears this variable depending on the date/time. Or you could make it depend on anything else you want (think: attach a camera with face recognition to your billboard and count the number of people watching it, to name something completely different:-).

You could also do things even more declarative, by having the script only filling in relevant parts of date and time, for example every hour, in a data structure like
  <state xmlns="">
    <data>
      <year/>
      <month/>
      <day/>
      <weekday/>
      <hour/>
    </data>
  </state>
your example B could now be coded as
   <ref expr="weekday=7 and hour &gt; 9 and hour &lt; 18" title="specialOverlay"/>

Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.

>
> __Scenario 2:__
>
> Consider again a presentation continually looping through a fixed set of pages:
>
> <seq repeatCount="indefinite">
>     <ref title="Page 1"/>
>     <ref title="Page 2"/>
>     <ref title="Page 3"/>
>     ...
> </seq>
>
> Imagine this presentation will run around-the-clock, all year long.
> Now, is it possible to specify an alternative <seq></seq> section for a specific calendar time range so that at the beginning of this time range, the normal seq presentation is halted (no matter what it's currently showing), and the alternative <seq></seq> is shown, until the end of the time range, when the normal presentation is resumed? (Note: it would also be acceptable if the original presentation would then re-start at its beginning, instead of resuming exactly where it had left off.)

This is easier, assuming single datetime begin and end points:

  <excl>
    <seq begin="0;wallclock(20100605T1800)" repeatCount="indefinite">... normal seq... </seq>
    <seq begin="wallclock(20100605T0900)" repeatCount="indefinite">...special seq...</seq>
  </excl>

This will play the normal sequence, repeatedly, except from 9AM to 6 PM on June 5th, 2010, when it plays the special sequence.
 
> Is this kind of stuff possible with SMIL 3.0 markup?
>
> Note that we *don't* want to use scripting, just XML-based markup (if this is not possible with plain SMIL, we'd rather develop a custom non-SMIL-based solution altogether, or our own SMIL-extension, or a "wrapper" that calls/terminates different SMIL presentation at different times).

If you decide on extending SMIL I would be more than happy to provide you with some ideas, the use case for richer specification of wallclock time constraints should be common for digital signage, and I think that it is an important area for SMIL. If you have the time (and inclination) to do this extension in a way that would ease possible integration into a next version of SMIL (if ever there is going to be one) that would be a boon!
--
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: RE:

Jack Jansen

On 28 mei 2010, at 01:44, Herlein Greg wrote:

> PRN uses SMIL for our playlists on our newer generation digital signage systems.  We found that wallclock within the SMIL playlist was not suitable, partly since we wanted to essentially schedule playlists and not have to a) send wholly rebuilt playlists, or b) have to parse a large playlist just to get to a portion that applied to a certain day part, and c) we wanted to be able to replace portions of playlists scheduled independently.  We designed a schedule mechanism using XML that is SMIL-like but is not SMIL and use that to meet the discrete needs of digital signage.  We've share that publically with the POPAI Digital Signage Technical Standards group.  Sanja, contact me directly from your company and I'll see if we can work out a way to share it with you.


Is this available publicly? All the links I can find seem to be either dead or leading nowhere...
--
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: SMIL content for specific calendar time ranges

Sanja C.
In reply to this post by Sanja C.
Hi Jack,

thank you for your reply.

> The slightly longer answer is that it is possible by using a tiny external agent (or script). SMIL State (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-state.html) was specifically designed with this use in mind (among other things): the whole SMIL presentation is declarative, with some parts based on SMIL State variable(s). This variable is then changed by the external agent.
> [...]
>  <state xmlns="">
>    <data>
>      <year/>
>      <month/>
>      <day/>
>      <weekday/>
>      <hour/>
>    </data>
>  </state>
> your example B could now be coded as
>   <ref expr="weekday=7 and hour &gt; 9 and hour &lt; 18" title="specialOverlay"/>

This does indeed look very promising, I like the flexibility it would imply regarding all kinds of complex states we might like to add in the future (which for example a custom SMIL extension for recurring wallclock event timing would not give us). Together with the basic SMIL 3.0 Tiny stuff (and possibly BasicTransition) this might just be all we need.

What I can't gather from the SMIL State w3c recommendation, however, is:

1) What kind of source file does the "source" attribute of the "state" element expect? Is this completely unspecified/client-specific?

2) Does any standardization (official or inofficial) exist regarding how external agents change state variables of a running SMIL presentation? (e.g. a SOAP schema or something for communication between the player and the external agent over HTTP or other means). How do implementations like GRiNS/ambulant handle this?

3) When exacly is the expression in the "expr" attribute of an element evaluated (and acted upon)? Only when the element is about to be shown, or is the expression also recalculated on each state change event? I.e. in the following example, will the Happy hour page not only appear when "happyHour" becomes true, but also disappear once it becomes false again?
<excl duration="indefinite">
    <seq title="Normal presentation" begin="0" repeatCount="indefinite"> ... </seq>
    <ref title="Happy hour page" expr="happyHour"/>
</excl>

> [...]
> Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.

Yes, I'm definitely interested :-)


Greg,

On Fri, May 28, 2010 at 1:44 AM, Herlein Greg <[hidden email]> wrote:
> PRN uses SMIL for our playlists on our newer generation digital signage systems.  We found that wallclock within the SMIL playlist was not suitable, partly since we wanted to essentially schedule playlists and not have to a) send wholly rebuilt playlists, or b) have to parse a large playlist just to get to a portion that applied to a certain day part, and c) we wanted to be able to replace portions of playlists scheduled independently.  We designed a schedule mechanism using XML that is SMIL-like but is not SMIL and use that to meet the discrete needs of digital signage.  We've share that publically with the POPAI Digital Signage Technical Standards group.  Sanja, contact me directly from your company and I'll see if we can work out a way to share it with you.

I've stumbled upon http://www.a-smil.org/index.php/Wallclock in the meantime, describing simple "Repeated Date/Time Events" wallclock scheduling for SMIL, specifically intended for digital signage, by allowing "R/.../.." specifiers in wallclock time values. Is your solution also along those lines?

While this kind of extension/modification to SMIL would provide support for the case of weekly or similarly scheduled items, the State mechanism as pointed out by Jack appears to be a much more flexible and probably also cleaner solution at least for our purposes, with the added benefit of being officially SMIL compliant, so I'd like to try and pursue that path first. If it doesn't work out, I might get back to you though.





Reply | Threaded
Open this post in threaded view
|

Re: SMIL content for specific calendar time ranges

Jack Jansen

On 28 mei 2010, at 16:21, Sanja C. wrote:

> Hi Jack,
>
> thank you for your reply.
>
>> The slightly longer answer is that it is possible by using a tiny external agent (or script). SMIL State (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-state.html) was specifically designed with this use in mind (among other things): the whole SMIL presentation is declarative, with some parts based on SMIL State variable(s). This variable is then changed by the external agent.
>> [...]
>> <state xmlns="">
>>   <data>
>>     <year/>
>>     <month/>
>>     <day/>
>>     <weekday/>
>>     <hour/>
>>   </data>
>> </state>
>> your example B could now be coded as
>>  <ref expr="weekday=7 and hour &gt; 9 and hour &lt; 18" title="specialOverlay"/>
>
> This does indeed look very promising, I like the flexibility it would imply regarding all kinds of complex states we might like to add in the future (which for example a custom SMIL extension for recurring wallclock event timing would not give us). Together with the basic SMIL 3.0 Tiny stuff (and possibly BasicTransition) this might just be all we need.
>
> What I can't gather from the SMIL State w3c recommendation, however, is:
>
> 1) What kind of source file does the "source" attribute of the "state" element expect? Is this completely unspecified/client-specific?

First thing you should realize is that the SMIL State definition is a two-stage process. The SMIL State chapter sets out general guidelines and defines the elements and attributes and what they should do. How this is then integrated in a language (such as the SMIL 3.0 language) is then defined in the Language Profile.

The SMIL 3.0 Language Profile defines that at least XPath must be allowed as the expression language (but implementations may provide support for other languages too). In <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-profile.html#SMILProfileNS-state-module>, around the sixth paragraph, it also states that serialization (if you use the XPath language) should be done according to what the XForms spec says. And it says "use XML".

But: implementations can extend this, for example by allowing a second language to be used. For example, some versions of the Ambulant SMIL player allow not only XPath and XML to be used as the SMIL State expression language, but also Python. This extension was done purely on the whim of one of the implementors (i.e. me:-), a more logical "second expression language" would be JavaScript. Note that the language used inside the state element (and the external representation) is tied to the expression language: only for XPath as expression language is it defined you must use XML as the data language.
>
> 2) Does any standardization (official or inofficial) exist regarding how external agents change state variables of a running SMIL presentation? (e.g. a SOAP schema or something for communication between the player and the external agent over HTTP or other means). How do implementations like GRiNS/ambulant handle this?

It is not defined, it is considered out of scope for the spec. Ambulant without any extensions does not provide any way for an external agent to change a state variable (although the SMIL presentation itself can get a new collection of state variables through use of the <send> and <submission> elements, but this mechanism is intended more for things like filling out forms).
But Ambulant extensions can do this easily, and we ourselves have used various methods to change state variables inside a running presentation:
- an XMLRPC server implementing set/get/del methods,
- a miniature webserver providing a form with buttons that change state variables,
- internal logic

>
> 3) When exacly is the expression in the "expr" attribute of an element evaluated (and acted upon)? Only when the element is about to be shown, or is the expression also recalculated on each state change event? I.e. in the following example, will the Happy hour page not only appear when "happyHour" becomes true, but also disappear once it becomes false again?
> <excl duration="indefinite">
>    <seq title="Normal presentation" begin="0" repeatCount="indefinite"> ... </seq>
>    <ref title="Happy hour page" expr="happyHour"/>
> </excl>

You caught us there: we overlooked this, and we didn't realise it until the spec was out. The SMIL spec specifically states that the expr attribute is evaluated when the element carrying it becomes active. This is distinct from the {var} construct in an attribute, which is explicitly re-evaluated if it changes during an elements lifetime. In hindsight we should have allowed both interpretations in both situations.

Luckily, there is a workaround that can be often (but not always) be used:
  <ref title="Happy hour page" restart="always" begin="0;xxx.stateChange(happyHour)" expr="happyHour"/>

There is even a method to have this activate/deactivate in sync (for example for switching audio tracks in parallel with a continuous video track) but that is so gross I'll keep it to myself unless someone wants it:-)

>
>> [...]
>> Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.
>
> Yes, I'm definitely interested :-)
>
>
> Greg,
>
> On Fri, May 28, 2010 at 1:44 AM, Herlein Greg <[hidden email]> wrote:
>> PRN uses SMIL for our playlists on our newer generation digital signage systems.  We found that wallclock within the SMIL playlist was not suitable, partly since we wanted to essentially schedule playlists and not have to a) send wholly rebuilt playlists, or b) have to parse a large playlist just to get to a portion that applied to a certain day part, and c) we wanted to be able to replace portions of playlists scheduled independently.  We designed a schedule mechanism using XML that is SMIL-like but is not SMIL and use that to meet the discrete needs of digital signage.  We've share that publically with the POPAI Digital Signage Technical Standards group.  Sanja, contact me directly from your company and I'll see if we can work out a way to share it with you.
>
> I've stumbled upon http://www.a-smil.org/index.php/Wallclock in the meantime, describing simple "Repeated Date/Time Events" wallclock scheduling for SMIL, specifically intended for digital signage, by allowing "R/.../.." specifiers in wallclock time values. Is your solution also along those lines?
>
> While this kind of extension/modification to SMIL would provide support for the case of weekly or similarly scheduled items, the State mechanism as pointed out by Jack appears to be a much more flexible and probably also cleaner solution at least for our purposes, with the added benefit of being officially SMIL compliant, so I'd like to try and pursue that path first. If it doesn't work out, I might get back to you though.
>
>
>
>
>

--
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman




Reply | Threaded
Open this post in threaded view
|

Re: SMIL content for specific calendar time ranges

Jack Jansen
In reply to this post by Sanja C.
Oops, almost missed a chance to evangelize our paper:

On 28 mei 2010, at 16:21, Sanja C. wrote:

>> [...]
>> Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.
>
> Yes, I'm definitely interested :-)


Here is the main reference: <http://portal.acm.org/citation.cfm?id=1410140.1410146>. If you don't have access to the ACM Digital Library: at the demo site there's an authors copy available: <http://homepages.cwi.nl/~jack/NoBudget/>. Please note that the example on the demo site stopped working after a Safari security update last year, and I haven't had a chance to fix it yet:-(

There's also an extended version of the paper published in Multimedia Tools and Applications: <http://dx.doi.org/10.1007/s11042-009-0270-3>, which has a more implementation detail.
--
Jack Jansen, <[hidden email]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman