An increasing number of live and recorded video and audio programs are being delivered to users via the Internet. Thanks to advances in bandwidth availability, media compression and computing power, more and more users enjoy programs delivered to their mobile and other computing devices. Rather than downloading entire programs for viewing, it is becoming increasingly common to “stream” programs to users by transmitting video or audio data to user devices in a steady, continuous stream. A number of streaming protocols are commonly used, including HTTP Live Streaming promoted by Apple® and Smooth Streaming promoted by Microsoft®. These streaming protocols define how, for example, a stream including video, audio, and possibly other ancillary data (e.g. cue points, time code, and closed captioning) is to be packaged or segmented for distribution to client devices.
An example of a conventional processing system configured according to certain existing approaches is shown in FIG. 2. This system provides a single manifest URL service 230 accessed by a user (e.g., operating a client device 240) and is subject to system failure. For example, on stream failure (of stream A of FIG. 2, for example) the user would see the stream stop mid-program. An administrator of the system may manually update the file uniform resource identifier (URI) in the manifest URL service 230, or the URI may be automatically updated by a watchdog process at which point the client device 240 may reinitialize the stream with the new URI. As shown in FIG. 2, previous approaches use a separate manifest file for each distribution chain. As can be seen from FIG. 2, when distributing a segmented HTTP stream, if there is an encoder, segmenter, or origin failure, the distribution stream will be interrupted. It would be desirable to reduce the interruptions associated with distributing a segmented HTTP stream.