---

Interactive Video on Demand

---

• Interactive Video on Demand aim to
  • Provide "VCR-like" functions to the set top box

• Imagine a cable set top box that:
  • Allows you to make requests on videos that you like to see (and which will start within a reasonable short time)

    (That was Video on Demand)

  • Allows you to pause the video while watching it (useful when you need to go or get a beer :-))

  • Allows you to fastforward the video (useful when you want to skip the intro :-))

  • Allows you to rewind the video (useful when you want to replays)

  What we will get is live TIVO (really TV your way !)

• Reading material source:
  • On the Use of Multicast Delivery to Provide a Scalable and Interactive Video-on-Demand Service, click here
  • by: K. Almeroth and M.H. Ammar

• This paper assumes the following service model:

  

  • Time is divided into slot and video will only start at the slot boundaries

  • The first request made will cause the video server to schedule the video object to be broadcast on an available channel

    The user will be notified on the channel used (this control signal is sent from the video server back to the set top box on the control channel click here )

  • Subsequent requests for the same video object will be informed about the channel information (but no new transmissions will be scheduled)

  • Receiver subscribes to ONE video channel at a time (it can switch channels, but must leave its current channel and then join a new channel)

  • Receivers subscribes to the SAME video channel form a "viewing (multicast) group"

• The Almoroth & Ammar paper focuses on how to provide the following functions to Video on Demand:
  • Pause
  • Fastforward
  • Rewind

  The paper also distinguishes:

  • Continuous operations: pause, fastforward and rewind that is "smooth"
  • Discrete operations: pause, fastforward and rewind that is "skippy" (e.g., pause will make the video pause 1 min, FF will make the video move forward 1 min, etc)

  I will discuss the continuous operations only, you can read on the discrete operations in the paper....

• Receiver's (disk) buffer organization in Interactive VoD:

  

  • Receiver must maintain a portion of previously playout video (``past video'') in buffer (to implement the rewind function)

  • Receiver always maintains a (small portion) of ``future video'' to compensate for ``jitter'' (see: click here )

    The ``future video'' could also be accumulated during a pause operation (see below)

• Pausing:
  • If pausing if followed by turning the TV set off, then it is "trivial" to implement :-)

  • The main problem that arises in pausing are:
    1. Because the sender is serving multiple receivers, the pause operation cannot be implemented by pausing the sender (it will cause everyone in the same "viewing group" to be paused - not very practical)

    2. Therefore: while the receiver is paused, the sender will still be transmitting....

       

    3. As a result, "future video" will accumulate in the paused receiver and sooner or later, the receiver buffer will become full...

  • Solution:
    • Let T_Stream be the time between two multicast streams

    • If the paused operation has been going on for longer that T_Stream seconds, try to switch the paused receiver to a later video stream:

      

    • Notice that a video stream that starts later is showing a scene before the scene in the current stream.

• Rewinding:
  • The receiver must maintain a (small) amount of "past video" to implement the rewind operation

  • Initially, the rewinding operation will be processed by moving the playout pointer into the "past video" area:

    

    Notice that the rewind operation increases the amount of data behind the playout pointer - just like the pause operation.

  • If the rewinding operation causes the amount of data behind the playout pointer to become greater than T_Stream seconds, the receiver can be moved to a later video stream:

    

  • If the rewinding operation rewinds to a location before the stored "past video", the receiver can no longer support continuous rewind.

    The receiver can still support a discrete rewind operation by switching the receiver to a later video stream:

    

• Fastforward:
  • Operation is similar to rewind....

  • Initially, the receiver uses the "future video" to support fast forward

  • The "future video" can be accumulated from a previous pause or rewind operation (see above), or if no pause or rewind was performed, there is a small amount of "future video" accumulated by the jitter prevention mechanism (See: click here )

  • When the fast forward operation advances the video to a location beyond the accumulated "future video", the system can then no longer support continuous fast forward.

  • But the system can still support a discrete fast forward by switching the receiver to an earlier video stream.