WO2025002871A1 - Modèle de vecteur de bloc affine pour copie intra-bloc - Google Patents

Modèle de vecteur de bloc affine pour copie intra-bloc Download PDF

Info

Publication number
WO2025002871A1
WO2025002871A1 PCT/EP2024/066741 EP2024066741W WO2025002871A1 WO 2025002871 A1 WO2025002871 A1 WO 2025002871A1 EP 2024066741 W EP2024066741 W EP 2024066741W WO 2025002871 A1 WO2025002871 A1 WO 2025002871A1
Authority
WO
WIPO (PCT)
Prior art keywords
ibc
affine
block
mode
current block
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/EP2024/066741
Other languages
English (en)
Inventor
Fabrice Le Leannec
Franck Galpin
Antoine Robert
Karam NASER
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.)
InterDigital CE Patent Holdings SAS
Original Assignee
InterDigital CE Patent Holdings SAS
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 InterDigital CE Patent Holdings SAS filed Critical InterDigital CE Patent Holdings SAS
Priority to CN202480054276.XA priority Critical patent/CN121753323A/zh
Priority to EP24732527.7A priority patent/EP4725191A1/fr
Publication of WO2025002871A1 publication Critical patent/WO2025002871A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • H04N19/52—Processing of motion vectors by encoding by predictive encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/537—Motion estimation other than block-based
    • H04N19/54—Motion estimation other than block-based using feature points or meshes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Definitions

  • FIG.4 illustrates an example of a system in which various aspects and examples may be implemented.
  • FIGs.5A-5D illustrate examples of intra block copy (IBC) reference regions depending on a current block prediction.
  • FIG.6 illustrates one or more padding candidates for the replacement of a zero-vector in an IBC list.
  • FIG.7 illustrates an example reference area for IBC if a coding tree unit (CTU) (m,n) is coded.
  • CTU coding tree unit
  • FIG.8 illustrates an example of whole-block and sub-block-based motion representation categories.
  • FIGs.9A-9B illustrate an example control point based affine motion models.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, IDVC_2023P00520WO PATENT a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial
  • UE user equipment
  • IDVC_2023P00520WO PATENT a subscription-based unit
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).
  • the base station 114b in FIG.1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or IDVC_2023P00520WO PATENT femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT.
  • the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • FIG.1B is a system diagram illustrating an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals IDVC_2023P00520WO PATENT 138, among others.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may include a plurality of processors.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG.1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0051] Although the transmit/receive element 122 is depicted in FIG.1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the UPF 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
  • the CN 115 may facilitate communications with other networks.
  • the emulation device may be directly coupled to another device for purposes of testing and/or may perform testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be testing equipment.
  • Direct RF coupling and/or wireless communications via RF circuitry may be used by the emulation devices to transmit and/or receive data.
  • RF circuitry e.g., which may include one or more antennas
  • This application describes a variety of aspects, including tools, features, examples, models, approaches, etc. Many of these aspects are described with specificity and, at least to show the individual characteristics, are often described in a manner that may sound limiting. However, this is for purposes of clarity in description, and does not limit the application or scope of those aspects. Indeed, all of the different aspects may be combined and interchanged to provide further aspects. Moreover, the aspects may be combined and interchanged with aspects described in earlier filings as well. [0089] The aspects described and contemplated in this application may be implemented in many different forms.
  • FIGs.5-15 described herein may provide some examples, but other examples are contemplated. The discussion of FIGs.5-15 does not limit the breadth of the implementations. At least one of the aspects generally relates to video encoding and decoding, and at least one other aspect generally relates to transmitting a bitstream generated or encoded. These and other aspects may be implemented as a method, an apparatus, a computer readable storage medium having stored thereon instructions for encoding or decoding video data according to any of the methods described, and/or a computer readable storage medium having stored thereon a bitstream generated according to any of the methods described.
  • the terms “reconstructed” and “decoded” may be used interchangeably, the terms “pixel” and “sample” may be used interchangeably, and the terms “image,” “picture” and “frame” may be used interchangeably.
  • Various methods are described herein, and each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for the proper operation of the method, the order and/or use of specific steps and/or actions may be modified or combined. Additionally, terms such as “first,” “second,” etc.
  • the video sequence may go through pre-encoding processing (201), for example, applying a color transform to the input color picture (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of the input picture components in order to get a signal distribution more resilient to compression (for instance using a histogram equalization of one of the color components). Metadata may be associated with the pre-processing and attached to the bitstream.
  • a picture may be encoded by one or more encoder elements as described herein.
  • the picture to be encoded may be partitioned (202) and processed in units of, for example, coding units (CUs).
  • a unit may be encoded using, for example, an intra mode or an inter mode. If a unit is encoded in an intra mode, the encoder may perform intra prediction (260). If a unit is encoded in an inter mode, the encoder may perform motion estimation (275) and/or motion compensation (270). The encoder may decide (205) which one of the intra mode or inter mode to use for encoding the unit and may indicate the intra/inter decision by, for example, a prediction mode indication, such as a prediction mode flag. Prediction residuals may be calculated, for example, by subtracting (210) the predicted block from the image block, e.g., the original image block. [0097] The prediction residuals may be transformed (225) and quantized (230).
  • FIG.3 illustrates a diagram showing an example of a video decoder.
  • a bitstream may be decoded by one or more decoder elements as described herein.
  • the video decoder (300) may perform a decoding pass reciprocal to the encoding pass as described in FIG.2.
  • the encoder (200) may perform video decoding as part of encoding video data.
  • the input of the decoder may be, or may include, a video bitstream, which may be generated by a video encoder (200).
  • the bitstream may be entropy decoded (330) to obtain transform coefficients, motion vectors, and/or other coded information.
  • the picture partition information may indicate how the picture is partitioned.
  • the decoder may divide (335) the picture according to the decoded picture partitioning information.
  • the transform coefficients may be de-quantized (340), and inverse transformed (350) to decode the prediction residuals. Combining (355) the decoded prediction residuals and the predicted block, an image block may be reconstructed.
  • the predicted block may be obtained (370) from intra prediction (360) or motion-compensated prediction (e.g., inter prediction) (375).
  • In-loop filters (365) may be applied to the reconstructed image.
  • the filtered image may be stored at a reference picture buffer (380).
  • the contents of the reference picture buffer (380) on the decoder (300) side may be similar (e.g., identical) to the contents of the reference picture buffer (280) on the encoder (200) side for the same picture.
  • the decoded picture may go through post-decoding processing (385), for example, an inverse color transform (e.g., conversion from YCbCr 4:2:0 to RGB 4:4:4) and/or an inverse remapping performing the inverse of the remapping process performed in the pre-encoding processing (201).
  • the post-decoding processing may use metadata derived in the pre-encoding processing and signaled in the bitstream.
  • the decoded images e.g., after application of the in-loop filters (365) and/or after post-decoding processing (385), if post-decoding processing is used
  • FIG.4 illustrates a diagram showing an example of a system in which various aspects and examples described herein may be implemented.
  • a system (400) may be embodied as a device including the various components described below and may be configured to perform one or more of the aspects described in this document. Examples of such devices may include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers.
  • One or more elements of the system (400), singly or in combination, may be IDVC_2023P00520WO PATENT embodied in a single integrated circuit (IC), multiple ICs, and/or discrete components.
  • the system (400) may include at least one memory (420) (e.g., a volatile memory device, and/or a non- volatile memory device).
  • the system (400) may include a storage device (440), which may include non- volatile memory and/or volatile memory, including, but not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, magnetic disk drive, and/or optical disk drive.
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • ROM Read-Only Memory
  • PROM Programmable Read-Only Memory
  • RAM Random Access Memory
  • DRAM Dynamic Random Access Memory
  • SRAM Static Random Access Memory
  • the storage device (440) may include an internal storage device, an attached storage device (including detachable and non-detachable storage devices), and/or a network accessible storage device, as non-limiting examples.
  • the system (400) may include an encoder/decoder module (430) configured, for example, to process data to provide an encoded video or decoded video, and the encoder/decoder module (430) may include its own processor and memory.
  • the encoder/decoder module (430) may represent a module(s) that may be included in a device to perform the encoding and/or decoding functions. As is known, a device may include one or both of the encoding and decoding modules.
  • the encoder/decoder module (430) may be implemented as a separate element of system (400) or may be incorporated within the processor (410) as a combination of hardware and software as known to those skilled in the art.
  • Program code to be loaded onto the processor (410) or the encoder/decoder (430) to perform the various aspects described herein may be stored in the storage device (440) and subsequently loaded onto the memory (420) for execution by the processor (410).
  • one or more of the processor (410), the memory (420), the storage device (440), and the encoder/decoder module (430) may store one or more of various items during the performance of the processes described herein.
  • Such stored items may include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.
  • a memory inside of the processor (410) and/or the encoder/decoder module (430) may be used to store instructions and to provide working memory for processing that is needed IDVC_2023P00520WO PATENT during encoding or decoding.
  • a memory external to the processing device for example, the processing device may be either the processor (410) or the encoder/decoder module (430) may be used for one or more of these functions.
  • the external memory may be the memory (420) and/or the storage device (440), for example, a dynamic volatile memory and/or a non-volatile flash memory.
  • an external non-volatile flash memory is used to store the operating system of, for example, a television.
  • a fast external dynamic volatile memory such as a RAM is used as working memory for video encoding and decoding operations.
  • the input to the elements of the system (400) may be provided through various input devices as indicated in the block (445).
  • Such input devices may include, but are not limited to, (i) a radio frequency (RF) portion that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a Component (COMP) input terminal (or a set of COMP input terminals), (iii) a Universal Serial Bus (USB) input terminal, and/or (iv) a High Definition Multimedia Interface (HDMI) input terminal.
  • RF radio frequency
  • COMP Component
  • USB Universal Serial Bus
  • HDMI High Definition Multimedia Interface
  • the input devices of the block (445) may have associated respective input processing elements as known in the art.
  • the USB and/or HDMI terminals may include respective interface processors for connecting system (400) to other electronic devices across USB and/or HDMI connections. It is to be understood that IDVC_2023P00520WO PATENT various aspects of input processing, for example, Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or within the processor (410) as necessary.
  • USB or HDMI interface processing may be implemented within separate interface ICs or within the processor (410) as necessary.
  • the demodulated, error corrected, and demultiplexed stream may be provided to various processing elements, including, for example, the processor (410) and the encoder/decoder (430) operating in combination with the memory and the storage elements to process the datastream as necessary for presentation on an output device.
  • processing elements including, for example, the processor (410) and the encoder/decoder (430) operating in combination with the memory and the storage elements to process the datastream as necessary for presentation on an output device.
  • Various elements of system (400) may be provided within an integrated housing. Within the integrated housing, the various elements may be interconnected and transmit data therebetween using the suitable connection arrangement (425), for example, an internal bus as known in the art, including the Inter-IC (I2C) bus, wiring, and printed circuit boards.
  • I2C Inter-IC
  • the system (400) may include a communication interface (450) that enables communication with other devices via a communication channel (460).
  • the communication interface (450) may include, but is not limited to, a transceiver configured to transmit and to receive data over the communication channel (460).
  • the communication interface (450) may include, but is not limited to, a modem or network card and the communication channel (460) may be implemented, for example, within a wired and/or a wireless medium.
  • Data may be streamed, or otherwise provided, to the system (400), in various examples, using a wireless network such as a Wi-Fi network, for example IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers).
  • the Wi-Fi signal of these examples is received over the communications channel (460) and the communications interface (450) which are adapted for Wi-Fi communications.
  • the communications channel (460) of these examples may be typically connected to an access point or router that provides access to external networks including the Internet for allowing streaming applications and other over-the-top communications.
  • Other examples may provide streamed data to the system (400) using a set-top box that delivers the data over the HDMI connection of the input block (445).
  • Still other examples provide streamed data to the system (400) using the RF connection of the input block (445).
  • various examples may provide data in a non-streaming manner.
  • various examples use wireless networks other than Wi-Fi, for example a cellular network or a Bluetooth® network.
  • the system (400) may provide an output signal to various output devices, including a display (475), speakers (485), and/or other peripheral devices (495).
  • the display (475) of various examples may include one or more of, for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and/or a foldable display.
  • the display (475) may be for a television, a tablet, a laptop, a cell phone (mobile phone), or other device.
  • the display (475) may also be integrated with other IDVC_2023P00520WO PATENT components (for example, as in a smart phone), or separate (for example, an external monitor for a laptop).
  • the output devices may be communicatively coupled to system (400) via dedicated connections through respective interfaces (470, 480, and 490). Alternatively, the output devices may be connected to the system (400) using the communications channel (460) via the communications interface (450).
  • the display (475) and speakers (485) may be integrated into a single unit with the other components of the system (400) in an electronic device such as, for example, a television.
  • the display interface (470) may include a display driver, such as, for example, a timing controller (T Con) chip.
  • T Con timing controller
  • the display (475) and the speakers (485) may alternatively be separate from one or more of the other components, for example, if the RF portion of input (445) is part of a separate set-top box.
  • the processor (410) may be of any type appropriate to the technical environment, and may encompass one or more microprocessors, general purpose computers, special purpose computers, and processors based on a multi-core architecture, as non-limiting examples.
  • Various implementations involve decoding. “Decoding,” as used in this application, can encompass all or part of the processes performed, for example, on a received encoded sequence in order to produce a final output suitable for display. In various examples, such processes include one or more of the processes typically performed by a decoder, for example, entropy decoding, inverse quantization, IDVC_2023P00520WO PATENT inverse transformation, and differential decoding.
  • such processes also, or alternatively, may include processes performed by a decoder of various implementations described in this application, for example, obtaining a prediction block of a current block in a current picture; obtaining a plurality of samples in the prediction block, wherein the plurality of samples include previously decoded samples and non-decoded samples; padding the non-decoded samples using neighboring samples; decoding the current block based on the padded samples, etc.
  • decoding refers only to entropy decoding
  • decoding refers only to differential decoding
  • decoding refers to a combination of entropy decoding and differential decoding.
  • decoding process is intended to refer specifically to a subset of operations or generally to the broader decoding process will be clear based on the context of the specific descriptions and is believed to be well understood by those skilled in the art.
  • Various implementations involve encoding.
  • encoding as used in this application can encompass all or part of the processes performed, for example, on an input video sequence in order to produce an encoded bitstream.
  • processes include one or more of the processes typically performed by an encoder, for example, partitioning, differential encoding, transformation, quantization, and entropy encoding.
  • “receiving” is typically involved, in one way or another, during operations such as, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.
  • “/”, “and/or”, and “at least one of”, for example, in the cases of “A/B”, “A and/or B” and “at least one of A and B” is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B).
  • the block vector prediction may use two candidates as predictors, e.g., one from a left neighbor and the other from an above neighbor (e.g., if IBC coded). If either neighbor is not available, a block vector IDVC_2023P00520WO PATENT (e.g., a default block vector) may be used as a predictor. An indication, such as a flag, may be signaled to indicate the block vector predictor index. [0134] An IBC reference region may be utilized. For example, an IBC reference region may be utilized to limit memory consumption and/or decoder complexity. The IBC in video coding may allow the reconstructed portion of the predefined area, e.g., including the region of current CTU and some region of the left CTU.
  • above-right, bottom-left, and/or above-left spatial candidates and a pairwise average candidate may be added into the IBC merge/AMVP candidate list.
  • a template based adaptive reordering (ARMC-TM) may be applied to the IBC merge list.
  • the history-based motion vector prediction (HMVP) table size for an IBC may be increased, e.g., to 25 entries.
  • the IBC merge candidates may be reordered together.
  • one or more candidates may be selected as final candidates in the IBC merge list. For example, after reordering, the first 6 candidates with the lowest template matching costs may be selected as the final candidates in the IBC merge list.
  • One or more candidates for zero vectors to pad the IBC Merge/AMVP list may be replaced with a set of block vector prediction (BVP) candidates located in the IBC reference region.
  • a zero vector may be invalid as a block vector in the IBC merge mode, and the zero vector may be discarded as the BVP in the IBC candidate list.
  • FIG.6 illustrates one or more padding candidates for the replacement of a zero-vector in an IBC list.
  • two or more (e.g., three) candidates may be located on corners (e.g., the nearest corners) of the reference region.
  • Two or more (e.g., three) additional candidates may be determined in the middle of the three sub-regions (A, B, and C).
  • the zero motion candidates may have been replaced by (-W, 0), (0, -H), (-W, -H) motion vectors (MVs).
  • the selected candidates may be refined with the template matching method.
  • a TM-merge indication such as a TM-merge flag, may be signaled to indicate the template matching merge IBC mode.
  • up to 3 candidates may be selected from the IBC-TM merge list.
  • a candidate e.g., each of the candidates
  • IBC may be used with pairwise merge candidate and HMVP.
  • a pairwise IBC merge candidate (e.g., a new pairwise IBC merge candidate) may be generated by averaging two IBC merge candidates.
  • IBC motion may be inserted into history buffer for future referencing.
  • IBC may not be used in combination with an inner tool, such as affine motion.
  • IBC may be used in combination with CIIP, MMVD, and GPM.
  • IBC may not be allowed for the chroma coding blocks if a partition, such as DUAL_TREE partition, is used.
  • IBC may be adapted to camera-captured video content. In a coding tool, such as EMC, the IBC coding mode may be used by default for the coding of camera-captured content.
  • the first bin of AMVR syntax may be signaled to indicate whether BV is in quarter-pel resolution.
  • the second bin may be signaled to switch between full-pel and 4-pel resolutions.
  • the interpolation filters applied to the luma and chroma components of IBC blocks may be the 8-tap luma filter and the chroma filter as used in motion compensation, respectively.
  • a 2-tap bilinear interpolation filter may be applied to generating template prediction blocks, if needed the IBC- related coding tools.
  • IDVC_2023P00520WO PATENT In examples, reference sample padding may be needed if one or more reference samples are not available or located outside a valid IBC reference area in the current frame.
  • FIG.8 illustrates an example of whole-block and sub-block-based motion representation categories.
  • merge/skip and AMVP modes for coding the motion information may be used.
  • the whole-block-based motion representation may be or may include in assigning a set of motion information, made of one or two motion vectors and associating a reference picture(s) to an inter block.
  • a motion vector may be used to describe the motion of the motion before refinement.
  • the sub-block motion representation the motion may be described for sub- block.
  • FIGs.9A-9B illustrate an example control point based affine motion models.
  • FIG.9A illustrates an example of 4-parameter affine model.
  • Fig.9B illustrates an example of 6-parameter affine model.
  • the affine motion field of the block may be described by motion information of two control point motion vectors (e.g., 4-parameter affine motion model as illustrated in FIG.9A) or three control point motion vectors (e.g., 6-parameter affine motion model as illustrated in FIG.9B).
  • he vectors ⁇ ⁇ , ⁇ ⁇ , ⁇ ⁇ may be the control point motion vectors (CPMVs) associated to the block and used to represent the affine motion field of the considered block.
  • CPMVs control point motion vectors
  • motion vector at sample location (x, y) in a block may be derived as: ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ IDVC_2023P00520WO PATENT Equation 1: 4-parameter affine motion field computation.
  • motion vector at sample location (x, y) in a block may be derived as: ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ [0197]
  • Motion may corner control point.
  • (mv1x, mv1y) may be the motion vector of the top-right corner control point.
  • Motion vector (mv2x, mv2y) may be the motion vector of the bottom-left corner control point.
  • affine motion compensation may be performed on a 4x4 sub-block basis.
  • the motion vector of the center sample of the sub-block according to above equations, as illustrated in FIGs.9A-9B, may be calculated according to above equations and rounded to 1/16 fraction accuracy.
  • the motion compensation interpolation filters may be applied to generate the prediction of a sub-block with derived motion vector.
  • the sub-block size in chroma- components may be 4 ⁇ 4.
  • one or more (e.g., maximum two) inherited affine candidates may be derived from affine motion model of the neighboring blocks, e.g., one from left neighboring CUs and one from above neighboring CUs.
  • IDVC_2023P00520WO PATENT [0202]
  • FIG.11 illustrates example locations of inherited affine motion predictors.
  • the candidate blocks may be shown in FIG.11.
  • the scan order may be from A0 to A1.
  • the scan order may be from B0 to B1 to B2.
  • the first inherited candidate from each side may be selected.
  • Constructed affine candidate may be or may mean the candidate is constructed by combining the neighbor translational motion information of each control point.
  • the motion information for the control points may be derived from the specified spatial neighbors and temporal neighbor illustrated in FIG.13.
  • the B2->B3->A2 blocks may be checked and the MV of the first available block may be used.
  • the B1->B0 blocks may be checked.
  • the A1->A0 blocks may be checked.
  • TMVP may be used as CPMV4 if TMVP is available.
  • FIG.13 illustrates example locations of candidate positions for constructed affine merge mode. After inherited affine merge candidates and constructed affine merge candidate are considered for being IDVC_2023P00520WO PATENT appended to the affine merge candidate list, if the list is still not full, one or more zero MVs may be inserted to the end of the list.
  • Affine AMVP mode may be used for affine inter prediction mode.
  • Affine AMVP mode may be applied for one or more CUs with a width and/or a height larger than or equal to 16.
  • An affine indication such as an affine flag, at a CU level may be signaled, e.g., in a bitstream, to indicate the use of affine AMVP mode.
  • Another indication such as another flag, may be signaled if 4-parameter affine or 6- parameter affine model is used.
  • affine AMVP mode the difference of the CPMVs of current CU and the predictors Control Point Motion Vector Predictors (CPMVPs) may be coded.
  • CPMVPs Control Point Motion Vector Predictors
  • the CPMVPs used to predict the CPMV of a CU may be taken from an affine AMVP candidate list, e.g., made of two elements.
  • the affine AMVP candidate list may be constructed using one or more of the following types of CPVM candidate (e.g., in order): inherited affine AMVP candidates extrapolated from the CPMVs of the neighbor CUs; constructed affine AMVP candidates CPMVPs that are derived using the translational MVs of the neighbor CUs; translational MVs from neighboring CUs; and/or Zero MVs.
  • One or more checking described herein may be configured.
  • Checking a potential candidate may be or may mean checking that a valid Affine AMVP or Affine merge candidate to predict the current CU’s affine CPMVs is available and is valid, and if so, add it to the candidate list under construction.
  • the checking order of inherited affine AMVP candidates may be the same as the checking order of inherited affine merge candidates. The difference may be that, for AVMP candidate, the affine CU that has the same reference picture as in current block may be considered. Pruning process may be skipped if inserting an inherited affine motion predictor into the candidate list.
  • Constructed affine AMVP candidate may be derived from one or more spatial neighbors (e.g., one or more specified spatial neighbors) illustrated in FIG.13.
  • the same checking order may be used as in affine merge candidate construction.
  • a reference picture index of the neighboring block may be checked.
  • the first block in the checking order that is inter coded and has the same reference picture as in current CUs may be used. [0213] If the current CU is coded with 4-parameter affine mode and ⁇ ⁇ ⁇ ⁇ and ⁇ ⁇ ⁇ ⁇ are available, the MVs may be added as a candidate in the affine AMVP list. If the current CU is coded with 6-parameter affine mode, and one or more (e.g., all) three CPMVs are available, the CPMVs may be added as one candidate in the affine AMVP list.
  • constructed AMVP candidate may be set as IDVC_2023P00520WO PATENT [0214] If affine AMVP list of candidates is still less than 2 after valid inherited affine AMVP candidates and constructed AMVP candidate are inserted, ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ , and ⁇ ⁇ ⁇ ⁇ may be added, e.g., in order, as the translational MVs to predict one or more (e.g., all) control point MVs of the current CU, if available.
  • Affine motion compensation refinement with prediction refinement with optical flow may be configured.
  • Sub-block based affine motion compensation may save memory access bandwidth and/or reduce computation complexity compared to pixel-based motion compensation, e.g., at the cost of prediction accuracy penalty.
  • PROF may be used to refine the sub-block based affine motion compensated prediction without increasing the memory access bandwidth for motion compensation.
  • luma prediction sample may be refined by adding a difference derived by the optical flow equation.
  • the PROF may be described in the following: performing the sub-block-based affine motion compensation; calculating the spatial gradients ⁇ ⁇ ⁇ ⁇ , ⁇ and ⁇ ⁇ ⁇ ⁇ , ⁇ of the sub-block prediction; calculating the luma prediction refinement; and/or adding the luma prediction refinement ⁇ ⁇ ⁇ , ⁇ to the sub-block prediction ⁇ ⁇ , ⁇ .
  • the sub-block-based affine motion compensation may be performed to generate sub-block prediction ⁇ ⁇ , ⁇ .
  • the spatial gradients ⁇ ⁇ ⁇ ⁇ , ⁇ and ⁇ ⁇ ⁇ ⁇ , ⁇ of the sub-block prediction may be calculated at a sample location, e.g., using a 3-tap filter [ ⁇ 1, 0, 1].
  • the gradient calculation may be the same as follows.
  • ⁇ h ⁇ ⁇ ⁇ 1 4x4) prediction may be extended by a bandwidth and/or additional interpolation computation, the extended samples on the extended borders may be copied from the nearest integer pixel position in the reference picture.
  • the luma prediction refinement may be calculated by the following optical flow equation. ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ , where the ⁇ ⁇ ⁇ , ⁇ may be the difference between sample MV computed for sample location ⁇ ⁇ , ⁇ , denoted by ⁇ ⁇ , ⁇ .
  • FIG.14 illustrates an example subblock MV V SB and pixel ⁇ ⁇ ⁇ , ⁇ (e.g., illustrated as the dotted arrow).
  • IDVC_2023P00520WO PATENT Since the affine model parameters and the sample location relative to the sub-block center are unchanged from sub-block to sub-block, ⁇ ⁇ ⁇ , ⁇ may be calculated for the first sub-block and reused for other sub-blocks in the same CU.
  • ⁇ ⁇ ⁇ , ⁇ and ⁇ ⁇ ⁇ , ⁇ be the horizontal and vertical offset from the sample location ⁇ ⁇ , ⁇ to the center of the sub-block ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ .
  • ⁇ ⁇ ⁇ , ⁇ may be derived by the following equation: ⁇ dx ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ d y ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ ⁇ [0222] In order to keep may be calculated as ( ( WSB ⁇ 1 )/2, ( HSB ⁇ 1 ) / , and height, respectively.
  • the prediction I’ may be generated as the following equation: ⁇ ′ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ⁇ , ⁇ .
  • PROF may not be applied in for an affine coded CU if: one or more (e.g., all) control point MVs are the same, which indicates the CU the affine motion parameters are greater than a limit (e.g., a specified limit) because the sub-block based affine motion compensation (MC) is degraded to CU based MC to avoid large memory access bandwidth.
  • An encoding method may be applied, e.g., to reduce the encoding complexity of affine motion estimation with PROF.
  • PROF may not be applied at affine motion estimation stage if: the CU is not the root IDVC_2023P00520WO PATENT block and the parent block of the CU does not select the affine mode as the best mode, PROF may not be applied since the possibility for current CU to select the affine mode as best mode is low; and/or if the magnitude of four affine parameters (C, D, E, F) are smaller than a predefined threshold and the current picture is not a low delay picture, PROF may not be applied because the improvement introduced by PROF is small. As described herein, the affine motion estimation with PROF may be accelerated.
  • a device such as an encoder and/or a decoder, may be configured to increase the coding efficiency of the IBC prediction mode, e.g., for the compression of camera-captured video content.
  • the camera-captured video content may be referred to interchangeably as natural video and/or natural video content.
  • an affine model for block vector representation may be introduced to enrich a block vector model supported in IBC mode.
  • such enriched representation of block vector information may have a compression (e.g., a mean of better compressing) associated with one or more picture parts by catching a variety (e.g., large variety) of geometric transform relationships that may exist between a predicted block and a reference block of the predicted block, such as a zoom, a rotation, a symmetry, and/or the like.
  • a compression e.g., a mean of better compressing
  • two or more (e.g., two) means described herein may be configured and/or used. For example, two or more of the following may apply.
  • Two control point block vectors may be associated to an IBC coding unit and may represent the block vector information at one or more spatial locations, e.g., corresponding to the top-left and top-right corners of the considered CU (e.g., similarly to Affine inter mode).
  • three control point motion vectors may be used for an affine block vector field representation (e.g., a richer affine block vector field representation).
  • an IBC Affine BVP mode may be introduced to code affine BV information.
  • the IBC Affine BVP mode may include the signaling of a BV prediction index in an affine IBC AMVP candidate list, e.g., together with one or two motion vector differences.
  • an IBC affine merge mode may be introduced to code affine BV information.
  • the IBC affine merge mode may include the signaling of an affine BV merge index, e.g., identifying an affine BV model in an affine IBC merge candidate list.
  • an IBC affine merge mode may be supported.
  • an affine-IBC-MBVD block vector coding mode may be introduced.
  • the affine-IBC- MBVD block vector coding mode may be included in the IBC affine merge mode described herein, e.g., IDVC_2023P00520WO PATENT where from BV offset may be signaled through an index and alternatively and/or additively applied to the control point block vector (CPBV) of the considered affine IBC merge CU.
  • an IBC affine mode may introduce a BV representation at a sub-block level, such as a 4x4 sub-block level.
  • a BV may be assigned to a sub block (e.g., a 4x4 sub-block) of the affine IBC coding unit.
  • pixel-based affine prediction may be performed for an affine IBC CU.
  • a BV may be assigned to a luma sample position inside the CU.
  • PROF may be applied to an affine IBC CU, e.g., after a sub-block-based (e.g., a 4x4 sub-block-based) affine prediction is performed.
  • the affine IBC mode described herein may be activated for the coding of camera-captured video content (e.g., not graphical video content).
  • control point block vectors of a given CU may be constrained (e.g., normatively constrained) to ensure that one or more (e.g., all) block vectors in the affine BV field of one or more (e.g., all) CUs point to a prediction block spatially located inside the IBC search area, e.g., illustrated in FIG.7.
  • the means may include, with respect to fractional block vector representation, an IBC block vector that is coded at accuracy-level corresponding to 1 ⁇ 4-pel precision, 1-pel, and/or 4-pel precision.
  • two or more motion vector differences may be coded for a given CU, e.g., according to the affine-BV model used.
  • the first MVD may be coded at the accuracy level associated to the current CU. If the first MVD may be coded at the accuracy level associated to the current CU, the other BVD may be coded differentially coded, e.g., under the form of a BV difference to the first BVD. For example, the other BVD may be coded with a doubled precision level compared to the first BVD, if the first BVD is coded at 1-pel or 4-pel accuracy level.
  • Table 1 illustrates an example coding unit syntax table, e.g., supporting affine motion compensation in IBC mode as described herein.
  • One or more syntax elements may be configured (e.g., added) as illustrated in Table 1, e.g., an indication, such as an ibc_affine_flag may be signaled, a type of affine model may be signaled, one or two additional block vector differences may be signaled.
  • an indication such as an ibc_affine_flag, may be added to indicate the use of affine BV model in IBC AMVP mode.
  • the indication such as the ibc_affine_flag, may be signaled if IBC affine is allowed at sequence parameter set (SPS) level and/or for a block size higher or equal to 16 in a width and a height.
  • SPS sequence parameter set
  • IDVC_2023P00520WO PATENT If the indication, such as the ibc_affine_flag is true, a type of affine model may be signaled. For example, if two affine BV models are allowed (e.g., a 4-parameter affine model and a 6-parameter affine mode) as in inter mode, a type of affine model may be signaled.
  • IBC affine is active for current IBC AMVP CU, one or two additional block vector differences may be signaled, e.g., according to the BV affine model used (e.g., 4-param or 6-param).
  • the syntax element mvp_l0_flag shown in Table 1 may be used for non-affine IBC AMVP mode and/or affine IBC AMVP mode.
  • the syntax element mvp_l0_flag may be configured to indicate the block vector predictor used to predictively code the BV information of the current CU in IBC AMVP mode (e.g., affine or not affine).
  • an indication such as an ibc_merge_affine_flag
  • the indication such as the ibc_merge_affine_flag
  • the ibc_merge_affine_flag may indicate to a device, such as a decoder, from which BV prediction candidate to derive BV data of the current CU.
  • the BV data may be derived in the IBC merge mode or in the IBC affine merge mode.
  • a decoding procedure may be performed.
  • the CU is in IBC mode, e.g., an IBC CU, whether a CU is in merge mode may be determined.
  • the CU may be in IBC affine AMVP mode.
  • the list of affine IBC control point block vector predictor candidates for current CU may be constructed.
  • the list of affine IBC control point block vector predictor candidates may include an affine AMVP candidate list construction (e.g., similar to the inter prediction).
  • the selected predictor of CPVC of current CU may be obtained.
  • the decoded BV difference associated with a CPBV may be added to the corresponding BVs. The addition may produce the decoded CPBVs of current CU.
  • the list of affine IBC merge candidates may be constructed (e.g., similar to the affine merge candidate list construction of inter prediction but applied to block vectors).
  • the CPBVs of current CU may be derived as the CPBVs indicated by the parsed merge_idx syntax element.
  • the BV affine field of current CU may be computed (e.g., the same way as the affine motion field computation in inter affine case).
  • Affine motion compensation may be applied, e.g., producing the prediction block of current CU.
  • the prediction refinement based on optical flow (PROF) may be applied to the predicted CU, e.g., to enhance the quality of the predicted block.
  • the applied PROF may be similar (e.g., the same) process as the one for inter prediction.
  • the residual block of the current CU and/or the predicted block may be added to obtained decoded IBC affine CU.
  • the two control point block vectors mode may be supported for IBC, e.g., corresponding to the 4- parameter affine model of inter prediction. IDVC_2023P00520WO PATENT
  • IBC affine merge mode may be supported (e.g., only IBC affine merge mode may be supported).
  • the support of IBC affine merge mode may achieve compression efficiency and/or reduce complexity (e.g., compared to the case where affine IBC AMVP mode is supported).
  • Affine AMVP mode may be used in one or more pictures.
  • Affine AMVP mode may be used in an inter picture with low temporal layer ID (e.g., the lowest temporal layer ID).
  • the inter picture with low temporal layer ID (e.g., the lowest temporal layer ID) may be used as a reference picture by one or more other pictures.
  • an affine-IBC-MBVD block vector coding mode may be employed.
  • An affine-IBC- MBVD block vector coding mode may be included in the IBC affine merge mode described herein.
  • a BV offset may be signaled through an index and additively and/or alternatively applied to the CPBV of the considered affine IBC merge CU.
  • pixel-based affine prediction may be performed for an affine IBC CU.
  • a BV may be assigned to a luma sample position inside the CU. Compression efficiency may be achieved.
  • PROF prediction refinement may be skipped during the prediction of a CU.
  • the affine IBC mode described herein may be activated for the coding of camera-captured video content (e.g., and not graphical video content).
  • control point block vectors of a given CU may be constrained (e.g., normatively constrained) that one or more (e.g., all) block vectors in the affine BV field of one or more (e.g., all) CUs point to a prediction block spatially located inside the IBC search area, e.g., illustrated in FIG.7.
  • an IBC block vector may be coded at accuracy-level corresponding to 1 ⁇ 4-pel precision, 1-pel, and/or 4-pel precision.
  • two or more motion vector differences may be coded for a given CU, e.g., according to the affine-BV model used.
  • the first MVd may be coded at the accuracy level associated to the current CU. If the first MVd is coded at the accuracy level associated to the current CU, other BVd of the affine CU may be coded differentially coded in comparison to the first BVd. For example, the other BVd may be coded with a doubled precision level compared to the first BVd, if the first BVd is coded at 1-pel or 4-pel accuracy level.
  • affine block vector computed on a sub-block basis may be stored in the motion data storing buffer of the video codec used, e.g., typically on a 4x4 block basis.
  • the computed affine block vector stored in the buffer may be used for the spatial prediction of the block vector data of future block in the same picture, which may be in affine mode or non-affine mode.
  • IDVC_2023P00520WO PATENT In examples, affine block vector computed on a sub-block basis may be stored in the motion data storing buffer of the video codec used, e.g., typically on a 4x4 block basis.
  • the computed affine block vector stored in the buffer may be used for the temporal prediction of the block vector data of block in one or more future pictures, e.g., which may use the current picture as a reference picture for temporal prediction.
  • the IBC affine motion described herein may be controlled at high level, e.g., at a sequence level.
  • the IBC affine motion described herein may be controlled using a dedicated SPS signaled indication, such as a dedicated SPS signaled flag.
  • the IBC affine motion described herein may be controlled at a high level, e.g., at a picture level.
  • the IBC affine motion described herein may be controlled using a dedicated picture header signaled indication, such as a dedicated picture header signaled flag.
  • the IBC affine motion described herein may be controlled at a high level, e.g., at a slice level.
  • the IBC affine motion described herein may be controlled using a dedicated slice header signaled indication, such as a dedicated slice header signaled flag.
  • the IBC affine motion described herein may be controlled at a high level, e.g., at a sub-picture level, a tile level, and/or a tile group level.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des systèmes, des procédés et des instrumentalités pour un codage vidéo et/ou un décodage vidéo à l'aide d'un mode de copie intra-bloc (IBC). Dans des exemples, un dispositif (par exemple, un décodeur) peut obtenir une indication de mode IBC dans des données vidéo. Le dispositif peut déterminer qu'un bloc actuel est associé à un mode IBC d'après l'indication. D'après la détermination, le dispositif peut obtenir un ou plusieurs (par exemple, de multiples) vecteurs de bloc de points de commande (CPBV) associés au bloc actuel. Le dispositif peut décoder le bloc actuel d'après les CBPV. Dans des exemples, un dispositif (par exemple, un codeur) peut obtenir un bloc actuel associé à un contenu vidéo. Le dispositif peut déterminer si le bloc actuel est associé à un mode IBC affine. D'après une détermination, le dispositif peut obtenir un ou plusieurs (par exemple, de multiples) CPBV associés au bloc actuel. Le dispositif peut coder le bloc actuel d'après les CPBV.
PCT/EP2024/066741 2023-06-27 2024-06-17 Modèle de vecteur de bloc affine pour copie intra-bloc Ceased WO2025002871A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202480054276.XA CN121753323A (zh) 2023-06-27 2024-06-17 用于帧内块拷贝的仿射块矢量模型
EP24732527.7A EP4725191A1 (fr) 2023-06-27 2024-06-17 Modèle de vecteur de bloc affine pour copie intra-bloc

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP23306025 2023-06-27
EP23306025.0 2023-06-27

Publications (1)

Publication Number Publication Date
WO2025002871A1 true WO2025002871A1 (fr) 2025-01-02

Family

ID=87378191

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/066741 Ceased WO2025002871A1 (fr) 2023-06-27 2024-06-17 Modèle de vecteur de bloc affine pour copie intra-bloc

Country Status (3)

Country Link
EP (1) EP4725191A1 (fr)
CN (1) CN121753323A (fr)
WO (1) WO2025002871A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210321112A1 (en) * 2018-12-27 2021-10-14 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Coding prediction method and apparatus, and computer storage medium
WO2023046127A1 (fr) * 2021-09-25 2023-03-30 Beijing Bytedance Network Technology Co., Ltd. Procédé, appareil et support de traitement vidéo

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210321112A1 (en) * 2018-12-27 2021-10-14 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Coding prediction method and apparatus, and computer storage medium
WO2023046127A1 (fr) * 2021-09-25 2023-03-30 Beijing Bytedance Network Technology Co., Ltd. Procédé, appareil et support de traitement vidéo

Also Published As

Publication number Publication date
CN121753323A (zh) 2026-03-27
EP4725191A1 (fr) 2026-04-15

Similar Documents

Publication Publication Date Title
WO2023194556A1 (fr) Mode intra implicite pour prédiction inter-fusion/intra combinée et prédiction intra/inter de mode de partitionnement géométrique
WO2025133069A1 (fr) Mode de fusion intra tmp-lic
WO2025003037A1 (fr) Combinaison intra-tmp et lic
EP4661392A1 (fr) Réorganisation de modes de prédiction intra de chrominance et d'arbre double adaptatif
EP4633142A1 (fr) Interaction entre un mode de prédiction de vecteur de bloc direct de chrominance et à arbre double adaptatif
EP4633138A1 (fr) Interaction entre un arbre double adaptatif et une copie intra-bloc
EP4633160A1 (fr) Enrichissement de liste fusion intra block copy / compensation de mouvement avancée et liste de fusion intra template matching prediction
EP4629620A1 (fr) Vecteurs de mouvement en tant que candidats à la fusion pour des blocs intra
EP4629619A1 (fr) Utilisation généralisée de vecteur de bloc autolocalisé
EP4725191A1 (fr) Modèle de vecteur de bloc affine pour copie intra-bloc
WO2025073519A1 (fr) Filtrage appliqué à un vecteur de bloc direct de chrominance
WO2025003313A1 (fr) Filtrage adaptatif ibc/intra tmp
EP4736417A1 (fr) Liste de fusion bi-prédictive pour codage de copie intra-bloc
WO2024133579A1 (fr) Combinaison gpm avec des outils inter
WO2025003029A1 (fr) Sbt appliquée à ibc et à tmp intra
EP4736410A1 (fr) Copie intra-bloc de bi-prédiction avec une compensation d'éclairage local
EP4736435A1 (fr) Mode de partitionnement géométrique de copie intra-bloc (ibc-gpm) avec des vecteurs de bloc bi-prédictifs
WO2023194599A1 (fr) Opérations basées sur des modèles et limitées par la largeur de bande de la mémoire
EP4639907A1 (fr) Compensation de mouvement pour blocs vidéo
WO2025003493A1 (fr) Copie intra-bloc bi-prédictive avec moyennage pondéré
WO2025073657A1 (fr) Représentation de mouvement de fusion-amvp étendue
EP4736445A1 (fr) Interactions amvr avec prédiction filtrée
WO2025002858A1 (fr) Améliorations apportées à la copie intra-bloc
WO2025131916A1 (fr) Amélioration de mode de fusion de modèle ibc lic
WO2025002757A1 (fr) Prédiction temporelle pour paramètres de partitionnement

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: 24732527

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202517130758

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2024732527

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 202517130758

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2024732527

Country of ref document: EP

Effective date: 20260106

ENP Entry into the national phase

Ref document number: 2024732527

Country of ref document: EP

Effective date: 20260106

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2024732527

Country of ref document: EP

Effective date: 20260106

ENP Entry into the national phase

Ref document number: 2024732527

Country of ref document: EP

Effective date: 20260106

WWP Wipo information: published in national office

Ref document number: 2024732527

Country of ref document: EP