Video encoder/decoder, method and computer program product that process tiles of video data

Abstract

A video decoder, method and computer program product allow for processing of a video frame encoded in rectangular tiles. An interface receives a bit stream in tile order within a video frame that was encoded into rectangular tiles. A processor decodes the video frame while respecting dependency breaks at tile boundaries; the rectangular tiles include an integer number of two-dimensional blocks of pixels. A tile shape is defined by N×M two-dimensional blocks of pixels, respective values of N and M need not be identical for each of the rectangular tiles, and information regarding tile shape for each tile being conveyed from an encoder to the decoder. The decoder determines N and M for each tile from the information, and tiles have dependency breaks therebetween.

Description

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the benefit of the earlier filing date of U.S. Provisional application 61/666,011, filed on Jun. 29, 2012, the entire contents of which being incorporated herein by reference.

TECHNICAL FIELD

The present application relates to video encoders/decoders, methods and computer program product generally, and more particular to video encoders/decoders, methods and computer program product that process groups of adjacent blocks arranged in tiles.

BACKGROUND

The “background” description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventor, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present invention.

A video encoder is typically implemented by dividing each frame of original video data in blocks of pixels. In existing standards for video compression (e.g., MPEG1, MPEG2, H.261, H.263, and H.264) these blocks would normally be of sized 16×16 and be referred to as macroblocks (MB). In the future HEVC/H.265 standard, the blocks would typically be larger (e.g. 64×64) and might be rectangular, for instance at frame boundaries.

Typically, the blocks are processed and/or transmitted in raster scan order, i.e. from the top row of blocks to the bottom row of blocks, and from left to right within each row of blocks.

For each block of original pixel data the encoding is typically performed in the following steps:

• • Produce prediction pixels using reconstructed pixel values from i) the previous frame (inter prediction), or ii) previously reconstructed pixels in the current frame (intra prediction). Depending on the prediction type, the block is classified as an inter block or an intra block.
  • Compute the difference between each original pixel and the corresponding prediction pixel within the block.
  • Apply a two-dimensional transform to the difference samples resulting in a set of transform coefficients.
  • Quantize each transform coefficient to an integer number.
  • Perform lossless entropy coding of the quantized transform coefficient.
  • Apply a two-dimensional inverse transform to the quantized transform coefficient to compute a quantized version of the difference samples.
  • Add the prediction to form the reconstructed pixels for the current block.

Moreover, in reference to FIG. 1, a current frame as well as a prediction frame are input to a subtractor 9. The subtractor 9 is provided with input from an intra prediction processing path 3 and a motion compensation processing path 5, the selection of which is controlled by switch 7. Intra prediction processing is selected for finding similarities within the current image frame, and is thus referred to as “intra” prediction. Motion compensation has a temporal component and thus involves anslysis between successive frames that is referred to as “inter” prediction.

The output of the switch 7 is subtracted from the pixels of the current frame in a subtractor 9, prior to being subjected to a two dimensional transform process 13. The transformed coefficients are then subjected to quantization in a quantizer 15 and then subject to an entropy encoder 17. Entropy encoding removes redundancies without losing information, and is referred to as a lossless encoding process. Subsequently, the encoded data is arranged in network packets via a packetizer, prior to be transmitted in a bit stream.

However, the output of the quantizer 15 is also applied to an inverse transform and used for assisting in prediction processing. The output is applied to a deblocking filter 8, which suppresses some of the sharpness in the edges to improve clarity and better support prediction processing. The output of the deblocking filer 8 is applied to a frame memory 6, which holds the processed image pixel data in memory for use in subsequent motion processing.

The corresponding decoding process for each block can be described as follows (as indicated in FIG. 2). After entropy decoding 22 (to produce the quantized transform coefficients) and two dimensional inverse transformation 26 on the quantized transform coefficient to provide a quantized version of the difference samples, the resultant image is reconstructed after adding the inter prediction and intra prediction data previously discussed.

Some of the more detailed encoder and decoder processing steps will now be described in more detail. In video encoders, blocks can be divided into sub-blocks. Typically, the blocks are of fixed (square) size, while the sub-blocks can be of various e.g. (rectangular) shapes. Also, the partitioning into sub-blocks will typically vary from one block to another.

Inter prediction is typically achieved by deriving a set of motion vectors for each sub-block. The motion vectors define the spatial displacement between the original pixel data and the corresponding reconstructed pixel data in the previous frame. Thus, the amount of data that needs to be transmitted to a decoder can be greatly reduced if a feature in a first frame can be identified to have moved to another location in a subsequent frame. In this situation, a motion vector may by used to efficiently convey the information about the feature that has changed position from one frame to the next.

Intra prediction is typically achieved by deriving an intra direction mode for each sub-block. The intra direction mode defines the spatial displacement between the original pixel data and the previously reconstructed pixel data in the current frame.

Both motion vectors and intra direction modes are encoded and transmitted to the decoder as side information for each sub-block. In order to reduce the number of bits used for this side information, encoding of these parameters depends on the corresponding parameters of previously processed sub-blocks.

Typically, some form of adaptive entropy coding is used. The adaptation makes the entropy encoding/decoding for a sub-block dependent on previously processed sub-blocks. Entropy encoding is lossless encoding that reduces the number of bits that are needed to convey the information to a receiving site.

Many video encoding/decoding systems and methods apply a deblocking filter (8 in FIG. 2) across boundaries between blocks. Moreover, a deblocking filter is applied to blocks in decoded video to improve visual quality and prediction performance by smoothing the sharp edges which can form between blocks when block coding techniques are used. The filter aims to improve the appearance of decoded pictures.

The AVC/H.264 standard for video compression supports two mechanisms for parallel processing of blocks: Slices and Slice groups.

Slices

A slice in AVC/H.264 is defined as a number of consecutive blocks in raster scan order. The use of slices is optional on the encoder side, and the information about slice boundaries is sent to the decoder in the network transportation layer or in the bit-stream as a unique bit pattern.

The most important feature for slice design in AVC/H.264 is to allow transportation of compressed video over packet-based networks. Typically, one slice of compressed video data is transported as one packet. To ensure resilience to packet loss, each slice is independently decodable. As recognized by the present inventor this requirement implies that all dependencies between blocks of different slices are broken. In addition, key parameters for the entire slice is transported in a slice header.

Slice Groups

Slice groups in AVC/H.264 define a partitioning of the blocks within a frame. The partitioning is signalled in the picture header. Blocks are processed and transmitted in raster-scan order within a slice group. Also, as recognized by the present inventor, since a slice can not span more than one slice group, dependencies are broken between slice groups in the same manner as between slices. As recognized by the present inventor, slice groups are different from “tiles” (as will be subsequently be discussed in detail) in at least two important aspects. First, with slice groups, blocks are transmitted in raster scan order within the slice group. Having to decode a bit stream that uses raster-scan order within a slice-group is a highly undesirable requirement for many decoders, especially those using a single core. This is because pixels are best decoded in the same order as they are rendered and stored in memory for rendering on a display device. In the extreme case, a bit stream with slice groups could force the decoder to decode each frame one column (of blocks) at a time rather than one row (of blocks) at a time. Secondly, slice groups can specify non-contiguous partitions of a frame (e.g. checkerboard pattern). Having to decode e.g. all the “white” blocks before all the “black” blocks of a checkerboard pattern or even more sophisticated patterns place an even worse burden on a decoder. Because of these difficulties in implementing generic slice groups in AVC/H.264 decoders, the latest revision of the AVC/H.264 standard introduced a new profile (constrained profile) which disallowed the use of slice groups in the bit stream. Decoders not being able to decode slice groups could then claim compliance with the constrained profile (instead of the baseline profile). With tiles (as will be discussed in the detailed description), blocks are transmitted in raster-scan order within the frame which is the optimal transmission order for most single core decoders.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a video encoder.

FIG. 2 is a block diagram of a video decoder.

FIGS. 3a and 3b show a layout relationship between encoder processing order and transmission order respectively according to one embodiment.

FIG. 4 shows a block diagram of an encoder according to an embodiment that supports parallel processing with the use of tiles.

FIG. 5 is a block diagram of a decoder according to an embodiment that supports parallel processing with the use of tiles.

FIG. 6 is a flowchart of an exemplary process performed according to an embodiment.

FIG. 7 is a block diagram of a host communication device according to an embodiment that employs the use of tiles in video encoding and decoding.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The present inventor recognized limitations with conventional approaches for partitioning frames into groups of macroblocks. For example, although the dependency breaks that are defined for slices in AVC/H.264 are useful also for parallel processing, the definition of slices also has some disadvantages. The slice header implies a significant overhead that is not needed for parallel processing. Also, the grouping of blocks into slices needs to comply with the raster-scan processing of blocks. In turn, this imposes an unnecessary an often undesired restriction on how a frame can be divided into independently decodable blocks.

With respect to slice groups being able to make available many partitions, the present inventor recognized that rectangular partitions/slice groups are most relevant for parallel processing. Rectangular partitioning enables partitioning vertically (columns) as well as horizontally. Even though the definition of slice groups gives the encoder flexibility to define almost any partition of the frame, the scheme has some undesired implications on the decoder. In particular, the decoder is forced to process the blocks in the same order as the encoder (i.e. raster-scan within a slice group). This might have severe implications on the decoder implementation as the decoder must be designed to handle almost arbitrary scan-orders. Another disadvantage of the slice groups in AVC/H.264 is that a maximum of 8 slice groups are allowed, and that each slice group consist of a separate slice including a slice header.

Typically, a video decoder specification defines sequential block processing in raster scan order as the normal mode of operation. This ensures maximum compression efficiency by allowing dependency between neighbour blocks of the same frame to be exploited without restrictions. Typically, this implies that parameters for a given block depend on the same parameters in the blocks to the left and above. As described previously, this typically applies to reconstructed pixels for intra prediction, motion vector coding, intra direction mode coding, and adaptive entropy coding.

Independent of the sequential nature of video encoding/decoding methods, many hardware architectures are designed for parallel processing to maximize the throughput (number of pixels processed per second). Typically a processing device designed for parallel processing comprises a number of cores (typically between 2 and 100), each core being able to encode/decode a subset of the blocks within a frame in parallel with other cores. This is best achieved if there are no dependencies between blocks being processed on different cores. Thus there is a trade-off between compression efficiency and the degree of parallel processing (number of blocks being processes simultaneously).

The cores have access to shared memory where the previous reconstructed frames are stored. In those cases, dependencies between neighbouring blocks only needs to be broken for the current frame, allowing for unrestricted choice of motion vectors.

Accordingly, one aspect of the present disclosure is that it minimizes the penalty on compression efficiency, while maximizing the degree and flexibility of parallel processing when encoding video frames.

Moreover, another aspect of the present disclosure is that it introduces tiles as a group of N×M adjacent blocks with dependency breaks at the tile boundaries. As opposed to slices and slice groups, the definition of tiles is independent of the transmission order. The transmission order is assumed to follow the normal raster scan order within a frame (or slice group). This implies that an encoder/decoder can choose to perform all processing except bit-stream generation/parsing independently for each tile. Even if the encoder processes the frame by tiles, the decoder can choose to decode the frame in raster scan order.

The present embodiment introduces the notion of “tiles” to exploit the two dimensional dependencies between blocks while also supporting the exploitation of multiple processors, if available in the encoder, to simultaneously perform encoding operations on multiple tiles. The partitioning of a frame into tiles is completely specified by the numbers N and M, eliminating the need for a slice header, which is a basic requirement in conventional slice processing. Here, N and M are the height and width of a tile measured in number of blocks. Typically, the values of N and M are conveyed to the decoder in the sequence header or picture header resulting in negligible transmission bandwidth overhead. In addition to unilaterally transmitting the N and M numbers to the decoder in the sequence or picture header, an alternative is to have a handshaking operation between the decoding device and encoding device, where the values of N and M are exchanged, as well as perhaps the processing capabilities of the decoder.

By making the dependency breaks in a N×M tile, the system exploits the possibility in images to create both vertical boundaries as well as horizontal boundaries that minimally disturbed correspondences between blocks. Moreover, the content of a particular series of images may be a natural landscapes that often have horizontal dependencies (such as horizons, etc.). On the other hand, imagery involving forests or other vertical oriented images may benefit more greatly by having a larger vertical dimension so that more blocks in the vertical dimension may be included as part of a common tile, thereby allowing for the exploitation of the dependencies between blocks in the vertical direction. The specification of the numbers N and M specifies dependency breaks at tile boundaries by implication.

In a typical video encoder according to the present embodiment, at least the following dependencies are broken at tile boundaries (other dependencies may be broken as well depending on the relevant standard defining the decoding requirements):

• • Use of reconstructed pixels for intra prediction,
  • Use of motion vectors from neighbouring blocks for motion vector coding,
  • Use of intra direction modes from neighbour blocks.
  • Adaptive entropy coding based on previously encoded blocks.
  • Flushing of arithmetic coding bits.
  • Deblocking filter across tile boundaries, although this can be avoided if deblocking is performed as a separate pass on a single processing core.
  • Use of adaptive loop filter (ALF)
  • Use of sample adaptive offset (SAO).

FIG. 3a shows an arrangement of 2×3 tiles (arbitrarily choosing 2 as being the vertical component and 3 being the horizontal component of a tile, but vice versa would also be an acceptable convention). Blocks having a same letter belong to a common tile and therefore are best suitable for being processed with one processing core. Therefore, supposing four processing cores are available, the “A” tile may be processed by one core while separate cores may handle the B, C and D tiles respectively, where all the processing is done in parallel.

In a non-limiting context, the numbers in each tile of FIG. 3a represent an ordering of macro blocks (or other blocks) within the tile. For example, for tile A the first three blocks 0-2 are arranged in a horizontal row (in the raster scan direction), while a second row of blocks 3-5 are disposed in a row beneath the first row. Thus, the blocks are arranged in a two-dimensional group of blocks where the dependencies are broken at the vertical edge between tile A and tile B, and at the horizontal edge between tile A and tile C.

FIG. 3b shows the transmission order for the frame, which follows the raster-scan order. In order to reorder the bits from the tiles into the bits in raster scan order, a tile reformatter is used. Likewise, at the decoder, if processing by tiles is chosen, a tile formatter is used to return the bits to proper block for each tile. The tile reformatter at the encoder conversion changes the tile-order (A0,A1,A2,A3,A4,A5,B0,B1,B2, . . . ) as shown in FIG. 3a to raster-scan order (A0,A1,A2,B0,B1,B2,A3, A4, . . . ) as shown in FIG. 3b. Likewise, the tile formatter at the decoder performs a reordering operation from raster-scan order to tile-order.

Regarding this reformatting process, if the encoder processes in tiles and the bits from each tile were not reordered, the resulting bitstream would be in tile-order. In that case, the decoder would have two options could either a) do nothing with the bitstream and decode the blocks in tile-order, or b) convert to raster-scan order and then decode the blocks in raster-scan order. Both options are alternative embodiments, although they place an extra processing burden on the decoder. On the other hand, the primary embodiment reflected in the drawings is to have the encoder place the bits in raster-scan order In turn, this minimizes the processing burden on the decoder and allows the decoder to either: a) do nothing with the bitstream and decode the blocks in raster scan order (i.e. no tile penalty), or b) convert from raster-scan order to tile-order and decode the blocks in tile-order. Therefore, if the encoder processes in tiles and assumes the burden of converting from tile-order to raster-scan order the decoder are compelled to do nothing except respect the dependency breaks at the tile boundaries.

In an encoder according to the present embodiment, tiles are processed in parallel on different cores. Each core produces a string of compressed bits for that particular tile. In order to transmit the compressed data in raster scan order, the bits produced by different tiles/cores need to be reformatted. This is typically done on a single core.

A parallel processor embodiment is illustrated in FIG. 4, where the dashed line indicates modules that are processed in parallel on respective cores. Moreover, each core is assigned a processing task per tile (although there is no restriction on processing multiple tiles per core), and share memory resources to assist in sharing reference data for inter prediction between tiles and blocks. The frame memory resides in shared memory, while the tile reformatter is implemented on a single core. (Alternatively, the deblocking filter can run on a single core.) Moreover, the subtractor 9, transform 13, quantization 15, inverse transform 26, blocking filter 8, frame memory 6, motion compensation 5, intraprediction 3, switch 7 and entropy coder 17 are all similar to that described earlier in FIG. 1. However, in this multicore embodiment that provides tile-compatible processing, a tile reformatter 18 is used to retrieve and arrange bits from respective tiles so as to place them in raster scan order so that the bit stream sent from the encoder of FIG. 4 would be in raster scan order. Likewise, a decoder would optionally employ a corresponding tile formatter if it is configured to repackage the bits into the end by end tiles before decoding.

Another thing to note in FIG. 4, is the presence of dashed lines. As discussed above, a common core may perform all the functions, for example, of the transform 13, quantization 15, entropy coder 17, inverse transform 26, deblocking filter 8, motion compensation 5, switch 7 and interprediction 3. Because the tile reformatter 18 and frame memory 6 are available as a common resource amongst the different cores, each used for processing different tiles, the frame memory and tile reformatter 18 are not limited to use on a single core, but rather available for interfacing between the different cores. Likewise the subtractors and adders shown are implemented on a different core. The present arrangement of encoding functions on different cores is meant to be non-exhaustive. Instead, one aspect of having the arrangement in tiles is that there can be a correspondence between the tiles and the number of cores made available. Moreover, as discussed above, having multiple processor cores, provides available processing resources that may result in arranging a number of tiles to correspond with those cores.

At the decoder side, the decoder in the handshaking process with the encoder, can specify whether the tile reformatter 18 shall be used or not (in a tile partitioning mode or not). The tile partitioning mode allows for the reception of bits read out from respective tiles, without reformatting, or reformatted so as to place the bits in the same order as would be provided in a raster-scan or as would be done with a conventional encoder. Of course, in a more straightforward process, no handshaking is performed and the encoder and decoder always operate in the tile partitioning mode. It should be noted that when both the encoder and decoder operate in tile partitioning mode the tile reformatter (encoder) and tile formatter (decoder) are not needed since there is no need to put the bit-stream in raster scan order. Thus, the tile reformatter 18 and tile formatter 25 have an internal by-pass capability for passing the bit-stream there through without manipulation. Of course in FIGS. 4 and 5 the tile reformatter 18 and tile formatter 25 are also used to show the two way communication between the encoder and decoder. This connection is merely exemplary because the encoder and decoder can exchange information (such as the values for N and M through sequence- or picture headers) through any one of a variety of communication interfaces. Moreover, the bits representing the values N and M need not be reformatted in any way, and thus by-pass the reformatting and formatting functions in the tile reformatter 18 and tile formatter 25 respectively. In this same way, other message data exchanged between the encoder and decoder use the tile reformatter and tile formatter as a communications interface, without bit reordering.

FIG. 5 is a block diagram of a decoder according to an embodiment that supports a tile portioning mode of operation, and includes parallel processing to assist in processing separate tiles. As was the case with FIG. 4, a dashed line indicates what decoding components are supported on a separate processing core, such that multiple cores may be used to simultaneously process tiles received from the encoder. The frame memory 6 is used as a common resource, similar to what is done at the encoder in FIG. 4. The tile formatter 25 initially receives the values N and M from the tile reformatter 18 from the encoder, although the tile reformatter does not perform any bit manipulation or reordering of these values. Instead, from the values N and M, the tile formatter 25 recognizes the tile shapes for the data arriving from the incoming bit stream and ultimately allows the decoder components to perform a decoding operation based on the tile partitioning (and associated dependency breaks) introduced at the encoder. Moreover, the decoder breaks the dependencies in the current frame between blocks at tile boundaries as dictated by the values N and M. It should be noted that the encoder may provide multiple pairs of N and M, indicating that each tile, or at least multiple tiles, in a frame can have a different rectangular shape.

In some instances, the decoder can specify its wishes to the encoder for required/desired values of N and M or whether to use tile partitioning at all. This may be useful, for example, by the decoder informing the encoder that the decoder can support only a 720p30 display format if not in tile partitioning mode, but could support 1080p30 display format if used in a tile partitioning mode using tiles that are not larger than N×M. This two-way communication between the encoder and the decoder is represented by a double headed arrow at the tile formatter 25 in FIG. 5.

When arranged in this way, tiles offer the advantage over conventional slices and slice groups in that no tile header is needed to identify tile boundaries. Moreover, there is no overhead required on a tile-by-tile or block-by-block basis to support the identification of tile boundaries. Instead, by specifying at first the shape of the tiles, or by reading the sequence or frame headers, the decoder has all the information it needs to identify tile boundaries based on the original specification of the values N and M. Also, the decoder has the option of using the tiles or not. In this way, the impact on the decoder is minimal since the decoder need not perform tile processing if it chooses not to. Also by allowing the encoder to specify different N×M shaped tiles, there is a large amount of flexibility with regard to arranging the number and size of the tiles to better support parallel processing and the speed with which encoding may be performed when multiple cores are available.

Moreover, tiles offer an advantage of decoupling the encoding process from the transmission order in which the bits are transmitted. This allows for better vertical intra prediction as opposed to conventional processes. Also, by using parallel tiles allows for better parallization for analysis since there is less constraint on tile shape and no header is required.

As further explanation, an advantage of breaking dependency at column boundaries (vertical boundaries), is that by dividing a frame vertically provides a smaller penalty on compression performance since a vertical boundary is shorter than a horizontal boundary when a 16:9 aspect ratio is the format for display, because motion generally tends to be performed in a horizontal direction. Also, parallelization by columns reduces a delay since the data arrives one row at a time from the camera and all available cores can start to work immediately on a new row, as it arrives. Thus, partitioning a frame into tiles allows for the more efficient use of available cores to begin immediate processing of data provided from a camera, as compared with conventional approaches using slices or slice groups.

Also, by using tiles, it is possible to be more flexible in the encoder for performing “stitching”. Stitching is the collection of arbitrarily shaped rectangles which means that the change in spatial position of sub-pictures by manipulation in the compressed domain may be made possible.

Tiles also allow for more efficient packetization into (almost) fixed-sized packets. Thus a packetizer can assemble independent shelves of compressed data (one per column/row) into one packet without any backwards dependency to the encoding process. This helps provide autonomy in how data is transmitted from one location to the next for both transmission over separate communication paths, as well as processing independently at the decoder side. As discussed above, allowing for parallization by columns, also provides for finer-grained parallelism and better load balancing amongst processing cores.

Finally, another advantage of using tiles is that by encoding by smaller widths provides the opportunity to reduce memory bandwidth and internal memory as composed to slice processing or slice groups. Moreover, the reduction in memory bandwidth and internal memory may be made available even if a single-core implementation is used.

As a summary, below is a list of advantages of dependency breaks at column boundaries:

• • 1) Dividing a frame vertically gives smaller penalty on compression performance since a vertical boundary is shorter than a horizontal boundary (assuming 16:9 aspect ratio) and because motion tends to be horizontally.
  • 2) Parallelization by columns reduces the delay since data arrives one row at a time from the camera, and all cores can start to work immediately as a new row arrives.
  • 3) Flexibility in the encoder to do “stitching” of arbitrarily shaped rectangles, i.e. change the spatial position of sub-pictures by manipulations in the compressed domain.
  • 4) More efficient packetization into (almost) fixed-sized packets. The packetizer can assemble independent chunks of compressed data (one per column/row) into one packet without any backward dependency to the encoder process.
  • 5) Parallelization by columns provides finer-grained parallelism and better load balancing.
  • 6) Encoding by smaller widths might reduce the memory bandwidth and internal memory. This is true even for single-core implementations.

FIG. 6 is a flowchart showing a method for encoding frames using N×M tiles. The process begins in step S1, where a frame is portioned into blocks of pixels. The process then proceeds to step S3 where the blocks are arranged into N×M tiles. The tiles are grouped independent of the order of transmission of the blocks. The process then proceeds to step S5, where the values of N and M are transmitted to the receiving device in the sequence or picture header, but not in a slice or slice group header, recognizing that AVC/H.264 does not support anything but slices or slice groups. The tiles would not be compliant with AVC/H.264 because if the encoder decided to divide the frame into tiles, the decoder would not recognize the format. In a sequence header (before the first frame—which is part of the video stream, but after the call set up), the encoder would send the height and width of the tile. This way the decoder would know the size of the tiles. It should be noted that there can also be a pre-assignment of tile shape to type of frame, for example I (intra frame), B and P frames.

Each tile may then be encoded in parallel in step S7, where each tile is optionally encoded by a separate processing core. Of course a single core can process more than one tile. Also, devices with only one core can process all of the tiles. The process then proceeds to step S9 where the encoded tiles are transmitted to the receiving device. The transmission order can be in the raster scan order even though the tiles may have been encoded in a different order. Once transmitted to the decoder at the receiving device, the decoder decodes the tiles in step S11 with one or more cores. The process then repeats in step S13 for processing the next frame.

The present inventor recognized that processing tiles may present an implementation burden for single-core decoders. Accordingly, for adopting an industry-wide video compression standard that includes tile processing, some restrictions may be applied. Example restrictions are described below.

• • Even if the bitstream is in tile order, some single core hardware decoders might be adapted to process in raster scan order. To make that feasible, single core decoders would benefit from knowing the start location (measured in number of bytes) in the bitstream for each tile in a frame or sub-frame. It should be noted that although tiles sizes in the pixel domain are deterministic, tile sizes in the compressed domain are input/content-dependent. It is plausible that future video compression standards, in some profiles, will make it mandatory for an encoder to send the size of each tile (in bytes) in the beginning of each frame, or sub-frame. However, this has a bandwidth cost that is unwanted for decoders that are capable of processing in tile order.
  • For single-core decoders it is desirable to have as few tiles as possible. This desire is in conflict with multi-core encoders that are better suited to process many tiles at the same time. It is plausible that future video compression standards, in some profiles, will contain a compromise expressed as a minimum tile width and a minimum tile height. For example, there may be a minimum tile width of 384 pixels (or samples), and there may be a minimum tile height of 192 pixels (or samples). In this example, these restrictions will allow for only 3×3=9 tiles for 1280×720 resolution.

It is anticipated in future video compression standards, there will be some profiles where tile restrictions apply (are mandatory), and other profiles where tile restrictions do not apply (are optional). For profiles where tile restrictions are optional, it would be possible for decoders to benefit from a flag, that is sent from the encoder in the sequence header, which informs the decoder whether certain tile restrictions (including those above) apply or not. An additional benefit of this flag is that it makes it easy to specify (in a standard text) whether the tile restrictions apply or not. The flag may be a single bit when signaling whether all tile restrictions are in place, or not. A multi-bit symbol may be used when there are multiple restrictions in place, and each bit within the multi-bit symbol signifies whether a particular restriction applies to the encoding and the bit stream.

The following table is from “High efficiency video coding (HEVC) text specification draft 7”, which was developed by Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11. In the standard, text specifies conformance points for an HEVC decoder. Essentially it defines decoder capabilities by level. For example, a decoder supporting 720p (1280×720 pixels) resolution would claim conformance to level 3.1, while a decoder supporting 1080p (1920×1080 resolution) would claim conformance to level 4.

	Max luma	Max luma
	sample rate	picture size	Max bit	Min	MaxDpbSize
	MaxLumaPR	MaxLumaFS	rate MaxBR	Compression	(picture storage	Max CPB size
Level	(samples/sec)	(samples)	(1000 bits/s)	Ratio MinCR	buffers)	(1000 bits)
1	552,960	36,864	128	2	6	350
2	3,686,400	122,880	1,000	2	6	1,000
3	13,762,560	458,752	5,000	2	6	5,000
3.1	33,177,600	983,040	9,000	2	6	9,000
4	62,668,800	2,088,960	15,000	4	6	15,000
4.1	62,668,800	2,088,960	30,000	4	6	30,000
4.2	133,693,440	2,228,224	30,000	4	6	30,000
4.3	133,693,440	2,228,224	50,000	4	6	50,000
5	267,386,880	8,912,896	50,000	6	6	50,000
5.1	267,386,880	8,912,896	100,000	8	6	100,000
5.2	534,773,760	8,912,896	150,000	8	6	150,000
6	1,002,700,800	33,423,360	300,000	8	6	300,000
6.1	2,005,401,600	33,423,360	500,000	8	6	500,000
6.2	4,010,803,200	33,423,360	800,000	6	6	800,000

Presently there is a tile size restriction expressed in “High efficiency video coding (HEVC) text specification draft 7”, cited above, that is independent of decoder capability level and therefore not included in the table above. For example, the minimum tile width is 384 pixels, independent of the level.

However, as recognized by the present inventor, a limitation with defining tile size restrictions in this way is that it does not allow for encoder/bitstream flexibility in terms of the number of tiles it can send to a decoder claiming support for a certain capability level. For example, suppose there is a decoder that can decode level 4 (1080×1280 pixels). It is expected that this decoder would also be able to handle the same number of tiles (as per level 4 performance) for a lower resolution. However, “High efficiency video coding (HEVC) text specification draft 7”, as cited above, does not allow for the encoder to send the same number of tiles for all resolutions. For example, with the current minimum tile width of 384, the encoder can send 1920/384=5 horizontal tiles at 1080×1920 resolution but only 3 horizontal tiles at 1280×720 resolution to the same level 4 capable decoder. It should be noted that the terms “horizontal tiles” and “vertical tiles” are used, “tile rows” and “tile columns” could also be used.

To solve this problem, to the present disclosure allows for the decoder to also specify its capability in terms of tile processing, such as maximum number of tiles vertically and maximum number of tiles horizontally.

This can be done by augmenting the table above with maximum numbers of tiles horizontally and vertically for each level. An advantage of augmenting the table with decoder tile number capability is that allows a decoder to more clearly make known how many tiles it can support. As a consequence, the encoder can send bitstreams at different resolutions but with the same number of tiles to a decoder claiming support to a certain decoder capability level. As a concrete example, suppose a decoder can support level 4 (1920 horizontal pixels by 1080 vertical pixels) and suppose level 4 (as per the augmented table) corresponds to a maximum of 5×5 tiles. Since the decoder has implicitly announced support for 5×5 tiles, through claiming support for level 4, an encoder can send a bitstream having 5×5 tiles at any resolution lower than 1080×1920.

An additional benefit of adding two new columns to the table, is that it is possible for the decoder through external signaling to announce that it can handle more tiles than given by the capability level it claims support for. For example, a decoder can announce that it conforms to level 3.1 (1280×720), but it can additionally support the number of tiles corresponding to, for instance, level 6.2. An example revised table is shown below, where CPB is coded picture buffer; and DPB is decoded picture buffer.

	Max luma	Max luma
	sample rate	picture size	Max bit				Max	Max
	MaxLumaPR	MaxLumaFS	rate MaxBR			Max CPB size	Vert.	Horiz
Level	(samples/sec)	(samples)	(1000 bits/s)	MinCR	MaxDpbSize	(1000 bits)	Tiles	Tiles
1	552,960	36,864	128	2	6	350	2	2
2	3,686,400	122,880	1,000	2	6	1,000	2	2
3	13,762,560	458,752	5,000	2	6	5,000	3	3
3.1	33,177,600	983,040	9,000	2	6	9,000	3	3
4	62,668,800	2,088,960	15,000	4	6	15,000	4	5
4.1	62,668,800	2,088,960	30,000	4	6	30,000	4	5
4.2	133,693,440	2,228,224	30,000	4	6	30,000	5	5
4.3	133,693,440	2,228,224	50,000	4	6	50,000	5	5
5	267,386,880	8,912,896	50,000	6	6	50,000	6	6
5.1	267,386,880	8,912,896	100,000	8	6	100,000	6	6
5.2	534,773,760	8,912,896	150,000	8	6	150,000	6	6
6	1,002,700,800	33,423,360	300,000	8	6	300,000	8	8
6.1	2,005,401,600	33,423,360	500,000	8	6	500,000	8	8
6.2	4,010,803,200	33,423,360	800,000	6	6	800,000	8	8

The encoder may know in advance the maximum number of vertical and horizontal tiles that a particular decoder can process. However, the decoder may also inform the encoder of its capability in advance of the encoder sending the bit stream. Once again, by allowing the decoder to inform the encoder in advance (either through signaling, or as a preregistered value known to the encoder), the encoder can send the same number of tiles, independent of the resolution of the image.

FIG. 7 illustrates a computer system 1201 upon which an embodiment of the present invention may be implemented. The computer system 1201 may be programmed to implement a computer based video conferencing endpoint that includes a video encoder or decoder for processing real time video images. The computer system 1201 includes a bus 1202 or other communication mechanism for communicating information, and a processor 1203 coupled with the bus 1202 for processing the information. While the figure shows a signal block 1203 for a processor, it should be understood that the processors 1203 represent a plurality of processing cores, each of which can perform separate Tile The computer system 1201 also includes a main memory 1204, such as a random access memory (RAM) or other dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), and synchronous DRAM (SDRAM)), coupled to the bus 1202 for storing information and instructions to be executed by processor 1203. In addition, the main memory 1204 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processor 1203. The computer system 1201 further includes a read only memory (ROM) 1205 or other static storage device (e.g., programmable ROM (PROM), erasable PROM (EPROM), and electrically erasable PROM (EEPROM)) coupled to the bus 1202 for storing static information and instructions for the processor 1203.

The computer system 1201 also includes a disk controller 1206 coupled to the bus 1202 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 1207, and a removable media drive 1208 (e.g., floppy disk drive, read-only compact disc drive, read/write compact disc drive, compact disc jukebox, tape drive, and removable magneto-optical drive). The storage devices may be added to the computer system 1201 using an appropriate device interface (e.g., small computer system interface (SCSI), integrated device electronics (IDE), enhanced-IDE (E-IDE), direct memory access (DMA), or ultra-DMA).

The computer system 1201 may also include special purpose logic devices (e.g., application specific integrated circuits (ASICs)) or configurable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), that, in addition to microprocessors and digital signal processors may individually, or collectively, are types of processing circuitry. The processing circuitry may be located in one device or distributed across multiple devices.

The computer system 1201 may also include a display controller 1209 coupled to the bus 1202 to control a display 1210, such as a cathode ray tube (CRT), for displaying information to a computer user. The computer system includes input devices, such as a keyboard 1211 and a pointing device 1212, for interacting with a computer user and providing information to the processor 1203. The pointing device 1212, for example, may be a mouse, a trackball, or a pointing stick for communicating direction information and command selections to the processor 1203 and for controlling cursor movement on the display 1210. In addition, a printer may provide printed listings of data stored and/or generated by the computer system 1201.

The computer system 1201 performs a portion or all of the processing steps of the invention in response to the processor 1203 executing one or more sequences of one or more instructions contained in a memory, such as the main memory 1204. Such instructions may be read into the main memory 1204 from another computer readable medium, such as a hard disk 1207 or a removable media drive 1208. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 1204. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

As stated above, the computer system 1201 includes at least one computer readable medium or memory for holding instructions programmed according to the teachings of the invention and for containing data structures, tables, records, or other data described herein. Examples of computer readable media are compact discs, hard disks, floppy disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, flash EPROM), DRAM, SRAM, SDRAM, or any other magnetic medium, compact discs (e.g., CD-ROM), or any other optical medium, punch cards, paper tape, or other physical medium with patterns of holes, a carrier wave (described below), or any other medium from which a computer can read.

Stored on any one or on a combination of computer readable media, the present invention includes software for controlling the computer system 1201, for driving a device or devices for implementing the invention, and for enabling the computer system 1201 to interact with a human user (e.g., print production personnel). Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software. Such computer readable media further includes the computer program product of the present invention for performing all or a portion (if processing is distributed) of the processing performed in implementing the invention.

The computer code devices of the present invention may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs. Moreover, parts of the processing of the present invention may be distributed for better performance, reliability, and/or cost.

The term “computer readable medium” as used herein refers to any medium that participates in providing instructions to the processor 1203 for execution. A computer readable medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks, such as the hard disk 1207 or the removable media drive 1208. Volatile media includes dynamic memory, such as the main memory 1204. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that make up the bus 1202. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Various forms of computer readable media may be involved in carrying out one or more sequences of one or more instructions to processor 1203 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions for implementing all or a portion of the present invention remotely into a dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1201 may receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to the bus 1202 can receive the data carried in the infrared signal and place the data on the bus 1202. The bus 1202 carries the data to the main memory 1204, from which the processor 1203 retrieves and executes the instructions. The instructions received by the main memory 1204 may optionally be stored on storage device 1207 or 1208 either before or after execution by processor 1203.

The computer system 1201 also includes a communication interface 1213 coupled to the bus 1202. The communication interface 1213 provides a two-way data communication coupling to a network link 1214 that is connected to, for example, a local area network (LAN) 1215, or to another communications network 1216 such as the Internet. For example, the communication interface 1213 may be a network interface card to attach to any packet switched LAN. As another example, the communication interface 1213 may be an asymmetrical digital subscriber line (ADSL) card, an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of communications line. Wireless links may also be implemented. In any such implementation, the communication interface 1213 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

The network link 1214 typically provides data communication through one or more networks to other data devices. For example, the network link 1214 may provide a connection to another computer through a local network 1215 (e.g., a LAN) or through equipment operated by a service provider, which provides communication services through a communications network 1216. The local network 1214 and the communications network 1216 use, for example, electrical, electromagnetic, or optical signals that carry digital data streams, and the associated physical layer (e.g., CAT 5 cable, coaxial cable, optical fiber, etc). The signals through the various networks and the signals on the network link 1214 and through the communication interface 1213, which carry the digital data to and from the computer system 1201 maybe implemented in baseband signals, or carrier wave based signals. The baseband signals convey the digital data as unmodulated electrical pulses that are descriptive of a stream of digital data bits, where the term “bits” is to be construed broadly to mean symbol, where each symbol conveys at least one or more information bits. The digital data may also be used to modulate a carrier wave, such as with amplitude, phase and/or frequency shift keyed signals that are propagated over a conductive media, or transmitted as electromagnetic waves through a propagation medium. Thus, the digital data may be sent as unmodulated baseband data through a “wired” communication channel and/or sent within a predetermined frequency band, different than baseband, by modulating a carrier wave. The computer system 1201 can transmit and receive data, including program code, through the network(s) 1215 and 1216, the network link 1214 and the communication interface 1213. Moreover, the network link 1214 may provide a connection through a LAN 1215 to a mobile device 1217 such as a personal digital assistant (PDA) laptop computer, or cellular telephone.

The term “a” or “the” as used herein should not be construed a being limited to a singular element, but may also used in the context of a pluarlity of elements.

Obviously, numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Claims

1. A video decoder, comprising:

an interface configured to receive a bit stream in tile order within a video frame that was encoded into rectangular tiles; and

processing circuitry configured to decode the video frame while respecting dependency breaks at tile boundaries, wherein

the rectangular tiles including an integer number of two-dimensional blocks of pixels,

a tile shape of each of the rectangular tiles being defined by N×M two-dimensional blocks of pixels,

respective values of N and M need not be identical for each of the rectangular tiles, and

information regarding tile shape being conveyed from an encoder to the decoder, the decoder configured to determine the values of N and M for each tile from the information, the rectangular tiles having dependency breaks therebetween;

wherein the processing circuitry is configured to process a maximum number of horizontal tiles and a maximum number of vertical tiles independent of a resolution of video frames, wherein the resolution of the video frames is determined by a width of the video frames and a height of the video frames.

2. The video decoder of claim 1, wherein

the processing circuitry is configured to support decoding according to level 3.1 of the High Efficiency video Coding (HEVC) standard, wherein the maximum number of vertical tiles of 3 and the maximum number of horizontal tiles of 3.

3. The video decoder of claim 2, wherein,

the processing circuitry is configured to support a maximum picture size of 983,040 samples.

4. The video decoder of claim 1, wherein

the maximum number of horizontal tiles is 5.

5. The video decoder of claim 4, wherein

the processing circuitry is configured to support level decoding according to level 4 and level 4.1 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

6. The video decoder of claim 4, wherein

the processing circuitry is configured to support a maximum bit rate of 30,000 (1000 bits/sec) and 5 vertical tiles.

7. The video decoder of claim 4, wherein

the processing circuitry is configured to support a maximum bit rate of 50,000 (1000 bits/sec) and 5 vertical tiles.

8. The video decoder of claim 1, wherein

the processing circuitry supports decoding according to level 2 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

9. The video decoder of claim 1, wherein

the processing circuitry supports decoding according to level 3 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

10. The video decoder of claim 9, wherein

the processing circuitry processes the associated maximum number of vertical tiles and maximum number of horizontal tiles independent of the resolution of the video frames.

11. The video decoder of claim 1, wherein

the processing circuitry supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 5, level 5.1, and level 5.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

12. The video decoder of claim 1, wherein

the processing circuitry supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 6, level 6.1, and level 6.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

13. A video decoding method, comprising:

receiving a bit stream in tile order within a video frame that was encoded into rectangular tiles;

preparing to process a maximum number of horizontal tiles and a maximum number of vertical tiles independent of a resolution of video frames, wherein the resolution of the video frames is determined by a width of the video frames and a height of the video frames, wherein the maximum number of horizontal tiles and the maximum number of vertical tiles are known to an encoder in advance either by the encoder having a preregistered indication of tiles, or by a decoder informing the encoder in advance; and

decoding with processing circuitry at least part of the video frame while respecting dependency breaks at tile boundaries, wherein

the rectangular tiles including an integer number of two-dimensional blocks of pixels,

a tile shape of the rectangular tiles being defined by N×M two-dimensional blocks of pixels,

respective values of N and M need not be identical for each of the rectangular tiles,

the receiving an indication including receiving information regarding tile size, and the decoding including determining the values of N and M for each tile from the information,

the rectangular tiles having dependency breaks therebetween.

14. The video decoding method of claim 13, wherein

the decoding is compliant with level 3.1 of the High Efficiency video Coding (HEVC) standard, and wherein the maximum number of vertical tiles is 3 and the maximum number of horizontal tiles is 3.

15. The video decoding method of claim 14, wherein

the decoding supports a maximum picture size of 983,040 samples.

16. The video decoding method of claim 13, wherein

the maximum number of horizontal tiles is 5.

17. The video decoding method of claim 16, wherein

the decoding is compliant with level 4 and level 4.1 of the High Efficiency video Coding (HEVC) standard.

18. The video decoding method of claim 16, wherein

the decoding supports a maximum bit rate of 30,000 (1000 bits/sec) and 5 vertical tiles.

19. The video decoding method of claim 16, wherein

the decoding supports a maximum bit rate of 50,000 (1000 bits/sec) and 5 vertical tiles.

20. The video decoding method of claim 13, wherein

the decoding supports decoding according to level 2 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

21. The video decoding method of claim 13, wherein

the decoding supports decoding according to level 3 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

22. The video decoding method of claim 13, wherein

the decoding supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 5, level 5.1, and level 5.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

23. The video decoding method of claim 13, wherein

the decoding supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 6, level 6.1, and level 6.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

24. A non-transitory computer program product embodied with a computer program that when executed by processing circuitry implements a method, the method comprising:

receiving a bit stream in tile order within a video frame that was encoded into rectangular tiles;

preparing to process a maximum number of horizontal tiles and a maximum number of vertical tiles independent of a resolution of video frames, wherein the resolution of the video frames is determined by a width of the video frames and a height of the video frames, wherein the maximum number of horizontal tiles and the maximum number of vertical tiles are known to an encoder in advance either by the encoder having a preregistered indication of maximum number of horizontal and vertical tiles, or by the decoder informing the encoder in advance; and

decoding with the processing circuitry at least part of the video frame while respecting dependency breaks at tile boundaries, wherein

the rectangular tiles including an integer number of two-dimensional blocks of pixels,

a tile shape of the rectangular tiles being defined by N×M two-dimensional blocks of pixels,

respective values of N and M need not be identical for each of the rectangular tiles,

the receiving an indication including receiving information regarding tile size, and the decoding including determining the values of N and M for each tile from the information, the rectangular tiles having dependency breaks therebetween.

25. The non-transitory computer program product of claim 24, wherein

the decoding is compliant with level 3 of the High Efficiency video Coding (HEVC) standard, and wherein the maximum number of vertical tiles of 3 and the maximum number of horizontal tiles of 3.

26. The non-transitory computer program product of claim 25, wherein,

the decoding supports a maximum picture size of 983,040 samples.

27. The non-transitory computer program product of claim 24, wherein

the decoding supports a maximum number of horizontal tiles of 5.

28. The non-transitory computer program product of claim 26, wherein

the decoding is compliant with level 4 and level 4.1 of the High Efficiency video Coding (HEVC) standard.

29. The non-transitory computer program product of claim 26, wherein

the decoding supports a maximum bit rate of 30,000 (1000 bits/sec) and 5 vertical tiles.

30. The non-transitory computer program product of claim 24, wherein

the decoding supports decoding according to level 2 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

31. The non-transitory computer program product of claim 24, wherein

the decoding supports decoding according to level 3 of the High Efficiency video Coding (HEVC) standard, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

32. The non-transitory computer program product of claim 24, wherein

the decoding supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 5, level 5.1, and level 5.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.

33. The non-transitory computer program product of claim 24, wherein

the decoding supports decoding according to the High Efficiency video Coding (HEVC) standard of at least one of level 6 , level 6.1, and level 6.2, with an associated maximum number of vertical tiles and maximum number of horizontal tiles.