EP3350996A1 - Procede d'encodage d'image et equipement pour la mise en oeuvre du procede - Google Patents

Procede d'encodage d'image et equipement pour la mise en oeuvre du procede

Info

Publication number
EP3350996A1
EP3350996A1 EP16766945.6A EP16766945A EP3350996A1 EP 3350996 A1 EP3350996 A1 EP 3350996A1 EP 16766945 A EP16766945 A EP 16766945A EP 3350996 A1 EP3350996 A1 EP 3350996A1
Authority
EP
European Patent Office
Prior art keywords
encoding
blocks
image
block
search area
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
EP16766945.6A
Other languages
German (de)
English (en)
Inventor
Olivier BATARD
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.)
Ateme SA
Original Assignee
Ateme SA
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 Ateme SA filed Critical Ateme SA
Publication of EP3350996A1 publication Critical patent/EP3350996A1/fr
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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/43—Hardware specially adapted for motion estimation or compensation
    • H04N19/433—Hardware specially adapted for motion estimation or compensation characterised by techniques for memory access
    • 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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • 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/533—Motion estimation using multistep search, e.g. 2D-log search or one-at-a-time search [OTS]

Definitions

  • the present invention relates to an image encoding method and a device for implementing this method. It applies in particular to the coding of images of a video stream.
  • the video data is generally subject to source coding to compress them in order to limit the resources required for their transmission and / or storage.
  • source coding There are many coding standards, such as H.264 / AVC, H.265 / HEVC and MPEG-2, that can be used for this purpose.
  • a video stream comprising a set of images is considered.
  • the images of the video stream to be encoded are typically considered in an encoding sequence, and each is divided into sets of pixels also processed sequentially, for example beginning at the top left and ending at the bottom. to the right of each image.
  • the encoding of an image of the stream is thus performed by dividing a matrix of pixels corresponding to the image into several sets, for example blocks of fixed size 16 ⁇ 16, 32 ⁇ 32 or 64 ⁇ 64 pixels, and encoding these blocks of pixels according to a given processing sequence.
  • Some standards such as H.264 / AVC, provide the possibility to break blocks of size 16 x 16 pixels (called macro-blocks) into sub-blocks, for example of size 8 x 8 or 4 x 4, in order to perform encoding processes with finer granularity.
  • the H.265 / HEVC standard provides for the use of fixed size blocks up to 64 x 64 pixels, which can be partitioned to a minimum size of 8 x 8 pixels.
  • the existing techniques of video compression can be divided into two main categories: on the one hand compression called “Intra”, in which the compression treatments are performed on the pixels of a single image or video frame, and secondly compression called “Inter”, in which the compression treatments are performed on several images or video frames.
  • Intra the processing of a block (or set) of pixels typically comprises a prediction of the pixels of the block made using causal pixels (previously coded) present in the image being encoded (referred to as " current image "), in which case we speak of” Intra prediction ".
  • the processing of a block (or set) of pixels typically comprises a prediction of the pixels of the block made using pixels from one or more images previously coded, in which case we speak of "Inter prediction” or "motion compensation".
  • hybrid High Efficiency Video Coding
  • This exploitation of the spatial and / or temporal redundancies makes it possible to avoid transmitting or storing the value of the pixels of each block (or set) of pixels, by representing at least some of the blocks by a residual of pixels representing the difference (or the distance) between prediction values of the pixels of the block and the real values of the pixels of the predicted block.
  • Pixel residual information is present in the data generated by the encoder after transform (eg discrete cosine transform, or DCT, for Discrete Cosine Transform) and quantization to reduce data entropy generated by the encoder.
  • transform eg discrete cosine transform, or DCT, for Discrete Cosine Transform
  • a video encoder typically performs an encoding mode selection corresponding to a selection of encoding parameters for a processed pixel array. This decision-making can be implemented by optimizing a rate and distortion metric, the encoding parameters selected by the encoder being those that minimize a rate-distortion criterion. The choice of the encoding mode then has an impact on the performance of the encoder, both in terms of rate gain and visual quality.
  • the implementation of a video encoder for which real-time processing performance is sought may be performed in the form of a combination of hardware and software elements, such as a software program to be loaded and executed on a hardware component.
  • type FPGA Field Programmable Gate Array
  • ASIC Application Specifies Integrated Circuit
  • Programmable logic circuits of FPGA Field-Programmable Gate Array
  • An ASIC is a dedicated electronic circuit that brings together custom features for a given application.
  • An encoder can also use hybrid architectures, such as CPU + FPGA based architectures, a Graphics Processing Unit (GPU), or Multi-Purpose Processor Array (MPPA).
  • hybrid architectures such as CPU + FPGA based architectures, a Graphics Processing Unit (GPU), or Multi-Purpose Processor Array (MPPA).
  • video encoders implemented on a dedicated component are often limited, especially those that perform processing in parallel, by the bandwidth available for the transfer of data between the component and an external memory in which are stored the data of the video stream to be encoded. .
  • This limitation is usually overcome by the implementation of a cache memory implanted on the component, which thus enjoys a much larger bandwidth than that of an external memory.
  • the limitations imposed on the encoder are various. Generally, they result in a limitation of the motion estimation algorithms allowed by the encoder.
  • Another object of the present invention is to provide an image encoding method using an improved cache memory for a real-time implementation.
  • a method of encoding a first image in a set of images wherein the first image is divided into blocks, each block being encoded according to one of a plurality of encoding modes comprising at least one least one time correlation prediction type coding mode using a plurality of images of the set of images, the method comprising, for a current block of the first image: defining, in a second image of the set of images distinct from the first image and previously coded according to a predefined encoding sequence of the images of the set of images, a unitary search zone of motion estimation vectors; load the data from the unit search area into a cache memory; determining, by a search in the cached unit search area, a motion estimation vector of the current block, the motion estimation vector pointing to a block of the search area correlated to the current block; and using the motion estimation vector to decide the encoding of the current block according to one of the plurality of encoding modes; wherein the unit search area comprises a set of data of the second
  • the proposed method optimizes the shape of the search area to be loaded into the cache, so as to minimize the amount of data loaded into the cache memory and not used by subsequent processing, such as for example processing related to the cache. motion estimation or motion compensation.
  • the unitary search area has substantially an ovoid shape.
  • the unit search area may also be determined such that at least a portion of the unit search area is substantially in the shape of an ellipsoid portion.
  • the ellipsoidal shape advantageously makes it possible to increase the excursion of the vector components without complexity of implementation or use of significant additional resources.
  • This embodiment of the proposed method has the advantage of increasing, for the same memory space, the excursion of the components of the motion vectors, without loss due, if necessary, to the configuration shape of the blocks of the group of blocks. encoding intended to be encoded in parallel.
  • the unit search area may be determined having a substantially ellipsoidal shape.
  • the unitary search area may be determined with a contour that defines a polygon of substantially elliptical shape.
  • the proposed method can also advantageously be applied to the case of a group of encoding blocks intended to be encoded in parallel, such as for example a group of 2, 3, or 4 encoding blocks.
  • a multiple search area is thus defined for a plurality of encoding blocks by unitary search zone meeting corresponding to the encoding blocks of the plurality of encoding blocks, respectively.
  • the data of the multiple search area in the cache memory a search is made in the multiple search area loaded in the cache memory, a plurality of estimation vectors respectively corresponding to the encoding blocks of the plurality of blocks of data. encoding, and the estimation vectors determined for the encoding of the encoding blocks of the plurality of encoding blocks are used.
  • the proposed method can furthermore be adapted to different forms of configuration of the blocks of the group of encoding blocks intended to be encoded in parallel, such as for example the MBAFF configuration of the H.264 type encoders (in English, "Macroblock-Adaptive”). Frame / Field Coding ").
  • a device for encoding a first image in a set of images comprising: an input interface configured to receive the first image; a video encoding unit, operatively coupled to the input interface, and configured to encode the first image using the proposed method.
  • a computer program loadable in a memory associated with a processor, and comprising portions of code for implementing the steps of the proposed method during the execution of said program by the processor, and a set of data representing, for example by compression or encoding, said computer program.
  • Another aspect relates to a non-transient storage medium of a computer executable program, comprising a data set representing one or more programs, said one or more programs including instructions for executing said one or more programs.
  • a computer comprising a processing unit operably coupled to memory means and an input / output interface module, causing the computer to encode a first image in a set of images according to the proposed method.
  • the proposed method is particularly well, although not exclusively, for encoding or compressing an image of an image sequence according to an H.264 / AVC (Advanced Video Coding) scheme. But it is also suitable for encoding images according to any video coding scheme operating on block-cut images in which the blocks are encoded according to a plurality of coding modes comprising at least one prediction type coding mode. temporal correlation using a plurality of images of the video stream to be encoded, such as an H.265 / HEVC encoding scheme.
  • the proposed method may advantageously be implemented in cases where the time correlation prediction type coding mode using a plurality of images of the set of images is of a type using a motion prediction from images.
  • previously coded type of coding mode referenced in some video coders under the name "Inter”
  • predetermined predictor vector selected from neighboring blocks of the previously coded current block
  • FIG. 1 is a diagram illustrating an encoder type H.264 / AVC
  • FIG. 2 is a diagram illustrating the architecture of an encoder for the implementation of the proposed method
  • FIGS. 3a, 3b, and 3c are diagrams illustrating Intra prediction modes
  • FIG. 4 is a diagram illustrating a median vector determination for coding in Inter prediction mode
  • FIG. 5 is a diagram illustrating an encoder architecture using an FPGA component and an external memory
  • FIG. 6a is a diagram illustrating a fractional pixel position determined in the context of an Inter prediction according to one embodiment
  • FIGS. 6b and 6c are diagrams illustrating a candidate motion vector and a set of vectors tested in the context of an Inter prediction according to one embodiment
  • FIG. 7 is a diagram illustrating an encoder architecture for implementing the proposed method
  • FIGS. 8a, 8b, 8c, 8d, 8e, and 8f are diagrams illustrating the loading of cached data for the encoding of a pair of encoding blocks
  • FIG. 9a is a diagram illustrating the loading of cached data for the encoding of a group of four encoding blocks
  • FIGS. 9b and 9c are diagrams illustrating the configuration of a group of four encoding blocks to be encoded in parallel;
  • FIGS. 9d and 9e are diagrams illustrating the loading of cached data for the encoding of a group of four encoding blocks
  • FIG. 10 is a diagram illustrating the proposed method according to an implementation mode
  • FIGS. 11a, 11b, 11c, 11d, 11f, 11f, 11g, 11b and 11b are diagrams illustrating different configurations of search zones according to different modes. implementation.
  • pixel and “pixel” are used interchangeably.
  • Sample to designate an element of a digital image.
  • the proposed method can be implemented by any type of image encoder of a set of images, such as, for example, a video codec conforming to H.264 / AVC, H.265 / HEVC, and / or MPEG standards. -2.
  • an H.264 / AVC type encoder using macroblocks (MB) of size 16 ⁇ 16 pixels can be adapted to an H.265 / HEVC type encoder by replacing the MB16x16 by blocks of type CTB16, CTB32 and CTB64, of respective sizes 16x16, 32x32 and 64x64, defined by the standard HEVC.
  • MB macroblocks
  • FIG. 1 illustrates an exemplary encoder architecture (10) of the type
  • An image stream F to be encoded (F n ) is provided at the input of the encoder (10).
  • Each image F n (1 1) of the input stream is divided into macroblocks of size 16 ⁇ 16 pixels, to be encoded according to a predetermined sequence of encoding macroblocks, for example from top to bottom and from left to right. .
  • Macroblocks are predicted using causal pixels (previously coded) present in the current image ("Intra” prediction), or using pixels from one or more previously coded images (prediction " Inter "). This exploitation of the spatial and temporal redundancies makes it possible to represent the coding units by a residual of pixels as small as possible which is then transmitted to the decoder, possibly after transformation and quantization.
  • Each macro-block to be encoded is provided as input to a motion estimation unit (12) ("ME” for “Motion Estimation”), which generates data relating to the movement of the block being encoded relative to to one or more previously encoded images F ' n _ 1 (13), commonly referred to as reference images, which are also inputted to the motion estimation unit (12).
  • the motion data produced by the motion estimation unit is supplied to a motion compensation unit (14) (or Inter prediction) ("MC”, for “Motion Compensation”), which further receives input the reference image (s) used by the estimation unit of movement (12).
  • the motion compensation unit (14) generates Inter prediction data, which is provided to an encoding decision unit (15).
  • the data of the block to be encoded are also provided to an Intra prediction choice unit (16) which evaluates different neighboring blocks of the block to be encoded in the current image as part of the Intra prediction.
  • the Intra prediction choice unit (16) generates, as input to an Intra prediction unit (17), data of one or more adjacent blocks of the current block (being encoded) for the Intra prediction, and the Intra prediction unit (17) outputs Intra prediction data, which is provided to the encoding decision-making unit (15), which selects an Inter-type prediction or an Intra-type prediction. according to the prediction data received for these two modes.
  • the Intra prediction choice unit (16) and the Intra prediction unit (17) receive as input encoded image data uF ' n .
  • a determination (18) of residual D n is made from the data of the current image (for the current block) F n and the prediction data selected by the encoding decision-making unit (15).
  • This pixel residual is then processed by transformation (T) (19) and quantization (Q) (20), and the quantized data (X) is encoded by entropy encoding (21) to generate an encoded stream (NAL).
  • An image reconstruction loop from the encoding data retrieves the quantized data (X) for processing by inverse quantization (Q "1 ) (22) and transform (T 1 ) (23) operations.
  • inverse operation (24) of the residual determination operation is further applied to reconstruct already encoded blocks uF ' n , which will be used by the Intra prediction units to provide data of neighboring blocks of the block being encoded. will then be filtered (25) for the reconstruction of whole images (26) F ' n , which will provide the reference images for the Inter prediction units.
  • the images are sequentially considered and divided into sets of sequentially processed pixels starting at the top left and ending at the bottom right.
  • These sets of pixels are called “encoding units” in the HEVC standard, and are of maximum size 64 x 64 pixels, the coding units of this size being called “Large Coding Units", or "LCU”.
  • LCU Large Coding Units
  • These sets of pixels are predicted using causal pixels (previously coded) present in the current image (“Intra” prediction), or using pixels from one or more previously coded images (prediction "Inter”). This exploitation of the spatial and temporal redundancies makes it possible to represent the coding units by a residual of pixels as small as possible which is then transmitted to the decoder, possibly after transformation and quantization.
  • the encoder 100 receives at input 109 an input video stream 101 comprising a plurality of images to be processed in order to perform the encoding of the stream.
  • the encoder 100 comprises a controller 102, operatively coupled to the input interface 109, which drives a motion pre-estimation unit (PRE-ME) 1 12, a motion estimation unit (ME) 1 10 and a motion compensation (MC) prediction unit 104 for Inter, Merge and / or Skip type predictions (described below), as well as an Intra mode prediction unit 103.
  • the received data on the input interface 109 are transmitted to the input of the Intra mode prediction 103, motion pre-estimation 1 12, and the controller 102 units.
  • the controller assembly 102, motion estimation unit 1 10, unit prediction system 104 for the Inter, Merge and Skip predictions, and Intra mode prediction unit 103 forms a 1 1 1 encoding unit operably coupled to the input interface 109.
  • the encoding unit 11 1 is further operably coupled to a memory unit 1 13, for example of the RAM type, through the controller 102 in the example illustrated in FIG. 2.
  • the Intra mode prediction unit 103 generates Intra prediction data 107 which is inputted to an entropy encoder 105.
  • the motion prediction unit 1 12 generates, for an encoding block, a list of vectors. potential candidates for the Inter decision, provided to the motion estimation unit 1 10.
  • the motion estimation unit 110 and the Inter / Merge / Skip 104 prediction unit perform a refinement of the candidate vectors. potential and then select a better candidate.
  • the Inter / Merge / Skip mode prediction unit 104 generates Inter, Merge, or Skip prediction data 106 that is inputted to the entropy encoder 105.
  • the data supplied to the decoder for an Inter-type prediction may include a residual of pixels and information concerning one or more motion vectors.
  • This information relating to one or more motion vectors may comprise one or more indices identifying a predictor vector in a list of predictor vectors known to the decoder.
  • the data provided to the decoder for a Skip type prediction will typically not include any residual pixels, and may also include information identifying a predictor vector in a list of predictors known to the decoder.
  • the list of predictor vectors used for Inter coding will not necessarily be the same as the list of predictor vectors used for Skip coding.
  • the controller 102 generates control data 108 which is also inputted to the entropy encoder 105.
  • the controller 102 is configured to drive the Intra mode prediction unit 103 and the Inter / Merge / Skip mode prediction unit 104 to control the prediction data which is respectively input to the entropy coder 105 by the Intra 103 mode prediction unit and Inter / Merge / Skip mode prediction unit 104.
  • the controller 102 may further be configured to select from the different types of prediction mode (Intra mode, Inter mode, Merge mode or Skip mode depending on the coding modes implemented in the encoding unit 1 1 1) for which prediction data will be transmitted to the entropy coder 105.
  • the encoding scheme may include a decision for each processed encoding block to select the type of prediction for which data will be transmitted to the entropy encoder 105.
  • This choice will typically be nt implemented by the controller, to decide whether to apply the Inter prediction mode, the Intra prediction mode, the Merge prediction mode or the Skip prediction mode to the current block (or coding unit). treatment.
  • This makes it possible to control the sending to the entropic coder of Intra 107 prediction data or Inter, Merge or Skip 106 prediction data as a function of the decision made by the controller 102.
  • the encoder 100 may be a computer, a computer network, an electronic component, or another apparatus having a processor operatively coupled to a memory, and, depending on the embodiment selected, a data storage unit. , and other associated hardware elements such as a network interface and a media player for reading and writing on a removable storage medium on such a medium (not shown in the figure).
  • the removable storage medium may be, for example, a compact disc (CD), a digital video / versatile disc (DVD), a flash disk, a USB key, etc.
  • the memory, the data storage unit, or the removable storage medium contains instructions that, when executed by the controller 102, cause the controller 102 to perform or control the interface portions of the device.
  • the controller 102 may be a component implementing a processor or a calculation unit for encoding images according to the proposed method and controlling the units 109, 1 10, 1 12, 103, 104, 105 of the encoder 100.
  • the encoder 100 can be implemented in software form, as described above, in which case it takes the form of a program executable by a processor, or in hardware form (or “hardware"), as a specific integrated circuit application (ASIC), a system-on-a-chip (SOC), or in the form of a combination of hardware and software elements, such as for example a software program intended to be loaded and executed on a FPGA-type component (Field Programmable Gâte Array ).
  • SOC System On Chips
  • on-chip systems are embedded systems that integrate all components of an electronic system into a single chip.
  • An encoder can also use hybrid architectures, such as CPU + FPGA based architectures, a Graphics Processing Unit (GPU), or Multi-Purpose Processor Array (MPPA).
  • hybrid architectures such as CPU + FPGA based architectures, a Graphics Processing Unit (GPU), or Multi-Purpose Processor Array (MPPA).
  • the image being processed is divided into encoding blocks or coding units (in English "Coding Unit” or CU), the shape and size of which are determined in particular as a function of the size of the matrix of pixels representing the image, for example square macroblocks of 16 x 16 pixels.
  • a set of blocks is defined for which a processing sequence (also called “processing path") is defined.
  • processing sequence also called "processing path”
  • blocks of square shape one can for example treat the blocks of the current image starting with the one located at the top left of the image, followed by that immediately to the right of the preceding one, until arriving at the end of the first row of blocks to move to the left-most block in the block line immediately below that first line, to complete the processing by the lowest-most block of the image.
  • the processing of the current block may include partitioning the block into sub-blocks, in order to process the block with a finer spatial granularity than that obtained with the block.
  • the processing of a block furthermore comprises the prediction of the pixels of the block, by exploiting the spatial correlation (in the same image) or the temporal correlation (in one or more other previously coded images) between the pixels.
  • the prediction of the pixels of the block typically comprises the selecting a prediction type of the block and prediction information corresponding to the selected type, the set forming a set of encoding parameters.
  • the prediction of the processed pixel block makes it possible to calculate a residual of pixels, which corresponds to the difference between the pixels of the current block and the pixels of the prediction block, and is in some cases transmitted to the decoder after transformation and quantization.
  • This coding information 106-108 may notably comprise the coding mode (for example the particular type of predictive coding among the "Intra” and “Inter” codings, or among the "Intra", “Inter”, “Merge” and “Skip” described below), the partitioning (in the case of one or more blocks partitioned into sub-blocks), and a motion information 106 in the case of an "Inter” type predictive coding, "Merge” or “Skip” and an Intra 107 prediction mode in the case of an "Intra” type predictive coding.
  • the coding modes "Inter", “Skip” and “Merge” these last two pieces of information can also be predicted in order to reduce their coding cost, for example by exploiting the information of the neighboring blocks of the current block.
  • the HEVC standard uses a quadtree coding scheme, described below, combined with a dynamic block size selection.
  • HEVC allows partitioning of each current image into blocks ranging in size from 64 x 64 pixels to 8 x 8 pixels.
  • the video stream to be encoded can thus be traversed with blocks of 64 x 64, each block of size 64 x 64 can be cut into blocks of smaller size (the finest cutting authorized being that in 8 x 8 blocks, each of size 8 x 8 pixels).
  • the encoder typically chooses the size of blocks used according to proprietary criteria that are not defined by the standard.
  • the video encoder may further use a YCbCr type representation of the color space of the video signals with sampling that may be 4: 2: 2 or 4: 2: 0 (sub-color sampling).
  • the video signal to be encoded carries a luminance information (signal Y) and two pieces of information chrominance (Cb and Cr signals).
  • the samples of each component (Y, Cb, Cr) can be encoded on 8 bits, 10 bits or more.
  • an H x L pixel size (or samples) of luminance is of size H / 2 x L for each chrominance component, which amounts to sub-sampling of colors in the horizontal direction only.
  • the 4: 2: 2 representation corresponds to the so-called SDI (System Deployment Image) signal format.
  • an H x L pixel (or sample) luminance size is of size H / 2 x L / 2 for each chrominance component, which amounts to sub-sampling of colors in the horizontal direction and in the vertical direction.
  • the predictive coding in "Intra” mode includes a prediction of the pixels of a block (or set) of pixels being processed using the previously coded pixels of the current image.
  • the values of the neighboring pixels of the current block belonging to blocks that have been previously coded are used, and an average of the values of these pixels is calculated. neighbors.
  • the predictive block is constructed using for each pixel the average value obtained.
  • the two sets of 8 neighboring pixels 201, 202 of the neighboring block disposed to the left of the current block and the neighboring block disposed at the left are used. above the current block.
  • An average value M of the values of these 16 pixels, which is used to fill the pixel values of the predictive block 200, is calculated.
  • VL "Intra” prediction mode
  • VL “Vertical-Left”
  • each of the 8 neighboring pixels is copied into the corresponding column of the predictive block 220 in a left diagonal projection direction as illustrated in FIG. 3c.
  • the H.264 / AVC video coding standard provides for 9 Intra prediction modes (including the DC, H, V, VL prediction modes described above).
  • the HEVC video coding standard predicts a greater number of 35 Intra prediction modes for luminance samples, and 5 modes for chrominance samples.
  • video coding standards also provide special cases for intra prediction.
  • the H.264 / AVC standard allows 16x16 pixel blocks to be chopped into smaller blocks, up to 4x4 pixels in size, to increase the granularity of the predictive coding process.
  • the information of the Intra prediction mode is predicted in order to reduce its coding cost. Indeed, the transmission in the encoded stream of an index identifying the Intra prediction mode has a higher cost as the number of usable prediction modes is important. Even in the case of H.264 / AVC coding, the transmission of an index between 1 and 9 identifying the Intra prediction mode used for each block among the 9 possible modes turns out to be expensive in terms of coding cost.
  • HEVC standard provides for the determination of not more than three Intra predicted modes. If the encoder makes an encoding decision using one of these modes, only information relating to its index (sometimes referred to as "mpm_index”) and to an indicator indicating that one of the predicted modes has been chosen is transmitted by the encoder. Otherwise, the encoder transmits information relating to a deviation with the predicted modes (sometimes denoted "rem_intra_pred_mode").
  • MPM in English "Most Probable Mode"
  • MPM is the result of the prediction of the Intra prediction mode used to encode the current block.
  • the Intra mode When the Intra mode is selected for the encoding of the current block, it will be possible to transmit to the decoder typically a set of coefficients corresponding to the transformed and quantized pixel residual and the MPM.
  • the time correlated prediction type prediction coding referenced for certain video coders under the name "Inter" includes a prediction of the pixels of a block (or set) of pixels being processed using pixels derived from one or more previously encoded images (pixels that are not derived from the current image, unlike the Intra prediction mode).
  • the Inter prediction mode typically uses one or two sets of pixels respectively located in one or two previously encoded images to predict the pixels of the current block. That said, it is possible to envisage, for an Inter prediction mode, the use of more than two sets of pixels located respectively in previously distinct two-to-two coded images whose number is greater than two.
  • This technique called motion compensation, involves the determination of one or two vectors, called motion vectors, which respectively indicate the position of the set or sets of pixels to be used for the prediction in the image or images.
  • Previously encoded images usually referred to as "reference images").
  • the vectors used for the "Inter" mode are to be chosen by the encoder 100 by means of the motion estimation unit 1 12, from the motion estimation unit 1 10 and the prediction unit Inter / Merge / Skip modes 104.
  • the implementation of the motion estimation within the encoder 100 can therefore provide, depending on the case, the determination of a single vector of motion estimation, two or more motion estimation vectors that point to different images.
  • the motion estimation vector (s) generated at the output of the motion estimation unit 110 will be supplied to the Inter / Merge / Skip mode prediction unit 104 for the generation of Inter prediction vectors.
  • Each prediction vector Inter can indeed be generated from a corresponding motion estimation vector.
  • Motion estimation can consist in studying the displacement of the blocks between two images by exploiting the temporal correlation between the pixels. For a given block in the current image (the “current block” or “original block”), the motion estimation makes it possible to select a most similar block (referred to as “reference block”) in a previously coded image, called “reference image”, by representing the movement of this block, for example with a two-dimensional vector (and therefore two components representing for example respectively a horizontal displacement and a vertical displacement).
  • reference block a most similar block in a previously coded image
  • the motion estimation method is non-normative and is therefore likely to differ from one encoder to another.
  • the motion estimation method may include searching in a more or less extended area of the reference image, for example defined from the block of the reference image corresponding to the original block in the original image, in order to test the resemblance of the original block with a larger or smaller number of candidate blocks of the reference image.
  • the correlation between a block and its displacement according to a motion estimation vector can be calculated using the Absolute Difference Sum (SAD):
  • the vector resulting from the motion estimation may serve as a basis for the determination of a vector Inter prediction.
  • the method of prediction Inter may include optimizations aimed at selecting a vector distinct from the vector resulting from the motion estimation, in order to have a prediction less expensive possible for the mode that is tested.
  • This optimization may for example include the testing of one or more vectors around the vector resulting from the motion estimation likely to give a better result depending on the objective pursued. Therefore, the vector used for the Inter prediction with respect to a given reference image will not necessarily be identical to the vector resulting from the motion estimation for this reference image.
  • the Inter mode When the Inter mode is selected for the encoding of the current block, it will be possible to transmit to the decoder typically the residual of pixels (calculated for each prediction vector Inter as a function of the pixels of the current block and of the pixels of the block to which the vector of Inter prediction) and information concerning the corresponding Inter prediction vector or vectors.
  • the Inter prediction vector or vectors can represent a significant cost in video encoders. Some encoders reduce this coding cost by exploiting the vectors of the neighboring blocks of the block being encoded. This optimization involves a prediction of the Inter prediction vector (s), like the prediction of the Intra prediction mode in the case of a predictive coding of the Intra mode block.
  • the information concerning each Inter prediction vector can thus be reduced in size by transmitting, in place of the coordinates of the vector for example, an index of a predictor vector in a known dictionary of the encoder and the decoder, and a residual quantifying the distance between the prediction vector and the predictor vector.
  • a median predictor vector mv pred is used to predict the vector to be encoded mv.
  • the principle used in the HEVC standard is similar in that it provides for the transmission of a residual vector e mv , which is however not calculated using a median predicted vector.
  • the standard actually specifies a method for calculating a set of predicted vectors.
  • the encoder then chooses a predictor from among these possible predicted vectors. It can thus transmit, with the residual vector, an index number of the predictor vector retained, so that the decoder can use the same.
  • the bidirectional prediction technique typically involves a weighted average of two Inter-type predictions.
  • the encoder selects a set of prediction parameters for a "direction" (for a first reference image) and then for a second "direction” (for a second reference image, distinct from the first reference image).
  • the encoder determines whether it retains only one of the two directions, or both, in which case an average of the two generated predictions is determined before calculating a corresponding pixel residual, which will eventually be processed by transformation and quantization.
  • the bidirectional prediction therefore corresponds in principle to an "Inter" type prediction with two predicted vectors.
  • aspects of the proposed Inter prediction method are applicable to bidirectional prediction.
  • FIG. 4 illustrates the determination of a corresponding predictor vector in the example illustrated at the median between the previously encoded neighboring block vectors.
  • the current block (in the course of encoding) 241 is surrounded by four neighboring blocks 243a, 243b, 243c, 243d previously encoded and three neighboring blocks 243a, 243b, 243c remaining to be coded.
  • the example presented assumes an encoding step of the blocks of the image such that, for each block being encoded, the blocks on the left or above the current block have already been encoded, so that on FIG. 4, the previously encoded neighboring blocks 243a, 243b, 243c, 243d are situated on the left 243a or above 243b, 243c, 243d of the current block 241.
  • the predictor vector mv pred 244 of the current block 241 corresponds to the median between the respective vectors 245a, 245b, 245c, 245d of the previously coded blocks 243a, 243b, 243c or 243a, 243b, 243d when the block 243c is for example not available.
  • the block 243c is encoded according to an Intra mode predictive coding.
  • a bad predictor vector will result in coding overhead for the current block 241.
  • the H.264 / AVC and HEVC standards provide rules for using one of the available vectors to the extent that the median is not computable.
  • Some coders use, sometimes in the context of the "Inter" prediction mode, a mode referenced in some video coders under the name "Skip” in which, as in the case of Inter mode, the current block is predicted using pixels from previously coded images (one or two images, or more depending on the implementation).
  • Skip mode is sometimes presented as a sub-mode of the Inter mode, because it corresponds to a prediction mode "Inter” without transmission (or generation in the encoded stream) prediction vector or residual pixels.
  • Skip mode is applicable when the pixel residual is small enough that it is considered unnecessary to transmit it into the encoder output stream.
  • the prediction vector or vectors used for this mode will typically not be transmitted to the decoder, and will be deduced by the decoder from a predetermined list of possible vectors.
  • predictors which will allow for example to transmit only the position of the predictor vector (for example a position index in the list of predictors) instead of transmitting its value (such as its coordinates).
  • a predictive vector is directly selected from a known predetermined list of the decoder, the selection of the predictor vector being effected from neighboring blocks of the current block which have previously been coded.
  • the respective lists of predictor vectors whether by their size or by their respective contents, will not necessarily be identical.
  • the HEVC standard provides another mode of predictive coding, called "Merge", similar to the Skip mode described above with the difference that we can transmit a residual pixel.
  • the Merge mode can thus also correspond to a prediction mode Inter, without transmission (or generation in the encoded stream) prediction vector, but in which a pixel residual and generated and transmitted in the encoded stream.
  • reference images are usually stored in a large depth memory, in order to store a set of multiple images. For example, storing 10 1920x1080-pixel HD images with 4: 2: 2 8-bit sampling requires 40 MB of storage space.
  • the memories used for this storage typically have average performance in terms of bandwidth. This is typically of the order of 2 Gb / s in the case of a DDR3-1333 type SDRAM RAM box. For example, with a reading efficiency of 70% for large quantities of burst data, we obtain a bandwidth of 1333333333 Hz x 16 bits x 0.7, or 1, 7 GB / s.
  • FIG. 5 illustrates a hardware architecture of this type, in which an encoder 400 implemented on a component 402 of the FPGA type stores reference images in a RAM 401.
  • the encoder may perform a motion estimation phase as part of an Inter, Skip or Merge prediction. which will require the reading in the storage RAM 401 of reference data (denoted F ⁇ ).
  • the encoder will be able to log in the RAM 401 data (denoted F ⁇ ) of the encoded image reconstructed from the decision taken, for use during the encoding of the images. following in the video stream.
  • the encoder 400 can therefore be provided with a motion estimation unit (ME) 403 and a motion compensation unit (MC) 404, the motion estimation unit 403 can also be configured to performing processing on data generated by a motion estimation unit 405, for example data 406 relating to candidate motion vectors as explained above with reference to FIG. 2.
  • a motion estimation unit for example data 406 relating to candidate motion vectors as explained above with reference to FIG. 2.
  • the amount of reference data (F ⁇ ) required for the functions of the motion estimation unit (ME) 403 and the motion compensation unit (MC) 404 of the encoder 400 may be of sufficient importance to consider using a cache system, especially to achieve the performance required in a hardware implementation of real-time processing.
  • this amount of data may be significantly larger than the amount of data corresponding to a single image, due in particular to the number of candidate vectors tested, to the increase in the pixel area required for the image. refining of the candidates (part ME of the treatments), and of the increase of the zone of pixels necessary for the computation of the prediction Inter (part MC of the treatments).
  • the area needed to calculate the inter prediction of an encoding block is equal to the size of this block increased by two crowns, one of which is necessary for the quarter-turn interpolation. pixel, and the other is necessary to the motion estimation excursion.
  • the motion vectors can be determined with fractional pixel precision, in that a motion vector can point to a fractional pixel element generated between two neighboring pixels. . In this case, fractional samples will be generated between two neighboring samples, for example by interpolation between these two samples.
  • the HEVC standard provides for the generation of fractional luminance samples by defining an 8-coefficient interpolator filter for the half-sample (or half-pixel) positions and a 7-coefficient interpolator filter for the positions. sample quarter (or quarter-pixel).
  • the HEVC standard thus enables the generation of motion vectors with a precision equal to one quarter of the distance between two luminance samples.
  • FIG. 6a illustrates this calculation, and shows 5 pixels 601a-601e of a reference image 600.
  • the pixels 601d and 601e belong to an encoding block 602 in the course of Inter-prediction encoding.
  • the calculation of the half-pixel 603 between the pixels 601d and 601e can use the values of the 601a-601e pixels as a function of the implementation.
  • the motion estimation function can comprise, as a function of the implementation, the testing of a set of vectors close to an initial vector, called the candidate vector, and the choice among the tested vectors of a vector minimizing a correlation function (often of the SAD or SSD type) between the prediction block and the block to be encoded.
  • this operation performs a refinement of candidate vectors identified by the motion pre-estimation function.
  • FIG. 6c illustrates this increase by showing an assembly covering a 5 ⁇ 5 pixel area that ultimately requires (when taking into account a ring necessary for quarter-pixel interpolation) an area of 21 ⁇ 21 pixels.
  • FIG. 6b shows a reference image 605 on which is represented the block 606 co-located in the reference image 605 with the encoding block being encoded in the current image.
  • a candidate vector 608 points to a pixel (half-pixel or quarter-pixel depending on the selected granularity) of the reference image 605, and a set 607 of vectors tested respectively point to pixels (half-pixels or quarter-pixels according to the selected granularity). the selected granularity) of the reference image 605.
  • FIG. 6c shows the end of the candidate vector 606, and the pixel 608 toward which this vector 606 points, as well as two test vectors 607a and 607b and the pixels 609a and 609b to which these vectors 607a and 607b respectively point.
  • vector pixels tested all the pixels to which the test vectors point respectively (referred to as "vector pixels tested" in FIG. 6c) will have to be included in the data. of the reference image retrieved from the RAM for the purposes of the processing of the Inter prediction.
  • Certain encoding standards such as the H.264 / AVC and H.265 / HEVC standards, allow the partitioning of a block to be encoded to split the Inter prediction into several zones each having a specific vector. This allows a better match of the macro-block to be encoded with the reference image, especially on object boundaries having different movements.
  • this partitioning increases the number of candidate vectors that one may wish to test in the encoder for an encoding block, and therefore the amount of data necessary for the decision of the inter prediction of a block. encoding.
  • partitioning a block of 16 pixels x 16 pixels in four 8 pixel x 8 pixel partitions requires four areas of 13 pixels x 13 pixels, making a total area of 52 pixels x 52 pixels.
  • the H.264 standard allows multiple partitioning of a macroblock of 16 pixels x 16 pixels, up to partitioning in blocks of 4 pixels x 4 pixels.
  • cache memory that is to say a memory space, often internal to the component, for example ASIC or FPGA, on which is implemented the video encoder, having a bandwidth in reading much more effective than that of an external memory, overcomes this problem of bandwidth limitation of an external memory.
  • a cache memory can be implemented within an Altera Stratix-III (FPGA) type FPGA (EP3SL340) using 32 M144K internal memories each of which can contain 2048 72-bit words.
  • FPGA Altera Stratix-III
  • EP3SL340 Altera Stratix-III type FPGA
  • Fig. 7 shows an implementation of the encoder implemented on an FPGA component illustrated in Fig. 4 using a cache memory within the Inter prediction decision unit.
  • An encoder 700 is implemented on a component 702 of the FPGA type, and stores in a RAM memory 701 external to the FPGA component 702 reference images F '.
  • the encoder 700 may perform a motion estimation phase as part of an Inter, Skip or Merge prediction, and read to do this in a cache memory 707 implemented on the FPGA component 702 (and not in the storage RAM 701 as in the architecture illustrated in Figure 4) reference data (denoted F ⁇ ).
  • the encoder 700 can log in the external RAM memory 701 data (denoted F ⁇ ) of the encoded image reconstructed from the decision taken, for use during encoding subsequent images in the video stream.
  • the encoder 700 may therefore be provided with a motion estimation unit (ME) 703 and a motion compensation unit (MC) 704, configured to read reference data in a local cache memory 707 rather than in an external memory 701.
  • the motion estimation unit 703 may also be configured to perform processing on data generated by a motion estimation unit 705, for example data 706 relating to candidate motion vectors as explained above. with reference to Figure 2.
  • the type of cache and its efficiency, as well as its complexity of implementation will preferably be chosen according to the coherence of the different zones necessary for motion estimation and motion compensation processes.
  • the data necessary for encoding processing of a block will be preloaded in the cache for the macroblock being processed.
  • an area around the block co-located in the reference image to the block being encoded may be preloaded in the cache.
  • the use of a systematic cache may be preferred to that of a Hit-Miss cache, because that the systematic cache allows to obtain a latency for obtaining the data almost invariable during the encoding processes of several blocks in parallel.
  • a bounded search zone intended to be pre-loaded into a cache, defined along the encoding path of the blocks to be encoded will therefore be considered.
  • FIGS. 8a and 8b illustrate these two factors and show the case of two blocks encoded in parallel at distinct encoding instants ⁇ and T 2 and for which it is necessary to load beforehand their cache processing a search area covering the data needed to process both blocks.
  • FIG. 8a shows the search area 801 of data of a reference image 800 that can be pre-loaded in cache memory with respect to the size thereof for the two blocks 802 and 803 corresponding to two blocks of the current image to be encoded in parallel
  • FIG. 8b shows the area of search 804 data of the reference image 800 to pre-load in cache memory for the two blocks 805 and 806 corresponding to two blocks of the current image to be encoded in parallel after the two blocks 802 and 803 (in the hypothesis a block encoding path from left to right and from top to bottom, as indicated by the black arrow in FIGS. 8a and 8b).
  • the search areas 801 and 804 to be loaded in the cache memory are defined around blocks of the reference image co-located with the blocks to be encoded in parallel.
  • the data of the reference image can be grouped into virtual lines, of height that of a block, as illustrated in FIGS. 8a to 8f which show a reference image 800 comprising 8 virtual lines.
  • the virtual lines may have different heights, and the images to encode a number of virtual lines different from that illustrated in Figures 8a to 8f, which show an example of implementation of the proposed method.
  • Figs. 8c-8f illustrate the caching of data of a reference image 800 for different pairs of parallel encoded blocks.
  • FIG. 8c shows two blocks 807 and 808 co-located in the reference image 800 with blocks to be encoded in parallel located in the upper part of the current image (first and second virtual lines).
  • the size of the search area 809 to be loaded in the cache is such that the encoding of two virtual lines of the current image leads to the caching of 4 virtual lines of the reference image.
  • FIG. 8d illustrates the cache loading of 6 virtual lines for the encoding of two blocks 810 and 81 1 co-located in the reference image 800 with blocks to be encoded in parallel located on the third and fourth virtual lines of FIG. the current image.
  • FIG. 8e illustrates the cache loading of six virtual lines for the encoding of two blocks 812 and 813 co-located in the reference image 800 with blocks to be encoded in parallel located on the fifth and sixth virtual lines of the current image.
  • FIG. 8f illustrates the cache loading of 4 virtual lines for the encoding of two blocks 814 and 815 co-located in the reference image 800 with blocks to encode in parallel located on the seventh and eighth virtual lines of the current image.
  • the amount of data loaded into the cache memory for the encoding of all the blocks of a current image, the encoding being performed in parallel for sets of two blocks will correspond to 20 times the width of an image of reference equal to 8 virtual lines, the height of a virtual line corresponding to that of a block to be encoded, as shown by the following formula:
  • the following table shows the case of the encoding of a 1080p60 image, with a search zone corresponding to a vertical excursion of 96 pixels (ie 6 encoding blocks of size 16 ⁇ 16 pixels), the encoding being performed with a processing in parallel of 4 encoding blocks:
  • MB Macroblock
  • ZR Search box
  • // parallel
  • Y vertical position (expressed in MB count).
  • the reference image is read 3.76 times. If we take has two references, for bidirectional predictions, we arrive at a quantity of data equivalent to 7.5 images, a gain of 3.6 compared to 27 images in the table of Figure 1 1. These 7.5 images represent 0.88 GB / s for a frame rate of 60 frames per second, considering only the luminance, and a rate of 1 .76 GB / s also considering the chrominance.
  • the search area usually used in encoder implementations using a cache memory in which the data of a motion estimation vector search area is pre-loaded is a square-shaped or more generally rectangular zone, for better reflect the aspect ratio of the reference image.
  • a search zone of 64 MB ⁇ 16 MB is obtained for a single reference image, and 32 MB x 16 MB for two reference images in the case of a bidirectional prediction, the size of the search area being defined in macroblocks (MB), for example of size 16x16 pixels for the luminance component Y, the size chrominance components U and V depending on the sampling of these components.
  • MB macroblocks
  • FIG. 9a shows a search zone 900 intended to be loaded in a cache memory, of rectangular shape and defined around four blocks 901 - 904 corresponding in a reference image to blocks co-located with four blocks of a current image in encoding course in parallel.
  • An additional encoding block column 905 may further be pre-loaded so as not to block the downstream processing stream as indicated above.
  • the search area 900 occupies a memory space of 32 x 16 MB
  • the configuration of the encoding blocks being encoded in parallel illustrated in FIG. 9a by the group of four blocks 901 - 904 of the reference image respectively co-located with encoding blocks of the current image can be advantageously replaced by a configuration called "in staircase ", and illustrated in Figure 9b, to account for encoding dependencies for each of the blocks being encoded.
  • the prediction of a block according to the Intra prediction mode or the Inter prediction mode may involve neighboring blocks in the current frame of the encoding block that have already been encoded.
  • the prediction Inter it will be possible, according to the embodiment, to seek to predict the motion estimation vector by using the vectors determined for the neighboring blocks, if necessary, because they are already encoded.
  • the Intra prediction depending on the embodiment, it will be possible to predict the pixels of the block being encoded (current block) as a function of the pixels of one or more neighboring blocks.
  • the definition of these neighboring blocks may therefore depend on the encoding path chosen for the blocks of the image.
  • the step configuration illustrated in FIGS. 9b, 9c and 9d is provided by way of example of configuration of a plurality of blocks intended to be encoded in parallel (or of corresponding blocks respectively co-located in a reference image), and positioned relative to each other so that none of the blocks of the configuration corresponds to a block neighboring another block of the configuration that can be used for encoding this other block, depending on the path of the block. encoding chosen for the blocks of the image being encoded.
  • Other stair configurations can of course be used for the implementation of the proposed method.
  • FIG. 9c illustrates a coding block 906 currently being encoded (current block) with four neighboring blocks 907-910 located in the immediate vicinity of the current block 906.
  • the four neighboring blocks are defined according to the encoding path of the blocks of the image 91 1 being encoded, which in the illustrated example changes from left to right and from top to bottom.
  • block 912, located immediately below and to the left of neighbor block 910 immediately to the left of current block 906, is a block that can be encoded in parallel with current block 906.
  • the search area 900 shown in FIG. 9a (horizontal excursion of 15 MB and vertical excursion of 6 MB) is reduced to a horizontal excursion of 12 MB because of the passage of a vertical configuration of the blocks to be encoded in parallel with a stair-type configuration, a configuration reflected on that of corresponding blocks 901-904 respectively co-located in a reference image.
  • the management of the image edges can be performed by duplication of data or by the use of a dedicated logic.
  • the duplication of data has the advantage of avoiding the cost of implementing a logic dedicated to managing the edges of the image to be encoded.
  • the duplication of the data for the management of the image edges can for example lead to the definition of a search area such as that illustrated in FIG. 9e.
  • FIG. 9e shows a rectangular-shaped search zone 915 intended to be pre-loaded in a cache memory in order to accelerate the processing related to a temporal correlation prediction of four blocks to be encoded in parallel positioned in a step-by-step configuration.
  • This stair configuration is found on the four corresponding blocks 901 - 904 respectively co-located in a reference image illustrated in Figure 9e.
  • a row of blocks 913 and a block column 914 are further copied in cache memory for management of the edges of the reference image.
  • the excursion of the vector components of the coded motion is limited to +/- 160 pixels for the horizontal component, which corresponds to a cache memory occupancy of 2 x 10 MB, and to +/- 96 pixels for the vertical component, which corresponds to a cache memory occupancy of 2 x 6 MB.
  • the search area 915 further includes two preloaded block columns 916a-916b so as not to block the downstream processing stream.
  • search area 915 shown in Figure 9e uses 17 x 30
  • the inventors of the proposed method have noticed that the data of the sets of blocks 917 and 918 respectively situated in the lower right and upper left parts of the search zone 915, were not used by the processing related to the motion estimation or motion compensation.
  • the proposed method overcomes this disadvantage by optimizing the shape of the search area to be loaded into the cache, so as to minimize the amount of data loaded into cache memory and not used by the subsequent processing related to the estimate movement or motion compensation.
  • the proposed method advantageously makes it possible to increase the excursion of the vector components without complexity of implementation or use of significant additional resources.
  • Fig. 10 is a diagram illustrating the proposed method according to one embodiment.
  • a first image of a set of images of a video sequence is envisaged.
  • This first image is divided into blocks on which image encoding processes are applied.
  • Each block is thus encoded, according to one of a plurality of coding modes comprising at least one temporal correlation prediction type coding mode using a plurality of images of the set of images, such as, for example, the predictions of type Inter, Merge, and Skip described above.
  • a search area in a reference image for searching motion estimation vectors of the current block of which at least a portion has substantially the shape of an ovoid portion.
  • the reference image used is chosen distinct from the image being encoded (first image), and has previously been encoded according to an encoding sequence of the images of the set of images.
  • the search area thus defined is unitary in the sense that it is defined for an encoding block being encoded.
  • the search area data is then loaded (1003) into a cache memory, and then a motion estimation vector pointing to a block of the search area correlated to the current block is determined (1004) by searching the search area loaded into cache.
  • a coding decision of the current block according to one of the coding modes is then taken (1005) using the motion estimation vector.
  • the proposed method thus uses a search area that is not defined with a rectangular or square shape.
  • infinite vector standard a vector standard defined by the following relation:
  • ⁇ max (v x , v y ), where v x and v y are two components of the vector v, of infinite norm
  • an ovoid shape makes it possible, among other things, to avoid the caching of data that are not used by the motion vector search algorithm in the search area.
  • a search zone is defined, a portion of which is substantially in the shape of an ellipsoid portion.
  • the search area may have in its entirety an ovoid shape, or, in a particular embodiment, an ellipsoid shape. In the latter case, the outline of the search area defines a polygon of substantially elliptical shape.
  • the shape of the unit search area is predetermined. Indeed, one or more forms of unit search area can be prerecorded. For example, shape definition data (ovoid, ellipsoid, or other) may be loaded from a memory to define the unit search area. Once loaded, this zone shape is predetermined for any image (s) of a sequence to be encoded.
  • shape definition data ovoid, ellipsoid, or other
  • these shape-defining data may define a curve corresponding to a portion or all of the search area.
  • the ellipse can be defined over a quarter of space, as illustrated in FIG. 11b, from shape definition data loaded in memory. .
  • the search area (1 101) can then be defined for a block (1 102) co-located in the selected reference picture with the current block being encoded by applying the form defined to one quadrant on the four quadrants, as shown in Figure 1 1 c.
  • Figures 1 1 d, 1 1 e and 1 1 f show other examples of area of search (1,104) and (1,105) defined from an ovoid portion (1,103) used for the definition of the quarter-space search area.
  • a multiple search area is defined which brings together the respectively definable unit search areas for each block. encoding encoded in parallel.
  • FIG. 11 g shows a multiple search area (1 106) uniting the unit search areas respectively corresponding to four blocks (1 107 - 1 1 10) respectively co-located in a reference image with four encoding blocks in FIG. encoding courses arranged in a stair configuration as described above.
  • the multiple search area is defined from a unitary search area definition having an ellipsoidal shape of the type illustrated in FIG. 1 1 c.
  • the caching of a search area for a new encoding block to be encoded may, in one or more embodiments, be defined by a series of offset values in the horizontal direction (denoted delta x or x loaded (y)) respectively corresponding to each of the possible vertical coordinate values of the blocks of the search area, determined on the basis of the shape of the search area to be loaded in cache memory.
  • the cache loading of the multiple search area for a new set of four encoding blocks to be encoded may, in one or more embodiments, be defined by a series of offset values in the horizontal direction (denoted delta x or x load (y)) respectively corresponding to each of the possible values of vertical coordinate of the blocks of the search area, determined on the basis of the shape of the area to load in cache and according to the encoding path of the blocks of the current image.
  • Figure 1 1h illustrates a set of offset values loaded to x (y) for the multiple search area illustrated in Figure 1 1 g.
  • the loaded x (y) values correspond to the 16 possible vertical coordinate values, respectively.
  • the offset values x A loaded (y) are determined relative to the position of one (1 1 10) of the four blocks (1107 - 1 1 10) co localized with the blocks being encoded in parallel, chosen as the reference block.
  • another of the four blocks (1 107 - 1 1 10) co-located with the blocks being encoded in parallel, or another block of the multiple search area 1 106 could be used as a reference block.
  • the offset values A x char3 (y) can be written in a memory, for example of the ROM type, which does not significantly degrade the access performance of the DDR3 controller, compared to the random accesses of the DDR3.
  • a system without cache because the memory read requests concern whole blocks (for example 512 bytes, aligned with the size of a macro-block in the case of an encoder of H.264 / AVC type).
  • each pair (x, A x char3 y)) corresponds to a macroblock of size 16x16 (512 bytes with a sampling of type 4: 2: 2-8 bits), ie to 32 words DDR3-aligned, access to 16x16 MBs (corresponding to 32 contiguous addresses) is more efficient than access to random addresses.
  • a x char3 (y) for each vertical position y ranging for example from 0 to 15, are grouped in the table below (the values of A x char3 (y) being natural numbers ):
  • the release of the cache area for a block whose encoding is complete can, in one or more embodiments, be defined by a series of offset values in the horizontal direction (denoted deltajib x or A " fc ()) respectively corresponding to each of the possible vertical coordinate values of the blocks of the cached update search area, determined on the basis of the shape of the cache-loaded search area and as a function of the search path. encoding chosen.
  • the release of the cache area for a set of four encoding blocks whose encoding is complete may, in one or more embodiments, be defined by a series of offset values in the horizontal direction (denoted deltajib x or ⁇ yy)) respectively corresponding to each of the possible vertical coordinate values of the blocks of the search area, determined on the basis of the shape of the search area loaded in memory cache and according to the encoding path of the blocks of the current image.
  • FIG. 11 illustrates a set of shift values at ⁇ ⁇ y for the multiple search area shown in FIG.
  • the offset values at ⁇ ⁇ ) correspond to the 16 possible vertical coordinate values, respectively.
  • the offset values ⁇ ⁇ 3 (y) are determined with respect to the position of one (1 107) of the four co-located blocks (1 107 - 1 1 10). with the blocks being encoded in parallel, chosen as the reference block.
  • another of the four blocks (1 107 - 1 1 10) co-located with the blocks being encoded in parallel, or another block of the multiple search area 1 106 could be used as a reference block.
  • one of the four blocks (1 107 - 1 1 10) can be used as a reference block, which leads to the smallest offset values ( ⁇ ), in order to minimize the memory space required for their storage.
  • the release offset values at x b (y) can be stored in a memory, for example ROM type.
  • release offset values A ⁇ (y) for each vertical position y are grouped in the table below (the values of ⁇ lb (y) being relative integers):
  • the invention thus makes it possible to obtain, with respect to a systematic rectangular mask, a gain in coding efficiency, because, for the same internal memory space of the FPGA, a larger excursion of the vectors is allowed.
  • This improvement of the excursion of the motion vector components is due, on the one hand, to the gain of the memory space loaded unnecessarily with a rectangular mask, as illustrated by the memory space portions 917 and 918 in FIG. 9e. and on the other hand, to the ovoid-shaped search zone which allows for larger vectors in the horizontal and vertical directions, and smaller in the diagonal directions, thanks to the use in some embodiments of the quadratic standard ⁇ v ⁇ 2 instead of the infinite norm.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Pour l'encodage d'une image découpée en blocs d'un ensemble d'images, chaque bloc étant encodé selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images, on définit, dans une deuxième image de l'ensemble d'images distincte de la première image et précédemment codée selon une séquence prédéfinie d'encodage des images de l'ensemble d'images, une zone de recherche de vecteurs d'estimation de mouvement, une portion au moins de la zone de recherche ayant sensiblement la forme d'une portion d'ovoïde, on charge les données de la zone de recherche dans une mémoire cache, on détermine, par une recherche dans la zone de recherche chargée en mémoire cache, un vecteur d'estimation de mouvement du bloc courant, et on utilise le vecteur d'estimation de mouvement pour décider de l'encodage du bloc courant selon l'un parmi la pluralité de modes de codage.

Description

PROCEDE D'ENCODAGE D'IMAGE ET EQUIPEMENT POUR LA MISE EN
ŒUVRE DU PROCEDE
La présente invention se rapporte à un procédé d'encodage d'image et un dispositif pour la mise en œuvre de ce procédé. Elle s'applique notamment au codage d'images d'un flux vidéo.
Les données vidéo font en général l'objet d'un codage source visant à les compresser afin de limiter les ressources nécessaires à leur transmission et/ou à leur stockage. Il existe de nombreux standards de codage, tels que H.264/AVC, H.265/HEVC et MPEG-2, qui peuvent être utilisés à cette fin.
On considère un flux vidéo comprenant un ensemble d'images. Dans les schémas de codage classique, les images du flux vidéo à encoder sont typiquement considérées selon une séquence d'encodage, et chacune est divisée en ensembles de pixels eux aussi traités séquentiellement, par exemple en commençant en haut à gauche et en finissant en bas à droite de chaque image.
L'encodage d'une image du flux est ainsi effectué en divisant une matrice de pixels correspondant à l'image en plusieurs ensembles, par exemple des blocs de taille fixe 16 x 16, 32 x 32 ou 64 x 64 pixels, et en encodant ces blocs de pixels selon une séquence de traitement donnée. Certains standards, comme le H.264/AVC, prévoient la possibilité de décomposer des blocs de taille 16 x 16 pixels (appelés alors macro-blocs) en sous-blocs, par exemple de taille 8 x 8 ou 4 x 4, afin d'effectuer les traitements d'encodage avec une granularité plus fine. Le standard H.265/HEVC prévoit l'utilisation de blocs de taille fixe allant jusqu'à 64 x 64 pixels, ces blocs pouvant être partitionnés jusqu'à une taille minimale de 8 x 8 pixels.
Les techniques existantes de compression vidéo peuvent être divisées en deux grandes catégories : d'une part la compression dite « Intra », dans laquelle les traitements de compression sont effectuées sur les pixels d'une unique image ou trame vidéo, et d'autre part la compression dite « Inter », dans laquelle les traitements de compression sont effectuées sur plusieurs images ou trames vidéo. Dans le mode Intra, le traitement d'un bloc (ou ensemble) de pixels comprend typiquement une prédiction des pixels du bloc effectuée à l'aide de pixels causaux (précédemment codés) présents dans l'image en cours d'encodage (dite « image courante »), auquel cas on parle de « prédiction Intra ». Dans le mode Inter, le traitement d'un bloc (ou ensemble) de pixels comprend typiquement une prédiction des pixels du bloc effectuée à l'aide de pixels issus d'une ou de plusieurs images précédemment codées, auquel cas on parle de « prédiction Inter » ou de « compensation de mouvement » (en anglais « motion compensation »).
Ces deux types de codage sont utilisés au sein de schémas de codage dits « hybrides », qui sont spécifiés dans les codées vidéo existants (MPEG2, H.264/AVC, HEVC) et sont décrits pour le codée HEVC (High Efficiency Video Coding) dans l'article intitulé « Overview of the High Efficiency Video Coding (HEVC) Standard », par Gary J. Sullivan et al., IEEE Transactions on Circuits and Systems for Video Technology, vol. 22, No. 12, Dec. 2012.
Cette exploitation des redondances spatiales et/ou temporelles permet d'éviter de transmettre ou de stocker la valeur des pixels de chaque bloc (ou ensemble) de pixels, en représentant certains au moins des blocs par un résiduel de pixels représentant la différence (ou la distance) entre des valeurs de prédiction des pixels du bloc et les valeurs réelles des pixels du bloc prédit.
L'information des résiduels de pixels est présente dans les données générées par l'encodeur après transformée (par exemple, de type transformée en cosinus discrète, ou en anglais DCT, pour Discrète Cosine Transform) et quantification afin de réduire l'entropie des données générées par l'encodeur.
Il est souhaitable de réduire autant que possible les informations additionnelles générées par la prédiction des pixels et présentes en sortie de l'encodeur afin d'augmenter l'efficacité d'un schéma de codage/compression à un niveau de distorsion donné. A l'inverse, on peut aussi chercher à réduire ces informations additionnelles pour augmenter l'efficacité d'un schéma de codage/compression à un niveau de débit de sortie de l'encodeur donné.
Un encodeur vidéo effectue typiquement un choix de mode d'encodage correspondant à une sélection de paramètres d'encodage pour un ensemble de pixels traité. Cette prise de décision peut être implémentée en optimisant une métrique de débit et distorsion, les paramètres d'encodage sélectionnés par l'encodeur étant ceux qui minimisent un critère débit-distorsion. Le choix du mode d'encodage a alors un impact sur les performances de l'encodeur, à la fois en termes de gain de débit et de qualité visuelle.
L'implémentation d'un encodeur vidéo pour lequel des performances de traitement temps réel sont recherchées peut être effectuée sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array), ou bien sous forme d'une architecture matérielle dédiée, comme par exemple un composant ASIC (Application Spécifie Integrated Circuit). Les circuits logiques programmables de type FPGA (Field-Programmable Gâte Array) sont des circuits électroniques reconfigurables par l'utilisateur. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée.
Un encodeur peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).
Un des avantages de la mise en œuvre d'un encodeur vidéo temps réel sur un composant de type FPGA tient dans la possibilité de concevoir l'implémentation des algorithmes de traitement de manière à ce que certains traitements soient effectués en parallèle. Les possibilités d'implémentation avec ce type d'optimisation sont moins présentes pour des implémentations d'encodeur vidéo temps réel sur des processeurs de traitement de signal (en anglais, « Digital Signal Processor », ou DSP), qui sont des composants génériques fonctionnant avec un code logiciel linéaire qui est déroulé séquentiellement lors de l'exécution sur le processeur DSP.
Les encodeurs vidéo implémentés sur un composant dédié sont néanmoins souvent limités, notamment ceux qui effectuent des traitements en parallèle, par la bande passante disponible pour le transfert de données entre le composant et une mémoire externe dans laquelle sont stockées les données du flux vidéo à encoder. Cette limitation est usuellement surmontée grâce à la mise en œuvre d'une mémoire cache implantée sur le composant, qui bénéficie ainsi d'une bande passante beaucoup plus importante que celle d'une mémoire externe.
L'utilisation d'un cache mémoire nécessite cependant d'adapter les algorithmes d'encodage qui font intervenir la mémoire cache, de manière à tirer au mieux parti des bénéfices que procure l'utilisation d'un cache pour réduire les temps de traitement tout en améliorant la qualité de compression du flux vidéo encodé.
Suivant le type de cache utilisé, les limitations imposées à l'encodeur sont diverses. Généralement, elles se traduisent par une limitation des algorithmes d'estimation de mouvement autorisés par l'encodeur.
Il existe ainsi un besoin pour un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression.
Un objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression. Un autre objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression pour une implémentation temps-réel.
Un autre objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré pour une implémentation temps-réel.
Selon un premier aspect, il est proposé un procédé d'encodage d'une première image dans un ensemble d'images, dans lequel la première image est découpée en blocs, chaque bloc étant encodé selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images, le procédé comprenant, pour un bloc courant de la première image : définir, dans une deuxième image de l'ensemble d'images distincte de la première image et précédemment codée selon une séquence prédéfinie d'encodage des images de l'ensemble d'images, une zone de recherche unitaire de vecteurs d'estimation de mouvement ; charger les données de la zone de recherche unitaire dans une mémoire cache ; déterminer, par une recherche dans la zone de recherche unitaire chargée en mémoire cache, un vecteur d'estimation de mouvement du bloc courant, le vecteur d'estimation de mouvement pointant sur un bloc de la zone de recherche corrélé au bloc courant ; et utiliser le vecteur d'estimation de mouvement pour décider de l'encodage du bloc courant selon l'un parmi la pluralité de modes de codage ; dans lequel la zone de recherche unitaire comprend un ensemble de données de la deuxième image comprenant les données d'un bloc de la deuxième image co-localisé avec le bloc courant, et dans lequel une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ovoïde.
Le procédé proposé permet d'optimiser la forme de la zone de recherche destinée à être chargée en mémoire cache, de manière à minimiser la quantité de données chargées en mémoire cache et non utilisées par des traitements ultérieurs, comme par exemple des traitements liés à l'estimation de mouvement ou la compensation de mouvement.
Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire a sensiblement une forme d'ovoïde.
L'optimisation de la zone de recherche liée à la forme d'ovoïde peut en effet être avantageusement appliquée à la totalité de la zone de recherche, et non pas seulement à une portion de celle-ci. Dans un ou plusieurs mode de réalisation du procédé proposé, la zone de recherche unitaire peut aussi être déterminée de manière qu'une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ellipsoïde.
La forme ellipsoïdale permet en effet avantageusement d'augmenter l'excursion des composantes vectorielles sans complexification d'implémentation ni utilisation de ressources supplémentaires significatives.
Ce mode de réalisation du procédé proposé présente comme avantage d'augmenter, pour un même espace mémoire, l'excursion des composantes des vecteurs de mouvement, sans perte due, le cas échéant, à la forme de configuration des blocs du groupe de blocs d'encodage destinés à être encodés en parallèle.
Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire pourra être déterminée ayant une forme sensiblement ellipsoïdale.
Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire pourra être déterminée avec un contour qui définit un polygone de forme sensiblement elliptique.
Le procédé proposé peut en outre avantageusement être appliqué au cas d'un groupe de blocs d'encodage destinés à être encodés en parallèle, comme par exemple un groupe de 2, 3, ou 4 blocs d'encodage.
Dans un mode de réalisation du procédé proposé, on définit ainsi une zone de recherche multiple pour une pluralité de blocs d'encodage par réunion de zones de recherche unitaires correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, on charge les données de la zone de recherche multiple dans la mémoire cache, on détermine, par une recherche dans la zone de recherche multiple chargée en mémoire cache, une pluralité de vecteurs d'estimation correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, et on utilise les vecteurs d'estimation déterminés pour l'encodage des blocs d'encodage de la pluralité de blocs d'encodage.
Le procédé proposé peut en outre être adapté à différentes formes de configuration des blocs du groupe de blocs d'encodage destinés à être encodés en parallèle, comme par exemple la configuration MBAFF des encodeurs de type H.264 (en anglais, « Macroblock-Adaptive Frame/field Coding »).
Selon un deuxième aspect, il est proposé un dispositif d'encodage d'une première image dans un ensemble d'images, comprenant : une interface d'entrée configurée pour recevoir la première image ; une unité d'encodage vidéo, couplée de manière opérationnelle à l'interface d'entrée, et configurée pour encoder la première image en utilisant le procédé proposé.
Selon un autre aspect, il est proposé un programme d'ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre des étapes du procédé proposé lors de l'exécution dudit programme par le processeur, ainsi qu'un ensemble de données représentant, par exemple par voie de compression ou d'encodage, ledit programme d'ordinateur.
Un autre aspect concerne un support de stockage non-transitoire d'un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l'exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d'interface entrées/sorties, conduire l'ordinateur à encoder une première image dans un ensemble d'images selon le procédé proposé.
Le procédé proposé convient particulièrement bien, bien que de façon non exclusive, pour l'encodage ou la compression d'une image d'une séquence d'images selon un schéma du type H.264/AVC (Advanced Video Coding). Mais il convient aussi pour l'encodage d'images selon tout schéma d'encodage vidéo opérant sur des images découpées en blocs dans lequel les blocs sont encodés selon une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images du flux vidéo à encoder, comme par exemple un schéma d'encodage de type H.265/HEVC.
Le procédé proposé pourra avantageusement être mis en œuvre dans les cas où le mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images est de type utilisant une prédiction de mouvement à partir d'images précédemment codées (type de mode de codage référencé dans certains codeurs vidéo sous l'appellation « Inter ») ou de type utilisant un vecteur prédicteur prédéterminé sélectionné à partir de blocs voisins du bloc courant précédemment codés (types de mode de codage référencés dans certains codeurs vidéo sous les appellations « Skip » et « Merge »).
D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
- La figure 1 est un schéma illustrant un encodeur de type H.264/AVC ; - La figure 2 est un schéma illustrant l'architecture d'un codeur pour la mise en œuvre du procédé proposé ;
- Les figures 3a, 3b, et 3c sont des schémas illustrant des modes de prédiction Intra ;
- La figure 4 est un schéma illustrant une détermination de vecteur médian pour le codage en mode de prédiction Inter ;
- La figure 5 est un schéma illustrant une architecture d'encodeur utilisant un composant FPGA et une mémoire externe ;
- La figure 6a est un schéma illustrant une position fractionnaire de pixel déterminée dans le cadre d'une prédiction Inter selon un mode de réalisation ;
- Les figures 6b et 6c sont des schémas illustrant un vecteur de mouvement candidat et un ensemble de vecteurs testés dans le cadre d'une prédiction Inter selon un mode de réalisation ;
- La figure 7 est un schéma illustrant une architecture d'encodeur pour la mise en œuvre du procédé proposé ;
- Les figures 8a, 8b, 8c, 8d, 8e, et 8f sont des schémas illustrant le chargement de données en mémoire cache pour l'encodage d'une paire de blocs d'encodage ;
- La figure 9a est un schéma illustrant le chargement de données en mémoire cache pour l'encodage d'un groupe de quatre blocs d'encodage ;
- Les figures 9b et 9c sont des schémas illustrant la configuration d'un groupe de quatre blocs d'encodage à encoder en parallèle ;
- Les figures 9d et 9e sont des schémas illustrant le chargement de données en mémoire cache pour l'encodage d'un groupe de quatre blocs d'encodage ;
- La figure 10 est un diagramme illustrant le procédé proposé selon un mode de mise en œuvre ;
- Les figures 1 1 a, 1 1 b, 1 1 c, 1 1d, 1 1 e, 1 1 f, 1 1 g, 1 1 h et 1 1 i sont des schémas illustrant différentes configurations de zones de recherche selon différents modes de mise en œuvre.
Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la description.
Dans ce qui suit, on utilise indifféremment les termes « pixel » et
« échantillon » pour désigner un élément d'une image numérique.
Le procédé proposé peut être mis en œuvre par tout type d'encodeur d'image d'un ensemble d'images, comme par exemple un codée vidéo conforme aux standards H.264/AVC, H.265/HEVC, et/ou MPEG-2.
En particulier, les différents modes de réalisation décrits ci-après pour un encodeur de type H.264/AVC utilisant des macro-blocs (MB) de taille 16x16 pixels peuvent être adaptés à un encodeur de type H.265/HEVC en remplaçant les MB16x16 par des blocs de type CTB16, CTB32 et CTB64, de tailles respectives 16x16, 32x32 et 64x64, définis par la norme HEVC.
La figure 1 illustre un exemple d'architecture d'encodeur (10) de type
H.264/AVC.
Un flux F d'images à encoder (Fn) est fourni en entrée de l'encodeur (10). Chaque image Fn (1 1 ) du flux d'entrée est découpée en macro-blocs de taille 16x16 pixels, pour être encodée selon une séquence prédéterminée d'encodage des macro-blocs, par exemple de haut en bas et de gauche à droite.
Les macro-blocs sont prédits à l'aide de pixels causaux (précédemment codés) présents dans l'image courante (prédiction « Intra »), ou bien à l'aide de pixels issus d'une ou plusieurs images précédemment codées (prédiction « Inter »). Cette exploitation des redondances spatiales et temporelles permet de représenter les unités de codage par un résiduel de pixels le plus faible possible qui est alors transmis au décodeur, éventuellement après transformée et quantification.
Chaque macro-bloc à encoder est fourni en entrée d'une unité d'estimation de mouvement (12) (« ME », pour « Motion Estimation »), qui génère des données relatives au mouvement du bloc en cours d'encodage par rapport à une ou plusieurs images précédemment encodées F'n_1 (13), communément appelées images de référence, qui sont aussi fournies en entrée de l'unité d'estimation de mouvement (12). Les données de mouvement produites par l'unité d'estimation de mouvement sont fournies à une unité de compensation de mouvement (14) (ou prédiction de type Inter) (« MC », pour « Motion Compensation »), qui reçoit en outre en entrée la ou les images de référence utilisées par l'unité d'estimation de mouvement (12). L'unité de compensation de mouvement (14) génère des données de prédiction Inter, qui sont fournies à une unité de prise de décision d'encodage (15).
Les données du bloc à encoder sont par ailleurs fournies à une unité de choix de prédiction Intra (16) qui évalue différents blocs voisins du bloc à encoder dans l'image courante dans le cadre de la prédiction Intra. L'unité de choix de prédiction Intra (16) génère en entrée d'une unité de prédiction Intra (17) des données d'un ou de plusieurs blocs voisins du bloc courant (en cours d'encodage) pour la prédiction Intra, et l'unité de prédiction Intra (17) produit en retour des données de prédiction Intra, qui sont fournies à l'unité de prise de décision d'encodage (15), qui sélectionne une prédiction de type Inter ou une prédiction de type Intra en fonction des données de prédiction reçues pour ces deux modes. L'unité de choix de prédiction Intra (16) ainsi que l'unité de prédiction Intra (17) reçoivent en entrée des données d'images encodées uF'n.
Une détermination (18) de résiduel Dn est effectuée à partir des données de l'image courante (pour le bloc courant) Fn et les données de prédiction sélectionnées par l'unité de prise de décision d'encodage (15). Ce résiduel de pixels est ensuite traité par transformation (T) (19) et quantification (Q) (20), et les données quantifiées (X) sont encodées par encodage entropique (21 ) pour générer un flux encodé (NAL).
Une boucle de reconstruction d'images à partir des données d'encodage récupère les données quantifiées (X) pour les traiter par des opérations inverse de quantification (Q"1) (22) et de transformée (T1) (23). Une opération inverse (24) de celle de détermination de résiduel est en outre appliquée pour reconstruire des blocs déjà encodés uF'n, et qui serviront aux unités de prédiction Intra pour fournir des données de blocs voisins du bloc en cours d'encodage. Ces données seront ensuite filtrées (25) pour la reconstruction d'images entières (26) F'n, qui fourniront les images de référence pour les unités de prédiction Inter.
Dans l'architecture d'un encodeur illustrée par la figure 2, les images sont considérées séquentiellement et divisées en ensembles de pixels traités séquentiellement en commençant en haut à gauche et en finissant en bas à droite. Ces ensembles de pixels sont dénommés « unités de codage » dans le standard HEVC, et sont de taille maximale 64 x 64 pixels, les unités de codage de cette taille étant appelés « Large Coding Units », ou « LCU ». Ces ensembles de pixels sont prédits à l'aide de pixels causaux (précédemment codés) présents dans l'image courante (prédiction « Intra »), ou bien à l'aide de pixels issus d'une ou plusieurs images précédemment codées (prédiction « Inter »). Cette exploitation des redondances spatiales et temporelles permet de représenter les unités de codage par un résiduel de pixels le plus faible possible qui est alors transmis au décodeur, éventuellement après transformée et quantification.
En référence à la figure 2, l'encodeur 100 reçoit en entrée 109 un flux vidéo d'entrée 101 comprenant une pluralité d'images à traiter pour effectuer l'encodage du flux. L'encodeur 100 comprend un contrôleur 102, couplé de manière opérationnelle à l'interface d'entrée 109, qui pilote une unité de pré-estimation de mouvement (PRE-ME) 1 12, une unité d'estimation de mouvement (ME) 1 10 et une unité de prédiction par compensation de mouvement (MC) 104 pour les prédictions de types Inter, Merge et/ou Skip (décrites ci-dessous), ainsi qu'une unité de prédiction de mode Intra 103. Les données reçues sur l'interface d'entrée 109 sont transmises en entrée des unités de prédiction de mode Intra 103, de pré-estimation de mouvement 1 12, et du contrôleur 102. L'ensemble contrôleur 102, unité d'estimation de mouvement 1 10, unité de prédiction 104 pour les prédictions Inter, Merge et Skip, et unité de prédiction de mode Intra 103 forme une unité d'encodage 1 1 1 couplée de manière opérationnelle à l'interface d'entrée 109. L'unité d'encodage 1 1 1 est en outre couplée de manière opérationnelle à une unité de mémoire 1 13, par exemple de type RAM, par le biais du contrôleur 102 sur l'exemple illustré par la figure 2.
L'unité de prédiction de mode Intra 103 génère des données de prédiction Intra 107 qui sont fournies en entrée d'un codeur entropique 105. L'unité de préestimation de mouvement 1 12 génère, pour un bloc d'encodage, une liste de vecteurs candidats potentiels pour la décision Inter, fournie à l'unité d'estimation de mouvement 1 10. L'unité d'estimation de mouvement 1 10 et l'unité de prédiction des modes Inter/Merge/Skip 104 réalisent un affinage des vecteurs candidats potentiels puis sélectionnent un meilleur candidat. L'unité de prédiction de modes Inter/Merge/Skip 104 génère des données 106 de prédiction Inter, Merge ou Skip qui sont fournies en entrée du codeur entropique 105. Par exemple, les données fournies au décodeur pour une prédiction de type Inter peuvent comprendre un résiduel de pixels et des informations concernant un ou plusieurs vecteurs de mouvement. Ces informations relatives à un ou plusieurs vecteurs de mouvement peuvent comprendre un ou plusieurs indices identifiant un vecteur prédicteur dans une liste de vecteurs prédicteurs connue du décodeur. Les données fournies au décodeur pour une prédiction de type Skip ne comporteront typiquement pas de résiduel de pixels, et pourront aussi comprendre des informations identifiant un vecteur prédicteur dans une liste de prédicteurs connue du décodeur. La liste de vecteurs prédicteurs utilisée pour le codage de type Inter ne sera pas nécessairement identique à la liste de vecteurs prédicteurs utilisée pour le codage de type Skip. Le contrôleur 102 génère des données de contrôle 108 qui sont aussi fournies en entrée du codeur entropique 105.
Le contrôleur 102 est configuré pour piloter l'unité de prédiction de mode Intra 103 et l'unité de prédiction de modes Inter/Merge/Skip 104 afin de contrôler les données de prédiction qui sont respectivement fournies en entrée du codeur entropique 105 par l'unité de prédiction de mode Intra 103 et l'unité de prédiction de modes Inter/Merge/Skip 104. En fonction du schéma d'encodage mis en œuvre par l'encodeur 100, le contrôleur 102 peut en outre être configuré pour sélectionner parmi les différents types de mode de prédiction (mode Intra, mode Inter, mode Merge ou mode Skip en fonction des modes de codage implémentés dans l'unité d'encodage 1 1 1 ) celui pour lequel des données de prédiction seront transmises au codeur entropique 105. Ainsi, le schéma d'encodage peut comprendre une décision pour chaque bloc d'encodage traité visant à choisir le type de prédiction pour lequel des données seront transmises au codeur entropique 105. Ce choix sera typiquement mis en œuvre par le contrôleur, pour décider de l'application du mode de prédiction Inter, du mode de prédiction Intra, du mode de prédiction Merge ou du mode de prédiction Skip au bloc (ou à l'unité de codage) en cours de traitement. Cela permet de commander l'envoi au codeur entropique de données de prédiction Intra 107 ou bien de données de prédiction Inter, Merge ou Skip 106 en fonction de la décision prise par le contrôleur 102.
L'encodeur 100 peut être un ordinateur, un réseau d'ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l'unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 102, amènent ce contrôleur 102 à effectuer ou contrôler les parties interface d'entrée 109, prédiction en mode Intra 103, prédiction en mode Inter/Merge/Skip 104, pré-estimation de mouvement 1 12, estimation de mouvement 1 10 et/ou traitement de données des exemples de mise en œuvre du procédé proposé décrits dans les présentes. Le contrôleur 102 peut être un composant implémentant un processeur ou une unité de calcul pour l'encodage d'images selon le procédé proposé et le contrôle des unités 109, 1 10, 1 12, 103, 104, 105 de l'encodeur 100.
L'encodeur 100 peut être mis en œuvre sous forme logicielle, comme décrit ci-dessus, auquel cas il prend la forme d'un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). Les SOC (System On Chip) ou systèmes sur puce sont des systèmes embarqués qui intègrent tous les composants d'un système électronique dans une puce unique.
Un encodeur peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).
L'image en cours de traitement est divisée en blocs d'encodage ou unités de codage (en anglais « Coding Unit », ou CU), dont la forme et la taille sont déterminées en fonction notamment de la taille de la matrice de pixels représentant l'image, par exemple en macroblocs de forme carrée de 16 x 16 pixels. On forme ainsi un ensemble de blocs pour lequel on définit une séquence de traitement (aussi appelé « parcours de traitement »). Dans le cas de blocs de forme carrée, on peut par exemple traiter les blocs de l'image courante en commençant par celui situé en haut à gauche de l'image, suivi de celui immédiatement à droite du précédent, jusqu'à arriver à la fin de la première ligne de blocs pour passer au bloc le plus à gauche dans la ligne de blocs immédiatement en-dessous de cette première ligne, pour terminer le traitement par le bloc le plus en bas et à droite de l'image.
On considère ainsi un « bloc courant » (parfois dénommé « bloc d'origine »), c'est-à-dire un bloc d'encodage en cours de traitement dans l'image courante. Le traitement du bloc courant peut comprendre le partitionnement du bloc en sous-blocs, afin de traiter le bloc avec une granularité spatiale plus fine que celle obtenue avec le bloc. Le traitement d'un bloc comprend par ailleurs la prédiction des pixels du bloc, en exploitant la corrélation spatiale (dans la même image) ou temporelle (dans une ou plusieurs autres images précédemment codées) entre les pixels. Lorsque plusieurs types de prédiction, comme par exemple une prédiction de type Intra, une prédiction de type Inter, une prédiction de type Merge et/ou une prédiction de type skip sont implémentés dans l'encodeur, la prédiction des pixels du bloc comprend typiquement la sélection d'un type de prédiction du bloc et d'informations de prédiction correspondants au type sélectionné, l'ensemble formant un jeu de paramètres d'encodage.
La prédiction du bloc de pixels traité permet de calculer un résiduel de pixels, qui correspond à l'écart entre les pixels du bloc courant et les pixels du bloc de prédiction, et est transmis dans certains cas au décodeur après transformée et quantification.
Pour coder un bloc courant, plusieurs modes de codage sont ainsi possibles et il est nécessaire d'inclure dans les données générées par l'encodage des informations de codage 106-108 signalant le choix de mode de codage qui a été effectué lors de l'encodage et selon lequel les données ont été encodées. Ces informations de codage 106-108 peuvent comprendre notamment le mode de codage (par exemple le type particulier de codage prédictif parmi les codages « Intra » et « Inter », ou parmi les codages « Intra », « Inter », « Merge » et « Skip » décrits ci-après), le partitionnement (dans le cas d'un ou plusieurs blocs partitionnés en sous-blocs), ainsi qu'une information de mouvement 106 dans le cas d'un codage prédictif de type « Inter », « Merge » ou « Skip » et un mode de prédiction Intra 107 dans le cas d'un codage prédictif de type « Intra ». Pour les modes de codage « Inter », « Skip » et « Merge », ces deux dernières informations peuvent elles aussi être prédites afin de réduire leur coût de codage, par exemple en exploitant les informations des blocs voisins du bloc courant.
Le standard HEVC utilise une structure de codage en quadtree, décrite ci- après, combinée à une sélection dynamique de taille principale de bloc. HEVC autorise un partitionnement de chaque image courante en blocs de taille allant de 64 x 64 pixels à 8 x 8 pixels. Le flux vidéo à encoder peut ainsi être parcouru avec des blocs de 64 x 64, chaque bloc de taille 64 x 64 pouvant être découpé en blocs de taille plus petite (le découpage le plus fin autorisé étant celui en 8 x 8 blocs, chacun de taille 8 x 8 pixels). L'encodeur choisit typiquement la taille des blocs utilisés selon des critères propriétaires qui ne sont pas définis par le standard.
L'encodeur vidéo peut par ailleurs utiliser une représentation de type YCbCr de l'espace colorimétrique des signaux vidéo avec un échantillonnage qui peut être de type 4:2:2 ou 4:2:0 (sous-échantillonnage des couleurs). Le signal vidéo à encoder porte une information de luminance (signal Y) et deux informations de chrominance (signaux Cb et Cr). Les échantillons de chaque composante (Y, Cb, Cr) peuvent être codés sur 8 bits, 10 bits ou plus.
En échantillonnage de type 4:2:2, une zone de taille H x L pixels (ou échantillons) de luminance est de taille H/2 x L pour chaque composante de chrominance, ce qui revient à effectuer un sous-échantillonnage des couleurs dans la direction horizontale seulement. La représentation de type 4:2:2 correspond au format de signal dit SDI (en anglais, System Deployment Image).
En échantillonnage de type 4:2:0, une zone de taille H x L pixels (ou échantillons) de luminance est de taille H/2 x L/2 pour chaque composante de chrominance, ce qui revient à effectuer un sous-échantillonnage des couleurs dans la direction horizontale et dans la direction verticale.
On décrit ci-après des exemples de modes de prédiction « Intra », « Inter », « Merge », et « skip », afin de faciliter la compréhension de la mise en œuvre du procédé proposé pour un codage vidéo utilisant ces modes de prédiction.
Comme indiqué ci-dessus, le codage prédictif en mode « Intra » inclut une prédiction des pixels d'un bloc (ou ensemble) de pixels en cours de traitement à l'aide des pixels précédemment codés de l'image courante. Il existe différents modes de codage prédictif de type « Intra », dont certains sont décrits ci-après :
Dans le mode de prédiction « Intra » dit « DC » (pour « Discrète Continuous »), on utilise les valeurs des pixels voisins du bloc courant appartenant à des blocs qui ont été précédemment codés, et on calcule une moyenne des valeurs de ces pixels voisins. Le bloc prédictif est construit en utilisant pour chaque pixel la valeur moyenne obtenue.
Par exemple, si l'on considère un bloc 200 de 8x8 pixels tel que celui illustré sur la figure 3a, on utilise les deux ensembles de 8 pixels voisins 201 , 202 du bloc voisin disposé à gauche du bloc courant et du bloc voisin disposé au- dessus du bloc courant. On calcule une valeur moyenne M des valeurs de ces 16 pixels, que l'on utilise pour remplir les valeurs des pixels du bloc prédictif 200.
Dans le mode de prédiction « Intra » dit « V » (pour « Vertical »), on utilise les valeurs des pixels voisins du bloc courant appartenant à au bloc voisin disposé au-dessus du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la colonne correspondante dans le bloc prédictif.
Par exemple, si l'on considère un bloc 210 de 8x8 pixels tel que celui illustré sur la figure 3b, on utilise par exemple l'ensemble de 8 pixels voisins 21 1 du bloc voisin disposé à gauche du bloc courant, dans le cas où le parcours de codage des blocs est tel que ce bloc a déjà été codé. On recopie la valeur de chacun des 8 pixels voisins dans la colonne correspondante du bloc prédictif 210.
Dans le mode de prédiction « Intra » dit « H » (pour « Horizontal »), on utilise les valeurs des pixels voisins du bloc courant appartenant à au bloc voisin disposé à gauche ou à droite du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la ligne correspondante dans le bloc prédictif.
Dans le mode de prédiction « Intra » dit « VL » (pour « Vertical-Left »), on utilise les valeurs des pixels voisins du bloc courant appartenant au bloc voisin disposé immédiatement au-dessus et au-dessus à droite du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la colonne correspondante dans le bloc prédictif.
Par exemple, si l'on considère un bloc 220 de 8x8 pixels tel que celui illustré sur la figure 3c, on utilise par exemple l'ensemble de 8 pixels voisins 221 des deux blocs voisins disposés respectivement immédiatement au-dessus et au- dessus sur la droite du bloc courant, dans le cas où le parcours de codage des blocs est tel que ces blocs voisins, ou au moins les pixels voisins considérés, ont déjà été codés. On recopie la valeur de chacun des 8 pixels voisins dans la colonne correspondante du bloc prédictif 220 selon une direction de projection diagonale gauche comme illustré sur la figure 3c.
Le standard de codage vidéo H.264/AVC prévoit 9 modes de prédiction Intra (dont les modes de prédiction DC, H, V, VL décrits ci-dessus). Le standard de codage vidéo HEVC prévoit quant à lui un nombre plus important de 35 modes de prédiction Intra pour les échantillons de luminance, et 5 modes pour les échantillons de chrominance.
Ces standards de codage vidéo prévoient par ailleurs des cas particuliers pour effectuer une prédiction intra. Par exemple, le standard H.264/AVC autorise le découpage de blocs de 16x16 pixels en blocs plus petits, dont la taille peut aller jusqu'à 4x4 pixels, afin d'augmenter la granularité du traitement de codage prédictif.
Comme indiqué ci-dessus, l'information du mode de prédiction Intra est prédite afin de réduire son coût de codage. En effet, la transmission dans le flux encodé d'un index identifiant le mode de prédiction Intra présente un coût d'autant plus élevé que le nombre des modes de prédiction utilisables est important. Même dans le cas du codage H.264/AVC, la transmission d'un index entre 1 et 9 identifiant le mode de prédiction Intra utilisé pour chaque bloc parmi les 9 modes possibles s'avère être chère en termes de coût de codage. Le standard HEVC prévoit la détermination d'au plus trois modes Intra prédits. Si l'encodeur prend une décision d'encodage utilisant l'un de ces modes, seul une information relative à son index (parfois noté « mpm_index ») et à un indicateur indiquant que l'un des modes prédits a été choisi est transmise par l'encodeur. Autrement, l'encodeur transmet une information relative à un écart avec les modes prédits (parfois noté « rem_intra_pred_mode »).
On calcule ainsi un mode le plus probable, noté MPM (en anglais « Most Probable Mode »), qui est utilisé pour coder sur un minimum de bits le mode de prédiction Intra le plus probable. Le MPM est le résultat de la prédiction du mode de prédiction Intra utilisé pour coder le bloc courant.
Lorsque le mode Intra est sélectionné pour l'encodage du bloc courant, on pourra transmettre au décodeur typiquement un ensemble de coefficients correspondant au résiduel de pixels transformé et quantifié et le MPM.
Le codage prédictif de type à prédiction par corrélation temporelle référencé pour certains codeurs vidéo sous l'appellation « Inter » inclut une prédiction des pixels d'un bloc (ou ensemble) de pixels en cours de traitement à l'aide de pixels issus d'une ou de plusieurs images précédemment codées (pixels qui ne sont donc pas issus de l'image courante, au contraire du mode de prédiction Intra).
Le mode de prédiction Inter utilise typiquement un ou deux ensembles de pixels respectivement situés dans une ou deux images précédemment codées afin de prédire les pixels du bloc courant. Cela dit, on peut envisager pour un mode de prédiction Inter l'utilisation de plus de deux ensembles de pixels situés respectivement dans des images précédemment codées distinctes deux-à-deux et dont le nombre est supérieur à deux. Cette technique, appelée compensation de mouvement, fait intervenir la détermination d'un ou de deux vecteurs, dits vecteurs de mouvement, qui indiquent respectivement la position de l'ensemble ou des ensembles de pixels à utiliser pour la prédiction dans l'image ou les images précédemment codées (usuellement dénommées « images de référence »). En référence à la figure 2, les vecteurs utilisés pour le mode « Inter » sont à choisir par l'encodeur 100 par le biais de l'unité de pré-estimation de mouvement 1 12, de l'unité d'estimation de mouvement 1 10 et de l'unité de prédiction des modes Inter/Merge/Skip 104. La mise en œuvre de l'estimation de mouvement au sein de l'encodeur 100 pourra donc prévoir, selon les cas, la détermination d'un seul vecteur d'estimation de mouvement, de deux vecteurs d'estimation de mouvement, voire plus, qui pointent vers des images différentes. Le ou les vecteurs d'estimation de mouvement générés en sortie de l'unité d'estimation de mouvement 1 10 seront fournis à l'unité de prédiction des modes Inter/Merge/Skip 104 pour la génération de vecteurs de prédiction Inter. Chaque vecteur de prédiction Inter pourra en effet être généré à partir d'un vecteur d'estimation de mouvement correspondant.
On décrit ci-après plus en détails l'estimation de mouvement pour un bloc courant selon des modes de réalisation.
L'estimation de mouvement peut consister à étudier le déplacement des blocs entre deux images en exploitant la corrélation temporelle entre les pixels, Pour un bloc donné dans l'image courante (le « bloc courant » ou « bloc d'origine »), l'estimation de mouvement permet de sélectionner un bloc le plus ressemblant (dénommé « bloc de référence ») dans une image précédemment codée, dite « image de référence », en représentant le mouvement de ce bloc par exemple avec un vecteur à deux dimensions (et donc deux composantes représentant par exemple respectivement un déplacement horizontal et un déplacement vertical).
Le procédé d'estimation de mouvement est non normatif et est donc susceptible de différer d'un encodeur à un autre.
Par exemple, le procédé d'estimation de mouvement pourra comprendre la recherche dans une zone plus ou moins étendue de l'image de référence, par exemple définie à partir du bloc de l'image de référence correspondant au bloc d'origine dans l'image d'origine, afin de tester la ressemblance du bloc d'origine avec un nombre plus ou moins grand de blocs candidats de l'image de référence.
La corrélation entre un bloc et son déplacement selon un vecteur d'estimation de mouvement peut être calculée à l'aide de la Somme des Différences Absolues (SAD) :
SAD =∑x∑y \pxy - V'xy \ (1 )
où p xy est le pixel à la position (x, y)du bloc d'origine et p xy le pixel à la position (x, y) du bloc de référence. Une SAD faible sera interprétée comme une indication que les deux blocs sont très ressemblants.
Le vecteur issu de l'estimation de mouvement, correspondant au bloc de l'image de référence le plus proche du bloc d'origine parmi les blocs candidats testés dans l'image de référence, pourra servir de base à la détermination d'un vecteur de prédiction Inter. En effet, selon les implémentations, le procédé de prédiction Inter pourra inclure des optimisations visant à sélectionner un vecteur distinct du vecteur issu de l'estimation de mouvement, afin d'avoir une prédiction la moins coûteuse possible pour le mode qui est testé.
Cette optimisation peut par exemple comprendre le test d'un ou de plusieurs vecteurs autour du vecteur issu de l'estimation de mouvement susceptibles de donner un meilleur résultat en fonction de l'objectif poursuivi. Dès lors, le vecteur utilisé pour la prédiction Inter eu égard à une image de référence donnée ne sera pas nécessairement identique au vecteur issu de l'estimation de mouvement pour cette image de référence.
Lorsque le mode Inter est sélectionné pour l'encodage du bloc courant, on pourra transmettre au décodeur typiquement le résiduel de pixels (calculé pour chaque vecteur de prédiction Inter en fonction des pixels du bloc courant et des pixels du bloc vers lequel pointe le vecteur de prédiction Inter considéré) et des informations concernant le ou les vecteurs de prédiction Inter correspondant.
Cependant, le ou les vecteurs de prédiction Inter peuvent représenter un coût important dans les encodeurs vidéo. Certains encodeurs réduisent ce coût de codage en exploitant les vecteurs des blocs voisins du bloc en cours d'encodage. Cette optimisation fait intervenir une prédiction du/des vecteurs de prédiction Inter, à l'instar de la prédiction du mode de prédiction Intra dans le cas d'un codage prédictif du bloc en mode Intra.
Comme indiqué ci-dessus, les informations concernant chaque vecteur de prédiction Inter pourront ainsi être réduites en taille en transmettant, à la place des coordonnées du vecteur par exemple, un indice d'un vecteur prédicteur dans un dictionnaire connu de l'encodeur et du décodeur, et un résiduel quantifiant la distance entre le vecteur de prédiction et le vecteur prédicteur.
Par exemple, dans les codeurs de type H.264/AVC, un vecteur prédicteur médian mvpred est utilisé pour prédire le vecteur à coder mv.
επιν = mv ~ mvpred (2)
Seul le résiduel emv est transmis dans le flux encodé, de manière à fortement réduire les coûts de codage.
Le principe utilisé dans le standard HEVC est similaire en ce qu'il prévoit la transmission d'un résiduel de vecteur emv, qui n'est cependant pas calculé en utilisant un vecteur prédit médian. La norme précise en fait une méthode de calcul d'un ensemble de vecteurs prédits. L'encodeur choisit ensuite un prédicteur parmi ces vecteurs prédits possibles. Il peut donc transmettre, avec le résiduel vecteur, un numéro d'indice du vecteur prédicteur retenu, afin que le décodeur puisse utiliser le même.
La technique de prédiction bidirectionnelle fait typiquement intervenir une moyenne pondérée de deux prédictions de type Inter. L'encodeur choisit un ensemble de paramètres de prédiction pour une « direction » (pour une première image de référence), puis pour une deuxième « direction » (pour une deuxième image de référence, distincte de la première image de référence). L'encodeur détermine ensuite s'il retient une seule des deux directions ou les deux, auquel cas une moyenne des deux prédictions générées est déterminée avant de calculer un résiduel de pixels correspondant, qui sera éventuellement traité par transformation et quantification.
La prédiction bidirectionnelle correspond donc dans son principe à une prédiction de type « Inter » avec deux vecteurs prédits. Il en résulte que les aspects du procédé proposé concernant la prédiction Inter sont applicables à la prédiction bidirectionnelle.
La figure 4 illustre la détermination d'un vecteur prédicteur correspondant dans l'exemple illustré au médian entre les vecteurs de blocs voisins précédemment codés. En référence à la figure 4, le bloc courant (en cours d'encodage) 241 est entouré de quatre blocs voisins 243a, 243b, 243c, 243d précédemment encodés et de trois blocs voisins 243a, 243b, 243c restant à coder.
L'exemple présenté suppose un parcours d'encodage des blocs de l'image tel que, pour chaque bloc en cours d'encodage, les blocs situés à gauche ou au- dessus du bloc courant ont déjà été encodé, de sorte que, sur la figure 4, les blocs voisins 243a, 243b, 243c, 243d précédemment encodés sont situés à gauche 243a ou au-dessus 243b, 243c, 243d du bloc courant 241 . Le vecteur prédicteur mvpred 244 du bloc courant 241 correspond au médian entre les vecteurs respectifs 245a, 245b, 245c, 245d des blocs précédemment codés 243a, 243b, 243c ou 243a, 243b, 243d lorsque le bloc 243c n'est par exemple pas disponible (par exemple dans le cas où le bloc 243c est encodé selon un codage prédictif en mode Intra). Un mauvais vecteur prédicteur résultera en un surcoût de codage pour le bloc courant 241 . Dans un autre cas particulier où uniquement un ou deux blocs voisins sont codés en mode Inter, les standards H.264/AVC et HEVC prévoient des règles permettant d'utiliser un des vecteurs disponibles dans la mesure où le médian n'est pas calculable.
Certains codeurs utilisent, parfois dans le cadre du mode de prédiction « Inter », un mode référencé dans certains codeurs video sous l'appellation « Skip » dans lequel, comme dans le cas du mode Inter, le bloc courant est prédit à l'aide de pixels issus d'images précédemment codées (une ou deux images, voire plus en fonction de l'implémentation). Le mode Skip est d'ailleurs parfois présenté comme un sous-mode du mode Inter, du fait qu'il correspond à un mode de prédiction « Inter » sans transmission (ou génération dans le flux encodé) de vecteur de prédiction ni de résiduel de pixels.
Le mode Skip trouve à s'appliquer lorsque le résiduel de pixels est suffisamment faible pour qu'il soit considéré inutile de le transmettre dans le flux de sortie du codeur.
D'autre part, dans une optique de réduction maximale du coût de codage, le ou les vecteurs de prédiction utilisés pour ce mode ne seront typiquement pas transmis au décodeur, et seront déduits par le décodeur à partir d'une liste prédéterminée de vecteurs possibles (appelés, de même que pour le mode « Inter », « vecteurs prédicteurs »), ce qui permettra par exemple de transmettre seulement la position du vecteur prédicteur (par exemple un indice de position dans la liste des vecteurs prédicteurs) au lieu de transmettre sa valeur (comme par exemple ses coordonnées). Ainsi, par exemple, dans ce mode de codage, on sélectionne directement un vecteur prédicteur dans une liste prédéterminée connue du décodeur, la sélection du vecteur prédicteur s'effectuant à partir de blocs voisins du bloc courant qui ont été précédemment codés. Comme indiqué ci- dessus, dans les cas où les modes Skip et Inter mis en œuvre dans le codeur utilisent l'un et l'autre une liste de vecteurs prédicteurs, les listes respectives de vecteurs prédicteurs, que ce soit de par leurs tailles ou de par leurs contenus respectifs, ne seront pas nécessairement identiques.
Le standard HEVC prévoit un autre mode de codage prédictif, dit « Merge », similaire au mode Skip décrit ci-dessus à la différence près que l'on pourra transmettre un résiduel de pixels. Le mode Merge peut ainsi lui aussi correspondre à un mode de prédiction Inter, sans transmission (ou génération dans le flux encodé) de vecteur de prédiction, mais dans lequel un résiduel de pixel et généré et transmis dans le flux encodé.
Dans l'architecture matérielle d'un encodeur à base de FPGA, les images de référence sont généralement stockées dans une mémoire importante en profondeur, afin de stocker un ensemble de plusieurs images. Par exemple, le stockage de 10 images au format HD 1920x1080 pixels avec un échantillonnage de type 4:2:2 sous 8 bits requiert un espace de stockage de taille 40 Mo. Les mémoires utilisées pour ce stockage présentent en général des performances moyennes en termes de bande passante. Celle-ci est typiquement de l'ordre de 2 Go/s dans le cas d'un boîtier de mémoire vive SDRAM de type DDR3-1333. Par exemple, avec une efficacité de lecture à 70% pour des quantités importantes de données en rafale, on obtient une bande passante de 1333333333 Hz x 16 bits x 0,7, soit 1 ,7 Go/s.
La figure 5 illustre une architecture matérielle de ce type, dans laquelle un encodeur 400 implémenté sur un composant 402 de type FPGA stocke dans une mémoire RAM 401 des images de référence. Par exemple, pour l'encodage de l'image Fn d'un flux vidéo d'entrée F, l'encodeur pourra effectuer une phase d'estimation de mouvement dans le cadre d'une prédiction de type Inter, Skip ou Merge, qui nécessitera la lecture dans la mémoire RAM de stockage 401 de données de référence (notées F^). Une fois les traitements relatifs à la prédiction Inter effectués, l'encodeur pourra consigner dans la mémoire RAM 401 des données (notées F^) de l'image encodée reconstruite à partir de la décision prise, pour utilisation lors de l'encodage des images suivantes dans le flux vidéo. L'encodeur 400 pourra donc être muni d'une unité d'estimation de mouvements (ME) 403 et d'une unité de compensation de mouvement (MC) 404, l'unité d'estimation de mouvements 403 pouvant par ailleurs être configurée pour effectuer des traitements sur des données générées par une unité de pré-estimation de mouvements 405, par exemple des données 406 relatives à des vecteurs de mouvement candidats comme expliqué ci-dessus en référence à la figure 2.
La quantité de données de référence (F^) nécessaires aux fonctions de l'unité d'estimation de mouvements (ME) 403 et de l'unité de compensation de mouvement (MC) 404 de l'encodeur 400 peut s'avérer suffisamment importante pour qu'il soit envisagé d'utiliser un système de cache, notamment pour atteindre les performances requises dans le cadre d'une implémentation matérielle de traitement temps-réel.
En fonction de l'implémentation, cette quantité de données peut être significativement plus importante que la quantité de données correspondant à une image simple, du fait notamment du nombre de vecteurs candidats testés, de l'augmentation de la zone de pixels nécessaire à l'affinage des candidats (partie ME des traitements), et de l'augmentation de la zone de pixels nécessaire au calcul de la prédiction Inter (partie MC des traitements).
On considère ci-après ces trois causes de la forte augmentation des données de référence :
La zone nécessaire au calcul de la prédiction inter d'un bloc d'encodage (par exemple un macro-bloc) est égale à la taille de ce bloc augmentée de deux couronnes, dont l'une est nécessaire à l'interpolation au quart de pixel, et l'autre est nécessaire à l'excursion de l'estimation de mouvement. En effet, en fonction de l'implémentation de l'encodage vidéo, les vecteurs de mouvement peuvent être déterminés avec une précision fractionnaire du pixel, en ce qu'un vecteur de mouvement peut pointer vers un élément de pixel fractionnaire généré entre deux pixels voisins. Dans ce cas, des échantillons fractionnaires seront générés entre deux échantillons voisins, par exemple par interpolation entre ces deux échantillons. C'est le cas du standard HEVC, qui prévoit la génération d'échantillons de luminance fractionnaires en définissant un filtre interpolateur à 8 coefficients pour les positions des demi-échantillons (ou demi-pixels) et un filtre interpolateur à 7 coefficients pour les positions des quarts d'échantillon (ou quarts de pixel). Le standard HEVC permet ainsi la génération de vecteurs de mouvement avec une précision égale au quart de la distance entre deux échantillons de luminance.
L'utilisation de vecteurs de mouvement pointant sur une image de référence avec une précision sous-pixellique conduit donc à interpoler les pixels de l'image de référence originale, ce qui augmente la quantité de données correspondant à cette image. Par exemple, pour calculer une prédiction inter d'un macro-bloc de taille 16 pixel x 16 pixel, qui correspond à un vecteur de mouvement avec une précision au quart de pixel, il peut s'avérer nécessaire de disposer d'une zone de l'image de référence de taille 19 x 19 pixels : une couronne de 3 pixels est utilisée dans le calcul d'une image au demi-pixel, le calcul de l'image au quart de pixel étant réalisé en interpolant l'image au demi-pixel. Cet accroissement de la quantité de données représentant une image de référence peut ainsi résulter de l'utilisation de filtres interpolateurs pour calculer les demi-pixels (HPELs) et, éventuellement les quarts de pixels (QPELs), en fonction de la profondeur de la granularité souhaitée.
On pourra par exemple, en fonction de l'implémentation, utiliser un filtrage à 5 coefficients pour calculer un demi-pixel. Il faudra donc connaître les valeurs de 5 pixels pour mettre en œuvre le filtrage interpolateur à 5 coefficients. La figure 6a illustre ce calcul, et montre 5 pixels 601 a - 601 e d'une image de référence 600. Les pixels 601 d et 601 e appartiennent à un bloc d'encodage 602 en cours d'encodage par prédiction Inter. En utilisant un filtre d'interpolation à 5 coefficients, le calcul du demi pixel 603 entre les pixels 601 d et 601 e pourra utiliser en fonction de l'implémentation les valeurs des 5 pixels 601 a - 601 e.
Par ailleurs, comme expliqué ci-dessus, la fonction d'estimation de mouvement peut comprendre, en fonction de l'implémentation, le test d'un ensemble de vecteurs proches d'un vecteur initial, appelé vecteur candidat, et le choix parmi les vecteurs testés d'un vecteur minimisant une fonction de corrélation (souvent de type SAD ou SSD) entre le bloc de prédiction et le bloc à encoder. Dans une implémentation utilisant une unité de pré-estimation de mouvement, cette opération réalise un affinage de vecteurs candidats identifiés par la fonction de pré- estimation de mouvement.
Cet ensemble de vecteurs de test augmente la zone de référence nécessaire à la décision d'encodage pour le mode Inter. La figure 6c illustre cette augmentation en montrant un ensemble couvrant une zone de 5 x 5 pixels qui demande au final (lorsque l'on prend en compte une couronne nécessaire à l'interpolation au quart de pixel) une zone de 21 x 21 pixels.
La figure 6b montre une image de référence 605 sur laquelle est représentée le bloc 606 co-localisé dans l'image de référence 605 avec le bloc d'encodage en cours d'encodage dans l'image courante. Un vecteur candidat 608 pointe vers un pixel (demi-pixel ou quart de pixel selon la granularité choisie) de l'image de référence 605, et un ensemble 607 de vecteurs testés pointent respectivement vers des pixels (demi-pixels ou quart de pixels selon la granularité choisie) de l'image de référence 605.
La figure 6c montre l'extrémité du vecteur candidat 606, et le pixel 608 vers lequel ce vecteur 606 pointe, ainsi que deux vecteurs tests 607a et 607b et les pixels 609a et 609b vers lesquels ces vecteurs 607a et 607b pointent respectivement. En fonction de l'implémentation de la fonction d'affinage de l'estimation de mouvement, l'ensemble des pixels vers lesquels les vecteurs de test pointent respectivement (dénommés « pixels vecteurs testés » sur la figure 6c) devra être inclus dans les données de l'image de référence récupérées de la mémoire RAM pour les besoins des traitements de la prédiction Inter.
Certains standard d'encodage, comme les standards H.264/AVC et H.265/HEVC, autorisent le partitionnement d'un bloc à encoder pour découper la prédiction Inter en plusieurs zones ayant chacune un vecteur spécifique. Ceci permet une meilleure correspondance du macro-block à encoder avec l'image de référence, notamment sur des frontières d'objet ayant des mouvements différents.
Ce partitionnement augmente cependant d'autant le nombre de vecteurs candidat que l'on peut souhaiter tester dans l'encodeur pour un bloc d'encodage, et par là même la quantité de donnée nécessaire à la décision de la prédiction Inter d'un bloc d'encodage.
Cette quantité de donnée est d'autant plus importante qu'il y a de partitions.
Par exemple, le partitionnement d'un bloc de 16 pixels x 16 pixels en quatre partitions 8 pixels x 8 pixels nécessite quatre zones de 13 pixels x 13 pixels, soit une surface totale de 52 pixels x 52 pixels.
La norme H.264 permet plusieurs partitionnements d'un macro-bloc de 16 pixels x 16 pixels, jusqu'à un partitionnement en blocs de 4 pixels x 4 pixels.
On peut également prendre en compte la possibilité, prévue dans certains standards (comme les standards H.264/AVC et H.265/HEVC), de réaliser des prédictions inter bidirectionnelles qui sont une pondération de deux prédictions Inter calculées sur deux images de référence différentes, comme décrit ci-dessus.
Enfin, on peut aussi tenir compte de l'augmentation de la quantité de données nécessaires à la décision de la prédiction Inter due à l'alignement en mémoire externe qui n'est (en fonction de l'implémentation) pas toujours accessible au pixel près. Typiquement il augmente la couronne de 3 pixels (on arrive ainsi à une couronne de 8 pixels : 3 + 2 + 3).
Le tableau suivant détaille la quantité de données à lire pour réaliser la décision inter dans le cas de 4 partitionnements (16x16, 8x16, 16x8, 8x8) pour deux références (L0 et L1 ), uniquement pour la composante luminance (Y). On arrive ainsi à un ratio de x 24 en lecture par macro-bloc pour le cas H.264/AVC, comme le montre le tableau suivant (les dimensions des partitions et zones sont exprimées en nombre de pixels):
Avec ce ratio on obtient, pour un encodage 1080p60, une quantité de données qui dépasse les capacités d'un boîtier mémoire de type DDR3-1333 (1 ,7 Go/s à 70% d'efficacité). Quand on considère également la lecture de la chrominance et la nécessité d'écriture des images de référence, amplifiées par le fait que les accès « aléatoires » envisagés plus haut, dus au partitionnement des zones à charger et à leur alignement au pixel, dégrade les performances en lecture (fermeture et ouverture de page), on voit qu'il est nécessaire d'avoir un système qui minimise ces accès à la RAM externe sans dégrader la qualité de la décision.
L'utilisation d'une mémoire cache, c'est-à-dire d'un espace mémoire, souvent interne au composant, par exemple ASIC ou FPGA, sur lequel est implémenté l'encodeur vidéo, ayant une bande passante en lecture beaucoup plus efficace que celle d'une mémoire externe, permet de pallier à ce problème de limitation de bande passante d'une mémoire externe.
Par exemple, on peut implémenter une mémoire cache au sein d'un composant FPGA de type Stratix-lll d'Altera (EP3SL340) en utilisant 32 mémoires internes de type M144K pouvant chacune contenir 2048 mots de 72 bits. En utilisant pour la sortie de ce cache un bus de 16 x 8 pixels à 133 MHz, on obtient une bande passante de l'ordre de 16 Go/s, c'est-à-dire une amélioration d'un facteur égal à 9 par rapport à une mémoire externe telle que celle décrite ci-dessus.
La figure 7 montre une mise en œuvre de l'encodeur implémenté sur un composant FPGA illustré par la figure 4 en utilisant une mémoire cache au sein de l'unité de décision de prédiction Inter. Un encodeur 700 est implémenté sur un composant 702 de type FPGA, et stocke dans une mémoire RAM 701 externe au composant FPGA 702 des images de référence F'. Pour l'encodage d'une image Fn d'un flux vidéo d'entrée F, l'encodeur 700 pourra effectuer une phase d'estimation de mouvement dans le cadre d'une prédiction de type Inter, Skip ou Merge, et lire pour ce faire dans une mémoire cache 707 implémentée sur le composant FPGA 702 (et non pas dans la mémoire RAM de stockage 701 comme dans l'architecture illustrée sur la figure 4) des données de référence (notées F^). Une fois les traitements relatifs à la prédiction Inter effectués, l'encodeur 700 pourra consigner dans la mémoire RAM externe 701 des données (notées F^) de l'image encodée reconstruite à partir de la décision prise, pour utilisation lors de l'encodage des images suivantes dans le flux vidéo. L'encodeur 700 pourra donc être muni d'une unité d'estimation de mouvements (ME) 703 et d'une unité de compensation de mouvement (MC) 704, configurées pour lire des données de référence dans une mémoire cache locale 707 plutôt que dans une mémoire externe 701 . L'unité d'estimation de mouvements 703 pourra par ailleurs être configurée pour effectuer des traitements sur des données générées par une unité de pré-estimation de mouvements 705, par exemple des données 706 relatives à des vecteurs de mouvement candidats comme expliqué ci-dessus en référence à la figure 2.
Dans un ou plusieurs modes de réalisation, le type de cache et son efficacité, ainsi que sa complexité de mise en œuvre, seront de préférence choisis en fonction de la cohérence des différentes zones nécessaires aux traitements d'estimation de mouvement et de compensation de mouvement.
Différents types de cache peuvent en effet être envisagés. Dans les caches de type « Hit-Miss », les données recherchées seront obtenues rapidement si elles se trouvent déjà dans le cache (cas de « hit »), ou bien devront être recherchées dans la mémoire externe puis stockées dans le cache (cas d'un « miss »). Le temps de latence pour l'obtention des données sera donc variable selon que les données recherchées se trouvent déjà dans le cache ou non.
Dans les caches dits « systématiques », les données nécessaires au traitement d'encodage d'un bloc seront préchargées dans le cache pour le macrobloc en cours de traitement. En particulier, une zone autour du bloc co- localisé dans l'image de référence au bloc en cours d'encodage pourra être préchargée dans le cache.
Dans l'exemple d'un encodeur vidéo implémenté sur un composant FPGA de manière à effectuer en parallèle l'encodage de plusieurs blocs, l'utilisation d'un cache systématique pourra être préférée à celle d'un cache Hit-Miss, du fait que le cache systématique permet d'obtenir un temps de latence pour l'obtention des données quasiment invariable pendant les traitements d'encodage de plusieurs blocs en parallèle.
Dans un ou plusieurs modes de réalisation, on considérera donc une zone de recherche bornée, destinée à être pré-chargée dans un cache, définie suivant le parcours d'encodage des blocs à encoder.
Deux facteurs pourront être pris en compte pour définir la quantité de données à pré-charger en mémoire cache : d'une part, la hauteur de la zone de recherche, qui sera liée à la composante verticale maximale autorisée pour les vecteurs de ME et de MC, et d'autre part, le nombre de blocs à traiter simultanément, c'est-à-dire en parallèle.
Les figures 8a et 8b illustrent ces deux facteurs et montrent le cas de deux blocs encodés en parallèle à des instants ΤΊ et T2 d'encodage distincts et pour lesquels il est nécessaire de charger préalablement à leur traitement en mémoire cache une zone de recherche couvrant les données nécessaires au traitement des deux blocs.
La figure 8a montre la zone de recherche 801 de données d'une image de référence 800 qu'il est possible de pré-charger en mémoire cache au regard de la taille de celle-ci pour les deux blocs 802 et 803 correspondant à deux blocs de l'image courante à encoder en parallèle, et la figure 8b montre la zone de recherche 804 de données de l'image de référence 800 à pré-charger en mémoire cache pour les deux blocs 805 et 806 correspondant à deux blocs de l'image courante à encoder en parallèle après les deux blocs 802 et 803 (dans l'hypothèse d'un parcours d'encodage de blocs allant de gauche à droite et de haut en bas, comme indiqué par la flèche noire sur les figures 8a et 8b). Les zones de recherche 801 et 804 à charger en mémoire cache sont définies autour de blocs de l'image de référence co-localisés avec les blocs à encoder en parallèle.
Lorsque la taille des blocs d'encodage est fixe, comme c'est le cas des macro-blocs du standard d'encodage vidéo H.264, les données de l'image de référence pourront être regroupées en lignes virtuelles, de hauteur celle d'un bloc, comme illustré sur les figures 8a à 8f qui montrent une image de référence 800 comprenant 8 lignes virtuelles. Bien entendu, en fonction du mode de réalisation et notamment de la taille des images à encoder ainsi que des différentes tailles possibles des blocs à encoder, les lignes virtuelles pourront avoir des hauteurs différentes, et les images à encoder un nombre de lignes virtuelles différent de celui illustré par les figures 8a à 8f, qui montrent un exemple de mise en œuvre du procédé proposé.
Les figures 8c - 8f illustrent le chargement en mémoire cache de données d'une image de référence 800 pour différentes paires de blocs encodés en parallèle.
La figure 8c montre deux blocs 807 et 808 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés dans la partie supérieure de l'image courante (première et deuxième lignes vituelles). La taille de la zone de recherche 809 à charger en mémoire cache est telle que l'encodage de deux lignes virtuelles de l'image courante conduit au chargement en mémoire cache de 4 lignes virtuelles de l'image de référence.
La figure 8d illustre le chargement en mémoire cache de 6 lignes virtuelles pour l'encodage de deux blocs 810 et 81 1 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les troisième et quatrième lignes virtuelles de l'image courante.
La figure 8e illustre le chargement en mémoire cache de 6 lignes virtuelles pour l'encodage de deux blocs 812 et 813 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les cinquième et sixième lignes virtuelles de l'image courante.
La figure 8f illustre le chargement en mémoire cache de 4 lignes virtuelles pour l'encodage de deux blocs 814 et 815 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les septième et huitième lignes virtuelles de l'image courante.
Ainsi, la quantité de données chargées en mémoire cache pour l'encodage de l'ensemble des blocs d'une image courante, l'encodage étant effectué en parallèle pour des ensembles de deux blocs, correspondra à 20 fois la largeur d'une image de référence de hauteur égale à 8 lignes virtuelles, la hauteur d'une ligne virtuelle correspondant à celle d'un bloc à encoder, comme le montre la formule suivante :
Largeur_Image_Référence x (4 + 6 + 6 + 4) = 20 x Largeur_Image_Référence La taille de l'image de référence considérée dans les exemples illustrés sur les figures 8a à 8f étant de Largeur_Image_Référence x 8, l'encodage des blocs d'une image courante conduit à lire 2,5 fois les données de l'image de référence.
Le tableau suivant présente le cas de l'encodage d'une image 1080p60, avec une zone de recherche correspondant à une excursion verticale de 96 pixels (soit 6 blocs d'encodage de taille 16x16 pixels), l'encodage étant effectué avec un traitement en parallèle de 4 blocs d'encodage :
Le tableau utilise les acronymes et notations suivants : MB : Macrobloc, ZR : Zone de recherche, // : parallèle, et Y : position verticale (exprimée en nombre de MB).
On constate que l'image de référence est lue 3,76 fois. Si on prend en compte deux références, pour les prédictions bidirectionnelles, on arrive à une quantité de données équivalente à 7,5 images, soit un gain de 3,6 par rapport aux 27 images du tableau de la Figure 1 1 . Ces 7,5 images représentent 0.88 Go/s pour un frame rate de 60 images par seconde, en ne considérant que la luminance, et un débit de 1 .76 Go/s en considérant aussi la chrominance.
Il y a donc un gain certain en bande passante par rapport à un accès direct et « aléatoire » à une mémoire externe, avec comme contrainte une limitation des composantes vectorielles du mouvement codé.
Le procédé proposé décrit ci-après permet de réduire l'impact de cette limitation sans complication d'implémentation ni ressource supplémentaire.
La zone de recherche habituellement utilisée dans les implémentations d'encodeur utilisant une mémoire cache dans laquelle sont pré-chargées les données d'une zone de recherche de vecteurs d'estimation de mouvement est une zone de forme carrée ou plus généralement rectangulaire, pour mieux refléter l'aspect ratio de l'image de référence.
Par exemple, avec 32 mémoires de type M144K (ce qui correspond à 66% des mémoires M144K d'un composant Stratix-3 EP3SL340 d'Altera), utilisées en 16k x 8 bits, c'est-à-dire pour stocker 214 mots (214 = 16384), chacun de taille 8 bits, on dispose de 512k x 8 bits = 512k pixels (avec un échantillonnage de la luminance et de la chrominance de type 4:2:2), soit 219 pixels, ce qui correspond à 1024 blocs d'encodage de taille 16x16 pixels (512k pixels / (16 x 16 x 2) = 1024 blocs 16 x 16 Y-UV, pour un bloc d'encodage comprenant les composantes Y et UV, soit 16x16 Y + 8x16 U + 8x16 V en échantillonnage 4:2:2). Pour une implémentation effectuant en parallèle l'encodage de 4 blocs d'encodage et une excursion verticale des vecteurs de 6 blocs d'encodage, on obtient une zone de recherche de 64 MB x 16 MB pour une unique image de référence, et de 32 MB x 16 MB pour deux images de référence dans le cas d'une prédiction bidirectionnelle, la taille de la zone de recherche étant définie en macro-blocs (MB), par exemple de taille 16x16 pixels pour la composante Y de luminance, la taille des composantes chrominance U et V dépendant de l'échantillonnage de ces composantes.
En référence à la figure 9a, en considérant qu'il faut une colonne de blocs d'encodage pré-chargés pour ne pas bloquer le flot de traitement aval, on obtient pour l'exemple décrit ci-dessus une excursion des composantes vectorielles (sans tenir compte des réductions dues aux couronnes décrites plus haut) de 15 MB x 6 MB, soit +/- 240 pixels x +/- 96 pixels. En effet, pour traiter en parallèle les blocs 901 , 902, 903 et 904, il est souhaitable de disposer de la zone de recherche non grisée sur la figure 9a. Si l'algorithme d'encodage attend la fin du traitement de ces quatre blocs pour libérer la colonne à l'extrémité gauche de la zone de recherche, et charger la colonne 905 pour passer au traitement des quatre blocs de droite adjacents aux quatre blocs en cours d'encodage, le chargement de la colonne 905 générera un temps mort dans les traitements. Dans un ou plusieurs modes de réalisation, on pourra pré-charger la colonne 905 afin d'éviter cette rupture de traitement.
La figure 9a montre une zone de recherche 900 destinée à être chargée dans une mémoire cache, de forme rectangulaire et définie autour de quatre blocs 901 - 904 correspondant dans une image de référence aux blocs co-localisés avec quatre blocs d'une image courante en cours d'encodage en parallèle. L'excursion horizontale des composantes des vecteurs de mouvement correspond, avec les paramètres décrits ci-dessus et correspondant à un mode de réalisation particulier, à un espace mémoire cache de 15 MB, ou à 15 blocs de largeur, tandis que l'excursion verticale des composantes des vecteurs de mouvement correspond, avec les paramètres décrits ci-dessus, à un espace mémoire cache de 6 MB, ou à 6 blocs de hauteur ( soit 6 x 16 = 96 pixels). Une colonne de blocs d'encodage supplémentaire 905 peut en outre être pré-chargée afin de ne pas bloquer le flot de traitement aval comme indiqué ci-dessus.
La zone de recherche 900 occupe un espace mémoire de 32 x 16 MB, soit
512 MB, qui correspond à l'espace mémoire disponible pour une implémentation de la mémoire cache utilisant 32 mémoires de type M144K du composant Stratix-3 EP3SL340 d'Altera (comme indiqué ci-dessus) et mettant en œuvre le chargement en mémoire cache de deux zones de recherche correspondant respectivement à deux images de référence pour une prédiction à corrélation temporelle de type bidirectionnelle (par exemple une prédiction Inter bidirectionnelle).
L'adressage de cette mémoire est peu complexe puisqu'il suffit d'ajouter un offset sur la position x du bloc souhaité, offset en fonction du « ruban » en cours de traitement (le « ruban » correspondant à l'ensemble des lignes auxquelles appartiennent les blocs en cours de traitement), de prendre les 5 bits LSB de ce résultat et de les combiner au 4 bits LSB de la position y du bloc demandé, pour obtenir une adresse sur 9 bits (512 MB).
La configuration des blocs d'encodage en cours d'encodage en parallèle illustrée sur la figure 9a par le groupe de quatre blocs 901 - 904 de l'image de référence respectivement co-localisés avec des blocs d'encodage de l'image courante, peut être avantageusement remplacée par une configuration dite « en escalier », et illustrée sur la figure 9b, afin de tenir compte de dépendances d'encodage pour chacun des blocs en cours d'encodage.
En effet, comme indiqué ci-dessus, la prédiction d'un bloc selon le mode de prédiction Intra ou le mode de prédiction Inter peut faire intervenir des blocs voisins dans l'image courante du bloc d'encodage qui ont déjà été encodés. Pour la prédiction Inter, on pourra, en fonction du mode de réalisation, chercher à prédire le vecteur d'estimation de mouvement en utilisant les vecteurs déterminés pour les blocs voisins, le cas échéant, du fait qu'ils sont déjà encodés. Pour la prédiction Intra, on pourra, en fonction du mode de réalisation, prédire les pixels du bloc en cours d'encodage (bloc courant) en fonction des pixels d'un ou de plusieurs blocs voisins. La définition de ces blocs voisins pourra donc dépendre du parcours d'encodage choisi pour les blocs de l'image.
La configuration en escalier illustrée sur les figures 9b, 9c et 9d est fournie à titre d'exemple de configuration d'une pluralité de blocs destinés à être encodés en parallèle (ou de blocs correspondants respectivement co-localisés dans une image de référence), et positionnés les uns par rapport aux autres de manière à ce qu'aucun des blocs de la configuration ne corresponde à un bloc voisin d'un autre bloc de la configuration utilisable pour l'encodage de cet autre bloc, en fonction du parcours d'encodage choisi pour les blocs de l'image en cours d'encodage. D'autres configurations en escalier peuvent bien entendu être utilisées pour la mise en œuvre du procédé proposé.
La figure 9c illustre un bloc d'encodage 906 en cours d'encodage (bloc courant) avec quatre blocs voisins 907 - 910 situés au voisinage immédiat du bloc courant 906. Les quatre blocs voisins sont définis en fonction du parcours d'encodage des blocs de l'image 91 1 en cours d'encodage, qui dans l'exemple illustré évolue de gauche à droite et de haut en bas. Dans cet exemple de configuration, le bloc 912, situé immédiatement en-dessous et à gauche du bloc voisin 910 situé immédiatement à gauche du bloc courant 906, est un bloc qui peut être encodé en parallèle avec le bloc courant 906.
L'utilisation d'une configuration d'un groupe de blocs à encoder en parallèle de type en escalier telle que celle illustrée sur le figures 9b et 9c entraîne une réduction de l'excursion des composantes vectorielles dans la zone de recherche correspondante à pré-charger en mémoire cache.
Par exemple, comme illustré sur la figure 9d, la zone de recherche 900 illustrée sur la figure 9a (excursion horizontale de 15 MB et excursion verticale de 6 MB) se trouve réduite à une excursion horizontale de 12 MB du fait du passage d'une configuration verticale des blocs à encoder en parallèle à une configuration de type en escalier, configuration reflétée sur celle de blocs correspondants 901 - 904 respectivement co-localisés dans une image de référence.
De plus, en fonction du mode de réalisation, la gestion des bords d'image peut être effectuée par duplication des données ou bien par l'utilisation d'une logique dédiée. La duplication des données présente l'avantage d'éviter le coût d'implémentation d'une logique dédiée à la gestion des bords de l'image à encoder.
La duplication des données pour la gestion des bords d'image peut conduire par exemple à la définition d'une zone de recherche telle que celle illustrée sur la figure 9e.
La figure 9e montre une zone de recherche 915 de forme rectangulaire destinée à être pré-chargée dans une mémoire cache afin d'accélérer les traitements liés à une prédiction par corrélation temporelle de quatre blocs à encoder en parallèle positionnés selon une configuration en escalier. Cette configuration en escalier se retrouve sur les quatre blocs correspondants 901 - 904 respectivement co-localisés dans une image de référence illustrés sur la figure 9e. Une ligne de blocs 913 et une colonne de blocs 914 sont en outre recopiés en mémoire cache pour la gestion des bords de l'image de référence. L'excursion des composantes vectorielles du mouvement codé est limitée à +/- 160 pixels pour la composante horizontale, ce qui correspond à une occupation mémoire cache de 2 x 10 MB, et à +/- 96 pixels pour la composante verticale, ce qui correspond à une occupation mémoire cache de 2 x 6 MB.
La zone de recherche 915 inclut en outre deux colonnes de blocs préchargées 916a - 916b afin de ne pas bloquer le flot de traitement aval.
Au total, la zone de recherche 915 illustrée sur la figure 9e utilise 17 x 30
MB, c'est-à-dire 510 MB, sur les 512 MB disponibles dans une implémentation de la mémoire cache utilisant 32 mémoires de type M144K du composant Stratix-3 EP3SL340 d'Altera (comme indiqué ci-dessus) et mettant en œuvre le chargement en mémoire cache de deux zones de recherche correspondant respectivement à deux images de référence pour une prédiction à corrélation temporelle de type bidirectionnelle (par exemple une prédiction Inter bidirectionnelle).
Les inventeurs du procédé proposé ont remarqué que les données des ensembles de blocs 917 et 918 respectivement situés dans les parties inférieure droite et supérieure gauche de la zone de recherche 915, n'étaient pas utilisées par les traitements liés à l'estimation de mouvement ou la compensation de mouvement. Le procédé proposé permet de remédier à cet inconvénient en optimisant la forme de la zone de recherche destinée à être chargée en mémoire cache, de manière à minimiser la quantité de données chargées en mémoire cache et non utilisées par les traitements ultérieurs liés à l'estimation de mouvement ou la compensation de mouvement.
De plus, le procédé proposé permet avantageusement d'augmenter l'excursion des composantes vectorielles sans complexification d'implémentation ni utilisation de ressources supplémentaires significatives.
La figure 10 est un diagramme illustrant le procédé proposé selon un mode de réalisation.
On envisage une première image d'un ensemble d'images d'une séquence vidéo.
Cette première image est découpée en blocs sur lesquels les traitements d'encodage de l'image sont appliqués. Chaque bloc est ainsi encodé, selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images, comme par exemple les prédictions de type Inter, Merge, et Skip décrits ci-dessus.
Pour un bloc courant (en cours d'encodage) de la première image (1001 ), on définit (1002) une zone de recherche dans une image de référence pour la recherche de vecteurs d'estimation de mouvement du bloc courant, dont au moins une portion a sensiblement la forme d'une portion d'ovoïde. L'image de référence utilisée est choisie distincte de l'image en cours d'encodage (première image), et a été précédemment encodée selon une séquence d'encodage des images de l'ensemble d'images.
La zone de recherche ainsi définie est unitaire en ce sens qu'elle est définie pour un bloc d'encodage en cours d'encodage.
Les données de la zone de recherche sont ensuite chargées (1003) dans une mémoire cache, puis un vecteur d'estimation de mouvement pointant sur un bloc de la zone de recherche corrélé au bloc courant est déterminé (1004) en effectuant une recherche dans la zone de recherche chargée en mémoire cache.
Une décision d'encodage du bloc courant selon l'un des modes de codage est ensuite prise (1005) en utilisant le vecteur d'estimation de mouvement.
Le procédé proposé utilise ainsi une zone de recherche qui n'est pas définie avec une forme rectangulaire ou carrée.
La zone de recherche carrée, et son équivalent rectangulaire pour suivre l'aspect ratio de l'image, correspond à l'utilisation de la norme vectorielle infinie pour la délimitation d'une zone de recherche. Par norme vectorielle infinie, on entend une norme vectorielle définie par la relation suivante : ||∞ = max(vx, vy), où vx et vysont deux composantes du vecteur v, de norme infinie ||∞.
L'utilisation d'une forme ovoïde permet entre autres d'éviter le chargement en mémoire cache de données qui ne sont pas utilisées par l'algorithme de recherche de vecteurs de mouvement dans la zone de recherche.
Dans un ou plusieurs modes de réalisation, on définit une zone de recherche dont une portion a sensiblement la forme d'une portion d'ellipsoïde.
En effet, si l'on utilise, pour la délimitation d'une zone de recherche, une norme vectorielle quadratique définie par la relation suivante : \\v\\2 = vx 2 + vy 2, où vx et vysont deux composantes du vecteur v, de norme quadratique \\v\\2, on obtient une zone de recherche ayant une forme circulaire. L'équivalent de cette forme circulaire pour suivre l'aspect ratio de l'image est une forme ellipsoïdale, comme illustré sur la figure 1 1 a.
Dans un ou plusieurs modes de réalisation, la zone de recherche peut avoir dans sa totalité une forme d'ovoïde, ou bien, dans un mode particulier de réalisation, une forme d'ellipsoïde. Dans ce dernier cas, le contour de la zone de recherche définit un polygone de forme sensiblement elliptique.
Par ailleurs, dans un ou plusieurs modes de réalisation, la forme de la zone de recherche unitaire est prédéterminée. En effet, une ou plusieurs formes de zone de recherche unitaire peuvent être préenregistrées. Par exemple, des données de définition de forme (ovoïde, ellipsoïde, ou autre) peuvent être chargées d'une mémoire pour définir la zone de recherche unitaire. Une fois chargée, cette forme de zone est prédéterminée pour toute(s) image(s) d'une séquence à coder.
Dans un mode de réalisation, ces données de définition de forme peuvent définir une courbe correspondant à une portion ou à la totalité de la zone de recherche.
Par exemple, dans le cas d'une zone de recherche de forme sensiblement ellipsoïdale, l'ellipse peut être définie sur un quart d'espace, comme illustré sur la figure 1 1 b, à partir de données de définition de forme chargées en mémoire.
Dans un mode de réalisation, la zone de recherche (1 101 ) peut ensuite être définie pour un bloc (1 102) co-localisé dans l'image de référence choisie avec le bloc courant en cours d'encodage en appliquant la forme définie pour un quadrant sur les quatre quadrants, comme illustré sur la figure 1 1 c.
Les figures 1 1 d, 1 1 e et 1 1 f montrent d'autres exemples de zone de recherche (1 104) et (1 105) définie à partir d'une portion d'ovoïde (1 103) utilisée pour la définition de la zone de recherche sur un quart d'espace.
Dans un ou plusieurs modes de réalisation dans lesquels l'implémentation de l'encodeur prévoit l'encodage en parallèle d'une pluralité de blocs d'encodage, on définit une zone de recherche multiple réunissant les zones de recherche unitaires respectivement définissables pour chaque bloc d'encodage encodé en parallèle.
La figure 1 1 g montre une zone de recherche multiple (1 106) réunissant les zones de recherche unitaires correspondant respectivement à quatre blocs (1 107 - 1 1 10) respectivement co-localisés dans une image de référence avec quatre blocs d'encodage en cours d'encodage disposés dans une configuration en escalier telle que décrite ci-dessus. Dans cet exemple, la zone de recherche multiple est définie à partir d'une définition de zone de recherche unitaire ayant une forme ellipsoïdale de type celle illustrée par la fig. 1 1 c.
En fonction du parcours d'encodage choisi, le chargement en mémoire cache d'une zone de recherche pour un nouveau bloc d'encodage à encoder peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (noté delta x ou àx charg(y)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche à charger en mémoire cache.
De même, dans le cas d'une zone de recherche multiple, le chargement en mémoire cache de la zone de recherche multiple pour un nouvel ensemble de quatre blocs d'encodage à encoder peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (noté delta x ou àx charg(y)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche à charger en mémoire cache et en fonction du parcours d'encodage des blocs de l'image courante.
La figure 1 1 h illustre un jeu de valeurs de décalage àx charg(y) pour la zone de recherche multiple illustrée sur la figure 1 1 g. Dans cet exemple, les valeurs xcharg(y) correspondent respectivement aux 16 valeurs de coordonnée dans le sens vertical possibles. Dans l'exemple illustré sur la figure 1 1 h, les valeurs de décalage Ax charg(y) sont déterminées par rapport à la position d'un (1 1 10) des quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, choisi comme bloc de référence. Bien entendu, dans un ou plusieurs modes de réalisation, un autre parmi les quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, ou bien un autre bloc de la zone de recherche multiple 1 106 pourrait être utilisé comme bloc de référence. On peut par exemple utiliser comme bloc de référence celui des quatre blocs (1 107 - 1 1 10) qui conduit à des valeurs de décalage Ax char3(y) les plus faibles, afin de minimiser l'espace mémoire requis pour leur stockage.
Dans un mode de réalisation, les valeurs de décalage Ax char3(y) peuvent être consignées dans une mémoire, par exemple de type ROM, ce qui ne dégrade pas significativement les performances d'accès du contrôleur DDR3, par rapport aux accès aléatoires d'un système sans cache, car les requêtes de lecture en mémoire concernent des blocs entiers (par exemple 512 octets, alignés à la taille d'un macro-block dans le cas d'un encodeur de type H.264/AVC). En effet, dans un mode de réalisation dans lequel chaque couple (x, Ax char3 y)) correspond à un macrobloc de taille 16x16 (512 octets avec un échantillonnage de type 4:2:2-8 bits), soit à 32 mots alignés en DDR3, l'accès à des MB 16x16 entiers (correspondant à 32 adresses contiguës) est plus efficace que des accès à des adresses aléatoires.
En référence à l'exemple de réalisation illustré par la figure 1 1 h, les valeurs de Ax char3(y) pour chaque position verticale y, allant par exemple de 0 à 15, sont regroupées dans le tableau ci-dessous (les valeurs de Ax char3(y) étant des entiers naturels) :
y araiy)
0 0
1 +3
2 +7
3 +10
4 +12
5 +13
6 +14
7 +14
8 +14
9 +14
10 +14
1 1 +13 12 +12
13 +1 1
14 +9
15 +6
De même, la libération de la zone de mémoire cache pour un bloc dont l'encodage est terminé peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (notées deltajib x ou A"fc ( )) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche mise à jour en mémoire cache, déterminées sur la base de la forme de la zone de recherche chargée en mémoire cache et en fonction du parcours d'encodage choisi.
Dans le cas d'une zone de recherche multiple, la libération de la zone de mémoire cache pour un ensemble de quatre blocs d'encodage dont l'encodage est terminé peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (notées deltajib x ou à^ Çy)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche chargée en mémoire cache et en fonction du parcours d'encodage des blocs de l'image courante.
La figure 1 1 i illustre un jeu de valeurs de décalage à^ Çy) pour la zone de recherche multiple illustrée sur la figure 1 1 g. Dans cet exemple, les valeurs de décalage à^ Çy) correspondent respectivement aux 16 valeurs de coordonnée dans le sens vertical possibles. Dans l'exemple illustré sur la figure 1 1 i, les valeurs de décalage Δ^3 (y) sont déterminées par rapport à la position d'un (1 107) des quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, choisi comme bloc de référence. Bien entendu, dans un ou plusieurs modes de réalisation, un autre parmi les quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, ou bien un autre bloc de la zone de recherche multiple 1 106 pourrait être utilisé comme bloc de référence. On peut par exemple utiliser comme bloc de référence celui des quatre blocs (1 107 - 1 1 10) qui conduit à des valeurs de décalage à^ Çy) les plus faibles, afin de minimiser l'espace mémoire requis pour leur stockage.
De même que pour les valeurs de décalage de chargement, dans un mode de réalisation, les valeurs de décalage de libération àxb (y) peuvent être consignées dans une mémoire, par exemple de type ROM.
En référence à l'exemple de réalisation illustré par la figure 1 1 i, les valeurs de décalage de libération A^ (y) pour chaque position verticale y, allant par exemple de 0 à 15, sont regroupées dans le tableau ci-dessous (les valeurs de à^l b (y) étant des entiers relatifs) :
L'invention permet ainsi d'obtenir, par rapport à un cache systématique rectangulaire, un gain en efficacité de codage, du fait que, pour un même espace mémoire interne au FPGA, on autorise une excursion des vecteurs plus importante. Cette amélioration de l'excursion des composantes des vecteurs de mouvement est due, d'une part, au gain de l'espace mémoire chargé inutilement avec un cache rectangulaire, comme illustré par les portions d'espace mémoire 917 et 918 sur la Figure 9e, et d'autre part, à la zone de recherche de forme ovoïdale qui permet des vecteurs plus grands dans les directions horizontales et verticales, et moins grands dans les directions diagonales, grâce à l'utilisation dans certains modes de réalisation de la norme quadratique \\v\\2 à la place de la norme infinie.
En fonction du mode de réalisation choisi, certains actes, actions, événements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou événements sont effectués ou se produisent concurremment et non pas successivement.
Bien que décrits à travers un certain nombre d'exemples de réalisation détaillés, le procédé d'encodage proposé et l'équipement pour la mise en œuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l'homme de l'art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l'invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l'ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l'invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n'incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.

Claims

REVENDICATIONS
1 . Procédé d'encodage d'une première image dans un ensemble d'images, dans lequel la première image est découpée en blocs, chaque bloc étant encodé selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images, le procédé comprenant, pour un bloc courant de la première image : définir, dans une deuxième image de l'ensemble d'images distincte de la première image et précédemment codée selon une séquence prédéfinie d'encodage des images de l'ensemble d'images, une zone de recherche unitaire de vecteurs d'estimation de mouvement ; charger les données de la zone de recherche unitaire dans une mémoire cache ; déterminer, par une recherche dans la zone de recherche unitaire chargée en mémoire cache, un vecteur d'estimation de mouvement du bloc courant, le vecteur d'estimation de mouvement pointant sur un bloc de la zone de recherche corrélé au bloc courant ; et utiliser le vecteur d'estimation de mouvement pour décider de l'encodage du bloc courant selon l'un parmi la pluralité de modes de codage ; dans lequel la zone de recherche unitaire comprend un ensemble de données de la deuxième image comprenant les données d'un bloc de la deuxième image co-localisé avec le bloc courant, et dans lequel une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ovoïde.
2. Procédé d'encodage selon la revendication 1 , dans lequel la zone de recherche unitaire a sensiblement une forme d'ovoïde.
3. Procédé d'encodage selon l'une quelconque des revendications précédentes, dans lequel une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ellipsoïde.
4. Procédé d'encodage selon la revendication 3, dans lequel la zone de recherche unitaire a sensiblement une forme ellipsoïdale.
5. Procédé d'encodage selon la revendication 1 , dans lequel le contour de la zone de recherche unitaire définit un polygone de forme sensiblement elliptique.
6. Procédé d'encodage selon la revendication 1 , comprenant en outre : définir une zone de recherche multiple pour une pluralité de blocs d'encodage par réunion de zones de recherche unitaires correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, et charger les données de la zone de recherche multiple dans la mémoire cache, déterminer, par une recherche dans la zone de recherche multiple chargée en mémoire cache, une pluralité de vecteurs d'estimation correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, et utiliser les vecteurs d'estimation déterminés pour l'encodage des blocs d'encodage de la pluralité de blocs d'encodage.
7. Dispositif d'encodage d'une première image dans un ensemble d'images, comprenant : une interface d'entrée configurée pour recevoir la première image ; une unité d'encodage vidéo, couplée de manière opérationnelle à l'interface d'entrée, et configurée pour encoder la première image en utilisant le procédé de l'une quelconque des revendications 1 à 6.
8. Programme d'ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre des étapes d'un procédé selon l'une quelconque des revendications 1 à 6 lors de l'exécution dudit programme par le processeur.
9. Ensemble de données représentant, par exemple par voie de compression ou d'encodage, un programme d'ordinateur selon la revendication 8.
10. Support de stockage non-transitoire d'un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l'exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d'interface entrées/sorties, conduire l'ordinateur à encoder une première image dans un ensemble d'images selon le procédé de l'une quelconque des revendications 1 à 6.
EP16766945.6A 2015-09-17 2016-09-15 Procede d'encodage d'image et equipement pour la mise en oeuvre du procede Ceased EP3350996A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1558768A FR3041495B1 (fr) 2015-09-17 2015-09-17 Procede d'encodage d'image et equipement pour la mise en oeuvre du procede
PCT/EP2016/071875 WO2017046273A1 (fr) 2015-09-17 2016-09-15 Procede d'encodage d'image et equipement pour la mise en oeuvre du procede

Publications (1)

Publication Number Publication Date
EP3350996A1 true EP3350996A1 (fr) 2018-07-25

Family

ID=54366432

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16766945.6A Ceased EP3350996A1 (fr) 2015-09-17 2016-09-15 Procede d'encodage d'image et equipement pour la mise en oeuvre du procede

Country Status (5)

Country Link
US (1) US10999586B2 (fr)
EP (1) EP3350996A1 (fr)
FR (1) FR3041495B1 (fr)
IL (1) IL257846A (fr)
WO (1) WO2017046273A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3612023A4 (fr) 2017-04-20 2021-05-12 Egenesis, Inc. Procédés de production d'animaux génétiquement modifiés
WO2019190339A1 (fr) * 2018-03-26 2019-10-03 Huawei Technologies Co., Ltd. Appareil d'inter-prédiction et procédé de codage vidéo
CN114222136B (zh) * 2019-06-25 2024-10-01 Oppo广东移动通信有限公司 运动补偿的处理方法、编码器、解码器以及存储介质
CN111163319B (zh) * 2020-01-10 2023-09-15 上海大学 一种视频编码方法
US11875427B2 (en) 2021-09-13 2024-01-16 Apple Inc. Guaranteed real-time cache carveout for displayed image processing systems and methods

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI450591B (zh) * 2009-04-16 2014-08-21 Univ Nat Taiwan 視訊處理晶片組及其中移動評估的資料讀取之方法
EP2425622B1 (fr) 2009-04-30 2016-10-05 Telefonaktiebolaget LM Ericsson (publ) Mémoire cache interne efficace pour estimation de mouvement matérielle
US20110228851A1 (en) 2010-03-18 2011-09-22 Amir Nusboim Adaptive search area in motion estimation processes
US8897355B2 (en) * 2011-11-30 2014-11-25 Avago Technologies General Ip (Singapore) Pte. Ltd. Cache prefetch during motion estimation

Also Published As

Publication number Publication date
IL257846A (en) 2018-04-30
US10999586B2 (en) 2021-05-04
US20200228810A1 (en) 2020-07-16
FR3041495A1 (fr) 2017-03-24
WO2017046273A1 (fr) 2017-03-23
FR3041495B1 (fr) 2017-10-20

Similar Documents

Publication Publication Date Title
WO2017046273A1 (fr) Procede d'encodage d'image et equipement pour la mise en oeuvre du procede
EP3318061B1 (fr) Procede d'encodage d'image et equipement pour la mise en oeuvre du procede
EP3225029B1 (fr) Procede d'encodage d'image et equipement pour la mise en oeuvre du procede
FR2906433A1 (fr) Procedes et dispositifs de codage et de decodage d'images, programme d'ordinateur les mettant en oeuvre et support d'informaton permettant de les mettre en oeuvre
FR2932637A1 (fr) Procede et dispositif de codage d'une sequence d'images
WO2010043811A1 (fr) Procede et dispositif de codage d'une sequence d'image mettant en oeuvre des blocs de taille differente, signal, support de donnees, procede et dispositif de decodage, et programmes d'ordinateur correspondants
FR2951345A1 (fr) Procede et dispositif de traitement d'une sequence video
FR2933565A1 (fr) Procede et dispositif de codage d'une sequence d'images mettant en oeuvre une prediction temporelle, signal, support de donnees, procede et dispositif de decodage, et produit programme d'ordinateur correspondants
EP3075155B1 (fr) Procédé de codage et de décodage d'images, dispositif de codage et de décodage d'images et programmes d'ordinateur correspondants
FR3002062A1 (fr) Systeme et procede de reduction dynamique de l'entropie d'un signal en amont d'un dispositif de compression de donnees.
EP3972247B1 (fr) Procédé de codage et de décodage d'images, dispositif de codage et de décodage d'images et programmes d'ordinateur correspondants
EP3158749B1 (fr) Procédé de codage et de décodage d'images, dispositif de codage et de décodage d'images et programmes d'ordinateur correspondants
EP2279620B1 (fr) Prediction d'images par determination prealable d'une famille de pixels de reference, codage et decodage utilisant une telle prediction
FR3057130B1 (fr) Procede de codage d'une image, procede de decodage, dispositifs, equipement terminal et programmes d'ordinateurs associes
FR2959093A1 (fr) Procede et dispositif de prediction d'une information de complexite de texture contenue dans une image
FR2957744A1 (fr) Procede de traitement d'une sequence video et dispositif associe
FR3079098A1 (fr) Procede d'encodage et de decodage video faible latence
WO2011051596A1 (fr) Procédés et dispositifs de codage et de décodage d'images, et programmes d'ordinateur correspondants
FR3035761A1 (fr) Procede de codage et de decodage d'images, dispositif de codage et de decodage d'images et programmes d'ordinateur correspondants
WO2024042286A1 (fr) Lissage hors boucle de codage d'une frontière entre deux zones d'image
FR3100679A1 (fr) Procede d’encodage d’image et equipement pour la mise en œuvre du procede
FR3081656A1 (fr) Procedes et dispositifs de codage et de decodage d'un flux de donnees representatif d'au moins une image.
FR2956552A1 (fr) Procede de codage ou de decodage d'une sequence video, dispositifs associes
FR3111253A1 (fr) Procede de traitement d’image et equipement pour la mise en œuvre du procede
EP3854085A1 (fr) Procédés et dispositifs de codage et de décodage d'un flux de données représentatif d'au moins une image

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180227

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190130

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20211104