HK1036901B - A multimedia system for processing program guides and associated multimedia objects - Google Patents

Description

Multimedia system for processing program guide and related multimedia objects

Technical Field

The present invention relates to the field of digital signal processing, and more particularly to program guides for channels and programs.

Background

Forming and processing large program guides that convey information that may involve thousands of broadcast program channels covering a wide geographic area raises a number of problems. For example, the geographic area covered may encompass the entire country or continent, and a large amount of information may have to be acquired, collated, and encoded for later broadcast in a format that decodes the broadcast material. The bandwidth required to process such a large amount of information expands in proportion to the amount of information processed. Therefore, there is a need to construct program guide data to optimize the use of available bandwidth.

The extent to which the program guide data structure can be optimized is constrained by the cost of the decoder unit receiving the structured data. In fact, there is a trade-off made between transmission bandwidth and decoder complexity. At one extreme of this tradeoff, all duplicate and redundant data elements in the program guide information are deleted to minimize the required transmission and processing bandwidth. As a result, each decoder needs to receive, buffer, parse, and collate information from the entire program guide data stream, thus requiring a decoder that is both complex and costly.

At the other extreme of the trade-off, the program guide information is partitioned into several subsets that meet the needs of specific users and groups of users. This means that each decoder needs to receive, buffer, analyze and collate the target information with minimal redundancy, which facilitates the use of less processing power. Simpler and cheaper decoders. However, such partitions require more transmission bandwidth to accommodate the increased information redundancy that results from the need to insert duplicate program guide information items into multiple different subsets of the program guide corresponding to different partitions. The problems related to handling large amounts of program guide information and achieving a desirable tradeoff between transmission bandwidth and demodulator complexity are solved by the system of the present invention. The derivative problems arising from the construction and partitioning of program guide data to facilitate decoding and selectable program guide generation by a decoder are also addressed by the system of the present invention.

Disclosure of Invention

It is, therefore, an object of the present invention to provide a decoding apparatus and method capable of processing a large amount of program guide information and enabling a demodulator to be reduced in complexity with a small transmission bandwidth.

To achieve the above object of the present invention, there is provided an apparatus for decoding packetized program data from at least a first source to provide a program guide, comprising: a first processor (22, 60) for obtaining program guide information and auxiliary information in said packetized program data, said auxiliary information comprising, (a) a directory of executable software application files associated with objects, and (b) a map for associating said objects with said program guide information entries; a second processor (60, 30, 37) for executing the executable software application file to link a desired object to a program guide information item in order to create a program guide having a desired information content; and a display processor for forming a composite image including the linked object and the program guide information item for display.

To achieve the above object of the present invention, there is also provided a method of decoding packetized program data from at least a first source to provide a program guide, including the step of acquiring program guide information and auxiliary information in the packetized program data, wherein the auxiliary information includes: (a) a directory of executable software application files associated with objects, and (b) a map for associating the objects with the program guide information entries; and the method further comprises the steps of: executing the executable software application file to process the program guide information items to form a program guide for display; and adjusting the formed program guide information for display.

Drawings

In the drawings:

FIG. 1 illustrates a Very Large Program Guide (VLPG) hierarchical file/table format for conveying program specific information in accordance with the present invention;

fig. 2 shows a Master Guide Table (MGT) format for delivering program specific information in accordance with the present invention;

FIG. 3 illustrates a Channel Information Table (CIT) format for transmitting program specific information inserted based on region partitions according to the present invention;

FIG. 4 illustrates a data structure format for a multimedia object inserted with zone and time based partitions according to the present invention;

fig. 5, 6 and 7 show examples of data structures of basic information files for channels, events and control objects according to the present invention;

fig. 8 shows a data structure containing a carouseld field (as used in the tables of fig. 5-7) compatible with MPEG (moving picture experts group) allowing zone and time partition based identifier fields;

FIG. 9 illustrates a master database table data structure format with layer-based version identifiers and unit partition identifiers inserted to support dynamic program guide re-partitioning in accordance with the present invention;

FIG. 10 illustrates an exemplary data structure of the present invention with an element type indicator (as used in the table of FIG. 9) inserted into the identifier field based on region, time, and complexity;

FIG. 11 shows a hierarchical directory format of an object database containing channels, events and control subdirectories in accordance with the present invention;

FIG. 12 illustrates a method of generating program specific information in accordance with the present invention;

fig. 13 is a block diagram of a digital video receiving device demodulating and decoding a broadcast signal containing VLPG information according to the principles of the present invention.

Detailed Description

A broadcast program transmitted in a digital format is encoded and broadcast together with auxiliary information, which contains Program Specific Information (PSI) for decoding the program and associated data. The program specific information contains program guide data and information for identifying and combining data packets to recover the content of the selected program channel. The program specific information and related program content is advantageously structured to convey a large program guide carrying information that may relate to thousands of broadcast program channels and related multimedia objects covering a wide geographic area (e.g., an entire continent, country, or state). Multimedia objects include audio clips (audio clips), video clips (video clips), animations, still images, internet data, email messages, text, and other types of data. A multimedia object is a data entity that can be viewed as a separate unit and is associated with an image within each program or with a program guide component. For example, the multimedia object is incorporated in a composite video image representing a program guide or video program. The auxiliary information data structure supports one-way communication applications, e.g., passive viewing, and two-way communication applications, e.g., interactive functions, and also supports storage applications.

The program specific information and related program content may be delivered by different service providers via the internet in a broadcast/multicast fashion, or via terrestrial, satellite or cable broadcast at a pre-paid or other pay-per-view basis. The data structure facilitates the acquisition and decoding of multimedia objects encoded in different data formats and communicated in different communication protocols from both local and remote sources.

In the following, the data referred to as being MPEG compatible comply with the MPEG 2 (moving picture experts group) image coding standard, termed "MPEG standard". This standard consists of a system coding part (ISO/IEC (International organization for standardization/International electrotechnical Commission) 13818-1, 10.6.1994) and a video coding part (ISO/IEC13818-2, 20.1.1995).

Data structure elements consistent with the principles of the invention may be transmitted in an MPEG compatible format (according to section 2.4.4 of the MPEG systems standard) or may be transmitted in a format compatible with the program and system information protocol for terrestrial broadcast and cable, hereinafter referred to as the PSIP standard, published by the Advanced Television Systems Committee (ATSC) on 11/10 1997, or other ATSC standards. In addition, the data structure elements may also be formed according to other MPEG standards, such as MPEG-4 or MPEG-7, or according to proprietary or custom requirements of a particular system.

The principles of the present invention are applicable to terrestrial, cable, satellite, internet or computer network broadcast systems in which the code pattern or modulation format may be changed, such systems may include: such as non-MPEG compatible systems, involve other types of encoded data streams and other methods of conveying program specific information. Further, although the disclosed system is described in terms of processing broadcast programs, this is merely exemplary. The term "program" is used to denote any form of packetized data, such as audio data, telephone messages, computer programs, internet data, or other communications.

Fig. 1 shows an overview of a Very Large Program Guide (VLPG) hierarchical file/table format of a transport stream layer data structure for transporting program specific information. The structure includes a plurality of hierarchically arranged and interconnected tables. The table consists of an array of data and parameters that enumerate and describe a set or sequence of TV channels, TV programs, channel parameters, program parameters, associated multimedia objects and object parameters, etc. The exemplary hierarchical table arrangement of FIG. 1 includes: master Guide Table (MGT)120, master database table (MDBT)122, Content and Classification Table (CCT)114, System Time Table (STT)116, and Rating Range Table (RRT) 118. The hierarchy of fig. 1 also shows terrestrial, cable and satellite channel information tables (TCIT entry 112, CCIT entry 110, and SCIT entry 108, respectively), where the channel information is collated by network providers such as CBS, NBC, HBO, Comcast, etc. The additional tables include schedule information tables (SIT 106, SIT 104 and SIT 102) for programs or services organized by the source.

The MGT contains information for acquiring program specific information transmitted in other tables. The channel information table, CIT (e.g., TCIT, CCIT, or SCIT), contains tuning and navigation information to receive the program channel selected by the user. The SIT contains an illustrative list of programs (events) that can be received on the channels listed by the CIT. The CIT, SIT, or other table may be used to convey information that enables a user to select and tune to a particular program. CIT is generally used to convey parameters for acquiring audiovisual program content data that remain unchanged over several events (TV programs). SIT is typically used to convey parameters of audiovisual program content data that remain unchanged for an event (individual TV program). Additional program specific information describing and supplementing entries in the hierarchical table is conveyed within the descriptor information element.

To accommodate data sufficient to satisfy a wide area program guide, the tables in the hierarchy of FIG. 1 are beneficially partitioned by both area (e.g., geographical, broadcast, or network market area) and scheduled broadcast times. Furthermore, the table data may be additionally partitioned according to a third parameter, such as complexity level of the data or multimedia object, for example, in order to make the decoding flexible. Such program guide sections are represented by three-dimensional cells shown in diagram 100. In fact, the VLPG structure of FIG. 1 supports almost any type of partitioning that a guide provider may require. Region and time based partitioning is achieved by including time and region identifiers in one or more of the tables of FIG. 1 and associated object data. The advantage of including the zone and time identifiers in the transport stage of the communication protocol in this way is: the processing burden (e.g., analyzing data) that would occur if the decoder were partitioned at a higher level, say, the application level, is alleviated. Thus, program guide filtering is performed at the transport layer and is performed directly by the transport chip contained in the decoder unit. However, time and region identifiers for both table data and objects can also be included at such higher levels, if desired.

In transmitting and processing program guides, bandwidth requirements increase as the amount of channel and program information and the number of related objects that need to be transmitted increases. For large program guides, even simple cases require the transmission of thousands of information and object entries. A simple program guide may have neither images nor audio or video segments, but still needs to carry at least textual descriptions of thousands of programs (events). Program guide information may be transmitted in a single box (bin) or data file without redundancy and without partitioning. In this case, and in the absence of transport level partitioning, the text description will end up in a single data file, for example. This means, for example, that a decoder in San Diego (San Diego) would receive all material (event text description, images, or any other object) from all other cities in the united states and would not be able to delete the useless material at the transport level. Therefore, in the absence of transport level partitions, it is necessary for the decoder to filter out the received program guide information at the application level. This is a particularly processor-intensive, time-consuming and burdensome task that requires complex software and significant processing power to accomplish, thus increasing the cost of the decoder unit.

The VLPG data structure of FIG. 1 facilitates providing the option of using region-based partitioning at the transport level. The program guide information may be partitioned by, for example, the eastern region, the middle region, the mountainous region, and the pacific region. Thus, a decoder located in san diego will no longer receive program guide information from the other 3 regions. Thus, such partitioning significantly reduces the analysis and filtering burden on the decoder, and smaller partitions (e.g., partitioning by state in a state) will further reduce the analysis and filtering burden. Another advantage of such partitioning is that the time taken to download available partitioned program guide information may be reduced.

Partitioning program guide information, however, involves introducing redundant program guide data because such partitioning requires duplication of data entries. As an example, if a basketball game is to be played in the pacific and mountainous areas, two copies of the relevant textual description information need to be sent, one for each partition targeting the pacific and mountainous areas. It can be seen that as the number of partitions increases, the amount of redundant information also increases, thus requiring a larger transmission bandwidth. Therefore, there is a tradeoff between bandwidth and information filtering burden. A large number of partitions means fast information filtering, but at the cost of increased bandwidth. When there is only one partition, there is no redundancy and thus minimal bandwidth, but the filtering burden is greater because all program guide information entries need to be analyzed.

By using the MPFG 2 PSI and DSM-CC fields, time and area elements can be mapped to MPEG-2 compliant data structures. Not all tables need to incorporate region-based identifiers. For example, program content ratings may be generally applicable anywhere in the united states. In the VLPG structure of FIG. 1, significant advantages are obtained by adding region-based partitions to a Channel Information Table (CIT) and a Main guide Table (PMT). The CIT determines the channel queue (list of available channels) of the service provider, which CIT depends on the geographical area covered by the service provider. For example, the channel lineup for terrestrial broadcasts in Indianapolis (Indianapolis) is different from the channel lineup for cable TV providers in philadelphia (philadelphia). In the system of fig. 1, MGT is also dependent on geographical area, but is not required.

The ability to focus program guide information to a particular viewer is an advantage that can be gained by area-based subdivision of the channel lineup at the broadcast market level. For this purpose, different tables "instances" are created. A table instance is a version of a surface that faces a particular market area and has inserted an area identifier that identifies the available market area. Multiple instances of a single table may be transmitted simultaneously, but each instance carries different information. The different table instances are identified using the "table _ id _ extension" field of the MPEG-2 protocol.

Fig. 2 and 3 show a Main Guide Table (MGT) format and a Channel Information Table (CIT) format, respectively, for transferring program specific information and inserting a table _ id _ extension field for market area identification. In the MGT of fig. 2 and in the CIT of fig. 3, this market area identification field is called "network _ provider" as shown in entry 130 in the MGT data structure and in entry 140 in the CIT data structure. The network _ provider area identifier field is a 16-bit field used to uniquely identify a network provider. The meaning of the network provider depends on the transmission medium. Specifically, for terrestrial broadcast, the network provider is a collection of stations within a geographic area; for cable broadcasts, the network provider is a local cable service provider; for satellite broadcasting, the network provider is a satellite service provider.

The data structure of fig. 1 advantageously enables different types of program specific and program guide information to be targeted to different regions. This feature enables flexibility in selecting an acceptable trade-off between decoder complexity and processing bandwidth related to broadcasting and receiving program guide data. As an example, it may be acceptable to divide the multimedia object into areas larger than the channel queue information. The data structure of fig. 1 provides a program provider with the ability to partition different types of data at different levels of a region ranging from a large region to a small region (e.g., as large as a country, state, or county to as small as a city, town, block, or even individual user).

In addition, the program guide information may be collated in the decoder to provide the user with a selection of program guides for different regions (e.g., between two adjacent regions or selecting a guide from any one of the available regions) or for different broadcast periods. In this way, the decoder may select a program guide from one or more available program guides associated with different regions in response to user selections entered via a remote control unit or other data entry device. In performing this selection, the decoder compares the range identifier (associated with the received program guide information) with a pre-stored range identifier representing the decoder's location. Such range identification flags may include: zip code, area code, and any other range identification code.

Fig. 4 shows a multimedia object data structure format for transferring objects within a VLPG. The multimedia object data structure supports region and time based partitioning by using the region and time identifier fields within the MPEG DSM-CC compatible carouseld (entry 150 in fig. 4).

Fig. 5, 6 and 7 show examples of data structures of objects including channels, times and control objects, respectively. Specifically, fig. 5 shows a channel basic information file (channel BIF) binary file, fig. 6 shows an event basic information file (event BIF) binary file, and fig. 7 shows a control basic information file (control BIF) binary file. As with fig. 4, the channel, event and control object data of fig. 5-7 includes area and time identifier fields within the MPEG DSM-CC compatible carouseld (entries 153, 157 and 159 in fig. 5-7, respectively).

Entry 152 of fig. 8 shows an exemplary carofelib data structure for an MPEG compatible carouseld (as used in the tables of fig. 4, 5, 6 and 7). The carouseld includes, as a database reference, a 16-bit directory entry identifier, an 8-bit time identifier, and an 8-bit area identifier. These fields enable the decoder to selectively filter out program guide data based on region and time based partitioning.

In the VLPG data structure of FIG. 1, the master database table (MDBT entry 122) is used to determine program guide partitions (cells) and to inform the decoders of the cells appropriate for its location to decode. FIG. 9 illustrates a master database table data structure having inserted a hierarchy-based version identifier and a unit partition identifier that facilitates dynamic program guide re-partitioning. The code between entries 170 and 178 includes a loop that determines the partitioned unit. Within this loop, a field called "cell-type" (entry 172) determines the index of the cell, as shown in FIG. 10.

Entry 179 of FIG. 10 shows an exemplary data structure for the cell type indicator. The unit type indicator includes an 8-bit complexity level identifier to define the complexity level of the object. The unit type indicator further includes an 8-bit region identifier and an 8-bit time identifier for defining a region and time based partition.

Each object or program guide information entry includes a carouseld (as defined in fig. 8 and shown in entry 150 of fig. 4) that links the object to the time and area index of its parent cell. By rearranging the unit entries in the MDBT and dynamically changing the parent unit time and area index identifier within the carouseld, a dynamic program guide can be re-partitioned. Thus, the guide provider can dynamically repartition the program guide data structure to accommodate changes in available transmission bandwidth or decoder complexity. If wider bandwidth is available, the guideline provider may use finer partitions to provide faster object filtering times; if the decoder processing power improves, the guide provider can use larger partitions to protect bandwidth. Thus, for example, a decoder located in san Diego may access program guide information associated with regions 0 and 7 today, while program guide information associated with regions 0 and 9 reflecting smaller partitions may be accessed in the future. In the future, real-time access to multimedia objects present in guides covering areas as large as the united states is fully possible by choosing a suitable compromise between bandwidth and partitioning.

Fig. 11 shows a hierarchical directory format of an object database including object files under channel, event and control subdirectories. FIG. 11 shows that a particular event, such as "event 2," may have its own directory containing its required files, e.g., "event 2" has 4 related objects (entries 240, 242, 244, and 246 in FIG. 11). Using the object database, directory-based addresses are mapped into transport level fields for processing. For example, assuming there is a path such as/VLPG/TIME 1/AREA1/events/event2/event. bif (the path through directory entries 220, 224, 228, 232, 238 and 242 of FIG. 11), there is one and only one object with a certain carouselD and modeleID. For example, in this case, the following mapping applies:

VLPG-file extracted from VLPG object database

/TIME1- - - - - - - - - - - - - > 0X 01 (TIME variable)

/AREA1- - - - - - - - - - - > 0X 01 (variable AREA)

/events/event2- - > 0X 3005 (Cat. No. variable)

Thus, the database address is mapped to a carouseld of 0 × 01013005. Furthermore, the event bif (entry 242) has a moduled id that can be determined from the program guide information (e.g., its value is 0 × 0002 in this example). The reverse mapping from the transfer level field to the directory-based address is also unique and can be similarly derived.

The directory structure illustrated in FIG. 11 supports the operation of software for processing and interacting with transport objects. The process software may be transmitted with the object in the form of a file, and then interpreted, compiled, and run by a decoder. Such processing software may be used in a wide variety of applications, including for facilitating the creation of content-based program guides in decoders using one of the following languages, such as HTML (hypertext markup language), SGML (standard generalized markup language), Java, ActiveX, and any other decoder-supported language. As an example, each weekday guide provider may need to make a web site that specifies all available weekday movies for transmission to a decoder unit containing a web browser and supporting HTML software. The sunday guide information is encoded in HTML and transmitted to the decoder as an HTML software file that describes the specific web site. The HTML software files are located anywhere in the directory structure of the object database and simultaneously generate image, text, video and audio files to form a sunday movie guide listing including a dedicated web site. In this way, the sunday guide web site is broadcast as part of the object database, rather than being traditionally accessed from an internet server. Other specialized program guide web sites that may be delivered in this manner may be listed: for example, (a) DVD/VCR (digital versatile disk/video cassette recorder) programs available for playback, (b) other internet web sites, (c) pre-stored fax/telephone numbers for access, (d) videophone functions, and (e) home appliance control functions.

A user selecting an associated displayed menu entry or display icon using a remote unit or other data entry device may initiate the display of a dedicated sunday guide web site contained in the object database, and the user may similarly navigate the web site and view the advertised movie. In addition, the user may be able to initiate commands via the web site, such as: (a) programming a VCR or DVD unit, (b) tuning the desired channel, or (c) accessing other internet sites that are similarly broadcast as part of the object database or are conventionally accessed via telephone (or cable). In addition, upon initiation of such telephone (or cable) line internet access, the decoder may obtain access information from a broadcast or other source. Such access information includes, for example, (a) an internet URL (uniform resource locator address), (b) an internet IP (internet protocol) address, (c) an email address, (d) a telephone/fax/videophone number.

The hierarchical directory structure of fig. 11 illustrates another advantage provided by the VLPG structure of fig. 1. In large program guides, managing updates of sub-tables and objects involves checking a large number of version numbers (which may involve thousands of version numbers). Upon determining a version number change, the decoder downloads a particular program guide table or object and ignores those tables and objects that show no version number change. Completion of this task can be aided by listing the tables and all version numbers of objects that are susceptible to change in one table, such as the MGT. The MGT is broadcast at a sufficiently high rate that a decoder can examine the MGT to determine which of these tables or objects has changed and obtain the changed tables and objects in time. However, in large program guide structures, analyzing each MGT input can become very time consuming.

The problem is solved by a system using hierarchical versioning, where there are several tables performing versioning. These tables are arranged in the exemplary tree structure of fig. 11. In FIG. 11, table 238(event2) controls the versions of those tables/files under table 238. Table 232(events) controls all versions of tables 336(event1), 238. Table 228(AREA1) controls only the versions of tables 230(channels), 232, and 236 (control). In this way, the version number information stored in each table is small and those files, tables or objects that need to be updated can be quickly found through the top-to-bottom tree structure.

Although a multi-level structure has been described above, a two-layer version control structure may also be used for version control of objects in the database in the VLPG of FIG. 1. In the two-tiered example, the upper level of the tree hierarchy is the master database table (MDBT) as exemplified in FIG. 9. The second level, below the MDBT level, consists of a number of elements including channel, event and control elementary information files as exemplified by the aforementioned data structures of fig. 5, 6 and 7, respectively. Any changes to the channel, event or control file are represented by changes to their respective version numbers, i.e., entry 160 (FIG. 5), entry 163 (FIG. 6) and entry 167 (FIG. 7). Furthermore, any change in the channel, event or control file version number is represented by a change in the next hierarchical (unit) level version number, i.e., such a change is represented by a change in version number 176 in the MDBT of fig. 9. As a specific example, if a channel identifier (logo), an image in the database, changes from one version to another, the channel BIF will reflect this change in entry 160 (fig. 5). The MDBT will also reflect this change in the entry 176 (fig. 9) at the unit level. The decoder first checks the MDBT and determines that the unit version number has changed and then checks the BIF file to identify the objects that have changed within the unit.

The main database table (MDBT) structure of fig. 9 provides another advantage of handling large program guides. Decoder complexity and processing power, as well as the ability to process complex multimedia objects, continue to evolve over time. For example, the first generation set-top-box decoders were primarily limited to processing pictures in a bit-mapped manner. Whereas newer generation decoders may use decompression software to download JPEG (joint photographic experts group), GIF (graphics interchange format), or other image formats, future decoders will be able to process not only images but also movie fragments in multiple formats. It is therefore desirable to construct program guide data that supports decoder scalability, that is, to allow a group of decoders of varying complexity to process program guide information with the level of processing power assigned to them. Thus, low complexity decoders are able to identify objects that they are able to process and delete objects that exceed their processing power. In addition, high complexity objects may corrupt the operation of the low complexity decoder by causing buffer overflows or other problems.

The MDBT data structure of fig. 9 (and fig. 10) is advantageous for supporting efficient multimedia object complexity discrimination in the decoder unit. To this end, the MDBT assigns PID (packet identifier) values to cells in the database. In fig. 9, entry 172 identifies a particular unit and is associated with a PID value of entry 174. In addition, the entry 172 defines a 24-bit field cell _ type, which defines the time, area and complexity coordinates of one cell (see fig. 10). Thus, an object complexity level indicator is included in the MPEG-2 compatible transport layer field. Thus, objects in the database belonging to different levels of complexity are transported in streams identified by different PIDs. A complexity level is pre-specified for the decoder, which then applies the MDBT (specifically entry 172) to select and cache PID values for those units having a complexity level equal to or lower than the pre-specified decoder complexity level. Objects with complexity levels exceeding the decoder capability are advantageously removed at the transport layer.

Fig. 12 shows a flow chart of a method of generating program specific information according to the invention. The method of fig. 12 generates program specific information, including: MGT, MDBT, CCT, STT, RRT, TCIT, CCIT, SCIT, and SIT data, as well as descriptors containing the aforementioned beneficial features. The method may be applied at an encoder for broadcasting program guide data, or may be applied at an encoder for encoding program guide data in a decoder for transmission to another device.

Flow begins at step 250 of FIG. 12 and at step 253, a method based on the foregoing data construction principles is selected to partition program specific information. The program specific information is partitioned according to time period and area, network type, complexity level, unit, and program (event). At step 255, PID values are specified for use with the partitioned program specific information. If a non-MPEG transport protocol is used, the PID values can be replaced by appropriate parameters that identify the logical channels. At step 257, the MGT and MDBT (or other type of control table) are generated to contain those elements formed during the partition operation. The MGT transmits information for acquiring program specific information transmitted in other tables. The MDBT transmits information for acquiring a multimedia object from one transport stream.

At step 260, private tables of CCT, STT, RRT, TCIT, CCIT, SCIT, SIT, etc. are formed that conform to the partition structure. These special tables incorporate the links, version numbers and identifiers of the multimedia objects obtained according to the aforementioned inventive principles. A CIT (e.g., TCIT, CCIT, and SCIT) is formed that contains channel and program identification information that enables the availability of available broadcast programs and channels that contain packet identifiers for identifying the packetized datastreams that make up each program to be transmitted on a particular channel. In addition, at step 260, a SIT is also generated that contains program guide scheduling information including an illustrative list of programs (events) that may be received on the channels listed in the CIT.

In step 263, the table formed in step 260, together with the associated multimedia object, is formatted to fit the desired data format and protocol. Such data formats and protocols include, for example, MPEG 2 compatible program specific information, MPEG 2 DSM-CC, DSS, and Internet compatible file transfer formats. At step 265, the final formatted tables and multimedia objects are merged into the data stream at their designated locations for terrestrial delivery. The MGT and MDBT are merged into the data stream at step 267.

In step 270, the program specific information generated in step 267 is multiplexed and formatted into a transport stream output along with video and audio program representative components (and other data) for multiple channels. At step 270, the output transport stream is further processed for suitable terrestrial transmission to another device, such as a receiver, video server, or storage device for recording on a storage medium. The processing performed at step 270 includes known encoding functions such as data compression Reed-Solomon encoding, interleaving, scrambling, trellis encoding and carrier modulation. Processing is complete and terminates at step 275. In the process of fig. 12, a plurality of CIT, SIT and associated extension tables may be formed and incorporated into the program specific information to accommodate the extended number of channels. Further, in other embodiments, these tables may be similarly processed for, for example, satellite, cable, or internet transmission.

In the video receiver system shown in fig. 13, a broadcast carrier modulated with signals carrying audio, video and related data representing broadcast program content is received by antenna 10 and processed by unit 13. The final digital output signal is demodulated by a demodulator 15. The demodulated output from unit 15 is trellis decoded by decoder 17, mapped into byte length data segments, deinterleaved and Reed-Solomon error corrected. The corrected output data from unit 17 is in the form of an MPEG compatible transport data stream containing the program typical multiplexed audio, video and data components. The transport stream from unit 17 is demultiplexed by unit 22 into audio, video and data components, which are further processed by other components of decoder system 100. In one mode, decoder 100 provides MPEG decoded data for display and audio reproduction on units 50 and 55, respectively. In another mode, decoder 100 processes the transport stream from unit 17 to provide an MPEG compatible data stream that is stored on storage medium 105 via storage device 90.

The user selects to view a TV channel (user selected channel-SC) or to view an on-screen menu, such as a program guide, using the remote control unit 70. Controller 60 uses the selection message provided from control unit 70 via interface 65 to appropriately configure the components of fig. 13 to receive the desired program channel for viewing. The controller 60 includes a processor 62 and a processor 64. Unit 62 processes (i.e., analyzes, collates, combines) system timing information and program specific information including program guide information. The processor 64 performs the remaining control functions required to operate the decoder 100. Although the functionality of unit 60 may be implemented as discrete components 62 and 64 as shown in fig. 13, the functionality of these two components may alternatively be implemented in a single processor. For example, the functionality of units 62 and 64 may be incorporated within the programming instructions of a microprocessor.

The controller 60 configures the processor 13, demodulator 15, decoder 17 and decoder system 100 to demodulate and decode the input signal format and encoding type. The controller 60 is furthermore provided with units 13, 15 and 17 for other communication modes, such as for receiving cable television (CATV) signals and for bidirectional communication via the coaxial line 14 or for bidirectional (e.g. internet) communication via, for example, a telephone line 18. In analog video mode, NTSC (national television standards committee) compatible signals are received by units 13, 15 and 17 and processed by decoder 100 for video display and audio reproduction on units 50 and 55, respectively. The controller 60 uses the bi-directional data and control bus C to set control register values in the units 13, 15, 17 and sub-units of the decoder 100 for the input signal type to configure these components one by one.

The transport stream provided to the decoder 100 includes: data packets containing program channel data and auxiliary system timing information; and program specific information including program guide information. The unit 22 directs the ancillary information packets to the controller 60 where this information is analyzed, collated and combined into the aforementioned hierarchically arranged table (as exemplified in fig. 1). Each data packet containing a user selected program channel SC is identified and combined by using the combined program specific information. In addition, the program specific information contains conditional access, network information and identification and linking data to enable the system of fig. 13 to tune to the desired channel and combine the data packets to form a complete program. The program specific information also contains a combination of data supporting identification and auxiliary information.

The program specific information and system timing information are combined by the controller 60 into a multi-tiered and interconnected table in accordance with the architecture of fig. 1. The STT contains a time reference indicator and associated correction data sufficient for the decoder to establish a transmission time for the broadcast source to transmit the program. The MGT contains information to obtain program specific information transmitted by other tables, such as identifiers to identify data packets associated with other tables. The CIT (e.g., TCIT) contains information for tuning and navigation to receive the program channel selected by the user. The SIT contains an illustrative list of programs (events) that may be received on the channels listed in the CIT. The RRT contains program content rating information such as MPAA (american movie association) or V-chip compatible rating information organized by range (e.g., by state throughout the united states or within the united states). Additional program specific information describing and supplementing entries in the hierarchical table is transmitted within the descriptor information element. The program specific information and system timing information obtained by controller 60 via unit 22 is stored in the internal memory of unit 60. The controller 60 uses the obtained program guide information to conditionally access and schedule program processing functions including program viewing, recording, and playing.

Controller 60 and processor 22 recognize the PIDs of the video, audio and sub-picture (sub-picture) streams in the packet decoded transport stream input to decoder 100 from unit 17. The video, audio and sub-picture streams constitute the desired program transmitted on the selected channel SC. Processor 22 provides MPEG compatible video, audio and sub-picture streams to video decoder 25, audio decoder 35 and sub-picture processor 30, respectively. The video and audio streams contain compressed video and audio data representing the SC program content of the selected channel. The sub-picture data contains SIT, CCT and RRT information associated with the SC program content of the selected channel.

Decoder 25 decodes and decompresses the MPEG compatible packetized video data from unit 22 and supplies the decompressed program representative pixel data to NTSC decoder 45 via multiplexer 40. Similarly, the audio processor 35 decodes the packetized audio data from the unit 22 and supplies the decoded and amplified audio data to the audio reproduction device 55 in synchronization with the associated decompressed video data. Processor 30 decodes and decompresses the sub-image data received from unit 22.

Processor 30 combines, collates and translates the RRT, CCT, CIT and data objects from unit 22 to produce formatted program guide data for output to OSD 37. The OSD37 processes the SIT, RRT, and CCT and other information to generate pixel map data representing subtitle, control, and information menu displays including selectable menu options and other items that appear on the display device 50. The displayed control and information menus enable a user to select programs to view and schedule future program processing functions, including: a) to receive the selected program for viewing, b) record the program onto storage medium 105, and c) play the program from medium 105.

The control and information displays containing text and graphics produced by OSD generator 37 are generated in the form of overlay pixel map data under the manipulation of controller 60. The overlay pixel map data from unit 37 is combined with the decompressed program representative pixel data from MPEG decoder 25 and synchronized in encoder 45 via multiplexer 40 under the control of controller 60. The composite pixel map data representing the video program on channel SC is encoded by NTSC encoder 45 along with the associated sub-picture data for output to display device 50 for display.

In the storage mode of the system of fig. 13, the corrected output data from unit 17 is processed by decoder 100 to provide an MPEG compatible data stream for storage. In this mode, the user selects a program for storage via the remote control unit 70 and the interface 65. Processor 22, together with processor 60, forms compressed program specific information including MGT, MDBT, CCT, STT, RRT, TCIT and SIT data and descriptors including the aforementioned beneficial features. The compressed program specific information supports decoding of the stored selected program, except for extraneous information. Processor 60 and processor 22 together form a composite MPEG compatible data stream containing packetized content data for a selected program and associated compressed program specific information. The resultant data stream is output to the storage interface 95.

The storage interface 95 buffers the resultant data stream to reduce gaps and bit rate variations in the data. The resulting buffered data is processed by the storage device 90 to be suitable for storage on the medium 105. The storage device 90 encodes the buffered data stream from the interface 95 using known error encoding (error encoding) techniques such as channel coding, interleaving and reed solomon encoding to produce an encoded data stream suitable for storage. Unit 90 stores the last encoded data stream with the compressed program specific information inserted on medium 105.

The structure of fig. 13 is not exclusive. Other arrangements for accomplishing the same objectives may also be achieved in accordance with the principles of the present invention. Furthermore, the component functions of the decoder 100 of FIG. 13 and the processing steps of FIG. 12 may be implemented in whole or in part in microprocessor programming instructions. Furthermore, the principles of the present invention are applicable to any form of MPEG or non-MPEG compatible electronic program guide. The data stream formed in accordance with the principles of the present invention may be used for a variety of applications including, for example, video servers or PC (personal computer) type communications over telephone lines. A program data stream containing one or more components of video, audio and data, formed by inserting program specific information in accordance with the principles of the present invention, may be recorded on a storage medium and transmitted or rebroadcast to other servers, PCs, or receivers. The key elements of the data structures described herein can be advantageously used to convey program auxiliary information in a wide variety of data transmission structures used to convey program content or program guide information. Such transport structures may include, for example, MPEG-PSI, Internet TCP/IP (Transmission control protocol/Internet protocol), DSS (digital satellite System), ATM (asynchronous transfer mode), and the like.

Claims (15)

1. An apparatus for decoding packetized program data from at least a first source to provide a program guide, comprising:

a first processor (22, 60) for obtaining program guide information and auxiliary information in said packetized program data, said auxiliary information including,

(a) a directory of executable software application files associated with the object, and

(b) a mapping for associating the object with the program guide information entry;

a second processor (60, 30, 37) for executing the executable software application file to link a desired object to a program guide information item in order to create a program guide having a desired information content; and

a display processor for forming a composite image including the linked objects and program guide information items for display.

2. The device of claim 1, wherein the directory of executable software application files lists files associated with at least one of: (a) broadcast programs, (b) broadcast channels, (c) user interface controls and peripherals connected to the apparatus.

3. The apparatus of claim 1, wherein each of the objects comprises at least one of: (a) a video segment, (b) an audio segment, (c) text, (d) an icon representing a user selectable item to be displayed, (e) an HTML or SGML file, (f) a menu of selectable items, (g) an image window to be presented within a contained image, and (h) an image window to enable a multimedia function.

4. The apparatus of claim 1, wherein the side information further comprises acquisition information for use in acquiring the side information from a second source different from the first source, and the acquisition information comprises one of: (a) internet URL, (b) internet IP address, (c) e-mail address, and (d) telephone/fax/videophone number.

5. The apparatus of claim 1, wherein said display processor displays said program guide in response to a user selection input command selecting between available program guides.

6. The apparatus of claim 1, wherein the assistance information further comprises an object complexity level indicator, and the apparatus ignores objects having a complexity that exceeds a predetermined level.

7. The device of claim 1, wherein each of the executable software application files comprises at least one of: (a) HTML or SGML document, (b) Java^TMFile, (c) Activex^TMFiles and (d) software language files supported by the decoder.

8. The apparatus of claim 1, wherein said second processor further creates a special program guide for display, said special program guide comprising program listings organized according to at least one of: (a) a particular time period during which the program is broadcast and (b) a particular category of the program.

9. The apparatus of claim 8, wherein the particular category of programs includes programs comprising at least one of: (a) a particular topic or theme, (b) a particular actor or director, and (c) user-defined particular criteria.

10. The apparatus of claim 1, wherein the second processor establishes a special program guide based on one or more of: (a) program guide information obtained from a broadcast source and (b) program guide information obtained over the internet.

11. The apparatus of claim 1, wherein the second processor establishes a special program guide for multimedia services comprising one or more of: (a) DVD/VCR programs available for playback, (b) internet web sites, (c) pre-stored fax/phone numbers for access, (d) videophone service access entries, and (e) home appliance control functions.

12. The apparatus of claim 11, wherein the second processor, when establishing the special program guide procedure, obtains program guide information by establishing bidirectional communication with a second source using acquisition information comprising one of: (a) internet URL, (b) internet IP address, (c) e-mail address, and (d) telephone/fax/video telephone number.

13. The apparatus of claim 1, wherein the program guide established by the second processor is a user-selected program guide selected from a number of program guides for display.

14. The device of claim 1, wherein one of the following functions is further implemented by the executable application software file: (a) instructing the VCR/DVD device to record a program at a predetermined broadcast time, (b) instructing the apparatus to tune to a particular broadcast video channel, (c) instructing the apparatus to tune to a particular broadcast audio channel.

15. A method of decoding packetized program data from at least a first source to provide a program guide, comprising the step of acquiring program guide information and auxiliary information in said packetized program data, wherein said auxiliary information comprises:

(a) a directory of executable software application files associated with the object, and

(b) a mapping for associating the object with the program guide information entry;

and the method further comprises the steps of:

executing the executable software application file to process the program guide information items to form a program guide for display; and adjusting the formed program guide information for display.