MXPA00004942A - Device interoperability utilizing bit-mapped on-screen display menus - Google Patents

Abstract

Interoperability for exchanging on-screen display menus and associated control between common consumer electronic (CE) devices is provided. This interoperability is based on the IEEE 1394 serial bus for the physical and link layers and makes use of AV/C or CAL as the control language. This invention provides for transferring a bitmapped on-screen display menu constructed by a target device (e.g., digital VCR) to display device (e.g., digital TV).

Description

DEVICE INTEROPERABILITY USING DEPLOYE UE USES ON SCREEN WITH BIT MAPS Field of invention The invention relates to a system for controlling multiple electronic devices, such as consumer electronic devices or the like, via interconnections such as digital data buses. More particularly, this invention relates to a configuration for managing the interoperability of the on-screen display menus of said devices. Background of the invention A data bus can be used to interconnect digital electronic devices such as television receivers, display devices, video tape recorders (VCR), direct transmission satellite receivers (D BS), and broadcast devices. home control (such as a security system or a temperature control device). Communication using a data bus is in accordance with a bus protocol. Examples of the bus protocols include the Consumer Electronics Bus (C EBus) and the I Serial Bus I EEE 394 High Performance. Commonly, a bus protocol provides information for data and information. For example, the control information of the Consumer Electronics Bus is communicated in a "control channel" that has a protocol defined in the specification of the Electronic Industries Association (EIA) IS-60. In a serial bus 1394 of I EEE, the control information is generally passed using the asynchronous bus services in series. The control information for a particular application can be defined using, for example, the Common Application Language (CAL) or AV / C. In the current analog audio / video (A / V) group, the control of peripheral devices may include, but does not require, the activation of an on-screen display (OSD) mechanism in a deployment device (i.e., television). ). The on-screen display of such audio / video devices is generated in the target or peripheral device (eg, a video tape recorder) and occurs as output in the NTSC output of said devices in the same manner as any other device. video signal. Therefore, no additional computer or computer programs are required in the peripheral or deployment device. Figure 1 illustrates a current audio / video system 10 having a video cassette recorder 12 and a display device 15 (eg, a television) employing this control methodology. The menus associated with the control of the video tape recorder 12 are generated by the video tape recorder 12 and are provided to the display device 14 via the NTSC output of the video tape recorder 12 as a video signal. compound Brief Description of the Invention Unfortunately, using the same approach (See Figure 2) with a digital television (DTV) as a display device 12 is impractical because it would require menus to be transported as transport streams M PEG-2. The generation of these currents needs to integrate an M P EG 1 5 encoder in all peripheral devices which significantly increases the cost and the complexity of said consumer electronic devices. The present invention provides the exchange of on-screen display menus and the associated control between interconnected consumer electronic devices via a digital serial bus. The serial bus is used for the lace and physical layers; a control language to manage on-screen deployments and control the connectivity of interconnected devices via the bus. Particularly, this invention provides the transfer of on-screen displays with bitmaps that are created and controlled by the target device to a display device and combine on-screen displays with bitmaps with a digital video stream received by the user. deployment device. In the preferred mode, the transfer of the display menu with bitmap is handled by activation messages sent from the target device to the deployment device. The present invention allows the selection of a target device or source (e.g., a digital video tape recorder) for the display device (e.g., a digital television) thus allowing the target device to display the content and a display on screen in the deployment device. Additionally, the user can select a source for the target device; this allows the chaining of devices so that for example, a program that is being decoded by an STB in Cable can be seen in a digital television and recorded in a DVHS recorder simultaneously. Another aspect of the present invention includes remote browsing; which is that the device that is being controlled carries a tracking of the user's navigation through the menu. For example, a video tape recorder (ie, target) makes its own changes to the screen display to move the highlight without participation of the display device (ie, television). This is achieved by using display update update blocks as described below. BRIEF DESCRIPTION OF THE DRAWINGS The invention can be better understood by referring to the accompanying drawings in which Figure 1 shows, in the form of a simplified block diagram, the interoperability of a prior art audio / video system; Figure 2 shows, in the form of a simplified block diagram, the interoperability of a digital video tape recorder and a digital television; Figure 3 shows, in the form of a simplified block diagram, the interoperability of digital devices employing the present invention; Figure 4 shows, in simplified block diagram form, a display device having a screen display menu constructed using the present invention; FIG. 5 shows a simplified block diagram, the construction of the deployment device of the on-screen display menu of FIG. 4; Figure 6 shows, in the form of a simplified block diagram, the modification of the on-screen menu of Figure 4; and Figure 7 shows, in the form of a simplified block diagram, the pixel map for different display menu settings in the context of the present invention. In the drawings, the reference numbers which are identical in different Figures indicate that the characteristics are the same or similar. Detailed Description of the Drawings The use of the Bus in Series I E EE 1 394 has been suggested for many applications with a Home Network environment. It is being discussed in the Video Electronics Standards Association (VESA) for use as a "complete home network". It is being inserted into the next generation of personal computers and will be used by many local peripherals including disk drives.

Additionally, digital audio / video consumer electronics devices such as digital televisions (DTVs) and digital video tape recorders (DVHS) can use a serial bus to interconnect these devices. The I EEE- 1 394 is a high-speed, low-cost digital serial bus developed for use as a peripheral or backplane bus. Some of the bus features include: dynamic node address assignments, data rates of 100, 200 and 400 Mbits / sec. , asynchronous and synchronous modes, fair bus arbitration, and consistency with ISO / I EC 13213. The pending requests with the present Agent File Numbers 88,761 and 88,823 discuss the use of the IEEE-1394 serial bus for interoperability of audiovisual devices. The transfer of Display Deployment Menus from a target (i.e., a device to be controlled) to a display device (e.g., a digital television) can be achieved using one of several formats. For example, a substring of HTML without the navigation features can be used to describe the screen display. Another possibility is to transfer an encoded version of a long run from the menu using something similar to the digital video disc sub-image format. However, the preferred embodiment includes transferring the actual information in a bitmap format of screen display. For example, an 8-bit / pixel full-screen display of 640X480 can be transferred in approximately 100 msec using 10% of the IEEE-1394 serial bus bandwidth of 200 Mbit / sec. A bitmap format for the description of the on-screen display allows (1) the manufacturer to maintain the "appearance and feeling" of screen display, (2) freedom in the generation of screen display and (3) dynamic updates ( that is, partial screen updates or even a single pixel are possible). Compared to compressed representations, the bitmap representation requires less processing time for deployment because deploying such display menus on bitmap screen requires minimal interpretation and manipulation. Descriptive approaches, such as HTML, have the disadvantage of being difficult to specify and update for typical consumer products. To simplify the transfer of bitmap display deployment information, a "Step" method is preferably used. With this method, the bulk of the screen display data is transferred from the target or peripheral device to a deployment device via asynchronous read requests issued by the deployment device. That is, the display device reads the on-screen display information from the memory of the peripheral device by making use of at least one IEEE 1394 block read transaction. The display device is informed of the location and size of the devices. screen display data via a "trigger" command that is sent from the peripheral device to the deployment device when the peripheral device is ready to begin transferring data. Other alternatives for transferring an on-screen display menu from a peripheral device to a display device include; (1) an asynchronous step method that mainly uses IEEE 1394 asynchronous script transactions initiated by the peripheral device to write the on-screen display data to the display device; (2) an isochronous transport method for transporting the display data on one of the isochronous channels provided by the IEEE 1394, (3) an asynchronous stream method for carrying the display information on the screen and (4) alternatively, the bitmap screen display could be provided via a remixed channel of 8 VSB-T (grid) or 16 VSB RF. Figure 3 defines a system 10 for providing interoperability between digital audio / video devices interconnected via a serial bus I EEE 1394. In a system 10 of this type, interoperability can be achieved by transferring the on-screen display menu directly from the target or peripheral device 12 (e.g., the digital video tape recorder) to the display device 14 (e.g., digital television) using the " He passed". The menu is not transferred as a composite video stream that would first require passing the menu information through an MPEG encoder contained in the peripheral device. The menu is transferred as an on-screen display in bitmap via the serial bus 16 to the digital television 14 where the menu information can be overlapped on the digital television 14 with the decoded MPEG stream before being displayed. Many of the devices can use a log table that is constructed during a discovery process that looks for the information stored in each Self-Descriptive Device Table (SDDT). The Self-Descriptive Device Table may contain information such as a unique identification, node address, etc. The log tables would be used by digital television to build a menu to allow the user to establish connections between components (similar to the user selecting the composite input for the source of his television currently). The target device first reviews the deployment format and the larger block fields available in the Self-Descriptive Device Table to see what size and resolution of screen display can be handled. Then it builds the display data on the screen (header and bitmap) and stores them in its display memory area. As shown in Figure 4, a screen display menu 18 constructed in a display 14 consists of a Display Deployment Region 20 and Display Deployment Update Blocks 24 (OSDU B 1 to OSDU B2). The data that defines a Deployment Region on the screen consists of a Display Deployment Update Block Header and a bitmap. The update blocks used to build the Display Deployment Menu are acquired from the target device (for example, the video tape recorder) by the display device for use in the construction of the screen display. Display Deployment Update Blocks are transferred from the target device to the deployment device on the serial bus. Once the display information is ready for transfer, the target device sends an activation message to the deployment device (see Figure 5). These same activation messages are used for the Deployment Header on the main screen and for the Display Deployment Update blocks 24. A single activation message is needed for each Display Deployment Update Block 24. The start of a transfer of Display Deployment Update Block can only occur through the use of an objective activation message to the target device. A queue can be implemented in the deployment device so that the activation messages are processed in the same order in which they are received. The activation messages 22 will be processed in the order in which they were sent, therefore it is important that the target knows that the Display Deployment Update Block belongs in the lower part and which belongs in the upper part. For example, an activation message for the Display Deployment Block 0 (Palette and Display Header on the Main screen) is sent first, followed by the activation message for the Deployment Block on screen 1, etc. Effectively, the first activation block ends at the bottom and the last update block at the top. (That is, a Display Menu on the screen it can be built in steps where each subsequent step can overwrite a portion of the previous step). This allows the on-screen display blocks to be built at the time thus keeping the memory requirements low. The bitmap immediately follows the header for each display block. The pixels of the screen display that are stored in the memory are a 4: 4: 4 representation of established chrominance / luminance levels of the palettes. Each palette entry contains a bit of transparency (T), one mix bit (B), 6 bits of Y, 4 bits of Cb, and 4 bits of Cr. The transparency bit and the mix bit for each input allow the target to selectively display either a display pixel in screen, a video pixel or a pixel mixed on a pixel by pixel basis. After a target activation message is received, the on-screen display module in the deployment device requests memory accesses (ie, uncomfortable readings) beginning at the memory location specified in the activation message. If the screen display is completely new, the first activation message should refer to the Palette and Deployment Header in the Main screen. Once the deployment device has this information, then it requests information specified in the second activation message (ie, the Deployment Block on screen 1). The deployment device reads all the information associated with the Deployment Block on screen 1 and begins to construct the actual image of the bitmap. At the same time, it informs the target that the block has been read so that the target can release any memory that has been allocated for the transfer of this block of data. Then this image is displayed. If additional activation messages have been received, then those Display Deployment Update Blocks are processed in the same manner. The display deployment controller of the display device (not shown) uses this data to build the screen display and mix it with the MPEG video decoded on the digital television 14. The Display Deployment Update Blocks remain on the screen until which are overwritten, deleted, or the user selects a different device. Before a color component is deployed, it is "justified to the left" by the Display Deployment Controller (that is, the least significant bits are padded with zeros) to produce 8 bits of each of Y, Cb, and Cr. The 4: 4: 4 representations will be Multiplexed in MPEG 4: 2: 2 video output by the internal deployment controller to the deployment device. After receiving the pixel data for block 1, the on-screen display module reads the header for block 2, obtains the necessary information and then reads the pixel data associated with block 2. The on-screen display module repeats this process (read the header, request data using the address, obtain pixel data, etc.) to the point where the digital television selects a different source. Then this data is stored in the appropriate format internal to the deployment device. The on-screen display deployment controller uses this data to build the screen display and mix it with the decoded MPEG video. Updates occur in exactly the same way that the original screen display is built with the exception that there would be no need to transfer the Deployment Header to the Main screen and the color palette unless the color palette or spatial resolution has changed. Based on the input of a remote control (directly or indirectly), the target constructs the Display Deployment Update Block (s) in its memory. These blocks can be very small and possibly overlap with the screen display that is already deployed. Once the block (s) are ready, the target sends the appropriate update message (s). After the activation message (s) is received from the target, the on-screen display module in the deployment device requests memory accesses that start at the memory location specified in the activation message. These Display Deployment Update Blocks are processed and placed on the existing screen display in the same order in which the activation messages were received. The deployment device again informs the target of a successful read so that the target can release any internal memory that has been assigned to the block transfer. Exactly like the original screen display, these blocks remain in the display until they are overwritten. You can build several views on the target and then deploy appropriately using the deployment device. When a change is made, the goal determines how deployment on the deployed screen is affected and sends the appropriate Update Blocks to the deployment device. This scheme reduces complexity and bus traffic compared to the deployment device that is required to track the overlaps. The amount of data to be transferred can be reduced by using a limited number of colors, using vertical line doubling and medium horizontal resolution. For example, a screen display of 320X240 can be displayed in 640X480 specifying the vertical line dubbing and half horizontal resolution. If only 4-bit color is used, then the amount of data that has to be transferred is approximately 39 Kbytes. Assuming a payload of 512 bytes per 500 μsec, this screen display could be transferred in approximately 40 μsec. Of course, small updates take much less time.

Video encoded in real time can be achieved by transferring screen display menus with bitmaps. In this case a 640X480 display using 8-bit color could be transferred at 30 frames / second using a 74 Mbit / second Isochronous channel. Probably one of these channels could be supported in the group. In addition to the start location and size of the current screen display data to be transferred to a deployment device, a field indicating the type of display data can be useful. For example, a user who is watching a movie may want to ignore status or error messages. The differentiation of the display data type is useful for the deployment device and / or the user to decide whether the message should be displayed. The activation message can also be used to inform the deployment device to read the Deployment Header on the Main screen and the color palette. Additionally, the activation message may also inform the deployment device to clear the screen display. The start of an On-Screen Display Update Block reading can only occur through the use of a target activation message to the display device. The deployment device should process the activation messages in the same order in which they were received. Fig. 6, il uses the use of a sub-region message 30 generated by the display device 14 to request the update of a specific sub-region 32 of the existing Display Deployment Region 20 being deployed. This message can be useful in various situations such as when an error message from the deployment device or some other device overwrites a portion of the existing screen display. The deployment device may request that this sub-region of the screen display be transmitted again. This sub-region message would be useful when there is a change in the color map, but the deployment device did not save copies of the original Display Deployment Update Bit Maps. Another additional benefit of using a sub-region message would be when the user selects a different device and then returns to the first device. The deployment device may have to request some information to reconstruct the deployment. Although a sub-region is requested as a block, it is possible that the form of screen display that was previously in that sub-region is not rectangular. For this reason, the target can transfer the information for this sub-region to the deployment device in multiple Display Deployment Update Blocks. This message will include the row / column start coordinates and the width / height of the sub-region. However, it should be noted that the target does not have to wait for that message to display a screen display. Most of the time, it will initiate changes to its on-screen display based on incoming remote control messages. Activation messages will be used to initiate the transfer of OSDU B in any case. The on-screen display menu can be displayed properly on any of the following ATSC Video Formats.

The general format of on-screen display menus that are being transferred from a target device to a deployment device includes first transferring a Deployment Header to the Main screen and second transferring a color palette. The on-screen display menu can be partially updated by transferring an updated Display Header on screen and the related bitmap menu. The Deployment Header on the Main screen contains control information for the color map and general control information such as resolution, size of screen display area required, etc. The color map can be in one of 4 formats (2-bit color, 4-bit color, 8-bit color, no color map) and also includes facilities for mixing with background video. Main Screen Display Header The main screen display header has been used to set the format of the following screen display menu, for example, the following header contains information (that is, the size of 640 X 480 pixels) throughout the Region of display on the screen and in the color palette. Changes to the Main Screen Display Header are communicated to the deployment device through the use of activation messages from the target. The defined screen display region is only valid as long as a target has been selected as a source for a deployment device.

The field of the Display Deployment Header is used to distinguish the type of Display Deployment Block that is being transferred from the target to the deployment device, for example, the Main Screen Display Header or the Bitmap Update block. . There is also the possibility to specify that each vertical line is duplicated. For an interleaved display, this has the effect of specifying that the even and odd fields are the same.

'When this mode is activated, each line of the on-screen display is repeated once (ie, duplicated). For example, by setting the activation bit from vertical to true and sending 5 lines of display data to the deployment device, the screen display would produce 10 lines in the deployment output. Then, it is necessary that the objective sets the Block Height to correspond correctly to the total lines deployed (in this case 10). The mix weight bits tell the screen display the mix ratio for display and video display. For example, each bit can have a resolution of 1/16. The mixing ratio goes from 0 (transparent) to 15/16 (almost solid pixel). The same mix weight is used for all the pixels that have their respective mix bit set (B [n] = 1). The weight is mixed is ignored for pallets with the mixture deactivated, producing a solid screen display. The Display Deployment Region Height and the Display Deployment Region Width define the height and width of the Display Deployment Region (in number of pixels) that the target plans to use. A typical region can be 640X480. The deployment device may not display portions of Display Deployment Update Blocks that fall outside of this region. The Color Resolution bits define the resolution of screen display current, such as full, half or one third resolution. The combination of the Display Deployment Region Height, the Display Deployment Region Width and the Color Resolution effectively set the screen display configuration. The color palette immediately follows the Header of Display on the Main Screen. Each palette entry contains one bit of transparency (T), one bit of mixture (B), 6 bits of Y, 4 bits of Cb, and 4 bits of Cr. It should be noted that each of these 3 color components is will convert to a byte before mixing with the MPEG video. Thus, the bits associated with each field, (for example, Y) can be considered the most significant bits in that byte. For example, for the luminance (Y), the 6 bits in the color map are the 6 most significant bits in a luminance byte. The transparency bit and the mix bit for each input allow the target to selectively display either a screen display pixel, a video pixel or a mixed pixel based on pixel by pixel. Changes to the Color Palette are communicated to the deployment device through the use of activation messages and subsequent reading operations. The on-screen display pixels that are stored in the memory are a 4: 4: 4 representation of set chrominance / luminance levels of the palette. The values in the bitmap are classified essentially in the palette. It should be noted that the color resolution for each block may be less than that specified for the palette. For example, if there are 256 entries in the color map (ie, 8 bits / pixel) then a specific display display block can specify 2 bits / pixel, 4 bits / pixel, or 8 bits / pixel. If 2 bits / pixel are specified for the on-screen display block in this example, then these 2 bits would be classified in the first 4 entries of the color map. If 4 bits / pixel are specified for the screen display block, then these 4 bits would be classified in the first 16 color map entries. For True Color Mode, the on-screen display physical equipment on the deployment device can extract 4: 2: 2 data directly from the OSD FI FO (not shown) and send it through the outputs, ignoring the normal appearance of the palette All normal screen display functions are supported, except for the mixing function. Therefore, the user can use this True Color Mode in full, half or one third resolution. Any pixel can be made transparent by setting this Y component to "0". It should be noted that all data for the header block is assumed to be in the 4: 2: 2 format in the following sequence: Y1, Cb1, Cr1, Y2, y3, Cb3, Cr3, Y4,. . . Each component has 8 bits of data. In this format, both Y1 and Y2 use the same chrominance components (Cb1, Cr1). That is, each pixel is represented by a respective luminance value and by a series of chrominance information that is shared with a second pixel. For example, pixels 1 and 2 are represented by respective luminance values Y1 and Y2 and a common series of chrominance values Cb1 and Cr1. This produces an effective pixel size of 16 bits / pixel. As in pixel-based mode, only the non-pixel numbers are supported by the Display Deployment Update Blocks. The pixel format of the update block can be configured in such a way that the upper left pixel is first, followed in a logical way by the first and then the second by the final pixel located in the lower right part of the region. Again, the user needs to properly calculate the number of pixels per line required for the given resolution and line width. Color Bitmap Format True pixel 1 - Y Pixel 0 & 1 - Cr pixel 0 &1 - Cb pixel 0 - Y pixel 3 - Y pixel 2 &3 - Cr pixel 2 &3 - Cb pixel 2 - Y Etc.High resolution displays can have 4 to 6 times the pixel density for the same size of screen display area. To facilitate setting the requirements and transmission times of screen display, half resolution and one third resolution modes are provided. It is important to consider that the objective has to adequately establish the width of the Display Deployment Region based on the resolution mode. The start column and the width in the Header of the Display Deployment Update Block correspond directly to the display deployment pixels of the display device (based on the internal display pixel counter). For example, if the column start position is 100 and the width 100, then the Display Deployment Update will begin to display pixels in pixel count 100 and end in pixel count 199. Therefore, this function does not depends on the selected resolution mode. If the resolution is Medium, and the target wishes to display this same series of pixels, then it would have to adjust the width to 200. The effect would be to see a "stretched" version of the original image of the screen display. At a minimum, all deployment devices should be able to display a 640x480 display at 2 bits / pixel using vertical line dubbing and J mode or 1/3 resolution for horizontal. For 1/3 horizontal mode, this would produce a 1920X1080 display with the resolution (and deployment transfer time) of a 640X480 display. The transfer of data (ie, menus with bitmap) through the bus can be achieved in a reasonable amount of time. For example, all data for a 640X480 display with 4 bits / pixel requires 1, 228,800 bits. All this data can be transferred in approximately 150 ms assuming a 100 Mb / sec bus, a packet payload of 512 Bytes and assuming that one packet can be transmitted every 500 μsec. This time is further reduced when it is considered that no screen display occupies so much space. Using only one quarter (typical) of the entire screen approximately 40 ms transfer time occurs. Small updates can be of the order of a few thousandths of a second. Display Deployment Update Blocks A Display Deployment Region is a defined area on the display screen. The region is filled using Display Deployment Update Blocks (OSDUB) (See Figure 4). Each Screen Deployment Update Block defines a rectangular portion of the screen that is to be updated. Each update block will remain on the screen until it is replaced by another block or until a "Delete Region" activation command is received. The objective has full flexibility of the format of these blocks (considering the limitations of the deployment device). The dimensions of the Block of Update Display Deployments are absolute (in a sense of pixels). Its coordinates are absolute in the Display Deployment Region. The upper left corner of the Display Deployment Region is the coordinate (0,0). The height / width of the Deployment Block in the expanded screen will depend on the deployment format. If the transmission format changes, the appearance of the screen display may change accordingly. If the transmission format changes, a message (see the discussion below under Display Information) of the display device will be provided to the target informing the target that the format has changed, allowing the target to re-specify the screen display if he wants it. It is anticipated that most of the screen displays will be mixed with the deployment format and will not be affected by a transmission format change. Nevertheless, the target may still want to redraw the screen display since the video may occupy a different portion of the screen. The header for a Screen Deployment Update Lock contains the start position in the Display Deployment Region and the size of the lock. The header (see below) contains two bits that designate the color resolution. This color resolution must be less than or equal to that specified in the Main Screen Display Header. Format of the Display Deployment Update Block Header The column start and row start markers define the upper left corner of the Display Deployment Block that will be displayed. Outside this box, no screen display will be displayed. It should be noted that the pixels are numbered in ascending order starting at 0. The height of the block and the width of the block define the height and width of the Display Deployment Block (in number of pixels) that will be displayed. Outside this box, no screen display will be displayed. A method for sending a single color update block has been provided. When a single color is specified, only a single color is sent in the Update Block (as opposed to a bitmap of the specified region). The color is supplied in the format implied by the header. When set, the Single Color (SC) bit specifies that the entire Display Deployment Update Block is a single color. In this case, the bitmap information will contain a color in the format specified by the Color Resolution bits. An Update Block can be used to move pixels in the specified region up, down, to the right or to the left. The data to be moved is supplied in the bitmap portion of the Update Block. For example, if a region of 200x100 is specified by the Update Block, and the offset to the right of 10 pixels is specified, then the bitmap supplied with the Update Block would be 10x100. A two-bit field specifies the direction of travel. When secured, the Offset bit specifies that the region specified by this Update Block be moved in this region specified by the specified number of pixels.

The data to be moved is contained in the bitmap data portion of the Update Block. When the offset bit is set, this 9-bit offset value field specifies the number of pixels that the data is displaced. The size of the bitmap included in the Update Block is a function of this field and the dimension perpendicular to the direction of travel. Sub-region Request A sub-region message 30 has also been defined and allows the display device 14 to request a specific portion 32 of a region 20 that had previously been sent (see Figure 6). This would be useful if the screen display had to be temporarily overwritten by an error message from a different device or something similar. In this way, the deployment device can request the region when needed (again keeping the memory requirements low).

Encapsulation of Display Request Sub-region Request Message < - 1 Byte -í > - 1 Byte - > < - 1 Byte - > r 1 Byte - > The field "Request_of_Sub-Region_ of_OSD" consists of the following information Row SR Column SR Height SR Width SR -X- 2Bytes 2 Bytes 2 Bytes 2 Bytes Row_SR: Row number from the top (the top row is 0 relative to the top of the Region requested by the target for on-screen display use). SR Column: Column number from the left (the left column is 0 in relation to the left of the Region requested by the objective for on-screen display use). SR Height: Height of the Subregion in number of rows (Must be less than the number of rows in the Display Deployment Region). SR Width: Subregion width in number of columns (Must be less than the number of columns in the Display Deployment Region).

If Height_SR = 0, then the request should be interpreted as a request to resubmit the Main Screen Display Header and the color map. All the objectives capable of generating a On-screen display must implement a Screen Deployment Subregion Object as defined below. The deployment devices communicate the applicable sub-region by specifying the row / column coordinates of the upper-left corner of the region and the width and height. The message syntax that goes in an FCP frame as defined in I EC 61883 is shown below. Deployment Information The following message has been defined to allow the deployment device to inform the target that the deployment format has changed. The deployment format (along with other information) will also be available to be read by the target at any time. The feedback provided from the display device to the target may consist of what is the entire bitmap plane of the screen display (usually the same as the display format) and what portion of the plane has overlapping video. For example, the bitmap plane of the screen display can be 1920X1080, but if the incoming video is 640X480 with an aspect ratio of 4: 3, then the resulting video can be displayed as 1280X960 with the upper left corner of the video in the coordinate (319.59).

Deployment Information < - 1 Byte - > - 1 Byte - > < - 1 Byte - > - 1 Byte - > Location Field / Bitmap Resolution and Video Location 1"Quadlet" Application Control Languages For a consumer electronic device to interact with other interconnected devices via a serial bus I EEE 1394, a common series of commands. Three standard approaches for models and control with Common Application Language, AV / C and the approach adopted for the Universal Serial Bus (USB). The design of control languages is based on the assumption that all consumer electronic products have a hierarchical structure of common parts or functions. Common Application Language and AV / C are control languages that distinguish between physical and logical entities. For example, a television (i.e., a physical entity) may have a number of functional components (i.e., logical entities) such as a tuner, an audio amplifier, etc. These control languages provide two main functions: Resource allocation and Control. Resource allocation refers to requesting, using and releasing Generic Network resources. The messages and control are transported by the FCP as defined in I EC-61883 and mentioned above, for example, the Common Application Language has adopted an object-based methodology for its command syntax. An object contains and has unique access to a set number of internal values known as instance (IV) variables. Each object maintains an internal list of methods. A method is an action that an object performs as a result of receiving a message. When a method is invoked, generally one or more instance variables are updated. A message may consist of a method identifier followed by zero or more parameters. When an object receives a method, it searches its method list for one that matches the method identified in the message. If you find it, the method will be carried out. The parameters supplied with the message determine the exact execution of the method. All the devices that are capable of deploying screen displays must implement the following object of display on the screen. This object assumes asynchronous EXTRACTION with activation message focus. This object will be carried in the activation message from the target to the deployment device. The deploying device will then remove the menu by reading it from the memory space formed on the map of the target bus. The response of this request will be used by the target device as an indication that the deployment device has read these update blocks. Display Deployment Update Activation Object Deployment Update Activation Object in (16) Screen Data Memory The object is used to activate the display deployment mechanism in devices capable of deployment. IV R / W Type Name Context Function a (61) R Numeric size of "memory block" block in byte (default = 10) b (62) R Numeric length_of_ length of current register in register bytes (default value = 10) C (43) R / W Numeric current index Block of current register signaled (default value = 0) 1 (6C) R / W Data 0 block_de In each record, 6 memory MSBs contain the offset and LSB contain the type_of_OSD , the remaining 3 bytes represent the length of the screen display in bytes.

All the devices capable of generating the screen display must im plant the following Display Sub-Planion Request Object in the Screen. This object will be carried in the request message of the deployment device to the objective to request a sub-region of the on-screen display with row and column coordinates, width and height. Application Object of the Display Deployment Subregion The following object is used to inform the target about the deployment. For example, the resolution and size of the bitmap plane of screen display, and the location and size of the displayed video. Deployment Information Object Although the invention has been described in detail with respect to numerous embodiments thereof, it will be apparent that upon reading and understanding the foregoing, numerous modifications will occur to the described embodiment and it is intended to include said modifications within the scope of the appended claims. .

Claims (10)

1. CLAIMS 1. A digital apparatus comprising: (a) means for receiving from a peripheral device, interconnected by a digital bus, bitmap data representative of a screen display associated with said peripheral device; (b) means for combining, in such digital apparatus, such bitmap data received from said peripheral device and such digital current to produce a signal representative of a combined pull-down image. The apparatus of claim 1, further comprising: (a) means for receiving subsequent bitmap data representative of an updated portion of said previously received data; and (b) means for updating such a pull-down image combined with said representative subsequent bitmap data to produce an updated combined pull-down image, such an updated combined pull-down image is associated with said peripheral device. 3. The digital apparatus of claim 2, wherein a portion of said combined drop-down image is overwritten, said digital apparatus further comprising: (a) means for requesting from said peripheral device such bitmap data corresponding to said overwritten portion; of such a combined pull-down image; and (b) means for receiving said bitmap data from said peripheral device. The digital apparatus of claim 3, further comprising: means for selecting said peripheral device from a plurality of available peripheral devices interconnected by such a digital bus. The digital apparatus of claim 4, further comprising: means for notifying said peripheral device of a format change in such display device in response to a format change of such received digital current. The digital apparatus of claim 5, further comprising: means for moving such data in bitmap in such a combined pull-down image. 7. A method for managing an on-screen display menu of a peripheral device interconnected to a deployment device via a digital bus, the deployment device performs the steps of: (a) receiving, from said peripheral device, a message indicative of the characteristics of a bitmap data block stored in a memory device associated with such a peripheral device, such bitmap data are associated with a screen display menu of said peripheral device; (b) generating and providing an asynchronous read request command to such peripheral device; (c) receiving, in response to said asynchronous read request command, such bitmap data of such peripheral device; (d) receive a digital current representative of a scheduled event; and (e) combining such bitmap data received from such peripheral device and said digital current to produce a combined pull-down image, such a combined image is representative of such display on the screen associated with said peripheral device. The method of claim 7, wherein said message contains the location and size of said bitmap data block stored in said memory device. The method of claim 8, wherein said data comprises a header and a bitmap update block, such a header defines the parameters of such a screen display menu and said bitmap update block defines the location and content of such menu. A digital television apparatus comprising: (a) receiving from a peripheral device, interconnected by a digital bus, bitmap data representative of an on-screen display associated with such peripheral device; and (b) receiving from said peripheral device, interconnected by a digital bus, subsequent bitmap data representative of an updated portion of such previously transferred bitmap data, such subsequent bitmap data are classified in such data. in bitmap previously transferred. RESU MEN Interoperability is provided to exchange on-screen display menus and associated control between consumer electronic devices (CE). This interoperability is based on the I EEE 1394 serial bus for the link and physical layers and uses AV / C or Common Application Language as the control language. The invention provides for transferring an on-screen display menu in bitmap constructed by a target device (e.g., a digital video tape recorder) to the display device (e.g., a digital television).