A Scalable and Reliable Paradigm for Media on Demand. Horn, G., Knudsgaard, P., Lassen, S., Luby, M., & Rasmussen, J. IEEE Computer, 34(9):40-45, September, 2001.
@article{ Horn01,
  author = {G. Horn and P. Knudsgaard and S. Lassen and M. Luby and J. Rasmussen},
  title = {A Scalable and Reliable Paradigm for Media on Demand},
  journal = {IEEE Computer},
  year = {2001},
  volume = {34},
  number = {9},
  pages = {40-45},
  month = {September},
  annote = {In this article, Gavin B. Horn and his colleagues address the problems faced when buildning a media-on-demand (MoD) system for live streaming. They present a survey over existing MoD strategies including user-centered MoD schemes and data-centered MoD schemes. Especially data-centered schemes are discussed. In particular, the principles for the data-centered MoD schemes pyramid broadcasting and harmonic broadcasting are presented. However, the emphasis of the article is on the MoD scheme designed by the authors. Their scheme is based on so-called Luby transform codes, a FEC coding scheme developed by Michael Luby, a chief technology officer and founder of Digital Fountain. Luby transform codes differ from other commonly used FEC codes, e.g. Reed Solomon codes, in that it only requires a constant number of XOR operations per coded symbol and are able to code a limited number of packets into an essentially infinite stream of unique packets. The principal idea with Luby codes are that an Luby encoder generates interchangeable packets, which means that the client can receive any packets in any order. Only the number of packets received determines when the client can reconstruct the original segment. In their MoD scheme, the media server partitions a media file into segments of varying sizes and then transmits each segment on a separate multicast group. The client starts by joining one or more multicast groups and collects the Luby-encoded packets. The client only starts playing back the media file once it has received enough packets to decode the entire first segment. Thus, all clients with approximately the same packet loss will experience the same start-up latency, independent of when they start.},
  submitter = {Karl-Johan Grinnemo},
  bibdate = {Monday, November 12, 2001 at 08:52:34 (CET)}
Downloads: 0