US20140373053A1

US20140373053A1 - System and method for inserting local content into satellite broadcast programs and epg on a network

Info

Publication number: US20140373053A1
Application number: US14/364,125
Authority: US
Inventors: Suresh Viswanath Leley; Thomas Anthony Stahl
Original assignee: Thomson Licensing SAS
Current assignee: InterDigital Madison Patent Holdings SAS
Priority date: 2011-12-15
Filing date: 2012-12-17
Publication date: 2014-12-18
Also published as: BR112014013646A2; US20140351859A1; BR112014014778A2; US9357263B2; WO2013090876A3; WO2013090876A2; WO2013090877A1

Abstract

The present invention relates to system of inserting locally stored content into satellite broadcast programs and electronic program guides. In particular, the system teaches a method of receiving satellite tuning parameters from a set top box, determine a request for locally stored content, and transmitting a multicast address in response to said reception of satellite tuning parameters. The locally stored content is then transmitted to the receiver over a network using the multicast address.

Description

PRIORITY CLAIM

This application claims the benefit of U.S. Provisional Patent Application No. 61/576,133, filed Dec. 15, 2011 entitled “SYSTEM AND METHOD FOR INSERTING LOCAL CONTENT INTO SATELLITE BROADCAST PROGRAMS AND EPG ON A NETWORK” which is incorporated herein by reference.

TECHNICAL FIELD OF THE INVENTION

The present disclosure generally relates to digital content systems and methods for delivering content to an end user, and more particularly, to a system and method for providing locally provided content and an electronic program guide (EPG) to an end user.

BACKGROUND

Due to the advent of cable television, direct satellite systems, and other television program broadcast systems, viewers have very large numbers of programs from which to select. Sophisticated systems have been developed to assist a viewer in selecting programs to view or record, among which are the Electronic Program Guide (EPG). An EPG is displayed on a display screen as an interface. In essence, an EPG is an interactive, on screen equivalent to listings found in local newspapers or other print media. An EPG interface can provide several different kinds of information about each program that is within the time frame covered by the EPG. The time frame typically ranges from the next hour up to seven days in advance. EPG program information is usually displayed in a two dimensional grid comprising a plurality of program cells wherein each cell corresponds to a particular program. Typically, the EPG program schedule grid has time on one axis and channel number on the other axis.
One such system employing an electronic program guide (EPG) is a system for providing satellite entertainment services and locally stored entertainment services to apartments within a multi-dwelling unit (MDU), dorm rooms within a dormitory, or to paying customers on a people transporter, such as an airplane. The system architecture of the airline system described herein is based on land based systems such as those used in multi-dwelling units (MDU) in the US Market. All of the programming is made available to the user via one unified Electronic Program Guide (EPG) on the seat display. The visual EPG is constructed from several sources. The satellite programming is accompanied by a satellite EPG stream that pertains to the satellite programming while the local content EPG stream is generated locally.
For the US System, the locally generated EPG is carried on Network 0xFFFE. The STB is forced to use Satellite Network 0 physical tuning parameters for local channel requests by the Transmit Network Descriptor that is carried in each local EPG Channel Object. The Transmit Network Descriptor with reference to Network 0 is place in the local Channel Objects in the local EPG streams by the local EPG Generator.
One method is for the Local EPG Generator to not place this Transmit Network Descriptor into the local Channel Objects. In that case, the STB will not redirect its tune request to Network 0 parameters, but will use its view of Network 0xFFFE. The view of a network is either in a STB by default or is based on a Satellite Descriptor or Advanced Satellite Descriptor that has been received in the Boot Stream of the Satellite EPG. Since Network 0xFFFE will not defined in the Satellite Descriptor, a default view of this logical network must be in the STB. Since Network 0xFFFE is not defined by the Satellite Service Provider, any reasonable frequency index to transponder frequency/polarity can be used. In this instantiation, the frequency index formula used in the US system will continue to be used.
Another method would be to keep the local network overlaid on Network 0, but do not use the tune parameters from the Satellite Descriptor for tune request. Instead, the STB would need to filter on PIDs to identify requests for local channels and treat them different than requests for satellite channels. Note that local channels use PIDs from a reserved range that is not used in satellite broadcasts. Requests for satellite channels would follow the normal flow. But request for local channels would be diverted to logic that uses the same formula for frequency and polarity as that used for DirecTV Network 0. This method requires modification of the STB middleware/application.
Another method is to keep the local network overlaid over Satellite Network 0 and use the freq_index map as provided in the Advanced Satellite Descriptor. The STB will receive that map via the Satellite EPG. The RTSP Server in the DSCD needs the same map in order to calculate IP Multicast Addresses. In this method, the map is supplied in a file to the RTSP Server during startup. This requires manually updating the freq_index map file in the DSCD when the Brazil Satellite Service provider changes their map. This manual step is obviously a disadvantage. However, the current system can be further modified to parse the Brazil Satellite Advanced Boot Stream to acquire the Transponder Map from the Advanced Satellite Descriptor carried in the Advanced Boot Object. This transponder map would be the same as that used in the Receiver making the system “future proof.”
A IP-based reference system that combines local AV content and EPGs with satellite AV content and EPGs already exists for the US market. The US system uses techniques from the US satellite service provider to overlay the EPG for the local content over a specific satellite network. However, the method for combining satellite broadcasts with local broadcasts relies on both the satellite Network 0 and the local network to use the same frequency index to frequency/polarity mapping. This exact technique cannot be used for the combination of US and other satellite markets because of the differences between the US Satellite Network and the Brazil Satellite Network or Satellite Networks in other market, therefore, there must be some modifications. For the Brazil Satellite System, the frequency index to frequency/polarity mapping does not follow a formula as Network 0 in the US System does. Since the satellite transponder mapping is determined by the Satellite EPG, either the local content will have to use the Brazil Network 0 Transponder map, which can only be represented by a table, or the system architecture must change to allow the existing US Network 0 formula to continue to be used for the local broadcasts. There is concern that the Brazil transponder map will grow and may change. For that reason, it is desirable to continue to use the US Network 0 formula for Local Content Insertion (LCI) or to provide a way for the Brazil transponder map to be updated.
Therefore, a need exists to provide simplified techniques that allow for the insertion of local content in different markets that use different satellites than the existing system.

SUMMARY

In one aspect, the present invention involves a method comprising the steps of receiving a frequency index map, receiving a request for an audio video program according to said frequency index map, determining a multicast address corresponding to said audio video program, and transmitting said multicast address.
In another aspect, the present invention involves an apparatus comprising a first input for receiving a frequency index map, a second input for receiving a request for an audio video program according to said frequency index map, a processor for determining a multicast address corresponding to said audio video program, and a transmitter for transmitting said multicast address.
In another aspect, the present invention involves a satellite signal head end comprising a first input for receiving a satellite channel frequency index map, a second input for receiving a request for an audio video program according to said satellite channel frequency index map from a receiver, a processor for determining a multicast address corresponding to said audio video program, a storage medium for storing said audio video program, and a transmitter for transmitting said multicast address and said audio video program.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects, features and advantages of the present disclosure will be described or become apparent from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings.

In the drawings, wherein like reference numerals denote similar elements throughout the views:

FIG. 1 is a block diagram of an exemplary system for delivering video content and EPG streams in accordance with the present disclosure;

FIG. 2 is a data flow diagram showing EPG streams, AV Streams, and related RTSP traffic between various functions for the US AV Entertainment System.

FIG. 3 is a flowchart that illustrates an exemplary embodiment of a method for inserting local content into satellite broadcast programs and EPG on a network according to the present invention.

It should be understood that the drawing(s) is for purposes of illustrating the concepts of the disclosure and is not necessarily the only possible configuration for illustrating the disclosure.

DETAILED SYSTEM DESCRIPTION

The present principles include systems and methods for providing a program guide interface in IP Video Distribution systems. Although the present principles are described herein below primarily within the context of an airplane multimedia distribution system, the specific implementations of the present principles should not be treated as limiting the scope of the invention. It is appreciated by those skilled in the art and informed by the teachings of the present principles that the concepts of the present invention can be advantageously applied in other types of multimedia content distribution systems. For example, the concepts of the present principles can be implemented in any Local Area Network (LAN) based system that distributes satellite broadcasts, cable television broadcasts and the like.
The functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and implementations of the present principles, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).
Thus, for example, it is appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the invention. Similarly, it is appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which can be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
The present disclosure relates to the seamless integration of one video service (e.g., locally presented programs and EPG) with a primary video service (e.g., Satellite TV Service) onto a local area network (LAN) where they are multicast to user terminals. The local EPG is generated such that the origin of individual programs may be transparent to the customer. It is presented to the customer as one seamless service. The inserted programs may be locally added to the network (e.g., stored movie or camera) or may be supplied from another broadcast source (e.g., satellite or cable). For simplicity, the locally inserted video and EPG will be referred to as “Local Content” and the process is called “Local Content Insertion.”
Such systems have already been created for a US Satellite Service provider. This disclosure presents modifications suitable for different service providers with similar systems.
Referring now in specific detail to the drawings in which like reference numerals identify similar or identical elements throughout the several views, and initially to FIG. 1, a high level block diagram of an exemplary IP video content distribution system 100 for providing an electronic program guide for local content and satellite content in accordance with one exemplary implementation of the present principles is illustrated. System 100 can include a Digital Satellite Concentrator and Distributor (DSCD) 102, a Content Server and System Controller (CSSC) 110, Ethernet switches 108 and a series of Receivers 120-1 to 120-N, including Decoders 122-1 to 122-N and EPG Interpreters 124-1 to 124-N, respectively. The receivers 120 can, for example, respectively service video displays for each passenger seat.
The DSCD 102 can act as a satellite gateway for the content distribution system. For example, DSCD 102 can receive video content data streams and corresponding program guide information from a satellite service provider (not shown) along line 117 through satellite tuners and demodulators 104. The satellite audio/video and EPG streams are passed to the Audio Video (AV) Streamers 107 where channels are packaged in IP protocols and are spooled onto the local network. Functions of the DSCD 102 can include modifying received satellite EPG packets to indicate the presence of a local network so that a receiver 120 can acquire the guide for local content generated by the CSSC 110. Additionally, the DSCD 102 can include a Real Time Streaming Protocol (RTSP) Server 106 to service receivers 120 by receiving local and satellite content tuning requests and responding to the receivers 120 by sending corresponding IP multicast group addresses on which requested video streams can be found. Here, the RTSP server 106 can distinguish between tuning requests for local content and tuning requests for satellite content. Further, audio/video content and guide information received from the satellite can be sent by the DSCD 102 to the receivers 120 on an Audio/video Digital Satellite Service (DSS) or Digital Video Broadcasting (DVB) Transport Stream (TS) encapsulated in IP and related protocols through switches 108. Modification of satellite packets can be accomplished in real-time using an e.g., Field Programmable Gate Array (FPGA).
The CSSC 110 can be the primary system controller that is responsible for overall system operation and local content insertion. For example, local content can include a video instructing passengers of customs regulations or a video instructing passengers of safety precautions. However, it should be understood that in other implementations, such as land-based cable television systems, local content insertion can include insertion of live video feeds, such as a front door camera. Further, it should be noted that local content can also comprise entertainment programs or motion pictures stored within CSSC 110. Components of the CSSC 110 can include, inter alia, an AV Streamer or Data Pump 114, a Content Scheduler 112, a Local Electronic Program Guide (EPG) Generator 116, and a Master Controller 111, each of which is discussed herein below.
The AV Streamer 114 can be configured to generate and stream AV content onto the local network at a proper rate. For example, the AV Streamer 114 can aggregate and encapsulate packets from a digital video file into a Real-time Protocol (RTP)/User Datagram Protocol (UDP)/Internet Protocol (IP) stream.
The Local EPG Generator 116 can be configured to generate and stream local EPG streams onto the local network at a proper rate. For example, the EPG Generator 116 can create EPG objects and descriptors based on information it receives from the Content Scheduler 112. It can construct valid fast load and broadcast carousel EPG streams from those objects and can encapsulate the packets into a Real-time Protocol (RTP)/User Datagram Protocol (UDP)/Internet Protocol (IP) stream. In some applications where the Satellite Service is not present, the EPG Generator may construct a Boot Stream.
The Content Scheduler 112 may control insertion of local content and local EPG streams by employing a Local Guide XML file 119 or alternately an API with common data structures. For simplicity, only the use of the XML files for inter-process communication is explained. The Local Guide XML file 119 may include a base time, channel listing, program listings and related information, optional pause functionality for channels, file names of files, and schedules, which can be offset by the base time.
In some implementations of the present principles, the AV Streamer 114 can perform the front end processing for the Local EPG Generator 116 for input from the Content Scheduler 112. For example, the AV Streamer can be configured to monitor the Local XML File 119 corresponding to a schedule of local programming, local content filenames and high-level commands such as “PAUSE.” The AV Streamer can monitor the Local Guide XML files for any changes to the status of channels or programs. In addition, the AV streamer 114 can parse XML files and supply guide generation related inputs to the Local EPG Generator 116 through an API 117. In general, the AV Streamer 114 can be controlled through the Local Guide XML file 119 generated by the Content Scheduler 112.
Alternatively, the XML parser can be independent of the AV Streamer 114 and can parse the Local Guide XML file 119 for both the AV Streamer 114 and the Local EPG Generator 116. Alternatively, the AV Streamer and the Local EPG Generator can be independent, each with its own XML parser as shown in FIG. 1.
Further, the AV Streamer 114 can inform the Content Scheduler 112 of the content currently playing, when certain content has finished playing, and the state of the AV streams through a Now Playing (NP) XML File 118. The playing status of content can be useful for pausing or un-pausing content for the display of locally inserted content, as discussed below with respect to the Content Scheduler 112. The format of the NP XML File can include a base time, a timestamp and a channel listing, which can reference all channels. The channel listing can include a channel name, channel objects, which can include a user-recognizable number, name and logo, and program information.
The base time can indicate a time by which all program start times and end times or other events are measured. For example, a base time can be specified as seconds since a predetermined time, e.g., Jan. 6, 1980 12:00 am, and all program start and end times can correspond to the total number of seconds after the base time, i.e., an offset from the base time.
The Master Controller 111 in the CSSC 110 is responsible for all high-level system operation and coordination. It keeps track of passenger credit card payments for each seat, controls DSCD configuration settings, controls the Content Scheduler, and has a private communication channel to elements in the Receivers 120, such as the Content Enforcers 125. It also takes input from an operator's console (not shown).
The entertainment system includes a series of Receivers 120-1 to 120-N. The Receivers 120-1 to 120-N may respectively include Logical Tuners 121-1 to 121-N, MPEG decoders 122-1 to 122N, EPG interpreters 124-1 to 124-N, Content Enforcer 125-1 to 125-N, RTSP Clients 126-1 to 126-N, Analog Video Encoders 127-1 to 127-N, Remote Control Unit (RCU) receivers 1281 to 128-N, Video Display Units (VDUs) (not shown), and credit card readers (not shown) respectively. The Receivers 120 can, for example, respectively service video displays and receive inputs, e.g., passenger commands, from respective RCUs. There is one receiver for each passenger on the airplane.
The Receiver software structure is based on hardware and software used in a standard satellite set-top box (STB) that directly tunes the RF satellite signal. Because of that, it contains a Logical Tuner 121, which takes the place of the RF tuner. Tuning information to the logical tuner includes information such as satellite, transponder frequency, and signal polarity. Once a tuning request is approved by the Content Enforcer 125, this information is turned into a RTSP tune request by the RTSP Client 126.
The MPEG Decoder 122 receives multicast audio/video streams from the network via a network interface and Logical Tuner 121. Local AV streams are transmitted from the CSSC 110 and Satellite AV streams are forwarded onto the local network by the DSCD 102. The MPEG decoder can parse the AV Stream, decode the video, decode audio, and present it to the Analog/Video Encoder for transmission to the VDU and headset (not shown).
The EPG Interpreter 124 receives multicast EPG streams from the network via a network interface and Logical Tuner 121. Local Guide streams are transmitted from the CSSC 110 and satellite guide streams are forwarded onto the local network by the DSCD 102. The EPG Interpreter 124 decodes each guide stream, combines the information from both local and satellite guides, and creates one unified EPG to be presented to the passenger on the VDU. Only channels allowed to be displayed by the Enforcer Table in the Content Enforcer 125 will be displayed in the EPG.
The Content Enforcer 125 works with the EPG Interpreter 124 to display only valid channels for the offered entertainment service. Not all available satellite channels are in the channel lineup. The Content Enforcer 125 also works with the RTSP Client 126 to make sure that only channels that the customer is allowed to see (e.g., has been paid for) can be tuned. The Content Enforcer 125 includes a structure called the Enforcer Table (not shown) which is used to control these actions. The Enforcer Table is created and sent to the Content Enforcer 125 by the Content Scheduler 112 in the CSSC 110.
The Enforcer Table is a structure that provides information, for each channel, required to determine whether or not a channel should be shown in the EPG and if the user may watch programs on that channel. All program access to the Content Enforcer 125 is based on the unique 32-bit channel identifier associated with each channel. This identifier is the channel object ID from the EPG data stream.
A customer/passenger can request to watch a specific channel (local or satellite) by choosing that channel on the EPG using the RCU 128. If the requested channel requires extra payment, the Receiver 120 presents the customer with on screen displays (OSDs) that allow them to pay by credit card. Payment information is sent back to the Master Controller 111 in the CSSC 110 via a separate control channel over the local network. The Content Scheduler 112 in the CSSC then updates the Enforcer Table in the Receiver 120, allowing that channel to be tuned. Once the customer is allowed to watch a channel, the tune request for that channel is transformed into a RTSP Request by the RTSP Client 126 and is sent over the local network to the RTSP Server 106 in the DSCD 102.
The DSCD 102 decides if the RTSP Request is for local content or satellite content depending on the tuning information contained in the RTSP request. If it is for a satellite channel, then the DSCD 102 makes sure that the requested channel is present in an IP Multicast on the local network. It then responds to the Receiver 120 with the IP Multicast Address to which the Receiver 120 should tune to receive the requested AV stream. If it was a request for stored content, the DSCD 102 sends an RTSP response back to the Receiver 120 with the IP multicast address of the AV stream for that local channel. In either case, the Receiver 120 then uses Internet Group Management Protocol (IGMP) to join the correct IP multicast stream.
An implementation of the LCI System for a US Satellite Broadcast system exists in the market. It is desired to modify the system for other markets, in this example, Brazil. There are several differences between the Brazil Satellite broadcasts and the US Satellite broadcasts that create the need for modifications to the Local Content Insertion (LCI) subsystem. DVB-S transport is used for video streams instead of Legacy transport stream. DVB-S transport is used for EPG streams instead of Legacy transport stream. The transponder frequencies and polarities for the Brazil Network 0 are different than those used the US Network 0. The transponder to frequency index mapping for the Brazil Satellite System's Network 0 cannot be represented by a formula like the US system. The current Brazil transponder mapping may not be stable.
Turning now to FIG. 2, a data flow diagram 200 showing EPG streams, AV Streams, and related RTSP traffic between various functions for the US AV Entertainment System is shown. For this exemplary embodiment, Local Content Insertion will be used interchangeably with “Local Content.” The AV Streams for the US Satellite System are based on a legacy transport stream format that existed before MPEG2-TS. Further, for this exemplary embodiment, these transport streams are similar to MPEG2-TS. Similarly, for the purposes of these system descriptions, Service Channel ID (SCIDs) and Program Identifiers (PIDs) are functionally equivalent. SCIDs are used in Legacy Transport Streams. PIDs are used in MPEG2 Transport Streams. The frequency_index to transponder mapping for US Market Satellite Network 0 is available from the satellite service provider. For US Network 0, the frequency_index to the transponder frequency and polarity mapping follows a formula.
The polarity can be determined from the frequency_index. For even frequency_indexes, the polarity is Right Hand Circular Polarization (RHCP) and for odd frequency_indexes, the polarity is Left Hand Circular Polarization (LHCP). The Satellite AV Streamer 212 in the DSCD 210 receives the satellite streams 211 and packages them into RTP packets and sends onto the network using an IP Multicast Address from the pool of addresses reserved for satellite streams 213.
Local AV content is stored on a local storage device 207. This content may for stored in MPEG format or converted before coupling to the Local AV Streamers 209. Local AV Streamers 209 package MPEG Transport Streams into IP LCI Multicasts 215. Each Local AV Streamer 209 continually sends the local multicast RTP audio/video packets as long as the stream is not paused by the Master Controller 206 in the CSSC 205.
Out of the IP addresses reserved for LCI Multicasts 215, the first 3 addresses are reserved for Local EPG streams 216. The remaining multicast addresses, reserved for local AV content, are used for streaming audio/video RTP packets for local channels according to a formula.
The Channel_OID_offset for each channel is specified in a data structure loaded by the Content Scheduler. In this exemplary system, the data structure is represented by a Local Guide XML file. The complete 32-bit Channel OID for a channel is determined by adding the Channel_OID_offset to a Base Local Channel_OID. In this exemplary system, the Channel_OID_offset can range from 0 to 0x3F. This limits Local Channel OIDs to a range.
The local content AV Streamer 209 uses the same multicast address for audio and video data. The LCI channels are expected to use only values for audio/video SCIDs that are reserved for that purpose. That current range consists of 16 SCIDs.
The following parameters corresponding to the LCI Network are stored in a LCI configuration file used by the Local AV Streamers 209 and EPG Generator 208 in the CSSC 205. Corresponding parameters are stored in a configuration file in the DSCD 210 for use by the RTSP Server 214. The corresponding parameters must match so that the IP Multicast Addresses distributed by the DSCD 210 match the addresses used for the LCI multicasts 215.
Satellite EPG Streams are received by the DSCD and are forwarded onto the network after IP encapsulation in the same way as Satellite AV Streams 213. The satellite EPG Boot Stream includes a Satellite_Descriptor (SD) that contains a table that maps from frequency_index to RF-band selection and tuning parameters. Although a SD describing Network 0 will most likely be present in the Satellite EPG Boot Stream, a default view in the receiver is used if the SD is not found. Both tune requests for Satellite channels and LCI channels use these tune parameters from the SD for tune requests. The (mxuLciConfigMultilpBase+0) multicast address is used for a local Boot Stream when no satellite is present. The (mxuLciConfigMultilpBase+1) multicast address is reserved for the fast load EPG stream. The (mxuLciConfigMultilpBase+2) multicast address is reserved for the broadcast carousel EPG stream.
In the exemplary US System, the US satellite service provider transmits an Additional Network Descriptor (AND) with the reserved network_ID=0xfffe to facilitate Local Content Integration. The AND is carried in a special Channel Object with a specific reserved Channel Object ID (COID). In this example, that number is 0x400000. The CO is also referenced in the Update List Object. In the exemplary system described here, the middleware of the Receiver can be modified, so the actual AND is not required. However, an advantage of some options is that they do not require middleware modifications. Some of these satellite objects aid in middleware independence.
The Local EPG is created and transmitted by the Local EPG Generator 208. Local Channel Objects are constructed to carry the information required to tune the associated AV stream. A unique Channel_OID_offset (COID_offset) is associated with each CO carried in the LCI EPG streams. The Local EPG Generator uses information from the Local Guide XML file provided by the Content Scheduler along with configuration file parameters to calculate the frequency_index and SCID range for each of the local channels using the formulas described next. In this implementation, the network_id is always 0xFFFE. This information is placed in the Channel Objects (COs) carried in the Local EPG streams.
A COID for a LCI channel will be in the range reserved for local channels. Its SCIDs are also in the range reserved for local channels. The COID_offset for each channel is specified in the Local Guide XML file generated by the Content Scheduler in the CSSC. The full COID is determined as previously described. Local EPG Channel Objects include the COID, frequency_index, SCIDs, and network_id. The frequency_index and SCID range will both be determined from the Channel_OID_offset using a formula. The formula uses some of the same configuration parameters shown in Table 1. In particular, the key parameters in the formula are PID Base SCID (PBS), SCIDs per Channel (SPC) and LCI SCID Range (LSR). A unique Channel_OID_offset is provided for each channel by the Content Scheduler.
The middleware of the Receiver 220 derives RF-band Selection and tuning parameters from the EPG database and user's selection. The satellite EPG includes a Satellite_Descriptor (SD) that contains mappings from frequency_index to RF Band Selection and tuning parameters. The Receiver 220 stores this EPG data 222 for the purposes of deriving RF selection and tuning parameters from the CO associated with a chosen channel. Also as previously stated, a channel is referenced to a specific network, frequency_index, and SCIDs in the associated CO.
For the exemplary US system, the Local Network, which is Network 0xFFFE, is overlaid onto Satellite Network 0 (i.e., channels are members of Network 0xFFFE, but streams are found on Network 0). Therefore, Network 0 tuning parameters are used. This is accomplished by placing Transmit Network Descriptors (TND) that point to Network 0 for physical tuning information into each LCI Channel Object. The Receiver uses its view of Network 0 to turn information found in a CO into RF band selection and tuning information, even if from a Local CO.
The RF-band selection and tuning parameters are intercepted by the Receiver's 220 physical network determiner 225 to create an RTSP request 228 instead of directly controlling HW. The p does not pass the network_id in the tuning parameters. The network_id is used in the RTSP requests 228 and must be derived from the tuning and band selection information.
The Receiver 220 puts the physical network_id, tuning frequency, and polarity in the RTSP Request 228 to the RTSP Server 214 in the DSCD 210. For the US System, the network_id could be 0, 1, 2, 3, 7, 10, 11, 14, or 15, but will always be 0 for the local content. For Network 0, the tuning Frequency and polarity are derived from the frequency_index and the STB's view of Satellite Network 0, which is based on the SD received from the satellite or by default.
When a user wants to tune a particular channel, the Receiver RTSP Client 226 sends a RTSP request 228 to the RTSP Server 214. If the RTSP setup request from the Receiver 220 is for a valid network, the request is checked for local channel SCIDs. The Video SCID is the first SCID listed in the applicable Local CO and in the RTSP Request. If the request meets the following criterion then it is considered a local channel request and processed different than satellite channels. RTSP setup requests related to local channels can be a request for local channel guide fastload object. This is indicated by SCID value from request matching with mxuLocalFastLoadScid and frequency index from request matching with mxuLocalFastLoadTransponder. In this case, the reply is sent with multicast address=(mxuLocalMultilpBase+1). Additionally, setup requests related to local channels can be a request for local guide carousel object. This is indicated by scid value from request matching with mxuLocalCarouselScid. In this case, the reply is sent with multicast address=(mxuLocalMultilpBase+2) or s request for local channel video or audio data. This is indicated when the SCID value from the request is in the reserved SCID range (i.e., mxuLciConfigScidBase≦SCID≦mxuLciConfigScidBase+mxuLciConfigScidRange−1).
The RTSP request 228 does NOT include the frequency index. It instead includes frequency and polarity. Therefore, to determine the AV IP multicast address, the RTSP Server first calculates the frequency_index. For AV Streams, The RTSP Server calculates an offset from the frequency index and the Video SCID. The IP multicast address carried in the RTSP Response 227 matches the address used to stream the content referenced by the Local CO from the Local EPG since the EPG Generator 208 and RTSP Server 214 use the same formulas and same values in analogous parameters.
The Brazil Satellite EPG streams follow the same basic EPG specification as the US system, except that the EPG Objects are carried in a MPEG2-TS instead of the US Satellite Legacy Transport Stream. In addition to EPG object encapsulation being different, slightly different EPG objects are also used. For example, the channel objects reference streams using 13-PIDs instead of 12-bit SCIDs. However, these differences are not important for the concepts here, so the previous EPG objects will continue to be used in the discussion.
Currently, the Brazil Satellite Transponders in the Brazil Network 0 are different than the exemplary US system previously described. The Brazil freq_index to transponder frequency and polarity mapping does not follow a formula as the US Network 0 does. There are only 18 transponders instead of 32. Also, the polarities of the transponders are specified as Vertical or Horizontal instead of RHCP or LHCP.
Three possible options are proposed to continue to use the US Satellite freq_index formula with the LCI Network placed on an unused network instead of being overlaid onto one of the satellite networks (i.e., Network 0 in the case of Brazil). These modifications are described in more detail in the following exemplary embodiments. The first places the LCI Network on Network 0xFFFE. The CSSC places the LCI channels on Network 0xFFFE by leaving the Transmit Network Descriptor out of the LCI EPG Channel Objects.
The AV Streams for the Brazil Satellite System are based on DVB-S, which is compliant with the MPEG2-TS specification. Unlike the US Satellite System, the Brazil Satellite System's Network 0 frequency_index to transponder frequency/polarity mapping does NOT follow a formula. The IP multicast addresses for the LCI Subsystem are determined as previously described for the US System. It is expected that the same value for the configuration parameters will be used resulting in e.g., 64 LCI Channels.
The Satellite EPG includes an Advanced Satellite Descriptor (ASD) in the Advanced Boot Stream that contains a mapping from logical parameters, such as frequency_index, to RF-band selection and tuning parameters. Although a ASD describing Network 0 will most likely be present in the Satellite EPG Boot Stream, a default view in the receiver is used if the ASD is not found. The satellite EPG includes an Advanced_Satellite_Descriptor (ASD) that contains mappings from frequency_index to RF-band selection and tuning parameters. The Receiver 220 stores this table for the purposes of deriving RF selection and tuning parameters from the CO associated with a chosen channel. A channel is referenced to a specific network, frequency_index, and PIDs in the CO.
In this exemplary embodiment the Local Network will not be overlaid over Satellite Network 0 as was done in the US system. Instead, since the channels are already members of Network 0xFFFE, they will be mapped onto a new Virtual Network 0xFFFE that uses the same transponder mapping as the US System). The Receiver 220 uses its view of Network 0 and Network 0xFFFE to turn the information in the COs into RF band selection and tuning information, even if based on a Local CO. This is accomplished with a minor change in the Local EPG structure. To use 0xFFFE for the local network ID in the Brazil System, the following changes relative to the US System can be made. The Local EPG Generator 208 in the CSSC should omit “Transmit Network Descriptor” from the Local EPG Streams 216. This will cause the Receiver 220 to use the Network 0xFFFE frequency_index mapping. The Receiver 220 needs a default view of the local network 0xFFFE since it will not receive a Satellite Descriptor for that network when the boot stream originates from the satellite broadcast. It is possible to include an additional Satellite Descriptor to describe Network 0xFFFE when using the Local Boot Stream, but that is only used when satellite service is not available. DSCD 210 will need to be configured or modified to consider 0xFFFE to be a valid network so that the RTSP Server 214 responds to RTSP Requests 228 from Receivers 220 for local channels. Also, for satellite content, the Brazil Receiver will need default view of the BrazilNetwork 0. However, this independent of the option used for the Brazil LCI subsystem implementation.
In this exemplary Brazil System, requests for local content will be for channels on Network 0xFFFE and requests for satellite content will be for channels on Network 0. In this case, the Receiver tuning SW can tell that a request is for Network 0xFFFE if the polarity is RHCP or LHCP. The tune request is for Network 0 if the polarity of the requested transponder is Horizontal or Vertical. The same frequency_index to transponder frequency/polarity mapping used for the US System's local channels will continue to be used for local channels this option. For all options, the Brazil Receiver algorithm must allow frequencies as high as 1.632 GHz instead of cutting it off at 1.45 GHz. See the simplified table below, which shows the modifications:
For the Brazil Satellite System, the only satellite network is Network 0. It uses Vertical and Horizontal Polarizations. There are vertical and horizontal transponders at each frequency. In this option, the Local Network will be Network 0xFFFE and will continue to use LHCP and RHCP polarizations. However, RHCP and LHCP use different frequencies, so the LHCP and RHCP information is not really needed in this option.
The high-level functionality of the RTSP Server that resides in the DSCD is basically the same as that for the US System. The major difference is that Network 0 will be used for satellite channels only. The local channels will all be on Network 0xFFFE and will continue to use the same transponder mapping that was used in the US System. The DSCD is modified (or configured) to consider 0xFFFE a valid network so that the SAP announcing service for that network will be sent to the Receivers on the network.
If the RTSP setup request from the Receiver 220 is for a valid network, the request is checked for local channel PIDs. If the request is for one of the PIDs reserved for LCI, then it is considered a local channel or EPG request and processed different than satellite channels. One possibility is to have local channel tuner parameters are associated with Network 0xFFFE instead of Network 0. To use 0xFFFE for the local network ID in the Brazil System, the Local EPG Generator in the CSSC should omit “Transmit Network Descriptor” from the LCI Fast Load EPG Stream. Additionally, the DSCD will need to be configured or modified to consider 0xFFFE a valid network so that the RTSP Server responds to those RTSP Requests and include Network 0xFFFE in the Network SAP. If configuration is used, then one tuner should be configured to belong to Network 0xFFFE. It could be LHCP or RHCP since the Proxy Server Network SAP does not include “X-dsfe-count,” which is used to designate the number of tuners of each polarity for Streamer Network SAPs. This adds 0xFFFE as a valid network and would cause Network 0xFFFE to be included in the Network SAP from the DSCD. The SAP contains the IP address of the Gateway. If the DSCD is modified, then it must recognize 0xFFFE as a valid network (maybe based on the LCI config parameter) and it must include Network 0xFFFE in the Network SAP. The Receiver will need a default view of the local network 0xFFFE since it will not receive a Satellite Descriptor for that network when the boot stream originates from the satellite broadcast. Receiver front-end SW must be modified to designate 0xFFFE as the local network. There may be some additional receiver modifications.
Alternatively, local channels may be associated with Network 0x0001 instead of Network 0. The use of Network 1 The advantage of this is not having to check to see if the Receiver 220 can deal with a network_id as high as 0xFFFE. To use 0x0001 for the local network ID in the Brazil System, the Local EPG Generator in the CSSC should place 0x0001 as the network_id in the “Transmit Network Descriptor” of the Advanced Channel Objects in the LCI EPG Streams. DSCD will need to be configured or modified to consider 0x0001 a valid network so that the RTSP Server responds to those RTSP Requests and include Network 0x0001 in the Network SAP. If configuration is used, then one, possibly two, tuner(s) should be configured to belong to Network 0xFFFE. If one works, it could be LHCP or RHCP since the Proxy Server Network SAP does not include “X-dsfe-count,” which is used to designate the number of tuners of each polarity for Streamer Network SAPs. This adds 0x0001 as a valid network and would cause Network 0x0001 to be included in the Network SAP from the DSCD. The SAP contains the IP address of the Gateway. If the DSCD is modified, then it must recognize 0x0001 as a valid network (maybe based on the LCI config parameter) and it must include Network 0x0001 in the Network SAP. The Receiver will need a default view of the local network 0x0001 since it will not receive a Satellite Descriptor for that network when the boot stream originates from the satellite broadcast. Receiver front-end SW must be modified to designate 0xFFFE as the local network. There may be some additional receiver modifications.
Another possible option for modification to the US system is that the LCI will remain overlaid over Network 0. The CSSC will leave the LCI channels on Network 0 by leaving the transmit Network Descriptor in the LCI Fast Load Stream. The Brazil Satellite Network 0 uses different transponders and transponder mapping than is used for US network 0. Since the LCI channels can be distinguished from the Satellite channels based on the PID range or Channel OID, the Receiver SW can treat such requests as an LCI request.
The AV Streams for the Brazil Satellite System are based on DVB-S, which is compliant with the MPEG2-TS specification. The multicast addresses for the LCI Subsystem are determined as previously described for the US System. It is expected that the same value for the configuration parameters will be used resulting in the same IP Multicast Address allocation shown in the description of the US System
According to another exemplary embodiment, the Satellite EPG includes Advanced_Satellite_Descriptors (ASD) in the Advanced Boot Stream that contains a mappings from logical parameters, such as frequency_index, to RF-band selection and tuning parameters. Although a ASD describing Network 0 will most likely be present in the Satellite EPG Boot Stream, a default view in the receiver is used if the ASD is not found. The Receiver stores a table of information for the purposes of deriving RF selection and tuning parameters from the CO associated with a chosen satellite channel. A channel is referenced to a specific network, frequency_index, and PIDs in the CO.
Accordingly to this exemplary embodiment, the Local Network will continue to be overlaid over Satellite Network 0 as was done in the US system. However, since the transponder mapping for the satellite channels and local channels are different but both are Network 0, the Satellite Network and the Local Network must be distinguished in some other way within the Receiver. Since the LCI channels use a reserved PID range, LCI channels can be distinguished from the Satellite channels based on the PIDs in the channel request. The Receiver SW will need modifications to examine PIDs (not normally done) and if it is a request for an LCI channel, it must use the LCI transponder mapping to derive frequency and polarity.
To use 0x0000 for the local network ID in the Brazil System, the following changes relative to the US System can be made. The Local EPG Generator in the CSSC should continue to include the “Transmit Network Descriptor” that points toward Network 0 in the Channl Objects in the Local EPG Streams. Therefore, no change is made in the CSSC between the US System and Brazil System. The Receiver needs to check the PIDs in channel tune requests and if the PIDs are in the reserved range for local channels, it must use the transponder frequency and polarity using the formula for the US Network 0. This would be a change to Receiver's middleware.
Also, for satellite content, the Brazil Receiver will need default view of the BrazilNetwork 0. However, this is independent of the option used for the Brazil System implementation. The Receiver's view of LCI Network 0 would be the same as for LCI Network 0xFFFE in Option 1 with the additional restriction on PIDs.
In this exemplary embodiment for the proposed Brazil System, requests for local content will be for channels on Network 0. Since the LCI channels use PIDs from a reserved range, the Receiver uses the PIDs to isolate requests for satellite channels from local channels. If the request is for a satellite channel, the Receiver determines the frequency and polarity of the tune request by indexing into the table loaded by the Advanced Satellite Descriptor from the satellite EPG. Note that in that case, the polarities are vertical or horizontal. If the request is for a local channel, the Receiver will use the formula that represents the transponder mapping. Note in that case the polarities are RHCP or LHCP. The RTSP Requests constructed in the Receiver have the Network ID in the RTSP Request set to 0 for both local and satellite channels.
The high-level functionality of the RTSP Server 214 that resides in the DSCD 210 is basically the same as that for the US System. The RTSP Server 214 will continue to distinguish local channel requests from satellite channel requests based on the PID range. Deriving the frequency index from the transponder frequency for RTSP Requests for local channels is the same as the US System. Calculating the IP Multicast Address is also the same as the US System for this option.
For this exemplary embodiment, the LCI will remain overlaid over Network 0. The CSSC will leave the LCI channels on Network 0 by leaving the transmit Network Descriptor in the Local EPG Streams. LCI continues to use frequency_indexes 0-31 and the US Network 0 frequency_index formula. The Brazil Satellite Network 0 uses different transponder frequencies and frequency_index mapping than is used for US Network 0. Since the LCI channels can be distinguished from the satellite channels based on the PID range, the Receiver SW must treat requests for channels with PIDs in the reserved range as LCI requests. This requires a modification to the middleware/application in the Receiver. If the RTSP server continues to use PID range to determine LCI vs. Satellite, then no change is needed in the DSCD. Local Channels will continue to be associated with Network 0. The US Network 0 formulas would continue to be used.
The Receiver 220 would be modified to recognize LCI PID range and create proper RTSP request parameters. The Receiver 220 would recognize PID range or LCI channel object ID range. Branch into a part of the code that then generates the correct LCI tuning frequency for the frequency index in the applicable Channel Object. PID Range should be configurable (LCI Base PID and LCI PID Range), possibly stored in EEPROM. The receiver would determine LHCP vs. RHCP from frequency_index. Additionally, the receiver would pPass tune frequency & polarization down to the RTSP Client layer. Network number should be correctly determined by the front end SW by examining the polarization. The receiver 220 would modify the Physical Network Determination 224 algorithm to return network 0 when presented with LCI tune frequencies. The Receiver middleware/application may also need a modification to properly display both LCI and Satellite Channels, which are both on Network 0. The Satellite Descriptor only contains reference to 18 transponders, not 32.
In this second exemplary embodiment, the Local Channels will use 32-63 for frequency indexes. The Receiver would need to be modfied to allow more than 32 frequency indexes per Network, in this case up to 64. Note that the frequency indexes in Channel Objects use 8 bits. The Receiver would not need to be modified to filter tune requests based on PIDs. Instead, it would have one large view of Network 0 with satellite transponders in the lower range and local transponders in the upper range. The Receiver could therefore operate in the normal way except for the larger number of frequency indexes. Therefore, there is no need for configuration parameters in the Receiver for LCI Base PID and LCI PID Range. The Receiver would need to be modified to leave the default transponders in the upper range (i.e., 32-63) while replacing the transponder entries in the lower range (i.e., 0-31) when it receives the Advanced Satellite Descriptor from the Satellite. The Frequency Index formula would be the same except it would be offset by the constant 32.
A third exemplary embodiment has the local channels mapped onto Brazil Satellite Network 0. This has the disadvantage of creating a dependence of the operation of the local system on the satellite transponders mapping, which may change. However, this option has some advantages, not the least of which is ease in implementation based on the current SW. It is a direct application of all high-level concepts from the US system to the Brazil System. In this case, the US frequency_index formula used in the US system and the first 2 options is not used at all. In Option 3, Brazil Satellite Network 0 “frequency_index to transponder frequency/polarity map” is used for LCI in the same way that the US Network 0 “frequency_index to transponder frequency/polarity map” is used for LCI in the US system.
The PIDs that have already been requested of the Brazil Service Provider for LCI may be used for this exemplary embodiment. To allow enough channels, the entire range of 18 transponders is used. To allow flexibility in the future, the DSCD 210 is modified to allow the transponder map to be loaded via a file during startup. The AV Streamer 209 and EPG Generator 208 in the CSSC 205 would need a new configuration parameter on the number of LCI transponders used or would at least need to be limited to 18 available transponders. Using this option the system can have a 2^ndphase where the DSCD 210 would automatically acquire the ASD from the Satellite EPG Boot Stream. This would eliminate the need to manually update the transponder map file if the frequency_index to frequency/polarity mapping changes someday. For this exemplary embodiment, only one frequency index is used such as the Boot Transponder. To allow enough channels, a new wider range of PIDs reserved for LCI would need to be used. Note that since PIDs are 13-bits instead of 12, there are twice as many PIDs as SCIDs. Anyway, additional reserved PIDs would need to be negotiated with the Brazil Service Provider.
As with the other exemplary embodiments, the same IP Multicast Address Allocation formula and related configuration parameters that are used in the US Satellite System will continue to be used. Since there are only 18 frequency_indexes in the Advanced Satellite Descriptor (ASD) instead of 32, only 36 channels are supported using the same 8 PIDs per channel. An approach that would allow continued support of at least 64 channels would be to use less audios per channel. This could facilitate 4 channels per transponder.
In this exemplary embodiment, the Local Network will continue to be overlaid onto Satellite Network 0 as was done in the US system. Both Satellite Network 0 and the LCI Network will use the frequency_index to frequency/polarity mapping in the satellite ASD.
In this third exemplary embodiment, the physical network determiner 224 derives RF Band Selection and Tuning Parameters from the EPG database and the user's selection. The RF Band Selection and Tuning Parameters are intercepted by “hijacked-layer” SW in the Receiver 220 to create an RTSP request instead of directly controlling HW. The Physical Network number for the RTSP Request is determined in Receiver front end SW in the US system where the routine should return Network 0 for Satellite and LCI channels, with some error checking.
The Receiver 220 puts the Physical Network ID, Tuning Frequency, and Polarity in the RTSP Request to the RTSP Server 214 via the RTSP client 226. For this option, the Network ID will always be 0. The tuning Frequency and Polarity are derived from the frequency_index and the Receiver's view of Network 0. The RTSP Server 210 will continue to distinguish local channel requests from satellite channel requests based on the PID range. The main difference between this option and the US System is that for this option, the RTSP Server in the DSCD uses a reverse table lookup to find the frequency index from the transponder frequency and polarity that was received in the RTSP request. Since the frequency_index cannot be determined from frequency alone, both frequency and polarity must be used to determine the frequency_Index. Since there is no apparent formula, the function is table driven. Once the frequency_index has been determined, calculating the IP Multicast Address is the same as the US System.
In this option, the LCI will remain overlaid over Satellite Network 0. The CSSC leaves the LCI channels on Network 0 by leaving the Transmit Network Descriptor in the LCI EPG Channel Objects. However in this option, the Brazil Satellite System transponder mapping is used instead of the US Network 0 transponder mapping. In this case, no modification is needed in the Receiver since it simply takes the information from the LCI Channel Objects, and based on the LCI Transmit Network Descriptor, assumes that the logical tuning information in the Channel Object refers to the physical tuning parameters for the Brazil Satellite Network 0. Local Channels will continue to be distinguished from satellite channels based on the LCI Reserved PID Range.
Since it is possible that the frequency index map that is carried in the ASD and is used in the Receiver may change sometime in the future, the inverse frequency index map that is used by the RTSP Server 214 in the DSCD 210 to determine the proper IP Multicast Address must be able to be updated. In the first phase, this update can happen manually. The application in the DSCD 210 reads a file at startup for the frequency map. If that map changes, then the file would need to be manually updated.
Since it may not be immediately obvious that the frequency map has changed the system would have a method to update its view of the frequency index map automatically. Note that for other reasons, the FPGA in the DSCD 210 already parses the Satellite Frequency Identification Stream to retrieve Marker Objects. It would be a straightforward modification of the FPGA to also parse the Boot stream enough to retrieve the Advanced Boot Object that carries the Advanced Satellite Descriptor. The ASD carries the same frequency index map that would be used in the Receiver. So, such a modification solves the issue of the Transponer Map possibly not being stable.
Alternatively, for this exemplary embodiment, only one Transponder may be used if the Boot Transponder does not change. This eliminates the need to use the frequency index map if the stability of the map is not an issue. The requirements for the number of channels and audio streams per channel is met by using a large number of PIDs. For example, to support 64 channels with up to 3 audios per channel requires 256 PIDs.
LCI Multicasts can use the same formula and configuration parameters to determine multicast addresses that are used in the US system. However, there is only 1 frequency_index used in this option. Since PIDs are 13-bits instead of 12, there are twice as many PIDs available as SCIDs. The PIDs used for LCI must be reserved on at least Transponder 0. More audios per channel can be supported with more reserved PIDs. The Receiver's 220 view of Network 0 is controlled by the Advanced Satellie Descriptor received on the Satellite broadcast.
Turning now to FIG. 3, a flowchart that illustrates an exemplary embodiment of a method for inserting local content into satellite broadcast programs and EPG on a network according to the present invention is shown. At startup, the system according to the present invention receives a frequency index to transponder mapping from a satellite service provider 320. The system further loads a table of local content multicast addresses. The system then waits for an RTSP request from a receiver 330.
Once the head end receives an RTSP request from a receiver for locally stored content, the system determines the corresponding multicast address for the requested locally stored content 340. The system then transmits this multicast address to the receiver 350. The system then transmits the locally stored content to the receiver 360. This continues until a request to stop the transmission is received from either the receiver or a master controller 370.
It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software or combinations thereof. Preferably, these elements are implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces.
The present description illustrates the principles of the present disclosure. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the disclosure and are included within its spirit and scope.
All examples and conditional language recited herein are intended for informational purposes to aid the reader in understanding the principles of the disclosure and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.
Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herewith represent conceptual views of illustrative circuitry embodying the principles of the disclosure. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (“DSP”) hardware, read only memory (“ROM”) for storing software, random access memory (“RAM”), and nonvolatile storage.
Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.
Although embodiments which incorporate the teachings of the present disclosure have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings. Having described preferred embodiments for a method and system for the 3D visualization of a disparity map (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings.

Claims

1. A method comprising the steps of:

storing a frequency index map for local AV programs;

receiving a request for an audio video program according to said frequency index map and PIDS in a range reserved for local AV programs;

determining that the request is for local programming based on the reserved PID range

determining a multicast address corresponding to said audio video program base on the frequency index and PIDs; and

transmitting said multicast address.

2. The method of claim 1 wherein said frequency index map includes at least one of satellite transponder information, frequency information, and polarity information.

3. The method of claim 1 wherein said frequency index map is associated with a satellite broadcast.

4. The method of claim 1 wherein said frequency index map can be manually updated.

5. The method of claim 1 further comprising the step of parsing and storing an updated frequency index map in response to receiving a new frequency index map.

6. The method of claim 1 wherein said multicast address multicast address is a logical identifier for a host of locally stored content.

7. The method of claim 1 further comprising the step of streaming said audio video program.

8. The method of claim 1 wherein said frequency index map is received via a satellite signal.

9. An apparatus comprising;

a first input for receiving a frequency index map;

a second input for receiving a request for an audio video program according to said frequency index map;

a processor for determining a multicast address corresponding to said audio video program; and

a transmitter for transmitting said multicast address.

10. The apparatus according to claim 9 wherein said frequency index map includes at least one of satellite transponder information, frequency information, and polarity information.

11. The apparatus according to claim 9 wherein said processor is further operative to store a transponder frequency index map for local AV programs associated with the reserved local AV network ID and send an RTSP request for local AV content that includes the frequency index from said stored frequency index map.

12. The apparatus according to claim 9 wherein said audio video program is locally stored content.

13. The apparatus according to claim 9 wherein said multicast address multicast address is a logical identifier for a host of locally stored content.

14. The apparatus according to claim 9 further comprising the step of streaming said audio video program.

15. The apparatus according to claim 9 wherein said frequency index map is received via a satellite signal.

16. A satellite signal head end comprising;

storing a transponder frequency index map for local AV programs;

receiving a request for an audio video program according to a reserved network ID and frequency index from said frequency index map;

determining that the request is for local programming based on the said reserved network ID in the request.

determining a multicast address corresponding to said audio video program based on frequency index and PIDs; and

transmitting AV program on said multicast address.

transmit response to said request that includes the multicast address carrying the local AV program.

17. The satellite signal head end according to claim 17 wherein said frequency index map includes at least one of satellite transponder information, frequency information, and polarity information.

18. The satellite signal head end according to claim 17 further comprising the steps of:

sending an RTSP request for local AV content that includes the frequency index from said stored frequency index map and wherein said storing a transponder frequency index map for local AV programs is associated with the reserved local AV network ID;

19. The apparatus according to claim 9 wherein said multicast address is stored in a table and is a logical identifier for a host of locally stored content.