Abstract:
Methods and apparatuses directed to generating a control packet, which may involve generating data rate information indicating whether a device supports a data rate modifying function regarding uncompressed data; and generating a control packet including the data rate information. Data rate information indicates whether a device supports a data rate modifying function regarding compressed data. Control packets may be exchanged between devices to determine a modified data rate and a type of data packet to be sent.

Description:
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS 
       [0001]    This application claims the benefit of Korean Patent Application No. 10-2011-0057002, filed on Jun. 13, 2011, in the Korean Intellectual Property Office, U.S. Provisional Patent Application No. 61/379,482, filed on Sep. 2, 2010, and U.S. Provisional Patent Application No. 61/381,577, filed on Sep. 10, 2010, in the U.S. Patent and Trademark Office, the disclosures of which are incorporated herein in their entirety by reference. 
     
    
     BACKGROUND 
       [0002]    1. Field 
         [0003]    Aspects of the exemplary embodiments relate to methods and apparatuses for generating control packets, and more particularly, to methods and apparatuses for generating control packets that indicate whether a device supports a data rate modification function. 
         [0004]    2. Related Art 
         [0005]    According to related data transmission art, when transmitting compressed data to devices, a data rate is modified to transmit the compressed data. That is, when transmitting compressed data to devices, if a channel through which the compressed data is to be transmitted is inappropriate or a bandwidth of available channels has decreased, the compressed data is transmitted at a substantially low data rate. If a channel condition is appropriate or a bandwidth of available channels has increased, the compressed data is transmitted at a substantially high data rate. 
       SUMMARY OF EMBODIMENTS 
       [0006]    Exemplary embodiments described herein provide for methods and apparatuses for generating control packets. 
         [0007]    According to an exemplary embodiment, there is provided a method of generating a control packet. The method may include generating data rate information indicating whether a device supports a data rate modifying function regarding uncompressed data; and generating a control packet including the data rate information. 
         [0008]    The control packet may further include second data rate information indicating whether the device supports a data rate modifying function regarding compressed data. 
         [0009]    The control packet may further include a first field including the data rate information and the second data rate information. 
         [0010]    The control packet may further include a second field including the data rate information and a third field including the second data rate information. 
         [0011]    The data rate modifying function regarding uncompressed data may include generating, when the uncompressed data is uncompressed video data, at least one pixel block constituting of at least one reference pixel and at least one adjacent pixel adjacent to the at least one reference pixel from among pixels of a video frame regarding the uncompressed video data, and modifying the number of the at least one adjacent pixel included in each of the pixel blocks. 
         [0012]    According to another exemplary embodiment, there is provided an apparatus for generating a control packet, which is installed in a device. The apparatus may involve an information generating unit generating data rate information indicating whether the device supports a data rate modifying function regarding uncompressed data; and a packet generating unit generating a control packet including the data rate information. 
         [0013]    According to another exemplary embodiment, there is provided a computer-readable recording medium having embodied thereon a program for executing the method of generating a control packet. The method may involve generating data rate information indicating whether a device supports a data rate modifying function regarding uncompressed data; and generating a control packet including the data rate information. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    The above and other aspects and features will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which: 
           [0015]      FIG. 1  is a flowchart illustrating a method of generating control packets, according to an exemplary embodiment; 
           [0016]      FIGS. 2A through 2F  are views for illustrating pixel blocks according to various exemplary embodiments; 
           [0017]      FIG. 3  is a flowchart illustrating a method of modifying a data rate of uncompressed data, according to an exemplary embodiment; 
           [0018]      FIG. 4  is a view for illustrating an audio/video (AV) capability request packet according to an exemplary embodiment; 
           [0019]      FIG. 5  is a view for illustrating an AV capability response packet according to an exemplary embodiment; 
           [0020]      FIG. 6  is a view for illustrating a feature list field according to an exemplary embodiment; 
           [0021]      FIG. 7  is a view for illustrating a feature list field according to another exemplary embodiment; 
           [0022]      FIG. 8  is a block diagram for illustrating an apparatus of generating a control packet, according to an exemplary embodiment; and 
           [0023]      FIG. 9  is a block diagram for illustrating an apparatus for modifying a data rate regarding uncompressed data, according to an exemplary embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    Exemplary embodiments will now be described more fully with reference to the accompanying drawings. 
         [0025]      FIG. 1  is a flowchart illustrating a method of generating control packets, according to an exemplary embodiment. 
         [0026]    In operation  110 , data rate information is generated indicating whether a device supports a data rate modifying function for uncompressed data . 
         [0027]    In operation  120 , a control packet including the data rate information is generated. 
         [0028]    Here, the control packet may further include second data rate information indicating whether a data rate modifying function regarding compressed data is supported. 
         [0029]    A control packet including the data rate information may be used when notifying another device of information about whether a device supports a data rate modifying function regarding uncompressed data or not. If the other device receiving the control packet also supports a data rate modifying function regarding uncompressed data, the uncompressed data may be transmitted or received between the two devices based on the data rate modifying function regarding uncompressed data. 
         [0030]    The data rate modifying function regarding uncompressed data according to an exemplary embodiment refers to, if the uncompressed data is uncompressed video data, a function of generating at least one pixel block which may include at least one reference pixel and at least one adjacent pixel to the at least one reference pixel from among pixels of an audio frame regarding the uncompressed audio data, and modifying the number of adjacent pixels included in each pixel block. Hereinafter, pixel blocks according to exemplary embodiments will be described with reference to  FIGS. 2A through 2F . 
         [0031]      FIGS. 2A through 2F  are views for explaining pixel blocks according to exemplary embodiments. 
         [0032]    In  FIG. 2A , thirty-two pixel blocks are illustrated, each of which has a size of 1 pixel×2 pixel. 
         [0033]    In regards to the left uppermost pixel block  201 , a circular pixel Y 00  represents a reference pixel, and a triangular pixel Y 01  represents an adjacent pixel. An arrow indicating a direction from Y 00  to Y 01  is illustrated, which indicates that a pixel value of the adjacent pixel Y 01  is replaced with a difference value between pixels values of Y 00  and Y 01 . 
         [0034]    When the pixel value of Y 01  is replaced with a difference value between pixel values of Y 00  and Y 01 , generation of the pixel block  201  of the left uppermost section is completed, and the rest of the thirty-one pixel blocks are also generated in the substantially same manner as the pixel block  201  of the left uppermost section. 
         [0035]    Hereinafter, a difference value between pixel values of two adjacent pixels will be referred to as a pixel difference value. 
         [0036]    According to another embodiment, after pixel blocks are generated, packets may be generated in each of the pixel blocks such that a pixel value of a reference pixel and a pixel difference value of an adjacent pixel are allocated to different packets according to positions of pixels. 
         [0037]    For example, in the exemplary embodiment of  FIG. 2A , pixels values of the reference pixels Y 00 , Y 02 , Y 04 , Y 06 , . . . , Y 76  may be included in a first packet, and pixel difference values of the adjacent pixels Y 01 , Y 03 , Y 05 , Y 07 , . . . , Y 77  may be included in a second packet. The number of reference pixels within the first packet may be determined by the modified data rate as shown in the examples of  FIG. 2A  to  FIG. 2F . 
         [0038]      FIG. 2B  illustrates sixteen pixel blocks, each of which has a size of 2 pixel×2 pixel. 
         [0039]    Regarding the pixel block  202  in a left uppermost section, a circular pixel Y 00  represents a reference pixel, and triangular pixels Y 01 , Y 10 , and Y 11  represent adjacent pixels. An arrow indicating a direction from Y 10  to Y 11  is illustrated, which indicates that the pixel value of the adjacent pixel Y 11  is replaced with a difference value between pixels values of Y 10  and Y 11 . That is, according to the embodiment  FIG. 2B , a pixel difference value of the adjacent pixel Y 11  may be generated not by referring to the reference pixel Y 00  but to another adjacent pixel Y 10 . Accordingly, in order for a receiver to restore the pixel value of the adjacent pixel Y 11 , the pixel value of the adjacent pixel Y 10  is to be restored first, and then the pixel value of the restored adjacent pixel Y 10  is used to determine the pixel value of Y 11 . 
         [0040]    In the pixel block  202  of the left uppermost section of  FIG. 2B , the pixel value of the reference pixel Y 00  may be included in a first packet, and a pixel value of the adjacent pixel Y 01  may be included in a second packet, and the pixel value of the adjacent pixel Y 10  may be included in a third packet, and the pixel value of the adjacent pixel Y 11  may be included in a fourth packet. In the rest of the fifteen pixel blocks of  FIG. 2B , pixel values and pixel difference values are allocated to the packets in the same manner as the pixel block  202  of the left uppermost section of  FIG. 2B . 
         [0041]    Here, the packets may be generated in the order of the first packet, the second packet, the third packet, and the fourth packet. That is, when a receiver side receives the packets, the most important packet is the first packet containing the reference pixels, and thus the first packet is to be generated first. Conversely, the adjacent pixels included in the fourth packet are generated last since they can be restored after the adjacent pixels included in the third packet are restored and thus are of lower importance. The number of packets containing pixel difference values that are generated and transmitted in addition to the second packet may be determined from the modified data rate and/or the number of reference pixels of the first packet. As noted in the foregoing exemplary embodiments and as noted above, additional packets containing difference values may be utilized in conjunction with the first packet, depending on the modified data rate. The packets with the pixel difference values may be transmitted sequentially to resolve the pixels in the pixel blocks. 
         [0042]    According to another exemplary embodiment, unequal error protection (UEP) may also be applied to the packets according to the relative importance of the packets as disclosed below. 
         [0043]    That is, in the above-described exemplary embodiment, the strongest error protection is applied to the first packet, and the weakest error protection may be applied to the fourth packet. For example, the number of bits allocated to packets for error restoration may be large in the order of the first packet, the second packet, the third packet, and the fourth packet. 
         [0044]      FIG. 2C  illustrates eight pixel blocks, each of which has a size of 2 pixel×4 pixel. 
         [0045]    In regards to the pixel block  203  in a left uppermost section, a circular pixel Y 00  represents a reference pixel, and triangular pixels Y 01 , Y 02 , Y 03 , Y 10 , Y 11 , Y 12 , and Y 13  represent adjacent pixels. 
         [0046]    In the pixel block  203  in the left uppermost section of the exemplary embodiment of  FIG. 2C , a pixel value of the reference pixel Y 00  and pixel difference values of the adjacent pixels Y 01 , Y 02 , Y 03 , Y 10 , Y 11 , Y 12 , and Y 13  are included in eight different packets according to the positions of the packets in the pixel block  203 . In  FIG. 2C , in the rest of the seven pixel blocks, pixel values and pixel difference values are allocated to the packets in the same manner as in the pixel block  203  of the left uppermost section of  FIG. 2C . 
         [0047]      FIG. 2D  illustrates four pixel blocks, each of which has a size of 4 pixel×4 pixel. 
         [0048]    In a pixel block  204  of the left uppermost section of  FIG. 2D , a pixel value of a reference value Y 00  and pixel difference values of fifteen adjacent pixels Y 01  through Y 33  are included in sixteen different packets according to positions of the pixels in the pixel block  204 . Referring to  FIG. 2D , in the rest of the three pixel blocks, pixel values and pixel difference values of the pixels are allocated to the packets in the same manner as in the pixel block  204  of the left uppermost section of  FIG. 2D . 
         [0049]      FIG. 2E  illustrates two pixel blocks, each of which has a size of 4 pixel×8 pixel. 
         [0050]    In the pixel block  205  of an upper section of  FIG. 2E , a pixel value of a reference value Y 00  and pixel difference values of thirty-one adjacent pixels Y 01  through Y 37  are included in thirty-two different packets according to positions of the pixels in the pixel block  205 . In the other pixel block of  FIG. 2E , a pixel value of a reference pixel and pixel difference values of adjacent pixels are allocated to packets in the same manner as in the pixel block  205  of the upper section. 
         [0051]    In  FIG. 2F , one pixel block  206  is illustrated, which has a size of 8 pixel×8 pixel. 
         [0052]    In the pixel block  206  of  FIG. 2F , a pixel value of a reference pixel Y 00  and pixel difference values of sixty-three adjacent pixels Y 01  through Y 77  are included in sixty four different packets according to positions of the pixels in the pixel block  206 . 
         [0053]    While the position of the reference pixel is in the left uppermost section of each pixel block in  FIGS. 2A through 2F , the exemplary embodiments described are not limited thereto. For example, the position of the reference pixel may be a right uppermost section of each pixel block. 
         [0054]    Here, a data rate modifying function regarding uncompressed data according to an exemplary embodiment will be described with reference to the embodiments of  FIGS. 2A through 2F : when a bandwidth of a channel through which the uncompressed data is to be transmitted is equal to or greater than a predetermined critical value, and a block mode of a pixel block is set as a 1 pixel×2 pixel mode, as illustrated in  FIG. 2A , to transmit uncompressed data using two packets, if the bandwidth of the channel is reduced to a value equal to or less than the predetermined critical value, the block mode of the pixel block is reset to a 8 pixel×8 pixel mode as illustrated in  FIG. 2F  so as to transmit uncompressed data using sixty-four packets. As such, modifying a block mode of a pixel block according to the state of a channel is referred to as a data rate modifying function regarding uncompressed data. 
         [0055]    A control packet including data rate information according to an exemplary embodiment may be an audio/video (AV) capability request packet, which is used by a device to request AN capability of an opposite device, or an AV capability response packet corresponding to the AV capability request packet. 
         [0056]    Hereinafter, a method of modifying a data rate regarding uncompressed data using an AV capability request packet and an AV capability response packet will be described with reference to  FIG. 3 . 
         [0057]      FIG. 3  is a flowchart illustrating a method of modifying a data rate regarding uncompressed data, according to an exemplary embodiment. 
         [0058]    In operation  1 , a first device  310  transmits an AV capability request packet that includes first device data rate information indicating whether the first device  310  supports a data rate modifying function regarding uncompressed data and is used to request A/V capability of a second device  320 , to the second device  320 . 
         [0059]    A structure of an AV capability request packet according to an exemplary embodiment will be described below with reference to  FIG. 4 . 
         [0060]    In operation  2 , the second device  320  transmits an AV capability response packet that includes data rate information indicating whether the second device  320  supports a data rate modifying function regarding uncompressed data and is a response to the AV capability request packet first device to the first device  310 . 
         [0061]    A structure of an AV capability response packet according to an exemplary embodiment will be described below with reference to  FIG. 5 . 
         [0062]    In operation  3 , the first device  310  selectively modifies a data rate regarding uncompressed data based on the second device data rate information. 
         [0063]    That is, when it is indicated in the second device data rate information that the second device  320  supports the data rate modifying function regarding uncompressed data, the first device  310  modifies a data rate regarding uncompressed data. Otherwise, the first device  310  does not modify a data rate regarding uncompressed data. 
         [0064]    According to another embodiment, an operation in which the first device  310  further transmits uncompressed data according to the modified data rate to the second device  320  may be further performed. 
         [0065]      FIG. 4  is a view for explaining an AV capability request packet according to an exemplary embodiment. 
         [0066]    Referring to  FIG. 4 , the AV capability request packet according to an embodiment of the present invention includes a feature list field  410 , a compression capability field  420 , a compression sub-capability field  430 , a number of vendor specific codecs field  440 , and a vendor specific codec identifier fields  450   a  through  450   n.    
         [0067]    The feature list field  410  represents AN capability types that are supported by the first device  310 . 
         [0068]    The compression capability field  420  supports a compression type of a compression method supported by the first device  310 . 
         [0069]    The compression sub-capability field  430  represents specific sub-capabilities regarding each of the compression types supported by the first device  310 . 
         [0070]    The number of vendor specific codecs field  440  represents the number of vendor specific codecs supported by the first device  310 . 
         [0071]    The vendor specific codec identifier fields  450   a  through  450   n  each include an identifier to identify vendor specific codecs. 
         [0072]      FIG. 5  is a view for explaining an AV capability response packet according to an exemplary embodiment. 
         [0073]    Referring to  FIG. 5 , an AV capability response packet according to an exemplary embodiment includes a feature list field  510 , a compression capability field  512 , a compression sub-capability field  514 , an audio delay field  516 , an interlaced audio delay field  518 , an audio buffer field  520 , a video delay field  522 , an interlaced video delay field  524 , a video buffer field  526 , a content protection (CP) support field  528 , a block mode field  530 , a component configuration field  532 , a number of vendor specific codecs field  534 , and vendor specific codec identifier fields  536   a  through  536   n.    
         [0074]    The feature list field  510  represents AN capability types supported by the second device  320 . 
         [0075]    A structure of the feature list field  510  according to an embodiment of the present invention will be described below with reference to  FIGS. 6 and 7 . 
         [0076]    The compression capability field  512  represents a compression type of a compression method supported by the second device  320 . 
         [0077]    The compression sub-capability field  514  represents a specific sub-capability of each compression method supported by the second device  320 . 
         [0078]    The audio delay field  516  represents a delay time when the second device  320  processes audio data. A unit of the delay time can be milliseconds (ms), or other units of time as appropriate. 
         [0079]    The interlaced audio delay field  518  represents audio latency when video data in an interlaced video format is received. A unit of the delay time can be milliseconds (ms), or other units of time as appropriate. 
         [0080]    The audio buffer field  520  denotes a size of buffer for audio processing in the second device  320 . A unit of a buffer size can be Kbytes, or other buffer sizes may be utilized as appropriate. 
         [0081]    The video delay field  522  denotes a delay time when the second device  320  processes audio data. A unit of delay time can be milliseconds (ms), or other units of time as appropriate. 
         [0082]    The interlaced video delay field denotes a video latency when video data having an interlaced video format is received. A unit of delay time can be milliseconds (ms), or other units of time as appropriate. 
         [0083]    The video buffer field  526  denotes a size of a buffer for video processing in the second device  320 . A unit of a buffer size can be Kbytes, or other buffer sizes may be utilized as appropriate. 
         [0084]    The CP support field  528  denotes content protection types supported by the second device  320 . 
         [0085]    When uncompressed data is uncompressed video data, the block mode field  530  denotes a block mode of a pixel block regarding pixels of a video frame of uncompressed video data supported by the second device  320 . For example, a block mode may be a 1 pixel×2 pixel mode, 2 pixel×2 pixel mode, 2 pixel×4 pixel mode, 4 pixel×4 pixel mode, 4 pixel×8 pixel mode, or 8 pixel×8 pixel mode. 
         [0086]    The component configuration field  532  denotes a color component configuration of uncompressed video data supported by the second device  320 . For example, the component configuration field  532  may indicate which of RGB, YCbCr, and YCoCg formats uncompressed video data has. 
         [0087]    The number of vendor specific codecs field  534  denotes the number of vendor specific codecs supported by the second device  320 . 
         [0088]    The vendor specific codec identifier fields  536   a  through  536   n  include identifiers for identifying vendor specific codecs. 
         [0089]      FIG. 6  is a view for explaining the feature list field  510  according to an exemplary embodiment. 
         [0090]    The feature list field  510  includes first through fourth sub-fields  510   a  through  510   d.    
         [0091]    The first sub-field  510   a  denotes whether the second device  320  supports a compressed data processing function. 
         [0092]    The second sub-field  510   b  denotes whether the second device  320  supports an uncompressed stream data processing function. 
         [0093]    The third sub-field  510   c  includes second data rate information indicating whether the second device  320  supports a data rate modifying function regarding compressed data. 
         [0094]    For example, when the third sub-field  510   c  is marked as 0, it may denote that the second device  320  does not support a data rate modifying function regarding compressed data, and when marked as 1, it may denote that the second device  320  supports a data rate modifying function regarding compressed data. 
         [0095]    The fourth sub-field  510   d  includes data rate information indicating whether the second device  320  supports a data rate modifying function regarding uncompressed data. 
         [0096]    In Wireless Gigabit Alliance (WiGiG) AN PAL format, WiGig spatial processing (WSP) is defined, wherein WSP is a function of supporting a data rate modifying function regarding uncompressed data. 
         [0097]    For example, when the fourth sub-field  510   d  is marked as 0, it may denote that the second device  320  does not support a data rate modifying function (or WSP) regarding uncompressed data, and when it is marked as 1, it may denote that the second device  320  supports a data rate modifying function (or WSP) regarding uncompressed data. 
         [0098]      FIG. 7  is a view for explaining a feature list field according to another exemplary embodiment. 
         [0099]    A first sub-field  510   a  denotes whether the second device  320  supports a compressed data processing function. 
         [0100]    A second sub-field  510   b  denotes whether the second device  320  supports an uncompressed stream data processing function. 
         [0101]    A third sub-field  510   e  includes data rate information indicating whether the second device  320  supports a data rate modifying function regarding uncompressed data and second data rate information indicating whether the second device  320  supports a data rate modifying function regarding compressed data. 
         [0102]    For example, when the third sub-field  510   e  is marked as 0, it may denote that the second device  320  does not support both a data rate modifying function regarding uncompressed data and a data rate modifying function regarding compressed data, and when the third sub-field  510   e  is marked as 1, it may denote that the second device  320  supports both a data rate modifying function regarding uncompressed data and a data rate modifying function regarding compressed data. 
         [0103]    A fourth sub-field  510   f  is a reserved field left empty for use in the future. 
         [0104]    While the structure of the feature list field  510  of an AV capability response packet has been described with reference to  FIGS. 6 and 7 , the feature list field  410  in the AV capability request field may have the same structure as that of the feature list field  510  of  FIGS. 6 and 7  except that the feature list field  410  is used in the first device  310 . 
         [0105]      FIG. 8  is a block diagram for explaining an apparatus of generating a control packet, according to an exemplary embodiment. 
         [0106]    Referring to  FIG. 8 , a control packet generating apparatus  800  includes an information generating unit  810  and a packet generating unit  820 . Here, the packet generating apparatus  800  may be installed in a predetermined device. 
         [0107]    The information generating unit  810  generates data rate information indicating whether a device in which the control packet generating apparatus  800  is installed supports a data rate modifying function regarding uncompressed data. 
         [0108]    The packet generating unit  820  generates a control packet including the data rate information. 
         [0109]    The control packet generating apparatus  800  may preferably further include a transmitting unit (not shown) transmitting control packets. 
         [0110]      FIG. 9  is a block diagram for explaining an apparatus  910  for modifying a data rate regarding uncompressed data, according to an exemplary embodiment. 
         [0111]    Referring to  FIG. 9 , the data rate modifying apparatus  910  includes a transmitting unit  912 , a receiving unit  914 , and a control unit  916 . In  FIG. 9 , it is assumed that the data rate modifying apparatus  910  is installed in a first device (not shown), and a second device  920  is further illustrated for convenience of description. 
         [0112]    The transmitting unit  912  transmits an AV capability request packet including first device data rate information indicating whether the first device supports a data rate modifying function regarding uncompressed data, to the second device  920 . 
         [0113]    The receiving unit  914  receives an AV capability response packet including second device data rate information indicating whether the second device  920  supports a data rate modifying function regarding uncompressed data, from the second device  920 . 
         [0114]    The control unit  916  selectively modifies a data rate regarding uncompressed data based on the first or second device data rate information. 
         [0115]    Preferably, the control unit  916  may control such that after a data rate regarding uncompressed data is modified, the transmitting unit  912  transmits the uncompressed data at the modified data rate. 
         [0116]    According to another embodiment, after the control unit  916  has compressed only some video frames according to a channel state, the transmitting unit  912  may be controlled to transmit the compressed video frames and other video frames that are not compressed. 
         [0117]    For example, regarding a 3D video data, the control unit  916  may control such that only an L video frame is compressed from among an R video frame and an L video frame, and the transmitting unit  912  transmits the compressed L video frame and the uncompressed R video frame afterwards. 
         [0118]    The embodiments can be written as computer programs and can be implemented in general-use digital computers that execute the programs using a computer-readable recording medium. Various units and modules of the exemplary embodiments may be executed by a processor. 
         [0119]    Examples of the computer-readable recording medium include magnetic storage media (e.g., ROM, floppy disks, hard disks, etc.) and optical recording media (e.g., CD-ROMs, or DVDs). 
         [0120]    While this invention has been particularly shown and described with reference to embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The embodiments should be considered in descriptive sense only and not for purposes of limitation. Therefore, the scope of the invention is defined not by the detailed description of the invention but by the appended claims, and all differences within the scope will be construed as being included in the present invention.