Device and method for supporting quick media switching

Abstract

The present disclosure relates to a device and a method for transmitting information required when a quick media switch (QMS) function is operated in a wired audio / video (AV) transmission standard technology such as HDMI. Specifically, the present disclosure relates to a device and a method for supporting a seamless operation without screen blanking by transferring, in advance, video format change information such as chroma sampling, a pixel format, or a high dynamic range (HDR) format as well as frame rate change information to a sink device by a source device during a QMS operation.

Description

Device and method for supporting rapid media switching

[0001] The present disclosure relates to an apparatus and method for transmitting information necessary for the operation of a Quick Media Switch (QMS) function in a wired AV (Audio / Video) transmission standard technology such as HDMI. Specifically, the present disclosure relates to an apparatus and method for supporting seamless operation without screen blanking by having a Source device transmit not only frame rate change information but also video format change information, such as chroma sampling, pixel format, or HDR (High Dynamic Range) format, to a Sink device in advance during QMS operation.

[0002]

[0003] The present disclosure relates to wired AV (Audio / Video) transmission standard technologies such as HDMI, and in particular to an apparatus and method for transmitting necessary information to support seamless operation when a function such as a Quick Media Switch (QMS) is in operation.

[0004] QMS is basically a function that operates by transmitting information about changes from the source device to the sink device in advance in situations where the frame rate changes. For example, when switching from a set-top box (Source) menu screen (e.g., 60Hz) to movie content (e.g., 24Hz), the QMS function aims to switch media smoothly without screen flickering.

[0005] However, conventional technology had a problem where blank noise, or screen flickering, occurred when the Sink device processed video transmitted from the Source device during QMS operation. This became a factor that hindered the seamless switching, which is the original purpose of QMS.

[0006] These problems arise because the source device transmits only frame rate switching information to the sink device. For example, when the frame rate is switched from 24Hz to 60Hz, the conventional source device transmits only the information of the frame rate to be changed (60Hz) to the sink device. However, in addition to the frame rate, the actual video stream may also change various video formats such as pixel format, chroma sampling, or HDR (High Dynamic Range) format. Since the conventional technology does not transmit this additional format change information to the sink device in advance, there is a problem in that the sink device cannot respond to this and screen flickering occurs.

[0007]

[0008] To solve the aforementioned problems, the present disclosure provides an apparatus and method for supporting seamless operation without blank noise in a sink device even when video formats such as pixel format, chroma sampling, and HDR format are changed together with the frame rate during Quick Media Switch (QMS) operation.

[0009] In addition, the present disclosure provides an apparatus and method in which a source device transmits video format information to a sink device in advance via an Extended Metadata Packet (EM) one frame prior to the change. This enables the sink device to detect the format change of the source device in advance and to display a seamless video by using techniques such as frame repetition to minimize blanks.

[0010] In addition, the present disclosure provides an apparatus and method that support a novel QMS operation method that allows frame drops so that it can operate under a 'visually seamless' concept when seamless operation is not possible.

[0011] The technical problems to be solved in this disclosure are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which this disclosure belongs from the description below.

[0012]

[0013] According to various embodiments of the present disclosure, a method of operating a source device comprises the steps of: determining that a change in frame rate and a change in video format occur in a next frame following a current frame of a video stream; changing the frame rate from a first frame rate to a second frame rate in the next frame following the current frame, and changing the video format from a first video format to a second video format in the next frame following the current frame; generating metadata of the next frame including information of the second frame rate and the second video format; inserting the metadata of the next frame into a Frame Accurate Packet Area (FAPA) of the current frame; and transmitting first video data of the current frame to a sink device, wherein the FAPA of the current frame within the first video data includes the metadata of the next frame.

[0014] According to various embodiments of the present disclosure, a method of operating a sink device is provided, comprising the steps of: receiving first video data of a current frame from a source device; wherein the Frame Accurate Packet Area (FAPA) of the current frame within the first video data includes metadata of a next frame, wherein in the next frame following the current frame, the frame rate is changed from a first frame rate to a second frame rate, and in the next frame following the current frame, the video format is changed from a first video format to a second video format, and the metadata includes information of the second frame rate and the second video format; identifying the change of the frame rate and the video format in the next frame following the current frame based on the metadata; and receiving second video data of the next frame from the source device based on the second frame rate and the second video format.

[0015] According to various embodiments of the present disclosure, a source device comprises: a processor; a memory; and a transceiver, wherein the memory stores instructions for performing operations based on execution by the processor, the operations comprising: determining that a change in frame rate and a change in video format occur in a next frame following a current frame of a video stream; that in the next frame following the current frame, the frame rate is changed from a first frame rate to a second frame rate, and in the next frame following the current frame, the video format is changed from a first video format to a second video format; generating metadata of the next frame including information of the second frame rate and the second video format; and inserting the metadata of the next frame into the Frame Accurate Packet Area (FAPA) of the current frame. A source device is provided that includes the step of transmitting first video data of the current frame to a sink device, wherein the FAPA of the current frame within the first video data includes the metadata of the next frame.

[0016]

[0017] To solve the aforementioned problems, the present disclosure may provide a device and method for supporting seamless operation without blank noise in a sink device even when video formats such as pixel format, chroma sampling, and HDR format are changed together with the frame rate during Quick Media Switch (QMS) operation.

[0018] In addition, the present disclosure may provide a device and method in which a source device transmits video format information to a sink device in advance, via an Extended Metadata Packet (EM), one frame prior. This enables the sink device to detect the format change of the source device in advance and to display a seamless video by using techniques such as frame repetition to minimize blanks.

[0019] In addition, the present disclosure may provide a device and method that support a novel QMS operation method that allows frame drops so that it can operate under a 'visually seamless' concept when seamless operation is not possible.

[0020]

[0021] The drawings attached below are intended to aid in understanding the present disclosure and may provide embodiments of the present disclosure together with the detailed description. However, the technical features of the present disclosure are not limited to specific drawings, and the features disclosed in each drawing may be combined with one another to form new embodiments. Reference numerals in each drawing may denote structural elements.

[0022] FIG. 1 is a block diagram showing a system according to various embodiments of the present disclosure.

[0023] FIG. 2 is a block diagram showing an example of the structure of a Source device and a Sink device according to various embodiments of the present disclosure.

[0024] FIG. 3 is a block diagram showing an example of the structure of a Source device and a Sink device according to various embodiments of the present disclosure.

[0025] FIG. 4 shows an example of a timing configuration (FAPA_start_location=0) of a FAPA (Frame Accurate Packet Area) according to one embodiment of the present disclosure.

[0026] FIG. 5 shows an example of a timing configuration (FAPA_start_location=1) of a FAPA (Frame Accurate Packet Area) according to another embodiment of the present disclosure.

[0027] Figure 6 shows an example of an initial connection sequence between a source device and a sink device according to the prior art.

[0028] Figure 7 shows an example of frame rate information transmission during the operation of a Quick Media Switch (QMS) according to the prior art.

[0029] FIG. 8 shows an example of an improved Quick Media Switch (QMS) operation sequence according to one embodiment of the present disclosure.

[0030] FIG. 9 illustrates an example of a metadata structure to which video format information may be added according to an embodiment of the present disclosure.

[0031] FIG. 10 is a drawing illustrating an example of a method of operation of a Source device according to various embodiments of the present disclosure.

[0032] FIG. 11 is a drawing illustrating an example of a method of operation of a Sink device according to various embodiments of the present disclosure.

[0033]

[0034] In various embodiments of the present disclosure, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in various embodiments of the present disclosure, "A or B" may be interpreted as "A and / or B." For example, in various embodiments of the present disclosure, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0035] In various embodiments of the present disclosure, a slash ( / ) or a comma used may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0036] In various embodiments of the present disclosure, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in various embodiments of the present disclosure, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0037] Additionally, in various embodiments of the present disclosure, “at least one of A, B and C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.” Also, “at least one of A, B or C” or “at least one of A, B and / or C” may mean “at least one of A, B and C.”

[0038]

[0039] FIG. 1 is a block diagram showing a system according to various embodiments of the present disclosure.

[0040] Hereinafter, devices that transmit and receive video, audio, and control data will be collectively referred to as AV (audio / video) systems. Examples of AV systems include HDMI and DisplayPort.

[0041] Referring to FIG. 1, the AV system may include a source device (100) and a sink device (200). In particular, in the AV system, the device that transmits video / audio data corresponds to the source device (100), and the device that receives video / audio data corresponds to the sink device (200). At this time, cables and connectors may be provided as physical devices that connect the two devices to support data transmission and reception.

[0042] Cables and connectors can perform pairing of four channels providing TMDS (Transition Minimized Differential Signaling) data channels and TMDS clock channels. TMDS data channels can be used to transmit video data, audio data, and auxiliary data.

[0043] Additionally, the AV system provides the VESA (Video Electronics Standards Association) Display Data Channel (DDC). The DDC is used for exchanging configuration and status information between source and sink devices. The CEC protocol can provide high-level control functions between various audio-visual products in the user environment and may be used optionally. Furthermore, the optional HDMI Ethernet and Audio Return Channel (HEAC) may provide Ethernet-compatible data networking between the Audio Return Channel (ARC) and connected devices from the opposite direction from the TMDS.

[0044] Video data, audio data, and auxiliary data can be transmitted / received through three TMDS data channels. The TMDS clock typically runs the video pixel rate and is transmitted through the TMDS clock channel. The TMDS clock can be used as a frequency reference for data recovery in the three TMDS data channels at the receiver. At the source device, 8 bits of data per TMDS data channel can be converted into a 10-bit DC-balanced, transition-minimized sequence and transmitted serially at a rate of 10 bits per TMDS clock period.

[0045] To transmit audio data and auxiliary data through TMDS channels, AV systems use a packet structure. To achieve high reliability for audio data and control data, data can be transmitted as 10-bit words generated using BCH error correction codes and error reduction coding.

[0046] The source device can read the E-EDID (Enhanced Extended Display Identification Data) of the DDC (Display Data Channel) sink device to determine the configuration information and available functions of the sink device. The E-EDID may also be referred to as EDID information below.

[0047] The utility line can be used for optional extension functions such as HEAC.

[0048] The source device (100) can receive EDID (Extended Display Identification Data) information from the sink device (200) through a DDC channel. The source device (100) can parse the received EDID information to recognize configuration information and support functions of the sink device (200). The EDID information may include at least one block containing various information regarding the sink device (200).

[0049] In particular, EDID information according to one embodiment of the present disclosure may include information regarding the function and power supply capability of the sink device (200) in power transmission and reception. The source device (100) recognizes the power transmission / reception capability of the sink device (200) through this EDID information and, accordingly, can transmit power to the sink device (200) or receive power from the sink device (200).

[0050] The source device (100) includes at least one of a display unit (110), a user input interface unit (120), a control unit (180), a transmitter (Tx), a memory unit (140), a storage unit (150), a multimedia unit (160), a power control unit (130), and a power supply unit (170).

[0051] The sink device (200) includes at least one of an EDID EEPROM (210), a power control unit (220), a display unit (230), a user input interface unit (240), a receiver (Rx), a control unit (280), a power supply unit (250), a memory unit (260), and a multimedia unit (270). In the following description, the description of units performing the same operation will not be duplicated.

[0052] The source device (100) represents a physical device that transmits or streams content stored in the storage unit (150) to the sink device (200). The source device (100) can send a request message to the sink device (200) or receive and process a request message received from the sink device (200). The source device (100) can provide a UI that processes a response message sent by the sink device (200) in response to the transmitted request message and delivers it to the user, and if the source device (100) includes a display unit (110), this UI can be provided as a display. Additionally, the source device (100) can request power to be supplied from the sink device (200).

[0053] The sink device (200) receives content from the source device (100) and can send a request message to the source device (100) or process a message received from the source device (100) and send a response message. The sink device (200) can also provide a User Interface (UI) that processes a response message received from the source device (100) and delivers it to a user, and if the sink device (200) includes a display unit, it can provide this UI as a display. Additionally, the sink device (200) can supply power requested by the source device (100) to the source device (100).

[0054] The user input interface unit (120, 240) can receive user action or input, and as an example, the user input interface (120, 240) may correspond to a remote controller, a voice receiving / recognition device, a touch input sensing / receiving device, etc.

[0055] The control unit (180, 280) can control the overall operation of each device. In particular, the control unit (180, 280) can perform communication between the units included in each device and control the operation of each unit.

[0056] The memory unit (140, 260) represents a volatile physical device in which various types of data are temporarily stored.

[0057] A storage unit (150) represents a non-volatile physical device capable of storing various types of data.

[0058] The EDID EEPROM (210) represents an EEPROM that stores EDID information.

[0059] The memory unit (140, 260), storage unit (150), and EDID EEPROM (210) described above all serve the function of storing data, and they may all be collectively referred to as memory units.

[0060] The display unit (110, 230) can display received data or content, data stored in the memory unit, UI, etc., under the control of the control unit (180, 280).

[0061] The multimedia unit (160, 270) can play various types of multimedia. The multimedia unit (160, 270) may be implemented separately from the control unit (180, 280) or may be implemented as a single physical configuration with the control unit (180, 280).

[0062] The power supply unit (170, 250) can supply power required for the operation of the source device (100), the sink device (200), and the units included therein.

[0063] The transmitter (Tx) is a unit equipped in the source device (100) for transmitting and receiving data, and performs data transmission and reception including not only audio / video data but also messages such as commands, requests, actions, and responses between devices.

[0064] The receiver (Rx) is a unit equipped in the sink device (200) for transmitting and receiving data, and performs data transmission and reception including not only audio / video data but also messages such as commands, requests, actions, and responses between devices.

[0065] The power control unit (130, 220) can manage and control power transmission and reception between devices through the transceiver.

[0066] Among the units described above, units other than the transmitter (Rx), receiver (Tx), and control unit (180, 280) may be optionally included in the source device (100) or sink device (200) according to the embodiment and may not correspond to essential component units.

[0067] Previously, power transfer between source and sink devices was not supported in AV systems. As a result, when operating portable devices for extended periods, there was the inconvenience of having to constantly connect an external power cable to ensure optimal operation. To resolve this inconvenience, this specification proposes a method to ensure optimal operation of the AV system without the need for a separate external device by enabling a wired interface in the AV system to support a power transfer function.

[0068] For the sake of convenience of explanation, the device supplying (or transmitting) power will be referred to as the P-Source device, and the device receiving (or supplying) power will be referred to as the P-Sync device. Additionally, a device that simultaneously supports the functions of both the P-Source device and the P-Sync device will be referred to as a Dual device.

[0069]

[0070] Various embodiments of the present disclosure relate to a method of distinguishing DSC versions.

[0071] The present disclosure relates to a device using an Interface, DisplayPort, and HDMI, and concerns an invention regarding checking support for DSC transmission between a Sink device and a Source device prior to transmission, and relates to information exchange between devices. It describes a method for supporting a gesture extraction function and directly transmitting data at the Sink / Source devices, a method for providing gesture information of the Sink / Source devices based on the extracted information, a method for transmitting changes in gesture information of the Sink / Source devices to the Sink / Source devices, and an operation thereof.

[0072]

[0073] Conventional technology only involved acquiring information from an external video / audio capture device directly connected to the source device: generally, to receive gesture information, the technology supporting the capture device had to be implemented so that it was supported on the source device. In sink devices, technology supporting gesture-related devices is expanding, but the source device could not use such devices.

[0074]

[0075] The main components of the method proposed in this disclosure are as follows:

[0076] 1. The main transmission line uses DDC lined.

[0077] 2. Regarding DSC support, the Source device reads the Sink device's information using EDID / DisplayID (HDMI / DisplayPort).

[0078] 3-1. Read the Source device information on the Sink device regarding DSC support using SCDC (HDMI).

[0079] 3-2. Read information from the Source device regarding DSC support on the Sink device using the Aux Channel (DisplayPort).

[0080] 4-1. The Source of the current Bus Interface checks the HDMI DSC version and transmits DSC Data & Info that can operate at the Sink (HDMI).

[0081] 4-2. The Source of the current Bus Interface checks the Display DSC version and transmits DSC Data & Info that can be operated at the Sink (DisplayPort).

[0082] 5. Using the HDMI HEC of the current Bus Interface, the Source device checks the DSC version information of the Sink device.

[0083]

[0084] According to various embodiments of the present disclosure, as models incorporating new Sink / Source devices with various types of DSC slices are expected to become more diverse, information can be exchanged in advance regarding connection compatibility to avoid situations where video is corrupted after audio / video transmission. The new Sink provides convenience by distinguishing between Legacy Sources and New Sources, enabling consumers who possess only one of the Sink or Source devices equipped with a camera to utilize a solution using gestures.

[0085]

[0086] Background art for various embodiments of the present disclosure

[0087] FIG. 2 is a block diagram showing an example of the structure of a Source device and a Sink device according to various embodiments of the present disclosure.

[0088] A detailed description of each component shown in Fig. 2 is as follows.

[0089] (1) Source Device

[0090] A device that sends request messages issuing commands to a Sink Device or receives and processes request messages from a Sink Device.

[0091] A device that supports a UI that processes a response message received from a Sink Device after sending the above request message and delivers it to the user, and a display device that displays the UI, and a device that supports a user input interface that receives user actions through the UI.

[0092] A device that supports a display device for providing a UI that receives, processes, and transmits a request message from the above-mentioned Sink Device to the user, and a device that supports a user input interface that receives user actions through the UI.

[0093] A physical device that transmits or streams content stored in the Source Device's Content Storage to the Sink Device.

[0094] (2) Sink Device

[0095] A device that sends request messages issuing commands to a Source Device or receives and processes request messages from a Source Device.

[0096] A device that supports a UI that processes a response message received from a Source Device after sending the above request message and delivers it to the user, and a display device that displays the UI, and a device that supports a user input interface that receives user actions through the UI.

[0097] A device that supports a display device for providing a UI that receives, processes, and transmits a request message from the above-mentioned Source Device to the user, and a device that supports a user input interface that receives user actions through the UI.

[0098] A physical device that receives content from a source device or streams it to provide content rendering to the user.

[0099] (3) Network interface

[0100] A physical device that enables the transmission of messages or data, such as commands, requests, actions, and responses, between devices.

[0101] (4) Memory unit

[0102] As an optional device implemented in various types of devices, a volatile physical device (e.g., Memory) in which various types of data are temporarily stored

[0103] (5) Control unit

[0104] Overall operation control of Source and Sink Devices

[0105] (6) Display

[0106] Data received through the network interface or data stored in the Content Storage is displayed on the screen under the control of the Control Unit.

[0107] (7) Multimedia module

[0108] Device for playing various types of multimedia

[0109] The multimedia module can be implemented within the control unit or separately from the control unit.

[0110] (8) Storage

[0111] A non-volatile physical device capable of storing various types of data (e.g., SD card)

[0112] (9) Power Supply

[0113] A device that receives external and internal power under the control of a control unit and supplies the power necessary for the operation of each component.

[0114] (10) EDID / Display block (EEPROM, memory)

[0115] EEPROM storing EDID information

[0116] (11) Video Encoder

[0117] A device that compresses video to be transmitted via HDMI / DisplayPort Tx

[0118] (12) Video Decoder

[0119] A device that decompresses compressed video received via HDMI / DisplayPort Rx

[0120]

[0121] FIG. 3 is a block diagram showing an example of the structure of a Source device and a Sink device according to various embodiments of the present disclosure.

[0122] A detailed description of each component shown in Fig. 3 is as follows.

[0123] (1) Source Device

[0124] A device that sends request messages issuing commands to a Sink Device or receives and processes request messages from a Sink Device.

[0125] A device that supports a UI that processes a response message received from a Sink Device after sending the above request message and delivers it to the user, and a display device that displays the UI, and a device that supports a user input interface that receives user actions through the UI.

[0126] A device that supports a display device for providing a UI that receives, processes, and transmits a request message from the above-mentioned Sink Device to the user, and a device that supports a user input interface that receives user actions through the UI.

[0127] A physical device that transmits or streams content stored in the Source Device's Content Storage to the Sink Device.

[0128] (2) Sink Device

[0129] A device that sends request messages issuing commands to a Source Device or receives and processes request messages from a Source Device.

[0130] A device that supports a UI that processes a response message received from a Source Device after sending the above request message and delivers it to the user, and a display device that displays the UI, and a device that supports a user input interface that receives user actions through the UI.

[0131] A device that supports a display device for providing a UI that receives, processes, and transmits a request message from the above-mentioned Source Device to the user, and a device that supports a user input interface that receives user actions through the UI.

[0132] A physical device that receives content from a source device or streams it to provide content rendering to the user.

[0133] (3) Network interface

[0134] A physical device that enables the transmission of messages or data, such as commands, requests, actions, and responses, between devices.

[0135] (4) Memory unit

[0136] As an optional device implemented in various types of devices, a volatile physical device (e.g., Memory) in which various types of data are temporarily stored

[0137] (5) Control unit

[0138] Overall operation control of Source and Sink Devices

[0139] (6) Display

[0140] Data received through the network interface or data stored in the Content Storage is displayed on the screen under the control of the Control Unit.

[0141] (7) Multimedia module

[0142] Device for playing various types of multimedia

[0143] The multimedia module can be implemented within the control unit or separately from the control unit.

[0144] (8) Storage

[0145] A non-volatile physical device capable of storing various types of data (e.g., SD card)

[0146] (9) Power Supply

[0147] A device that receives external and internal power under the control of a control unit and supplies the power necessary for the operation of each component.

[0148] (10) EDID / Display block (EEPROM, memory)

[0149] EEPROM storing EDID information

[0150] (11) Video Encoder

[0151] A device that compresses video to be transmitted via HDMI / DisplayPort Tx

[0152] (12) Video Decoder

[0153] A device that decompresses compressed video received via HDMI / DisplayPort Rx

[0154]

[0155] 1. EDID (Extended Display Identification Data)

[0156] EDID is a type of data structure containing various information about a display device defined by VESA, and it is transmitted to the source device.

[0157] EDID is compatible with the upper 128 bytes from Version 1.0 to 1.4, and from version 1.3 onwards it is called Enhanced EDID, and an EDID extension block is added after the upper 128 bytes to insert additional data.

[0158] EDID was deprecated up to Version 1.2, and Version 1.3 is widely used in IT display devices, CE display devices, and video interfaces (e.g., HDMI).

[0159] The following Table 1 shows the configuration of the EDID.

[0160] Address No. Bytes Description 00h ~ 07h 8 Header information. Fixed as 00 FF FF FF FF FF FF 00. 08h ~ 11h 10 Vendor / Product Identification. Manufacturer, product code, serial number, and manufacturing date 12h ~ 13h 2 EDID Structure Version / Revision 14h ~ 18h 5 Basic Display Parameters / Features. Video Input definition (analog or digital), Max. Horizontal Image Size, Max. Vertical Image Size, Display Transfer Characteristic (Gamma), Feature Support (Standby, Suspend, Display Type, Standard Default Color space (sRGB), Preferred Timing Mode support, etc.) 19h ~ 22h 10 Color Characteristics. Information related to color and white point. Displayed as xy coordinates of Red, Green, Blue, and White in color space. 23h ~ 25h 3 Established Timings. Describes commonly used timing modes. 26h ~ 35h 16 Standard Timings. Eight standard timing descriptors are described, with each descriptor containing information on the range of horizontal active pixels, Image Aspect Ratio, and Refresh Rate (60 ~ 123Hz). Timing not included in Established Timing is described in accordance with the VESA DMT standard or using timing information calculated via GTF. 36h ~ 7 Dh 7 2 Detailed Timing Descriptors.Detailed timing information for the resolutions supported by the display is described, and there are four descriptors. The first descriptor is Preferred Detailed timing. The second descriptor indicates secondary detailed timing or additional monitor information (Serial Number, Range Limits, Name), and the remaining two descriptors contain additional monitor information. Monitor Range Limit and Name must be specified. 7Eh1Extension Flag. Specifies the number of additional EDID extension blocks. 7Fh1Checksum.

[0161] 2. CEA 861 EDID Extension Block

[0162] The timing information described in the EDID is for IT display devices, and the EDID 1.3 Extension Block from CEA 861 is used to represent the timing information of CE display devices.

[0163] Version 3 CEA Extension is defined in the CEA 861B standard and specifies four optional Data Blocks (Video, Audio, Speaker Allocation, Vendor Specific).

[0164]

[0165] Byte #0Tag. 0x02 1Revision Number. 0x03 2Byte number where the 18-byte Detailed Timing Descriptor (DTD) starts Offset d value 3Indication of underscan, audio support, YCBCR 4:4:4 or YCBCR 4:2:2 support, number of supported native DTDs 4Start of data block collectiond -1End of data block collectiond Start of 18-byte DTD. Follows EDID DTD format. d+(18n)-1End of 18-byte DTD. n is the number of descriptors included +(18n)Beginning of Padding. 0x0012 6End of Padding. 0x0012 7Checksum

[0166] The following Table 3 shows the Video Data Block.

[0167] Byte #Bits 5-7Bits 0-40Video Tag CodeShort Video Descriptor Total number of bytes (L1)1CEA Short Video Descriptor 1L1CEA Short Video Descriptor L1

[0168] The Short Video Descriptor contains the Video Identification Code defined in CEA-861.

[0169]

[0170] The following Table 4 shows the Audio Data Block.

[0171] Byte #Bits 5-7Bits 0-40Audio Tag CodeShort Audio Descriptor Total number of bytes (L2)1 ~ 3CEA Short Audio Descriptor 14 ~ 3L2CEA Short Video Descriptor L2 / 3

[0172] The Short Audio Descriptor contains the Audio Format Code defined in CEA-861.

[0173]

[0174] The following Table 5 shows the Speaker Allocation Data Block.

[0175] Byte #Bits 5-7Bits 0-40Speaker allocation Tag CodeSpeaker Allocation Total number of bytes (L3=3)1 ~ 3Speaker Allocation Data Block Payload

[0176] The Speaker Allocation Data Block Descriptor contains the Data Block Payload defined in CEA-861.

[0177]

[0178] 3. Vendor-Specific Data Block

[0179] As a block where vendor-specific data can be defined, HDMI uses this data block to define HDMI-specific data. The data block below is HF-VSDB.

[0180] Byte / Bits #765432100Vendor Specific Tag Code (=3)Length (=N)1IEEE OUI, Third Octet (0xD8)2IEEE OUI, Second Octet (0x5D)3IEEE OUI, First Octet (0xC4)4Version (=1)5Max_TMDS_Character_Rate6SCDC_PresentRR_CapableRsvd(0)Rsvd(0)LTE_340Mcsc_scrambleIndependent_viewDual_ view3D_OSD_Disparity7Rsvd(0)Rsvd(0)Rsvd(0)Rsvd(0)Rsvd(0)DC_48bit_420DC_36bit_420DC_30bit_420...NReserved(0)

[0181] (1) Length : The total length of the data block, with a minimum value of 7 and a maximum value of 31.

[0182] (2) IEEE OUI: As an IEEE Organizationally Unique Identifier, the OUI assigned to the HDMI Forum is 0xC45DD8.

[0183] (3) Version: The version number of HF-VSDB (HDMI Forum-VSDB) is 1.

[0184] (4) Max_TMDS_Character_Rate : Indicates the maximum supported TMDS Character Rate. If the Sink device does not support 340 MaxDS or higher, set it to 0, and if it does support it, set it to 1.

[0185] (5) 3D_OSD_Disparity: When set to 1, it indicates that the Sink device supports receiving 3D_OSD_Disparity Indication.

[0186] (6) Dual_view : When set to 1, it indicates that the Sink device supports Dual_view signaling reception.

[0187] (6) Independent_view : When set to 1, it indicates that the Sink device supports receiving 3D independent view signaling.

[0188] (7) LTE_340Mcsc_scramble: When set to 1, it indicates that the Sink device supports scrambling at a TMDS character rate of 340Mcss or less. Also, if SCDC_Present is set to 0, this flag must also be set to 0.

[0189] (8) RR_Capable: When set to 1, it indicates that the Sink device can initiate an SCDC read request. And if SCDC_Present is set to 0, this flag must also be set to 0.

[0190] (9) SCDC_Present: When set to 1, it indicates that the Sink supports SCDC functionality.

[0191] (10) DC_48bit_420, DC_36bit_420, DC_30bit_420 : When set to 1, it indicates that Deep Color 4:2:0 pixel encoding is supported at 10 bits / 12 bits / 16 bits per component.

[0192]

[0193] 4. DisplayPort Supported Resolutions

[0194] Unlike HDMI, DisplayPort does not have a defined default mandatory resolution.

[0195] Definition Formats Field Rate Aspect Ratio Support by Standard Technology DisplayPort 1.2a 1.3 SD (Standard Definition) Supports all ED (Enhanced Definition) Supports all HD (High Definition) Supports all Full HD Supports all 4K UHD (Ultra High Definition) 3840x2160p 23.98 / 24Hz 16:9 Support Support3840x2160p25Hz3840x2160p29.97 / 30Hz3840x2160p50Hz3840x2160p59.94 / 60Hz3840x2160p23.98 / 24Hz64:273840x2160p25Hz3840x2160p29.97 / 30Hz3 840x2160p50Hz3840x2160p59.94 / 60Hz4096x2160p23.98 / 24Hz256:1354096x 2160p25Hz4096x2160p29.97 / 30Hz4096x2160p50Hz4096x2160p59.94 / 60Hz8K UHD 7680x4320p 23.98 / 24Hz 16:9 Not supported Not supported (Scheduled for support in 1.3a)

[0196] 5. Display ID Extension Block

[0197] (1) Display ID is a VESA standard created to replace the E-EDID standard and EDID v1.4.

[0198] (2) Display ID v1.1 was published in March '09, and v1.3 was published in September '13.

[0199] (3) This standard has a variety of structures, including new extension formats for embedded displays and 3D displays as well as existing EDID extension formats.

[0200] (4) The Display ID format includes several blocks that describe information about the display, such as video interfaces, display device technology, timing details, and manufacturer information.

[0201] (5) Blocks are flexible up to the length of the header, and the length of each field is variable and the specific number of bytes is not fixed. Only a few data blocks are fixed.

[0202]

[0203] Table 8 shows the Display ID Structure.

[0204] AddressValueDescription00h12hDisplay ID Structure Version 1, Revision 201h00h -> FBhBytes in Section02h ~ 03h00h -> FFhDisplay Product Type Identifier & Extension Count04hBLOCKFirst Data block......(N-2)hBLOCKLast byte of Last valid data block(N-1)h00h -> FFhChecksum

[0205] Table 9 shows the Data Block Format.

[0206] OffsetValueDescription00h00h -> FFhData Block Identification01h0 -> 7Block Revision and other data02h00h -> F8hNumber of Payload Bytes 0 -> 24803hDESCRIPTOR1st Data Payload Byte04h.2nd Data Payload Byte... (if present)...

[0207] (1) Data Block Identification: Displays the tag of each data block.

[0208] (2) Block revision and other data: The revision increases whenever a bit is added or changed in the block.

[0209] (3) Number of Payload Bytes: Indicates the number of bytes of payload used in a single data block.

[0210] (4) 1 ~ N Data Payload Byte : Starting from 03h, it explains what role each Data Payload Byte plays.

[0211]

[0212] 6. DDC (Display Data Channel)

[0213] (1) Protocol standard for transmitting digital information between a monitor and a computer's graphics adapter defined by VESA (Video Electronics Standard Association)

[0214] (2) The monitor transmits information on supported display modes to the graphics adapter, and the graphics adapter transmits video to the monitor accordingly.

[0215] (3) Before the DDC standard was established, the VGA standard used four pins (Pin 11, 12, 4, 15) of the analog VGA connector to recognize monitor types, and only Pins 11, 12, and 4 were used, and 7 types of monitor types could be recognized.

[0216] (4) DDC version 1 (established in 1994)

[0217] (4-1) Defines EDID (Extended Display Identification Data), a binary file format that describes monitor information.

[0218] (4-2) Use Pin 12 as the data line and continuously transmit 128-byte EDID blocks from the monitor to the computer.

[0219] (5) DDC version 2 (established in 1996)

[0220] (5-1) EDID is not defined in DDC but is defined as an independent standard as a companion standard.

[0221] (5-2) Defined based on the I2C Serial Bus, Pin 12 is used as the data line of the I2C Bus, and Pin 15 is used as the clock line of the I2C Bus.

[0222] (5-3) Pin 9: Used to supply 5V DC power (up to 50mA) from the computer to the monitor to read the EDID stored in the EEPROM even when the monitor power is off.

[0223] (5-4) The monitor is assigned the 7-bit I2C address 50h as a slave device of the I2C Bus.

[0224] (5-5) Allows EDID storage capacity of up to 28 bytes = 256 bytes with an 8-bit data offset.

[0225] (6) E-DDC

[0226] (6-1) Version 1 was established in 1999 as a standard replacing DDC versions 1 and 2, and allows up to 32 Kbytes of display information storage capacity for use with Enhanced EDID.

[0227] (6-2) By applying a new I2C addressing scheme using 8-bit segment indices (0x00 to 0x7F), 128 segments (1 segment = 256 bytes) can be accessed, allowing access up to 32K bytes.

[0228] (6-3) E-DDC version 1.1 was established in 2004 and includes support for CE devices and video interfaces other than VGA (e.g., HDMI).

[0229] (6-4) E-DDC version 1.2 was established in 2007 and includes support for DisplayPort and DisplayID.

[0230]

[0231] 7. SCDCS (Status and Control Data Channel Structure)

[0232] (1) SCDCS is a one-to-one communication protocol based on I2C serial communication that enables data exchange between HDMI source devices and sink devices.

[0233] (2) Extension of the existing I2C standard: A function is added in which the I2C slave Sink device requests a status check read from the I2C master Source device, and the Source device, upon receiving this, reads the corresponding status from the Sink device.

[0234] Table 10 shows an example of a specific configuration of SCDCS.

[0235] OffsetR / WName0x01RSink Version0x02R / WSource Version0x10R / WUpdate_00x11R / WUpdate_10x12-0x1FRReserved for Update Related Uses0x20R / WTMDS_Config0x21RScrambler_Status0x30R / WConfig_00x31-0x3FRReserved for Configuration0x40RStatus_Flag_00x41RStatus_Flag_10x42-0x4FRReserved for Status Related Uses0x50RErr_Det_0_L0x51RErr_Det_0_H0x52RErr_Det_1_L0x53RErr_Det_1_H0x54RErr_Det_2_L0x55RErr_Det_2_H0x56RErr_Det_Checksum0xC0R / WTest_Config_00xC1`0xCFRReserved for test features0xD0RManufacturer IEEE OUI, Third Octet0xD1RManufacturer IEEE OUI, Second Octet0xD2RManufacturer IEEE OUI, First Octet0xD3-0xDDRDevice ID0xDE-0xFFR / WManufacturer SpecificAll Remaining OffsetsRReserved

[0236] The following is a detailed description of each component of the SCDCS.

[0237] (1) Sink Version : Displays the version information of the SCDCS compliant sink device. Set to 1.

[0238] (2) Source Version: SCDCs compliant. When a source device reads an E-EDID from a sink device and the SCDC_Present of the E-EDID is set to 1, the Source Version of the SCDCs is set to 1.

[0239] (3) Update Flags (Update_0, Update_1): When there is a change in the information (Status, Character Error Detect, etc.) that the Sink device must notify the Source device, the corresponding bit is set to 1.

[0240] (4) TMDS Configuration (TMDS_Config): TMDS_Bit_Clock_Ratio and Scrambling_Enable each occupy 1 bit. If the Source device wants to enable the scrambling function of the Sink device, set the bit to 1. If TMDS_Bit_Clock_Ratio is 1 / 10, set it to 0, and if it is 1 / 40, set it to 1.

[0241] (5) Scrambler Status: When the Sink device detects a scrambled control code sequence, the corresponding bit is set to 1.

[0242] (6) Configuration (Config_0): A field for configuring information related to the capabilities of Source and Sink devices. Currently, there is only the RR_Enable field, which indicates whether the Source device supports the Sink device's Read Request.

[0243] (7) Status Flags (Status_Flag_0, Status_Flag_1) : Indicates whether data received through Clock, channel 0, 1, and 2 has been successfully decoded.

[0244]

[0245] FIG. 4 shows an example of a timing configuration (FAPA_start_location=0) of a FAPA (Frame Accurate Packet Area) according to one embodiment of the present disclosure.

[0246] Specifically, FIG. 4 shows the timing structure of a Frame Accurate Packet Area (FAPA), which is one of the Extended Metadata (EM) packet transmission methods according to the present disclosure.

[0247] Referring to Figure 4, it illustrates the behavior when the 'FAPA_start_location' field value is 0 among the two FAPA modes (corresponding to Figure 10-16). In this mode, FAPA starts at the first blank pixel immediately following the last active video pixel of the video frame or field.

[0248] Referring to Fig. 4, the 'FAPA b' area begins immediately after the active video area of ​​the current frame, called 'Active Video a', ends.

[0249] The core function of FAPA is that the data sets transmitted through this 'FAPA b' area are applied to the first active pixel line of 'Active Video b', which is the next frame following 'FAPA b'. As a result, this structure has the effect of allowing the sink device to receive information to be applied to the next frame one frame in advance.

[0250]

[0251] FIG. 5 shows an example of a timing configuration (FAPA_start_location=1) of a FAPA (Frame Accurate Packet Area) according to another embodiment of the present disclosure.

[0252] Specifically, FIG. 5 illustrates an EM (Extended Metadata) packet transmission method. This specifically shows the FAPA (Frame Accurate Packet Area) timing structure when the 'FAPA_start_location' field value is 1.

[0253] In the method of Fig. 5, FAPA starts at the first horizontal blank pixel immediately following the first active video pixel of the video frame or field.

[0254] In the diagram of Fig. 5, the data set transmitted during FAPA (e.g., 'FAPA c') is applied to the first line and first active pixel of the next active video block (e.g., 'active video c') that follows the FAPA.

[0255]

[0256] Figure 6 shows an example of an initial connection sequence between a source device and a sink device according to the prior art.

[0257] (Step 0) Cable connection between source device and sink device: The user connects a cable between the source device and the sink device for A / V data transmission.

[0258] Step 1: Provide high level to +5V power line: The source device applies a high level to the +5V power line and flows current to operate the EEPROM and related circuits where the sink device's EDID information is stored.

[0259] Step 2: Provide high level to hot plug detection (HPD) line: The EDID-related circuit of the sink device, activated by the +5V power supply (Step 1), transitions the HPD line, which was maintained at a low level, to a high level to inform the source device that the cable is properly connected and EDID information is accessible.

[0260] Step 3: Request to read EDID / DPID information: The source device confirms that the HPD line is at a high level (Step 2) and requests the sink device to read EDID / DPID information through the display data channel (DDC).

[0261] Step 4: Transmit EDID / DPID information: In response to the source device's request to read the EDID (Step 3), the sink device transmits the EDID / DPID information stored in the EEPROM to the source device via the DDC.

[0262] Step 5: EDID / DPID parsing and operation parameter determination: The source device parses the received EDID / DPID information (Step 4) and determines the operation parameters (e.g., timing, format, DSC compression, etc.) of the A / V data to be transmitted to the sink device.

[0263] Step 6: DPCD Request: (After determining parameters) The source device can send a DPCD (DisplayPort Configuration Data) request to the sink device.

[0264] These conventional technologies have problems when operating a Quick Media Switch (QMS). When other formats, such as pixel format or HDR format, are changed along with the frame rate for movie playback, the source device does not transmit this information to the sink device in advance. As a result, the sink device uses a video mute to respond to the sudden format change, causing screen flickering (blank noise), which hinders the seamless operation that is the original function of the QMS.

[0265]

[0266] Specifically, examples of changes in video formats that may change along with the frame rate during QMS operation may be as follows.

[0267] First, there is the case where the pixel format changes. For example, the pixel format can be changed from 8 bits to 10 bits, from 8 bits to 12 bits, or from 8 bits to 16 bits. Also, it can be changed from 10 bits to 8 bits, from 10 bits to 12 bits, or from 10 bits to 16 bits, and from 12 bits to 8 bits, from 12 bits to 10 bits, or from 12 bits to 16 bits.

[0268] Second, there is the case where chroma sampling is changed. For example, chroma sampling can be changed from 4:2:0 to 4:2:2, from 4:2:0 to 4:4:4, or from 4:2:0 to 4:1:1. Also, it can be changed from 4:2:2 to 4:2:0, from 4:2:2 to 4:4:4, or from 4:2:2 to 4:1:1, and from 4:4:4 to 4:2:0, from 4:4:4 to 4:2:2, or from 4:4:4 to 4:1:1.

[0269] Third, there is the case of changing from SDR (Standard Dynamic Range) to HDR (High Dynamic Range). This includes all cases where HDR is supported, and may include, for example, changes from SDR to HDR10, SDR to HLG, SDR to HDR10+, or SDR to Dolby Vision.

[0270] Fourth, there is the case where there is a change between different HDR formats (i.e., a change from HDR to HDR). For example, this may include cases where the HDR format changes from HDR to Dolby Vision (Low Latency) mode or Dolby Vision (Standard) mode.

[0271]

[0272] Figure 7 shows an example of frame rate information transmission during the operation of a Quick Media Switch (QMS) according to the prior art.

[0273] This diagram illustrates a situation where the frame rate of a video stream changes. The 'Next Frame Rate' field changes from '8' (corresponding to 50Hz depending on the key) to '4' (corresponding to 30 / 1.001Hz), which is triggered by a change in the level of 'Static_field'.

[0274] The core problem of the conventional technology illustrated in Fig. 7 is that the information shared in advance one frame before the frame through the Extended Metadata (EM) of the Frame Accurate Packet Area (FAPA) is entirely the frame rate.

[0275] To solve these problems, the present disclosure aims to provide a method for pre-transmitting information, such as frame rate, about other format changes (e.g., pixel format, chroma sampling, HDR format, etc.) that may affect the maintenance of seamlessness.

[0276]

[0277] FIG. 8 shows an example of an improved Quick Media Switch (QMS) operation sequence according to one embodiment of the present disclosure.

[0278] The diagram in Fig. 8 shows the interaction between the 'Source Device' and the 'Sink Device'.

[0279] 1. First, the sink device sends a 'Read_EDID(QMS)' message to the source device. This indicates the process of reading QMS-related EDID information.

[0280] 2. Afterwards, when the source device transmits 24Hz video, the sink device receives it and processes it by pulling it down to 120Hz.

[0281] 3. Likewise, when the source device transmits 60Hz video, the sink device receives it and processes it by pulling it down to 120Hz.

[0282] This illustrates an example of the behavior of the improvement proposal where 'Next Frame Rate' information is transmitted when a change is made in 'Fixed Video'.

[0283]

[0284] FIG. 9 illustrates an example of a metadata structure to which video format information may be added according to an embodiment of the present disclosure.

[0285] Specifically, FIG. 9 shows a ‘Class 1 Video Timing Extended Metadata Structure (for QMS-VRR)’ as part of a sequence diagram corresponding to the ‘improvement proposal’ of the present disclosure. The structure of FIG. 9 represents the configuration of metadata used during Quick Media Switch (QMS) operation.

[0286] (1) The MD0 byte contains fields such as QMS_EN (QMS Enable), M_CONST (M Constant), etc.

[0287] (2) MD1 byte contains the Base_Vfront field.

[0288] (3) MD2 and MD3 bytes contain Base_Refresh_Rate and Next_TFR (Next Frame Rate) fields.

[0289] The present disclosure proposes the following improvements in relation to this structure.

[0290] 1. Limitations of existing fields: The Next_TFR field in MD2 is intended to indicate the frame rate to be changed in advance. However, in conventional technology, it is difficult to guarantee seamless operation with this information alone.

[0291] 2. Suggested Improvement (Addition of Information): It is necessary to add other format information that affects seamless operation. The present disclosure proposes adding the following information to this metadata structure.

[0292] (1) Chroma Field[3:0]: Chroma sampling information (e.g., 0=4:2:0, 1=4:2:2, 2=4:4:4, 3=4:1:1).

[0293] (2) HDR Type[4:0]: HDR format information (e.g., 0=HDR10, 1=HLG, 2=Dolby Vision Type 1(Low Latency), 3=Dolby Vision Type 2(Standard)).

[0294] (3) Pixel Format[3:0]: Pixel format information (e.g., 0=8 bits, 1=10 bits, 2=12 bits, 3=16 bits).

[0295] (4) Color Space[3:0]: Color space information (e.g., 0=YCbCr, 1=RGB).

[0296] 3. Alternative (Redefining Seamless): If a seamless solution is not possible even by adding the previously proposed information, a redefinition of 'Seamless' itself is required.

[0297] (1) Currently, HDMI Seamless is based on 'Minor Video Transition Artifact'.

[0298] (2) The improvement proposal is to add a blank 1 frame here and expand (redefine) the definition of Seamless by adding the term 'Visually Seamless' instead of the existing 'Seamless'.

[0299]

[0300] [Explanation regarding Source device claim]

[0301] The embodiments described above will be explained in detail below with reference to FIG. 10 regarding the operation of the terminal. The methods described below are distinguished only for the convenience of explanation, and it is obvious that, as long as they are not mutually excluded, a part of one method may be substituted with a part of another method or combined with one another and applied.

[0302] FIG. 10 is a drawing illustrating an example of the operation process of a Source device according to various embodiments of the present disclosure.

[0303] According to various embodiments of the present disclosure, a method performed by a Source device is provided.

[0304] The Source device includes a processor; memory; and a transceiver. The memory stores instructions for performing operations based on execution by the processor.

[0305] In step S1001, the Source device determines that a change in frame rate and a change in video format occur in the next frame following the current frame of the video stream. In the next frame following the current frame, the frame rate is changed from a first frame rate to a second frame rate. In the next frame following the current frame, the video format is changed from a first video format to a second video format.

[0306] In step S1002, the Source device generates metadata of the next frame including information on the second frame rate and the second video format.

[0307] In step S1003, the Source device inserts the metadata of the next frame into the FAPA (Frame Accurate Packet Area) of the current frame.

[0308] In step S1004, the Source device transmits the first video data of the current frame to the Sink device. Within the first video data, the FAPA of the current frame includes the metadata of the next frame.

[0309]

[0310] According to various embodiments of the present disclosure, the information of the second video format may include at least one of a pixel format, chroma sampling, an HDR (High Dynamic Range) format, and color space information.

[0311] According to various embodiments of the present disclosure, the metadata may be transmitted via an Extended Metadata Packet (EM).

[0312] According to various embodiments of the present disclosure, the Extended Metadata Packet (EM) may be transmitted to the sink device one frame before the next frame is transmitted.

[0313] According to various embodiments of the present disclosure, after the metadata is transmitted through the first video data, the method may further include the step of transmitting the second video data of the next frame, to which the second frame rate and the second video format are applied, to the sink device.

[0314] According to various embodiments of the present disclosure, the metadata may include information of the second video format within a 'Class 1 Video Timing Extended Metadata Structure' for QMS-VRR (Quick Media Switch-Variable Refresh Rate).

[0315] According to various embodiments of the present disclosure, the information of the pixel format may represent 8 bits, 10 bits, 12 bits, or 16 bits. The information of the chroma sampling may represent 4:2:0, 4:2:2, or 4:4:4. The information of the HDR format may represent SDR, HDR10, HLG, or Dolby Vision.

[0316]

[0317] According to various embodiments of the present disclosure, a Source device is provided. The Source device comprises a processor; a memory; and a transceiver, and the processor may be configured to perform the method of operation of the Source device according to FIG. 10.

[0318] According to various embodiments of the present disclosure, a device for controlling a Source device is provided. The device comprises at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions for performing a method of operating the Source device according to FIG. 10 based on execution by the at least one processor.

[0319] According to various embodiments of the present disclosure, one or more non-transitory computer-readable media (CRMs) storing one or more instructions are provided. The one or more instructions perform operations based on execution by one or more processors, and the operations may include a method of operation of a Source device according to FIG. 10.

[0320]

[0321] [Explanation regarding Sink device claim]

[0322] The embodiments described above will be explained in detail below with reference to FIG. 9 regarding the operation of the terminal. The methods described below are distinguished only for the convenience of explanation, and it is obvious that, as long as they are not mutually excluded, a part of one method may be substituted with a part of another method or combined with one another and applied.

[0323] FIG. 11 is a drawing illustrating an example of the operation process of a Sink device according to various embodiments of the present disclosure.

[0324] According to various embodiments of the present disclosure, a method performed by a sink device is provided.

[0325] The Sink device includes a processor; memory; and a transceiver. The memory stores instructions for performing operations based on execution by the processor.

[0326] In step S1101, the Sink device receives first video data of the current frame from the Source device. Within the first video data, the Frame Accurate Packet Area (FAPA) of the current frame contains metadata of the next frame. In the next frame following the current frame, the frame rate is changed from a first frame rate to a second frame rate. In the next frame following the current frame, the video format is changed from a first video format to a second video format. The metadata includes information regarding the second frame rate and the second video format.

[0327] In step S1102, the Sink device identifies a change in the frame rate and the video format in the next frame after the current frame based on the metadata.

[0328] In step S1103, the Sink device receives the second video data of the next frame from the source device based on the second frame rate and the second video format.

[0329]

[0330] According to various embodiments of the present disclosure, the information of the second video format may include at least one of a pixel format, chroma sampling, an HDR (High Dynamic Range) format, and color space information.

[0331] According to various embodiments of the present disclosure, the metadata may be received via an Extended Metadata Packet (EM).

[0332] According to various embodiments of the present disclosure, the Extended Metadata Packet (EM) may be received from the source device one frame before the next frame is transmitted.

[0333] According to various embodiments of the present disclosure, the second video data of the next frame may be subject to the second frame rate and the second video format.

[0334] According to various embodiments of the present disclosure, the metadata may include information of the second video format within a 'Class 1 Video Timing Extended Metadata Structure' for QMS-VRR (Quick Media Switch-Variable Refresh Rate).

[0335] According to various embodiments of the present disclosure, the information of the pixel format may represent 8 bits, 10 bits, 12 bits, or 16 bits. The information of the chroma sampling may represent 4:2:0, 4:2:2, or 4:4:4. The information of the HDR format may represent SDR, HDR10, HLG, or Dolby Vision.

[0336]

[0337] According to various embodiments of the present disclosure, a sink device is provided. The sink device comprises a processor; a memory; and a transceiver, and the processor may be configured to perform the method of operation of the sink device according to FIG. 11.

[0338] According to various embodiments of the present disclosure, a device for controlling a sink device is provided. The device comprises at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions for performing a method of operating a sink device according to FIG. 11 based on execution by the at least one processor.

[0339] According to various embodiments of the present disclosure, one or more non-transitory computer-readable media (CRMs) storing one or more instructions are provided. The one or more instructions perform operations based on execution by one or more processors, and the operations may include a method of operation of a Sink device according to FIG. 11.

[0340]

[0341] The claims described in various embodiments of the present disclosure may be combined in various ways. For example, the technical features of the method claims of various embodiments of the present disclosure may be combined to be implemented as a device, and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a method.

Claims

1. In the method of operating a source device, A step of determining that a change in frame rate and a change in video format occur in the next frame following the current frame of a video stream, In the next frame after the current frame, the frame rate is changed from the first frame rate to the second frame rate, and In the next frame following the current frame, the video format is changed from the first video format to the second video format; A step of generating metadata of the next frame including information on the second frame rate and the second video format; A step of inserting the metadata of the next frame into the FAPA (Frame Accurate Packet Area) of the current frame; The method includes the step of transmitting the first video data of the current frame to a sink device, and In the first video data above, the FAPA of the current frame includes the metadata of the next frame, method.

2. In Paragraph 1, The information of the second video format above includes at least one of pixel format, chroma sampling, HDR (High Dynamic Range) format, and color space information. method.

3. In Paragraph 1, The above metadata is transmitted via an EM (Extended Metadata Packet), method.

4. In Paragraph 3, The above EM (Extended Metadata Packet) is transmitted to the sink device one frame before the next frame is transmitted, method.

5. In Paragraph 1, The method further comprises the step of transmitting the second video data of the next frame, to which the second frame rate and the second video format are applied, to the sink device after the metadata is transmitted through the first video data. method.

6. In Paragraph 1, The above metadata includes information of the second video format within a 'Class 1 Video Timing Extended Metadata Structure' for QMS-VRR (Quick Media Switch-Variable Refresh Rate), method.

7. In Paragraph 2, The information of the above pixel format represents 8-bit, 10-bit, 12-bit, or 16-bit, and The information of the above chroma sampling represents 4:2:0, 4:2:2, or 4:4:4, and The information of the above HDR format indicates SDR, HDR10, HLG, or Dolby Vision, method.

8. In the method of operating a sink device, A step of receiving first video data of the current frame from a source device, In the first video data above, the FAPA (Frame Accurate Packet Area) of the current frame includes metadata of the next frame, and In the next frame after the current frame, the frame rate is changed from the first frame rate to the second frame rate, and In the next frame after the current frame, the video format is changed from the first video format to the second video format, and The above metadata includes information on the second frame rate and the second video format; A step of identifying a change in the frame rate and the video format in the next frame after the current frame based on the above metadata; Based on the second frame rate and the second video format, the method comprises the step of receiving second video data of the next frame from the source device. method.

9. In Paragraph 8, The information of the second video format above includes at least one of pixel format, chroma sampling, HDR (High Dynamic Range) format, and color space information. method.

10. In Paragraph 8, The above metadata is received via an EM (Extended Metadata Packet), method.

11. In Paragraph 10, The above EM (Extended Metadata Packet) is received from the source device one frame before the next frame is transmitted, method.

12. In Paragraph 8, The second video data of the above-mentioned next frame has the second frame rate and the second video format applied, method.

13. In Paragraph 8, The above metadata includes information of the second video format within a 'Class 1 Video Timing Extended Metadata Structure' for QMS-VRR (Quick Media Switch-Variable Refresh Rate), method.

14. In Paragraph 9, The information of the above pixel format represents 8-bit, 10-bit, 12-bit, or 16-bit, and The information of the above chroma sampling represents 4:2:0, 4:2:2, or 4:4:4, and The information of the above HDR format indicates SDR, HDR10, HLG, or Dolby Vision, method.

15. In a source device, It includes a processor; memory; and a transceiver, The above memory stores instructions for performing operations based on execution by the processor, and The above operations are, A step of determining that a change in frame rate and a change in video format occur in the next frame following the current frame of a video stream, In the next frame after the current frame, the frame rate is changed from the first frame rate to the second frame rate, and In the next frame following the current frame, the video format is changed from the first video format to the second video format; A step of generating metadata of the next frame including information on the second frame rate and the second video format; A step of inserting the metadata of the next frame into the FAPA (Frame Accurate Packet Area) of the current frame; The method includes the step of transmitting the first video data of the current frame to a sink device, and In the first video data above, the FAPA of the current frame includes the metadata of the next frame, Source device.

16. In Paragraph 15, The information of the second video format above includes at least one of pixel format, chroma sampling, HDR (High Dynamic Range) format, and color space information. Source device.

17. In Paragraph 15, The above metadata is transmitted via an EM (Extended Metadata Packet), Source device.

18. In Paragraph 17, The above EM (Extended Metadata Packet) is transmitted to the sink device one frame before the next frame is transmitted, Source device.

19. In Paragraph 15, The above operations are, The method further comprises the step of transmitting the second video data of the next frame, to which the second frame rate and the second video format are applied, to the sink device after the metadata is transmitted through the first video data. Source device.

20. In Paragraph 19, The above metadata includes information of the second video format within a 'Class 1 Video Timing Extended Metadata Structure' for QMS-VRR (Quick Media Switch-Variable Refresh Rate), Source device.

Images