US20060053460A1 - Transmission communications management - Google Patents
Transmission communications management Download PDFInfo
- Publication number
- US20060053460A1 US20060053460A1 US11/258,427 US25842705A US2006053460A1 US 20060053460 A1 US20060053460 A1 US 20060053460A1 US 25842705 A US25842705 A US 25842705A US 2006053460 A1 US2006053460 A1 US 2006053460A1
- Authority
- US
- United States
- Prior art keywords
- data
- transmitter
- broadcast
- transmission
- transmission system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
- H04N7/165—Centralised control of user terminal ; Registering at central
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
- H04N21/2221—Secondary servers, e.g. proxy server, cable television Head-end being a cable television head-end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4782—Web browsing, e.g. WebTV
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8545—Content authoring for generating interactive applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division
- H04N7/087—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only
- H04N7/088—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only the inserted signal being digital
Definitions
- the invention relates to transmission communications management.
- digital information may be encoded into broadcast television signals and transmitted to a home personal computer that has been configured to receive the information.
- a technology developed for transporting such a combination of digital information and broadcast TV signals is the Intel® Intercast® technology.
- the Intercast® technology includes three parts: the broadcast headend, the transport, and the platform.
- broadcasters may create digital data such as Web pages, multimedia applications or other data files.
- the digital data is then assembled into packages and scheduled for insertion into the broadcast signal so that the broadcast signal can carry the TV audio, TV video, and digital data.
- the broadcast signal (with inserted digital data) is received and processed for display.
- a TV tuner appropriate to the transport is used for receiving the broadcast signal.
- Data processing is then preformed by video capture and decode circuitry, which may be integrated with the tuner that receives the regular TV signals.
- FIG. 1 is a block diagram of a broadcast system incorporating an embodiment of the invention.
- FIG. 2 is a block diagram of a transmitter and a broadcast encoder according to an embodiment of the invention.
- FIG. 3 illustrates an example data structure used for communication between the transmitter and broadcast encoder of FIG. 2 .
- the bridge unit 14 multiplexes the digital data and the TV data and provides the combined data to an uplink block 16 .
- the system containing the interactive broadcasting application programs 12 and the data inserter unit 15 may be separate systems, while in other embodiments the units may be implemented as one integrated system.
- the uplink block 16 transmits (by broadcasting or multicasting, for example) the combined digital and TV data over one or more transport media or communications channels 20 , which may be the broadcast airwaves, a cable medium, a satellite medium, a computer network (such as local area networks, wide area networks, or the Internet), or a digital TV medium, to one or more platforms 30 .
- An example platform 30 may include a TV-enabled computer 32 that is configured to receive the combined digital and PC broadcast data over the transport medium 20 .
- the computer 32 may also include a modem 34 that may be connected to an Internet Web server 22 .
- the bridge unit 14 and uplink block 16 include several components as shown in FIG. 2 .
- the bridge unit 14 includes a broadcast encoder 100 (implemented in one embodiment as a software module) that interleaves digital data received from the application programs 12 with television programming data.
- the broadcast encoder 100 is able to work with a number of different types of transport media 20 .
- one or more different transmitters 102 that are configured for corresponding transport media are also included in the bridge unit 14 .
- each transmitter 102 is essentially a transport abstraction implemented as a software module that acts as the interface between application programs (including the broadcast encoder 100 ), and the connected transport media 20 .
- the broadcast encoder 100 and one or more of the transmitters 102 exchange information on a “continuous” (or continued) basis so that the broadcast encoder 100 may efficiently and reliably manage communications for different transport media and as transmitter characteristics change.
- the exchange of information may be performed by the broadcast encoder 100 periodically polling each transmitter 102 or by a transmitter 102 requesting an update, for example.
- the exchange of information is continuous in the sense that the broadcast encoder 100 and transmitters 102 continue to exchange information after startup of the broadcast encoder 100 or one of the transmitters 102 .
- multiple broadcast encoders may be specified for use with multiple corresponding transmitters.
- embodiments of the invention may include the ability to automatically control data flow that is transparent to application programs in the broadcast headend system 10 .
- embodiments of the invention may allow for transport independence at the broadcast headend in interactive broadcast systems.
- the broadcast encoder 100 mixes the digital data and the TV programming data according to the type of transport medium 20 used. For example, if the transport medium uses an analog broadcast signal (transmitted over analog airwave or cable media, for example), the digital data is inserted into the vertical blanking interval (VBI) portion of the broadcast signal.
- VBI vertical blanking interval
- the VBI portion of the broadcast signal may also be used to transmit, among other things, closed captioning data.
- a predetermined number e.g., 10
- a portion of the available VBI lines is typically used to carry the digital data.
- Characteristics of a transport medium 20 are communicated by a corresponding transmitter 102 to the broadcast encoder 100 through negotiations between the broadcast encoder and the transmitters.
- Each transmitter 102 may be configured as a separate module, such a Component Object Model (COM) object.
- COM Component Object Model
- the COM specification is described in “The Component Object Model Specification,” Draft Version 0.9, Microsoft Corporation and Digital Equipment Corporation (October 1995).
- the behavior of the broadcast encoder 100 is modified based on the capabilities that the one or more transmitters 102 advertise.
- the broadcast encoder 100 and each transmitter 102 are loosely coupled, with the communications between a transmitter and the broadcast encoder in one embodiment being accomplished through an application specific interface (API).
- API application specific interface
- the broadcast encoder 100 obtains details of the characteristics of each transmitter 102 to allow the broadcast encoder 100 to efficiently manage data communications over the transport media 20 .
- API interface several methods are defined through which the broadcast encoder and transmitters exchange information.
- negotiations between the broadcast encoder and each transmitter may be accomplished with other interfaces, including use of OLE events defined under the Object Linking and Embedding (OLE) standard, described in David Chappell, “Understanding ActiveX and OLE: A Guide for Developers & Managers,” published in 1996.
- OLE Object Linking and Embedding
- the transmitter 102 may accept two general types of data: raw data streams or predefined datagrams.
- Raw data streams are transmitted by the broadcast encoder 100 or another application by calling a Send( ) method, and datagrams are transmitted using a SendDatagrams( ) method.
- Send( ) method When data is provided by the broadcast encoder 100 or some other application to the transmitter 102 using the Send( ) method, the transmitter 102 does not know the type of data that is passed to it. When a transmitter 102 receives this kind of data, it does not interpret this data but instead passes the data on to another device or software module.
- the Send( ) method in one embodiment writes the data pointed to in the method to a target transmitter 102 .
- the broadcast encoder 100 along with the other applications may assume that the data bits have actually been written to the transmitter.
- the Send( ) method is a blocking call, and will return a value if one of the following conditions occur: the transmission was successful, a timeout occurred, an error occurred, or the caller has aborted the call.
- the Initialize( ) method may be a blocking call, with the call returning only if the system is really initialized.
- the broadcast encoder 100 checks (at 206 ) to determine if the loading and initialization is successful. If a failure is detected, then the broadcast encoder 100 designates itself as being in a Homeless state (at 208 ), in which the broadcast encoder 100 does not accept or send any data.
- the broadcast encoder 100 requests (at 210 ) the configuration information from the one or more transmitters 102 using the GetConfiguration( ) method.
- the transmitter advertises its capabilities.
- Some of the outputs are already known to the broadcast encoder 100 and some are specific to the class of transmitter involved. For example, a transmitter associated with a VBI transport will have a field indicating the number of VBI lines used.
- the types of information that a transmitter can send include the following: the version, length of the header, name of the transmitter, some description of the transmitter, the transfer rate, the maximum transmission unit, the buffer size, if any, the timeout and seconds per datagram (if any), the data gram type (UDP, IP, or raw data), flags, padding size, and other information.
- the configuration information received from each transmitter 102 is stored in memory by the broadcast encoder 100 at predefined memory locations. The stored transmitter configuration information is used at a later time to modify the broadcast encoder's behavior.
- the broadcast encoder 100 may send (at 212 ) device specific information (information describing certain details of the broadcast encoder 100 ) to each of the transmitter 102 .
- the method used to communicate this information is a RegisterStream( ) method.
- the broadcast encoder 100 stores all the stream-related information in a data structure (referred to as OPENSTREAM) and allocates a handle (address information indicating where the OPENSTREAM structure is stored) that is passed to the transmitter 102 in the RegisterStream( ) method.
- This handle may be passed by the broadcast encoder 102 in subsequent datagrams (in block 60 of the example datagram of FIG. 3 ).
- the broadcast encoder 100 determines transmitter characteristics.
- Other methods used by the broadcast encoder 100 to determine transmitter characteristics include the GetAdjustedTransferRate( ) method, which calculates the actual transfer rate adjusted for delays and overhead in the transmitter 102 .
- the GetAdjustedTransferRate( ) method obtains the adjusted rate of transfer in bits per second that accounts for the network traffic, hardware and software overhead and other delays.
- a transmitter may have some intelligent mechanism to study the flow and return and appropriate value, and this value may vary from time to time depending on such conditions as the network traffic.
- the broadcast encoder will use this adjusted transfer rate to arrive at a transfer rate to perform the transfer of data to the transmitter.
- the adjusted transfer rate effectively is the data transfer rate that the transmitter 102 is able to handle.
- the broadcast encoder 100 also needs to account for the incoming data flow rate.
- the broadcast encoder 100 may receive input data from several sources, each potentially at different rates. Further, the broadcast encoder may include one or more buffers to store incoming data. Some transmitters 102 may also have this capability. Transmitters that include an internal cache (or buffer) that is able to hold data are referred to as “none-blocking transmitters.”
- the second type of transmitter does not cache data at all, in which case all Send( ) and SendDatagrams( ) calls are blocked until data actually is sent by the transmitter.
- the broadcast encoder 100 may determine if a transmitter 102 includes data buffers by calling the method GetFreeBuff( ). If a transmitter 102 includes a buffer, then it may be able to handle a faster data flow from the broadcast encoder 100 to the transmitter 102 . In addition, the broadcast encoder 100 determines how fast returns are received from Send( ) or SendDatagram( ) calls.
- the broadcast encoder 100 is able to perform effective data flow control.
- the broadcast encoder 100 and transmitters 102 may be stored on a suitable mass storage medium such as the CD or DVD drive 230 , the floppy disk drive 224 , or the hard disk drive 226 .
- a suitable mass storage medium such as the CD or DVD drive 230 , the floppy disk drive 224 , or the hard disk drive 226 .
- the broadcast encoder 100 and transmitters 102 or portions of the software modules may loaded into the system memory 218 for execution by the microprocessor 210 .
- Data generated by the transmitters 102 may be transmitted over the network, serial or parallel ports, or other interfaces (not shown) to the uplink unit 16 .
Abstract
An interactive transmission system having a data management module that identifies at least one transmission characteristic of at least one transmitter module. The transmitter module transmits data over a transport medium. The data management module modifies its behavior based on the identified at least one transmission characteristic.
Description
- This application is a continuation of U.S. patent application Ser. No. 09/138,054, entitled “TRANSMISSION COMMUNICATIONS MANAGEMENT,” filed on Aug. 21, 1998, now U.S. Pat. No. 6,959,451, granted on Oct. 25, 2005.
- The invention relates to transmission communications management.
- In an interactive broadcasting system, digital information may be encoded into broadcast television signals and transmitted to a home personal computer that has been configured to receive the information. A technology developed for transporting such a combination of digital information and broadcast TV signals is the Intel® Intercast® technology.
- The Intercast® technology includes three parts: the broadcast headend, the transport, and the platform. At the broadcast headend, such as a television studio, broadcasters may create digital data such as Web pages, multimedia applications or other data files. The digital data is then assembled into packages and scheduled for insertion into the broadcast signal so that the broadcast signal can carry the TV audio, TV video, and digital data.
- The combined digital and TV broadcast signal may be transmitted over a number of different transports, including regular television airwave broadcasts, satellite transmissions, cable transmissions, digital TV transmissions, or computer networks such as local area networks (LANs) or wide area networks (WANs).
- At the receiving end, or the platform, which may be a TV-enabled personal computer or a set-top box, the broadcast signal (with inserted digital data) is received and processed for display. A TV tuner appropriate to the transport is used for receiving the broadcast signal. Data processing is then preformed by video capture and decode circuitry, which may be integrated with the tuner that receives the regular TV signals.
- The different transports that are able to transmit such broadcast signals have different transmission rates and different protocols. Thus, a need arises for broadcast equipment that is capable of supporting multiple broadcast transports.
-
FIG. 1 is a block diagram of a broadcast system incorporating an embodiment of the invention. -
FIG. 2 is a block diagram of a transmitter and a broadcast encoder according to an embodiment of the invention. -
FIG. 3 illustrates an example data structure used for communication between the transmitter and broadcast encoder ofFIG. 2 . -
FIG. 4 is a flow diagram of a process performed by the broadcast encoder according to an embodiment of the invention. -
FIG. 5 is a block diagram of an example computer system that can be used in the broadcast system ofFIG. 1 . - Referring to
FIG. 1 , an example transmission system 8 (which may be an interactive broadcast system, for example) is illustrated that includes abroadcast headend system 10, one ormore transports 20, and one ormore platforms 30 to receive the broadcast signals. At thebroadcast headend system 10, which includes a computer system along with other broadcast-related components (which may be located at a TV studio, for example), digital data are provided to a system containing interactivebroadcasting application programs 12, which assemble the received digital data into packages and schedule them for insertion into a broadcast signal. The assembled data from the interactivebroadcasting application programs 12 are routed to a data inserter unit 15 including abridge unit 14, which also receives broadcast program video and audio data (TV data). Thebridge unit 14 multiplexes the digital data and the TV data and provides the combined data to anuplink block 16. In some embodiments, the system containing the interactivebroadcasting application programs 12 and the data inserter unit 15 may be separate systems, while in other embodiments the units may be implemented as one integrated system. - The
uplink block 16 in turn transmits (by broadcasting or multicasting, for example) the combined digital and TV data over one or more transport media orcommunications channels 20, which may be the broadcast airwaves, a cable medium, a satellite medium, a computer network (such as local area networks, wide area networks, or the Internet), or a digital TV medium, to one ormore platforms 30. Anexample platform 30 may include a TV-enabledcomputer 32 that is configured to receive the combined digital and PC broadcast data over thetransport medium 20. Thecomputer 32 may also include amodem 34 that may be connected to anInternet Web server 22. - According to embodiments of the invention, the
bridge unit 14 is able to automatically adjust for the different characteristics ofdifferent transport media 20, including data flow rates and other characteristics as described below. Further, each particular transport medium may have transport characteristics that vary over time, for which thebridge unit 14 may also make adjustments. Thebridge unit 14 may be implemented entirely in software that runs in the computer system in thebroadcast headend system 10, or alternatively, thebridge unit 14 may be a combination of hardware and software. - In some embodiments, the
bridge unit 14 anduplink block 16 include several components as shown inFIG. 2 . Thebridge unit 14 includes a broadcast encoder 100 (implemented in one embodiment as a software module) that interleaves digital data received from theapplication programs 12 with television programming data. Thebroadcast encoder 100 is able to work with a number of different types oftransport media 20. To provide for such flexibility, one or moredifferent transmitters 102 that are configured for corresponding transport media are also included in thebridge unit 14. In one embodiment, eachtransmitter 102 is essentially a transport abstraction implemented as a software module that acts as the interface between application programs (including the broadcast encoder 100), and the connectedtransport media 20. - In one embodiment, the
broadcast encoder 100 and one or more of thetransmitters 102 exchange information on a “continuous” (or continued) basis so that thebroadcast encoder 100 may efficiently and reliably manage communications for different transport media and as transmitter characteristics change. The exchange of information may be performed by thebroadcast encoder 100 periodically polling eachtransmitter 102 or by atransmitter 102 requesting an update, for example. The exchange of information is continuous in the sense that thebroadcast encoder 100 andtransmitters 102 continue to exchange information after startup of thebroadcast encoder 100 or one of thetransmitters 102. In an alternative embodiment, multiple broadcast encoders may be specified for use with multiple corresponding transmitters. - Advantages of embodiments of the invention may include the ability to automatically control data flow that is transparent to application programs in the
broadcast headend system 10. In addition, embodiments of the invention may allow for transport independence at the broadcast headend in interactive broadcast systems. - The
broadcast encoder 100 mixes the digital data and the TV programming data according to the type oftransport medium 20 used. For example, if the transport medium uses an analog broadcast signal (transmitted over analog airwave or cable media, for example), the digital data is inserted into the vertical blanking interval (VBI) portion of the broadcast signal. The VBI portion of the broadcast signal may also be used to transmit, among other things, closed captioning data. Conventionally, in an analog broadcast signal, a predetermined number (e.g., 10) of VBI lines are available, with each line having a predetermined data transmission capacity. A portion of the available VBI lines is typically used to carry the digital data. - Other transport media, such as satellite transmissions or digital TV transmissions, may have much higher data transmission rates.
- Data from the
bridge unit 14 is transmitted to theuplink unit 16, which typically may include a hardware unit (or sometimes a software stack) that ships the data along with other contents over a specifiedtransport medium 20, which may be any network that supports broadcast or multicast transmissions. - Characteristics of a
transport medium 20 are communicated by acorresponding transmitter 102 to thebroadcast encoder 100 through negotiations between the broadcast encoder and the transmitters. Eachtransmitter 102 may be configured as a separate module, such a Component Object Model (COM) object. The COM specification is described in “The Component Object Model Specification,” Draft Version 0.9, Microsoft Corporation and Digital Equipment Corporation (October 1995). - The behavior of the
broadcast encoder 100 is modified based on the capabilities that the one ormore transmitters 102 advertise. Thebroadcast encoder 100 and eachtransmitter 102 are loosely coupled, with the communications between a transmitter and the broadcast encoder in one embodiment being accomplished through an application specific interface (API). During negotiations between thebroadcast encoder 100 and eachtransmitter 102 through the API interface, thebroadcast encoder 100 obtains details of the characteristics of eachtransmitter 102 to allow thebroadcast encoder 100 to efficiently manage data communications over thetransport media 20. In the API interface, several methods are defined through which the broadcast encoder and transmitters exchange information. - To increase efficiency of data transfer between the broadcast encoder and the transmitter, each
transmitter 102 according to an embodiment is configured as a COM object to the broadcast encoder that has two interfaces: ITransmitter, which is the transmitter's primary interface for data communication and control; and the IPropertyPage interface for configuration management. Any application (including the broadcast encoder 100) that uses thetransmitters 102 in the described embodiment first obtains the ITransmitter interface to set up communications with eachtransmitter 102. - In alternative embodiments, negotiations between the broadcast encoder and each transmitter may be accomplished with other interfaces, including use of OLE events defined under the Object Linking and Embedding (OLE) standard, described in David Chappell, “Understanding ActiveX and OLE: A Guide for Developers & Managers,” published in 1996.
- In the described embodiment, the
transmitter 102 may accept two general types of data: raw data streams or predefined datagrams. Raw data streams are transmitted by thebroadcast encoder 100 or another application by calling a Send( ) method, and datagrams are transmitted using a SendDatagrams( ) method. When data is provided by thebroadcast encoder 100 or some other application to thetransmitter 102 using the Send( ) method, thetransmitter 102 does not know the type of data that is passed to it. When atransmitter 102 receives this kind of data, it does not interpret this data but instead passes the data on to another device or software module. - The Send( ) method in one embodiment writes the data pointed to in the method to a
target transmitter 102. When a Send( ) call returns, thebroadcast encoder 100 along with the other applications may assume that the data bits have actually been written to the transmitter. The Send( ) method is a blocking call, and will return a value if one of the following conditions occur: the transmission was successful, a timeout occurred, an error occurred, or the caller has aborted the call. - The other type of data, predefined datagrams such as Internet Protocol (IP) or User Datagram Protocol (UDP) datagrams that are transmitted by calling the SendDatagrams( ) method, have known formats. The SendDatagrams( ) method is similar to the Send( ) method. The IP protocol is described in “Internet Protocol, DARPA Internet Program, Protocol Specification,” Request for Comment 791 (September 1981), and the UDP protocol is described in “User Datagrams Protocol,” Request for Comment 768 (August 1980). Each datagram may include header information that may have the following types of information: version information; length of the header; type of datagram, including UDP, IP, and raw data; length of the data; flags; compression used; and other information. A datagram header may also be followed by broadcast encoder data that describe certain details of the
broadcast encoder 100. The datagram also includes the actual data that is being transmitted. An example IP datagram is shown inFIG. 3 , in which ablock 60 contains the header information and broadcast encoder information, ablock 64 contains the actual data, and ablock 62 may optionally be used as a pad region. Atransmitter 102 is able to reformat a datagram received from thebroadcast encoder 100 or other application program for transmission further downstream. - The behavior of the
broadcast encoder 100 is dependent on information advertised by eachtransmitter 102 from negotiations thebroadcast encoder 100 performs with one ormore transmitters 102. Depending on howmany transport media 20 is used in the system, more than onetransmitter 102 may be active at the same time. According to an embodiment of the invention, several methods may be used to perform these negotiations, including GetConfiguration( ), GetAdjustmentRate( ), GetNumSendErrors( ), and GetFreeBuff( ), which are discussed further below. - Referring to
FIG. 4 , the tasks performed by thebroadcast encoder 100 of one embodiment during the negotiation process with thetransmitter 102 are described. First, through the IPropertyPage API interface, thebroadcast encoder 100 loads (at 202) the one or more designatedtransmitters 102 into thebroadcast headend system 10. Transmitters may be designated in a preselected database, such as the registry under the Windows operating system. In addition, the loadedtransmitters 102 are initialized (at 204) by calling a method Initialize( ). Once an Initialize( ) method is issued, eachtransmitter 102 responds by allocating memory (such as internal buffers) and initializing any variables and device settings. The Initialize( ) method may be a blocking call, with the call returning only if the system is really initialized. Thebroadcast encoder 100 checks (at 206) to determine if the loading and initialization is successful. If a failure is detected, then thebroadcast encoder 100 designates itself as being in a Homeless state (at 208), in which thebroadcast encoder 100 does not accept or send any data. - But if the loading and initialization were successful (as determined at 206), then the
broadcast encoder 100 requests (at 210) the configuration information from the one ormore transmitters 102 using the GetConfiguration( ) method. When a transmitter receives the GetConfiguration( ) call, the transmitter advertises its capabilities. Some of the outputs are already known to thebroadcast encoder 100 and some are specific to the class of transmitter involved. For example, a transmitter associated with a VBI transport will have a field indicating the number of VBI lines used. The types of information that a transmitter can send include the following: the version, length of the header, name of the transmitter, some description of the transmitter, the transfer rate, the maximum transmission unit, the buffer size, if any, the timeout and seconds per datagram (if any), the data gram type (UDP, IP, or raw data), flags, padding size, and other information. The configuration information received from eachtransmitter 102 is stored in memory by thebroadcast encoder 100 at predefined memory locations. The stored transmitter configuration information is used at a later time to modify the broadcast encoder's behavior. - Next, the
broadcast encoder 100 may send (at 212) device specific information (information describing certain details of the broadcast encoder 100) to each of thetransmitter 102. In the illustrated embodiment, the method used to communicate this information is a RegisterStream( ) method. Thebroadcast encoder 100 stores all the stream-related information in a data structure (referred to as OPENSTREAM) and allocates a handle (address information indicating where the OPENSTREAM structure is stored) that is passed to thetransmitter 102 in the RegisterStream( ) method. This handle may be passed by thebroadcast encoder 102 in subsequent datagrams (inblock 60 of the example datagram ofFIG. 3 ). - Next, the broadcast encoder uses (at 214) the configuration information advertised by each
transmitter 102 in response to the GetConfiguration( ) method to modify its behavior. In the illustrated embodiment, the configuration information is stored in a data structure, referred to as the CONFIG data structure. Transmitters associated with different transport media have different characteristics. Some characteristics may include the maximum transfer rate that a transport medium can handle, the maximum size of each data packet (also refer to as the maximum transmission unit or MTU), whether compression is used, whether internal buffers are used in the transmitter, the type of data management (if any) performed by each transmitter, whether framing of data is performed, and whether fragmentation of the data is performed. - Another characteristic of a transmitter is whether it understands the concept of priorities. Thus, if the transmitter is able to assign priorities to data it receives, then the
broadcast encoder 100 does not perform priority assignment, leaving the task to thetransmitter 102. If thetransmitter 102 is unable to prioritize the received data stream, then thebroadcast encoder 100 multiplexes the data stream based on the requested priority from theapplication programs 12. - Yet a further transmitter characteristic is bandwidth management, in which the
transmitter 102 may advertise that it is able to perform bandwidth management. Similarly, thebroadcast encoder 100 may also optionally allow thetransmitter 102 to perform data compression if thetransmitter 102 is able to do so. Other characteristics that may be negotiated between the broadcast encoder and the transmitters include the basic data types that a transmitter requires. In one embodiment, the data types include raw data streams, Internet Protocol (IP) data, user datagram protocol (UDP) data, or other types of data. Raw data streams may be used in network interfaces not requiring an IP or UDP header. In addition, atransmitter 102 may ask thebroadcast encoder 100 to repackage data before it is transmitted to the transmitter. - Some of the characteristics of the transmitters are further discussed below. The maximum transmission unit (MTU) refers to the maximum size of a single IP or UDP datagram. If an MTU is advertised, the
broadcaster encoder 100 sets the size of each datagram to be less than or equal to the advertised MTU. If a software layer (such as the broadcaster encoder 100) sends data that is more than the specified MTU size, then the IP layer (such as the transmitter 102) may fragment the data into MTU-sized datagrams before further transmission. In some embodiments, atransmitter 102 does not need to advertise the MTU of its transport medium. Instead atransmitter 102 may advertise its MTU as having the value zero, in which case thetransmitter 102 would perform its own internal buffering, fragmentation, and data management. - In addition to using the configuration information advertised by the transmitters, other methods used by the
broadcast encoder 100 to determine transmitter characteristics include the GetAdjustedTransferRate( ) method, which calculates the actual transfer rate adjusted for delays and overhead in thetransmitter 102. The GetAdjustedTransferRate( ) method obtains the adjusted rate of transfer in bits per second that accounts for the network traffic, hardware and software overhead and other delays. A transmitter may have some intelligent mechanism to study the flow and return and appropriate value, and this value may vary from time to time depending on such conditions as the network traffic. The broadcast encoder will use this adjusted transfer rate to arrive at a transfer rate to perform the transfer of data to the transmitter. - The adjusted transfer rate effectively is the data transfer rate that the
transmitter 102 is able to handle. To effectively manage the data flow, thebroadcast encoder 100 also needs to account for the incoming data flow rate. Thebroadcast encoder 100 may receive input data from several sources, each potentially at different rates. Further, the broadcast encoder may include one or more buffers to store incoming data. Sometransmitters 102 may also have this capability. Transmitters that include an internal cache (or buffer) that is able to hold data are referred to as “none-blocking transmitters.” The second type of transmitter does not cache data at all, in which case all Send( ) and SendDatagrams( ) calls are blocked until data actually is sent by the transmitter. Such transmitters are referred to as “blocking transmitters.” Thebroadcast encoder 100 may determine if atransmitter 102 includes data buffers by calling the method GetFreeBuff( ). If atransmitter 102 includes a buffer, then it may be able to handle a faster data flow from thebroadcast encoder 100 to thetransmitter 102. In addition, thebroadcast encoder 100 determines how fast returns are received from Send( ) or SendDatagram( ) calls. Using the adjusted transfer rate, incoming data rate or rates, the existence of buffers in thetransmitters 102, and the speed of returns in response to the Send( ) or SendDatagrams( ) methods, all negotiated on a continuous basis between thebroadcast encoder 100 and each of thetransmitters 102, thebroadcast encoder 100 is able to perform effective data flow control. - Referring to
FIG. 5 , anexample computer system 200 used in thebroadcast headend system 10 may include amicroprocessor 210 that is capable of running thebroadcast encoder 100 andtransmitters 102 according to embodiments of the invention. Asystem memory 218, themicroprocessor 210, and a bridge/system controller circuitry 214 are all coupled to ahost bus 212. Thebridge circuitry 214 provides an interface from thehost bus 212 to adown stream bus 229 that is coupled to an I/O controller 220 and anetwork interface card 222, as examples. The I/O controller 220 may also be coupled to serial andparallel ports 232. Thecomputer 200 may also have, as examples, a CD orDVD drive 230, afloppy disk drive 224, and/or ahard disk drive 226. - According to some embodiments, the
broadcast encoder 100 andtransmitters 102 may be stored on a suitable mass storage medium such as the CD orDVD drive 230, thefloppy disk drive 224, or thehard disk drive 226. During execution, thebroadcast encoder 100 andtransmitters 102 or portions of the software modules may loaded into thesystem memory 218 for execution by themicroprocessor 210. Data generated by thetransmitters 102 may be transmitted over the network, serial or parallel ports, or other interfaces (not shown) to theuplink unit 16. - Thus, by continuously monitoring transmitter characteristics, the broadcast encoder can efficiently and accurately manage the transmission of broadcast signals containing both digital data and TV data over one or more transport media. Because the broadcast encoder monitors the transmitters on a continuous basis, changes in characteristics of a transmitter and corresponding transport medium can be ascertained by the broadcast encoder for adjustments.
- Other embodiments are also included in the following claims. For example, even though specific units have been identified in the interactive broadcast system, other types of units may be used. In addition, the order of the tasks illustrated for the broadcast encoder may be modified and still achieve desirable results.
- While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the invention.
Claims (15)
1. A transmission system, comprising:
a data management module capable of managing data flow; and
a transmitter module coupled to a transport medium and to the data management module, the transmitter module storing configuration data indicative of whether the transmitter module is capable of assigning priorities to data the transmitter module receives, wherein the data management module modifies its data flow management based on the configuration data.
2. The transmission system of claim 1 , further comprising at least an additional transmitter module.
3. The transmission system of claim 2 , wherein each transmitter module is associated with a different transport medium.
4. The transmission system of claim 1 , wherein the transmission characteristic of the transmitter module varies over time.
5. The transmission system of claim 1 , wherein the configuration data indicates a data flow rate of the transmitter module.
6. The transmission system of claim 5 , wherein the data flow rate is adjusted to compensate for delays in the transmitter module.
7. The transmission system of claim 1 , wherein the data management module combines digital data with television data to transmit over the transport medium.
8. The transmission system of claim 1 , wherein the transport medium includes a medium selected from the group consisting of an airwave transmission, a cable transmission, a satellite transmission, a digital television transmission, and a computer network.
9. A computer-readable medium storing a program executable by a computer in a transmission system including a transport medium, the program comprising instructions to cause the computer to:
determine whether a transmitter module is capable of performing bandwidth management; and
modify data flow management based on the determination.
10. The computer-readable medium of claim 9 , the program further comprising instructions causing the computer to identify a transmission characteristic of at least another transport medium over which data is to be transmitted by at least another transmitter.
11. The computer-readable medium of claim 10 , wherein the transport media have different transmission characteristics.
12. The computer-readable medium of claim 9 , wherein the program includes the transmitter module and a data management module.
13. A method of managing data flow over a transport medium in an interactive transmission system, comprising:
determining at least one characteristic indicative of data management by a transmitter other than a rate at which the transmitter processes the data; and
modifying data flow management based on the identified said at least one characteristic.
14. The method of claim 13 , further comprising determining said at least one characteristic on a continued basis.
15. The method of claim 13 , wherein said at least one characteristic indicates at least one of the following:
whether internal buffers are used in the transmitter,
whether framing of the data is performed,
whether fragmentation of the data is performed, and
whether the transmitter is able to perform bandwidth management.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/258,427 US20060053460A1 (en) | 1998-08-21 | 2005-10-25 | Transmission communications management |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/138,054 US6959451B1 (en) | 1998-08-21 | 1998-08-21 | Transmission communications management |
US11/258,427 US20060053460A1 (en) | 1998-08-21 | 2005-10-25 | Transmission communications management |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/138,054 Continuation US6959451B1 (en) | 1998-08-21 | 1998-08-21 | Transmission communications management |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060053460A1 true US20060053460A1 (en) | 2006-03-09 |
Family
ID=35115426
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/138,054 Expired - Fee Related US6959451B1 (en) | 1998-08-21 | 1998-08-21 | Transmission communications management |
US11/258,427 Abandoned US20060053460A1 (en) | 1998-08-21 | 2005-10-25 | Transmission communications management |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/138,054 Expired - Fee Related US6959451B1 (en) | 1998-08-21 | 1998-08-21 | Transmission communications management |
Country Status (1)
Country | Link |
---|---|
US (2) | US6959451B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010027561A1 (en) * | 1998-11-30 | 2001-10-04 | Microsoft Corporation | Video on demand methods and systems |
US20030189587A1 (en) * | 1998-11-30 | 2003-10-09 | Microsoft Corporation | Interactive video programming methods |
US20060095945A1 (en) * | 1998-11-30 | 2006-05-04 | Microsoft Corporation | Proxy for video on demand server control |
US20070294721A1 (en) * | 2006-06-20 | 2007-12-20 | Sbc Knowledge Ventures, Lp | System and method of providing supplemental video content related to targeted advertisements in a video stream |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7213061B1 (en) | 1999-04-29 | 2007-05-01 | Amx Llc | Internet control system and method |
JP2001326914A (en) * | 2000-03-08 | 2001-11-22 | Sony Corp | Distribution processing system for contents of electronic information, information distribution device, information processor and distribution processing method for contents of electronic information |
US7142508B2 (en) * | 2000-12-22 | 2006-11-28 | Radiance Technologies, Inc. | System and method for controlling data transfer rates on a network |
US20050273514A1 (en) * | 2000-12-22 | 2005-12-08 | Ray Milkey | System and method for automated and optimized file transfers among devices in a network |
AU2006287639C1 (en) * | 2005-09-07 | 2012-06-28 | Open Invention Network, Llc | Method and computer program for device configuration |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5497460A (en) * | 1994-06-20 | 1996-03-05 | International Business Machines Corporation | System and method for determining network connectivity |
US5539882A (en) * | 1992-12-16 | 1996-07-23 | International Business Machines Corporation | Method and system for an efficient multiple access polling protocol for interactive communication |
US5719942A (en) * | 1995-01-24 | 1998-02-17 | International Business Machines Corp. | System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node |
US5987519A (en) * | 1996-09-20 | 1999-11-16 | Georgia Tech Research Corporation | Telemedicine system using voice video and data encapsulation and de-encapsulation for communicating medical information between central monitoring stations and remote patient monitoring stations |
US5987518A (en) * | 1996-10-28 | 1999-11-16 | General Instrument Corporation | Method and apparatus for communicating internet protocol data over a broadband MPEG channel |
US6038625A (en) * | 1998-01-06 | 2000-03-14 | Sony Corporation Of Japan | Method and system for providing a device identification mechanism within a consumer audio/video network |
US6104705A (en) * | 1997-12-31 | 2000-08-15 | U.S. Philips Corporation | Group based control scheme for video compression |
US6181711B1 (en) * | 1997-06-26 | 2001-01-30 | Cisco Systems, Inc. | System and method for transporting a compressed video and data bit stream over a communication channel |
US6603775B1 (en) * | 1998-04-09 | 2003-08-05 | Aspect Communications Corporation | Dynamic allocation of communication resources within a communication system |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3691295A (en) * | 1970-03-31 | 1972-09-12 | Ibm | Two-way communication system for video and digital data |
US5002827A (en) * | 1987-10-26 | 1991-03-26 | Nippon Glass Fiber Co., Ltd. | Agglomerated glass flakes |
JP3222456B2 (en) * | 1990-07-30 | 2001-10-29 | 株式会社東芝 | Video monitoring system, transmitting device, receiving device, and video monitoring method |
US5506844A (en) * | 1994-05-20 | 1996-04-09 | Compression Labs, Inc. | Method for configuring a statistical multiplexer to dynamically allocate communication channel bandwidth |
US6044396A (en) * | 1995-12-14 | 2000-03-28 | Time Warner Cable, A Division Of Time Warner Entertainment Company, L.P. | Method and apparatus for utilizing the available bit rate in a constrained variable bit rate channel |
JP3000913B2 (en) * | 1996-02-02 | 2000-01-17 | 富士ゼロックス株式会社 | Data transmission apparatus and method |
JPH09284746A (en) * | 1996-04-19 | 1997-10-31 | Sony Corp | System and method for two-way information transmission |
US6225993B1 (en) * | 1996-04-22 | 2001-05-01 | Sun Microsystems, Inc. | Video on demand applet method and apparatus for inclusion of motion video in multimedia documents |
JP3435295B2 (en) * | 1996-09-30 | 2003-08-11 | 株式会社東芝 | Information transmitting device and traffic control device, band operation method and call accepting method using the same |
FI964640A (en) * | 1996-11-21 | 1998-07-28 | Nokia Multimedia Network Terminals Oy | Method for transmitting address information |
US6078919A (en) * | 1997-10-23 | 2000-06-20 | Lucent Technologies Inc. | Method and apparatus for delivery of data over a network based on determination of network parameters |
US6618392B1 (en) * | 1998-04-17 | 2003-09-09 | Advanced Micro Devices, Inc. | Network transceiver using signal detect input to control modes of operation |
-
1998
- 1998-08-21 US US09/138,054 patent/US6959451B1/en not_active Expired - Fee Related
-
2005
- 2005-10-25 US US11/258,427 patent/US20060053460A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5539882A (en) * | 1992-12-16 | 1996-07-23 | International Business Machines Corporation | Method and system for an efficient multiple access polling protocol for interactive communication |
US5497460A (en) * | 1994-06-20 | 1996-03-05 | International Business Machines Corporation | System and method for determining network connectivity |
US5719942A (en) * | 1995-01-24 | 1998-02-17 | International Business Machines Corp. | System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node |
US5987519A (en) * | 1996-09-20 | 1999-11-16 | Georgia Tech Research Corporation | Telemedicine system using voice video and data encapsulation and de-encapsulation for communicating medical information between central monitoring stations and remote patient monitoring stations |
US5987518A (en) * | 1996-10-28 | 1999-11-16 | General Instrument Corporation | Method and apparatus for communicating internet protocol data over a broadband MPEG channel |
US6181711B1 (en) * | 1997-06-26 | 2001-01-30 | Cisco Systems, Inc. | System and method for transporting a compressed video and data bit stream over a communication channel |
US6104705A (en) * | 1997-12-31 | 2000-08-15 | U.S. Philips Corporation | Group based control scheme for video compression |
US6038625A (en) * | 1998-01-06 | 2000-03-14 | Sony Corporation Of Japan | Method and system for providing a device identification mechanism within a consumer audio/video network |
US6603775B1 (en) * | 1998-04-09 | 2003-08-05 | Aspect Communications Corporation | Dynamic allocation of communication resources within a communication system |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060095945A1 (en) * | 1998-11-30 | 2006-05-04 | Microsoft Corporation | Proxy for video on demand server control |
US20050076379A1 (en) * | 1998-11-30 | 2005-04-07 | Microsoft Corporation | Video on demand methods and systems |
US20030189587A1 (en) * | 1998-11-30 | 2003-10-09 | Microsoft Corporation | Interactive video programming methods |
US20050028197A1 (en) * | 1998-11-30 | 2005-02-03 | Microsoft Corporation | Video on demand methods and systems |
US20010027561A1 (en) * | 1998-11-30 | 2001-10-04 | Microsoft Corporation | Video on demand methods and systems |
US20050044568A1 (en) * | 1998-11-30 | 2005-02-24 | Microsoft Corporation | Video on demand methods and systems |
US20010027563A1 (en) * | 1998-11-30 | 2001-10-04 | Microsoft Corporation | Video on demand methods and systems |
US20060010478A1 (en) * | 1998-11-30 | 2006-01-12 | Microsoft Corporation | Video on demand |
US20050034162A1 (en) * | 1998-11-30 | 2005-02-10 | Microsoft Corporation | Video on demand methods and systems |
US7913283B2 (en) | 1998-11-30 | 2011-03-22 | Microsoft Corporation | Video on demand methods and systems |
US20080148323A1 (en) * | 1998-11-30 | 2008-06-19 | Microsoft Corporation | Video on demand methods and systems |
US7392532B2 (en) * | 1998-11-30 | 2008-06-24 | Microsoft Corporation | Interactive video programming methods |
US20080196070A1 (en) * | 1998-11-30 | 2008-08-14 | Microsoft Corporation | Video on demand methods and systems |
US7793325B2 (en) | 1998-11-30 | 2010-09-07 | Microsoft Corporation | Video on demand methods and systems |
US7865919B2 (en) | 1998-11-30 | 2011-01-04 | Microsoft Corporation | Proxy for video on demand server control |
US20070294721A1 (en) * | 2006-06-20 | 2007-12-20 | Sbc Knowledge Ventures, Lp | System and method of providing supplemental video content related to targeted advertisements in a video stream |
Also Published As
Publication number | Publication date |
---|---|
US6959451B1 (en) | 2005-10-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20060053460A1 (en) | Transmission communications management | |
US6928656B1 (en) | Method for delivery of IP data over MPEG-2 transport networks | |
US7433937B2 (en) | Coupling a filter graph space to a network driver space | |
US7181759B2 (en) | System and method for providing interactivity for end-users over digital broadcast channels | |
US7333495B2 (en) | Method for scheduling upstream communications | |
US5797010A (en) | Multiple run-time execution environment support in a set-top processor | |
EP1266526B1 (en) | Method for scheduling upstream communications | |
EP1445914A2 (en) | Method and apparatus for delivery of a bytecode embedded within a transport stream | |
US20090168649A1 (en) | Methods and System for Efficient Data Transfer Over Hybrid Fiber Coax Infrastructure | |
US20020056143A1 (en) | Programmable broadband downstream module | |
US6557172B1 (en) | Communicating enhancement data in layers | |
US6813270B1 (en) | Method and system for generating and providing delayed media unit sequences to end-users | |
WO2009088749A2 (en) | Methods and system for efficient data transfer over hybrid fiber coax infrastructure | |
US7751315B1 (en) | Shared network path contention reduction | |
US7535888B1 (en) | System and method for providing in-band timing information to digital home communication terminals | |
EP1109405A1 (en) | Communication with receiver/decoder | |
EP1269666A2 (en) | Method and system for transmission of content description information and connection information in digital broadcast networks | |
EP2312773A2 (en) | Methods of managing a group of to be managed nodes and corresponding sequence of packets | |
US20230328310A1 (en) | System and method for wireless media streaming from television receiver | |
US20040199650A1 (en) | System and methods for accelerating data delivery | |
US7062779B1 (en) | Methods and apparatus for accessing synchronized broadcast data | |
CN102450029A (en) | Methods, apparatuses and computer program products for media recording | |
EP2141605A1 (en) | Method and device to perform direct memory access | |
CN100426864C (en) | Method for increasing broadcast effect of data flow | |
KR101197602B1 (en) | Methods and apparatus for transmitting and receiving interactive service using ubiquitous server and ubiquitous terminal on digital cable broadcasting system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |