Method and apparatus for encoder-based distribution of live video and other streaming content

P-0001[0001] This application claims the benefit of U.S. provisional application Ser. No. 60/178,749, filed Jan. 28, 2000.

CROSS REFERENCE TO RELATED APPLICATIONS

P-0002[0002] Related subject matter is disclosed in co-pending U.S. patent application of Nils B. Lahr et al., filed Sep. 28, 1998, entitled “Streaming Media Transparency” (attorney's file IBC-P001); in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “Method and Apparatus for Client-Side Authentication and Stream Selection in a Content Distribution System” (attorney's file 39505A); in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “A System and Method for Rewriting A Media Resource Request and/or Response Between Origin Server and Client” (attorney's file 39511A); in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “Method And System For Real-Time Distributed Data Mining And Analysis For Networks” (attorney's file 39510A); in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “Method and Apparatus for Using Single Uniform Resource Locator for Resources With Multiple Formats” (attorney's file 39502A); in co-pending U.S. patent application of Nils B. Lahr et al., filed even date herewith, entitled “A System and Method for Mirroring and Caching Compressed Data in a Content Distribution System” (attorney's file 39565A); in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “A System and Method for Determining Optimal Server in a Distributed Network for Serving Content Streams” (attorney's file 39551A); and in co-pending U.S. patent application of Nils B. Lahr, filed even date herewith, entitled “A System and Method for Performing Broadcast-Enabled Disk Drive Replication in a Distributed Data Delivery Network” (attorney's file 39564A); the entire contents of each of these applications being expressly incorporated herein by reference.

FIELD OF THE INVENTION

P-0003[0003] The invention relates to a method and apparatus for providing multicast output from an encoder to one or more servers or other receive sites.

BACKGROUND OF THE INVENTION

P-0004[0004] Demand for streaming audio and video content on Internet and intranet sites is increasing to present, for example, news and entertainment content to users (e.g., pay-per-view programming and digital rights management), as well as provide advertising and commerce services, distance learning and the like. Before the development of streaming technology, audio and video content was downloaded from the Web, for example, using download-and-play technology. This download-and-play technology was extremely slow, even with the downloading of relatively small media files, since a media file had to be first downloaded in its entirety before it could be played. Streaming technology allows for the distribution and playback of much larger media files in a more efficient manner.

P-0005[0005] Streaming of media content can be accomplished using a web server or a streaming media server. A web server allows media files to be accessed via Web pages having the media files' uniform resource locators (URLs). Web server streaming generally uses Hyper Text Transport Protocol (HTTP) for communication between the server and the user or client. HTTP operates on top of transmission control protocol (TCP), which handles data transfers. TCP is designed to maximize data transfer rate, while ensuring overall stability and high throughput in a network, and employs packet loss reporting and re-transmission of lost packets. For example, TCP allows for the variability of the data rate, depending on the packet loss rate.

P-0006[0006] While a streaming media server can use HTTP/TCP, they also use such protocols as user datagram protocol (UDP) to improve the streaming experience. UDP reduces the bandwidth needed due to it being only a unidirectional protocol. Unlike TCP, UDP does not use ACK's and NAC's. Unlike TCP, UDP and similar protocols are faster protocols without retransmission or data-rate management functionality. UDP and similar protocols are therefore advantageous for transmitting real-time audio and video data, which can tolerate some lost packets. These protocols allow higher bandwidth to be delivered to the client than TCP since bandwidth is not used to re-transmit lost packets or keep track of packet order. UDP traffic also receives higher priority than TCP traffic on the Internet.

P-0007[0007] Multicast delivery of content is becoming more prevalent. Multicast networking technology allows a single stream to be distributed to multiple points in a network, while also reducing bandwidth use. A number of servers, however, do not support redistribution of a multicast stream either via multicast or unicast to a client. Servers that use TCP or other connection-oriented protocols require set-up and tear-down of virtual connections with users and therefore a considerable amount of handshaking to establish a virtual connection, which is not desirable in applications such as streaming and multicasting of content. Thus, a need exists for an encoding process to convert streams that are typically full-duplex (e.g., TCP streams) into a multicast stream for distribution. Further, there is a need to make existing video servers accept this multicast stream and redistribute it to clients in much the same way that they currently redistribute a stream provided to it via a TCP based-connection. The TCP-based connections that are currently supported, however, are not scalable to a large network of edge stream servers.

SUMMARY OF THE INVENTION

P-0008[0008] The above described disadvantages are overcome and a number of advantages are realized by a method and apparatus for protocol translation whereby the output of an encoder (e.g., a digital video encoder) can be broadcast using conventional broadcast IP technology. A remote receiver/protocol converter receives the broadcast IP stream and spoofs the original protocol employed by the encoder. This apparatus or method can either exist as a separate application or can be built directly into the encoder or server.

P-0009[0009] In accordance with an aspect of the present invention, a server is provided with a built-in encoding function that provides a broadcast IP stream. The broadcast IP stream employs header information that can be updated within a broadcast stream to facilitate reception and parsing of a received broadcast stream into a real-time stream.

BRIEF DESCRIPTION OF DRAWINGS

P-0010[0010] The various aspects, advantages and novel features of the present invention will be more readily comprehended from the following detailed description when read in conjunction with the appended drawings, in which:

P-0011[0011]FIGS. 1, 2 and <b>3</b> are block diagrams of conventional content distribution systems;

P-0012[0012]FIG. 4 illustrates an Internet broadcast system for streaming media constructed in accordance with an embodiment of the present invention;

P-0013[0013]FIG. 5 is a block diagram of a media serving system constructed in accordance with an embodiment of the present invention;

P-0014[0014]FIG. 6 is a block diagram of a data center constructed in accordance with an embodiment of the present invention;

P-0015[0015]FIG. 7 illustrates data flow in a Internet broadcast system for streaming media constructed in accordance with an embodiment of the present invention;

P-0016[0016]FIGS. 8, 9 and <b>10</b> illustrate acquisition, broadcasting and reception phases employed in a Internet broadcast system for streaming media constructed in accordance with an embodiment of the present invention;

P-0017[0017]FIG. 11 illustrates transport data management in a Internet broadcast system for streaming media constructed in accordance with an embodiment of the present invention;

P-0018[0018]FIG. 12 is a block diagram of a content distribution system constructed in accordance with an embodiment of the present invention; and

P-0019[0019]FIG. 13 is a block diagram of a content distribution system constructed in accordance with an embodiment of the present invention.

P-0020[0020] Throughout the drawing figures, like reference numerals will be understood to refer to like parts and components.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

P-0021[0021] Existing encoders support a protocol that is intended for a particular proprietary server. Thus, other protocols are needed to distribute a stream from one server to another. With reference to FIGS. 1, 2 and <b>3</b>, existing encoders <b>10</b> are limited to connection with a local server or servers <b>12</b>, and are therefore unable to broadcast their output to multiple reception points. Separate encoded streams are unicast to respective servers, which is in contrast with generating a single encoded stream that is multicast to different servers. With reference to FIG. 3, conventional local servers also cannot output the encoder signals in a format for transmission to multiple servers at the same time. In other words, a conventional server is limited to providing unicast streams to respective servers, as opposed to generating a multicast stream.

P-0022[0022] One of the reasons for these shortcomings of conventional servers is the use of connection-oriented protocols such as TCP. As stated previously, IP-based media servers are available which provide broadcast output. These servers, however, cannot be monitored and the broadcast output is different from the encoder output. Thus, scalability is limited. Further, IP-based media servers are not configured to process a broadcast stream in order to re-broadcast the stream to other clients or servers.

P-0023[0023] In accordance with the present invention, the output of an encoder is converted to, or simply output as, a broadcast IP stream, which can be translated by remote receivers or user devices to the original encoder output protocol or, if the original output is multicast, accepted ‘as is’. The protocol translation of the present invention essentially allows an encoder to be distributed (e.g., to appear at plural remote locations simultaneously) and therefore provides for larger scaling of encoders and servers, as well as better quality of service (QOS) and control over the distribution of streams. In accordance with another aspect of the present invention, an encoding scheme is provided in a server to enable it to output a broadcast IP stream.

P-0024[0024] The encoding of the present invention is described herein for illustrative purposes in connection with an exemplary Internet broadcast system <b>10</b> for streaming media. It is to be understood that implementation of the invention is not limited to the architecture of the system <b>10</b> described herein.

P-0025[0025] 1. System Component Overview

P-0026[0026] With reference to FIG. 4, a system <b>10</b> is provided which captures media (e.g., using a private network), and broadcasts the media (e.g., by satellite) to servers located at the edge of the Internet, that is, where users <b>20</b> connect to the Internet such as at a local Internet service provider or ISP. The system <b>10</b> bypasses the congestion and expense associated with the Internet backbone to deliver high-fidelity streams at low cost to servers located as close to end users <b>20</b> as possible.

P-0027[0027] To maximize performance, scalability and availability, the system <b>10</b> deploys the servers in a tiered hierarchy distribution network indicated generally at <b>12</b> that can be built from different numbers and combinations of network building components comprising media serving systems <b>14</b>, regional data centers <b>16</b> and master data centers <b>18</b>. The system also comprises an acquisition network <b>22</b> that is preferably a dedicated network for obtaining media or content for distribution from different sources. The acquisition network <b>22</b> can operate as a network operations center (NOC) which manages the content to be distributed, as well as the resources for distributing it. For example, content is preferably dynamically distributed across the system network <b>12</b> in response to changing traffic patterns in accordance with the present invention. While only one master data center <b>18</b> is illustrated, it is to be understood that the system can employ multiple master data centers, or none at all and simply use regional data centers <b>16</b> and media serving systems <b>14</b>, or only media serving systems <b>14</b>.

P-0028[0028] An illustrative acquisition network <b>22</b> comprises content sources <b>24</b> such as content received from audio and/or video equipment employed at a stadium for a live broadcast via satellite <b>26</b>. The broadcast signal is provided to an encoding facility <b>28</b>. Live or simulated live broadcasts can also be rendered via stadium or studio cameras, for example, and transmitted via a terrestrial network such as a T1, T3 or ISDN or other type of a dedicated network <b>30</b> that employs asynchronous transfer mode (ATM) or other technology. In addition to live analog or digital signals, the content can include analog tape recordings, and digitally stored information (e.g., media-on-demand or MOD), among other types of content. Further, in addition to a dedicated link <b>30</b> or a satellite link <b>26</b>, the content harvested by the acquisition network <b>22</b> can be received via the Internet, other wireless communication links besides a satellite link, or even via shipment of storage media containing the content, among other methods. The encoding facility <b>28</b> converts raw content such as digital video into Internet-ready data in different formats such as the Microsoft Windows Media (MWM), RealNetworks G2, or Apple QuickTime (QT) formats. The system <b>10</b> also employs unique encoding methods to maximize fidelity of the audio and video signals that are delivered via multicast by the distribution network <b>12</b>.

P-0029[0029] With continued reference to FIG. 4, the encoding facility <b>28</b> provides encoded data to the hierarchical distribution network <b>12</b> via a broadcast backbone which is preferably a point-to-multipoint distribution network. While a satellite link indicated generally at <b>32</b> is used, the broadcast backbone employed by the system <b>10</b> of the present invention is preferably a hybrid fiber-satellite transmission system that also comprises a terrestrial network <b>33</b>. The satellite link <b>32</b> is preferably dedicated and independent of a satellite link <b>26</b> employed for acquisition purposes. The tiered network building components <b>14</b>, <b>16</b> and <b>18</b> are each equipped with satellite transceivers to allow the system <b>10</b> to simultaneously deliver live streams to all server tiers <b>14</b>, <b>16</b> and <b>18</b> and rapidly update on-demand content stored at any tier. When a satellite link <b>32</b> is unavailable or impractical, however, the system <b>10</b> broadcasts live and on-demand content though fiber links provided in the hierarchical distribution network <b>12</b>. Where the feed is pulled from in case of a failure is based on a set of routing rules that include priorities, weighting, and so on. In other words, the feed is pulled in a manner similar to the way routers currently operate, but at the actual stream level.

P-0030[0030] The system <b>10</b> employs a director agent to monitor the status of all of the tiers of the distribution network <b>12</b> and redirect users <b>20</b> to the optimal server, depending on the requested content. The director agent can originate, for example, from the NOC/encoding facility <b>28</b>. The system employs an Internet Protocol or IP address map to determine where a user <b>20</b> is located and then identifies which of the tiered servers <b>14</b>, <b>16</b> and <b>18</b> can deliver the highest quality stream, depending on network performance, content location, central processing unit load for each network component, application status, among other factors. Cookies and data from other databases can also be employed to facilitate this system intelligence.

P-0031[0031] Media serving systems <b>14</b> comprise hardware and software installed in ISP facilities at the edge of the Internet. The media serving systems preferably only serve users <b>20</b> in its subnetwork. Thus, the media serving systems <b>14</b> are configured to provide the best media transmission quality possible because the end users <b>20</b> are local. A media serving system <b>14</b> is similar to an ISP caching server, except that the content served from the media serving system is controlled by the content provider that input the content into the system <b>10</b>. The media serving systems <b>14</b> each serve live streams delivered by the satellite link <b>32</b>, and store popular content such as current and/or geographically-specific news clips. Each media serving system <b>14</b> manages its storage space and deletes content that is less frequently accessed by users <b>20</b> in its subnetwork. Content that is not stored at the media serving system <b>14</b> can be served from regional data centers.

P-0032[0032] With reference to FIG. 5, a media serving system <b>14</b> comprises an input <b>40</b> from a satellite and/or terrestrial signal transceiver <b>43</b>. The media serving system <b>14</b> can output content to users <b>20</b> in its subnetwork or control/feedback signals for transmission to the NOC or another hierarchical component in the system <b>10</b> via a wireline or wireless communication network. The media serving system <b>14</b> has a central processing unit <b>42</b> and a local storage device <b>44</b>. A file transport module <b>136</b> and a transport receiver <b>144</b>, which are described below with reference to FIG. 10, are provided to facilitate reception of content from the broadcast backbone. The media serving system <b>14</b> also preferably comprises one or more of an HTTP/Proxy server <b>46</b>, a Real server <b>48</b>, a QT server <b>50</b> and a WMS server <b>52</b> to provide content to users <b>20</b> in a selected format. The media serving system can also support Windows and Real caching servers, allowing direct connections to a local box regardless of whether the content is available. The content in the network <b>12</b> is then located and cached locally for playback. This allows for split live feeds by a local media serving system <b>14</b> regardless of whether is being sent via a broadcast or feed mechanism. Thus, pull splits from a media serving system <b>14</b> are supported, as well as broadcast streams that are essentially push splits with forward caching. Also, the database <b>44</b> and file system <b>136</b> can be local or remote, depending on where the media serving system <b>14</b> is installed.

P-0033[0033] The regional data centers <b>16</b> are located at strategic points around the Internet backbone. With reference to FIG. 6, a regional data center <b>16</b> comprises a satellite and/or terrestrial signal transceiver, indicated at <b>61</b> and <b>63</b>, to receive inputs and to output content to users <b>20</b> or control/feedback signals for transmission to the NOC or another hierarchical component in the system <b>10</b> via wireline or wireless communication network. A regional data center <b>16</b> preferably has more hardware than a media serving system <b>14</b> such as gigabit routers and load-balancing switches <b>66</b> and <b>68</b>, along with high-capacity servers (e.g., plural media serving systems <b>14</b>) and a storage device <b>62</b>. The CPU <b>60</b> and host <b>64</b> are operable to facilitate storage and delivery of less frequently accessed on-demand content using the servers <b>14</b> and switches <b>66</b> and <b>68</b>. The regional data centers <b>16</b> also deliver content if a standalone media serving system <b>14</b> is not available to a particular user <b>20</b>. The director agent software preferably continuously monitors the status of the standalone media serving systems <b>14</b> and reroutes users <b>20</b> to the nearest regional data center <b>16</b> if the nearest media serving system <b>14</b> fails, reaches its fulfillment capacity or drops packets. Users <b>20</b> are typically assigned to the regional data center <b>14</b> that corresponds with the Internet backbone provider that serves their ISP, thereby maximizing performance of the second tier of the distribution network <b>12</b>. The regional data centers <b>14</b> also serve any users <b>20</b> whose ISP does not have an edge server.

P-0034[0034] The master data centers <b>18</b> are similar to regional data centers <b>16</b>, except that they are preferably much larger hardware deployments and are preferably located in a few peered data centers and co-location facilities, which provide the master data centers with connections to thousands of ISPs. With reference to FIG. 6, master data centers <b>18</b> comprises multiterabyte storage systems (e.g., a larger number of media serving systems <b>14</b>) to manage large libraries of content created, for example, by major media companies. The director agent automatically routes traffic to the closest master data center <b>18</b> if a media serving system <b>14</b> or regional data center <b>16</b> is unavailable. The master data centers <b>18</b> can therefore absorb massive surges in demand without impacting the basic operation and reliability of the network.

P-0035[0035] Transmissions can occur out of the data centers <b>16</b> and <b>18</b>. In the case of the satellite <b>32</b>, however, transmissions can also be implemented by taking what is being received and routing a copy thereof directly to the uplink system without first passing through the media serving systems <b>14</b>.

P-0036[0036] 2. System Operation Overview

P-0037[0037] With reference to FIG. 7, the Internet broadcast system <b>10</b> for streaming media generally comprises three phases, that is, acquisition <b>100</b>, broadcasting <b>102</b> and receiving <b>104</b>. In the acquisition phase <b>100</b>, content is provided to the system <b>10</b> from different sources such as Internet content providers (ICPs) or event or studio content sources. As stated previously, content can be received from audio and/or video equipment employed at a stadium for a live broadcast. The content can be, for example, live analog signals, live digital signals, analog tape recordings, digitally stored information (e.g., media-on-demand or MOD), among other types of content. The content can be locally encoded or transcoded at the source using, for example, file transport protocol (FTP), MSBD, or real-time transport protocol/real-time streaming protocol (RTP/RTSP). The content is collected using one or more acquisition modules <b>106</b>, which are described in more detail below in connection with FIG. 8. The acquisition modules <b>106</b> represent different feeds to the system <b>10</b> in the acquisition network <b>12</b> and can be co-located or distributed. Generally, acquisition modules <b>106</b> can perform remote transcoding or encoding of content using FTP, MSBD, or RTP/RTSP or other protocols prior to transmission to a broadcaster <b>110</b> for multicast to edge devices and subsequent rendering to users <b>20</b> located relatively near to one of the edge devices. The content is then converted into a broadcast packet in accordance with an aspect of the present invention. This process of packaging packets in a manner to facilitate multicasting, and to provide insight at reception sites as to what the packets are and what media they represent, constitutes a significant advantage of the system <b>10</b> over other content delivery systems.

P-0038[0038] Content obtained via the acquisition phase <b>100</b> is preferably provided to one or more broadcasters <b>110</b> via a multicast cloud or network(s) <b>108</b>. The content is unicast or preferably multicast from the different acquisition modules <b>106</b> to the broadcasters <b>110</b> via the cloud <b>108</b>. As stated above, the cloud <b>108</b> is preferably a point-to-multipoint broadcast backbone. The cloud <b>108</b> can be implemented as one or more of a wireless network such as a satellite network or a terrestrial or wireline network such as optical fiber link. The cloud <b>108</b> can employ a dedicated ATM link or the Internet backbone, as well as a satellite link, to multicast streaming media. The broadcasters <b>110</b> are preferably in tier <b>120</b>, that is, they are master data centers <b>18</b> that receive content from the acquisition modules <b>106</b> and, in turn, broadcast the content to other receivers in tiers <b>116</b>, <b>118</b> and <b>120</b>.

P-0039[0039] During the broadcasting phase <b>102</b>, broadcasters <b>110</b> operate as gatekeepers, as described below in connection with FIG. 9, to transmit content to a number of receivers in the tiers <b>116</b>, <b>118</b> and <b>120</b> via paths in the multicast cloud <b>108</b>. The broadcasters <b>110</b> support peering with other acquisition modules indicated generally at <b>112</b>. The peering relationship between a broadcaster <b>110</b> and an acquisition module <b>112</b> is via a direct link and each device agrees to forward the packets of the other device and to otherwise share content directly across this link, as opposed to a standard Internet backbone.

P-0040[0040] During the reception phase <b>104</b>, high-fidelity streams that have been transmitted via the broadcasters <b>110</b> across the multicast cloud <b>108</b> are received by servers <b>14</b>, <b>16</b> and <b>18</b> located as close to end users as possible. The system <b>10</b> is therefore advantageous in that streams bypass congestion and expense associated with the Internet backbone. As stated previously, the servers are preferably deployed in a tiered hierarchy comprising media serving systems <b>14</b>, regional data centers <b>16</b> and master data centers <b>18</b> that correspond to tiers <b>116</b>, <b>118</b> and <b>120</b>, respectively. The tiers <b>116</b>, <b>118</b> and <b>120</b> provide serving functions (e.g., transcoding from RTP to MMS, RealNet, HTTP, WAP or other protocol), as well as delivery via a local area network (LAN), the Internet, a wireless network or other network to user devices <b>122</b> for rendering (e.g., PCs, workstations, set-top boxes such as for cable, WebTV, DTV, and so on, telephony devices, and the like). The tiers in the reception phase are described in further detail below in connection with FIG. 10.

P-0041[0041] 3. Data Transport Management

P-0042[0042] With reference to FIGS. 8, 9 and <b>10</b>, hardware and/or software components associated with the acquisition <b>100</b>, broadcasting <b>102</b> and reception phases <b>104</b> will now be described. These hardware and/or software components comprise various transport components for supporting MOD or live stream content distribution in one or more multicast-enabled networks in the system <b>10</b>. The transport components can be, but are not limited to, a file transport module, a transport sender, a transport broadcaster, and a transport receiver. The content is preferably characterized as either live content and simulated/scheduled live content, or MOD (i.e., essentially any file). Streaming media such as live content or simulated/scheduled live content are managed and transported similarly, while MOD is handled differently.

P-0043[0043] Acquisition for plural customers A through X is illustrated in FIG. 8. By way of an example, acquisition for customer A involves an encoder, as indicated at <b>134</b>, which can employ Real, WMT, MPEG, QT, among other encoding schemes with content from a source <b>24</b>. The encoder also encodes packets into a format to facilitate broadcasting in accordance with the present invention. A disk <b>130</b> stores content from different sources and provides MOD streams, for example, to a disk host <b>132</b>. The disk host <b>132</b> can be proxying the content or hosting it. Live content, teleconferencing, stock and weather data generating systems, and the like, on the other hand, is also encoded. The disk host <b>132</b> unicasts the MOD streams to a file transport module <b>136</b>, whereas the encoder <b>134</b> provides the live streams to a transport sender <b>138</b> via unicast or multicast. The encoder can employ either unicast or multicast if QT is used. Conversion from unicast to multicast is not always needed, but multicast-to-multicast conversion can be useful. The file transport module <b>136</b> transfers MOD content to a multicast-enabled network. The transport sender <b>138</b> pulls stream data from a media encoder <b>134</b> or an optional aggregator and sends stream announcements (e.g., using session announcement protocol and session description protocol (SAP/SDP)) and stream data to multicast Internet protocol (IP) addresses and ports received from a transport manager. The transport manager is described below with reference to FIG. 11. When a Real G2 server is used to push a stream, as opposed to a pulling scheme, an aggregator can be used to convert from a push scheme to a pull scheme. The components described in connection with FIG. 8 can be deployed at the encoding center <b>28</b> or in a distributed manner at, for example, content provider facilities.

P-0044[0044]FIG. 9 illustrates an exemplary footprint for one of a plurality of broadcasts. As shown in FIG. 9, the broadcasting phase <b>102</b> is implemented using a transport broadcaster <b>140</b> and a transport bridge <b>142</b>. These two modules are preferably implemented as one software program, but different functions, at a master data center <b>18</b> or network operations center. The transport broadcaster <b>140</b> performs transport path management, whereas the transport bridge <b>142</b> provides for peering. The broadcaster <b>140</b> and bridge <b>142</b> get data from the multicast cloud (e.g., network <b>108</b>) being guided by the transport manager and forward it to an appropriate transport path. One transport broadcaster <b>140</b>, for example, can be used to represent one transport path such as satellite uplink or fiber between data centers or even a cross-continental link to a data center in Asia from a data center in North America. The broadcaster <b>140</b> and bridge <b>142</b> listen to stream announcements from transport senders <b>138</b> and enable and disable multicast traffic to another transport path, accordingly. They can also tunnel multicast traffic by using TCP to send stream information and data to another multicast-enabled network. Thus, broadcasters <b>110</b> transmit corresponding subsets of the acquisition phase streams that are sent via the multicast cloud <b>108</b>. In other words, the broadcasters <b>110</b> operate as gatekeepers for their respective transport paths, that is, they pass any streams that need to be sent via their corresponding path and prevent passage of other streams. Transmission can also be accomplished using TCP to another receiver regardless whether the system that the receiver is in is muiticast-enabled. Thus, multicast operation can be disabled and the broadcast is still routed and distributed, although not quite as effectively or inexpensively as multicast.

P-0045[0045]FIG. 10 illustrates the reception phase <b>104</b> at one of a plurality of servers or data centers. As stated above, the data centers are preferably deployed in a tiered hierarchy <b>116</b>, <b>118</b> and <b>120</b> comprising media serving systems <b>14</b>, regional data centers <b>16</b> and master data centers <b>18</b>, respectively. The tiers <b>116</b>, <b>118</b> and <b>120</b> each comprise a transport receiver <b>144</b>. Transport receivers can be grouped using, for example, the transport manager. Each transport receiver <b>144</b> receives those streams from the broadcasters <b>110</b> that are being sent to a group to which the receiver belongs. The transport receiver listens to stream announcements, receives stream data from plural transport senders <b>138</b> and feeds the stream data to media servers <b>146</b>. The transport receiver <b>144</b> can also switch streams, as indicated at <b>154</b> (e.g., to replace a live stream with a local MOD feed for advertisement insertion purposes). The stream switch <b>154</b> can be a plug-in in the Media Server <b>14</b> or exist in the server itself to enable switching per end-user <b>20</b>. The plug-in can interact with an advertisement platform to inject advertisements into streams. The MOD streams are received via the file transport <b>136</b> and stored, as indicated via the disk host <b>148</b>, database <b>150</b> and proxy cache/HTTP server <b>152</b>. The servers <b>146</b> and <b>152</b> provide content streams to users <b>20</b>.

P-0046[0046] 4. Encoding

P-0047[0047] The transport components described in connection with FIGS. 8, 9 and <b>10</b> are advantageous in that they generalize data input schemes from encoders and optional aggregators to data senders, data packets within the system <b>10</b>, and data feeding from data receivers to media servers, to support essentially any media format. The transport components preferably employ RTP as a packet format and XML-based remote procedure calls (XBM) to communicate between transport components.

P-0048[0048] The transport manager will now be described with reference to FIG. 11 which illustrates an overview of transport data management. The transport manager is preferably a software module deployed at the encoding facility <b>28</b> or other facility designated as a NOC. As shown in FIG. 11, multiple data sources <b>14</b> (e.g., database content, programs and applications) provide content as input into the transport manager <b>170</b>. Information regarding the content from these data sources is also provided to the transport manager such as identification of input source <b>14</b> and output destination (e.g., groups of receivers). Decisions as to where content streams are to be sent and which groups of servers are to receive the streams can be predefined and indicated to the transport manager <b>170</b> as a configuration file or XBM function call in real-time. This information can also be entered via a graphical user interface (GUI) <b>172</b> or command line utility. In any event, the information is stored in a local database <b>174</b>. The database <b>174</b> also stores information for respective streams relating to defined maximum and minimum IP address and port ranges, bandwidth usage, groups or communities intended to receive the streams, network and stream names, as well as information for user authentication to protect against unauthorized use of streams or other distributed data.

P-0049[0049] With continued reference to FIG. 11, a customer requests to stream content via the system <b>10</b> using, for example, the GUI <b>172</b>. The request can include the customer's name and account information, the stream name to be published (i.e., distributed) and the IP address and port of the encoder or media server from which the stream can be pulled. Requests and responses are sent via the multicast network (e.g., cloud <b>108</b>) using separate multicast addresses for each kind of transport component (e.g., a transport sender channel, a broadcaster channel, a transport manager channel and a transport receiver channel), or one multicast address and different ports. IP and port combinations can be used for TCP transmissions. An operator at the NOC <b>28</b> can approve the request if sufficient system resources are available such as bandwidth or media server capacity. Automatic approval can be provided by a scheduling system configured to provide immediate responses to attempted broadcasts. The transport manager <b>170</b> preferably pulls stream requests periodically. In response to an approved request, the transport manager <b>170</b> generates a transport command in response to the request (e.g., an XML-based remote procedure call (XBM)) to the transport sender <b>138</b> corresponding to that customer which provides the assigned multicast IP address and port that the transport sender is allowed to use in the system <b>10</b>.

P-0050[0050] The transport sender <b>138</b> receives the XBM call and responds by announcing the stream that is going to be sent. All of the transport components listen to the announcement. Once the transport sender <b>138</b> commences sending the stream into the assigned multicast IP address and port, the corresponding transport broadcaster <b>140</b> filter the stream. The transport receiver <b>144</b> joins the multicast IP address and receives the data or stream if the stream is intended for a group to which the receiver <b>144</b> belongs. As stated above in connection with FIG. 7, the receiver converts the steam received via the cloud <b>108</b> and sends it to the media server available to the users <b>20</b>. The data is then provided to the media server associated with the receiver. Receivers <b>144</b> and broadcasters <b>140</b> track announcements that they have honored using link lists.

P-0051[0051] As stated above, the transport components described with reference to FIGS. <b>7</b>-<b>11</b> preferably use RPT as a data transport protocol. Accordingly, Windows Media, RealG2 and QT packets are wrapped into RTP packets. The acquisition network <b>22</b> preferably employs an RTP stack to facilitate processing any data packets, wrapping the data packets with RTP header and sending the data packets. RTSP connection information is generally all that is needed to commence streaming.

P-0052[0052] RTP is used for transmitting real-time data such as audio and video, and particularly for time-sensitive data such as streaming media, whether transmission is unicast or multicast. RTP employs User Datagram Protocol (UDP), as opposed to Transmission Control Protocol (TCP) that is typically used for non-real-time data such as file transfer and e-mail. Unlike with TCP, software and hardware devices that create and carry UDP packets do not fragment and reassemble them before they have reached their intended destination, which is important in streaming applications. RTP adds header information that is separate from the payload (e.g., content to be distributed) that can be used by the receiver. The header information is merely interpreted as payload by routers that are not configured to use it.

P-0053[0053] RTSP is an application-level protocol for control over the delivery of data with real-time properties and provides an extensible framework to enable controlled, on-demand delivery of real-time data including live feeds and stored clips. RTSP can control multiple data delivery sessions, provide means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide means for choosing delivery mechanisms based on RTP. HTTP is not suitable for streaming media because it is more of a store-and-forward protocol that is more suitable for web pages and other content that is read repeatedly. Unlike HTTP, RTSP is highly dynamic and provides persistent interactivity between the user device (hereinafter referred to as a client) and server that is beneficial for time-based media. Further, HTTP does not allow for multiple sessions between a client and server, and travels over only a single port. RTP can encapsulate HTTP data, and can be used to dynamically open multiple RTP sessions to deliver many different streams at the same time.

P-0054[0054] The system <b>10</b> employs transmission control software deployed at the encoding facilities <b>28</b>, which can operate as a network operations center (NOC), and at broadcasters <b>110</b> (e.g., master data centers <b>120</b>) to determine which streams will be available to which nodes in the distribution system <b>12</b> and to enable the distribution system <b>12</b> to support one-to-one streaming or one-to-many streaming. The extensible language capabilities of RTSP augment the transmission control software at the edge of the distribution network <b>12</b>. Since RTSP is a bi-directional protocol, its use enables encoders <b>134</b> and receivers <b>144</b> to talk to each other, allowing for routing, conditional access (e.g., authentication) and bandwidth control in the distribution network <b>12</b>. Standard RTSP proxies can be provided between any network components to allow them to communicate with each other. The proxy can therefore manage the RTSP traffic without necessarily understanding the actual content.

P-0055[0055] For every RTSP stream, there is an RTP stream. Further, RTP sessions support data packing with timestamps and sequence numbers. They can also be used for carrying stereo information, wide screen versions of requested media, different audio tracks, and so on. RTP packets are wrapped in a broadcast protocol. Applications in the receiving phase <b>104</b> can use this information to determine when to expect the next packet. Further, system operators can use this information to monitor network <b>12</b> and satellite <b>32</b> connections to determine the extent of latency, if any.

P-0056[0056] Encoders and data encapsulators written with RTP as the payload standard are advantageous because off-the-shelf encoders (e.g., MPEG2 encoders) can be introduced without changing the system <b>10</b>. Further, encoders that output RTP/RTSP can connect to RTP/RTSP transmission servers. In addition, the use of specific encoder and receiver combinations can be eliminated when all of the media players support RTP/RTSP.

P-0057[0057] With reference to FIG. 12 and in accordance with an embodiment of the present invention, a proxy is created in software for use between an encoder (e.g., encoder <b>134</b>) and any device with which the encoder communicates and to which the encoder provides output. The proxy can be implemented, for example, as a stand-alone application or can be compiled into an encoder. The proxy provides for protocol translation to allow the encoder output to be broadcast (e.g., via network <b>108</b>) and to allow the encoder to appear at a large number of locations to other network devices such as servers (e.g., data centers or servers <b>14</b>, <b>16</b> and <b>18</b>) or clients <b>20</b>. In the illustrated embodiment, the proxy is provided in a receiver/protocol converter <b>180</b> to allow for a broadcast IP function to be added to an encoder or for a connection to a first generation IP-compatible encoder.

P-0058[0058] The protocol translation provided by the proxy <b>180</b> of the present invention involves determining the types of input that each of a number of different types of encoders <b>134</b> is configured to receive. For each type of encoder, the proxy repacketizes packets received from that encoder to initiate a broadcast IP stream. The stream comprises header information that is preferably updated and transmitted periodically within the stream. The header information comprises information such as multiple bit rates used by the encoder, codec information, audio and video channel information, information relating to stereo or surround-sound reception, and the like. The header information also comprises sequence numbers and time stamps. Additional data pertaining to the actual audio and/or video data that the payload represents can also be provided in the packets encoded for broadcasting in accordance with the present invention.

P-0059[0059] Following broadcast transmission via a network <b>108</b>, the header facilitates decoding of the stream at a receive site such as a decoder client <b>22</b>, a destination receiver/protocol converter <b>182</b>, a server <b>14</b>, <b>16</b> or <b>18</b>, and so on, as illustrated in FIG. 12. The receive sites (e.g., servers or data centers <b>14</b>, <b>16</b> and <b>18</b>) are configured to recognize the re-packetized broadcast stream and to parse the broadcast stream to convert it to the real-time stream (e.g., a media-on-demand (MOD) file) generated by the encoder <b>134</b>. Edge devices in the distribution system <b>12</b> can listen to a multicast stream and determine for each packet the stream to which the packet belongs, the metadata associated with that stream, codecs and bit rates used to create the stream, quality of service information, among other types of information. The broadcast packets can therefore be converted to their original packet format for serving to a client <b>22</b> in the order with which they were original time-stamped. Further, packets that were unsuccessfully broadcast can be identified. A management device can be added which supports, for example, Simple Network Management Protocol (SNMP) queries about packet loss rate and other information needed to report the quality of bits transmitted via the distribution system <b>12</b>.

P-0060[0060] If the proxy is compiled and not a stand-alone application, re-packetizing is not needed. The broadcast stream is instead directly output with header information. Similarly, at the receiver side, there is no re-packetized broadcast stream requiring conversion back to a real-time stream. The receiver applications are instead only concerned with the header information and the payload data.

P-0061[0061] In accordance with another embodiment of the present invention, a server <b>184</b> is provided than can simply broadcast an encoded stream over the network <b>108</b>, as shown in FIG. 13. Remote servers <b>186</b> and <b>188</b> are provided to receive the same stream. No protocol converters <b>180</b> and <b>182</b> are needed in this illustrated embodiment. The server <b>184</b> is different than existing servers which do not redistribute media streams using multicast. Further, the server <b>184</b> is different from an encoder that simply outputs multicast and requires files to be placed on remote sites. The illustrated embodiment in FIG. 13, in contrast, broadcasts the header information, as well as the payload data.

P-0062[0062] The receiver/protocol converter <b>182</b> uses the header information that is multiplexed into the multicast stream or sent on another IP address/port combination to commence a negotiation or hand-shaking process with a receiver (decoder client <b>20</b>, a destination receiver/protocol converter <b>182</b>, a server <b>20</b>, and so on). Information for the negotiation process (e.g., bit rate, method of decoding broadcast payload information in bi-directional communication, reason for connecting, and so on) is therefore provided on a periodic and dynamically updated basis, as opposed to on a payload basis from the origin source. The broadcast stream can be converted, for example, to a bi-directional stream if necessary (i.e., when a receive site such as a client <b>22</b> or server <b>14</b>, <b>16</b> or <b>18</b> expects to receive such a formatted steam).

P-0063[0063] The protocol translation of the present invention facilitates the hosting of live/near-live digital video streams on a network. The present invention is operable to essentially any encoder to scale digital video output in a manner similar to analog output of conventional broadcast networks.

P-0064[0064] Although the present invention has been described with reference to a preferred embodiment thereof, it will be understood that the invention is not limited to the details thereof Various modifications and substitutions will occur to those of ordinary skill in the art. All such substitutions are intended to be embraced within the scope of the invention as defined in the appended claims.