USING FRAME RATE UP CONVERSION TOOLS

FIELD OF THE INVENTION

The present principles relate to video compression and more particularly to performing video coding and decoding.

BACKGROUND OF THE INVENTION

Many attempts have been made to improve the coding efficiency of block-based codecs. Frame Rate Up-Conversion (FRUC) is a tool that allows derivation of motion vector predictors without any information, i.e. without supplemental syntax. The FRUC process is completely symmetric, in that the same operations are performed at the decoding side as at the encoding side.

This tool can only be fully on or off with one flag (as shown in Table 2) while it uses several sub-tools:

AMVP (Advanced Motion Vector Prediction) blocks use one template matching cost function, and no signaling.

Merge blocks can use a sub-part refinement with the same process, with two different template matching cost functions, and with some signaling (off/on Template/ Bilateral).

Overall performances of the FRUC too! as well as of the different sub-tools over the Joint Exploration Model 4 (JEM 4) of the Joint Video Exploration Team (ITU-T VCEG (Q6/16) and ISO/!EC MPEG (JTC 1/SC 29/WG 11 ) are provided in Table 1.

Low delay B MainIO

Over H -16.6-JE -4.0 (parallel)

Y U V I EncT DecT FRUC -2 41· ^' :. -3 28 ·:·. -3 39'':. 161% 162%

A VP -0.41% 0.17% -0.28% 113% 116%

Merge -2 OST-, -3 65-, -3 79 ··. 132% 136%

Sub-part -0.48% -0.99% -0.79% 114% 117%

Bilateral - 1 03-> -2 Off ¹ -. -2.10% 120% 120%

Table 1 Performances of the FRUC tools and sub-toois over the JEM4 [2]

Moreover, several of these sub-tools use parameters. Some of them are already in the syntax as shown in Table 2, but the others are absent.

In Table 2, sps_use_FRUC_mode is the on/off flag for the whole FRUC tool,

FRUC_refine_filter allows changing the sub-pel interpolation filter, FRUC_refine_range_in_pel defines the maximum integer pel range for refinement, and FRUC_small_blk_refine_depth the maximum depth for sub-parts of FRUC Merge blocks (i.e. their minimum size).

Table 2 SPS syntax of the current FRUC tool

SUMMARY OF THE INVENTION

These and other drawbacks and disadvantages of the prior art are addressed by the present described embodiments, which are directed to a method and apparatus to manage a trade-off between the coding efficiency provided by FRUC tools and its complexity. According to an aspect of the described embodiments, there is provided a method. The method comprises steps for encoding a portion of a video image, comprising performing frame rate up conversion for a portion of a video image; including a first flag in a video bitstream, the first flag indicative of the frame rate up conversion; and including a second flag in said video bitstream, said second flag further indicative of said frame rate up conversion.

According to another aspect of the described embodiments, there is provided a method. The method comprises steps for decoding a portion of a video image, comprising parsing a video bitstream to identify a first flag; parsing a video bitstream to identify a second flag, and performing frame rate up conversion for a portion of a video image based on the first flag and the second flag.

According to another aspect of the described embodiments, there is provided an apparatus. The apparatus comprises a memory and a processor. The processor can be configured to encode a portion of a video signal by performing frame rate up conversion for a portion of a video image; including a first flag in a video bitstream, the first flag indicative of the frame rate up conversion; and including a second flag in said video bitstream, said second flag further indicative of said frame rate up conversion.

According to another aspect of the described embodiments, there is provided an apparatus. The apparatus comprises a memory and a processor. The processor can be configured to decode a portion of a video signal by parsing a video bitstream to identify a first flag; parsing a video bitstream to identify a second flag, and performing frame rate up conversion for a portion of a video image based on the first flag and the second flag.

These and other aspects, features and advantages of the present principles will become apparent from the following detailed description of exemplary embodiments, which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates a block diagram for a typical video encoder to which the proposed embodiments can be applied.

Figure 2 illustrates a block diagram for a typical video decoder to which the proposed embodiments can be applied. Figure 3 illustrates one embodiment of a method for encoding using the described embodiments.

Figure 4 illustrates one embodiment of a method for decoding using the described embodiments.

Figure 5 illustrates one embodiment of an apparatus for encoding or decoding using the described embodiments.

DETAILED DESCRIPTION

The domain of the embodiments described herein is video compression, intended to improve the video compression efficiency of state of the art video coding schemes.

An exemplary coding tool recently introduced in the Joint Exploration Model (JEM) is called FRUC (Frame Rate Up Conversion), or also pattern matched motion derivation, and aims at decoder side motion block-based motion vector predictor derivation.

The Frame Rate Up-Conversion (FRUC) tool aims at finding the best motion vector predictor (MVP) among a set of candidates with respect to a template matching cost. The best identified candidate is then refined towards the minimum template matching cost.

The FRUC processes are similar for every type of block: one process is performed for the whole block then, for some particular blocks, a second process on sub-parts can also be achieved. The main difference between these processes is the initial list of candidates and the available template matching cost functions.

in order to manage the trade-off between the performances of this FRUC tool and its complexity, it is possible to inform the decoder of which FRUC processes (or sub- processes, i.e. parts of processes) are allowed or not.

The problem solved by the embodiments described herein is to manage the trade- off between the coding efficiency provided by the FRUC tool and its complexity, as for example, in the JEM video codec.

The FRUC tool is applied to all blocks (Merge and AMVP) and refined at a subpart, or a sub-block, level of Merge blocks. For AMVP blocks, only one template matching cost function is available, "Template". For Merge blocks and their sub-parts, two different template matching cost functions are tested, "Template" and "Bilateral".

Template matching derives motion information of a current coding unit by finding the best match between a template (the top and/or left neighboring blocks of a current coding unit) in a current picture and a block, having same size as the template, in a reference picture.

Bilateral matching derives motion information of the current coding unit by finding the best match between two blocks along the motion trajectory of the current coding unit in two reference pictures.

The sub-parts of Merge blocks are sub-blocks. In FRUC Merge, the FRUC tool is applied firstly at the CU (Coding Unit) level, then this CU is divided into sub-blocks and the FRUC tool is applied again for each of the sub-blocks with the same template matching cost functions as for the CU.

When the SPS (Sequence Parameter Set) FRUC flag is on, the FRUC tool is used/tested at the encoding side and is enabled at the decoding side.

For AMVP, the FRUC tool allows finding an AMVP candidate derived in the same way at encoding and decoding without signaling.

For Merge, the FRUC Merge mode is tested at the encoding side, then there is some signaling which indicates whether FRUC should be used or not, and if it is used, with which template matching cost function (there are three states: off/template/bilateral).

For a Merge CU, when the FRUC tool is activated (at SPS level), a first flag signals the Merge mode, then a second one the FRUC state. The decoder reads these flags and so knows if the FRUC tool must be used for this CU.

CU -> Merge flag = 0 => AMVP (with FRUC)

= 1 => Merge + FRUC mode = off => classical Merge

= Temp/bilat => FRUC Merge + template matching cost function in other words, currently a flag at the SPS (Sequence Parameter Set) level enables whether the FRUC tool is used. When activated, every AMVP block, at the encoding and decoding sides, goes to the FRUC tool without signaling, and every Merge block, also at the encoding side but with some signaling (off/on Template/Bilateral) goes to the FRUC tool.

The solution proposed by the aspects herein comprises adding some high-level syntax to allow management of the trade-off between the coding efficiency provided by the FRUC tool and its complexity.

As shown in Table 1 , the overall performance of the FRUC tool is huge, in the JEM4, it brings 3.60% BDrate gain in RA (Random Access), 2.41 % in LDB (Low Delay- B) and 1.38% in LDP (Low Delay-P), but with also a huge amount of complexity of about 40% in RA, 60% in LDB and 30% in LDP either at encoding and at decoding.

in this FRUC tool, there are several sub-processes that each bring coding gains but also add complexity, but they are all activated with a unique flag at the SPS level. it is advantageous to be able to manage the trade-off between the coding gain and the complexity by using some new high-level syntax to indicate which sub-tools are to be used and with which parameters or to activate particular tools on a sub-block or sub-part basis. For example, disabling the sub-parts of FRUC Merge blocks allows saving 10-15% encoding time (RA/LDB) and nearly 20% decoding time for a BD-rate loss of less than 0.5%.

in a first embodiment, the FRUC AMVP sub-tool can be enabled/disabled from the initial FRUC tools with one flag using the syntax from Table 3.

Table 3 Syntax of the flag enabling/disabling FRUC AMVP in a second embodiment, the whole FRUC Merge sub-tool, with sub-parts and both template matching cost functions, can be enabled/disabled from the initial FRUC tools with one flag using the syntax from Table 4.

Table 4 Syntax of the flag enabling/disabling the whole FRUC M in a third embodiment, the sub-parts of FRUC Merge sub-tool can be enabled/disabled from the initial FRUC tools with one flag using the syntax from Table 5. if( sps use FRUC mode ) { FRUC merge subblock u( l)

\

Table 5 Syntax of the flag enabling/disabling the sub-parts of FRUC Merge

In a fourth embodiment, the Bilateral template matching cost function of FRUC Merge sub-tool can be enabled/disabled from the initial FRUC tools with one flag using the syntax from Table 6.

Table 6 Syntax of the flag enabling/disabling the Bilateral

template matching cost function of FRUC Merge in a fifth embodiment, the whole FRUC Merge sub-tool can be enabled/disabled from the initial FRUC tools with one flag, then either the sub-parts or the Bilateral template matching cost function of FRUC Merge sub-tool can also be enabled/disabled with one flag only when the FRUC Merge sub-tool is enable.

For that purpose, the syntax should follow either Table 7 or Table 8 where FRUC_merge_xxx stands for FRUC_merge_subblock or FRUC_merge_bilateral or both.

Table 7 Syntax of the flags enabling/disabling the whole FRUC Merge, and sub-parts

and/or bilateral template matching cost function when FRUC Merge is enable

Table 8 Independent syntax of the flags enabling/disabling the whole FRUC Merge, and sub-parts and/or bilateral template matching cost function when FRUC Merge is enable in a sixth embodiment, the FRUC AMVP and the whole FRUC Merge sub-tools can be enabled/disabled from the initial FRUC tools, each with one flag. Then, the subparts and the Bilateral template matching cost function of FRUC Merge sub-tool can also be enabled/disabled with one flag using the syntax from Table 9 or Table 10.

Table 9 Syntax of the flags enabling/disabling the FRUC AMVP and the whole FRUC Merge, and sub-parts and/or bilateral template matching cost function when FRUC Merge is enable

Table 10 Independent syntax of the flags enabling/disabling the FRUC AMVP and the whole FRUC

Merge,

and sub-parts and/or bilateral template matching cost function when FRUC Merge is enable if FRUC_amvp and FRUCjmerge flags are used together, at least one must be "true" (otherwise when both flags are "false", it is the same as turning all the FRUC tool off (sps_use_FRUC_mode == "false")).

Furthermore, any other combination of the first four embodiments can be observed. in a seventh embodiment, some of the parameters that are not already in the syntax can also be added in order to manage more finely the trade-off between coding gains and complexity. These parameters can be, but are not limited to: the refinement search pattern (diamond, hexagon, cross, etc.), the number of refinement loops, the template matching size for Template function, the weight applied to the motion vector cost during refinement, the maximum number of candidates to be evaluated, the maximum value for the template matching cost, or other such parameters.

Each of these parameters can be specified either for all the processes or for each kind of block (AMVP, Merge) or sub-parts or any combination as shown on the exemplary Table 11.

Table 11 Syntax example of several FRUC parameters in an eighth embodiment, any flag introduced from embodiments 1 to 6 can be coupled with any parameter from embodiment 7.

in a ninth embodiment, such high-level syntax can take place in different NAL units as: VPS (Video Parameter Set) in the "Profile, tier, level" as a general information, SPS (Sequence Parameter Set), PPS (Picture Parameter Set), or SH (Slice Header).

The syntax location used depends on the granularity that is needed, i.e. at the VPS and SPS level it will be activated for the whole sequence, at the PPS level for a set of frames, and at the SH for each frame independently.

Syntax from embodiments 1 , 2, 3, 4, 5 Table 7, 6 Table 9 and 7 can take any location in the bitstream. The first part of the syntax from embodiments 5 Table 8 and 6 Table 10 can appear also at any location, but the second part should follow, either at the same level or at a deeper level. For example, AMVP/Merge could be defined for the whole sequence at the SPS level and the subblock/bilateral for each frame at the SH level.

One embodiment of a method 300 for performing frame rate up conversion in an encoder for a portion of a video image is shown in Figure 3. The method commences at Start block 301 and proceeds to block 310 for performing frame rate up conversion for a portion of a video image. Control proceeds from block 310 to block 320 for including a first flag in a video bitstream, the first flag indicative of the frame rate up conversion. Control proceeds from block 320 to block 330 for including a second flag in the video bitstream, the second flag further indicative of said frame rate up conversion. The second flag can be used to indicate additional features of the frame rate conversion process, such as performance for a sub-part of a block or coding unit, or implementing one or more sub-processes of the frame rate up conversion process.

One embodiment of a method 400 for performing frame rate up conversion in a decoder for a portion of a video image is shown in Figure 4. The method commences at Start block 401 and commences to block 410 for parsing a video bitstream to identify a first flag. Control proceeds from block 410 to block 420 for parsing a video bitstream to identify a second flag. Control proceeds from block 420 to block 430 for performing frame rate up conversion for a portion of a video image based on the first flag and the second flag.

One embodiment of an apparatus 500 for encoding or decoding a block in a video image is shown in Figure 5. The apparatus comprises a Processor 510 and a Memory 520. The Processor 510 is configured, for encoding, to perform the steps of Figure 3, that is performing frame rate up conversion for a portion of a video image; including a first flag in a video bitstream, the first flag indicative of the frame rate up conversion; and including a second flag in the video bitstream, the second flag further indicative of the frame rate up conversion.

When Processor 510 is configured for decoding, it performs the steps of Figure 4, that is, decoding a video bitstream by parsing a video bitstream to identify a first flag; parsing a video bitstream to identify a second flag, and performing frame rate up conversion for a portion of a video image based on the first flag and the second flag.

The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor ("DSP") hardware, read-only memory ("ROM") for storing software, random access memory ("RAM"), and non-volatile storage.

Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

The present description illustrates the present principles. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the present principles and are included within its scope.

All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the present principles and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.

Moreover, all statements herein reciting principles, aspects, and embodiments of the present principles, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative circuitry embodying the present principles. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. in the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The present principles as defined by such claims reside in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

Reference in the specification to "one embodiment" or "an embodiment" of the present principles, as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment of the present principles. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment", as well any other variations, appearing in various places throughout the specification are not necessarily all referring to the same embodiment.

In conclusion, improved methods and apparatus of performing frame rate up conversion for a portion of a video image are shown by the aforementioned embodiments. In at least one embodiment, an encoder can signal to a decoder whether to use frame rate up conversion for only portions of a video image or a sub-part of a coding unit. In addition, flags are provided to use sub-processes of the frame rate up conversion process in an encoder or a decoder.