The sequential playlist is the simplest form of playlists in SMIL. In a sequential playlist, media objects are played in the order they are listed in the SMIL file. One media object starts playing after the one ends.
Another great feature of SMIL is the option to nest container.
You can find a simple seq samples to study here, here, and here
The SMIL parallel playlist is a list of media objects that start playback simultaneously. Illustration of using the parallel playlist for multi-zone effects are located in the section on Layout. Children of the parallel playlist can be specified to start at a specific time defined by the player's real-time clock. See section on trigger for details.
The parallel schedule has two children: a sequential playlist containing 3 images, and a single audio media object. The sequential playlist and the audio object start simultaneously, like a slide show, while music plays in the background.
You can find a real world with a simple multiple screen layout par samples to study here
This is the most interesting, but also most complicated container. It allows only one of its children to play at the same time. The start of one media object causes the currently playing item to either pause or stop. The priorityClass tag further defines interrupt priorities and behavior (pause, defer, never, or stop) of media objects when interrupts occur. The starting of a media object may be triggered by an event such as a key press, mouse click, touch, or a time, as the following sample code illustrates.
The peer-attribute describes the interrupt behavior of the priorityClass children.
Stop means, that a higher element stops the lower element.
The attribute begin will be discussed during lesson trigger in more detail. You need to image a timeline. It starts on 0s with image 1 which should play 10s. But it will be interrupted by 001 after 1s because 1 has a higher priority in the priority class.
You can skip the priorityClass-tags if you use only one priority. If you have two priorities, it is necessary to use the priorityClass two times; otherwise this is an error. As the default behavior for peer is stop, we get the same results as above.
A more complex real world excl sample to study the peer stop behavior
Pause causes a higher element to pause the lower element. The paused element enters a waiting queue. After the higher element is finished, the lower element plays again for the remaining time of his duration.
This timeline starts on 0s with image 001 and will again be interrupted by 001 after 1s because 1 has a higher priority in the priority class. But because we set pause as peer after the end of 002 it jumps back to 002 and play for rest time of 9s.
Defer describes what happened when a lower element tries to interrupt a higher element. In this case, the lower element will take place in a waiting queue until the higher element finished.
This timeline starts on 0s with image 001 and after one second image 002 try to start. But as image 002 has a lower priority, it will enter in wait state. Nine seconds later when 001 is finished 002 starts to display for two seconds.
The attribute lower describe, what happened when an item of an element from a lower priorityClass try to interrupt a higher priority.
There are two options: defer (default) and never.
This is also similar to the defer behavior in peer. Image 1 starts, 3 attempts to interrupt, bus as in lower priority it moves to a waiting queue and starts player after the finish of image 2. The higher priority has a duration of 12 seconds.