Patent Abstract:
Methods and apparatus are disclosed to broadcast advanced television system committee (ATSC) video in switched digital video (SDV) systems. An example SDV broadcast method includes configuring a de-multiplexer to de-multiplex at least one of the plurality of MPTSs into a plurality of program streams, the at least one of the plurality of program streams comprising a first program stream and a second program stream, wherein the first program stream is selected and the second program stream is excluded based on a rating region table (RRT), independent of any user provided program stream request, and independent of any contractual commitment associated with any user. The example method includes configuring a switch to deliver the first program stream to an SDV broadcast engine.

Full Description:
RELATED APPLICATION 
     This patent arises from a continuation of U.S. application Ser. No. 11/112,299, which was filed on Apr. 22, 2005 and is hereby incorporated herein by reference in its entirety. 
    
    
     FIELD OF THE DISCLOSURE 
     This disclosure relates generally to switched digital video (SDV) systems, and, more particularly, to methods and apparatus to broadcast Advanced Television System Committee (ATSC) video in SDV systems. 
     BACKGROUND 
     The amplitude modulated (AM)-vestigial sidebands (VSB) 6 Megahertz (MHz) television (TV) broadcast system only supports one standard definition video channel plus a pair of stereo audio channels and two auxiliary audio channels. In 1995, the Federal Communications Commission (FCC) adopted the Advanced Television System Committee (ATSC) broadcast standards for digital TV (DTV) (e.g., A/53B, A/65B, A/90, etc.). With support of motion picture experts group (MPEG) multiple program transport streams (MPTSs), the ATSC DTV standards include dynamic support for and transport of one or more program streams (e.g., each containing video plus audio) within a single 6 MHz broadcast channel. For example, a broadcaster may simultaneously provide a football game, a local news program, and weather information within a single MPTS. The ATSC DTV standards support an effective payload of approximately 19.3 Megabits per second (Mbps) for a terrestrial 6 MHz broadcast channel or approximately 38 Mbps for a 6 MHz cable broadcast channel. 
       FIG. 1  is a schematic illustration of an example prior art transmitter  100  for the prior art ATSC DTV broadcast system. A plurality of application encoders  105  principally perform data compression and encoding for a plurality of sources  110  (e.g. video, audio, data, etc.) to reduce the number of bits required to represent the sources  110 . For example, the ATSC DTV system uses MPEG-2 compression for video sources and the ATSC compression standard (AC-3) for audio sources. A plurality of outputs  115  (i.e., program streams) of the application encoders  105  are provided to a transport packetizer and multiplexer (TPM)  120  that divides each of the program streams  115  into packets of information (including the addition of uniquely identifying information) and multiplexes the plurality of packetized program streams  115  into a single MPTS  125 . The TPM  120  also receives, packetizes, and multiplexes program and system information protocol (PSIP) information  127  into the MPTS  125 . Finally, a modulator  130  uses the MPTS  125  to modulate a carrier to create a radio frequency (RF) transmission  135 . The modulator  130  uses either 8-VSB or 16-VSB. Example implementations of the application encoders  105 , the TPM  120 , and the modulator  130  are well known to persons of ordinary skill in the art, and, thus, will not be discussed further. 
     The PSIP information  127  (as defined in ATSC standard A/65A) is a small collection of hierarchically arranged tables designed to operate within every MPTS to describe the programs carried within the MPTS. There are two main categories of PSIP information  127 : system information and program data. System information allows navigation and access of the channels (i.e., program streams) within the MPTS, and program data provides necessary information for efficient selection of programs. Some tables announce future programs, and some are used to logically locate current program streams that make up the MPTS. 
       FIG. 2  is an example set of PSIP information tables  200  illustrating the relationships between the various tables. The master guide table (MGT)  205  provides indexing information for the other tables. It also defines table sizes necessary for memory allocation during decoding, defines version numbers to identify those tables that are new or need updating, and generates the packet identifiers (PID) that label the tables. For example, MGT  205  entry  207  points to the zero th  (i.e., original) version of a ratings region table (RRT)  210 . The RRT  210  is designed to transmit the ratings system in use for each country. For example, in the United States the RRT  210  represents the television parental guidelines (TVPG), more commonly referred to as the “V-chip” system. A system time table (STT)  215  is a small data structure that serves as a reference for time of day functions, e.g., to manage scheduled events, display time-of-day, etc. 
     A virtual channel table (VCT)  220  contains a list of all the channels that are or will be active, plus their attributes, e.g., channel name and number. Event information tables  225   a - b  describe the program(s) for a time interval of three hours. There may be up to 128 EITs, EIT-0 through EIT-127, allowing for up to 16 days of programming to be advertised in advance. 
     Example implementations of generating PSIP information, PSIP tables, PSIP packets, and decoding PSIP information and tables are well known to persons of ordinary skill in the art and, in the interest of brevity, will not be discussed further. 
       FIG. 3  further illustrates information contained in the VCT  220 . In the example table, Short Name is typically displayed in the upper corner of a TV screen to identify a channel and Type indicates the type of channel. Major Channel indicates a 6 MHz RF broadcast channel, with Minor Channel indicating sub channels. Source ID provides a PID within a MPTS, and Extended Names are typically displayed in an electronic program guide (EPG). The VCT  220  facilitates selection and location of programs by a receiver or a user of a set-top box or television. The VCT  220  can be updated in real-time so that situations like over-time (OT) in sporting events can be supported in addition to the regularly scheduled programs, reducing the number of times that programs are “joined in progress.” 
       FIG. 4  illustrates an example portion of a programming line-up transported in a MPTS showing how bandwidth of the MPTS could be utilized to support multiple simultaneous programs. The example of  FIG. 4  conveys several points: 
     1. Bandwidth requirements are dynamic. In the case of nondeterministic programs, like sports, an allocation may change on a moment by moment basis. 
     2. The number of programming streams will change as programming options change. 
     3. The UT vs. A&amp;M OT situation underscores the dynamic nature of the MPTS. 
     4. Services such as Weather Graphics, Text and other low bit rate services may also be supported. 
     5. Names of channels may change as the programming line up changes. 
     The PSIP tables provide the necessary information so that an EPG can be created and/or updated, but also so that a receiver can locate, select and display programs. There are several subtle differences that exist between the PSIP protocols for terrestrial broadcast and the cable multiple service operator&#39;s PSIP. These slight differences are standardized, well understood by those of ordinary skill in the art, and, will not be discussed further. However, a device supporting both terrestrial and cable broadcasts, must support both forms of PSIP information. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic illustration of an example prior art transmitter for the prior art ATSC DTV broadcast system. 
         FIG. 2  is an example of the relationships among PSIP tables for the prior art ATSC DTV broadcast system. 
         FIG. 3  further illustrates example information contained in the VCT of  FIG. 2 . 
         FIG. 4  shows an example bandwidth utilization of a MPEG MPTS. 
         FIG. 5  is a schematic diagram illustrating an example system for broadcasting ATSC video in a SDV system constructed in accordance with the teachings of the invention. 
         FIG. 6  is a schematic illustration of an example manner of implementing the proxy server of  FIG. 5 . 
         FIG. 7  is a schematic illustration of an example manner of implementing the de-multiplexer and switch of  FIG. 5 . 
         FIG. 8  is a flow chart representative of machine readable instructions which may be executed to implement the controller of  FIG. 6 . 
         FIGS. 9   a - b  are flow charts representative of machine readable instructions which may be executed to implement the controller of  FIG. 6 . 
         FIG. 10  is a schematic illustration of an example processor platform that may execute the example machine readable instructions represented by  FIGS. 8 and 9   a - b  to implement the controller of  FIG. 6 . 
     
    
    
     DETAILED DESCRIPTION 
     As described above, the dynamic nature of the ATSC DTV system provides tremendous flexibility in providing and transporting programs. Terrestrial, cable and satellite broadcast systems are very similar, and implementations of the ATSC DTV standards within those systems have substantially leveraged existing infrastructure. For example, all three systems (terrestrial, cable, and satellite) simply provide all programming to the customer premises, and selection of programs is implemented in customer premise equipment (CPE). In a SDV system, switching is implemented out of necessity within the SDV system due to a bandwidth constrained transport network (e.g., digital subscriber line (DSL), passive optical network (PON), etc.). Thus, in a SDV system all programming cannot be provided to a customer premises, and a different method of supporting the ATSC DTV standards is required. 
       FIG. 5  illustrates an example SDV system  500  constructed in accordance with the teachings of the invention that supports ATSC DTV based MPTSs. The SDV system  500  of  FIG. 5  receives a plurality of RF transmissions  135  which are demodulated by a plurality of ATSC receivers  505   a - b  to create a plurality of MPTSs  506 . In the illustrated example, the SDV system  500  further separates the MPTSs  506  into a plurality of PSIP streams  507  (primarily comprising PSIP information packets present in the MPTSs  506 ) and a plurality of transport streams  508  (primarily comprising program packets (e.g., packets containing video, audio, etc.) present in the MPTSs  506 ). Alternatively, the SDV system  500  does not split the resulting MPTSs  506 , thus, the PSIP streams  507  and the transport streams  508  are identical to the MPTSs  506 . 
     In the illustrated example, the plurality of ATSC receivers  505   a - b  are implemented as separate devices. Alternatively, one or more ATSC receivers  550   a - b , each capable of demodulating one or more RF transmissions, may be employed. For instance, a single ATSC receiver  500  capable of demodulating a plurality of RF transmissions may be employed to receive and demodulate all of the received RF transmissions  135 . 
     In the illustrated example, a PSIP stream  507  (which may be null or empty) and a transport stream  508  (which may be null or empty) are associated with each of the RF transmissions  135 . The number of PSIP streams  507  and transport streams  508  may be dynamically created and destroyed based upon the number of active RF transmissions  135 . Further, the PSIP streams  507  could be multiplexed together to create one or more combined PSIP stream(s). Likewise, the transport streams  508  could be multiplexed together to create one or more combined transport stream(s). Example implementations of ATSC receivers  505 ,  505   a - b  are well known to persons of ordinary skill in the art, and, thus, are not discussed further. 
     To connect one or more program streams (not shown) contained in the plurality of transport streams  508  with a plurality of SDV broadcast engines  550   a - b , the SDV system  500  includes a de-multiplexer and switch (DS)  515 . The DS  515  of the illustrated example de-multiplexes one or more of the plurality of transport streams  508  into one or more program streams (which may include an audio stream, a video stream, a data stream and/or a control stream for a single program), and further connects one or more of the program streams to one or more of the SDV broadcast engines  550   a - b.    
     In the illustrated example of  FIG. 5 , each SDV broadcast engine  550   a - b  includes a video encoder  525   a - b  and an Internet protocol (IP) TV system server (ITSS)  530   a - b . The video encoder  525   a - b  re-encodes/re-compresses a program stream to further reduce the number of bits required to represent the program stream. In the illustrated example, the video encoder  525   a - b  implements the MPEG-4 or Microsoft&#39;s® VC1 encoding standard. The re-encoded program stream is then passed to the ITSSs  530   a - b  that, among other things, adds any necessary or provisioned encryption, packetizes the re-encoded program streams into IP packets, and provides the packetized re-encoded program streams to an IP network  540  for transport to a customer (not shown) that is also connected to the IP network  540 . Example implementations of SDV broadcast engines  550   a - b , video encoders  525   a - b , and ITSS  530   a - b  are well known to persons of ordinary skill in the art, and, thus, will not be discussed further. 
     As will be described in more detail in conjunction with  FIGS. 6-9 , the illustrated example SDV system  500  includes a proxy server  510  to configure and control the de-multiplexing and connecting performed by the DS  515 , the video encoders  525   a - b , and the ITSSs  530   a - b . The proxy server  510  decodes the PSIP streams  507  to create PSIP information tables for each of the RF transmissions  135  (and, thus, for each transport stream  508  and each PSIP stream  507 ). The proxy server  510  provides the PSIP information tables to a system manager  520  which indicates selected programs and assigned SDV system resources (e.g., SDV broadcast engine  550   a - b , video encoder  525   a - b , etc.) based on inputs  522  explained below. Finally, the proxy server  510  configures the DS  515 , one or more of the video encoders  525   a - b , and one or more of the ITSSs  530   a - b  based on the program selections and SDV resource assignments received from the system manager  520 . 
     The system manager  520 , among other things, implements and maintains an EPG for each RF transmission  135 , and processes the EPGs against one or more business objectives, operational rules (e.g., regular program streams, broadcasters, stations, broadcast networks that have been provisioned within the SDV system  500 ), ratings rules, contractual commitments, or customer requests to select which programs will be broadcast by the SDV system  500  to customers and those that will not. For each selected program, the system manager  520  assigns a SDV broadcast engine  550   a - b  (e.g., a video encoder  525   a - b  and an ITSS  530   a - b ). Further, the system manager  520  processes the EPG to determine programs that have ended (or are no longer to be broadcast to customers). For each of the ended (or are no longer to be broadcast to customers) programs the system manager  520  de-allocates the associated SDV broadcast engine  550   a - b . In one example, the system manager  520  may be implemented by a general purpose computer with a user interface that facilitates entering of programming schedule instructions by a system administrator. 
       FIG. 6  illustrates an example manner of implementing the proxy server  510  of  FIG. 5 . To decode the PSIP information contained in the PSIP streams  507 , the example proxy server  510  includes a PSIP decoder  605 . The PSIP decoder  605  uses well known existing prior art techniques to decode the PSIP information to create corresponding PSIP tables in a memory  610  for each of the PSIP streams  507 . In the illustrated example, the PSIP decoder  605  continually updates the PSIP tables for a PSIP stream in the memory  610  as additional PSIP information is received on the PSIP streams  507 . In this manner, the PSIP decoder  605  maintains up-to-date PSIP tables in the memory  610 . Whenever the PSIP decoder  605  creates, updates, or deletes one or more PSIP tables, the PSIP decoder  605  notifies a controller  615  using signal line(s)  612  that new or updated PSIP information is available. In the illustrated example, the PSIP decoder  605  decodes PSIP information for each of the PSIP streams  507 . Alternatively, the proxy server  510  may be implemented by one or more PSIP decoders, each of which decodes one or more of the PSIP streams  507 . For example, a PSIP decoder may be implemented for each of the PSIP streams  507 . 
     Upon receiving notification that new or updated PSIP information is available, the controller  615  notifies the system manager  520  using signal line(s)  512 . In the illustrated example, the controller  615  provides changes to the PSIP information to the system manager  520 . Alternatively, the controller  615  may provide the entire set of PSIP tables for the one or more PSIP streams  507  that have new or updated PSIP information whenever a change occurs. 
     The controller  615  receives signals via line(s)  512  from the system manager  520  identifying assignments of one or more selected programs to one or more SDV broadcast engines  550   a - b  (e.g., video encoders  525   a - b , ITSS  530   a - b ). For each of the selected programs, the controller  615  receives an identification of an allocated SDV broadcast engine  550   a - b . The controller  615  also receives notifications from the system manager  520  via line(s)  512  identifying that one or more programs are no longer selected, and that associated SDV broadcast engines  550   a - b  can, thus, be de-allocated. Based upon the information received from the system manager  520 , the controller  615  maintains a table in the memory  610  of selected programs, and the associated SDV broadcast engine  550   a - b  for each selected program. 
     To configure the SDV system  500 , the controller  615  of  FIG. 6  communicates with the DS  515  and the SDV broadcast engines  550   a - b . In particular, the controller  615  configures the DS  515  using signal line(s)  513 , and configures the video encoders  525   a - b  and the ITSSs  530   a - b  using signal lines(s)  514 . To configure the DS  515  for each selected program, the controller  615  provides signals via line(s)  513  that indicate, among other things, which program streams to de-multiplex from one or more of the transport streams  508 , and to which SDV broadcast engine  550   a - b  (i.e., output port) each de-multiplexed program stream is to be connected. To configure the video encoders  525   a - b  and ITSSs  530   a - b , the controller  615  provides signals via line(s)  514  that include, among other things, instructions identifying the desired format, standard definition (SD) versus high definition (HD), encoding configuration/standard, audio information, etc. 
       FIG. 7  is an example manner of implementing the DS  515  of  FIG. 5 . To de-multiplex one or more of the plurality of transport streams into a plurality of program streams  707 , the DS  515  includes a plurality of de-multiplexers  705   a - b . In the illustrated example, a de-multiplexer  705   a - b  is implemented for each of the transport streams  508 . The DS  515  could alternatively include one or more de-multiplexers  705   a - b  that can de-multiplex one or more transport streams  508 . For example, the DS  515  could be implemented by one de-multiplexer  705  that de-multiplexes all of the transport streams  508 . In such an example, the de-multiplexer  705  should be capable of de-multiplexing at least the maximum number of program streams  707  supported by the SDV system  500 . The maximum number is approximately equal to or less than the maximum number of possible program streams per transport stream times the number of transport streams  508 . For implementation efficiency, the SDV system  500  and, thus, the de-multiplexer  705  could alternatively support fewer than the maximum number of program streams  707 . 
     To connect program streams  707  with video encoders  525   a - b , the DS  515  includes a cross-connection switch  710 . In the illustrated example, the cross connection switch  710  is configurably capable to connect any input port (associated with a program stream  707 ) with any output port (associated with a video encoder  525   a - b . Alternatively, the switch  710  may only be able to connect each input port with a subset of the output ports. In the illustrated example, the switch  710  is implemented as a single device. Alternatively, the switch  710  may be implemented as multiple devices, where each device may switch some or all of the input ports to some or all of the output ports. 
     To configure and control the de-multiplexers  705 ,  705   a - b  and the switch  710 , the DS  515  includes a controller  715 . The controller  715  receives the information necessary to configure and control the de-multiplexers  705 ,  705   a - b  and the switch  710  from the proxy server  510  via the signal line(s)  513 . In the illustrated example, the received information includes one or more sets of information identifying a transport stream  508 , a program stream  707  within the transport stream  508 , and an output port (associated with a video encoder  525   a - b ) to allocate or de-allocate. The controller maps or uses the received information to generate appropriate configuration and control signals for the de-multiplexers  705 ,  705   a - b  and the switch  710 . 
       FIGS. 8 ,  9   a  and  9   b  illustrate flowcharts representative of example machine readable instructions that may be executed by the example controller  615  of  FIG. 6 . The machine readable instructions of  FIGS. 8 ,  9   a  and  9   b  may be implemented by a processor, a controller, or any other suitable processing device. For example, the machine readable instructions of  FIGS. 8 ,  9   a  and  9   b  may be embodied in coded instructions stored on a tangible medium such as a flash memory, or random-access memory (RAM) associated with the processor  1010  shown in the example processor platform  1000  discussed below in conjunction with  FIG. 10 . Alternatively, the machine readable instructions of  FIGS. 8 ,  9   a  and  9   b  may be implemented using an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc. Also, some portion(s) of the machine readable instructions of  FIGS. 8 ,  9   a  and  9   b  may be implemented manually or as combinations of any of the foregoing techniques. Further, although the example machine readable instructions of  FIGS. 8 ,  9   a  and  9   b  are described with reference to the flowcharts of  FIGS. 8 ,  9   a  and  9   b , persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example controller  615  of  FIG. 6  may be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. 
     The example program of  FIG. 8  begins when the controller  615  reads new or updated PSIP tables from the memory (block  805 ). Next, the controller  615  provides the new or updated PSIP information to the system manager  520  and receives one or more program stream selections or de-selections from the system manager  520  (block  810 ). For each of the program stream selections or de-selections (block  815 ), the controller  615  determines if the program stream is being added or removed (i.e., selected or de-selected) (block  820 ). If the program stream is being added, the controller  615  sends one or more signals to the DS  515  and the SDV broadcast engines  550   a - b  to execute the example program represented by  FIG. 9   a  (block  900   a ). Otherwise the controller  615  sends one or more signals to the DS  515  and the SDV broadcast engines  550   a - b  to execute the example program represented by  FIG. 9   b  (block  900   b ). Once, all program stream selections or de-selections are completed (block  815 ), the controller  615  ends the example program of  FIG. 8 . 
     Additionally, the controller  615  may receive program selection information (e.g., program selections, program de-selections, SDV broadcast engine  550   a - b  assignments, etc.) from the system manager  520  at times other than when the controller  615  provides program information to the system manager  520  (block  810 ). In this case, the controller  615  carries out a portion of the example program of  FIG. 8  comprising blocks  815 - 820  and interacts with the DS  515  and the SDV broadcast engines  550   a - b  to perform allocation or de-allocation in accordance with  FIGS. 9   a  and  9   b.    
     The example process of  FIG. 9   a  begins with the controller  615  sending configuration and control information (e.g., format, SD vs. HD, audio information, enable, etc.) using the signals  514  to an ITSS  530   a - b  (block  905   a ) and to a video encoder  525   a - b  (block  910   a ). Next, the controller  615  sends configuration information (e.g., selection of a transport stream  508 , a program stream  707 , an output port, and an allocate indication) to the controller  715  of  FIG. 7  (block  915   a ). 
     The example process of  FIG. 9   b  begins with the controller  615  sending control information using the signals  514  to an ITSS  530   a - b  (block  905   b ) and to a video encoder  525   a - b  (block  910   b ) to disable them. Next, the controller  615  sends configuration information (e.g., selection of a transport stream  508 , a program stream  707 , an output port, and de-allocate indication) to the controller  715  of  FIG. 7  (block  915   b ) to de-allocate SDV resources. 
       FIG. 10  is a block diagram of an example processor platform  1000  capable of implementing the example processes  800  and  900   a - b  of  FIGS. 8 ,  9   a - b . For example, the processor platform  1000  can be implemented by one or more general purpose microprocessors, microcontrollers, etc. 
     The processor platform  1000  of the example includes the processor  1010  that is a general purpose programmable processor. The processor  1010  executes coded instructions present in main memory of the processor  1010 . The processor  1010  may implement, among other things, the controller  615  of  FIG. 6  and/or the controller  715  of  FIG. 7 . 
     The processor  1010  is in communication with the main memory including a read only memory (ROM)  1020 , a random access memory (RAM)  1025 , and the memory  610  of  FIG. 6  via a bus  1005 . The RAM  1025  may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), and/or any other type of random access memory device. The ROM  1020  may be implemented by flash memory and/or any other desired type of memory device. Access to the memory space  1020 ,  1025 ,  610  is typically controlled by a memory controller (not shown) in a conventional manner. 
     The processor platform  1000  also includes a conventional interface circuit  1030 . The interface circuit  1030  may be implemented by any type of well known interface standard, such as an external memory interface, serial port, general purpose input/output, etc. 
     One or more input devices  1035  are connected to the interface circuit  1030 . The input device(s)  1035  (e.g., signals  612 ,  512 ) may be used to provide the processor  1010  information on programs present on RF transmissions  135  and selected and de-selected programs. 
     One or more output devices  1040  are also connected to the interface circuit  1030 . The output devices  1040  (e.g., signals  512 ,  513 ,  514 ) may be used by the processor  1010  to provide program information to a system manager  520 , control information to DS  515 , and/or control information to SDV broadcast engines  550   a - b  (e.g., video encoders  525   a - b , ITSSs  530   a - b ). 
     From the foregoing, persons of ordinary skill in the art will appreciate that the above disclosed methods and apparatus may be realized within a single device or across two cooperating devices, and could be implemented by software, hardware, and/or firmware to implement the improved wireless receiver disclosed herein. 
     Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Technology Classification (CPC): 7