Video on Demand

Video on Demand is one of the three methods of distributing video content:

  • DownloadPlay, first download something, then play it. Standard BitTorrent + player
  • LiveStreaming, p2p videodistribution where everybody in the swarm is viewing the same content at the same time. Comparable to television channels.
  • VideoOnDemand, comparable to an online movie rental. User decides what to watch and when to watch.

The complication with video on demand is in getting the incentives right.

Multi-bitrate Bittorrent swarms

​Vuze live test content

Code updates

On 25/02/09 a large code update was committed to the Tribler mainbranch with the purpose of improving VOD performance. In order not to loose the general idea behind the changes that were applied at this update we will list them here.

  • Perviously a timestamp was given to each piece that the piece picker selected. This is inefficient for large pieces as the chunk requests for some of the chunks in this piece may be done 'a lot later' instantly expiring them. After the fix a timestamp is stored for each individual chunk request.
  • With the new chunk-based timestamp we cancel individual requests instead of all the outstanding requests for a piece where ONE request expired.
  • Only chunks from the high priority range are examined for timeout/on-time-delivery. Previously all pieces were examined.
  • Each chunk may be canceled if (1.1) is was requested a minimal amount of time ago and (1.2) the data will not arrive on time given number of outstaning chunks and current download speed. Or if may be canceld if (2.1) the request was given a minimal amount of time ado and (2.2) the request has been outstanding more than the maximal amount of time. These minimal and maximal times are configurable and differ during playback and pause/buffering phases.
  • The current download speed (used to estimate if a peer will send data within the deadline) is calculated using a 5 second history on received chunks. Previously this was a 20 second history on received chunks.
  • The ETA to play is now estimated based on a weighted average between (1) download speed of chunks in the high priority range using the 5 second history and (2) overall download speed of any chunk in of the file using the 20 second history. The weight depends on the number of pieces that have been received from the high priority range.
  • The high priority range now depends on either (1) a the amount of data required to play for a minimal amount of time or (2) a minimal number of pieces.
  • The high priority range will grow each time the playback fails and the client is forced to pause for buffering. There is a maximum to the this buffer size given in either amount of time or number of pieces.
  • Connections are given a bad-performance counter that increases each time a high priority chunk fails to download on time and decreases (with a minimal of 0) each time that -any- chunk is downloaded.
  • High priority pieces are only downloaded (piece picker policy) from connections that have a bad-performance counter <= 0.