WO2015137751A1 - Hdmi를 사용한 데이터 송수신 기기 및 방법 - Google Patents

Hdmi를 사용한 데이터 송수신 기기 및 방법 Download PDF

Info

Publication number
WO2015137751A1
WO2015137751A1 PCT/KR2015/002418 KR2015002418W WO2015137751A1 WO 2015137751 A1 WO2015137751 A1 WO 2015137751A1 KR 2015002418 W KR2015002418 W KR 2015002418W WO 2015137751 A1 WO2015137751 A1 WO 2015137751A1
Authority
WO
WIPO (PCT)
Prior art keywords
sink device
decompression
data
information
source device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2015/002418
Other languages
English (en)
French (fr)
Inventor
박장웅
이현재
양현식
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Priority to US15/125,939 priority Critical patent/US9779687B2/en
Priority to KR1020167027463A priority patent/KR20160133475A/ko
Priority to EP15762311.7A priority patent/EP3119100A4/en
Priority to CN201580013370.1A priority patent/CN106464964B/zh
Priority to JP2016556950A priority patent/JP6522643B2/ja
Publication of WO2015137751A1 publication Critical patent/WO2015137751A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/003—Details of a display terminal, the details relating to the control arrangement of the display terminal and to the interfaces thereto
    • G09G5/006—Details of the interface to the display terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43632—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wired protocol, e.g. IEEE 1394
    • H04N21/43635—HDMI
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/615—Signal processing at physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2340/00—Aspects of display data processing
    • G09G2340/02—Handling of images in compressed format, e.g. JPEG, MPEG
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00—Aspects of data communication
    • G09G2370/04—Exchange of auxiliary data, i.e. other than image data, between monitor and graphics controller
    • G09G2370/045—Exchange of auxiliary data, i.e. other than image data, between monitor and graphics controller using multiple communication channels, e.g. parallel and serial
    • G09G2370/047—Exchange of auxiliary data, i.e. other than image data, between monitor and graphics controller using multiple communication channels, e.g. parallel and serial using display data channel standard [DDC] communication
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00—Aspects of data communication
    • G09G2370/12—Use of DVI or HDMI protocol in interfaces along the display data pipeline

Definitions

  • the present invention relates to an apparatus and method for transmitting and receiving data using a high definition multimedia interface (HDMI), and more particularly, to an apparatus for transmitting and receiving data using HDMI, which compresses and transmits a large amount of data and decompresses received data. It is about a method.
  • HDMI high definition multimedia interface
  • HDMI is an interface / standard developed for AV electronics using DVI (Digital Visual Interface), a standard for personal computers and displays.
  • HDMI is a source that is transmitted from the player to the display device without compressing video / audio. There is little latency between the device and the sink device, and there is no need for a separate decoder chip or software, resulting in high format compatibility.
  • video, audio, and control signals are all transmitted in one cable, simplifying the wiring of complex AV devices, and supporting high-bandwidth digital content protection (HDCP) for password protection. It can even provide protection.
  • HDMI is an interface / standard developed for AV electronics using DVI (Digital Visual Interface), a standard for personal computers and displays.
  • HDMI is a source that is transmitted from the player to the display device without compressing video / audio. There is little latency between the device and the sink device, and there is no need for a separate decoder chip or software, resulting in high format compatibility.
  • video, audio, and control signals are all transmitted in one cable, simplifying the wiring
  • U-HD Ultra-HD
  • 4K resolution or UD resolution pixels can be captured at a resolution four times higher (3840x2160) than full-HD to provide very high-definition images.
  • UHD content is being distributed through various storage media and services in order to provide viewers with vivid realism and immersion.
  • external sources such as UHD TVs, set-top boxes, and Blu-ray Disc players can be connected to wired video interfaces such as HDMI to watch uncompressed video.
  • wired video interfaces such as HDMI to watch uncompressed video.
  • UHD resolution is increased to 8K or higher, the physical limitations of the existing wired video interface will make it impossible to transmit uncompressed video.
  • research is being conducted on a method of transmitting a losslessly compressed image from a source device and decompressing it from a sink device.
  • the compression and decompression feature information exchange between the source device and the sink device, the control of the decompression function operation, and the state change information transmission method are proposed to accurately convey the compression characteristic information to the sink device, and the sink device accurately decompresses the compression device.
  • the viewer can provide an environment in which the given UHD content can be viewed in an optimal environment.
  • the data transmission and reception method of the source device for transmitting the compressed video data using the HDMI (High Definition Media Interface) in accordance with the present invention EDID (Extended) to the sink device when the sink device is connected Requesting to read Display Identification Data; Receiving an EDID including decompression capability information of the sink device from the sink device; Transmitting operating parameter information determined based on the EDID, wherein the operating parameter information includes compressed metadata; And transmitting the compressed video data.
  • HDMI High Definition Media Interface
  • the decompression capability information indicates whether the sink device supports decompression or at least one of decompression related characteristic information, and the decompression capability information Is received as an HDIM Forum-Vendor Specific Data Block (HF-VSDB).
  • HF-VSDB HDIM Forum-Vendor Specific Data Block
  • the compressed metadata includes characteristic information of the compressed video data, and the compressed metadata is transmitted as an infoframe.
  • the data transmission and reception method of the source device further comprises the step of activating or deactivating the decompression function of the sink device, the activation or deactivation of the decompression function is SCDCS (Status and Control) of the sink device This is done using the decompression activation information contained in the Data Channel Structure.
  • SCDCS Status and Control
  • the method may further include reading the state change information included in the SCDCS of the sink device when the state change of the decompression function of the sink device occurs.
  • a source device for transmitting video data compressed using HDMI the HDMI transmitter for transmitting and receiving data via HDMI; A video encoding unit for compressing video data transmitted through the HDMI; And a control unit for controlling the HDMI transmitter and the video encoding unit, wherein the source device requests reading of Extended Display Identification Data (EDID) from the sink device when the sink device is connected, and the sink device from the sink device.
  • EDID Extended Display Identification Data
  • a data transmission / reception method of a sink device that receives compressed video data using a high definition media interface (HDMI) may receive a request to read EDID (Extended Display Identification Data) from a connected source device. step; Transmitting an EDID including decompression capability information of the sink device to the source device; Receiving operation parameter information including compressed metadata from the source device; And receiving the compressed video data.
  • EDID Extended Display Identification Data
  • the decompression capability information indicates whether the sink device supports decompression or at least one of decompression related characteristic information. Is transmitted as the HDIM Forum-Vendor Specific Data Block (HF-VSDB).
  • HF-VSDB HDIM Forum-Vendor Specific Data Block
  • the compressed metadata includes characteristic information of the compressed video data, and the compressed metadata is received as an infoframe.
  • the data transmission and reception method of the sink device further comprises the step of activating or deactivating the decompression function of the sink device by the source device, the activation or deactivation of the decompression function of the sink device This is performed using the decompression activation information contained in the Status and Control Data Channel Structure (SCDCS).
  • SCDCS Status and Control Data Channel Structure
  • the state change information included in the status and control data channel structure (SCDCS) of the sink device is written.
  • the method may further include transmitting a read request message to the source device.
  • a sink device for receiving video data compressed using a high definition media interface (HDMI) according to the present invention, an HDMI receiver for transmitting and receiving via HDMI; A video decoding unit for decompressing video data received through the HDMI; And a control unit for controlling an HDMI receiver and the video decoding unit, wherein the sink device is requested to read EDID (Extended Display Identification Data) from a connected source device, and to the source device according to the request.
  • EDID Extended Display Identification Data
  • An EDID including decompression capability information is transmitted, operation parameter information including compressed metadata is received from the source device, and the compressed video data is received.
  • the present invention by transmitting the compressed A / V data (at least one of audio data or video data) through the HDMI, it is possible to support the content of very high resolution in HDMI.
  • the source device knows whether the sink device has the decompression capability through the EDID information, the compressed video data or the uncompressed video data can be selectively transmitted according to the type of the sink device.
  • the sink device by transmitting compression metadata indicating a compression attribute used by the source device to compress the video data, the sink device can decompress the compressed video data in an appropriate manner.
  • the decompression function of the sink device when the source device transmits the compressed video data or the uncompressed video data, the decompression function of the sink device can be activated / deactivated through the SCDCS. Therefore, even if the user does not change the decompression function of the sink device, the user can change the sink device setting according to the type of video data on the source side, thereby eliminating user inconvenience.
  • the source device may be notified through the SCDCS to change the operation parameter according to the changed state in the source device.
  • FIG. 1 illustrates an HDMI system and data transmission / reception channels included in an HDMI system according to an embodiment of the present invention.
  • FIG. 2 illustrates a source device and a sink device in an HDMI system according to an embodiment of the present invention.
  • FIG 3 illustrates an EDID structure according to an embodiment of the present invention.
  • 4 through 5 illustrate an embodiment of an EDID extension block.
  • FIG. 6 illustrates an HDMI Forum (HF) -Vendor-Specific Data Block (VSDB) according to an embodiment of the present invention.
  • HF HDMI Forum
  • VSDB Video Data Block
  • FIG 7 illustrates an HDMI Forum-Vendor Specific InfoFrame (HF-VSIF) according to an embodiment of the present invention.
  • HF-VSIF HDMI Forum-Vendor Specific InfoFrame
  • SCDC 8 illustrates a Status and Control Data Channel (SCDC) structure according to an embodiment of the present invention.
  • FIG 9 illustrates A / V data transmission and reception method through HDMI according to an embodiment of the present invention.
  • FIG. 10 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention.
  • FIG. 11 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and in particular, a method of controlling a decompression function of a sink device by a source device.
  • FIG. 12 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and in particular, illustrates a method in which a source device activates a decompression function of a sink device using SCDCS.
  • FIG. 13 is a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and particularly, illustrates a method in which a sink device notifies a source device of a state change of a decompression function.
  • FIG. 14 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention.
  • a sink device notifies the source device of a state change of a decompression function using SCDCS.
  • FIG. 1 illustrates an HDMI system and data transmission / reception channels included in an HDMI system according to an embodiment of the present invention.
  • HDMI system Devices that transmit and receive video / audio / control data using HDMI may be referred to as an HDMI system, and the HDMI system may include a source device 1010, a sink device 1020, and an HDMI cable.
  • a device for transmitting video / audio data through HDMI corresponds to the source device 1010
  • a device for receiving video / audio data through HDMI corresponds to a sink device 1020, and connects two devices.
  • HDMI cable is provided to support data transmission and reception.
  • the HDMI cables and connectors may perform pairing of four channels providing a transition minimized differential signaling (TMDS) data channel and a TMDS clock channel.
  • TMDS data channels can be used to carry video data, audio data and auxiliary data.
  • the HDMI system provides VESA (Video Electronics Standards Association) Display Data Channel (DDC).
  • DDC Video Electronics Standards Association
  • the DDC is used for exchanging configuration and status information between one source device and one sink device.
  • the CEC protocol can provide high-level control between various audiovisual products in the user's environment and can be used optionally.
  • the optional HDMI Ethernet and Audio Return Channel may provide Ethernet compatible data networking between Audio Return Channel (ARC) and connected devices in the opposite direction from the TMDS.
  • Video data, audio data and additional data can be transmitted / received through three TMDS data channels.
  • the TMDS clock typically runs the video pixel rate and is transmitted over the TMDS clock channel.
  • the TMDS clock can be used as a frequency reference for data recovery on three TMDS data channels in the HDMI receiver.
  • 8 bits of data per TMDS data channel are converted into 10 bits of DC balanced, transition-minimized sequence and serially transmitted at 10 bits per TMDS clock period. Can be.
  • HDMI In order to transmit audio data and additional data over the TMDS channel, HDMI uses a packet structure. In order to achieve high reliability for audio data and control data, the data may be transmitted as 10-bit words generated using BCH error correction code and error reduction coding.
  • the source device can find out the configuration information and possible functions of the sink device by reading Enhanced Extended Display Identification Data (E-EDID) of the Display Data Channel (DDC) sink device.
  • E-EDID Enhanced Extended Display Identification Data
  • DDC Display Data Channel
  • the E-EDID may also be referred to as EDID information below.
  • the utility line can be used for optional extensions such as HEAC.
  • FIG. 2 illustrates a source device and a sink device in an HDMI system according to an embodiment of the present invention.
  • a device for transmitting video / audio data through HDMI corresponds to the source device 2100, and a device for receiving video / audio data through HDMI corresponds to a sink device 2200.
  • the source device 2100 may include a display unit 2110, a user input interface unit 2120, a video encoding unit 2130, a video encoder 2130, a control unit 2140, an HDMI transmitter 2150, and a memory unit 2160. , At least one of the storage unit 2170, the multimedia unit 2180, or the power supply unit 2190.
  • the sink device 2200 includes an EDID EEPROM 2210, a video decoding unit 2220, a display unit 2230, a user input interface unit 2240, an HDMI receiver 2250, a control unit 2260, a power supply unit 2270. ), A memory unit 2280, or a multimedia unit 2290. In the following descriptions of units performing the same operation will not be duplicated.
  • the source device 2100 represents a physical device for transmitting or streaming content stored in the storage unit to the sink device 2200.
  • the source device 2100 may send a request message to the sink device or receive and process a request message received from the sink device.
  • the source device 2100 may provide a UI that processes and transmits a response message transmitted by the sink device 2200 to the user in response to the transmitted request message, and the source device 2100 may display the display unit 2110. If included, this UI can be provided as a display.
  • the sink device 2200 may receive content from the source device 2100, transmit a request message to the source device 2100, or process a message received from the source device 2100 to transmit a response message.
  • the sink device 2200 may also provide a UI that processes and delivers a response message received from the source device 2100 to the user.
  • the UI may be provided. Can be provided as a display.
  • the source device 2100 and the sink device 2200 may include user input interface units 2120 and 2240 for receiving a user action or input.
  • the user input interfaces 2120 and 2240 may include a remote controller, It may correspond to a voice receiving / recognizing device, a touch input sensing / receiving device, and the like.
  • the memory units 2160 and 2280 represent a volatile physical device in which various kinds of data are temporarily stored.
  • the storage unit 2170 represents a nonvolatile physical device capable of storing various kinds of data.
  • EDID EEPROM 2210 represents an EEPROM that stores EDID information.
  • the above-described memory unit, storage unit, and EDID EEPROM all serve to store data, which may be collectively referred to as a memory unit.
  • the display units 2110 and 2230 represent units for displaying data received through the HDMI or data stored in the content storage, the UI, and the like on the screen under the control of the control unit.
  • the multimedia units 2180 and 2290 perform various kinds of multimedia playback.
  • the multimedia units 21180 and 2290 may be implemented separately from the control units 2140 and 2260, or may be implemented as one physical configuration with the control unit.
  • the power supply units 2190 and 2270 supply power required for the operation of the source device and the sink device and sub units included therein.
  • the HDMI transmitter 2150 is a unit provided in the source device 2100 to transmit and receive data through HDMI.
  • the HDMI transmitter 2150 transmits and receives data including messages such as commands, requests, actions, and responses, as well as audio / video data. .
  • the video encoding unit 2130 compresses video data to be transmitted through the HDMI transmitter 2150.
  • the HDMI receiver 2250 is a unit provided in the sink device 2200 for transmitting and receiving data through HDMI, and performs data transmission and reception including not only audio / video data but also messages such as commands, requests, actions, and responses between devices. .
  • the video decoding unit 2130 decompresses the compressed image data received through the HDMI receiver 2250.
  • channels, data structures, and functions provided by HDMI will be described in more detail.
  • the HDMI system provides a Display Data Channel (DDC) which is a protocol standard for transmitting digital information between a monitor and a computer graphics adapter defined by the Video Electronics Standard Association (VESA).
  • DDC Display Data Channel
  • VESA Video Electronics Standard Association
  • the DDC allows HDMI devices to send display mode information supported by the monitor to the graphics adapter, which can then send video to the monitor accordingly.
  • the VGA standard used four pins (Pin 11, 12, 4, 15) of the analog VGA connector to recognize the monitor type, of which only Pin 11, 12, 4 was used and seven types were used. The monitor type could be recognized. Version contents of the DDC are as follows.
  • EDID Extended Display Identification Data
  • -Pin 12 is used as the data line and 128-byte EDID blocks are continuously sent from the monitor to the computer.
  • pin 12 is the data line on the I2C bus and pin 15 is the clock line on the I2C bus.
  • Pin 9 is used to apply 5V DC power (up to 50mA) from the computer to the monitor to read the EDID stored in the EEPROM even when the monitor is powered off.
  • 8-bit data offset allows for 28 to 256 bytes of EDID storage.
  • Version 1 was established in 199 as a replacement for DDC versions 1 and 2. It allows display information storage capacity of up to 32 Kbytes for use with Enhanced EDID (E-EDID).
  • E-EDID Enhanced EDID
  • E-DDC version 1.1 was enacted in 2004 and includes support for video interfaces such as HDMI in addition to CE devices and VGA.
  • FIG 3 illustrates an EDID structure according to an embodiment of the present invention.
  • the EDID is a data structure including various information about the display device defined in the VESA, and may be transmitted to or read from the source device through the DDC channel.
  • version 1.3 data structures are used in IT display devices, CE display devices, and video interfaces (HDMI).
  • 4 through 5 illustrate an embodiment of an EDID extension block.
  • FIG. 4 illustrates an EDID extension block
  • FIG. 5A illustrates a video data block
  • FIG. 5B illustrates an audio data block
  • FIG. 5C illustrates a speaker allocation data block.
  • the timing information described in the EDID is for IT display devices and may use the EDID 1.3 extension block defined in CEA-861 to indicate timing information of the CE display devices.
  • Version 3 of the CEA Extension Block is defined in the CEA-861B standard and specifies four optional data blocks (Video, Audio, Speaker Assignment, and Vendor Specific).
  • the Short Video Descriptor represents a video identification code defined in CEA-861.
  • the Short Audio Descriptor represents an audio format code defined by CEA-861.
  • the Speaker Allocation Data Block Descriptor of FIG. 5C shows a data block payload defined in CEA-861.
  • FIG. 6 illustrates an HDMI Forum (HF) -Vendor-Specific Data Block (VSDB) according to an embodiment of the present invention.
  • HF HDMI Forum
  • VSDB Video Data Block
  • the HF-VSDB of FIG. 6 is a data block in which vendor-specific data can be defined, and HDMI can use this data block to define HDMI specific data.
  • the HF-VSDB may be included in the E-EDID of the sink device and, if included, in the CEA extension version 3 in the E-EDID of the sink device.
  • Length field The total length of the data block, with a minimum of 7, and a maximum of 31.
  • IEEE OUI field The OUI assigned to the HDMI Forum as an IEEE Organizationally Unique Identifier is 0xC45DD8.
  • Version field The version number of the HF-VSDB (HDMI Forum-VSDB).
  • Max_TMDS_Character_Rate field indicates the maximum TMDS Character Rate supported. Set to 0 if the sink device does not support more than 340 Mcsc.
  • 3D_OSD_Disparity If set to 1, indicates that the Sink device supports receiving 3D_OSD_Disparity Indication.
  • Independent_view field When set to 1, indicates that the sink device supports 3D independent view signaling.
  • LTE_340Mcsc_scramble field If set to 1, it indicates that the sink device supports scrambling at TMDS character rate of less than 340Mcss. And if SCDC_Present is set to 0, this flag should also be set to 0.
  • RR_Capable field If set to 1, indicates that the Sink device can initiate an SCDC read request. And if SCDC_Present is set to 0, this flag should also be set to 0.
  • SCDC_Present field If set to 1, indicates that Sink supports the SCDC function.
  • the decompression capability information of the sink device may be signaled through the HF-VSDB of the EDID, which will be described later.
  • FIG 7 illustrates an HDMI Forum-Vendor Specific InfoFrame (HF-VSIF) according to an embodiment of the present invention.
  • HF-VSIF HDMI Forum-Vendor Specific InfoFrame
  • FIG. 7 (a) shows the HF-VSIF packet header and FIG. 7 (b) shows the HF-VSIF packet contents, which together may form an infoframe.
  • HF-FSIF is one of the infoframes
  • the HF-VSIF packet is provided to support a feature (s) requesting ancillary information for fully identifying the stream content and may be transmitted from the source device to the sink device.
  • the HF-VSIF may be defined for transmission of 3D video and 2160p video.
  • Packet Type field indicates a payload type and HF-VSIF is divided into 0x81.
  • Version field The version number of the HF-VSIF.
  • Length field indicates the length of the payload.
  • -3D_Valid field indicates that 3D video data transmission exists. If set to 1, 3D_F_Structure, 3D_Addiotional_Info_Present, 3D_Meta_Present and 3D_F_Ext_Data fields should be activated.
  • 3D_F_Structure field indicates a transmission format (side-by-side, top-and-bottom, etc.) of 3D video data.
  • -3D_Additional_Info_Present field Set to 1 when 3D_DualView, 3D_ViewDependency and 3D_Preferred2DView information are added.
  • 3D_Disparity_Data_Present field set to 1 when 3D disparity data exists.
  • 3D_Meta_Present field Set to 1 when 3D metadata exists.
  • 3D_F_Ext_Data field Indicates a sub-sampling method according to a transmission format of 3D video data.
  • -3D_Dual_View field Set to 1 when 3D dual view exists.
  • 3D_ViewDependency field indicates a dependency on the coded view of the right or left view.
  • 3D_Preferred2DView field Indicates whether a 3D view of a right 3D view and a left 3D view is more suitable for a 2D view.
  • 3D_DisparityData_Version field Indicates a version of 3D disparity data.
  • 3D_DisparityData_length field indicates the length of 3D disparity data.
  • 3D_DisparityData_1 to 3D_DisparityData_J fields Describes 3D disparity data.
  • 3D_MetaData_type field Indicates a type of 3D metadata.
  • 3D_MetaData_length field indicates the length of 3D metadata.
  • 3D_Metadata_1 ⁇ 3D_Metadata_K fields Describes 3D metadata.
  • SCDC 8 illustrates a Status and Control Data Channel (SCDC) structure according to an embodiment of the present invention.
  • the Status and Control Data Channel corresponds to a point-to-point communication protocol in which data is exchanged between a source device and a sink device.
  • SCDC communication may use the above-described DDC channel (line I2C).
  • SCDC is a one-to-one communication protocol based on I2C serial communication that enables data exchange between an HDMI source device and a sink device.
  • the SCDC includes a mechanism in which a sink device that is an I2C slave requests a status check read from a source device that is an I2C master, and the source device receiving the read device reads the corresponding status from the sink device.
  • the SCDCS (SCDC Structure) is stored in the memory of the sink device and may include data such as the structure of FIG. 8.
  • the R / W represents data of the SCDCS stored in the sink device from the viewpoint of the source device, and whether the source device can read only or both read / write.
  • Sink Version field Displays the version information of the SCDCS compliant sink device. Set to 1.
  • Update_0, Update_1 If there is a change in information (Status, Character Error Detect, etc.) that the sink device should inform the source device, set the corresponding bit to 1.
  • TMDS_Config TMDS Configuration (TMDS_Config) field: If the TMDS_Bit_Clock_Ratio and Scrambling_Enable occupy 1 bit each, and the source device wants to enable the scrambling function of the sink device, set the corresponding bit to 1. Set to 0 if TMDS_Bit_Clock_Ratio is 1/10, or 1 if 1/40.
  • Scrambler Status field sets the bit to 1 when the sink device detects a scrambled control code sequence.
  • Configuration (Config_0) field A field for configuring capability-related information of source and sink devices.
  • RR_Enable field indicating whether a source device supports a read request of a sink device.
  • Status Flags (Status_Flag_0, Status_Flag_1) field: Indicates whether data received through Clock, channel 0, 1, and 2 has been successfully decoded.
  • Err_Det_0 ⁇ 2_L / H fields indicate LSB and MSB of the error counter detected in channels 0-3.
  • Err_Det_Checksum field implemented so that the one-byte sum of the error detection values of the seven registers containing the checksum is zero.
  • FIG 9 illustrates A / V data transmission and reception method through HDMI according to an embodiment of the present invention.
  • the HDMI devices transmit uncompressed A / V data / V data (at least one of audio data and video data) from a source device to a sink device.
  • the source device and the sink device are connected with an HDMI cable (S9000).
  • the source device switches the 5V power line from the low level to the high level and applies a current (S9010).
  • This allows the source device to operate the EEPROM and associated circuits in which the EDID information of the sink device is stored.
  • the sink device may notify the source device that the hot plug detect (HPD) line is switched from the low level to the high level (S9020), and the cable is normally connected and the EDID-related circuit is activated to access the EDID information.
  • HPD hot plug detect
  • the source device may transmit a read request for EDID information to the sink device through the DDC (S9030).
  • the sink device may transmit EDID information stored in the EEPROM through the DDC (S9040).
  • the EDID information may be transmitted as the VSDB described above.
  • the sink device parses the received EDID information to determine operation parameters (timing, format, etc.) of the A / V data to be transmitted to the sink device (S9050), and relates to uncompressed A / V data to be transmitted.
  • the determined operating parameter may be transmitted to the source device (S9060).
  • the operating parameter may be transmitted as HF-VSIF.
  • the source device may transmit uncompressed A / V data controlled by the determined operating parameter to the sink device (S9070).
  • the source device may compress the video into a format compressed within the bandwidth supported by the physical layer. You have to send data. However, to do this, the sink device needs to know whether the source device has the ability to decompress the video data compressed and sent, and the source device must also inform whether the video data transmitted is in a compressed format.
  • a method of transmitting and receiving compressed video data through HDMI will be described in more detail.
  • an example of video data will be described. However, the description and the invention can be equally applied to audio data as well as video data.
  • FIG. 10 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention.
  • steps S10000 to S10030 are performed in the same manner as step S90030 in step S9000 of FIG. 9, and descriptions thereof will not be repeated.
  • FIG. 10 includes operations added to the flowchart of FIG. 9, and the same description as in FIG. 9 may be applied to the description of FIG. 10 without being described again in FIG. 10.
  • the sink device receiving the EDID information reading request may transmit EDID information including decompression capability information to the source device through the DDC (S10040).
  • the decompression capability information transmitted includes information about whether the sink device can process compressed A / V data, and if so, what operational parameters can be used to process compressed A / V data. It may include.
  • the decompression capability information may include whether or not the decompression function of the sink device is supported and related characteristic information. As described above, this EDID information can be read from the EEPROM and transmitted as the HF-VSDB.
  • the sink device parses the received EDID information to determine operation parameters (timing, format, etc.) of the A / V data to be transmitted to the sink device (S10050), and relates to uncompressed A / V data to be transmitted.
  • the determined operating parameter may be transmitted to the source device (S10060).
  • the operating parameter transmitted includes compression metadata.
  • Compression metadata is information necessary to decompress compressed A / V data in a sink device, and represents characteristic information of compressed video data.
  • the operating parameter may be transmitted as HF-VSIF.
  • the source device may transmit the compressed A / V data controlled by the determined operating parameter to the sink device (S10070).
  • FIG. 11 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and in particular, a method of controlling a decompression function of a sink device by a source device.
  • FIG. 11 in addition to the description of FIG. 10, when the type of data transmitted from the source device is changed from uncompressed data to compressed data or from compressed data to uncompressed data, FIG. how to enable or disable it.
  • the source device determines to compress and transmit the corresponding A / V data, and activates the decompression function on the sink device. You can request
  • the source device may transmit uncompressed A / V data according to the operation parameters determined by the sink device (S11000).
  • the user may change the video content into the 8K video content in the source device.
  • 8K video content may be difficult to transmit uncompressed / lossless in the bandwidth of the currently connected HDMI cable.
  • the source device may decide to compress and transmit the 8K video (S11020).
  • 8K video is an embodiment, and the source device can determine whether the A / V data to be transmitted is capable of lossless transmission without compression in the bandwidth of the currently connected HDMI cable and, if lossless transmission is difficult, decide to change the transmission method to compression transmission. have.
  • the source device may request that the sink device activate the decompression function (S11030).
  • the sink device may activate the decompression function (S11040) and inform the source device that the decompression function is activated.
  • the source device may transmit operation parameters including compression metadata to the sink device (S11050), and transmit the compressed A / V data controlled by the transmitted compression parameters to the sink device (S11060).
  • the source device may determine the transmission of the uncompressed video data for various reasons (S11070). For example, if uncompressed transmission is possible over the bandwidth of HDMI, such as lowering the resolution of the video being viewed by the user or changing the video content of the receiving / streaming itself to a lower resolution, the source device may decide to transmit uncompressed video. Can be.
  • the source device may request the deactivation of the decompression function to the sink device (S11090).
  • the sink device may deactivate the decompression function according to the request of the source device (S11090), and may inform the source device that the decompression function is deactivated.
  • the source device can now transmit uncompressed A / V data to the sink device (S11100).
  • the above request for activation and deactivation of the decompression function for the sink device of the source device may be performed using SCDCS, which will be described later.
  • FIG. 12 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and in particular, illustrates a method in which a source device activates a decompression function of a sink device using SCDCS.
  • FIG. 12 is a method of enabling / disabling a decompression function of a sink device through SCDC in FIG. 11, and show steps S11030, S11040, S11080, and S11090 of FIG. 11 as SCDC data communication.
  • the description of the same steps S12000, S12010, S12020 and S12050 of steps S11000, S11010, S11020 and S11050 of FIG. 11 will be omitted.
  • decompression activation information is defined in the SCDCS to activate / deactivate the decompression function.
  • the decompression activation information may be defined as a flag or a bit as in FIG. 12 (b).
  • Information (DC_Enable) included in bit 1 of FIG. 12 (b) indicates decompression activation information included in the SCDCS.
  • the decompression activation information is defined in a register at offset 0x30 of the SCDCS, which may be defined as bit1. When the value of the decompression activation information is set to 1, it may indicate that the decompression function is activated, and when it is set to 0, the decompression function is deactivated.
  • the source device can activate / deactivate the decompression function of the sink device by writing a value of 1 or 0 to the value of the decompression enable information.
  • the decompression enable information may be defined as 1 bit in the Config_0 information portion of the SDCDS.
  • the source device must activate the decompression function of the sink device to transmit the compressed video.
  • the source device may transmit a SCDC write message for activating the decompression function (S12030).
  • Figure 12 (a) shows an embodiment of the SCDC write message to activate the decompression function.
  • the sink device may set a value of the decompression activation information according to the received SCDC write message (S12040).
  • the sink device may set a bit value of the corresponding address according to the received SCDC write message. That is, the position values of bit 0 and bit 1 may be set to 1 in the SCDCS of FIG. 12 (b).
  • the sink device may activate the decompression function of the video decoding unit according to the changed decompression activation information.
  • the source device requests to deactivate the decompression function (S11080), and the sink device deactivates the decompression function (S11090).
  • the source device transmits an SCDC write message for writing the value of the decompression activation information to 0, and the sink device sends a value of the decompression activation information according to the received SCDC write message. Can be done by setting to zero.
  • the sink device may deactivate the decompression function of the video decoding unit according to the value of the changed decompression activation information.
  • the RR_Enable information may be set to 1 when the source device supports a read request and 0 when the source device supports only polling of an update flag. In the embodiment of FIG. 12, the RR_Enable information is set to 1 to indicate that the source device supports the read request.
  • FIG. 13 is a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention, and particularly, illustrates a method in which a sink device notifies a source device of a state change of a decompression function.
  • FIG. 10 when a state change (for example, buffer overflow / underflow) occurs while performing decompression at the sink device receiving the compressed A / V data, FIG. Indicates how to tell the device.
  • the source device may read information about the state change, change the operation parameter, and transmit compressed A / V data according to the changed operation parameter.
  • the source device may transmit compressed A / V data according to the operation parameters determined to the sink device (S13000).
  • the sink device may receive and decompress the compressed A / V data to provide the content.
  • a state change may occur while the sink device is executing decompression (S13010).
  • this state change may correspond to a buffer overflow or a buffer underflow of the video decoding unit.
  • the sink device may inform the source device of the state change of the decompression function (S13020).
  • the source device knows the occurrence of the state change from the sink device, and thus can read detailed information / additional information on the state change from the sink device (S13030).
  • the source device may change the operation parameter based on the read detailed information in operation S13040, and transmit the changed operation parameter to the sink device in operation S13050.
  • the source device may transmit the compressed A / V data controlled by the changed operating parameter. Determination of operating parameters of the source device, transmission of operating parameters including compressed metadata, and compressed A / V data transmission may be performed as in steps S10050 to S10070 of FIG. 10.
  • the state change generated during the execution of the above-described decompression function may inform the source device by using the SCDCS, which will be described later.
  • FIG. 14 illustrates a method of transmitting / receiving compressed A / V data through HDMI according to an embodiment of the present invention.
  • a sink device notifies the source device of a state change of a decompression function using SCDCS.
  • the sink device updates the state change to notify the source device, and the source device reads the changed state change using the SCDC.
  • the source device may transmit uncompressed A / V data according to operating parameters determined by the sink device (S14000).
  • the sink device may write this to the SCDCS as status change information and notify the source device of the sink device through the SCDC.
  • the state change information may be located in the Status_Flag_1 portion of the SCDCS as shown in FIG. 14 (c).
  • the state change information includes buffer underflow information indicating whether a buffer underflow has occurred, buffer overflow information indicating whether a buffer overflow has occurred, or chunk length indicating whether the chunk size specified in the HF-VSIF is different from the chunk size of the received video data. It may include at least one of the error information.
  • the state change information may be located at bits 0 to 2 of offset 0x41 in the SCDCS as shown in FIG. 14 (c). The embodiment and description of the fields corresponding to / included in the state change information are as follows.
  • RC_Buffer_Underrun field Set to 1 when an underflow occurs in the RC buffer.
  • RC_Buffer_Overflow field Set to 1 when overflow occurs in the RC buffer.
  • Chunk_Length_Error field Can be set to 1 when the chunk size specified in HF-VSIF and the received chunk size are different.
  • the sink device may set the value of the state change information of the SCDCS corresponding to the changed state to 1 (S14010). As shown in FIG. 14C, when the chunk size is different, when the buffer overflow occurs, when the buffer underflow occurs, the sink device may set a value of the corresponding state change information field to 1, respectively.
  • the sink device may transmit a SCDC Read Request message to the source device (S14020).
  • the SCDC read request message is a message requesting the connected source device to read the update flag.
  • the sink device sends an SCDC read request message to the source device to inform the source device of the updated status information.
  • the source device may read state change information (S14030), which may be performed by reading an update through the SCDC (S14030-1) and reading state change information corresponding to the update (S14030-2).
  • the source device may read the SCDC update information by transmitting the SCDC update read request message of FIG. 14A (S14030-1).
  • the SCDC update read request message may include slave address information and register address information to be read.
  • the update read message is a message requesting to read the register values of Update_0 and Update_1 of the sink device whose slave address is 0x54.
  • the sink device can cause the source device to read it by writing the register value to a message received on the bus.
  • the source device confirming the update can read the state change information of the SCDCS by transmitting the SCDC state change information read request message of FIG. 14B (S14030-2).
  • the SCDC state change read request message may include slave address information and register address information to be read.
  • the read state change information message is a message requesting to read state change information, which is a register value separated by 0x41 of a sink device having a slave address of 0x54.
  • the corresponding data may be at least one of 0x01, 0x02 or 0x04 in each case since the values of bit 0, bit 1, and bit 2 may be changed in register values separated by 0x41.
  • the sink device may cause the source device to read state change information by writing the corresponding register value to a message received on the bus.
  • the decompression capability information is added to the HF-VSDB illustrated in FIG. 6.
  • the HF-VSDB of FIG. 15 may include decompression capability information as one of EDID information, and the decompression capability information may include fields indicating decompression support and decompression capability of the sink device. May contain ..
  • a new HF-VSDB is further defined, and a version number of a version field may be set to 2 to distinguish it from an earlier version of HF-VSDB.
  • a version number of a version field may be set to 2 to distinguish it from an earlier version of HF-VSDB.
  • the sink device can process the compressed A / V data
  • at least one bit of bits 5 to 4 of the byte 6 block of the HF-VSDB and bits 7 to 3 of the byte 7 block may be used.
  • the corresponding bit is set to 1, it may indicate that the sink device can process (receive / decompress) the compressed video data, and if it is 0, it may indicate that the compressed video cannot be processed.
  • the decompression capability information may include at least one of the following fields shown in FIG. 15.
  • compression_version_major field Indicates the major version of the compression algorithm.
  • compression_version_minor field Indicates the minor version of the compression algorithm.
  • rc_buffer_block_size field indicates the size of the rc buffer block of the decoder device's decoder.
  • rc_buffer_size field indicates the rc buffer size of the decoder device's decoder.
  • slice capabilities (1 slice per line, 2 slice per line, 4 slice per line) field Indicates the number of supported slices per line.
  • -line_buffer_bit_depth field indicates the size of buffer allocated per line.
  • block prediction support field indicates presence or absence of block prediction support in the sink device. This field may be located in one of 5 to 4 bits of byte 6 or 7 to 3 bits of byte 7.
  • max_bits_per_pixel field indicates a maximum number of bits per pixel supported by a decoder.
  • color depth capabilities (CD_6, CD_8, CD_10, CD_12) field: Indicates the color depths supported by the sync device.
  • the HF-VSIF of FIGS. 16 and 17 may include compression metadata as one of the infoframes.
  • the HF-VSIF of FIGS. 16 and 17 may be referred to as an infoframe.
  • a new HF-VFIF is further defined, and a version number of a version field may be set to 2 to distinguish it from an earlier version of HF-VSIF.
  • the source device transmits the compressed video whether the video being transmitted is the compressed video may be signaled through at least one of bits 7 to 1 of PB5 (packet byte 5) to inform the sink device.
  • PB5 packet byte 5
  • VSIF in HDMI can be limited to 27 bytes of packet bytes per packet.
  • video compression metadata may need to be divided into a plurality of packets and transmitted.
  • a flag indicating whether or not the current packet is the last packet indicating video compression metadata is needed, and as an embodiment, one of reserved bits located in PB5 may be used for this purpose. In other words, if a message end (End of Message) flag pit indicating the end of the delivery data is added to one of the reserved bits of the PB5, and the corresponding bit is set to 1, it may indicate that the message is the last delivery packet of the message.
  • video compression related metadata may be located after 3D_Metadata. However, if the 3D_Valid field value is 0, video compression related metadata may be located from PB6. (If the value of the 3D_Valide field is 1, the packet byte is defined as 3D related information. If the video compression bit is enabled, the packet byte can be defined as video compression metadata.)
  • Compressed metadata may include at least one of the following fields shown in FIGS. 16 to 17.
  • compression_version_major field Represents the major version of the compression algorithm.
  • compression_version_minor field Indicates the minor version of the compression algorithm.
  • pps_identifier field used as an application-specific identifier to distinguish between different PPS tables.
  • bits_per_component field indicates the number of bits allocated to each component (e.g. R, G and B, or Y, Cb and Cr) of uncompressed video input to an encoder that performs compression.
  • Linebuf_depth field indicates the line buffer bit depth used to generate the stream.
  • Block_pred_enable field indicates whether the decoder selects block prediction (BP) or MMAP. 0 indicates that BP is not used.
  • Convert_rgb field indicates whether the uncompressed video was RGB or YCbCr. 0 indicates YCbCr, and 1 indicates the decoder changed from YCoCg-R to RGB.
  • Enable_422 field Indicates whether 4: 2: 2 sampling is used.
  • Enable_420 field Indicates whether 4: 2: 0 sampling is used.
  • vbr_enable field indicates whether the VBR mode is on / off if supported by the decoder and the transport.
  • Bits_per_pexel field indicates the number of bits per pixel of the encoded video of the encoder performing compression.
  • Pic_height indicates the size of a picture in pixels. It is recommended that the number is an integer multiple of Slice_width and slice_height.
  • sub_sampling_format field indicates a subsampling method of uncompressed video input to an encoder that performs compression.
  • Slice_height, Slice_width field indicates the size of each slice.
  • Chunk_size field indicates the byte size of the chunk used for slice multiplexing.
  • initial_xmit_delay field indicates the time of pixel time to wait in the rate buffer of the encoder before transmission.
  • initial_dec_delay field Indicates the number of pixel times the decoder decodes and stores in the rate buffer before starting pixel output.
  • initial_scale_value field indicates the initial value for rcXformScale used at the beginning of the slice.
  • Scale_increment_interval field represents the number of group times between rxXformScale factors at the end of the slice.
  • Scale_decrement_interval field indicates the number of group times between rxXformScale factors at the beginning of a slice.
  • first_line_bpg_offset field Indicates the number of additional bits allocated for each group in the first line of the slice.
  • Nfl_bpg_offset field Indicates the number of bits to release allocation for each group for the group after the first line of the slice.
  • Slice_bpg_offset field Indicates the number of bits to deallocate for each group to enforce slice constraints while programmatic initial_offset is allowed.
  • Initial_offset field indicates an initial value for rcXformOffset.
  • Final_offset field indicates the maximum value of the end-of-slice value for the rcXformOffset.
  • Flatness_min_qp field indicates the minimum value of the QP in which flatness is signaled and a flatness QP correction is generated.
  • Flatness_max_qp field indicates the maximum value of the QP in which the flatness is signaled and the flatness QP correction is generated.
  • Rc_model_size field indicates the number of bits of the RC model.
  • Rc_edge_factor field indicates the ratio of current activity / previous activity to check for the existence of an edge.
  • Rc_quant_incr_limit0 field Indicates a QP threshold used for short-term rate control.
  • Rc_quant_incr_limit1 field Indicates a QP threshold used for short-term rate control.
  • Rc_tgt_offset_hi field indicates an upper end of a variable range of target bits per group allowed by short-term rate control.
  • Rc_tgt_offset_lo field indicates a low end of a variable range of target bits per group allowed by short-term rate control.
  • Rc_range_parameters [15] field For each of the 15 ranges in the RC model, range_min_qp (5 bits), range_max_qp (5 bits) and rage_bpg_offset (6 bits).
  • 16 and 17 illustrate an embodiment in which compressed metadata of a video is added and transmitted using HF-VSIF among infoframes.
  • a method of defining and using a separate infoframe for transmitting compressed metadata instead of adding compressed metadata to the HF-VSIF will be described.
  • InfoFrame is a data structure that is transmitted from the source device to the sink device via HDMI.
  • the infoframe may deliver auxiliary information about a video stream, an audio stream, or a source device.
  • the infoframe includes a packet header and packet content.
  • Table 1 shows packet types transmitted and received on HDMI.
  • Packet type value Packet type 0x00 Null 0x01 Audio Clock Regeneration 0x02 Audio Sample 0x03 General Control 0x04 ACP Packet 0x05 ISRC1 packet 0x06 ISRC2 packet 0x07 One bit audio sample 0x08 DST audio packet 0x09 High Bitrate Audio Stream Packet 0x0A Gamut Metadata Packet 0x80 + infoframe type Infoframe Packet 0x81 Vendor-Specific Infoframe 0x82 AVI Infoframe 0x83 Source Product Descriptor Infoframe 0x84 Audio infoframe 0x85 MPEG Source Infoframe 0x86 Video Compression Infoframe 0x0B 3D audio sample packet (L-PCM format only) 0x0C 1-bit 3 D audio sample packet 0x0D Audio metadata packet 0x0E Multi Stream Audio Sample Packets 0x0F 1-bit multi-stream audio sample packet
  • the HF-VSIF of FIGS. 16 and 17 may have a packet type value of 0x81.
  • the present invention can send compression related metadata to HF-VSIF as shown in FIG. 16 and FIG. 17, and as another embodiment, may separately define a separate infoframe for transmitting compressed metadata. have.
  • An infoframe including newly defined compression metadata in the present invention may be referred to as a video compression infoframe, and a packet type value of 0x86 may be assigned as shown in Table 1.
  • packet bytes HB0 to HB2 indicate packet header bytes
  • PB1 to 27 indicate packet content bytes.
  • byte HB0 represents the packet type.
  • Byte HB1 represents the major and minor version of the compression algorithm used by the encoder to encode the video data.
  • byte HB2 one of the reserved bits located in the header is allocated an End of Message bit indicating the end of the delivered data, and when the corresponding bit is set to 1, it may indicate that the last delivered packet.
  • the size of the packet byte that can be transmitted in one packet may be limited to 28 bytes in the infoframe. Therefore, video compression metadata may be divided into three parts and delivered in three packets as shown in FIGS. However, this is an embodiment, and the number and contents of the divided packets may be changed according to the packet capacity.
  • the video compression metadata conveyed in FIGS. 18 to 20 is the same as the information conveyed in FIGS. 16 and 17, and the description of the aforementioned fields also applies to the fields of FIGS. 18 to 20.
  • the present invention provides a decompression function support and a decompression characteristic information definition of the sink device, and a method for delivering it to the source device, a compression characteristic information definition of the source device and a method for delivering it to the sink device, and the decompression function state of the sink device
  • the sink device transmits to the source device via the DDC the VSDB of the E-EDID with support for decompression of the sink device and related characteristic information.
  • the source device compresses the image based on the relevant characteristic information and transmits the compressed image to the source device before sending the compressed image by including the characteristic information of the compressed image in the VSIF. .
  • the limited packet body length when the packet body length (28 bytes) of the existing limited VSIF is exceeded, the limited packet body length may be increased to display all the compression characteristic information in one VSIF packet.
  • compression characteristic information may be divided and expressed according to the existing limited VSIF packet body length, and segmentation information (start, continue, and end of the divided packet) of the divided VSIF packet may be expressed in the VSIF packet header or body.
  • the decompression function can be activated by setting the bit related to the decompression function defined in the SCDCS of the sink device to 1 through the SCDC.
  • the decompression function is disabled by setting the decompression function bit defined in the SCDCS of the sink device to 0 through the SCDC before sending the uncompressed video. It is possible.
  • a field indicating the status information is defined in the SCDCS of the sink device, and when there is a change in the corresponding field, the SCDC notifies that the source device has a state change.
  • the source device receiving this can access the field indicating the corresponding state information defined in the SCDCS through the SCDC to read detailed information on the changed state.
  • the present invention is used in the field of HDMI.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

HDMI를 사용한 싱크 기기의 데이터 송수신 방법이 개시된다. 본 발명에 따른 HDMI(High Definition Media Interface) 소스 기기의 데이터 송수신 방법은, 싱크 기기가 연결되면 상기 싱크 기기로 EDID(Extended Display Data Channel) 정보 판독을 요청하는 단계; 상기 싱크 기기로부터 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID 정보를 수신하는 단계; 상기 EDID 정보에 기초하여 결정된 동작 파라미터 정보를 전송하는 단계로서, 상기 동작 파라미터 정보는 압축 메타데이터를 포함하는, 전송 단계; 및 상기 압축된 비디오 데이터를 전송하는 단계를 포함한다.

Description

HDMI를 사용한 데이터 송수신 기기 및 방법
본 발명은 HDMI(High Definition Multimedia Interface)를 사용하는 데이터 송수신 장치 및 방법에 관한 것으로, 특히 HDMI를 통해 고용량의 데이터를 압축하여 전송하고 수신된 데이터를 압축해제하는, HDMI를 사용하는 데이터 송수신 장치 및 방법에 관한 것이다.
HDMI는 개인용 컴퓨터와 디스플레이의 인터페이스 표준 규격인 DVI(Digital Visual Interface)를 AV 전자제품용으로 개발한 인터페이스/규격으로, HDMI는 영상/음성을 압축하지 않고 플레이어에서 디스플레이 기기 측으로 전송하므로 소스(source) 기기와-싱크(sink) 기기간의 지연(Latency)이 거의 없으며, 별도의 디코더 칩이나 소프트웨어를 필요로 하지 않아 포맷 호환성이 높다. 또한 비디오 신호, 오디오 신호, 및 컨트롤 신호가 케이블 하나로 전송되기 때문에 복잡했던 AV 기기들의 배선을 간단히 할 수 있고, 불법 복제 방지를 위한 암호와 기술(HDCP: High-bandwidth Digital Content Protection)을 지원하여 저작권 보호 기능까지 제공할 수 있다.
디스플레이 기기의 발전 및 사용자들의 고해상도 영상 시청의 필요로 인해, 영상 컨텐트의 용량은 점점 커지고 있다. 이미 풀-HD를 지나 울트라-HD(U-HD) 급의 해상도를 지원하는 디스플레이 기기가 출시되고 있다. U-HD는 4K 해상도 또는 UD 해상도라고 부르기도 하며, 화소가 풀-HD의 경우보다 4배 높은 해상도(3840x2160)로 촬영되어 매우 높은 선명도의 영상을 제공할 수 있다.
UHD TV의 보급이 시작되면서 UHD TV에서 생생한 현장감 및 몰입감을 시청자에게 제공해 주기 위해 UHD 켄텐츠를 다양한 저장 매체 및 서비스를 통해 보급하고 있다. 시청자가 UHD 컨텐츠를 감상하기 위한 방법으로 UHD TV와 셋탑 박스, 블루레이 디스크 플레이어 등 외부 소스 기기를 HDMI와 같은 유선 비디오 인터페이스로 연결하여 무압축된 비디오를 감상할 수 있다. 하지만 UHD 해상도가 8K 이상으로 높아지게 되면 기존 유선 비디오 인터페이스의 물리적 한계로 인해 무압축된 비디오를 전송할 수 없는 문제가 발생하게 된다. 이를 극복하기 위해 소스 기기에서 무손실로 압축된 영상을 전송하고 싱크 기기에서 압축 해제하는 방안에 대해 연구가 진행되고 있다.
본 발명에서는 소스 기기와 싱크 기기간 압축 및 압축 해제 특성 정보 교환, 압축 해제 기능 동작 제어 및 상태 변화 정보 전송 방법을 제안함으로써 압축 특성 정보를 싱크 기기에 정확히 전달하고 이를 바탕으로 싱크 기기는 압축 해제를 정확히 함으로써 시청자에게 주어진 UHD 컨텐츠를 최적의 환경에서 시청할 수 있는 환경을 제공하게 된다.
상술한 기술적 과제를 해결하기 위하여, 본 발명에 따른 HDMI(High Definition Media Interface)를 사용하여 압축된 비디오 데이터를 전송하는 소스 기기의 데이터 송수신 방법은, 싱크 기기가 연결되면 상기 싱크 기기로 EDID(Extended Display Identification Data) 판독을 요청하는 단계; 상기 싱크 기기로부터 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 수신하는 단계; 상기 EDID에 기초하여 결정된 동작 파라미터 정보를 전송하는 단계로서, 상기 동작 파라미터 정보는 압축 메타데이터를 포함하는, 전송 단계; 및 상기 압축된 비디오 데이터를 전송하는 단계를 포함한다.
또한, 본 발명에 따른 소스 기기의 데이터 송수신 방법에 있어서, 상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 수신된다.
또한, 본 발명에 따른 소스 기기의 데이터 송수신 방법에 있어서,상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 전송된다.
또한, 본 발명에 따른 소스 기기의 데이터 송수신 방법은, 상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화시키는 단계를 더 포함하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행된다.
또한, 본 발명에 따른 소스 기기의 데이터 송수신 방법은, 상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우 상기 싱크 기기의 SCDCS에 포함된 상태 변화 정보를 판독하는 단계를 더 포함한다.
상술한 기술적 과제를 해결하기 위하여, 본 발명에 따른 HDMI를 사용하여 압축된 비디오 데이터를 전송하는 소스 기기는, HDMI를 통해 데이터를 송수신하는 HDMI 송신기; 상기 HDMI를 통해 전송하는 비디오 데이터을 압축하는 비디오 인코딩 유닛; 및 상기 HDMI 송신기 및 상기 비디오 인코딩 유닛을 컨트롤하는 컨트롤 유닛을 포함하며, 상기 소스 기기는, 싱크 기기가 연결되면 상기 싱크 기기로 EDID(Extended Display Identification Data) 판독을 요청하고, 상기 싱크 기기로부터 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 수신하고, 상기 EDID에 기초하여 결정된 동작 파라미터 정보를 전송하며, 상기 동작 파라미터 정보는 압축 메타데이터를 포함하고, 상기 압축된 비디오 데이터를 전송한다.
상술한 기술적 과제를 해결하기 위하여, HDMI(High Definition Media Interface))를 사용하여 압축된 비디오 데이터를 수신하는 싱크 기기의 데이터 송수신 방법은, 연결된 소스 기기로부터 EDID(Extended Display Identification Data) 판독을 요청받는 단계; 상기 소스 기기로 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 전송하는 단계; 상기 소스 기기로부터 압축 메타데이터를 포함하는 동작 파라미터 정보를 수신하는 단계; 및 상기 압축된 비디오 데이터를 수신하는 단계를 포함한다.
또한, 본 발명에 따른 싱크 기기의 데이터 송수신 방법에 있어서, 상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 전송된다.
또한, 본 발명에 따른 싱크 기기의 데이터 송수신 방법에 있어서, 상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 수신된다.
또한, 본 발명에 따른 싱크 기기의 데이터 송수신 방법은, 상기 소스 기기에 의해 상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화하는 단계를 더 포함하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행된다.
또한, 본 발명에 따른 싱크 기기의 데이터 송수신 방법은, 상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우, 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 상태 변화 정보를 기입하고, 상기 소스 기기로 판독 요청 메시지를 전송하는 단계를 더 포함한다.
상술한 기술적 과제를 해결하기 위하여, 본 발명에 따른 HDMI(High Definition Media Interface)를 사용하여 압축된 비디오 데이터를 수신하는 싱크 기기는, HDMI를 통해 송수신하는 HDMI 수신기; 상기 HDMI를 통해 수신하는 비디오 데이터을 압축해제하는 비디오 디코딩 유닛; 및 HDMI 수신기 및 상기 비디오 디코딩 유닛을 컨트롤하는 컨트롤 유닛을 포함하며, 상기 싱크 기기는, 연결된 소스 기기로부터 EDID(Extended Display Identification Data) 판독을 요청받고, 상기 요청에 따라 상기 소스 기기로 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 전송하고, 상기 소스 기기로부터 압축 메타데이터를 포함하는 동작 파라미터 정보를 수신하고, 상기 압축된 비디오 데이터를 수신한다.
본 발명에 따르면, HDMI를 통해 압축된 A/V 데이터(오디오 데이터 또는 비디오 데이터 중 적어도 하나)를 전송함으로써 매우 높은 해상도의 컨텐츠까지 HDMI로 지원이 가능하게 된다.
또한, 본 발명에 따르면 소스 기기가 EDID 정보를 통해 싱크 기기가 압축해제 능력이 있는지를 알 수 있으므로, 싱크 기기의 종류에 따라 압축한 비디오 데이터 또는 비압축 비디오 데이터를 선별하여 전송할 수 있다.
또한, 본 발명에 따르면 소스 기기가 비디오 데이터를 압축하는데 사용한 압축 속성을 나타내는 압축 메타데이터를 전송함으로써, 싱크 기기에서 적절한 방법으로 압축된 비디오 데이터를 압축해제할 수 있다.
또한, 본 발명에 따르면 소스 기기가 압축된 비디오 데이터를 전송하거나, 비압축된 비디오 데이터를 전송하는 경우, SCDCS를 통해 싱크 기기의 압축해제 기능을 활성화/비활성화할 수 있다. 따라서 싱크 기기의 압축해제 기능을 사용자가 설정변경하지 않아도 소스 측에서 비디오 데이터의 타입에 따라 싱크 기기 설정을 변경할 수 있어 사용자 측 불편함을 해소할 수 있다.
또한, 본 발명에 따르면 싱크 기기에서 압축해제 기능에 상태 변경이 발생한 경우 이를 SCDCS를 통해 소스 기기에게 알려 소스 기기에서 변경된 상태에 따라 동작 파라미터를 변경하여 대처할 수 있다.
도 1은 본 발명의 일 실시예에 따른 HDMI 시스템 및 HDMI 시스템에 포함된 데이터 송수신 채널들을 나타낸다.
도 2는 본 발명의 실시예에 따른 HDMI 시스템에서, 소스 기기 및 싱크 기기를 나타낸다.
도 3은 본 발명의 실시예에 따른 EDID 스트럭처를 나타낸 도면이다.
도 4 내지 도 5는 EDID 익스텐션 블록의 실시예를 나타낸다.
도 6은 본 발명의 실시예에 따른 HF(HDMI Forum)-VSDB(Vendor- Specific Data Block)을 나타낸다.
도 7은 본 발명의 실시예에 따른 HF-VSIF(HDMI Forum-Vendor Specific InfoFrame)을 나타낸다.
도 8은 본 발명의 실시예에 따른 SCDC(Status and Control Data Channel) 스트럭처를 나타낸다.
도 9는 본 발명의 실시예에 따른 HDMI를 통한 A/V 데이터 송수신 방법을 나타낸다.
도 10은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법을 나타낸다.
도 11은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 소스 기기에 의한 싱크 기기의 압축해제 기능을 제어하는 방법을 나타낸다.
도 12는 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 SCDCS를 사용하여 소스 기기가 싱크 기기의 압축해제 기능을 활성화하는 방법을 나타낸다.
도 13은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 싱크 기기가 소스 기기로 압축 해제 기능의 상태 변화를 알리는 방법을 나타낸다.
도 14는 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 SCDCS를 사용하여 싱크 기기가 압축해제 기능의 상태변화를 소스기기로 알리는 방법을 나타낸다.
도 15는 본 발명의 다른 실시예에 따른 HF-VSDB를 나타낸다.
도 16 및 도 17은 본 발명의 다른 실시예에 따른 HF-VSIF를 나타낸다.
도 18 내지 도 20은 본 발명의 실시예에 따른 비디오 압축 인포프레임을 나타낸다.
본 발명의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 본 발명의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 본 발명의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.

도 1은 본 발명의 일 실시예에 따른 HDMI 시스템 및 HDMI 시스템에 포함된 데이터 송수신 채널들을 나타낸다.
HDMI를 사용하여 비디오/오디오/컨트롤 데이터를 송수신하는 기기들을 함께 HDMI 시스템이라고 지칭할 수 있으며, HDMI 시스템은 소스 기기(1010)와 싱크 기기(1020) 및 HDMI 케이블을 포함할 수 있다. HDMI 시스템에서, HDMI를 통해 비디오/오디오 데이터를 전송하는 기기가 소스기기(1010)에 해당하고, HDMI를 통해 비디오/오디오 데이터를 수신하는 기기가 싱크 기기(1020)에 해당하며, 두 기기를 연결하여 데이터 송수신을 지원하는 HDMI 케이블이 제공된다.
도 1에서와 같이, HDMI 케이블 및 커넥터들은 TMDS(Transition Minimized Differential Signaling) 데이터 채널 및 TMDS 클럭 채널을 제공하는 4개 채널의 페어링을 수행할 수 있다. TMDS 데이터 채널들은 비디오 데이터, 오디오 데이터 및 부가(auxiliary) 데이터를 전달하는데 사용될 수 있다.
추가로, HDMI 시스템은 VESA(Video Electronics Standards Association) DDC(Display Data Channel)를 제공한다. DDC는 하나의 소스 기기와 하나의 싱크 기기간의 구성(Configuration) 및 상태(status) 정보 교환에 사용된다. CEC 프로토콜은 사용자 환경의 다양한 오디오비주얼 제품들 간의 하이-레벨의 컨트롤 기능을 제공할 수 있으며, 옵셔널(optional)하게 사용될 수도 있다. 또한, 옵셔널 HEAC(HDMI Ethernet and Audio Return Channel)는 TMDS로부터 반대 방향에서 ARC(Audio Return Channel) 및 연결된 기기들 간의 이더넷(Ethernet) 호환 데이터 네트워킹을 제공할 수도 있다.
비디오 데이터, 오디오 데이터 및 부가 데이터는 3개의 TMDS 데이터 채널을 통해 전송/수신될 수 있다. TMDS 클록은, 통상적으로 비디오 픽셀 레이트를 운용(run)하며, TMDS 클럭 채널을 통해 전송된다. TMDS 클록은 HDMI 수신기에서 3개의 TMDS 데이터 채널들에서의 데이터 리커버리(recovery)를 위한 기준 주파수(frequency reference)로서 사용될 수 있다. 소스 기기에서, TMDS 데이터 채널 당 8비트의 데이터는 10비트의 DC 밸런싱된, 트랜지션(transition)이 최소화된 시퀀스로 변환되어, TMDS 클럭 주기(period) 당 10 비트의 레이트(rate)로 시리얼하게 전송될 수 있다.
TMDS 채널을 통해 오디오 데이터 및 부가 데이터를 전송하기 위해, HDMI는 패킷 구조를 사용한다. 오디오 데이터 및 컨트롤 데이터를 위한 높은 신뢰도(reliability)를 달성하기 위해, 데이터는 BCH 에러 정정 코드 및 에러 감소 코딩을 사용하여 생성되는 10비트의 워드로서 전송될 수 있다.
소스 기기는 DDC(Display Data Channel) 싱크 기기의 E-EDID(Enhanced Extended Display Identification Data)를 판독하여 싱크 기기의 구성 정보 및 가능한 기능을 알아낼 수 있다. E-EDID는 이하에서 EDID 정보라고 지칭할 수도 있다.
유틸리티 라인은 HEAC와 같은 옵셔널한 확장 기능에 사용될 수 있다.

도 2는 본 발명의 실시예에 따른 HDMI 시스템에서, 소스 기기 및 싱크 기기를 나타낸다.
HDMI 시스템에서, HDMI를 통해 비디오/오디오 데이터를 전송하는 기기가 소스기기(2100)에 해당하고, HDMI를 통해 비디오/오디오 데이터를 수신하는 기기가 싱크 기기(2200)에 해당한다.
소스 기기(2100; source device)는 디스플레이 유닛(2110), 사용자 입력 인터페이스 유닛(2120), 비디오 인코딩 유닛(2130; Video Encoder), 컨트롤 유닛(2140), HDMI 송신기(2150), 메모리 유닛(2160), 스토리지 유닛(2170), 멀티미디어 유닛(2180), 또는 파워 공급 유닛(2190) 중 적어도 하나를 포함한다. 싱크 기기(2200)는 EDID EEPROM(2210), 비디오 디코딩 유닛(2220), 디스플레이 유닛(2230), 사용자 입력 인터페이스 유닛(2240), HDMI 수신기(2250), 컨트롤 유닛(2260), 파워 공급 유닛(2270), 메모리 유닛(2280) 또는 멀티미디어 유닛(2290) 중 적어도 하나를 포함한다. 이하에서, 동일한 동작을 수행하는 유닛에 대한 설명은 중복하지 않도록 한다.
소스 기기(2100)는 스토리지 유닛에 저장된 컨텐트를 싱크 기기(2200)로 전송하거나 스트리밍하는 물리적 장치를 나타낸다. 소스 기기(2100)는 싱크 기기에 요청(request) 메시지를 보내거나 싱크 기기로부터 수신한 요청 메시지를 수신하여 처리할 수 있다. 또한, 소스 기기(2100)는 전송한 요청 메시지에 대해 싱크 기기(2200)가 전송하는 응답 메시지를 처리하여 사용자에게 전달하는 UI를 제공할 수 있으며, 소스 기기(2100)가 디스플레이 유닛(2110)을 포함하는 경우에는, 이 UI를 디스플레이로 제공할 수 있다.
싱크 기기(2200)는 소스 기기(2100)로부터 컨텐트를 수신하며, 소스 기기(2100)에 요청 메시지를 전송하거나 소스 기기로부터(2100) 수신한 메시지를 처리하여 응답 메시지를 전송할 수 있다. 싱크 기기(2200) 역시 소스 기기(2100)로부터 수신하하는 응답 메시지를 처리하여 사용자에게 전달하는 UI를 제공할 수 있으며, 싱크 기기(2200)가 디스플레이 유닛(2230)을 포함하는 경우에는, 이 UI를 디스플레이로 제공할 수 있다.
소스 기기(2100) 및 싱크 기기(2200)는 사용자의 액션 또는 입력을 수신하는 사용자 입력 인터페이스 유닛(2120, 2240)을 포함할 수 있으며, 실시예로서 사용자 입력 인터페이스(2120, 2240)는 리모트 컨트롤러, 음성 수신/인식 장치, 터치 입력 센싱/수신 장치 등에 해당할 수 있다.
메모리 유닛(2160, 2280)은 다양한 종류의 데이터가 임시적으로 저장되는 휘발적 성격의 물리 장치를 나타낸다.
스토리지 유닛(2170)은 다양한 종류의 데이터를 저장할 수 있는 비휘발성성격의 물리적 장치를 타나낸다.
EDID EEPROM(2210)은 EDID 정보를 저장하고 있는 EEPROM을 나타낸다.
상술한 메모리 유닛, 스토리지 유닛, EDID EEPROM은 모두 데이터를 저장하는 역할을 하며, 이를 통칭하여 메모리 유닛이라고 지칭할 수도 있다.
디스플레이 유닛(2110, 2230)은 HDMI를 통해 수신된 데이터 또는 컨텐트 스토리지에 저장된 데이터 및 UI 등을 컨트롤 유닛의 제어에 의해 화면에 디스플레이하는 유닛을 나타낸다.
멀티미디어 유닛(2180, 2290)은 다양한 종류의 멀티미디어 재생을 수행한다. 멀티 미디어 유닛(21180, 2290)은 컨트롤 유닛(2140, 2260)과 별도로 구현되거나, 컨트롤 유닛과 하나의 물리적 구성으로서 구현될 수도 있다.
파워 공급 유닛(2190, 2270)은 소스 기기 및 싱크 기기 및 이들에 포함된 서브 유닛들의 동작에 필요한 전력을 공급한다.
HDMI 송신기(2150)는 소스 기기(2100)에 구비되어 HDMI를 통해 데이터를 송수신하는 유닛으로서, 오디오/비디오 데이터 뿐 아니라 기기간의 커맨드, 요청, 액션, 응답 등의 메시지를 포함하는 데이터 송수신을 수행한다.
비디오 인코딩 유닛(2130)은 HDMI 송신기(2150)를 통해 전송할 영상 데이터를 압축한다.
HDMI 수신기(2250)는 싱크 기기(2200)에 구비되어 HDMI를 통해 데이터를 송수신하는 유닛으로서, 오디오/비디오 데이터 뿐 아니라 기기간의 커맨드, 요청, 액션, 응답 등의 메시지를 포함하는 데이터 송수신을 수행한다.
비디오 디코딩 유닛(2130)은 HDMI 수신기(2250)를 통해 수신한 압축된 영상 데이터의 압축해제를 수행한다.
이하에서는, HDMI에서 제공하는 채널, 데이터 구조, 기능들에 대해 더욱 상세히 설명하도록 한다.

상술한 바와 같이, HDMI 시스템은 VESA(Video Electronics Standard Association)에서 정의한 모니터 및 컴퓨터 그래픽 어댑터 간의 디지털 정보 전송을 위한 프로토콜 표준인 DDC(Display Data Channel)를 제공한다. DDC를 통해 HDMI 기기들은 모니터에서 지원 가능한 디스플레이 모드 정보를 그래픽 어댑터에 전송하고, 그래픽 어댑터는 이에 맞춰 모니터에 영상을 전송할 수 있다. DDC 표준이 제정되기 전, VGA 표준에서는 모니터 타입을 인식하기 위해 아날로그 VGA 커넥터의 4가지 핀(Pin 11, 12, 4, 15)을 사용하였으며, 이 중 Pin 11, 12, 4만이 사용되고 7 종류의 모니터 타입을 인식할 수 있었다. DDC에 대한 버전 별 내용은 이하와 같다.
** DDC 버전 1 (1994년 제정)
-모니터링 정보를 기술하는 바이너리 파일 포맷인 EDID(Extended Display Identification Data)를 정의함.
-핀 12를 데이터 라인으로 사용하며 128 바이트의 EDID 블록을 연속적으로 모니터에서 컴퓨터로 전송함.
** DDC 버전 2 (1996년 제정)
-EDID를 DDC에서 정의하지 않고 병행하는 독립적인 표준으로 정의함.
-I2C 시리얼 버스를 기반으로 정의되며 Pin 12는 I2C 버스의 데이터 라인, Pin 15는 I2C 버스의 클록 라인으로 사용함.
Pin 9는 모니터 전원이 오프되어 있어도 EEPROM에 저장된 EDID를 읽기 위해 컴퓨터에서 모니터로 5V DC 전원(50mA까지)을 인가하는 용도로 사용됨.
-8비트 데이터 오프셋으로 28 바이트~256 바이트까지의 EDID 저장 용량을 허용.
** E-DDC
-DDC 버전 1 및 2를 대체하는 표준으로서 199년에 버전 1이 제정되었으며 E-EDID(Enhanced EDID) 사용을 위해 디스플레이 정보 저장 용량을 32Kbyte까지 허용함.
-8비트 세그먼트 인덱스(0x00~0x7F)를 사용하는 새로운 I2C 어드레싱 스킴을 적용하여 128 세그먼트(1세그먼트=256바이트)를 액세스할 수 있으며, 이로 인해 32 바이트까지 액세스 가능함.
-2004년 E-DDC 버전 1.1이 제정되었으며 CE 기기 및 VGA 이외에 HDMI 같은 비디오 인터페이스도 지원하는 내용이 포함됨.
-2007년 E-DDC 버전 1.2가 제정되었으며, 디스플레이 포트 및 디스플레이 ID 지원 내용이 포함됨.
이하에서는 DDC를 통해 제공되는 EDID에 대하여 설명하도록 한다.

도 3은 본 발명의 실시예에 따른 EDID 스트럭처를 나타낸 도면이다.
EDID는 VESA에서 정의된 디스플레이 장치에 대한 다양한 정보가 포함된 데이터 스트럭처로서, DDC 채널을 통해 소스 기기로 전송되거나 소스 기기에 의해 판독될 수 있다. EDID의 경우 버전 1.3의 데이터 스트럭처가 IT 디스플레이 장치, CE 디스플레이 장치 및 비디오 인터페이스(HDMI)에서 사용되고 있다.
도 3은, EDID 데이터 스트럭처에서, 각각의 어드레스에서 나타내는 정보들을 간략히 나타낸다.

도 4 내지 도 5는 EDID 익스텐션 블록의 실시예를 나타낸다.
각각 도 4는 EDID 익스텐션(Extension) 블록을, 도 5(a)는 비디오 데이터 블록을, 도 5(b)는 오디오 데이터 블록을 및 도 5(c)는 스피커 할당(allocation) 데이터 블록을 나타낸다.
EDID에 기술된 타이밍 정보는 IT 디스플레이 장치들을 위한 것으로서 CE 디스플레이 장치들의 타이밍 정보를 나타내기 위해 CEA-861에서 정의한 EDID 1.3 익스텐션 블록을 사용할 수 있다. 버전 3의 CEA 익스텐션 블록은 CEA-861B 표준에서 정의되었으며, 4개의 옵셔널 데이터 블록(비디오, 오디오, 스피커 할당, 벤더 특정(Vendor Specific)을 명시한다.
도 5(a)의 비디오 데이터 블록에서, Short Video Descriptor는 CEA-861에서 정의한 비디오 식별 코드(Video Identification Code)를 나타낸다. 도 5(b)의 오디오 데이터 블록에서, Short Audio Descriptor는 CEA-861에서 정의한 오디오 포맷 코드(Audio Format Code)를 나타낸다. 도 5(c)의 Speaker Allocation Data Block Descriptor는 CEA-861에서 정의한 데이터 블록 페이로드(Data Block Payload)를 나타낸다.

도 6은 본 발명의 실시예에 따른 HF(HDMI Forum)-VSDB(Vendor- Specific Data Block)을 나타낸다.
도 6의 HF-VSDB는 벤더-특정 데이터가 정의될 수 있는 데이터 블록으로, HDMI는 이 데이터 블록을 사용하여 HDMI 특정 데이터를 정의할 수 있다. HF-VSDB는 싱크 기기의 E-EDID에 포함될 수 있으며, 포함되는 경우 싱크 기기의 E-EDID 내의 CEA 익스텐션 버전 3에 위치할 수 있다.
도 6의 HF-VSDB에 포함된 필드들에 대한 설명은 이하와 같다.
- Length 필드: 데이터 블록의 전체 길이(total length)로서 최소값은 7, 최대값은 31임.
- IEEE OUI 필드: IEEE Organizationally Unique Identifier로서 HDMI 포럼에 할당된 OUI는 0xC45DD8임.
- Version 필드: HF-VSDB (HDMI Forum-VSDB)의 버전 넘버로서 값은 1임.
- Max_TMDS_Character_Rate 필드: 지원하는 maximum TMDS Character Rate를 나타내며 싱크 기기가 340 Mcsc 이상을 지원하지 않으면 0으로 세팅하고 지원하면 1로 세팅.
- 3D_OSD_Disparity : 1로 세팅 되면 Sink 기기가 3D_OSD_Disparity Indication 수신을 지원함을 나타냄.
- Dual_view : 1로 세팅되면 싱크 기기가 Dual_view 시그널링 수신을 지원함을 나타냄.
- Independent_view 필드: 1로 세팅되면 싱크 기기가 3D independent view 시그널링 수신을 지원함을 나타냄.
- LTE_340Mcsc_scramble 필드: 1로 세팅 되면 싱크 기기가 TMDS character rate 340Mcss 이하에서 스크램블링을 지원함을 나타냄. 그리고 SCDC_Present가 0으로 세팅되면 이 flag 또한 0으로 세팅 되어야 함.
- RR_Capable 필드: 1로 세팅 되면 Sink 기기가 SCDC 판독 요청(read request)을 개시(initiating) 할 수 있는 것을 나타냄. 그리고 SCDC_Present가 0으로 세팅되면 이 flag 또한 0으로 세팅 되어야 함.
- SCDC_Present 필드: 1로 세팅 되면 Sink가 SCDC 기능을 지원함을 나타냄.
- DC_48bit_420, DC_36bit_420, DC_30bit_420 : 1로 세팅 되면, Deep Color 4:2:0 픽셀 인코딩을 컴포넌트(component)당 10 bit/12bit/16bit를 지원함을 나타냄.
본 발명에서는 EDID의 HF-VSDB를 통해 싱크 기기의 압축해제 능력 정보를 시그널링할 수 있으며, 이에 대해서는 후술하도록 하겠다.

도 7은 본 발명의 실시예에 따른 HF-VSIF(HDMI Forum-Vendor Specific InfoFrame)을 나타낸다.
도 7에서, 도 7(a)는 HF-VSIF 패킷 헤더를, 도 7(b)는 HF-VSIF 패킷 컨텐츠를 각각 나타내며, 이들이 함께 인포프레임을 구성할 수 있다. HF-FSIF는 인포프레임의 하나로서,
HF-VSIF 패킷은 스트림 컨텐트를 완전히(fully) 식별하기 위한 보조(ancillary) 정보를 요청하는 피처(feature(s))를 지원하기 위해 제공되며, 소스 기기에서 싱크 기기로 전송될 수 있다. 실시예로서, HF-VSIF는 3D 비디오 및 2160p 비디오의 전송을 위하여 정의될 수도 있다.
도 7(a)의 HF-VSIF 패킷 헤더 및 도 7(b)의 HF-VSIF 패킷 컨텐츠에 포함된 필드들에 대한 설명은 이하와 같다.
** HF-VSIF 패킷 헤더
- Packet Type 필드: Payload 형태를 나타내며 HF-VSIF는 0x81로 구분됨.
- Version 필드: HF-VSIF의 version number로서 값은 1임.
- Length 필드: Payload의 길이를 나타냄.
** HF-VSIF 패킷 컨텐츠
- 3D_Valid 필드: 3D 비디오 데이터 전송이 있음을 나타내며 1로 설정되면 3D_F_Structure, 3D_Addiotional_Info_Present, 3D_Meta_Present 그리고 3D_F_Ext_Data 필드가 활성화 되어야 함.
- 3D_F_Structure 필드: 3D 비디오 데이터의 전송 포맷(side-by-side, top-and-bottom 등)을 나타냄.
- 3D_Additional_Info_Present 필드: 3D_DualView, 3D_ViewDependency 그리고 3D_Preferred2DView 정보가 추가될 시 1로 설정함.
- 3D_Disparity_Data_Present 필드: 3D 디스패리티(disparity) 데이터가 존재할 시 1로 설정함.
- 3D_Meta_Present 필드: 3D 메타데이터가 존재할 시 1로 설정함.
- 3D_F_Ext_Data 필드: 3D 비디오 데이터의 전송 포맷에 따라 sub-sampling 방법을 나타냄.
- 3D_Dual_View 필드: 3D 듀얼 뷰가 존재할 시 1로 설정함.
- 3D_ViewDependency 필드: right view 또는 left view의 coded view에 대한 dependency를 나타냄.
- 3D_Preferred2DView 필드: right 3D view 및 left 3D view 중 어느 3D view가 2D view에 더 적합한지 나타냄.
- 3D_DisparityData_Version 필드: 3D 디스패리티 데이터의 version을 나타냄.
- 3D_DisparityData_length 필드: 3D 디스패리티 데이터의 길이를 나타냄
- 3D_DisparityData_1~3D_DisparityData_J 필드: 3D 디스패리티 데이터를 기술함.
- 3D_MetaData_type 필드: 3D 메타데이터의 타입을 나타냄.
- 3D_MetaData_length 필드: 3D 메타데이터의 길이를 나타냄.
- 3D_Metadata_1~3D_Metadata_K 필드: 3D 메타데이터를 기술함.

도 8은 본 발명의 실시예에 따른 SCDC(Status and Control Data Channel) 스트럭처를 나타낸다.
SCDC(Status and Control Data Channel)는 소스 기기와 싱크 기기가 데이터를 교환하는 포인트-대-포인트(Point-to-Point) 통신 프로토콜에 해당한다. SCDC 통신은 상술한 DDC 채널(라인I2C)을 사용할 수 있다. 즉, SCDC는 HDMI 소스 기기와 싱크 기기간의 데이터 교환을 가능하게 하는 I2C 시리얼 통신 기반의 일대일 통신 프로토콜이다. SCDC는 I2C 슬레이브인 싱크 기기가 I2C 마스터인 소스 기기에 상태 확인 판독(status check read)을 요청하고, 이를 수신한 소스 기기가 해당 상태(status)를 싱크 기기로부터 읽어오는 매커니즘을 포함한다.
SCDCS(SCDC Structure)는 싱크 기기의 메모리에 저장되며, 도 8의 구조와 같은 데이터를 포함할 수 있다. 도 8에서 R/W는 소스 기기 관점에서, 싱크 기기에 저장된 SCDCS의 데이터를, 소스 기기는 판독(read)만 가능한지 또는 판독/기입(read/write)이 모두 가능한지를 나타낸다.
도 8의 SCDCS에 포함되는 필드들에 대한 설명은 이하와 같다.
- Sink Version 필드: SCDCS 지원(compliant) 싱크 기기의 버전 정보를 표시. 1로 설정함.
- Source Version 필드: SCDCS 지원(compliant) 소스 기기가 싱크 기기로 부터 E-EDID를 읽어오고 E-EDID의 SCDC_Present = 1로 설정되어 있으면 SCDCS의 Source Version을 1로 설정함.
- Update Flags (Update_0, Update_1) 필드: 싱크 기기가 소스 기기에 알려주어야 할 정보 (Status, Character Error Detect 등) 에 변화가 생기면 해당 bit를 1로 설정함.
- TMDS Configuration (TMDS_Config) 필드: TMDS_Bit_Clock_Ratio와 Scrambling_Enable이 각각 1 bit씩 점유하고 있으며 소스 기기가 싱크 기기의 스크램블링 기능을 활성화하고자 한다면 해당 bit를 1로 설정. TMDS_Bit_Clock_Ratio가 1/10이면 0로, 1/40이면 1로 설정.
- Scrambler Status 필드: 싱크 기기가 스크램블된 컨트롤 코드 시퀀스를 감지할 때 해당 bit를 1로 설정.
- Configuration (Config_0) 필드: 소스 및 싱크 기기의 Capability 관련 정보를 configuration하는 필드로서 현재는 Source 기기가 Sink 기기의 Read Request를 지원하는지를 나타낼 수 있는 RR_Enable field만 있음.
- Status Flags (Status_Flag_0, Status_Flag_1) 필드: Clock, channel 0,1, 그리고 2를 통해 수신된 data가 성공적으로 decoding 되었는지 아닌지를 나타냄.
- Err_Det_0~2_L/H 필드: 채널 0~3에서 디텍팅된 에러 카운터의 LSB 및 MSB를 각각 나타냄.
- Err_Det_Checksum 필드: 체크섬(hecksum)을 포함하는 7개 레지스터들의 에러 디텍션 값들의 1바이트 합(sum)이 0이 되도록 구현됨.

도 9는 본 발명의 실시예에 따른 HDMI를 통한 A/V 데이터 송수신 방법을 나타낸다.
도 9와 같이, HDMI 기기들은 비압축(uncompressed) A/V 데이터/V 데이터(오디오 데이터 또는 비디오 데이터 중 적어도 하나)를 소스 기기에서 싱크 기기로 전송하는 실시예이다.
먼저 소스 기기 및 싱크 기기가 HDMI 케이블로 연결된다(S9000). HDMI 케이블이 연결되면 소스 기기는 5V의 전력 라인을 로우 레벨로부터 하이 레벨로 전환하고 전류를 인가한다(S9010). 이를 통해 소스 기기는 싱크 기기의 EDID 정보가 저장된 EEPROM 및 관련 회로를 동작시킬 수 있다. 싱크 기기는 HPD(Hot Plug Detect) 라인을 로우 레벨에서 하이 레벨로 전환하여(S9020), 케이블이 정상적으로 연결되었고, EDID 관련 회로가 활성화되어 EDID 정보의 액세스가 가능함을 소스 기기에게 알려줄 수 있다.
이제 소스 기기는 싱크 기기로 DDC를 통해 EDID 정보 판독 요청을 전송할 수 있다(S9030). 소스 기기의 EDID 판독 요청에 대한 응답으로서, 싱크 기기는 DDC를 통해 EEPROM에 저장된 EDID 정보를 전송할 수 있다(S9040). 본 발명의 실시예에서, EDID 정보는 상술한 VSDB로서 전송될 수 있다.
싱크 기기는 수신한 EDID 정보를 파싱(parsing)하여 싱크 기기로 전송할 A/V 데이터의 동작 파라미터(타이밍, 포맷 등)를 결정하고(S9050), 전송할 비압축(uncompressed) A/V 데이터와 관련된, 결정된 동작 파라미터를 소스 기기로 전송할 수 있다(S9060). 본 발명의 실시예에서, 동작 파라미터는 HF-VSIF로서 전송될 수도 있다.
마지막으로 소스 기기는 결정된 동작 파라미터로 제어되는 비압축 A/V 데이터를 싱크 기기로 전송할 수 있다(S9070).
도 9는, 비압축 A/V 데이터를 전송하는 방법을 나타낸다. 다만, 상술한 바와 같이 초고화질 해상도의 비디오/오디오 데이터를 비압축 포맷으로 전송하고자 하나 HDMI의 피지컬 레이어에서 충분한 대역폭을 지원하지 못하는 경우, 소스 기기는 피지컬 레이어에서 지원 가능한 대역폭 안에 압축된 포맷으로 비디오 데이터를 전송해야만 한다. 다만 이를 위해서는 싱크 기기에서 소스 기기가 압축하여 보낸 비디오 데이터를 압축해제할 수 있는 능력이 있는지를 알아야 하며, 소스 기기에서도 전송하는 비디오 데이터가 압축된 포맷인지 여부를 알려주어야만 한다. 이하에서는, HDMI를 통해 압축된 비디오 데이터를 송수신하는 방법에 대하여 더욱 상세히 설명하도록 한다. 이하에서는 비디오 데이터의 예를 들어 설명하도록 하나, 본 명세서의 설명 및 발명은 비디오 데이터 뿐 아니라 오디오 데이터에도 동일하게 적용될 수 있다.

도 10은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법을 나타낸다.
먼저, 단계(S10000)에서 단계(S10030)까지는 도 9의 단계(S9000)에서 단계(S90030)와 동일하게 수행되며, 이에 대한 설명은 중복하지 않는다. 도 10은 도 9의 순서도에 추가되는 동작들을 포함하는 것으로서, 도 9에서와 동일한 설명은 도 10에서 다시 기술되지 않아도, 도 10의 설명에 적용이 가능한 것이다.
도 10에서, EDID 정보 판독 요청을 수신한 싱크 기기는, 압축해제 능력(capability) 정보를 포함하는 EDID 정보를 DDC를 통해 소스 기기로 전송할 수 있다(S10040). 전송되는 압축해제 능력 정보는 압축된(compressed) A/V 데이터를 싱크 기기가 처리할 수 있는지, 처리할 수 있다면 어떤 동작 파라미터로 세팅된 압축된 A/V 데이터를 처리할 수 있는 등에 대한 정보를 포함할 수 있다. 다시 말하면, 압축해제 능력 정보는 싱크 기기의 압축해제 기능 지원 유무 및 관련 특성 정보를 포함할 수 있다. 상술한 바와 같이, 이러한 EDID 정보는 EEPROM에서 판독되어 HF-VSDB로서 전송될 수 있다.
싱크 기기는 수신한 EDID 정보를 파싱(parsing)하여 싱크 기기로 전송할 A/V 데이터의 동작 파라미터(타이밍, 포맷 등)를 결정하고(S10050), 전송할 비압축(uncompressed) A/V 데이터와 관련된, 결정된 동작 파라미터를 소스 기기로 전송할 수 있다(S10060). 도 10에서, 전송되는 동작 파라미터는 압축 메타데이터(compression metadata)를 포함한다. 압축 메타데이터는 싱크 기기에서 압축된 A/V 데이터를 압축해제(decompression)하는 데 필요한 정보로서, 압축된 비디오 데이터의 특성 정보를 나타낸다.
본 발명의 실시예에서, 동작 파라미터는 HF-VSIF로서 전송될 수도 있다.
마지막으로 소스 기기는 결정된 동작 파라미터로 제어되는 압축된 A/V 데이터를 싱크 기기로 전송할 수 있다(S10070).

도 11은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 소스 기기에 의한 싱크 기기의 압축해제 기능을 제어하는 방법을 나타낸다.
도 11은, 도 10의 설명에 추가로, 소스 기기가 전송하는 데이터의 종류를 비압축 데이터에서 압축 데이터로 또는 압축 데이터에서 비압축 데이터로 변경하는 경우 그에 따른 싱크 기기의 압축해제 기능을 활성화(enable)하거나 비활성화(disable)하는 방법에 대한 것이다. 도 11에서와 같이, 소스 기기에서 재생하는 비디오 컨텐트가 비압축 포맷으로 전송하는 것이 불가능한 경우, 소스 기기는 해당 A/V 데이터를 압축하여 전송할 것을 결정하고, 싱크 기기에서 압축해제 기능을 활성화할 것을 요청할 수 있다.
소스 기기는 싱크 기기로 결정된 동작 파라미터들에 따른 비압축 A/V 데이터를 전송할 수 있다(S11000). 그리고 사용자가 소스 기기에서 비디오 컨텐트를 8K 비디오 컨텐트로 변경할 수 있다(S11010). 실시예에서, 8K 비디오 컨텐트는 현재 연결된 HDMI 케이블의 대역폭에서는 비압축/무손실로 전송이 어려울 수 있다. 이러한 경우 소스 기기는 8K 비디오를 압축하여 전송하기로 결정할 수 있다(S11020). 8K 비디오는 실시예인 것으로, 소스 기기는 전송할 A/V 데이터가 현재 연결된 HDMI 케이블의 대역폭에서 비압축으로 무손실 전송이 가능한지를 판단하고, 무손실 전송이 어려운 경우에는 압축 전송으로 전송 방식을 변경할 것을 결정할 수 있다.
이제, 소스 기기는 싱크 기기가 압축해제 기능(function)을 활성화시킬 것을 요청할 수 있다(S11030). 싱크 기기는 압축해제 기능을 활성화시키고(S11040), 압축해제 기능이 활성화 되었음을 소스 기기로 알려줄 수도 있다.
소스 기기는 압축 메타데이터를 포함하는 동작 파라미터들을 싱크 기기에게 전송하고(S11050), 전송한 압축 파라미터들에 의해 컨트롤되는 압축된 A/V 데이터를 싱크 기기로 전송할 수 있다(S11060).
소스 기기는 다양한 사유로 인해 비압축 비디오 데이터의 전송을 결정할 수 있다(S11070). 예를 들면, 사용자가 시청하는 비디오의 해상도를 낮추었거나, 수신/스트리밍하는 비디오 컨텐트 자체가 낮은 해상도로 변경되는 등 HDMI의 대역폭에서 무압축 전송이 가능해지면, 소스 기기는 비압축 비디오의 전송을 결정할 수 있다.
소스 기기는 싱크 기기로 압축해제 기능의 비활성화를 요청할 수 있다(S11090). 싱크 기기는 소스 기기의 요청에 따라서 압축해제 기능을 비활성화하고(S11090), 압축해제 기능이 비활성화되었음을 소스 기기로 알려줄 수도 있다. 이제 소스 기기는 비압축 A/V 데이터를 싱크 기기로 전송할 수 있다(S11100).
상술한 소스 기기의 싱크 기기에 대한 압축 해제 기능의 활성화 및 비활성화 요청은 SCDCS를 사용하여 수행될 수 있으며, 이에 대해서는 이하에서 다시 설명하도록 한다.

도 12는 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 SCDCS를 사용하여 소스 기기가 싱크 기기의 압축해제 기능을 활성화하는 방법을 나타낸다.
도 12는 도 11에서 소스 기기가 싱크 기기의 압축해제 기능을 SCDC를 통해 활성화/비활성화하는 방법으로서, 도 11의 단계들(S11030, S11040, S11080 및 S11090)을 SCDC 데이터 통신으로서 나타낸다. 도 12의 단계들 중 도 11의 단계들(S11000, S11010, S11020 및 S11050)과 동일한 단계들(S12000, S12010, S12020 및 S12050)에 대한 설명은 생략하도록 한다.
본 발명에서는 SCDCS에 압축해제 기능을 활성화/비활성화하기 위한 압축해제 활성화 정보(DC_Enable)를 정의한다. 도 12에서, 압축해제 활성화 정보는 플래그 또는 비트로서 도 12(b)에서와 같이 정의될 수 있다. 도 12(b)의 비트1에 포함된 정보(DC_Enable)가 SCDCS에 포함되는 압축해제 활성화 정보를 나타낸다. 도 12(b)의 실시예에서, 압축해제 활성화 정보는 SCDCS의 오프셋 0x30의 레지스터에 정의되며, 이 중 비트1으로 정의될 수 있다. 압축해제 활성화 정보의 값이 1로 설정되면 압축해제 기능이 활성화되었음을, 0으로 설정되면 압축해제 기능이 비활성화되었음을 각각 나타낼 수 있다. 따라서, 소스 기기는 압축해제 인에이블 정보의 값에 1 또는 0의 값을 기입함으로써 싱크 기기의 압축해제 기능을 활성화/비활성화할 수 있다. 압축해제 인에이블 정보는 SDCDS의 Config_0 정보 부분에서 1비트로 정의될 수도 있다.
소스 기기는 압축된 비디오를 전송하기 위해 싱크 기기의 압축 해제 기능을 활성화해야 한다. 이를 위해 소스 기기는 압축해제 기능을 활성화시키는 SCDC 기입 메시지를 전송할 수 있다(S12030). 도 12(a)는 압축해제 기능을 활성화시키는 SCDC 기입 메시지의 실시예를 나타낸다. 이 메시지는 슬레이브 어드레스가 0x54인 싱크 기기의 0x54에서 0x30만큼 떨어진 레지스터에 0x03을 기입하는 SCDC 기입 메시지이다. 즉, SCDC 기입 메시지는 슬레이브 어드레스 정보(Slv Addr=0x54), 서브 어드레스 정보(0x30) 및 기입할 데이터(Data=0x03)를 포함할 수 있다.
싱크 기기는 수신한 SCDC 기입 메시지에 따라 압축해제 활성화 정보의 값을 설정할 수 있다(S12040). 싱크 기기는 수신한 SCDC 기입 메시지에 따라 해당 주소의 비트 값을 설정할 수 있다. 즉, 도 12(b)의 SCDCS에서 비트 0 및 비트 1의 위치 값을 1로 설정할 수 있다. 그리고 싱크 기기는 변경된 압축해제 활성화 정보의 값에 따라서 비디오 디코딩 유닛의 압축해제 기능을 활성화시킬 수 있다.
도 11에서 소스 기기가 압축해제 기능 비활성화를 요청하고(S11080), 싱크 기기가 압축해제 기능을 비활성화하는 단계(S11090) 또한 상술한 바와 유사하게 실행될 수 있다. 이 경우 상술한 단계들(S12030 및 12040)과 같이 소스 기기는 압축해제 활성화 정보의 값을 0으로 기입하는 SCDC 기입 메시지를 전송하고, 싱크 기기는 수신한 SCDC 기입 메시지에 따라서 압축해제 활성화 정보의 값을 0으로 설정함으로써 수행될 수 있다. 싱크 기기는 변경된 압축해제 활성화 정보의 값에 따라서 비디오 디코딩 유닛의 압축해제 기능을 비활성화시킬 수 있다.
도 12(b)에서 RR_Enable 정보는 소스 기기가 판독 요청을 지원하는 경우 1로, 소스 기기가 업데이트 플레그의 폴링(polling) 만을 지원하는 경우 0으로 설정될 수 있다. 도 12의 실시예에서, RR_Enable 정보는 1로 설정되어 소스 기기가 판독 요청을 지원하는 것으로 나타내었다.

도 13은 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 싱크 기기가 소스 기기로 압축 해제 기능의 상태 변화를 알리는 방법을 나타낸다.
도 13는, 도 10의 설명에 이어, 압축된 A/V 데이터를 수신하는 싱크 기기에서 압축해제를 수행하는 중 상태 변화(예를 들면, 버퍼 오버플로우/언더플로우)가 발생하는 경우, 이를 소스 기기에 알려주는 방법을 나타낸다. 소스 기기는 해당 상태 변화에 대한 정보를 읽어 동작 파라미터를 바꾸고 바뀐 동작 파라미터에 따른 압축된 A/V 데이터를 전송할 수 있다.
소스 기기는 싱크 기기로 결정된 동작 파라미터들에 따른 압축 A/V 데이터를 전송할 수 있다(S13000).
싱크 기기는 압축된 A/V 데이터를 수신 및 압축해제하여 컨텐트를 제공할 수 있다. 그리고 싱크 기기가 압축해제를 실행하는 중 상태 변화가 발생할 수 있다(S13010). 실시예로서, 이러한 상태 변화는 비디오 디코딩 유닛의 버퍼 오버플로우 또는 버퍼 언더플로우 등에 해당할 수도 있다. 그리고 싱크 기기는 소스 기기에게 압축 해제 기능의 상태 변화를 알려줄 수 있다(S13020).
소스 기기는 싱크 기기로부터 상태 변화의 발생을 알게 되고, 그에 따라 싱크 기기로부터 상태 변화에 대한 상세(detailed) 정보/추가 정보를 판독할 수 있다(S13030). 소스 기기는 판독한 상세 정보에 기초하여 동작 파라미터를 변경하고(S13040), 변경된 동작 파라미터를 싱크 기기로 전송할 수 있다(S13050). 그리고 소스 기기는 변경된 동작 파라미터에 의해 제어되는 압축된 A/V 데이터를 전송할 수 있다(S13060). 소스 기기의 동작 파라미터 결정, 압축 메타데이터를 포함하는 동작 파라미터의 전송 및 압축된 A/V 데이터 전송은 도 10의 단계들(S10050~S10070)과 같이 수행될 수 있다.
도 13에서, 상술한 압축해제 기능 실행 중 발생한 상태 변화는 싱크 기기가 SCDCS를 사용하여 소스 기기에 알려줄 수 있으며, 이에 대해서는 이하에서 다시 설명하도록 한다.

도 14는 본 발명의 실시예에 따른 HDMI를 통한 압축된 A/V 데이터 송수신 방법으로서, 특히 SCDCS를 사용하여 싱크 기기가 압축해제 기능의 상태변화를 소스기기로 알리는 방법을 나타낸다.
도 14는, 도 13의 설명에 이어, 싱크 기기가 상태 변화를 업데이트하여 소스 기기에게 알리고, 소스 기기가 변경된 상태 변화를 판독하는 과정을 SCDC를 사용하여 설면한다. 도 14에서도 소스 기기는 싱크 기기로 결정된 동작 파라미터들에 따른 비압축 A/V 데이터를 전송할 수 있다(S14000).
상술한 바와 같이 싱크 기기의 압축해제 기능에 상태 변화가 발생하는 경우, 싱크 기기는 이를 상태 변화 정보(status change information)로서 SCDCS게 기입하고, SCDC를 통해 이를 소스 기기에게 알려줄 수 있다. 상태 변화 정보는 도 14(c)에서와 같이 SCDCS의 Status_Flag_1 부분에 위치할 수 있다.
상태 변화 정보는 버퍼 언더플로우 발생 여부를 나타내는 버퍼 언더플로우 정보, 버퍼 오버플로우 발생 여부를 나타내는 버퍼 오버플로우 정보 또는 HF-VSIF에서 명시된 청크 사이즈와 수신한 비디오 데이터의 청크 사이즈가 다른지 여부를 나타내는 청크 길이 에러 정보 중 적어도 하나를 포함할 수 있다. 상태 변화 정보는 SCDCS에 도 14(c)에서와 같이 오프셋 0x41의 비트0~2에 위치될 수 있으며, 상태 변화 정보에 해당/포함되는 필드들의 실시예 및 설명은 아래와 같다.
- RC_Buffer_Underrun 필드: RC 버퍼에서 언더런(underflow) 발생시 1로 설정됨.
- RC_Buffer_Overflow 필드: RC 버퍼에서 오버플로우(overflow) 발생시 1로 설정됨.
- Chunk_Length_Error 필드: HF-VSIF에 명시된 청크 사이즈와 수신한 청크사이즈의 길이가 다른 경우 1로 설정될 수 있음.
싱크 기기는 위와 같이 상태 변화가 발생하면 발생한 상태 변화에 해당하는SCDCS의 상태변화 정보의 값을 1로 설정할 수 있다(S14010). 싱크 기기는 도 14(c)와 같이 청크 사이즈가 다른 경우, 버퍼 오버플로우가 발생한 경우, 버퍼 언더 플로우가 발생한 경우 각각 해당하는 상태 변화 정보 필드의 값을 1로 설정할 수 있다.
싱크 기기는 소스 기기로 SCDC 판독 요청(SCDS Read Request) 메시지를 전송할 수 있다(S14020). SCDC 판독 요청 메시지는 싱크 기기가 연결된 소스 기기에게 업데이트 플래그를 판독할 것을 요청하는 메시지이다. 싱크 기기는 업데이트된 상태 정보를 소스 기기에게 알리기 위해 SCDC 판독 요청 메시지를 소스 기기로 전송하는 것이다.
소스 기기는 상태 변화 정보를 판독할 수 있으며(S14030), 이는 SCDC를 통해 업데이트를 판독하고(S14030-1), 업데이트에 해당하는 상태 변화 정보를 판독함(S14030-2)으로써 수행될 수 있다.
먼저 소스 기기는 도 14(a)의 SCDC 업데이트 판독 요청 메시지를 전송함으로써 SCDC 업데이트 정보를 판독할 수 있다(S14030-1). SCDC 업데이트 판독 요청 메시지는 슬레이브 어드레스 정보 및 판독할 레지스터 주소 정보를 포함할 수 있다. 도 14(a)에서, 업데이트 판독 메시지는 슬레이브 어드레스가 0x54인 싱크 기기의 Update_0 및 Update_1의 레지스터 값을 판독할 것을 요청하는 메시지이다. 싱크 기기는 해당 레지스터값을 버스에 수신된 메시지에 기입함으로써 소스 기기가 이를 판독하도록 할 수 있다.
업데이트를 확인한 소스 기기는 도 14(b)의 SCDC 상태 변화 정보 판독 요청 메시지를 전송함으로써 SCDCS의 상태 변화 정보를 판독할 수 있다(S14030-2). SCDC 상태변화 판독 요청 메시지는 슬레이브 어드레스 정보 및 판독할 레지스터 주소 정보를 포함할 수 있다. 도 14(b)에서, 상태변화 정보 판독 메시지는 슬레이브 어드레스가 0x54인 싱크 기기의 0x41만큼 떨어진 레지스터 값인 상태 변화 정보를 판독할 것을 요청하는 메시지이다. 해당 데이터는 0x41만큼 떨어진 레지스터 값에서, 비트0, 비트 1, 비트2의 값이 바뀔 수 있으므로 각 경우 0x01, 0x02 또는 0x04 중 적어도 하나의 값이 될 수 있다. 싱크 기기는 해당 레지스터 값을 버스에 수신된 메시지에 기입함으로써 소스 기기가 상태 변화 정보를 판독하도록 할 수 있다.
이후 소스 기기가 동작 파라미터를 변경하고(S14040), 변경된 동작 파라미터를 전송하고(S14050), 압축된 A/V 데이터를 전송하는(S14060) 과정은 도 13에서 해당 동작들을 설명한 바와 같다.

도 15는 본 발명의 다른 실시예에 따른 HF-VSDB를 나타낸다.
도 15에서는, 도 6에서 도시한 HF-VSDB에 추가로, 압축해제 능력 정보가 추가된 추가된 실시예에 해당한다. 도 15의 HF-VSDB는 상술한 바와 같이 EDID 정보의 하나로서, 압축해제 능력 정보를 포함할 수 있고, 압축해제 능력 정보는 싱크 기기의 압축해제 지원여부 및 압축 해제 기능(capability)을 나타내는 필드들을 포함할 수 있다..
도 15에서는 새로운 HF-VSDB를 추가로 정의하며, 이전 버전의 HF-VSDB와 구별하기 위해 버전(Version) 필드의 버전 넘버를 2로 설정할 수 있다. 싱크 기기가 압축된 A/V 데이터를 처리할 수 있음을 나타내기 위하여 HF-VSDB의 바이트 6 블록의 비트 5~4, 바이트 7 블록의 비트 7~3 중 적어도 하나의 비트를 사용할 수 있다. 실시예로서, 해당 비트가 1로 설정되면 싱크 기기가 압축된 비디오 데이터를 프로세싱(수신/압축해제)할 수 있음을 나타내고, 0이면 압축된 비디오를 프로세싱할 수 없음을 나타낼 수 있다.
도 15에서 새로이 추가된 압축해제 능력 정보에 대한 필드들에 대한 설명은 이하와 같다. 압축해제 능력 정보는 도 15에서 나타낸 아래의 필드들 중 적어도 하나의 필드를 포함할 수 있다.
- compression_version_major 필드: 압축(compression) 알고리즘의 메이저 버전(major version)을 나타냄.
- compression_version_minor 필드: 압축 알고리즘의 마이너 버전(minor version)을 나타냄.
- rc_buffer_block_size 필드: 싱크 기기의 디코더(decomoressor)의 rc 버퍼 블록 사이즈를 나타냄.
- rc_buffer_size 필드: 싱크 기기의 디코더(decomoressor)의 rc 버퍼 사이즈를 나타냄.
- slice capabilities (1 slice per line, 2 slice per line, 4 slice per line) 필드: 라인(line) 당 지원하는 슬라이스(slice)의 개수를 나타냄.
- line_buffer_bit_depth 필드: 라인 당 할당 되는 버퍼의 크기를 나타냄.
- block prediction support 필드: 싱크 기기에서 블록 예측(prediction) 지원 유무를 나타냄. 이 필드는 바이트 6의 5~4비트 또는 바이트 7의 7~3비트 중 하나에 위치할 수 있다.
- max_bits_per_pixel 필드: 디코더(decompressor)에서 지원되는 픽셀 당 최대 비트수(maximum bits per pixel)를 나타냄.
- color format capabilities (RGB, YCbCr_444, YCbCr_422, YCbCr_420) 필드: 싱크 기기에서 지원하는 컬러 포맷을 나타냄.
- color depth capabilities (CD_6, CD_8, CD_10, CD_12) 필드: 싱크 기기에서 지원하는 컬러 뎁스를 나타냄

도 16 및 도 17은 본 발명의 다른 실시예에 따른 HF-VSIF를 나타낸다.
도 16 및 도 17에서는, 도 7에서 도시한 HF-VSIF에 추가로, 소스 기기가 압축된 비디오를 전송하기 위해 싱크 기기로 전송하는 압축 메타데이터에 해당하는 필드들이 추가된 실시예에 해당한다. 도 16 및 도 17의 HF-VSIF는 상술한 바와 같이 인포프레임의 하나로서, 압축 메타데이터를 포함할 수 있다. 도 16 및 도 17의 HF-VSIF를 인포프레임이라고 지칭할 수도 있다.
도 16 및 도 17에서는 새로운 HF-VFIF를 추가로 정의하며, 이전 버전의 HF-VSIF와 구별하기 위해 버전(Version) 필드의 버전 넘버를 2로 설정할 수 있다. 소스 기기에서 압축된 비디오를 전송하는 경우 현재 전송하고 있는 비디오가 압축된 비디오인지여부를 PB5(5번 패킷 바이트)의 비트 7~1 중 적어도 하나를 통해 시그널링하여 싱크 기기에게 알려줄 수 있다. 실시예로서, 해당 비트가 1로 설정되면 압축된 비디오가 전송됨을, 해당 비트가 0으로 설정되면 비압축 비디오가 전송됨을 나타낼 수 있다.
HDMI의 VSIF는 한 패킷당 패킷 바이트의 길이가 27 바이트로 제한될 수 있다. 이러한 경우 비디오 압축 메타데이터를 복수의 패킷으로 분할하여 전송해야할 수도 있다. 이러한 경우, 현재 패킷이 비디오 압축 메타데이터를 나타내는 마지막 패킷인지 아닌지를 나타내는 플래그가 필요하며, 실시예로서 PB5에 위치한 예비(Reserved) 비트들 중 하나를 이러한 용도로 사용할 수 있다. 다시 말하면, PB5의 예비 비트들 중 하나에 전달 데이터의 마지막임을 나타내는 메시지 종료(End of Message) 플래그 피트를 추가하고, 해당 비트를 1로 설정하면 메시지의 마지막 전달 패킷임을 나타낼 수 있다.
3D_Valide 필드가 1로 설정되는 경우, 비디오 압축 관련 메타데이터는 3D_Metadata뒤에부터 위치할 수 있다. 하지만, 3D_Valid 필드값이 0인 경우, 비디오 압축 관련 메타데이터는 PB6부터 위치할 수도 있다. ( 3D_Valide 필드값이 1인 경우, 해당 패킷 바이트가 3D 관련 정보로 정의되고, 비디오 압축 유무 비트가 활성화 된 경우, 해당 패킷 바이트는 비디오 압축 메타데이터로 정의될 수 있음.)
도 16 내지 도 17에서 새로이 추가된 압축 메타데이터에 대한 필드들에 대한 설명은 이하와 같다. 압축메타데이터는, 도 16 내지 도 17에서 나타낸 아래 필드들 중 적어도 하나의 필드를 포함할 수 있다.
- compression_version_major 필드: 압축 알고리즘의 메이저 버전을 나타냄.
- compression_version_minor 필드: 압축 알고리즘의 마이너 버전을 나타냄.
- pps_identifier 필드: 서로 다른 PPS 테이블 사이에서 구별하는 어플리케이션-특정 식별자(application-specific identifier)로 사용됨.
- bits_per_component 필드: 압축을 수행하는 인코더에 입력되는 압축되지않은비디오(uncompressed video)의 각 컴포넌트들(e.g. R, G and B, or Y, Cb and Cr)에 할당된 비트 수를 나타냄.
- Linebuf_depth 필드: 스트림을 생성시키는데 사용된 라인 버퍼 비트 뎁스(line buffer bit depth)를 나타냄.
- Block_pred_enable 필드: 디코더에서 BP(block prediction)과 MMAP중 어떤 것을 선택할 지 나타냄. 0일 경우 BP가 사용 되지 않음을 나타냄.
- Convert_rgb 필드: 압축되지 않은 비디오(uncompressed video)가 RGB였는지 YCbCr이었는지 표기함. 0으로 표기할 경우 YCbCr이었음을 나타내고 1으로 표기할 경우 디코더에서 YCoCg-R에서 RGB로 변경함.
- Enable_422 필드: 4:2:2 샘플링을 사용했는지 나타냄.
- Enable_420 필드: 4:2:0 샘플링을 사용했는지 나타냄.
- vbr_enable 필드: 디코더와 송신기(transport)에서 지원할 경우 VBR 모드를 온/오프(on/off)할지 나타냄
- Bits_per_pexel 필드: 압축을 수행하는 인코더의 인코딩된 비디오의 픽셀 당 비트 수를 나타냄.
- Pic_height, Pic_width 필드: 픽처(picture)의 크기를 픽셀 단위로 나타냄. Slice_width와 slice_height의 정수배에 가까운 숫자일 것이 권장됨.
- sub_sampling_format 필드: 압축을 수행하는 인코더에 입력되는 압축되지 않은 비디오의 서브 샘플링 방법을 나타냄.
- Slice_height, Slice_width 필드: 슬라이스(slice) 각각의 크기를 나타냄.
- Chunk_size 필드: 슬라이스 멀트플렉싱(slice multiplexing)을 위해 사용되는 청크(chunk)의 바이트 사이즈를 나타냄.
- initial_xmit_delay 필드: 전송 전 인코더의 레이트 버퍼(rate buffer)에서 대기하는 픽셀 타임(pixel time)의 시간을 나타냄.
- initial_dec_delay 필드: 디코더가 디코딩하고 픽셀 출력을 시작하기 전에 레이트 버퍼에 모아두는 픽셀 타임의 수를 나타냄.
- initial_scale_value 필드: 슬라이스의 시작 부분에 사용되는 rcXformScale을 위한 초기값을 나타냄.
- Scale_increment_interval 필드: 슬라이스의 마지막 부분에 있는 rxXformScale factor 사이의 group times 수를 나타냄.
- Scale_decrement_interval 필드: 슬라이스의 시작 부분에 있는 rxXformScale 팩터(factor) 사이의 그룹 타임(group times) 수를 나타냄.
- first_line_bpg_offset 필드: 슬라이스의 첫 번째 라인에 있는 각각 그룹을 위해 할당된 추가 비트 수를 나타냄.
- Nfl_bpg_offset 필드: 슬라이스의 첫 번째 라인 이후 그룹을 위해 각각의 그룹에 대한 할당을 해지하는 비트 수를 나타냄.
- Slice_bpg_offset 필드: 프로그램 작동이 가능한 initial_offset이 허용되는동안 슬라이스 컨스트레인트(constraint)를 강제하기 위해 각각의 그룹에 대해 할당을 해지하는 비트 수를 나타냄.
- Initial_offset 필드: rcXformOffset을 위한 초기값을 나타냄.
- Final_offset 필드: rcXformOffset을 위한 슬라이스 종료(end-of-slice) 값의 최대값을 나타냄.
- Flatness_min_qp 필드: 플랫니스(flatness)가 시그널링되고 플랫니스 QP 수정이 생성되는 QP의 최소값을 나타냄.
- Flatness_max_qp 필드: 플랫니스가 시그널링되고 플랫니스 QP 수정이 생성되는 QP의 최대값을 나타냄.
- Rc_model_size 필드: RC 모델의 비트 수를 나타냄.
- Rc_edge_factor 필드: 에지의 존재 여부를 확인하기 위해 현재 액티비티/종전의 액티비티(current activity/previous activity)의 비율을 나타냄
- Rc_quant_incr_limit0 필드: 단기 레이트 컨트롤(short-term rate control)에 사용되는 QP 스레스홀드를 나타냄.
- Rc_quant_incr_limit1 필드: 단기 레이트 컨트롤(short-term rate control)에 사용되는 QP 스레스홀드를 나타냄.
- Rc_tgt_offset_hi 필드: 단기 레이트 컨트롤에 의해 허용된 그룹당 타겟비트(target bits)의 가변적 범위의 상한(upper end)을 나타냄.
- Rc_tgt_offset_lo 필드: 단기 레이트 컨트롤에 의해 허용된 그룹당 타겟비트(target bits)의 가변적 범위의 하한(low end)을 나타냄.
- Rc_buf_thresh[14] 필드: RC 모델에 있는 15개 레인지(range)를 위한 스레스홀드
- Rc_range_parameters[15] 필드: RC 모델에 있는 15개 각각의 레인지(range)에 대하여 range_min_qp(5 bits), range_max_qp(5 bits)와 rage_bpg_offset(6 bits)을 나타냄.

도 16 및 도 17는 인포프레임 중 HF-VSIF를 사용하여 비디오의 압축 메타데이터 추가하여 전송하는 실시예를 나타내었다. 이하에서는 HF-VSIF에 압축 메타데이터를 추가하는 방법 대신 압축 메타데이터를 전송하기 위한 별도의 인포프레임을 정의 및 사용하는 방법에 대해 설명하도록 한다.
인포프레임은 HDMI를 통해 소스 기기에서 싱크 기기로 전달되는 데이터 스트럭처이다. 인포프레임은 비디오 스트림, 오디오 스트림 또는 소스 기기 등에 대한 보조(auxiliary) 정보를 전달할 수 있다. 인포프레임은 패킷 헤더와 페킷 컨텐트를 포함한다.
표 1은 HDMI에서 송수신되는 패킷 타입들을 나타낸다.
패킷 타입 값 패킷 타입
0x00 널(Null)
0x01 오디오 클럭 재생성(Audio Clock Regeneration )
0x02 오디오 샘플(Audio Sample)
0x03 일반 컨트롤(General Control)
0x04 ACP 패킷
0x05 ISRC1 패킷
0x06 ISRC2 패킷
0x07 1비트 오디오 샘플(one Bit Audio Sample)
0x08 DST 오디오 패킷
0x09 고-비트레이트 오디오 스트림 패킷(High Bitrate Audio Stream Packet)
0x0A 전반(Gamut) 메타데이터 패킷
0x80 + 인포프레임 타입 인포프레임 패킷
0x81 Vendor-Specific 인포프레임
0x82 AVI 인포프레임
0x83 소스 프로덕트 디스프립터 인포프레임
0x84 오디오 인포프레임
0x85 MPEG 소스 인포프레임
0x86 비디오 압축 인포프레임
0x0B 3D 오디오 샘플 패킷(L-PCM format only)
0x0C 1비트 3 D 오디오 샘플 패킷
0x0D 오디오 메타데이터 패킷
0x0E 멀티 스트림 오디오 샘플 패킷
0x0F 1비트 멀티-스트림 오디오 샘플 패킷

표 1에서와 같이, 도 16 및 도 17의 HF-VSIF는 0x81의 패킷 타입 값을 가질 수 있다. 상술한 바와 같이 본 발명은 압축 관련 메타데이터를 도 16 및 도 17에서와 같이 HF-VSIF에 추가하여 보낼 수 있고, 다른 실시예로서 압축 메타데이터를 전송하기 위한 별도의 인포프레임을 새로 정의 할 수 있다. 본 발명에서 새롭게 정의하는 압축 메타데이터를 포함하는 인포프레임은 비디오 압축 인포프레임(Video compression InfoFrame)이라 지칭할 수 있으며, 표 1에서와 같이 0x86의 패킷 타입 값이 할당될 수 있다.

도 18 내지 도 20은 본 발명의 실시예에 따른 비디오 압축 인포프레임을 나타낸다.
도 18 내지 도 20에서 패킷 바이트가 HB0~HB2는 패킷 헤더 바이트를, PB1~27은 패킷 컨텐츠 바이트를 나타낸다.
패킷 헤더에서, 바이트 HB0는 패킷 타입을 나타낸다. 그리고 바이트 HB1은 인코더에서 비디오 데이터 인코딩에 사용하는 압축 알고리즘의 메이저 버전과 마이너 버전을 나타낸다. 바이트 HB2에서, 헤더에 위치한 예비 비트들 중 하나에 전달 데이터의 마지막임을 표시하는 메시지 종료(End of Message) 비트를 할당하고, 해당 비트가 1로 설정되면 마지막 전달 패킷임을 나타낼 수 있다.
상술한 바와 같이 인포프레임은 한 패킷에서 전송할 수 있는 패킷 바이트의 크기가 28 바이트로 제한될 수 있다. 따라서 제한 내에서 전달하기 위해 도 18 내지 도 20과 같이 비디오 압축 메타데이터를 3부분으로 분할하여, 3개의 패킷으로 전달할 수 있다. 다만 이는 실시예로서, 패킷 용량에 따라서 분할되는 패킷의 수 및 컨텐츠는 변경될 수도 있다.
도 18 내지 도 20에서 전달되는 비디오 압축 메타데이터는 도 16 및 도 17에서 전달되는 정보와 동일하며, 상술한 필드들에 대한 설명이 도 18 내지 도 20의 필드들에게도 적용된다.

본 발명은 싱크 기기의 압축 해제 기능 지원 및 압축 해제 특성 정보 정의, 그리고 이를 소스 기기에 전달하는 방법, 소스 기기의 압축 특성 정보 정의 및 이를 싱크 기기에 전달하는 방법, 그리고 싱크 기기의 압축 해제 기능 상태 정보 정의 및 이를 소스 기기에 전달하는 방법을 제시한다.
소스 기기와 싱크 기기간 압축 및 압축 해제 특성 정보 정의 및 교환 방법
소스 기기와 싱크 기기가 연결되었을 때, 싱크 기기는 E-EDID의 VSDB에 싱크 기기의 압축 해제 기능 지원 유무 및 관련 특성 정보를 담아 DDC를 통해 소스기기에 전송한다. 이를 수신하고 해석한 소스 기기는 싱크 기기가 압축 해제 기능이 지원됨을 확인하면 관련 특성 정보를 기반으로 영상을 압축하고 압축된 영상의 특성 정보를 VSIF에 담아 압축된 영상을 보내기 전에 소스 기기에 전송한다. 이를 수신한 소스 기기는 VSIF의 압축 특성 정보를 기반으로 압축된 영상을 압축 해제 한다. 그리고 압축 특성 정보를 VSIF에 표현함에 있어 기존 제한된 VSIF의 패킷 바디 길이(28 바이트)를 초과하게 되면 제한된 패킷 바디 길이를 늘려서 모든 압축 특성 정보를 하나의 VSIF 패킷에 나타낼 수 있다. 또는 기존 제한된 VSIF 패킷 바디 길이에 맞춰 압축 특성 정보를 분할하여 표현할 수 있으며 분할된 VSIF 패킷의 분할 정보(분할 패킷의 시작, 계속, 끝)를 VSIF 패킷 헤더 또는 바디에 표현할 수 있다.
2) 싱크 기기의 압축 해제 기능 동작 제어 방법
소스 기기가 압축된 영상을 압축 해제 기능을 지원하는 싱크 기기에 전송하기 전에 싱크 기기의 압축 해제 기능을 활성화 시킨다. 이를 위해 싱크 기기의 SCDCS에 압축 해제 기능을 활성화 및 비활성화을 나타내는 비트를 정의한다. 그리고 정의된 비트를 제어함에 있어 SCDC를 통해 싱크 기기의 SCDCS에 정의된 압축 해제 기능 관련 비트를 1로 세팅함 으로서 압축 해제 기능 활성화가 가능하다. 또한 소스 기기가 압축된 영상을 전송하다가 무압축 영상을 보내고자 할 때 무압축 영상을 보내기 전 SCDC를 통해 싱크 기기의 SCDCS에 정의된 압축 해제 기능 관련 비트를 0으로 세팅함 으로서 압축 해제 기능 비활성화가 가능하다.
3) 싱크 기기의 압축 해제 기능 상태 변화 정보 전송 방법
싱크 기기의 압축 해제 기능 상태 변화 정보를 소스 기기에 알려 주기 위해 싱크 기기의 SCDCS에 상태 정보를 나타내는 필드를 정의 하고 해당 필드에 변화가 있을 시 SCDC를 통해 소스 기기에 상태 변화가 있음을 알려 준다. 이를 수신한 소스 기기는 변화된 상태에 대한 자세한 정보를 읽어 오기 위해 SCDCS에 정의된 해당 상태 정보를 나타내는 필드를 SCDC를 통해 액세스 하여 읽어올 수 있다.

본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
다양한 실시예가 본 발명을 실시하기 위한 최선의 형태에서 설명되었다.
본 발명은 일련의 HDMI 분야에서 이용된다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (20)

  1. HDMI(High Definition Media Interface)를 사용하여 압축된 비디오 데이터를 전송하는 소스 기기의 데이터 송수신 방법에 있어서,
    싱크 기기가 연결되면 상기 싱크 기기로 EDID(Extended Display Identification Data) 판독을 요청하는 단계;
    상기 싱크 기기로부터 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 수신하는 단계;
    상기 EDID에 기초하여 결정된 동작 파라미터 정보를 전송하는 단계로서, 상기 동작 파라미터 정보는 압축 메타데이터를 포함하는, 전송 단계; 및
    상기 압축된 비디오 데이터를 전송하는 단계를 포함하는, 소스 기기의 데이터 송수신 방법.
  2. 제 1 항에 있어서,
    상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 수신되는, 소스 기기의 데이터 송수신 방법.
  3. 제 1 항에 있어서,
    상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 전송되는, 소스 기기의 데이터 송수신 방법.
  4. 제 1 항에 있어서,
    상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화시키는 단계를 더 포함하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행되는, 소스 기기의 데이터 송수신 방법.
  5. 제 1 항에 있어서,
    상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우 상기 싱크 기기의 SCDCS에 포함된 상태 변화 정보를 판독하는 단계를 더 포함하는, 소스 기기의 데이터 송수신 방법.
  6. HDMI를 사용하여 압축된 비디오 데이터를 전송하는 소스 기기에 있어서,
    HDMI를 통해 데이터를 송수신하는 HDMI 송신기;
    상기 HDMI를 통해 전송하는 비디오 데이터을 압축하는 비디오 인코딩 유닛; 및
    상기 HDMI 송신기 및 상기 비디오 인코딩 유닛을 컨트롤하는 컨트롤 유닛을 포함하며,
    상기 소스 기기는,
    싱크 기기가 연결되면 상기 싱크 기기로 EDID(Extended Display Identification Data) 판독을 요청하고,
    상기 싱크 기기로부터 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 수신하고,
    상기 EDID에 기초하여 결정된 동작 파라미터 정보를 전송하며, 상기 동작 파라미터 정보는 압축 메타데이터를 포함하고,
    상기 압축된 비디오 데이터를 전송하는, 소스 기기.
  7. 제 6 항에 있어서,
    상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 수신되는, 소스 기기
  8. 제 6 항에 있어서,
    상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 전송되는, 소스 기기.
  9. 제 6 항에 있어서,
    상기 소스 기기는, 상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행되는, 소스 기기.
  10. 제 6 항에 있어서,
    상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우 상기 싱크 기기의 SCDCS에 포함된 상태 변화 정보를 판독하는, 소스 기기.
  11. HDMI(High Definition Media Interface))를 사용하여 압축된 비디오 데이터를 수신하는 싱크 기기의 데이터 송수신 방법에 있어서,
    연결된 소스 기기로부터 EDID(Extended Display Identification Data) 판독을 요청받는 단계;
    상기 소스 기기로 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 전송하는 단계;
    상기 소스 기기로부터 압축 메타데이터를 포함하는 동작 파라미터 정보를 수신하는 단계; 및
    상기 압축된 비디오 데이터를 수신하는 단계를 포함하는, 싱크 기기의 데이터 송수신 방법.
  12. 제 11 항에 있어서,
    상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 전송되는, 싱크 기기의 데이터 송수신 방법.
  13. 제 11 항에 있어서,
    상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 수신되는, 싱크 기기의 데이터 송수신 방법.
  14. 제 11 항에 있어서,
    상기 소스 기기에 의해 상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화하는 단계를 더 포함하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행되는, 싱크 기기의 데이터 송수신 방법.
  15. 제 11 항에 있어서,
    상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우, 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 상태 변화 정보를 기입하고, 상기 소스 기기로 판독 요청 메시지를 전송하는 단계를 더 포함하는, 싱크 기기의 데이터 송수신 방법.
  16. HDMI(High Definition Media Interface)를 사용하여 압축된 비디오 데이터를 수신하는 싱크 기기에 있어서,
    HDMI를 통해 송수신하는 HDMI 수신기;
    상기 HDMI를 통해 수신하는 비디오 데이터을 압축해제하는 비디오 디코딩 유닛; 및
    HDMI 수신기 및 상기 비디오 디코딩 유닛을 컨트롤하는 컨트롤 유닛을 포함하며,
    상기 싱크 기기는,
    연결된 소스 기기로부터 EDID(Extended Display Identification Data) 판독을 요청받고, 상기 요청에 따라 상기 소스 기기로 상기 싱크 기기의 압축해제 능력 정보를 포함하는 EDID를 전송하고,
    상기 소스 기기로부터 압축 메타데이터를 포함하는 동작 파라미터 정보를 수신하고,
    상기 압축된 비디오 데이터를 수신하는, 싱크 기기.
  17. 제 16 항에 있어서,
    상기 압축해제 능력 정보는, 상기 싱크 기기가 압축해제를 지원하는지의 여부 또는 압축해제 관련 특성 정보 중 적어도 하나를 나타내며, 상기 압축해제 능력 정보는 HF-VSDB(HDIM Forum-Vendor Specific Data Block)으로서 전송되는, 싱크 기기.
  18. 제 16 항에 있어서,
    상기 압축 메타데이터는, 상기 압축된 비디오 데이터의 특성 정보를 포함하며, 상기 압축 메타데이터는 인포프레임으로서 수신되는, 싱크 기기.
  19. 제 16 항에 있어서,
    상기 싱크 기기는, 상기 소스 기기에 의해 상기 싱크 기기의 압축해제 기능을 활성화 또는 비활성화하며, 상기 압축해제 기능의 활성화 또는 비활성화는 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 압축해제 활성화 정보를 사용하여 수행되는, 싱크 기기
  20. 제 16 항에 있어서,
    상기 싱크 기기의 압축해제 기능의 상태 변화가 발생한 경우, 상기 싱크 기기의 SCDCS(Status and Control Data Channel Structure)에 포함된 상태 변화 정보를 기입하고, 상기 소스 기기로 판독 요청 메시지를 전송하는, 싱크 기기.
PCT/KR2015/002418 2014-03-13 2015-03-12 Hdmi를 사용한 데이터 송수신 기기 및 방법 Ceased WO2015137751A1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US15/125,939 US9779687B2 (en) 2014-03-13 2015-03-12 Device and method for transmitting and receiving data using HDMI
KR1020167027463A KR20160133475A (ko) 2014-03-13 2015-03-12 Hdmi를 사용한 데이터 송수신 기기 및 방법
EP15762311.7A EP3119100A4 (en) 2014-03-13 2015-03-12 Device and method for transmitting and receiving data using hdmi
CN201580013370.1A CN106464964B (zh) 2014-03-13 2015-03-12 利用hdmi发送和接收数据的装置和方法
JP2016556950A JP6522643B2 (ja) 2014-03-13 2015-03-12 Ｈｄｍｉを使用したデータ送受信機器及び方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201461952139P 2014-03-13 2014-03-13
US61/952,139 2014-03-13

Publications (1)

Publication Number Publication Date
WO2015137751A1 true WO2015137751A1 (ko) 2015-09-17

Family

ID=54072110

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2015/002418 Ceased WO2015137751A1 (ko) 2014-03-13 2015-03-12 Hdmi를 사용한 데이터 송수신 기기 및 방법

Country Status (6)

Country Link
US (1) US9779687B2 (ko)
EP (1) EP3119100A4 (ko)
JP (1) JP6522643B2 (ko)
KR (1) KR20160133475A (ko)
CN (1) CN106464964B (ko)
WO (1) WO2015137751A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118227565A (zh) * 2022-12-20 2024-06-21 北京嘀嘀无限科技发展有限公司 一种数据管理方法、装置和电子设备
US12445421B2 (en) 2021-12-08 2025-10-14 Analog Devices, Inc. Apparatus, methods, and systems for pre-authentication, keep-authentication, and regain-authentication

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9883184B2 (en) 2014-10-07 2018-01-30 Qualcomm Incorporated QP derivation and offset for adaptive color transform in video coding
US10754537B2 (en) * 2015-09-16 2020-08-25 Lg Electronics Inc. Method and apparatus for processing human interface device (HID)-based data using high-speed interface
US10587852B2 (en) * 2015-10-06 2020-03-10 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US10574988B2 (en) * 2015-11-19 2020-02-25 Qualcomm Incorporated System and methods for reducing slice boundary visual artifacts in display stream compression (DSC)
US10319336B2 (en) * 2016-02-16 2019-06-11 Samsung Electronics Co., Ltd. Electronic device and control method thereof
US10551988B2 (en) * 2016-02-29 2020-02-04 Dell Products L.P. Multi-input display
CN106937071A (zh) * 2017-03-10 2017-07-07 微鲸科技有限公司 一种edid自适应方法及系统
US11768545B2 (en) 2017-04-05 2023-09-26 Fibernet Ltd. Secured KVM switching device with unidirectional communications
EP3614681B1 (en) * 2017-04-21 2025-02-19 Panasonic Intellectual Property Management Co., Ltd. Reproduction device, reproduction method, display device, and display method
EP3574392B1 (en) * 2017-07-07 2025-08-27 Hewlett-Packard Development Company, L.P. Selection of an extended display identification data standard
CN107948709B (zh) * 2017-12-05 2021-04-27 晶晨半导体(上海)股份有限公司 一种机顶盒的输出参数设置方法及系统
KR102476605B1 (ko) * 2018-05-11 2022-12-13 삼성전자주식회사 전자 장치 및 그 제어 방법
US10839565B1 (en) 2019-08-19 2020-11-17 Samsung Electronics Co., Ltd. Decoding apparatus and operating method of the same, and artificial intelligence (AI) up-scaling apparatus and operating method of the same
CN110895549B (zh) * 2019-09-04 2022-12-06 成都四方伟业软件股份有限公司 一种量化数据检索方法及系统
KR102674618B1 (ko) * 2019-12-13 2024-06-12 삼성전자주식회사 디스플레이 장치 및 그 동작 방법
CN118921520A (zh) * 2019-12-17 2024-11-08 索尼集团公司 接收装置、用于控制接收装置的方法和发送/接收系统
JP7437220B2 (ja) * 2020-04-01 2024-02-22 株式会社東芝 アダプタ装置及び通信方法
CN111918013B (zh) * 2020-08-13 2022-04-08 广东博华超高清创新中心有限公司 一种hdmi 8k100/120视频判断和输出的方法及装置
CN112073659B (zh) * 2020-09-08 2023-03-21 海信视像科技股份有限公司 Hdmi接口控制方法、装置及显示设备
WO2022152320A1 (zh) * 2021-01-14 2022-07-21 海信视像科技股份有限公司 显示设备、音画参数调节方法
CN112911170B (zh) * 2021-03-26 2021-09-21 深圳智尚视讯科技有限公司 用于hdmi的兼容性提升方法、存储介质、设备及系统
KR20220165395A (ko) * 2021-06-08 2022-12-15 엘지전자 주식회사 싱크 장치, 소스 장치 및 hdmi 제어 방법
TWI783588B (zh) * 2021-07-23 2022-11-11 瑞昱半導體股份有限公司 可應用於在顯示裝置中進行多畫面處理之縮放器積體電路
WO2023136610A1 (ko) * 2022-01-11 2023-07-20 엘지전자 주식회사 비디오 데이터 송수신 방법 및 이에 대한 장치
CN114598751A (zh) * 2022-05-09 2022-06-07 合肥宏晶半导体科技有限公司 高清多媒体接口hdmi接收装置、数据传输方法及设备
CN114666415B (zh) * 2022-05-16 2022-09-09 宏晶微电子科技股份有限公司 数据传输方法、显示设备及控制设备
CN115514992B (zh) * 2022-09-23 2024-11-26 深圳市音络科技有限公司 一种hdmi数据传输方法、系统、终端及存储介质
JP7444955B1 (ja) * 2022-12-02 2024-03-06 レノボ・シンガポール・プライベート・リミテッド 情報処理装置の製造方法及びプログラム
WO2024215107A1 (ko) * 2023-04-11 2024-10-17 엘지전자 주식회사 Source와 sink 간에 지원하는 dsc 정보를 구별하기 위한 장치 및 방법
WO2025089873A1 (ko) * 2023-10-25 2025-05-01 엘지전자 주식회사 소스와 싱크 간에 소스 능력 정보를 공유하기 위한 장치 및 방법
CN121464641A (zh) * 2023-11-30 2026-02-03 华为技术有限公司 一种视频传输方法及设备
US12581026B2 (en) * 2024-04-08 2026-03-17 Mediatek Inc. Power saving method for high definition multimedia interface

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080009063A (ko) * 2005-03-15 2008-01-24 라디오스파이어 네트웍스, 인크. 일반화된 콘텐츠 소오스와 일반화된 콘텐츠 싱크간의콘텐츠의 무선 전달을 위한 시스템, 방법, 및 장치
US20100247059A1 (en) * 2009-03-31 2010-09-30 Samsung Electronics Co., Ltd. Method and apparatus for transmitting compressed data using digital data interface, and method and apparatus for receiving compressed data using digital data interface
KR20100111609A (ko) * 2008-02-04 2010-10-15 소니 주식회사 영상신호 송신 장치, 영상신호 송신 방법, 영상신호 수신 장치 및 영상신호 수신 방법
US20110142427A1 (en) * 2009-12-04 2011-06-16 General Instrument Corporation Method to seamlessly insert audio clips into a compressed broadcast audio stream
WO2012166512A2 (en) * 2011-05-31 2012-12-06 Dolby Laboratories Licensing Corporation Video compression implementing resolution tradeoffs and optimization

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007023939A1 (ja) * 2005-08-26 2007-03-01 Matsushita Electric Industrial Co., Ltd. 信号ソース装置
KR20080058740A (ko) * 2006-12-22 2008-06-26 삼성전자주식회사 디지털 방송 수신 장치 및 시간 동기화 방법
KR20110091852A (ko) * 2008-12-01 2011-08-16 소니 주식회사 송신 장치 및 전송 데이터 포맷 결정 방법
WO2010140199A1 (ja) * 2009-06-01 2010-12-09 パナソニック株式会社 映像データの伝送方法
JP2011124925A (ja) * 2009-12-14 2011-06-23 Sony Corp 出力制御装置、出力制御方法、プログラム、及び出力制御システム
JP5771986B2 (ja) * 2010-12-28 2015-09-02 ソニー株式会社 電子機器、電子機器の制御方法および電子機器システム
JP5673172B2 (ja) * 2011-02-09 2015-02-18 ソニー株式会社 電子機器、電子機器における立体画像情報送信方法、および電子機器における立体画像情報受信方法
JP2013115456A (ja) * 2011-11-25 2013-06-10 Hitachi Consumer Electronics Co Ltd 画像伝送装置、および画像伝送方法
US20140347559A1 (en) * 2011-12-28 2014-11-27 Sanyo Electric Co., Ltd. Video display apparatus

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080009063A (ko) * 2005-03-15 2008-01-24 라디오스파이어 네트웍스, 인크. 일반화된 콘텐츠 소오스와 일반화된 콘텐츠 싱크간의콘텐츠의 무선 전달을 위한 시스템, 방법, 및 장치
KR20100111609A (ko) * 2008-02-04 2010-10-15 소니 주식회사 영상신호 송신 장치, 영상신호 송신 방법, 영상신호 수신 장치 및 영상신호 수신 방법
US20100247059A1 (en) * 2009-03-31 2010-09-30 Samsung Electronics Co., Ltd. Method and apparatus for transmitting compressed data using digital data interface, and method and apparatus for receiving compressed data using digital data interface
US20110142427A1 (en) * 2009-12-04 2011-06-16 General Instrument Corporation Method to seamlessly insert audio clips into a compressed broadcast audio stream
WO2012166512A2 (en) * 2011-05-31 2012-12-06 Dolby Laboratories Licensing Corporation Video compression implementing resolution tradeoffs and optimization

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3119100A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12445421B2 (en) 2021-12-08 2025-10-14 Analog Devices, Inc. Apparatus, methods, and systems for pre-authentication, keep-authentication, and regain-authentication
CN118227565A (zh) * 2022-12-20 2024-06-21 北京嘀嘀无限科技发展有限公司 一种数据管理方法、装置和电子设备

Also Published As

Publication number Publication date
JP6522643B2 (ja) 2019-05-29
JP2017515333A (ja) 2017-06-08
CN106464964B (zh) 2019-09-10
EP3119100A4 (en) 2018-01-17
KR20160133475A (ko) 2016-11-22
US9779687B2 (en) 2017-10-03
CN106464964A (zh) 2017-02-22
US20170092226A1 (en) 2017-03-30
EP3119100A1 (en) 2017-01-18

Similar Documents

Publication Publication Date Title
US9779687B2 (en) Device and method for transmitting and receiving data using HDMI
US10085058B2 (en) Device and method for transmitting and receiving data using HDMI
US9819995B2 (en) Device and method for data transmission and reception using HDMI
KR102397289B1 (ko) Hdmi를 사용하여 데이터를 송수신하기 위한 방법 및 장치
EP2983354B1 (en) Video data processing method and device for display adaptive video playback
US9014258B2 (en) Transmission device and method of determining transmission date format
US10474241B2 (en) Method and device for transmitting/receiving data using HDMI
CN102232296B (zh) 发送设备和发送数据格式确定方法
US9936236B2 (en) Video processing method and video processing apparatus
EP2071849A1 (en) Receiver, delayed information transmitting method for receivers, audio output device, and delay control method for audio output devices
US10162769B2 (en) Method and apparatus for transmitting and receiving data using HDMI
US10754537B2 (en) Method and apparatus for processing human interface device (HID)-based data using high-speed interface
US12587704B2 (en) Video data transmission and reception method using high-speed interface, and apparatus therefor
US10009650B2 (en) Method and apparatus for processing object-based audio data using high-speed interface
EP2995080B1 (en) Devices and methods for communicating sideband data with non-compressed video
KR20260071226A (ko) 프레임 레이트가 고정된 비디오와 관련된 동작을 수행하기 위한 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15762311

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016556950

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15125939

Country of ref document: US

REEP Request for entry into the european phase

Ref document number: 2015762311

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015762311

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20167027463

Country of ref document: KR

Kind code of ref document: A