HK1078215B - A method for acquiring data transmitted on a transmission channel - Google Patents
A method for acquiring data transmitted on a transmission channel Download PDFInfo
- Publication number
- HK1078215B HK1078215B HK05109989.9A HK05109989A HK1078215B HK 1078215 B HK1078215 B HK 1078215B HK 05109989 A HK05109989 A HK 05109989A HK 1078215 B HK1078215 B HK 1078215B
- Authority
- HK
- Hong Kong
- Prior art keywords
- data
- video
- controller
- coding
- transmission channel
- Prior art date
Links
Description
The present application is a divisional application of the invention patent application having application number 03103341.5 and application date 1997, 8/1.
Technical Field
The present invention relates to the field of digital signal processing, and more particularly to the collection, processing and storage of video data and program guide information derived from input data encoded in a variable broadcast encoding format.
Background
In video processing and storage applications, digital video data is typically encoded to meet the requirements of well-known standards. One such widely adopted standard is the MPEG2 (moving picture experts group) image coding standard, hereinafter referred to as the "MPEG standard". The MPEG standard comprises a system coding part (ISO/IEC13818-1, 10.6.1994) and a video coding part (ISO/IEC 13818-2, 20.1.1995), hereinafter referred to as "MPEG system standard" and "MPEG video standard", respectively. Video data encoded according to the MPEG standard is in the form of a packetized data stream that typically includes data content for a number of program channels (e.g., content corresponding to cable television channels 1-125). For example, in order for a decoder to decode a packetized data stream and recover the video data content of a selected program channel for display, individual packets containing the selected program channel must be identified and combined.
To recover the content of the selected program channel, the information in the program guide is used to identify and combine the individual data packets that make up the selected program. Program guide data is collected for this purpose from a program data stream input to a video decoder. The program guide data is organized into a Main Program Guide (MPG) sufficient to decode the selected program. Once it is composed, the MPG can be used to decode the selected program or it can be transmitted to another application device along with the data content of the selected program. However, in some video transmission systems, the MPG must be collected and composed from program guide data encoded in a variable broadcast encoding format.
Variable broadcast encoding formats are used in wireless terrestrial video broadcast systems to selectively provide enhanced levels of broadcast signal immunity. However, broadcast coding formats that provide enhanced immunity to interference also require increased transmission bandwidth. One example of a system that uses a variable broadcast encoding format is the proprietary Multipoint Microwave Distribution System (MMDS), which employs a "line-of-sight" transmission system. In such a system, encoding formats that provide a higher degree of immunity to the broadcast signal also result in a higher overhead in error correction coding and therefore require a greater transmission bandwidth. Similarly, for a fixed transmission bandwidth, providing a higher degree of immunity to broadcast signals reduces the amount of information throughput that can be achieved. In addition, the encoding format used may vary on a temporal or geographic basis to accommodate changes in reception conditions related to atmospheric or terrestrial characteristics.
The variation of the broadcast modulation and the error correction coding format and associated required transmission bandwidth present problems for the video receiver when decoding the variable coding format and acquiring a compatible MPG. These problems are solved with the system according to the invention.
The use of variable broadcast encoding formats may result in variations in the transmission bandwidth available for program data content. The present inventors have recognized that the number of program channels transmitted using a variable broadcast encoding format may vary along with the encoding format. Furthermore, the number of program channels may vary with time and geographic broadcast area.
The present inventors have further recognized that it is desirable for a receiver system to be able to adaptively receive variable broadcast encoding formats and a variable number of program channels. This allows the signal immunity of the broadcast system to meet the requirements of a particular broadcast area. In a particular broadcast area, for example, an area with degraded reception conditions due to hilly terrain, the receiver may be configured to provide a higher broadcast signal immunity.
Disclosure of Invention
It is an object of the invention to provide a system for receiving variable coding formats and transmission channel numbers.
In accordance with one aspect of the present invention, in a system for receiving a digital data stream representing video information encoded in one of a plurality of different formats and transmitted on one of a plurality of transmission channels, a method for collecting data transmitted on the transmission channel, comprising the steps of: a) selecting a transmission channel from the plurality of channels; b) selecting a modulation format; c) tuning to receive the modulation format; d) determining whether valid data is received on the selected transmission channel; e) repeating steps a-d until the valid data is received; f) capturing program guide information for the selected transmission channel; and g) retuning to receive a transmission channel in response to the program guide information.
The disclosed receiver system automatically adaptively tunes to a broadcast signal that is variable in the following respects: a) number and frequency allocation of transmitted channels, b) signal coding type such as trellis coding or non-trellis coding, and c) modulation format such as a format employing symbol clustering (constellation) of 64 or 256 elements.
In accordance with the principles of the present invention, a system receives a digital bit stream representing video information encoded in one of a plurality of different formats and transmitted on one of a plurality of transmission channels. In the system, a method for collecting data for transmission over a transmission channel includes selecting a transmission channel from a plurality of channels and selecting a modulation format. The method also includes tuning to a receive modulation format and determining whether valid data is received on the selected transmission channel. The method steps are repeated.
According to one feature of the invention, a method for collecting data transmitted over a transmission channel includes selecting a coding type and tuning to receive the coding type.
According to another feature of the present invention, a method for collecting data includes repeating the steps of the method until valid data is received, capturing program guide information for a selected transmission channel, and retuning to receive a transmission channel in response to the program guide information.
Drawings
In the figure:
fig. 1 is a block diagram of an apparatus for demodulating and decoding signals of a variable broadcast encoding format for display in accordance with the principles of the present invention.
Fig. 2 shows a flow diagram of a process for tuning a forward error correction decoder system to a variable broadcast encoding format signal.
Fig. 3 shows a flow chart of a process for acquiring a Main Program Guide (MPG) from an input signal containing a plurality of Physical Transmission Channels (PTCs).
Fig. 4 shows a flow diagram of a process for providing selected video channel or program guide information for display from an input signal containing a plurality of Physical Transmission Channels (PTCs).
Fig. 5 shows a flow chart of a process for composing program guide information and incorporating the program guide information into a video program data stream for transmission in a variable broadcast encoding format.
Detailed Description
Fig. 1 is a block diagram of a receiver system for demodulating and decoding signals of a variable broadcast encoding format for display in accordance with the principles of the present invention. The receiver system automatically adaptively tunes to a broadcast signal that is variable in the following respects: a) the number and frequency allocation of transmitted channels, b) the type of signal coding, e.g., trellis coded or non-trellis coded, and c) the modulation format, e.g., a format employing symbol clusters of 64 or 256 elements. To facilitate reception and decoding of variable broadcast encoding formats, parameters indicating the type of encoding and modulation format are advantageously incorporated into the program guide information within the transport signal.
The ability of the receiver system of fig. 1 to adaptively receive variable broadcast encoding formats allows the signal immunity of the broadcast system to meet the needs of a particular broadcast area. For example, the receiver may be configured to provide a higher broadcast signal immunity in a particular broadcast area that is degraded by reception conditions in hilly terrain. In this mode, the receiver may be configured to a less noise sensitive modulation format, such as with 64 elements (better than 256 elements) and, for example, trellis coded data. However, enhanced noise immunity coding requires more signal bandwidth, which results in less bandwidth being available for program data content, thereby transmitting fewer program channels. Thus, the receiver of fig. 1 also accommodates variations in the number and frequency allocation of the transmitted channels.
Although the disclosed system is described in terms of a system for receiving MPEG compatible variable broadcast encoding format signals, it is merely exemplary. The principles of the present invention may be applied to systems in which the transmission channels may vary in number or frequency allocation, or to systems in which the type of coding or modulation format may vary. Such systems may include, for example, non-MPEG compatible systems involving other types of encoded data streams and other methods of transmitting program guide signals. Additionally, although the disclosed system is described as processing broadcast programs, this is merely an example. For example, the term "program" is used to denote any form of packetized data such as telephone messages, computer programs, internet data or other communications.
In general, in the video receiver system 12 of fig. 1, a carrier modulated with video data is received by an antenna 15 and processed by a unit 20. The resulting digital output signal is demodulated by a demodulator 25. The demodulated output from unit 25 is optionally differentially decoded by decoder 30 and provided to unit 50 via multiplexer 35 and multiplexer 45 following the optional trellis decoding of trellis decoder 40. The optionally trellis decoded output from multiplexer 45 is mapped by unit 50 to byte length data segments, deinterleaved and Reed-Solomon error corrected. The corrected output data from unit 50 is processed by an MPEG compatible transport processor 55 which separates the data according to type based header information analysis and provides synchronization and error indication information for subsequent video data decompression. The compressed video and audio output data from processor 55 is decompressed by MPEG decoder 60 to provide audio and video output data to audio processor 70 and video processor 65. Processors 65 and 70 format the audio and video signals to fit into unit 75 for reproduction.
A user of the video receiver selects for viewing either a video channel or an on-screen menu, such as a program guide, using a remote control (not shown for simplicity of the drawing). The system controller 17 employs selection information provided from the remote control to appropriately configure the elements of fig. 1 to receive, demodulate and decode input signal encoding types including differential or non-differential encoding, trellis or non-trellis encoding, and input signal modulation formats containing symbol clusters of 64 or 256 elements. The elements 20, 25, 30, 40, 50 and 55 of fig. 1 are configured with respect to the input signal type, respectively, by control register values provided within these elements and by selecting the signal path via multiplexers 35 and 45 using bidirectional data and control signal bus C. It should be noted that the demodulator and decoder functions implemented by the units 20, 25, 30, 40 and 50 are each well known and are described generally, for example, in the reference book "digital communications" by Lee and Messerschmidt (Kluwer Academic Press, Boston, MA, USA, 1988).
Considering fig. 1 in detail, the carrier wave modulated with video data received by antenna 15 is converted to digital form and processed by input processor 20. The processor 20 includes a Radio Frequency (RF) tuner and an Intermediate Frequency (IF) mixer and an amplification stage for downconverting the input video signal to a lower frequency band suitable for further processing. In this exemplary system, the input signal received by the antenna contains 33 physical transmission channels (PTC 0-32). Each Physical Transmission Channel (PTC) is allocated a 6MHz bandwidth and contains up to 6 video channels, corresponding for example to cable tv channels 2-7.
Assume for exemplary purposes that a video receiver user selects a video channel (SC) for viewing using a remote control (not shown for simplicity). The system controller 17 suitably configures the elements of the system 12 to receive the PTC corresponding to the selected video channel SC using selection information provided by the remote control. After downconversion, the output signal from unit 20 has a bandwidth of 6MHz for the selected PTC and a center frequency in the range of 119-405 MHz.
Controller 17 configures the Radio Frequency (RF) tuner and Intermediate Frequency (IF) mixer and amplification stages of unit 20 to receive the selected PTC. The down-converted frequency output of the selected PTC is conditioned by unit 25. The main functions of the demodulator 25 are to recover and track the carrier frequency, to recover the transmitted data clock frequency and to recover the video data itself.
The output of carrier recovery loop processing unit 20 in unit 25 recovers the baseband video information. The data from unit 20 is a binary data stream representing a sequence of symbols, each symbol in the sequence of symbols being represented by an assigned digital value. As is well known, a set of symbols can be represented on a complex plane as a set of points called a symbol cluster. The variable broadcast signal format input to the system 12 employs 64-point or 256-point Quadrature Amplitude Modulation (QAM) symbol constellations. As is well known, the carrier recovery loop function in unit 25 compensates for symbol point offsets and symbol point rotations caused by phase and frequency jitter in the carrier frequency introduced by the transmission channel and oscillator instability in the Low Noise Block (LNB) down-converter.
The unit 25 carrier recovery loop derives a carrier offset value indicative of the symbol point rotation caused by the frequency error between the transmitted and derived carrier frequencies of the selected PTC. The derived carrier offset value is used by the unit 25 carrier recovery loop to compensate for the symbol rotation caused by this frequency error. The carrier offset values in the exemplary embodiment do not vary significantly between different PTCs. Thus, once a carrier offset value is derived for one PTC, it is stored by controller 17 and applied to unit 25 carrier recovery loop to speed up system 12 retuning to other PTCs. By applying the stored carrier offset value to the unit 25 carrier recovery loop, the time required to retune the system 12 to a different PTC is reduced, since the offset value speeds up the convergence of the recovery loop. To compensate for frequency drift and other variations that affect carrier loop convergence, the controller 17 provides a carrier offset value that is periodically derived and updated. System 12 can be selectively configured to derive a carrier offset value specific to each PTC for carrier recovery loop compensation.
As is well known, the unit 25 demodulator also contains an equalizer function used in conjunction with the carrier recovery loop for the purpose of compensating for disturbances in the transmission channel and reducing inter-symbol interference. In addition, a slicer in unit 25 applies a series of decision thresholds to the corrected output from the carrier recovery loop to recover the symbol sequence of the data input to demodulator 25. Controller 17 configures the slicer for 64-point or 256-point QAM symbol constellation in response to a configuration control signal C. The recovered video data output from unit 25 is provided to differential decoder 30.
Unit 25 also recovers a sampling and synchronization clock corresponding to the transmitter clock and is used to time the operation of processor 20, demodulator 25 and differential decoder 30. The clock is derived in unit 25 by deriving phase and timing error signals from a comparison of the slicer input and output data according to well known principles. The derived error signal is filtered and applied to a control input of a voltage controlled crystal oscillator to generate a clock. Alternatively, a clock frequency greater than twice the symbol rate may be used as the sampling clock.
The output of demodulator 25 is optionally differentially decoded by unit 30 and passed to multiplexer 35. Differential encoding/decoding is a well-known technique for overcoming problems associated with potential phase ambiguity in deriving the carrier and recovering symbol constellation.
The controller 17 determines whether the input data is trellis-decoded based on parameters in the input data or whether trellis decoding is arbitrarily selected as part of the iterative initialization process. As will be discussed below in conjunction with fig. 2, this initialization process is used to appropriately configure the system 12 to collect and decode the received input data. If controller 17 selects a trellis decoding mode, either the differentially decoded data from decoder 30 or the demodulated data from unit 25 is passed to trellis decoder 40 via multiplexer 35. The decoder 40 applies well-known trellis decoding principles to detect the code sequence of the trellis-encoded data from the multiplexer 35. The decoder 40 determines from the data symbols received by the multiplexer 35 the maximum possible corresponding bit sequence that has been trellis encoded by the encoder and thus identifies the corresponding transmitted data symbol. The resulting recovered original data is supplied to unit 50 via multiplexer 45. However, if controller 17 selects the non-trellis decoding mode, either the differentially decoded data from decoder 30 or the demodulated data from unit 25 are provided to unit 50, bypassing trellis decoder 40, via multiplexers 35 and 45.
The output of multiplexer 45 is mapped by unit 50 to byte length data segments, deinterleaved and Reed-Solomon error corrected according to well known principles. In addition, unit 50 provides a Forward Error Correction (FEC) validity or lock indication to controller 17. Reed-Solomon error correction is a well-known type of forward error correction. The FEC lock indicator signal for Reed-Solomon error correction is synchronized to the corrected data and provides an effective output.
The corrected output data from unit 50 is processed by an MPEG compatible transport processor 55. Individual packets containing specific program channel content or program guide information are identified by their Packet Identifiers (PIDs). The processor 55 separates the data according to the type of analysis based on Packet Identifiers (PIDs) included in the header information and provides synchronization and error indication information for subsequent decompression of the video data.
The PIDs contained in a Main Program Guide (MPG) are used to identify and combine packets comprising the selected program channel. However, the PID identifying the MPG packet is predetermined and stored in the internal memory of the controller 17. Thus, after the controller 17 generates valid data to the transport processor 55 from the FEC lock indication determination system 12 provided by unit 50, the MPG present at each PTC is collected without additional PID information. Using control signal C, controller 17 configures transport processor 55 to select packets containing MPG. Processor 55 compares the PID of the incoming packet provided by multiplexer 45 with the PID value preloaded by controller 17 in the control register of unit 55. The controller 17 collects a complete MPG by accessing and combining the MPG packets identified and captured by the processor 55.
Information in the MPG that allows the controller 17 together with the processor 55 to identify packets containing the respective programs is called a channel map. The MPG advantageously also includes channel map information that allows identification of packets containing all PTCs and individual programs of different broadcast encoding formats. Different channel maps are associated with different broadcast coding formats because the maximum number of Physical Transmission Channels (PTCs) available is determined by the transmission bandwidth available for a particular coding format. As explained earlier, the use of encoding formats that provide higher signal immunity results in less bandwidth being available for the transmission of program content. In normal broadcast operation, the channel map may also change to allow for changes in the program content being sent between different broadcast areas, or to allow for changes in services, i.e., additions or deletions.
The controller 17 uses the channel map information in the captured MPG to identify packets containing the video channel SC selected for viewing by the user. The processor 55 compares the PID of the incoming packets provided by the multiplexer 45 with the PID value of the video channel SC preloaded by the controller 17 in a control register within the unit 55. In this manner, the processor 55 captures the packets of the video channel SC and combines them into an MPEG compatible data stream containing compressed video and audio data representing the program content of the selected video channel SC.
The compressed video and audio output data from processor 55 are decompressed by MPEG decoder 60 to provide audio and video output data to audio processor 70 and video processor 65. Processors 65 and 70 format the audio and video signals for reproduction by unit 75. It should be noted that the MPEG compatible data stream to which the MPG output is added by processor 55 is alternately supplied to a storage device for storage (not shown for simplicity).
As previously discussed in connection with fig. 1, the controller 17 employs the process of fig. 2 to tune and configure the processor 20, demodulator 25, differential decoder 30 and trellis decoder 40 to receive signals in a variable broadcast encoding format. The process of fig. 2 automatically adaptively tunes system 12 to receive signals that vary in the following ways: a) the number and frequency allocation of transmitted channels, b) the type of signal coding, such as trellis or non-trellis coding, or differential or non-differential coding, and c) the modulation format, such as one using symbol clusters of 64 or 256 elements. The procedure of fig. 2 is for when the FEC lock indication provided by unit 50 (fig. 1) signals that locking has not been achieved. Such a condition may occur, for example, upon first power-up or after a change in a broadcast encoding format of the encoder. In the exemplary process of fig. 2, the input data to system 12 is either both differential encoded and trellis encoded or neither.
After the start of step 100 of fig. 2, a carrier offset value is derived in step 105 in the manner described above in connection with fig. 1. A carrier offset value is derived for an initial PTC, e.g. PTC ═ 0, and applied by controller 17 to the unit 25 carrier recovery loop at step 105. At step 110, the controller 17 is programmed to iteratively execute process step 115 of fig. 2 for each PTC, starting with the first PTC (PTC ═ 0) until the FEC locks onto one of the resulting PTCs 150.
Controller 17 configures demodulator 25 for a 64-point QAM modulation format symbol constellation and configures multiplexers 35 and 45 to provide outputs from demodulator 25 to unit 50 bypassing decoder 30 and trellis decoder 40 at step 115. If controller 17 determines at step 120 that unit 50 has not achieved FEC lock, controller 17 performs step 125 to configure demodulator 25 for a 64-point QAM modulation format. In addition, controller 17 configures decoder 30 and decoder 40 to differentially decode and trellis decode the output data from demodulator 25 at step 125 to provide differentially decoded and trellis decoded data to unit 50 via multiplexers 35 and 45.
If controller 17 determines at step 130 that unit 50 has not achieved FEC lock, controller 17 executes step 135 to configure demodulator 25 for a 256-point QAM modulation format symbol constellation. Controller 17 also configures multiplexers 35 and 45 to provide output data from demodulator 25 to unit 50 bypassing decoder 30 and trellis decoder 40 at step 135. If controller 17 determines at step 140 that unit 50 has not achieved FEC locking, controller 17 executes step 145 to configure demodulator 25 for a 256-point QAM modulation format. In addition, controller 17 configures decoder 30 and decoder 40 to differentially decode and trellis decode the output data from demodulator 25 at step 145 to provide differentially decoded and trellis decoded data to unit 50 via multiplexers 35 and 45.
If the controller 17 determines at step 150 that the unit 50 has not achieved FEC locking after the iteration through step 115 and 150 for each PTC (PTC 0-32), the controller 17 provides a system error indication to the user at step 155. This may take the form of a panel light indication, or a graphic display of a fault on the reproduction means 75, or an error message or another error indication transmitted by the telephone line. However, if the unit 50 obtains an FEC lock for any PTC at steps 120,130,140 or 150, the controller 17 performs step 160. At step 160, the controller 17 stores the carrier offset value in its internal memory, the modulation format (64 or 256 point QAM) and the type of coding (trellis coded or non-trellis coded) of the PTC that has obtained the FEC lock. And ends at step 165 after completing step 155 or 160 of the fig. 2 process.
The controller 17 employs the process of fig. 3 to collect a Main Program Guide (MPG) from an input signal containing a plurality of Physical Transmission Channels (PTCs). The process of fig. 3 is used after the process of fig. 2 to tune the system 12 to a particular PTC. However, the process of fig. 3 may also be applied whenever it is desired to obtain a new MPG, such as after changing a broadcast encoding format in an encoder.
After the start of step 200 of fig. 3, controller 17 searches the data output from multiplexer 45 (fig. 1) for an MPG packet. As discussed previously in connection with fig. 1, the controller 17 preloads the MPG PID value at step 205 within internal registers within the processor 55. The processor 55 compares the MPG PID value with the PID value of the packet input from the multiplexer 45 and captures the identified MPG packet. After detecting the MPG packet at step 210, the controller 17 transfers the MPG packet captured by the processor 55 to the internal memory at step 240. The controller 17 continues the process of step 240 until a complete, valid and error-free MPG is obtained, decoded and combined in internal memory. If the controller 17 determines at step 245 that a complete, valid and error-free MPG has been acquired, the execution of the FIG. 3 process is complete and ends at step 260.
If controller 17 determines at step 245 that a complete, valid and error-free MPG has not been collected, controller 17 configures system 12 (fig. 1) to receive the next PTC at step 215, e.g., PTC No. 1 if the current PTC is zero. Likewise, if at step 210 the processor 55 does not detect an MPG packet, the controller 17 similarly configures the system 12 to receive the next PTC at step 215. However, if the controller 17 determines in step 220 that all available PTCs have not been successfully searched, the controller 17 indicates a system error to the user in step 230. This may take the form of a panel light indication, or a graphic display of a fault on the reproduction device 75, or an error message or another type of error indication transmitted by a telephone line.
If controller 17 determines at step 220 that all available PTCs have not been searched, controller 17 performs the previously described tuning process of fig. 2 at step 225 from step 115 (fig. 2) for the PTC selected at step 215 (fig. 3). This portion of the process of fig. 2 is used to tune the system 12 to the PTC selected at step 215 (fig. 3). After tuning system 12 to the new PTC at step 225, controller 17 repeats the process of fig. 3 to obtain the MPG beginning at step 205. After an error indication is generated at step 230 or an MPG is successfully acquired at step 245, the implementation of fig. 3 is complete and ends at step 260.
Controller 17 applies the process of fig. 4 to provide selected video channels or program guide information for display from an input signal containing multiple Physical Transmission Channels (PTCs) and variable modulation and coding formats. The process of fig. 4 is used, for example, after the MPG acquisition of the process of fig. 3.
After beginning at step 300 of fig. 4, controller 17 determines from the selection information provided by the remote control whether a user requests to view a video channel or a program guide at step 305. If a video channel (SC) is selected, the controller 17 determines at step 310 on which PTC the selected channel SC is transmitted using the previously stored MPG information. The controller 17 determines whether the PTC for the selected channel is different from the PTC currently tuned by the system 12 at step 315. If the PTC of the selected channel is different from the current PTC, the controller 17 configures the system 12 with the carrier offset value, modulation format (64 or 256 point QAM) and coding type (trellis coded or non-trellis coded) of the desired PTC at step 320. The modulation format and type of encoding of the required PTC is determined by the controller 17 from parameters in the stored MPG data. The carrier offset value for the desired PTC is derived by the controller 17 from the stored offset data previously determined in the acquisition process of fig. 2.
At step 325, the controller 17 performs the previously described tuning process of fig. 2 from step 115 (fig. 2). This portion of the fig. 2 process is used to tune the system 12 to the PTC determined at step 310 (fig. 3) and the selected video channel SC is transmitted on the PTC. However, at step 315, if the PTC of the selected video channel SC is the same as the PTC currently tuned by the system 12, the controller 17 bypasses step 320 and continues the process of step 330.
At step 330, the controller 17 uses the MPG data to identify the packets containing the video channel SC selected for viewing by the user. As depicted in fig. 1, the processor 55 compares the PID of the incoming packets provided by the multiplexer 45 with the PID value of the video channel SC preloaded by the controller 17 in a control register within the unit 55. In this manner, the processor 55 is controlled by the controller 17 at step 335 to capture the packets of the video channel SC and assemble them into an MPEG compatible data stream containing compressed video and audio data representing the program content of the selected video channel SC.
At step 365, the compressed video and audio output data from processor 55, as directed by controller 17, is decompressed by MPEG decoder 60 to provide audio and video output data to audio processor 70 and video processor 65. In addition, at step 365, processors 65 and 70 format the audio and video signals for reproduction by unit 75. The process of fig. 4 ends at step 370.
However, if the video receiver user requests to view a program guide at step 305, the controller 17 determines whether a Special Program Guide (SPG) or an MPG is requested at step 350. The MPG transmits on each PTC and includes all the information necessary to identify and combine data packets comprising a selected video channel program or an SPG. In contrast, SPG is an optional guideline and may only be sent over a limited number of PTCs, e.g., 0. In addition, there are several different SPGs and a single SPG may contain only the information of the selected video channel.
In the example process of fig. 4, the SPG is sent on the PTC zero. Thus, if an SPG is requested to view at step 350, the controller 17 sets the required PTC to zero at step 360 and continues execution of the fig. 4 process from step 315 in the manner previously described. However, if viewing of an MPG is requested at step 350, the controller 17 retrieves the MPG data previously stored in the internal memory and forms an MPG representative data stream with the processor 55 at step 355. The resulting MPG provided by processor 55 indicates that the data stream is an MPEG compatible data stream containing compressed video and audio data. At step 365, the compressed video and audio output data from processor 55 is decompressed by MPEG decoder 60 to provide audio and video output data to audio processor 70 and video processor 65. In addition, at step 365, processors 65 and 70 format the audio and video signals for reproduction by unit 75. The process of fig. 4 ends at step 370.
The principles of the present invention also apply to the formation, encoding and transmission of data streams in conjunction with an MPG as described herein. The principles of the present invention apply to the formation of an MPG incorporating channel mapping information that allows for the identification of packets containing all PTCs and individual programs of different broadcast encoding formats. The principles of the present invention apply analogously to the formation of MPG in combination with parameters indicating modulation format and coding type.
Data streams formed in accordance with the principles of the present invention may be used for communication in a variety of applications including, for example, video server or PC type communication via telephone lines. A video program data stream formed in accordance with the principles of the present invention in conjunction with an MPG may be recorded on a storage medium and transmitted or rebroadcast to other servers, PCs or receivers. In addition, the video program may be stored in a trellis-coded or non-trellis-coded form, for example.
If a program is stored in trellis coded form, the stored program guide information includes modulation and coding type data to facilitate later demodulation and decoding of the program by a receiver when retrieving and rebroadcasting the program. If the program is stored in a non-trellis coded form, a server may modulate and trellis code the program based on the modulation and coding type data transmitted on the program guide when searching for programs from the storage medium. The program may then be retransmitted to other receivers, which may use the modulation and coding type data in the program guide information to facilitate demodulation and decoding of the program. Similarly, in video server type applications involving the re-broadcasting of programs, the server may re-modulate the transmitted program data according to the program guide information.
Fig. 5 shows a flow diagram of a process for forming and incorporating program guide information into a video program data stream for transmission in a variable broadcast encoding format. After the start of step 400 in fig. 5, parameters are generated at step 405 indicating the modulation format and the type of encoding used to transmit each PTC. At step 410, a channel map is generated to identify data packets containing the respective video program and accompanying audio data to be transmitted on each PTC. At step 415, the modulation format and coding type indicator parameters generated at step 405 are incorporated into the channel map, thereby associating a PTC with a particular broadcast coding format and a particular video program. The program guide format may be of various types. For example, it may comply with Program Specific Information (PSI) requirements specified by the MPEG system standard in section 2.2.4 or it may comply with the High Definition Television (HDTV) signal standard "digital television standard for HDTV transmission" set by the Advanced Television Systems Committee (ATSC) in the united states at 12 months 4 in 1995. Alternatively, it may be formed according to proprietary or customized requirements of a particular system.
At step 420, program guide information is formed in conjunction with the channel map and modulation format and encoding type parameters. The program guide information is combined into a selected video program data stream at step 425 to form a video output program. At step 430, the video output program data is further processed for suitable transmission, for example, to another device, such as a receiver, video server or storage device for recording on a storage medium. The process performed at step 430 includes well-known encoding functions such as data compression Reed-Solomon encoding, de-interleaving, scrambling, optional trellis encoding, differential encoding and modulation. This process is complete and ends at step 435.
The structure of fig. 1 is not exclusive. Other configurations may be derived to achieve the same objectives in accordance with the principles of the present invention. In addition, the functions of the elements of system 12 of FIG. 1 and the process steps of FIGS. 2-5 may be performed in whole or in part within the programming instructions of a microprocessor. In addition, the principles of the present invention apply to any form of MPEG or non-MPEG compatible electronic program guide. Further, while the disclosed system receives variable broadcast QAM modulation formats and trellis-coded or non-trellis-coded data, it is by way of example only. The principles of the present invention may be applied to systems receiving other types of signal coding than just selectable trellis coding, and other modulation formats than just QAM, including Pulse Amplitude Modulation (PAM) forms.
Claims (10)
1. In a system for receiving a digital data stream representing video information encoded in one of a plurality of different formats and transmitted on one of a plurality of transmission channels, a method of collecting data transmitted on the transmission channel comprising the steps of:
a) selecting one transmission channel from the plurality of transmission channels;
b) selecting a modulation format;
c) tuning to receive the modulation format;
d) determining whether valid data is received on the selected transmission channel based on a forward error correction function;
e) repeating steps a-d until the valid data is received, wherein the valid data is indicated according to a forward error correction function;
f) capturing program guide information on the selected transmission channel; and
g) retuning to receive a transmission channel in response to the program guide information.
2. The method of claim 1, further comprising the step of selecting a coding type from a plurality of coding types.
3. The method of claim 2, wherein the repeating step comprises repeating steps a-d for each of the plurality of coding types.
4. The method of claim 2, wherein the plurality of coding types include trellis coding and non-trellis coding.
5. The method of claim 2, wherein the plurality of coding types includes an error correction coding type.
6. The method of claim 1, wherein the tuning and retuning steps include configuring a demodulator.
7. The method of claim 1, wherein the tuning and retuning steps include configuring a decoder.
8. The method of claim 1, wherein the repeating step comprises repeating steps a-d for each of the plurality of transmission channels.
9. The method of claim 1, wherein the repeating step comprises repeating steps a-d for each of a plurality of modulation formats.
10. The method of claim 9, wherein the plurality of modulation formats includes modulation formats of different symbol constellation sizes.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US2437196P | 1996-08-01 | 1996-08-01 | |
| US60/024,371 | 1996-08-01 | ||
| US08/818,591 | 1997-03-18 | ||
| US08/818,591 US6366326B1 (en) | 1996-08-01 | 1997-03-18 | System for acquiring, processing, and storing video data and program guides transmitted in different coding formats |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| HK1078215A1 HK1078215A1 (en) | 2006-03-03 |
| HK1078215B true HK1078215B (en) | 2008-06-06 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5065174B2 (en) | Program guide and system for forming video data for storage and transmission in different signal formats | |
| JP5049403B2 (en) | Apparatus and method for receiving variable encoding format and transmission channel number | |
| JP5078072B2 (en) | System for retrieving and processing video data and program guides transmitted in different encoding formats | |
| HK1078215B (en) | A method for acquiring data transmitted on a transmission channel | |
| HK1009578B (en) | Multipoint microwave distribution system and program guide | |
| HK1009224B (en) | A method of formatting video data | |
| HK1058874B (en) | Method for forming program guides | |
| HK1009225B (en) | A system for acquiring and processing video data and program guides transmitted in different coding formats | |
| MXPA97005811A (en) | System for acquiring and processing video data and program guides transmitted in different coding formats |