Low-latency image coding

Abstract

To provide parallel processing concepts such as wavefront parallel processing (WPP).SOLUTION: A reduced end-to-end delay is achieved by giving up following the usual slice concept according to which slices 14 are either coded / decoded completely independently of areas of the picture outside of the respective slices, or coded / decoded at least independently of areas outside of the respective slices as far as the entropy coding is concerned, in favor of slices of different modes, namely, normal slices and slices which allow interdependence across slice boundaries. Combined with the presence or absence of the aspect, a WPP processing concept is made more efficiently by using slices' start syntax portions to locate WPP entry points.SELECTED DRAWING: Figure 24

Description

[Technical field]

[0001] The present invention relates to low-delay coding of images. [Background technology]

[0002] In the current HEVC design slices, Entropy Slice (formerly Lightweight Slice) tiles and WPP (Wavefront Parallel Processing) are included as tools for parallelization.

[0003] For parallelization of video encoders and decoders, picture-level partitioning has several advantages compared to other approaches. In traditional video codecs, such as H.264 / AVC [1], picture partitioning was only possible for regular slices, which have a high cost in terms of coding efficiency. For scalable parallel H.264 / AVC decoding, it is necessary to combine macroblock-level parallelism for picture reconstruction and frame-level parallelism for entropy decoding. However, this approach results in limited reduction in picture latency and high memory usage. To overcome these limitations, new picture partitioning strategies are included in the HEVC codec. The current reference software version (HM-6) includes four different approaches: regular or normal slices, entropy slices, wavefront parallel processing (WPP) substreams and tiles. Typically, those picture partitions include a set of largest coding units (LCUs) or, synonymously, coding tree units (CTUs), as defined in HEVC or a subset thereof.

[0004] 1 shows an image 898 in which every row 902 of LCUs or macroblocks in the image is exemplarily arranged into a regular slice 900. Regular or normal slices (as defined in H.264[1]) have the largest coding penalty, as they destroy entropy decoding and prediction dependencies. Entropy slicing, like slicing, breaks the entropy decoding dependency, but allows prediction (and filtering) to cross slice boundaries.

[0005] In WPP, image partitions are row interleaved, and both entropy decoding and prediction are enabled to use data from blocks in other partitions. In this way, coding loss is minimized while at the same time taking advantage of wavefront parallelism. However, interleaving disrupts bitstream causality, such that a conventional partition requires the next partition to be decoded.

[0006] 2 exemplarily illustrates an image 898 divided into two rows 904a, 904b of tiles 906 that partition horizontally. The tiles define horizontal 908 and vertical boundaries 910 that partition the image 898 into tile columns 912a, b, c and rows 904a, b. Similar to regular slices 900, tiles 906 break entropy decoding and prediction dependencies but do not require a header for each tile.

[0007] For each of these techniques, the number of partitions can be freely chosen by the encoder. In general, having more partitions leads to higher compression loss. However, in WPP, the loss propagation is not so high, and therefore the number of image partitions can even be fixed at one per row. This also brings several advantages. First, for WPP, bitstream causality is guaranteed. Second, the decoder implementation can assume that a certain amount of parallelism is available, which also increases with resolution. Furthermore, and finally, neither context selection nor prediction dependency needs to be broken when decoding in wavefront order, leading to relatively low coding loss.

[0008] However, up to now, the all-parallel coding in transform concept cannot provide high compression efficiency while keeping the delay low. This is also true for the WPP concept: a slice is the smallest unit of transfer in the coding pipeline, and furthermore, several WPP substreams still have to be transferred consecutively. Summary of the Invention [Problem to be solved by the invention]

[0009] It is therefore an object of the present invention to provide an image coding concept which allows for parallel decoding with increased efficiency, e.g. by further reducing the end-to-end delay or by increasing the coding efficiency by reducing the coding overhead consumed, e.g. according to wavefront parallelism. [Means for solving the problem]

[0010] This object is achieved by the subject matter of the independent claims.

[0011] The basic insight of the present invention is that if the normal slice concept, in which slices are coded / decoded completely independently of the regions of the image outside the respective slice, or at least as far as entropy coding is concerned, is abandoned in favor of different modes of slices, i.e., some called dependent slices that allow mutual dependencies across slice boundaries and others called normal slices that do not, then parallel processing concepts such as wavefront parallel processing can be realized with reduced end-to-end delay.

[0012] A further fundamental finding of the present invention, which can be combined with the first one or used individually, is that the WPP processing concept can be made more efficient if the starting syntax part of a slice is used to locate the WPP entry point.

[0013] Preferred embodiments of the present application are described below with reference to the figures, advantageous embodiments are the subject matter of the dependent claims. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 shows an image that is exemplary partitioned into regular slices by rows of LCUs or macroblocks in the image. [Diagram 2] FIG. 2 shows an image exemplarily divided into two rows of horizontally partitioned tiles. [Diagram 3] FIG. 3 exemplarily illustrates the allocation of parallel encoded partitions to slices or network transport segments. [Figure 4] FIG. 4 shows a schematic diagram illustrating a general fragmentation of a frame in a tile coding approach for minimum end-to-end delay. [Diagram 5] FIG. 5 shows a schematic diagram illustrating an exemplary fragmentation of a frame in a WPP encoding approach for minimum end-to-end delay. [Figure 6]FIG. 6 shows a schematic block diagram illustrating a conversation scenario using video services. [Figure 7] FIG. 7 illustrates diagrammatically a possible time scheduling of encoding, transmission and decoding for tiles with a common subset with minimum end-to-end delay. [Figure 8] FIG. 8 shows a schematic timing schedule for achieving a common end-to-end delay. [Figure 9] FIG. 9 shows an image with an exemplary 11×9 coding tree block partitioned into two slices. [Figure 10] FIG. 10 shows an image with an exemplary 13×8 coding tree block partitioned into three tiles. [Figure 11a] FIG. 11a shows an example for the sequence parameter set syntax. [Figure 11b] FIG. 11b shows an example for the sequence parameter set syntax. [Figure 11c] FIG. 11c shows an example for the sequence parameter set syntax. [Figure 12a] FIG. 12a shows an example for an image parameter set syntax. [Figure 12b] FIG. 12b shows an example for the image parameter set syntax. [Figure 13a] FIG. 13a shows an example for a slice header syntax. [Figure 13b] FIG. 13b shows an example for slice header syntax. [Figure 13c] FIG. 13c shows an example for slice header syntax. [Figure 14] FIG. 14 illustrates partitioning of an image for WPP processing on regular slices and for low latency processing on dependent slices. [Figure 15] FIG. 15 shows examples for portions within the image parameter set syntax. [Figure 16] FIG. 16 shows a possible slice header syntax. [Figure 17] FIG. 17 illustrates a schematic of the coding interdependencies for normal slices (and dependent slices). [Figure 18] FIG. 18 shows a schematic diagram comparing coding for low-latency transmission of tiles (wavefront parallel processing with dependent slices). [Figure 19] FIG. 19 shows a timing schedule illustrating an exemplary WPP encoding with pipelined low-latency transmission when using wavefront parallel processing with dependent slices as shown on the right side of FIG. [Figure 20] FIG. 20 shows a schematic diagram illustrating the robustness improvement by using regular slices as anchors. [Figure 21] FIG. 21 shows another embodiment for the slice header syntax. [Figure 22] FIG. 22 illustrates another embodiment for an image parameter set syntax. [Diagram 23] FIG. 23 shows a schematic diagram illustrating the symbol probability initialization process for dependent slices when starting at the left image border. [Figure 24] FIG. 24 shows a schematic diagram of a decoder. [Diagram 25] FIG. 25 illustrates a schematic partitioning of an image into coding blocks and slices, as well as a schematic block diagram of a decoder. [Figure 26] FIG. 26 shows a schematic block diagram of an encoder. [Figure 27] FIG. 27 illustrates diagrammatically an image that is partitioned into normal and dependent slices, referred to herein as slice segments. [Figure 28] 28a and 28b show diagrammatically an image partitioned into normal and subordinate slices, here called slice segments on the one hand and tiles on the other hand. [Figure 29] FIG. 29 shows a flow diagram illustrating the context initialization process with dependent slices. [Diagram 30]FIG. 30 shows a flow diagram illustrating the context storage process for using dependent slices. [Diagram 31] FIG. 31 shows a schematic of the various possibilities for signaling the WPP entry point. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] In the following, the description starts with a description of the current concepts for enabling parallel image processing and low-delay coding, respectively. The problems that arise when one wishes to have both capabilities are outlined. In particular, as can be seen from the following description, the WPP substream concept as somehow taught so far contradicts the desire to have low delay due to the need to convey the WPP substream by grouping it into one slice. The following embodiment represents a parallel processing concept, such as the WPP concept, that can be applied to applications that require even less delay by extending the slice concept, i.e. by introducing another type of slice, later called dependent slice.

[0016] Minimizing the end-to-end video delay, from capturing to display, is one of the primary objectives, for example in applications such as video conferencing.

[0017] The signal processing chain for digital video transmission consists of a camera, a capturing device, an encoder, an encapsulator, a transmitter, a demultiplexer, a decoder, a renderer, and a display. Each of these stages contributes to the end-to-end delay by buffering the image data before its serial transmission to the later stage.

[0018] Some applications require minimization of such delays, for example remote manipulation of objects in hazardous areas without direct view of the manipulated object, or minimally invasive surgery. Even short delays can result in serious problems with proper operation or even serious mistakes.

[0019] Often, entire video frames are buffered within a processing stage, for example to allow intra-frame processing. Some stages collect data to form packets that are sent to the next stage. In general, there is a lower bound for the delay resulting from local processing requirements. This is analyzed for each individual stage in more detail below.

[0020] Processing within the camera does not necessarily require intraframe signal processing, as the minimum delay is given by the integration time of the sensor, which is limited by the frame rate, and some design choices made by the hardware manufacturer. The camera output is typically associated with a scan order, where processing usually starts in the upper left corner, moves to the upper right corner, and continues line by line to the lower right corner. As a result, it takes approximately one frame period for all data to be transferred from the sensor to the camera output.

[0021] Although the capturing device can send the camera data immediately after receiving it, it typically buffers some data and also generates bursts to optimize data access to memory or storage. Furthermore, the connection between the camera / capture and the computer memory typically limits the bit rate for sending the captured image data to the memory for further processing (encoding). Typically, the camera is connected via USB 2.0 or immediately USB 3.0, which always includes a partial transfer of the image data to the encoder. This limits the parallelization capabilities on the encoder side in extreme low latency scenarios, i.e. the encoder tries to start encoding as soon as possible when the data becomes available from the camera in a raster scan order, for example from the top to the bottom of the image.

[0022] In the encoder there is a degree of freedom that allows one to trade off coding efficiency for reduced processing delay with respect to the data rate required for a particular video fidelity.

[0023] The encoder uses data already sent to predict the image to be coded later. In general, the difference between the actual image and the prediction can be coded with fewer bits than would be required without the prediction. This prediction must be made available to the decoder, and thus the prediction is based on previously decoded parts of the same image (intra-frame prediction) or other previously processed images (inter-frame prediction). Pre-HEVC video coding standards only use parts of the image above or in the same line but to the left, that have been previously coded, for intra-frame prediction, motion vector prediction and entropy coding (CABAC).

[0024] In addition to optimizing the prediction structure, the impact of parallel processing can be considered. Parallel processing requires the identification of image regions that can be processed independently. For practical reasons, contiguous regions, e.g. horizontal or vertical rectangles, are chosen, which are often called "tiles". In the case of low latency constraints, these regions should allow parallel coding of data entering the memory from capture as soon as possible. Assuming a raster scan memory transfer, a vertical partition of the raw data makes sense to start coding immediately. Splitting the image into vertical partitions (see figure below), inside such tiles, intra prediction, motion vector prediction and entropy coding (CABAC) can result in considerable coding efficiency. To minimize latency, starting from the top, only parts of the image are transferred to the encoder's frame memory, and further, parallel processing should start in the vertical tiles.

[0025] Another way to enable parallel processing is to use WPP within regular slices compared to tiles, where a "row" of tiles is contained in a single slice. Data within a slice can be coded in parallel using WPP substreams within the slice. Image separation into slices 900 and tiles / WPP substreams 914 is shown in the form of an example FIG. 3 / FIG. 1.

[0026] Thus, FIG. 3 illustrates the allocation of parallel encoded partitions, such as 906 or 914, to slices or network transport segments (single network packets or multiple network 900 packets).

[0027] The encapsulation of the coded data into Network Abstraction Layer (NAL) units, as defined in H.264 or HEVC, if applicable, adds several headers to the data blocks before transmission or during the coding process, which allow the identification of each block and the reordering of the blocks. In the case of the standard, no additional signaling is required since the order of the coding elements is always the decoding order, which is given an implicit assignment of the positions of tiles or generic coding fragments.

[0028] If parallelism is taken into account with an additional transport layer for low-latency parallel transmission, i.e., the transport layer can reorder the image partitions for tiles to enable low-latency transmission, which means sending the fragments as they are encoded as shown in Figure 4. Those fragments may be completely unencoded slices, they may be subsets of slices, or they may be included in dependent slices.

[0029] When creating additional fragments, there is a tradeoff between efficiency, which is highest for large data blocks due to the header information adding a certain number of bytes, and delay due to the large data blocks of the parallel encoder needing to be buffered before transmission. The overall delay can be reduced if the coded representation of a vertical tile 906 is separated into multiple fragments 916 that are transmitted as soon as the fragment is fully coded. The size of each fragment can be determined in terms of a fixed image area, e.g., a macroblock, LCU, etc., or in terms of a maximum data as shown in FIG. 4.

[0030] Thus, FIG. 4 shows a general fragmentation of a frame in a tile coding approach for minimum end-to-end delay.

[0031] Similarly, FIG. 5 illustrates frame fragmentation in the WPP encoding approach for minimum end-to-end delay.

[0032] The transmission may add further delays, for example when additional block-oriented processing is applied, such as forward error correction codes to increase the robustness of the transmission. Also, the network infrastructure (such as routers) or physical links may add delays, which are typically known as the latency for the connection. In addition to the latency, the transmission bit rate determines the time (latency) to transfer data from participant a to participant b in a conversation as shown in FIG. 6 using video services.

[0033] If encoded data blocks are transmitted out of order, delay reordering must be taken into account: decoding can start as soon as a data unit arrives, assuming that other data units that have to be decoded before this one are available.

[0034] In the case of tiles, there is no dependency between tiles, so tiles can be decoded immediately. If fragments are made of tiles, such as a separate slice for each fragment as shown in FIG. 4, the fragments can be forwarded directly as soon as they are each coded and their contained LCUs or CUs are coded.

[0035] The renderer assembles the output of the parallel decoding engines and then sends the combined image line-by-line to the display.

[0036] The display does not necessarily add any delay, but may in fact do some intra-frame processing before the image data is actually displayed - this is up to the design choice made by the hardware manufacturer.

[0037] In summary, we can affect the stages encoding, encapsulation, transmission and decoding to achieve the minimum end-to-end delay. If we use parallel processing, tiles and fragmentation within tiles, the overall delay can be significantly reduced as shown in Figure 7, compared to commonly used processing chains that add about one frame delay at each of these stages as shown in Figure 8.

[0038] In particular, FIG. 7 shows the encoding, transmission and decoding for tiles with a generic subset with minimum end-to-end delay, while FIG. 8 shows the commonly achieved end-to-end delay.

[0039] HEVC further enables the use of slice partitioning, tile partitioning in the following ways:

[0040] Tile: An integer number of treeblocks occurring together in a column and a row, which are ordered consecutively in a treeblock raster scan of the tile. The division of each image into tiles is a partition division. In an image, tiles are ordered consecutively in a tile raster scan of the image. Even though a slice contains treeblocks that are consecutive in a treeblock raster scan of the tile, these treeblocks are not necessarily consecutive in a treeblock raster scan of the image.

[0041] Slice: An integer number of tree blocks ordered consecutively in a raster scan. The division of each image into slices is a partition division. Tree block addresses are derived from the address of the first tree block in the slice (as represented in the slice header).

[0042] Raster Scan: The mapping of a rectangular two-dimensional pattern onto a one-dimensional pattern such that the first entry in the one-dimensional pattern is the first row at the top of the two-dimensional pattern scanned from left to right, followed similarly by the second, third, etc. rows of the pattern, each scanned left to right (down).

[0043] Treeblock: An NxN block of luma samples and two corresponding blocks of chroma samples for an image with three sample arrays, or an NxN block of samples for a monochrome image or an image that is coded with three separate color planes. The division of a slice into treeblocks is a partition division.

[0044] Partitioning: The division of a set into subsets such that each element of the set is in exactly one of the subsets.

[0045] Quadtree: A tree in which a parent node can be split into four child nodes, and a child node can become a parent node for another split into four child nodes.

[0046] In the following, spatial subdivision of images, slices and tiles is described. In particular, the following description specifies how an image is partitioned into slices, tiles and coding tree blocks. An image is divided into slices and tiles. A slice is a sequence of coding tree blocks. Similarly, a tile is a sequence of coding tree blocks.

[0047] Samples are processed in units of coding treeblocks. The luma array size per treeblock in samples, both width and height, is CtbSize. The width and height of the chroma array per coding treeblock are CtbWidthC and CtbHeightC, respectively. For example, an image may be divided into two slices as shown in the following figure. As another example, an image may be divided into three tiles as shown in the second following figure.

[0048] Unlike slices, tiles are always rectangular and always contain an integer number of coding tree blocks in a coding tree block raster scan. A tile may consist of coding tree blocks contained in more than one slice. Similarly, a slice may consist of coding tree blocks contained in more than one tile.

[0049] FIG. 9 shows an image 898 having an 11×9 coding tree block 918 that is partitioned into two slices 900 a,b.

[0050] FIG. 10 shows an image with a 13×8 coding tree block 918 that is partitioned into three tiles.

[0051] Each coding 898 tree block 918 is assigned a partition signaling to identify the block size for intra or inter prediction and for transform coding. The partitioning is a recursive quad-tree partitioning. The root of the quad-tree is associated with the coding tree block. The quad-tree is split until a leaf is reached, which is called a coding block. The coding block is the root node of two trees, the prediction tree and the transform tree.

[0052] The prediction tree specifies the location and size of the prediction block. A prediction block and associated prediction data is called a prediction unit.

[0053] FIG. 11 illustrates an example sequence parameter set RBSP syntax.

[0054] The transform tree specifies the location and size of the transform blocks. A transform block and its associated transform data are called a transform unit.

[0055] The split information for luma and chroma is the same as the prediction tree, and may or may not be the same as the transform tree.

[0056] A coding block, its associated coded data, and its associated prediction and transform units together form a coding unit.

[0057] The process for conversion of coding tree block addresses in coding tree block raster order to tile scan order may be as follows: The output of this process is - an array CtbAddrTS[ctbAddrRS] with ctbAddrRS in the range from 0 to PicHeightInCtbs*PicWidthInCtbs-1; - An array TileId[ctbAddrTS] with ctbAddrTS in the range 0 to PicHeightInCtbs*PicWidthInCtbs-1. The array CtbAddrTS[] is derived as follows: TIFF0007640795000001.tif62153

[0058] The array TileId[] is derived as follows: TIFF0007640795000002.tif30153

[0059] Corresponding, example syntax is shown in Figures 11, 12 and 13, where Figure 12 has an example picture parameter set RBSP syntax, and Figure 13 shows an example slice header syntax.

[0060] In the syntax examples, the following semantics may apply:

[0061] entropy_slice_flag equal to 1 specifies that the value of the absent slice header syntax element is inferred to be equal to the value of the slice header syntax element in the proceeding slice, where the proceeding slice is defined as the slice that contains a coding tree block having position (SliceCtbAddrRS-1). entropy_slice_flag is equal to 0 when SliceCtbAddrRS is equal to 0.

[0062] tiles_or_entropy_coding_sync_idc equal to 0 specifies that there is only one tile in each image in the coded video sequence, and furthermore, no specific synchronization process for the context variables is invoked before decoding the first coding tree block in a row of coding tree blocks.

[0063] tiles_or_entropy_coding_sync_idc equal to 1 specifies that there may be more than one tile in each image in the coded video sequence, and furthermore, no specific synchronization process for the context variables is invoked before decoding the first coding tree block of a row of coding tree blocks.

[0064] tiles_or_entropy_coding_sync_idc equal to 2 specifies that there is only one tile in each image in the coded video sequence, and a specific synchronization process for the context variables is invoked before decoding the first coding tree block in a row of coding tree blocks, and furthermore a specific storage process for the context variables is invoked after decoding two coding tree blocks in a row of coding tree blocks.

[0065] The value of tiles_or_entropy_coding_sync_idc ranges from 0 to 2.

[0066] num_tile_columns_minus1+1 specifies the number of tile columns into which the image should be partitioned.

[0067] num_tile_rows_minus1+1 specifies the number of tile rows to partition the image into. When num_tile_columns_minus1 is equal to 0, num_tile_rows_minus1 is not equal to 0.

[0068] One or both of the following conditions are met for each slice and tile: - All coded blocks in a slice belong to the same tile. - All coded blocks in a tile belong to the same slice.

[0069] NOTE - Within the same image, there may be both slices that contain multiple tiles and tiles that contain multiple slices.

[0070] uniform_spacing_flag equal to 1 specifies that column borders, and similarly row borders, are uniformly distributed across the image. uniform_spacing_flag equal to 0 specifies that column borders, and similarly row borders, are not uniformly distributed across the image, but are explicitly indicated using the syntax elements column_width[i] and row_height[i].

[0071] column_width[i] specifies the width of the i-th tile column in units of coding tree blocks.

[0072] row #where height[i] specifies the height of the ith tile row in units of coding tree blocks. The value of ColumnWidth[i], which specifies the width of the ith tile column in units of coding tree blocks, and ColumnWidthInLumaSamples[i], which specifies the width of the ith tile column in units of luma samples, are derived as follows: TIFF0007640795000003.tif41155

[0073] The value of RowHeight[i], which specifies the height of the i-th tile row in terms of coding treeblocks, is derived as follows: TIFF0007640795000004.tif35159

[0074] The value of ColBd[i], which specifies the left column boundary position of the ith tile column in terms of the coding tree block, is derived as follows: TIFF0007640795000005.tif18159

[0075] The value of RowBd[i], which specifies the top row boundary position of the ith tile row in terms of the coding tree block, is derived as follows: TIFF0007640795000006.tif12116

[0076] num_substreams_minus1+1 specifies the maximum number of subsets included in a slice when tiles_or_entropy_coding_sync_idc is equal to 2. When not present, the value of num_substreams_minus1 is inferred to be equal to 0.

[0077] num_entry_point_offsets specifies the number of entry_point_offset[i] syntax elements in the slice header. When tiles_or_entropy_coding_sync_idc is equal to 1, the value of num_entry_point_offsets ranges from 0 to (num_tile_columns_minus1+1)*(num_tile_rows_minus1+1)-1. When tiles_or_entropy_coding_sync_idc is equal to 2, the value of num_entry_point_offsets ranges from 0 to num_substreams_minus1. When not present, the value of num_entry_point_offsets is inferred to be equal to 0.

[0078] offset_len_minus1+1 specifies the length, in bits, of the entry_point_offset[i] syntax element.

[0079] entry_point_offset[i] specifies the ith entry point offset in bytes and is represented by offset_len_minus1+1 bits. The coded slice NAL unit consists of num_entry_point_offsets+1 subsets with subset index values ​​ranging from 0 to num_entry_point_offsets. Subset 0 consists of bytes 0 to entry_point_offset[0]-1 of the coded slice NAL unit, subset k with k in the range from 1 to num_entry_point_offsets-1 consists of bytes entry_point_offset[k-1] to entry_point_offset[k]+entry_point_offset[k-1]-1 of the coded slice NAL unit, and the last subset (with subset index equal to num_entry_point_offsets) consists of the remaining bytes of the coded slice NAL unit.

[0080] NOTE - The NAL unit header and the slice header of a coded slice NAL unit are always included in subset 0.

[0081] When tiles_or_entropy_coding_sync_idc is equal to 1 and num_entry_point_offsets is greater than 0, each subset contains all coded bits of one or more complete tiles, and the number of subsets is less than or equal to the number of tiles in the slice. When tiles_or_entropy_coding_sync_idc is equal to 2 and num_entry_point_offsets is greater than 0, the subset k includes all bits used during the initialization process for the current bitstream pointer k, for each of all possible k values.

[0082] Regarding slice data semantics, the following may apply:

[0083] An end_of_slice_flag equal to 0 indicates that another macroblock follows in the slice. An end_of_slice_flag equal to 1 indicates the end of the slice, and no further macroblocks follow.

[0084] entry_point_marker_two_3bytes is a fixed-value sequence of three bytes equal to 0x000002. This syntax element is called the entry marker prefix.

[0085] tile_idx_minus_1 specifies the TileID in raster scan order. The first tile in an image has a TileID of 0. Values ​​of tile_idx_minus_1 range from 0 to (num_tile_columns_minus1+1)*(num_tile_rows_minus1+1)-1.

[0086] The CABAC analysis process for slice data may be as follows:

[0087] This process is invoked when parsing a syntax element with a descriptor ae(v).

[0088] The inputs to this process are the value of a syntax element and a request for the value of a conventional parsed syntax element.

[0089] The output of this process is the value of the syntax element.

[0090] The initialization process of the CABAC parsing process is called when starting parsing the slice data of a slice. When tiles_or_entropy_coding_sync_idc is equal to 2 and num_substreams_minus1 is greater than 0, a mapping table BitStreamTable with num_substreams_minus1+1 entries that specify the bitstream pointer table to use for subsequent current bitstream pointer derivation is derived as follows: - BitStreamTable[0] contains the initialized bitstream pointer. - For every index i greater than 0 and less than num_substreams_minus1+1, BitStreamTable[i] contains a bitstream pointer to entry_point_offset[i] bytes after BitStreamTable[i-1]. The current bitstream pointer is set to BitStreamTable[0].

[0091] The minimum coding block address of the coding tree block containing the spatial neighboring block T, ctbMinCbAddrT, is derived using the position (x0, y0) of the top-left luma sample of the current coding tree block, for example, as follows: x=x0+2< <Log2CtbSize-1 y=y0-1 ctbMinCbAddrT=MinCbAddrZS[x>>Log2MinCbSize][y>>Log2MinCbSize]

[0092] The variable availableFlagT is obtained by invoking the appropriate coding block availability derivation process with ctbMinCbAddrT as input. Start parsing the coding tree, and when tiles_or_entropy_coding_sync_idc is equal to 2 and num_substreams_minus1 is greater than 0, the following applies: - If CtbAddrRS%PicWidthInCtbs is equal to 0, the following applies: When availableFlagT is equal to 1, the synchronization process of the CABAC parsing process is invoked as specified in the subclause "Synchronization process for context variables". - The decoding process for binary decisions before termination is called, followed by an initialization process for the arithmetic decoding engine. - The current bitstream pointer is set to point to BitStreamTable[i] with index i, which is derived as follows: i=(CtbAddrRS / PicWidthInCtbs)%(num_substreams_minus1+1) - Otherwise, if CtbAddrRS%PicWidthInCtbs is equal to 2, then the storage process of the CABAC parsing process is invoked as specified in the subclause "Storage Process for Context Variables".

[0093] The initialization process might look like this:

[0094] The output of this process is the initialized CABAC internal variables.

[0095] That special process is invoked when starting to parse slice data for a slice, or when starting to parse data for a coding tree and the coding tree is the first coding tree in a tile.

[0096] The storage process for the context variables can be as follows:

[0097] The input to this process is the CABAC context variables indexed by ctxIdx.

[0098] The output of this process are the variables TableStateSync and TableMPSSync, which contain the values ​​of the variables m and n used in the initialization process of the context variables assigned to the syntax elements except for the end flag of the slice. For each context variable, the corresponding entries n and m in the tables TableStateSync and TableMPSSync are initialized to the corresponding pStateIdx and valMPS.

[0099] The synchronization process for context variables may be as follows:

[0100] The inputs of this process are the variables TableStateSync and TableMPSSync, which contain the values ​​of the variables n and m used in the storage process of the context variables assigned to the syntax elements except for the end flag of the slice.

[0101] The output of this process is a CABAC context variable indexed by ctxIdx.

[0102] For each context variable, the corresponding context variables pStateIdx and valMPS are initialized to the corresponding entries n and m of the tables TableStateSync and TableMPSSync.

[0103] In the following, low-delay encoding and forwarding using WPP is described. In particular, the following description clarifies how low-delay forwarding as described in FIG. 7 can be applied to WPP.

[0104] First of all, it is important that a subset of the image can be sent before the completion of the entire image. Typically, this can be achieved using slices, as already shown in FIG.

[0105] To reduce the delay compared to tiles, it is necessary to apply a single WPP sub-bitstream per row of LCUs and still allow separate transmission of each of those rows, as shown in the figure below. To keep the coding efficiency high, a slice per column / substream cannot be used. Therefore, in the following, a so-called dependent slice is introduced as defined in the next section. This slice has, for example, not all fields of the full HEVC slice header, but the fields used for the entropy slice. Furthermore, there may be a switch to turn off the CABAC breaking between rows. In the case of WPP, the use of CABAC context (arrows in Figure 14) and row prediction is enabled to keep the coding efficiency gain of WPP on tiles.

[0106] In particular, FIG. 14 illustrates an image 10 for WPP to a regular slice 900 (regular SL) and for low latency processing to a dependent slice (DS) 920.

[0107] Currently, the upcoming HEVC standard provides two types of partitioning for slices: regular (normal) slices and entropy slices. Regular slices are completely independent image partitions, except for some dependency that can be exploited to deblock the filter process at slice boundaries. Entropy slices are independent only with respect to entropy coding. The idea of ​​FIG. 14 is to generalize the slicing concept. Thus, the upcoming HEVC standard should provide two general types of slices: independent (regular) or dependent. Therefore, a new type of slice is introduced: dependent slice.

[0108] A dependent slice is a slice that has a dependency on a previous slice, the dependency being specific data available between slices in the entropy decoding process and / or pixel reconstruction process.

[0109] In Fig. 14, the concept of dependent slices is exemplarily shown. An image, for example, always starts with a regular slice. It should be noted that in this concept, the regular slice behavior is slightly modified. Typically, in standards such as H264 / AVC or HEVC, a regular slice is a completely independent partition and does not need to keep any data after decoding, except for some data for deblocking the filter process. However, the processing of this next dependent slice 920 is only possible by referring to the data of the regular slice 900 in the slice mentioned above, here in the first row. To establish it, the regular slice 900 should keep the data of the last CU row. This data is - CABAC encoding engine data (context model state of one CU in which the entropy decoding process of a dependent slice can be initialized); - all decoded syntax elements of a CU for the regular CABAC decoding process of a subordinate CU, - Intra and motion vector prediction data Includes.

[0110] Consequently, each subordinate slice 920 should follow the same procedure, preserving the data for its next subordinate slice in the same image.

[0111] In practice, these additional steps should not be a problem, since the decoding process is generally always forced to store some data such as syntax elements.

[0112] In the following sections, possible changes to the HEVC standard syntax that are needed to enable the concept of dependent slices are presented.

[0113] FIG. 5, for example, shows possible changes in the picture parameter set RBSP syntax.

[0114] The picture parameter set semantics for the dependent slices may be as follows:

[0115] dependent_slices_present_flag equal to 1 specifies that the image contains dependent slices, and furthermore, the decoding process of each (regular or dependent) slice should store the state of entropy decoding and the data of intra and motion vector prediction for the next slice, which may be a dependent slice that may follow a regular slice. The following dependent slices can refer to the stored data.

[0116] FIG. 16 shows a possible slice_header syntax with changes relevant to the current state of HEVC.

[0117] dependent_slice_flag equal to 1 specifies that the value of the absent slice header syntax element is inferred to be equal to the value of the slice header syntax element in a progressive (regular) slice, where a progressive slice is defined as the slice that contains a coding tree block with position (SliceCtbAddrRS-1). dependent_slice_flag is equal to 0 when SliceCtbAddrRS is equal to 0.

[0118] no_cabac_reset_flag equal to 1 specifies CABAC initialization from the saved state of a previously decoded slice (which has no initial value). Otherwise, i.e. equal to 0, it specifies CABAC initialization independent of any state of a previously decoded slice, i.e. having initial values.

[0119] last_ctb_cabac_init_flag equal to 1 specifies CABAC initialization from the saved state of the last coded tree block of the previously decoded slice (e.g. for tiles always equal to 1). Otherwise (equal to 0), the initialization data is referenced from the saved state of the second coded tree block of the last (adjacent) ctb-row of the previously decoded slice if the first coded tree block of the current slice is the first coded tree block in the row (i.e. WPP mode), otherwise the CABAC initialization is preformed from the saved state of the last coded tree block of the previously decoded slice.

[0120] A comparison of dependent slices and other partitioning schemes (information) is provided below.

[0121] In FIG. 17 the difference between normal and dependent slices is shown.

[0122] The possible encoding and transmission of WPP substreams in dependent slices (DS) as shown with respect to FIG. 18 is comparable to the encoding for tiles (left) and WPP / DS (right) low latency transfer. The thick consecutively drawn crosses in FIG. 18 indicate the same point in time for the two methods assuming that encoding a WPP row takes the same time as encoding a single tile. Due to the encoding dependency, only the first row of the WPP is ready after all tiles are encoded. However, with the dependent slice approach, the WPP approach allows sending the first row as soon as it is encoded. This differs from the earlier WPP substream allocation, where a "substream" is defined for WPP as the concatenation of CU rows of slices that are WPP decoded by the same decoder thread, i.e., the same core / processor. However, substreams per row and per entropy slice are also possible before the entropy slice breaks the entropy encoding dependency and therefore has low encoding efficiency, i.e., WPP efficiency gains are lost.

[0123] In addition, the delay difference between both approaches can be made really low, assuming a transmission as shown in Figure 19. In particular, Figure 19 shows WPP encoding with pipelined low-delay transmission.

[0124] Assuming that the encoding of the two CUs after DS#1.1 in the WPP approach in Fig. 18 is not longer than the transmission of the first row SL#1, there is no difference between tile and WPP in the low-delay case. However, the encoding efficiency of WP / DS outperforms the tile concept.

[0125] To increase the robustness for the WPP low latency mode, Fig. 20 shows that robustness improvement is achieved by using a regular slice (RS) as an anchor. In the image shown in Fig. 20, a (regular) slice (RS) is followed by a dependent slice (DS). Here, the (regular) slice acts as an anchor that breaks the dependency on the previous slice, so that more robustness is provided at such an insertion point of the (regular) slice. In principle, this is no different from inserting a (regular) slice anyway.

[0126] The dependent slice concept can also be implemented as follows.

[0127] Here, FIG. 21 shows a possible slice header syntax.

[0128] The slice header semantics are as follows:

[0129] dependent_slice_flag equal to 1 specifies that the value of each absent slice header syntax element is inferred to be equal to the value of the corresponding slice header syntax element in the previous slice containing the coding tree block whose coding tree block address is SliceCtbAddrRS-1. When absent, the value of dependent_slice_flag is inferred to be equal to 0. The value of dependent_slice_flag is equal to 0 when SliceCtbAddrRS is equal to 0.

[0130] slice_address specifies the address in slice granularity resolution where the slice begins. The length of the slice_address syntax element is (Ciel(Log2(PicWidthInCtbs*PicHeightInCtbs))+SliceGranularity) bits.

[0131] The variable SliceCtbAddrRS, which indicates the coding tree block where the slice starts in coding tree block raster scan order, is derived as follows: SliceCtbAddrRS=(slice_address>>SliceGranularity)

[0132] The variable SliceCbAddrZS, which denotes the address of the first coding block in a slice at the smallest coding block granularity in z-scan order, is derived as follows: SliceCbAddrZS=slice_address <<((log2_diff_max_min_coding_block_size-SliceGranularity)<<1)

[0133] Slice decoding starts at the largest possible coding unit, or in other terms, at the slice start coordinate, CTU.

[0134] first_slice_in_pic_flag indicates whether the slice is the first slice of a picture. If first_slice_in_pic_flag is equal to 1, the variables SliceCbAddrZS and SliceCtbAddrRS are both set to 0, and decoding starts at the first coding tree block in the picture.

[0135] The pic_parameter_set_id specifies the picture parameter set in use. The value of pic_parameter_set_id is in the range 0 to 255.

[0136] num_entry_point_offsets specifies the number of entry_point_offset[i] syntax elements in the slice header. When tiles_or_entropy_coding_sync_idc is equal to 1, the value of num_entry_point_offsets ranges from 0 to (num_tile_columns_minus1+1)*(num_tile_rows_minus1+1)-1. When tiles_or_entropy_coding_sync_idc is equal to 2, the value of num_entry_point_offsets ranges from 0 to PicHeightInCtbs-1. When not present, the value of num_entry_point_offsets is inferred to be equal to 0.

[0137] offset_len_minus1+1 specifies the length, in bits, of the entry_point_offset[i] syntax element.

[0138] entry_point_offset[i] specifies the i-th entry point offset in bytes and is represented by offset_len_minus1+1 bits. The coded slice data after the slice header consists of num_entry_point_offsets+1 subsets having subset index values ​​ranging from 0 to num_entry_point_offsets. Subset 0 consists of bytes 0 to entry_point_offset[0]-1 of the coded slice data, subset k with k ranging from 1 to num_entry_point_offsets-1 consists of bytes entry_point_offset[k-1] to entry_point_offset[k]+entry_point_offset[k-1]-1 of the coded slice data, and the last subset (with subset index equal to num_entry_point_offsets) consists of the remaining bytes of the coded slice data.

[0139] When tiles_or_entropy_coding_sync_idc is equal to 1 and num_entry_point_offsets is greater than 0, each subset contains all coded bits of exactly one tile, and the number of subsets (i.e., the value of num_entry_point_offsets+1) is less than or equal to the number of tiles in the slice.

[0140] NOTE - When tiles_or_entropy_coding_sync_idc is equal to 1, each slice must contain either a subset of one tile (in which case entry point signaling is unnecessary) or an integer number of complete tiles.

[0141] When tiles_or_entropy_coding_sync_idc is equal to 2 and num_entry_point_offsets is greater than 0, each subset k, with k in the range from 0 to num_entry_point_offsets-1, contains all coded bits of exactly one row of the coding tree block, and the last subset (with subset index equal to num_entry_point_offsets) contains all coded bits of the remaining coding blocks in the slice, which consist of exactly one row of the coding tree block or a subset of one row of the coding tree block, and the number of subsets (i.e., the value of num_entry_point_offsets+1) is equal to the number of rows of the coding tree blocks in the slice, and subsets of one row of the coding tree blocks in the slice are also counted.

[0142] NOTE A slice may contain multiple rows of coding tree blocks and subsets of rows of coding tree blocks when tiles_or_entropy_coding_sync_idc is equal to 2. For example, if a slice contains 2.5 rows of coding tree blocks, the number of subsets (i.e., the value of num_entry_point_offsets+1) is equal to 3.

[0143] The corresponding image parameter set RBSP syntax can be selected as shown in FIG.

[0144] The image parameter set RBSP semantics can be as follows:

[0145] dependent_slice_enabled_flag equal to 1 specifies the presence of the syntax element dependent_slice_flag in the slice header for a coded image that references the picture parameter set. dependent_slice_enabled_flag equal to 0 specifies the absence of the syntax element dependent_slice_flag in the slice header for a coded image that references the picture parameter set. The value of dependent_slice_enabled_flag is equal to 1 when tiles_or_entropy_coding_sync_idc is equal to 3.

[0146] tiles_or_entropy_coding_sync_idc equal to 0 specifies that there is only one tile in each image referencing the picture parameter set, there is no specific synchronization process for the context variables that is invoked before decoding the first coding tree block of a row of coding tree blocks in each image referencing the picture parameter set, and furthermore the values ​​of cabac_independent_flag and dependent_slice_flag for the coded images referencing the picture parameter set are not both equal to 1.

[0147] Note that when cabac_independent_flag and dependent_slice_flag are both equal to 1 for a slice, the slice is an entropy slice.

[0148] tiles_or_entropy_coding_sync_idc equal to 1 specifies that there may be more than one tile in each image that references the picture parameter set, and there is no specific synchronization process for the context variables that is invoked before decoding the first coding tree block of a row of coding tree blocks in each image that references the picture parameter set, and further, the values ​​of cabac_independent_flag and dependent_slice_flag for the coded images that reference the picture parameter set are not both equal to 1.

[0149] tiles_or_entropy_coding_sync_idc equal to 2 specifies that there is only one tile in each image that references the picture parameter set, a specific synchronization process for the context variables is invoked before decoding the first coding tree block of a row of coding tree blocks in each image that references the picture parameter set, and a specific storage process for the context variables is invoked after decoding two coding tree blocks of a row of coding tree blocks in each image that references the picture parameter set, and the values ​​of cabac_independent_flag and dependent_slice_flag for coded images that reference the picture parameter set are not both equal to 1.

[0150] tiles_or_entropy_coding_sync_idc equal to 3 specifies that there is only one tile in each image referencing the picture parameter set, and there is no specific synchronization process for the context variables that is invoked before decoding the first coding tree block of a row of coding tree blocks in each image referencing the picture parameter set, and further, the values ​​of cabac_independent_flag and dependent_slice_flag for coded images referencing the picture parameter set may both be equal to 1.

[0151] When dependent_slice_enabled_flag is equal to 0, tiles_or_entropy_coding_sync_idc is not equal to 3.

[0152] It is a bitstream conformance requirement that the value of tiles_or_entropy_coding_sync_idc be for all picture parameter sets activated within a coded video sequence.

[0153] For each slice that references the picture parameter set, when tiles_or_entropy_coding_sync_idc is equal to 2 and the first coding block in the slice is not the first coding block in the first coding tree block of a row of coding tree blocks, the last coding block in the slice belongs to the same coding tree block row as the first coding block in the slice slice.

[0154] num_tile_columns_minus1+1 specifies the number of tile columns into which the image should be partitioned. num_tile_rows_minus1+1 specifies the number of tile rows into which the image should be partitioned.

[0155] When num_tile_columns_minus1 is equal to 0, num_tile_rows_minus1 is not equal to 0. uniform_spacing_flag equal to 1 specifies that the column borders, and similarly the row borders, are uniformly distributed across the image. uniform_spacing_flag equal to 0 specifies that the column borders, and similarly the row borders, are not uniformly distributed across the image, but are explicitly indicated with the syntax elements column_width[i] and row_height[i].

[0156] column_width[i] specifies the width of the i-th tile column in units of coding tree blocks.

[0157] row_height[i] specifies the height of the i-th tile row in units of coding tree blocks.

[0158] The vector colWidth[i] specifies the width of the i-th tile column in units of CTBs with column i ranging from 0 to num_tile_columns_minus1.

[0159] The vector CtbAddrRStoTS[ctbAddrRS] specifies the correspondence from a CTB address in raster scan order to a CTB address in tile scan order, with index ctbAddrRS ranging from 0 to (picHeightInCtbs*picWidthInCtbs)-1.

[0160] The vector CtbAddrTStoRS[ctbAddrTS] specifies the correspondence from CTB addresses in tile scan order to CTB addresses in raster scan order, with index ctbAddrTS ranging from 0 to (picHeightInCtbs*picWidthInCtbs)-1.

[0161] The vector TileId[ctbAddrTS] specifies the correspondence from CTB address to tile id in tile scan order, with ctbAddrTS ranging from 0 to (picHeightInCtbs*picWidthInCtbs)-1.

[0162] The values ​​of colWidth, CtbAddrRStoTS, CtbAddrTStoRS and TileId are derived by invoking a tile scanning conversation process with the CTB raster and PicHeightInCtbs and PicWidthInCtbs as inputs, and the output is assigned to colWidth, CtbAddrRStoTS and TileId.

[0163] The value of ColumnWidthInLumaSamples[i], which specifies the width of the i-th tile column in units of luma samples, is set equal to colWidth[i], and if colWidth[i]< <Log2CtbSizeである。

[0164] The array MinCbAddrZS[x][y], which specifies the correspondence from location (x,y) to the minimum CB address in z scan order in units of minimum CB, with x ranging from 0 to picWidthInMinCbs-1 and y ranging from 0 to picHeightInMinCbs-1, is derived by invoking the Z scanning order array initialization process with Log2MinCbSize, Log2CtbSize, PicHeightInCtbs, PicWidthInCtbs and the vector CtbAddrRStoTS as inputs, and the output is assigned to MinCbAddrZS.

[0165] loop_filter_across_tiles_enabled_flag equal to 1 specifies that in-loop filtering operations are performed across tile boundaries. loop_filter_across_tiles_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across tile boundaries. In-loop filtering operations include deblocking filter, sample adaptive offset and adaptive loop filter operations. When not present, the value of loop_filter_across_tiles_enabled_flag is inferred to be equal to 1.

[0166] cabac_independent_flag equal to 1 specifies that the CABAC decoding of the coding blocks in the slice is independent of any state of previously decoded slices. cabac_independent_flag equal to 0 specifies that the CABAC decoding of the coding blocks in the slice is dependent on the state of previously decoded slices. When not present, the value of cabac_independent_flag is inferred to be equal to 0.

[0167] The derivation process for the availability of the coding block with the smallest coding block address may be as follows:

[0168] The inputs to this process are: - the minimum coded block address in z-scan order, minCbAddrZS - the current minimum coded block address in z-scan order, currMinCBAddrZS It is.

[0169] The output of this process is the availability of the coding block with the smallest coding block address cbAddrZS in the z-scan order cbAvailable.

[0170] NOTE 1 - The meaning of availability is determined at the time this process is invoked. NOTE 2 - Any coding block, regardless of its size, is associated with a minimum coding block address, which is the address of the coding block having the minimum coding block size in the z-scan order. - cbAvailable is set to false if one or more of the following conditions are true: - minCbAddrZS is less than 0 - minCbAddrZS is greater than currMinCBAddrZS - the coding block with the minimum coding block address minCbAddrZS belongs to a different slice than the coding block with the current minimum coding block address currMinCBAddrZS, and furthermore, the dependent_slice_flag of the slice containing the coding block with the current minimum coding block address currMinCBAddrZS is equal to 0. - The coding block with the minimum coding block address minCbAddrZS is included in a different tile than the coding block with the current minimum coding block address currMinCBAddrZS. - Otherwise, cbAvailable is set to true.

[0171] The CABAC analysis process for slice data may be as follows:

[0172] This process is invoked when parsing a particular syntax element with descriptor ae(v).

[0173] The inputs to this process are the values ​​of syntax elements and conventional parsed requests for the values ​​of syntax elements.

[0174] The output of this process is the value of the syntax element.

[0175] When starting the analysis of slice data for a slice, the initialization process of the CABAC analysis process is called.

[0176] FIG. 23 shows how the spatial neighborhood T is used to invoke the coding tree block availability derivation process associated with the current coding tree block (information).

[0177] The minimum coding block address of the coding tree block containing the spatial neighboring block T (Figure 23), ctbMinCbAddrT, is derived using the position (x0, y0) of the top-left luma sample of the current coding tree block as follows: x=x0+2< <Log2CtbSize-1 y=y0-1 ctbMinCbAddrT=MinCbAddrZS[x>>Log2MinCbSize][y>>Log2MinCbSize]

[0178] The variable availableFlagT is obtained by invoking the coding block availability derivation process with ctbMinCbAddrT as input.

[0179] When beginning the analysis of a coding tree as specified, the following ordered steps are applied.

[0180] The arithmetic decoding engine is initialized as follows:

[0181] If CtbAddrRS is equal to slice_address, dependent_slice_flag is equal to 1, and entropy_coding_reset_flag is equal to 0, then the following applies: The CABAC parsing process synchronization process is called with TableStateIdxDS and TableMPSValDS as inputs. The decoding process for binary decisions before termination is called, followed by an initialization process for the arithmetic decoding engine.

[0182] Otherwise, if tiles_or_entropy_coding_sync_idc is equal to 2 and CtbAddrRS % PicWidthInCtbs is equal to 0, then the following applies: When availableFlagT is equal to 1, the CABAC parsing process synchronization process is called with TableStateIdxWPP and TableMPSValWPP as inputs. The decoding process for the binary decisions before termination is called, followed by the process for the arithmetic decoding engine.

[0183] When cabac_independent_flag is equal to 0 and dependent_slice_flag is equal to 1 or tiles_or_entropy_coding_sync_idc is equal to 2, the storage process is applied as follows. When tiles_or_entropy_coding_sync_idc is equal to 2 and CtbAddrRS%PicWidthInCtbs is equal to 2, the storage process of the CABAC analysis process is called with TableStateIdxWPP and TableMPSValWPP as outputs. When cabac_independent_flag is equal to 0, dependent_slice_flag is equal to 1, and end_of_slice_flag is equal to 1, the storage process of the CABAC parsing process is called with TableStateIdxDS and TableMPSValDS as outputs.

[0184] Parsing of a syntax element proceeds as follows:

[0185] For each requested value of the syntax element, a binarization is derived.

[0186] The binarization for the syntax elements and the sequence of parsed bins determines the decoding process flow.

[0187] For each bin of the binarization of a syntax element, indexed by the variable binIdx, a context index ctxIdx is derived.

[0188] For each ctxIdx, the arithmetic decoding process is invoked.

[0189] The resulting sequence of parsed bins (b0..bbinIdx) is compared with the set of bin strings given by the binarization process after decoding of each bin. When the sequence matches a bin string in a given set, the corresponding value is assigned to the syntax element.

[0190] If a request for a syntax element value is processed for the syntax element pcm-flag and the decoded value of pcm_flag is equal to 1, the decoding engine is initialized after decoding of any pcm_alignment_zero_bit, num_subsequent_pcm, and all pcm_sample_luma and pcm_sample_chroma data.

[0191] Thus, the above description reveals a decoder as shown in Fig. 24. This decoder, generally indicated by reference numeral 5, reconstructs an image 10 from a data stream 12 in which the image 10 is encoded in slices 14 into which the image 10 is partitioned, the decoder 5 being configured to decode the slices 14 from the data stream 12 according to a slice order 16. Naturally, the decoder 5 is not restricted to successively decoding the slices 14. Rather, the decoder 5 can use wave-front parallel processing to decode the slices 14, provided that the image 10 partitioning into slices 14 is suitable for wave-front parallel processing. Thus, the decoder 5 may be a decoder capable of decoding the slices 14 in a staggered parallel manner, starting the decoding of the slices 14 by taking into account the slice order 16 to enable wave-front processing, for example, as described above and further below.

[0192] The decoder 5 is responsive to a syntax element portion 18 within a current slice of slices 14 to decode the current slice according to one of at least two modes 20 and 22. According to a first mode of the at least two modes, i.e. mode 20, the current slice is decoded from the data stream 12 using a context-adaptive entropy decoding including derivation of a context across slice boundaries, i.e. across the dotted lines in FIG. 24, i.e. by using information resulting from the encoding / decoding of other "previous slices in slice order 16". Furthermore, the decoding of the current slice from the data stream 12 using the first mode 20 includes a continuous update of the codec's symbol probabilities, and an initialization of the symbol probabilities at the start of the decoding of the current slice that are dependent on the saved states of the symbol probabilities of previously decoded slices. Such a dependency has been described above, for example, in connection with the "synchronization process for codec variables". Finally, the first mode 20 also includes predictive decoding across slice boundaries. Such predictive decoding across slice boundaries may include, for example, intra prediction across slice boundaries, i.e., predicted sample values ​​within a current slice based on already reconstructed sample values ​​of a previous slice "in slice order 16," or prediction of coding parameters, prediction modes, coding modes, etc. across slice boundaries, such as prediction of motion vectors.

[0193] According to the second mode 22, the decoder 5 decodes the current slice, i.e. the currently decoded slice, from the data stream 12 using context adaptive entropy decoding but restricting the derivation of the context so as not to cross slice boundaries. If, for example, a template of adjacent positions used to derive a context for a particular syntax element related to a block in the current slice extends into an adjacent slice, thereby crossing a slice boundary of the current slice, the corresponding attributes of the respective parts of the adjacent slice, such as the values ​​of the corresponding syntax elements of this adjacent part of the adjacent slice, are set to default values ​​to suppress mutual dependencies between the current slice and the adjacent slice. While continuous updating of the symbol probabilities of the context can occur as it is the case in the first mode 20, the initialization of the symbol probabilities in the second mode 22 is independent of any previously decoded slice. Furthermore, predictive decoding is performed restricting the predictive decoding so as not to cross slice boundaries.

[0194] To facilitate the understanding of the description of Fig. 24 and the following description, reference is made to Fig. 25 which shows a possible implementation of the decoder 5 in a more structural sense compared to Fig. 24. As is the case in Fig. 24, the decoder 5 is a predictive decoder which uses, for example, context adaptive entropy decoding for decoding the data stream to obtain prediction residuals and prediction parameters.

[0195] As shown in Fig. 25, the decoder 5 may include an entropy decoder 24, an inverse quantization and inverse transform module 26, a combiner 28 implemented, for example, as an adder and a predictor 28, as shown in Fig. 25. The entropy decoder 24, the module 26 and the adder 27 are serially connected between the input and the output of the decoder 5 in their mentioned order, and further, the predictor 28 is connected between the output of the adder 28 and its further input to form a prediction loop together with the combiner 27. Thus, the decoder 24 has its output further connected to the coding parameter input of the predictor 28.

[0196] Although Fig. 25 gives the impression that the decoder serially decodes the current image, the decoder 5 may be implemented to decode, for example, the image 10 in parallel. The decoder 5 may, for example, include multiple cores, each operating according to elements 24-28 in Fig. 25. However, parallel processing is optional, and furthermore, the decoder 5 operating serially may also decode an incoming data stream at the input of the entropy decoder 24.

[0197] To efficiently achieve the just-mentioned ability to decode the current image 10 serially or in parallel, the decoder 5 operates on a coding block 30 basis to decode the image 10. The coding blocks 30 are, for example, coding tree blocks or leaf blocks in which the largest coding blocks 32 are partitioned by a recursive multi-tree partitioning, such as a quad-tree partitioning. The code tree blocks 32 may then be regularly arranged in columns and rows to form a regular partitioning of the image 10 into these code tree blocks 32. In FIG. 25, the code tree blocks 32 are shown with solid lines, while the coding blocks 30 are shown with dotted lines. For illustrative purposes, it is shown that only one code tree block 32 is further partitioned into coding blocks 30, and instead, the other code tree block 32 is not further partitioned to directly form coding blocks. The data stream 12 may include a syntax portion signaling how the image 10 is partitioned into code blocks 30.

[0198] Data stream 12 conveys syntax elements for each coding block 30 that clarify how modules 24-28 recover the image content within that coding block 30. For example, these syntax elements include: 1) optionally partitioning data for further partitioning the coding block 30 into prediction blocks; 2) optionally partitioning data for further partitioning the coding block 30 into residual and / or transform blocks; 3) A prediction mode that signals which prediction mode is used to derive a prediction signal for the coding block 30, where the granularity at which the prediction mode is signaled may depend on the coding block 30 and / or the prediction block. 4) Prediction parameters may be signaled for each coding block, or for each prediction block with certain prediction parameters being sent, if present, depending on the prediction mode, for example. Possible prediction modes may include, for example, intra-prediction and / or inter-prediction. 5) Other syntax elements may be present, such as, for example, filtering information for filtering the image 10 in the coding block 30 to obtain a prediction signal and / or a reconstructed signal to be reproduced. 6) Finally, residual information, particularly in the form of transform coefficients, may be included in the data stream for coding block 30, the residual data may be signaled on a residual block basis, and for each residual block, if present, a spectral decomposition may be performed, e.g., on a transform block basis as described above.

[0199] The entropy decoder 24 is responsible for obtaining the just mentioned syntax elements from the data stream. For this purpose, the entropy decoder 24 uses a context-adaptive entropy decoding, i.e. it provides several contexts. To derive a particular syntax element from the data stream 12, the entropy decoder 24 selects a particular context among the possible contexts. The selection among the possible contexts is performed depending on the attributes of the neighborhood of the part of the image 10 to which the current syntax element belongs. For each of the possible contexts, the entropy decoder 24 manages symbol probabilities, i.e. probability estimates for each possible symbol of the symbol alphabet on which the entropy decoder 24 operates. "Managing" includes the above-mentioned continuous updating of the symbol probabilities of the contexts in order to apply the symbol probabilities associated with each context to the actual image context. By this measure, the symbol probabilities are applied to the actual probability statistics of the symbols.

[0200] Another environment in which attributes of the neighborhood influence the reconstruction of a current portion of the image 10, such as the current coding block 30, is predictive decoding in the predictor 28. The prediction is not limited to the predicted content in the current coding block 30, but can also include prediction of parameters, partitioning data or transform coefficients contained in the data stream 12 for the current coding block 30, such as prediction parameters. That is to say, the predictor 28 can predict the image content or such parameters from the above-mentioned neighborhood to obtain a written signal that is subsequently combined with a prediction residual as obtained by the module 26 from the data stream 12. When predicting a parameter, the predictor 28 can use syntax elements contained in the data stream as a prediction residual to obtain the actual value of the prediction parameter. The predictor 28 uses the later prediction parameter value to obtain the just-mentioned prediction signal that is then combined with the prediction residual in the combiner 27.

[0201] The above-mentioned "neighborhood" mainly covers the upper left part of the environment of the current part to which the currently entropy decoded or currently predicted syntax element belongs. In Fig. 25, such a neighborhood is exemplarily indicated at 34 for one coding block 30.

[0202] The encoding / decoding order is defined within the coding blocks 30: at the coarsest level, the code tree blocks 32 of the image 10 are scanned in a scan order 36, shown here as a raster scan leading row-by-row from top to bottom. Within each code tree block, the coding blocks 30 are scanned in a depth-first traversal order, such that at each hierarchical level, the code tree blocks 32 are also scanned in a raster scan leading row-by-row from top to bottom.

[0203] The coding order defined in the coding block 30 is in harmony with the definition of the neighborhood 34 used to derive attributes in the neighborhood to select a context and / or perform spatial prediction, in that the neighborhood 34 mainly covers parts of the image 10 that have already undergone decoding according to the coding order. Whenever a part of the neighborhood 34 covers an unavailable part of the image 10, default data is for example used instead. For example, the neighborhood template 34 can extend outside the image 10. However, another possibility is that the neighborhood 34 extends to adjacent slices.

[0204] The image 10 along the encoding / decoding order defined along the slice division, e.g., along the coding blocks 30, i.e., each slice, is a continuous uninterrupted sequence of coding blocks 30 along the coding block order described above. In FIG. 25, the slices are indicated by dashed and dotted lines 14. The order defined in the slices 14 results from their configuration of execution of successive coding blocks 30 as described above. If the syntax element portion 18 of a particular slice 14 indicates that it is decoded in a first mode, the entropy decoder 24 enables the context-adaptive entropy decoding to derive a context beyond the slice boundary. That is, the spatial neighborhood 34 is used to select a context in the entropy decoded data for the current slice 14. In the case of FIG. 25, for example, slice number 3 may be the currently decoded slice, and further, in the entropy decoding syntax element for the coding block 30 or some portion contained therein, the entropy decoder 24 can use attributes resulting from the decoded portion in an adjacent slice, e.g., slice number 1. Predictor 28 operates in a similar manner: for slices in the first mode 20, predictor 28 uses spatial prediction across slice boundaries surrounding the current slice.

[0205] However, for slices that have a second mode 22 associated with them, i.e. the syntax element portion 18 indicates the second mode 22, the entropy decoder 24 and the predictor 28 limit the derivation of the entropy context and the predictive decoding to depend on attributes related to the parts present only in the current slice. Obviously, the coding efficiency is subject to this limitation. On the other hand, slices in the second mode 22 make it possible to break the mutual dependencies between sequences of slices. Thus, slices in the second mode 22 can be interspersed within a picture 10 or within the video to which the picture 10 belongs to allow resynchronization points. However, it is not necessary that each picture 10 has at least one slice in the second mode 22.

[0206] As already mentioned above, the first and second modes 20 and 22 also differ in their initialization of the symbol probabilities. A slice coded in the second mode 22 results in the entropy decoder 24 reinitializing the probabilities independent of any previously decoded slices, i.e. slices previously decoded in the sense of the order defined in the slice. The symbol probabilities are for example set to default values ​​known on both the encoder and the decoder side, or initialization values ​​are included in the slice coded in the second mode 22.

[0207] That is, for slices that are coded / decoded in the second mode 22, the adaptation of the symbol probabilities always starts immediately from the beginning of these slices, and therefore the adaptation accuracy is not good for these slices at the beginning of these slices.

[0208] Things are different for slices coded / decoded in the first mode 20. For the subsequent slices, the initialization of the symbol probabilities performed by the entropy decoder 24 is subordinate to the saved state of the symbol probabilities of the previously decoded slice. Whenever a slice coded / decoded in the first mode 20 has its start, for example, located other than on the left side of the image 10, i.e. on the side where the raster scan 36 does not start running row by row before proceeding down the next row, the symbol probabilities are adopted as they occur at the end of the entropy decoding of the previous slice. This is indicated, for example, in FIG. 2 by the arrow 38 for slice number 4. Slice number 4 has its start somewhere between the right and left side of the image 10, and therefore when initializing the symbol probabilities, the entropy decoder 24 adopts, when initializing the symbol probabilities, the symbol probabilities obtained in the entropy decoding of the previous slice, i.e. slice number 3, up to its end, i.e. including the continuous update of the symbol probabilities during the entropy decoding of slice 3.

[0209] A slice having a second mode 22 associated with it but starting on the left side of the image 10, such as slice number 5, does not apply the symbol probabilities as obtained after completing the entropy decoding of the immediately preceding slice number 4, because this would prevent the decoder 5 from decoding the image 10 in parallel by using wavefront processing. Rather, as described above, the entropy decoder 24 applies the symbol probabilities as obtained after completing the entropy decoding of the second code tree block 32 in the encoding / decoding order 36, in the immediately preceding code tree block row in the encoding / decoding order 36, as indicated by arrow 40.

[0210] 25, for example, image 10 is illustratively partitioned into three rows of code tree blocks and four columns of coding tree root blocks 32, and each code tree block row is further subdivided into two slices 14, such that the start of every second slice coincides with the first coding unit in the coding unit order of each code tree root block row. Thus, entropy decoder 24 can use wavefront processing on decoded image 10 by decoding each code tree root block row in parallel, starting with the first or top code tree root block row, and then the second, then the third, alternatingly decoding these code tree root block rows.

[0211] Of course, the partitioning of blocks 32 in a recursive manner into further coding blocks 30 is arbitrary, and therefore, in a more general sense, blocks 32 may also be referred to as "coding blocks." That is, more generally, image 10 may be partitioned into coding blocks 32 having a raster scan order 36 arranged in rows and columns and further defined relative to one another, and decoder 5 may be considered to associate each slice 14 with a consecutive subset of coding blocks 32 in raster scan order 36, such that the subsets follow one another along raster scan order 36 according to slice order.

[0212] Also, as becomes clear from the above description, the decoder 5, or more specifically the entropy decoder 24, may be configured to store the symbol probabilities as obtained in the context adaptive entropy decoding of any slice up to the second coding block in the coding block row according to the raster scan order 36. When initializing the symbol probabilities for the context adaptive entropy decoding of the current slice having the first mode 20 associated therewith, the decoder 5, or more specifically the entropy decoder 24, checks whether the first coding block 32 of the consecutive subset of coding blocks 32 associated with the current slice is the first coding block 32 in the coding block row according to the raster scan order 36. If so, the symbol probabilities for the context adaptive entropy decoding of the current slice are initialized as described with respect to the arrow 40, i.e. in response to the stored symbol probabilities as obtained in the context entropy decoding of the slice previously decoded up to the second coding block in the coding block row according to the raster scan order 36. Otherwise, an initialization of the symbol probabilities for the context-adaptive entropy decoding of the current slice is performed according to the symbol probabilities as obtained in the context-adaptive entropy decoding of the previously decoded slice up to the end of the previously decoded slice, i.e. according to arrow 38. Also, in the case of the initialization according to 38, it is meant the state saved at the end of the entropy decoding of the previous slice in the slice order 36, whereas in the case of initialization 40, it is that the previously decoded slice comprises the end of the second block of the row immediately preceding block 32 in the block order 36.

[0213] As shown by the dotted lines in Figure 24, the decoder may be configured to respond to syntax element portion 18 within a current slice of slice 14 to decode the current slice according to one of at least three modes. That is, a third mode 42 may be beside the others 20 and 22. The third mode 42 may differ from the second mode 22 in that prediction across slice boundaries is enabled, but entropy encoding / decoding is still restricted to not cross slice boundaries.

[0214] Above, two embodiments are shown for the syntax element portion 18. The table below summarizes these two embodiments.

[0215] TIFF0007640795000007.tif63131

[0216] In one embodiment, the syntax element part 18 is formed by the dependent_slice_flag individually, while in another embodiment, the combination of dependent_slice_flag and no_cabac_reset_flag forms the syntax element part. As far as the initialization of the symbol probabilities according to the saved states of the symbol probabilities of the previously decoded slices is concerned, it refers to the synchronization process for the context variables. In particular, the decoder may be configured to: if last_ctb_cabac_init_flag=0 and tiles_or_entropy_coding_sync_idc=2, store the symbol probabilities as obtained in the context adaptive entropy decoding of the previously decoded slice in succession according to the raster scan order up to the second coding block; and, when initializing the symbol probabilities for the context adaptive entropy decoding of the current slice in accordance with the first mode, check whether the first coding block of the consecutive subset of coding blocks associated with the current slice is the first coding block in succession according to the raster scan order, and, if so, initialize the symbol probabilities for the context adaptive entropy decoding of the current slice in accordance with the stored symbol probabilities as obtained in the context adaptive entropy decoding of the previously decoded slice in succession according to the raster scan order up to the second coding block; and, if not, initialize the symbol probabilities for the context adaptive entropy decoding of the current slice in accordance with the symbol probabilities as obtained in the context adaptive entropy decoding of the previously decoded slice up to the end of the previously decoded slice.

[0217] Thus, in other words, according to the second embodiment for the syntax, the decoder reconstructs the image 10 from a data stream 12 in which the image is encoded in slices 14 into which the image (10) is partitioned, the decoder is configured to decode the slices 14 from the data stream 12 according to a slice order 16, and further the decoder is responsive to a syntax element portion 18, i.e. dependent_slice_flag in the current slice of the slice, in order to decode the current slice according to one of at least two modes 20, 22. According to a first mode 20 of the at least two modes, i.e. when dependent_slice_flag=1, the decoder decodes the current slice from the data stream 12 using context adaptive entropy decoding 24 including derivation of context across slice boundaries, continuous updating of symbol probabilities of the context and initialization of symbol probabilities 38, 40 according to the saved states of the symbol probabilities of previously decoded slices, and predictive decoding across slice boundaries, and according to a second mode 22 of the at least two modes, i.e. when dependent_slice_flag=0, the decoder decodes the current slice from the data stream 12 using context adaptive entropy decoding with derivation of context to not cross slice boundaries, continuous updating of symbol probabilities of the context and initialization of symbol probabilities independent of any previously decoded slices, and predictive decoding that restricts predictive decoding to not cross slice boundaries. The image 10 may be partitioned in coding blocks 32 having a raster scan order 36 arranged in rows and columns and defined relative to one another, and the decoder is further configured to associate each slice 14 with a consecutive subset of the coding blocks 32 in the raster scan order 36 such that the subsets follow one another along the raster scan order 36 according to the slice order.The decoder may be configured, i.e. in response to tiles_or_entropy_coding_sync_idc=2, to store symbol probabilities as obtained in context adaptive entropy decoding of slices previously decoded in succession according to the raster scan order 36 up to the second coding block 32, and further configured, when initializing the symbol probabilities for context adaptive entropy decoding of the current slice in accordance with the first mode, to check whether the first coding block of the consecutive subset of coding blocks 32 associated with the current slice is the first coding block 32 in succession according to the raster scan order, and further configured, if so, to initialize 40 the symbol probabilities for context adaptive entropy decoding of the current slice in accordance with the stored symbol probabilities as obtained in context adaptive entropy decoding of slices previously decoded in succession according to the raster scan order 36 up to the second coding block, and further configured, if not, to initialize 38 the symbol probabilities for context adaptive entropy decoding of the current slice in accordance with the symbol probabilities as obtained in context adaptive entropy decoding of slices previously decoded up to the end of the previously decoded slice. The decoder may be configured to respond to a syntax element portion (18) within a current slice of slice 14 to decode the current slice according to one of at least three modes, namely one of a first mode 20 and a third mode 42 or the second mode 22, and the decoder is configured to decode the current slice from the data stream according to the third mode 42, i.e., if dependent_slice_flag=1 and tiles_or_entropy_coding_sync_idc=3, restricting the derivation of the context to not cross slice boundaries, using context-adaptive entropy decoding with continuous updating of the symbol probabilities of the context and initialization of the symbol probabilities independent of any previously decoded slices, and predictive decoding across slice boundaries, wherein one of the first and third modes is selected in response to a syntax element, namely cabac_independent_flag.The decoder may further be configured to store the symbol probabilities as obtained in the context adaptive entropy decoding of the previously decoded slice up to the end of the previously decoded slice, i.e. when tiles_or_entropy_coding_sync_idc=0, 1 and 3 ("3" when cabac_independentflag=0), and further configured to initialize the symbol probabilities for the context adaptive entropy decoding of the current slice depending on the stored symbol probabilities when initializing the symbol probabilities for the context adaptive entropy decoding of the current slice according to the first mode. The decoder may be configured to restrict the predictive decoding within the tiles into which the image is subdivided in the first and second modes, i.e. when tiles_or_entropy_coding_sync_idc=1.

[0218] Of course, the encoder can therefore set the above syntax to enable the decoder to obtain the above advantages. The encoder may be, but need not be, a parallel process, such as a multi-core encoder, etc. To encode the image 10 into the data stream 12 in slices 14, the encoder is configured to encode the slices 14 into the data stream 12 according to a slice order 16. The encoder determines a syntax element portion 18 for a current slice of the slice to signal that the syntax element portion is coded according to one of the at least two modes 20, 22, and further encodes the syntax element portion 18 thereto, and further encodes the current slice into the data stream 12 using context adaptive entropy coding 24 including derivation of context across slice boundaries, continuous updating of symbol probabilities of the context and initialization of symbol probabilities 38, 40 according to a saved state of the symbol probabilities of a previously coded slice, and predictive coding across slice boundaries if the current slice is coded according to a first mode 20 of the at least two modes, and further encodes the current slice into the data stream 12 using context adaptive entropy coding with derivation of context to not cross slice boundaries, continuous updating of symbol probabilities of the context and initialization of symbol probabilities independent of any previously coded slice, and predictive coding that restricts predictive coding to not cross slice boundaries if the current slice is coded according to a second mode 22 of the at least two modes. While the image 10 may be partitioned in coding blocks 32 arranged in rows and columns and having a raster scan order 36 defined relative to one another, the encoder may be configured to associate each slice 14 with a consecutive subset of the coding blocks 32 in the raster scan order 36 such that the subsets follow one another along the raster scan order 36 according to the slice order.The encoder may be configured to store symbol probabilities as obtained in context adaptive entropy coding of previously coded slices in succession according to a raster scan order 36 up to the second coding block 32, and further, when initializing the symbol probabilities for context adaptive entropy coding of the current slice in accordance with the first mode, check whether the first coding block of a consecutive subset of coding blocks 32 associated with the current slice is the first coding block 32 in succession according to the raster scan order, and, if so, initialize 40 the symbol probabilities for context adaptive entropy coding of the current slice in accordance with the stored symbol probabilities as obtained in context adaptive entropy coding of previously coded slices in succession according to the raster scan order 36 up to the second coding block, and, if not, initialize 38 the symbol probabilities for context adaptive entropy coding of the current slice in accordance with the symbol probabilities as obtained in context adaptive entropy coding of previously decoded slices up to the end of the previously coded slice. The encoder may be configured to encode the syntax element portion (18) into a current slice of the slices (14) such that the current slice is signaled to be encoded therein according to one of at least three modes, namely, one of a first mode (20) and a third mode (42) or a second mode (22), and the encoder is configured to encode the current slice into a data stream using context-adaptive entropy coding with continuous updating of the symbol probabilities of the context and initialization of the symbol probabilities independent of any previously encoded slices, and predictive coding across slice boundaries, restricting derivation of the context to not cross slice boundaries according to the third mode (42), and the encoder distinguishes between the first and third modes, for example, using a syntax element, namely, cabac_independent_flag.The encoder may be configured to determine a generic syntax element, such as for example dependent_slices_present_flag, and to operate in one of at least two generic operation modes according to the generic syntax element, i.e. to perform encoding of the syntax element portion slice by slice according to a first generic operation mode, and to write the generic syntax element into the data stream necessarily using a different one of at least two modes other than the first mode according to a second generic operation mode. The encoder may be configured to necessarily and uninterruptedly continue the continuous updating of the symbol probabilities from the start to the end of the current slice according to the first and second modes. The encoder ay is further configured to store probabilities for symbols as obtained in the context adaptive entropy encoding of the previously encoded slice until the end of the previously encoded slice, and to initialize the symbol probabilities for the context adaptive entropy encoding of the current slice according to the stored symbol probabilities when initializing the symbol probabilities for the context adaptive entropy encoding of the current slice according to the first mode. Furthermore, the encoder may restrict predictive encoding in the first and second modes within tiles in which the image is subdivided.

[0219] A possible structure of the encoder is represented for completeness in Fig. 26. The predictor 70 works much like the predictor 28, i.e. it performs prediction, but also determines the coding parameters, including, for example, the prediction parameters and the mode, by optimization. The modules 26 and 27 also occur in the decoder. The subtractor 72 determines the lossless prediction residual, which is lossy coded in the transform and quantization module 74, by use of quantization and, optionally, with a spectral decomposition transform. The entropy coder 76 performs context-adaptive entropy coding.

[0220] In addition to the specific syntax examples given above, different examples are outlined below showing correspondence between the terminology used below and above.

[0221] In particular, not as outlined above, a dependent slice is not only "dependent" in that it allows it to utilize knowledge known from outside its boundaries, but also has a more rapidly adapted entropy context, as outlined above, or achieves better spatial prediction due to tolerance beyond its boundaries. Rather, in order to save the rate cost that would be spent to define the slice header by dividing the image into slices, the dependent slice adopts a part of the slice header syntax from the previous slice, i.e., this slice syntax header part is not transmitted again for the dependent slice. This is, for example, shown at 100 in FIG. 16 and at 102 in FIG. 21, according to which the slice type is adopted, for example, from the previous slice. By this measure, the subdivision of the image into slices, such as independent slices and dependent slices, is cheaper in terms of expensive bit consumption.

[0222] It is the dependencies just mentioned that result in slightly different wording in the example outlined below: A slice is defined as a unit portion of an image for which the slice header syntax can be set individually. Thus, a slice consists of one independent / regular / normal slice, now called an independent slice segment, using the nomenclature above, and zero, one or more dependent slices, now called dependent slice segments, using the nomenclature above.

[0223] FIG. 27 shows, for example, an image partitioned into two slices, one formed of slice segments 141-143 and the other only formed of slice segment 144. The indices 1-4 indicate the slice order in the coding order. FIG. 28a and FIG. 28b show different examples in the case of a subdivision of an image 10 into two tiles, where in FIG. 28a one slice is formed of all five slice segments 14 covering both tiles 501 and 502 whose indices rise in the coding order, and in FIG. 28a two slices are formed of slice segments 141 and 142 and 143 and 144 respectively, subdividing tile 501, and another slice is formed of slice segments 145-146 covering tile 502.

[0224] The definition could be:

[0225] Dependent slice segment: a slice segment in which the values ​​of some syntax elements of the slice segment header are inferred from the values ​​for the previous independent slice segment in decoding order, previously referred to as a dependent slice in the above embodiments.

[0226] Independent slice segment: a slice segment in which the values ​​of syntax elements in the slice segment header are not inferred from the values ​​for the previous slice segment, previously referred to as a normal slice in the above embodiments.

[0227] Slice: An integer number of coding tree units contained in one independent slice segment and all subsequent dependent slice segments (if any) that precede the next independent slice segment (if any) within the same access unit / picture.

[0228] Slice Header: The slice segment header of an independent slice segment that is the current slice segment or that precedes the current dependent slice segment.

[0229] Slice segment: An integer number of coding tree units that are sequentially ordered in a tile scan and contained in a single NAL unit. The division of each image into slice segments is a partitioning.

[0230] Slice segment header: The part of an encoded slice segment that contains data elements related to the first or all coding tree units represented in the slice segment.

[0231] The signaling of "modes" 20 and 22, i.e. "dependent slice segment" and "independent slice segment", can be as follows:

[0232] In some additional NAL units, such as for example the PPS, syntax elements may be used to signal whether the use of dependent slices is configured for a particular picture of a sequence for a particular picture:

[0233] dependent_slice_segments_enabled_flag equal to 1 specifies the presence of the syntax element dependent_slice_segment_flag in the slice segment header. dependent_slice_segments_enabled_flag equal to 0 specifies the absence of the syntax element dependent_slice_segment_flag in the slice segment header.

[0234] The dependent_slice_segments_enabled_flag has the same range as the dependent_slices_present_flag described above.

[0235] Similarly, the dependent_slice_flag may be referred to as dependent_slice_segment_flag to account for the different nomenclature for slices.

[0236] dependent_slice_segment_flag equal to 1 specifies that the value of each slice segment header syntax element that is not present in the header of the current slice segment is inferred to be equal to the value of the corresponding slice segment header syntax element in the slice header, i.e., the slice segment header of the previous independent slice segment.

[0237] At the same level, e.g. the image level, the following syntax elements may be included:

[0238] An entropy_coding_sync_enabled_flag equal to 1 specifies that a specific synchronization process for the context variables is invoked before decoding a coding tree unit including a first coding tree block of a row of coding tree blocks in a respective tile in each image that references the PPS, and furthermore, a specific storage process for the context variables is invoked after decoding a coding tree unit including a second coding tree block of a row of coding tree blocks in a respective tile in each image that references the PPS. An entropy_coding_sync_enabled_flag equal to 0 specifies that a specific synchronization process for the context variables is not required to be invoked before decoding a coding tree unit including a first coding tree block of a row of coding tree blocks in a respective tile in each image that references the PPS, and furthermore, a specific storage process for the context variables is not required to be invoked after decoding a coding tree unit including a second coding tree block of a row of coding tree blocks in a respective tile in each image that references the PPS. It is a bitstream conformance requirement that the value of entropy_coding_sync_enabled_flag be the same for all PPSs that are activated within a CVS. It is a bitstream conformance requirement that when entropy_coding_sync_enabled_flag is equal to 1 and the first coding tree block in a slice is not the first coding tree block in a row of coding tree blocks in a tile, the last coding tree block in a slice belongs to the same coding tree block row as the first coding tree block in the slice. It is a bitstream conformance requirement that when entropy_coding_sync_enabled_flag is equal to 1 and the first coding tree block in a slice segment is not the first coding tree block of a row of coding tree blocks in a tile, the last coding tree block in a slice segment belongs to the same coding tree block row as the first coding tree block in the slice segment.

[0239] As already mentioned, the encoding / decoding order in CTB 30 results in a row-by-row start from top to bottom, scanning the first tile and then visiting the next tile in a raster manner if more than one tile is present in the image.

[0240] The decoder 5 and the encoder therefore work in the entropy decoding (encoding) of the slice segments 14 of the image as follows:

[0241] A1) Whenever the currently decoded / encoded syntax element synEl is the first syntax element of a row of a tile 50, slice segment 14 or CTB, the initialization process of FIG. 29 is started. A2) Otherwise, decoding of this syntax element occurs using the current entropy context. A3) If the current syntax element was the last syntax element in the CTB 30, then the entropy context storage process as shown in FIG. 30 is initiated. A4) The process advances to the next syntax element in A1).

[0242] In the initialization process, it is checked 200 whether synEI is the first syntax element of a slice segment 14 or a tile 50. If yes, the context is initialized in step 202 independently of any previous slice segment. If no, it is checked 204 whether synEI is the first syntax element of a line of a CTB 30 and entropy_coding_sync_enabled_flag is equal to 1. If yes, it is checked 206 whether a second CTB 30 is available in the previous line of the CTB 30 of the equivalent tile (see FIG. 23). If yes, the context adoption according to 40 is performed in step 210 using the currently stored context probability for adoption of type 40. If not, the context is initialized in step 202 independently of any previous slice segment. If check 204 reveals no, it is checked in step 212 whether synEl is the first syntax element in the first CTB of the dependent slice segment 14 and further whether dependent_slice_segement_flag is equal to 1, and further, if yes, a context adoption according to 38 is performed in step 214 using the currently stored context probability for adoption of type 38. After any of steps 214, 212, 210 and 202, the decoding / encoding actually starts.

[0243] Dependent slice segments with dependent_slice_segement_flag equal to 1 help to further reduce the encoding / decoding delay with little coding efficiency penalty.

[0244] In the storage process of FIG. 30, it is checked in step 300 whether the encoded / decoded synEl is the last syntax element of the second CTB 30 in a row of the CTB 30 and whether the entropy_coding_sync_enabled_flag is equal to 1. If yes, the current entropy context is stored in step 302, i.e., the entropy coding probability of the context is stored in a storage specified for the adoption of the 40 type. Similarly, in addition to step 300 or 302, it is checked in step 304 whether the encoded / decoded synEl is the last syntax element of the slice segment 14 and whether the dependent_slice_segement_flag is equal to 1. If yes, the current entropy context is stored in step 306, i.e., the entropy coding probability of the context is stored in a storage specified for the adoption of the 38 type.

[0245] Note that any check asking whether a syntax element is the first synEl in a CTB row makes use of, for example, the syntax element slice_adress400 in the slice segment header, i.e., the start syntax element that identifies the location of the start of the respective slice segment along the decoding order.

[0246] When reconstructing the image 10 from the data stream 12 using the WPP process, the decoder can accurately utilize the later start syntax portion 400 to search for the WPP substream entry point. Since each slice segment includes a start syntax portion 400 indicating the location of the decoding start of the respective slice segment in the image 10, the decoder can identify the entry point of the WPP substream in which the slice segments are grouped by identifying the slice segment that starts on the left side of the image using the start syntax portion 400 of the slice segment. The decoder can then start decoding the WPP substreams consecutively according to the slice order to decode the WPP substreams in a staggered parallel manner. The slice segments may be smaller than one image width, i.e., one row of the CTB, so that their transmission can be interleaved in the WPP substream to further reduce the overall transmission end-to-end delay. The encoder provides each slice (14) with a start syntax portion (400) that indicates where in the image (10) the encoding of the respective slice begins, and further groups the slices into WPP substreams such that, for each WPP substream, the first slice begins on the left side of the image in slice order. The encoder may even use the WPP process alone in encoding the image: the encoder encodes the WPP substreams in a staggered parallel manner, starting encoding the WPP substreams consecutively according to the slice order.

[0247] However, the latter aspect of using the start syntax portion of a slice segment as a means for locating the entry point of a WPP substream can be used without the dependent slice concept.

[0248] It is possible to achieve this in all cases for parallel processing image 10 by setting the above mentioned variables as follows:

[0249] TIFF0007640795000008.tif103166

[0250] It is feasible to mix WPP with tile partitioning. In that case, one can consider tiles as individual images: each with WPP consists of slices with one or more dependent slice segments, and the checks in steps 300 and 208 refer to a second CTB in the CTB row above in the same tile, just as steps 204 and A1 refer to a first CTB 30 in the CTB 30 row of the current tile. In that case, the above table can be expanded:

[0251] TIFF0007640795000009.tif241161

[0252] As a brief remark, the latter extension is made possible in embodiment 2. Embodiment 2 allows the following processing:

[0253] TIFF0007640795000010.tif104168

[0254] However, for the following extension, the following table occurs:

[0255] Add to the image parameter set semantics: If tiles_or_entropy_coding_sync_idc is equal to 4, then the first row of each, but not all, CTBs are included in a different slice that has its dependent slice flag set to 1. CTBs of different rows must not be in the same slice. There MAY be more than one slice per CTB row.

[0256] If tiles_or_entropy_coding_sync_idc is equal to 5, then the CTBs of each tile, but the first tile, must be contained in a different slice. The CTBs of different tiles must not be in the same slice. There MAY be more than one slice present per tile.

[0257] For further explanation, please refer to FIG.

[0258] That is, the above table can be expanded:

[0259] TIFF0007640795000011.tif181131

[0260] With regard to the above-mentioned embodiments, it should be noted that the decoder should be configured, e.g., in response to tiles_or_entropy_coding_sync_idc=1, 2 in the first and second modes, to read information from the current slice revealing the subdivision of the current slice into parallel subsections, which may be WPP sub-streams or tiles, to stop context-adaptive entropy decoding at the end of the first parallel subsection and further resume context-adaptive entropy decoding anew at the start of any subsequent parallel subsection, including, in the first mode, initialization of symbol probabilities according to the saved state of the symbol probabilities of the previous parallel subsection, and, in the second mode, initialization of symbol probabilities independent of any previously decoded slices and any previously decoded parallel subsections.

[0261] Thus, the above description reveals a method for low-delay encoding, decoding, encapsulation and transmission of video data configured as provided by the new HEVC encoding standard, e.g., organized in tiles, wavefront parallel processing (WPP) sub-streams, slices or entropy slices.

[0262] In particular, it is defined how to transfer parallel coded data in a conversational scenario to obtain minimum latency in the coding, decoding and transmission process. Thus, a pipelined parallel coding, transmission and decoding approach is described to enable minimum latency applications such as gaming, remote surgery, etc.

[0263] Furthermore, the above embodiment fills a gap in wavefront parallel processing (WPP) to allow it to be used in low latency transmission scenarios. Thus, a new encapsulation format for WPP substream 0 shows a dependent slice. This dependent slice can contain entropy slice data, WPP substreams, a complete row of LCUs, just a fragment of a slice, and the conventional transmitted slice header also applies to the included fragment data. The included data is signaled in the subslice header.

[0264] Finally, note that the naming for the new slice could also be "subset / lightweight slice", but the name "dependent slice" has been found to be better.

[0265] Signaling is shown that describes the level of parallelism in encoding and forwarding.

[0266] Although some aspects are described in the context of an apparatus, it will be apparent that these aspects also represent a description of a corresponding method, where a block or apparatus corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of any of the most important method steps may be performed by such an apparatus.

[0267] Depending on specific implementation requirements, the embodiments of the present invention can be implemented in hardware or in software. The implementation can be carried out using a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, on which electronically readable control signals are stored that cooperate (or can cooperate) with a programmable computer system so that the respective method is executed. The digital storage medium may therefore be computer readable.

[0268] Some embodiments according to the present invention include a data carrier having electronically readable control signals capable of cooperating with a programmable computer system to cause one of the methods described herein to be performed.

[0269] Generally, embodiments of the present invention can be implemented as a computer program product having program code which operates to perform one of the methods when the computer program product is run on a computer. The program code may for example be stored on a machine readable carrier.

[0270] Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier.

[0271] In other words, a method embodiment of the present invention is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0272] A further embodiment of the inventive method is therefore a data carrier (or digital storage medium or computer readable medium) comprising recorded thereon the computer program for performing one of the methods described herein. The data carrier, digital storage medium or recording medium is typically tangible and / or non-transitory.

[0273] A further embodiment of the inventive method is therefore a data stream or a sequence of signals representing the computer program for performing one of the methods described herein, the data stream or the sequence of signals being adapted to be transmitted via a data communication connection, for example the Internet.

[0274] A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0275] A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0276] Further embodiments according to the present invention include an apparatus or system configured to transfer (e.g., electronically or optically) a computer program for performing one of the methods described herein to a receiver. The receiver may be, for example, a computer, a mobile device, a memory device, etc. The apparatus or system may, for example, include a file server for transferring the computer program to the receiver.

[0277] In some embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by any hardware apparatus.

[0278] The above-described embodiments are merely illustrative for the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to others skilled in the art. It is therefore intended that the present invention be limited only by the scope of the appended claims and not by the specific details shown herein as descriptions and illustrations of the embodiments.

[0279] literature [1] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, Ajay Luthra, "Overview of the H.264 / AVC Video Coding Standard", IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, July 2003. [2] JCT-VC, "High-Efficiency Video Coding (HEVC) text specification Working Draft 6", JCTVC-H1003, February 2012. [3] ISO / IEC 13818-1: MPEG-2 Systems specification.

Claims

1. 1. A decoder for decoding information from a data stream to reconstruct an image partitioned into a plurality of parts, said decoder comprising: A processor; 11. An entropy decoder configured with the processor to entropy decode the plurality of portions based on wavefront parallel processing (WPP), each portion including a start syntax element indicating a location in the image where decoding of the respective portion begins, the plurality of portions being grouped into one or more WPP sub-streams, and for each of the one or more WPP sub-streams, a first portion in slice order within each WPP sub-stream begins at a left edge of the image as indicated by the start syntax element of the first portion, and a current portion of the plurality of portions is entropy decoded in one of at least two modes, the entropy decoder comprising: and configured to decode data associated with the current portion using context-adaptive entropy decoding to obtain a residual signal according to a first mode of the at least two modes, the context-adaptive entropy decoding including deriving context across portion boundaries and initializing the symbol probabilities associated with the current portion in dependence on a stored state of symbol probabilities of previously decoded portions, the entropy decoder, when initializing the symbol probabilities associated with the current portion according to the first mode, in response to determining that the first coded block associated with the current portion is the first coded block from the left end of a first row of the image in raster scan order, initialize the symbol probabilities associated with the current portion based on stored symbol probabilities obtained during context adaptive entropy decoding of the previously decoded portion from the left end of a second row of the image to a second coded block, where the second row is associated with the previously decoded portion and the second coded block is spatially adjacent to and to the right of a first coded block of the second row, otherwise initialize the symbol probabilities associated with the current portion based on symbol probabilities obtained at the end of context adaptive entropy decoding of the previously decoded portion; an entropy decoder configured to decode data related to the current portion using context-adaptive entropy decoding according to at least a second of two modes to obtain a residual signal, where the context-adaptive entropy decoding includes restricting the derivation of the context from crossing the portion boundary and initializing the symbol probabilities independent of a previously decoded portion, and configured to store the symbol probabilities obtained during context-adaptive entropy decoding of the previously decoded portion up to the second coding block of the second row associated with the previously decoded portion according to the raster scan order, where the image is partitioned into a plurality of portions, and the plurality of portions are slices or slice segments; a predictor configured to generate, with the processor, a prediction signal from the data stream based on prediction parameters associated with the current portion; a reconstruction module configured to reconstruct, using the processor, a portion of the image related to the current portion based on the residual signal and the prediction signal; A decoder comprising:

2. 2. The decoder of claim 1, wherein the image is partitioned into coding blocks arranged in rows and columns and having the raster scan order defined between each other, each of the portions being a slice, and the decoder is configured to associate each slice with a contiguous subset of the coding blocks in the raster scan order, the subsets following each other along the raster scan order according to slice order.

3. 2. The decoder of claim 1, wherein, when initializing the symbol probabilities associated with the current portion according to the first mode, the entropy decoder is configured to initialize the symbol probabilities associated with the current portion based on symbol probabilities obtained at the end of context-adaptive entropy decoding of the previously decoded portion in response to determining that the first coded block associated with the current portion is not the first coded block of the first row.

4. 2. The decoder of claim 1, wherein the entropy decoder is configured to be responsive to a syntax element portion in the current portion, the syntax element portion indicating whether the first mode or the second mode is to be used for decoding.

5. 5. The decoder of claim 4, wherein the entropy decoder is configured to operate in one of at least two generic operating modes in response to generic syntax elements in the data stream, and to perform in response to the syntax element portions of each portion in a first generic operating mode, and to use another mode of the at least two modes other than the first mode in a second generic operating mode.

6. 2. The decoder of claim 1, wherein the entropy decoder is configured to continue successively updating the symbol probabilities from the beginning to the end of the current portion according to the first and second modes.

7. 2. The decoder of claim 1, wherein the entropy decoder is configured to preserve symbol probabilities obtained during context-adaptive entropy decoding of the previously decoded portion up to an end of the previously decoded portion.

8. The decoder of claim 1 , wherein the entropy decoder is configured to restrict predictive decoding in the first and second modes to tiles into which the image is subdivided.

9. 2. The decoder of claim 1, wherein the entropy decoder is configured to copy for the current portion a portion of a slice header syntax from a previous portion decoded in the second mode in accordance with the first mode of the at least two modes.

10. The decoder of claim 1 , wherein the entropy decoder is configured to stagger and parallel decode the WPP sub-streams and to begin the decoding of the WPP sub-streams sequentially according to the slice order.

11. 1. An encoder for encoding an image into a data stream, the image being partitioned into a plurality of parts, the encoder comprising: A processor; a residual module configured to generate, using the processor, a residual signal associated with a current one of the portions of the image; a predictor configured to generate, with the processor, prediction parameters based on a prediction signal, the prediction parameters being encoded into the data stream; an entropy encoder configured to entropy encode, using the processor, the plurality of portions into the data stream based on wavefront parallel processing (WPP), each of the portions including a start syntax element indicating a position in the image where encoding of the portion begins, the portions being grouped into one or more WPP sub-streams, and for each of the one or more WPP sub-streams, a first portion in slice order within each WPP sub-stream begins at a left edge of the image as indicated by the start syntax element of the first portion, and the residual signal associated with the current portion is entropy encoded in one of at least two modes, the entropy encoder configured to: If the current portion is coded according to a first of the at least two modes, the entropy encoder is configured to code the residual signal using context-adaptive entropy coding, including deriving a context across portion boundaries and initializing the symbol probabilities associated with the current portion in dependence on a stored state of symbol probabilities of previously coded portions, wherein upon initialization of the symbol probabilities associated with the current portion according to the first mode, the entropy encoder: In response to determining that the first coding block associated with the current portion is a first coding block from the left end of a first row of the image in raster scan order, the method is configured to initialize the symbol probabilities associated with the current portion based on the stored symbol probabilities obtained during context-adaptive entropy encoding of the previously coded portion from the left end of a second row of the image to a second coding block, where the second row is associated with the previously coded portion and the second coding block is spatially adjacent to and to the right of a first coding block of the second row, otherwise, to initialize the symbol probabilities associated with the current portion based on the stored symbol probabilities obtained at the end of context-adaptive entropy encoding of the previously coded portion. an entropy encoder configured to initialize symbol probabilities, if the current portion is coded according to a second of the at least two modes, to code the residual signal using context adaptive entropy coding and to restrict the derivation of the context from crossing the portion boundary, to initialize the symbol probabilities independently of any previously coded portion, and to store the symbol probabilities obtained when context adaptive entropy coding the previously coded portion up to the second coding block of the second row associated with the previously coded portion according to the raster scan order, wherein the image is partitioned into a plurality of portions, the plurality of portions being slices or slice segments; An encoder comprising:

12. 12. The encoder of claim 11, wherein the image is partitioned into coding blocks arranged in rows and columns and having the raster scan order defined between each other, each of the portions being a slice, and the encoder is configured to associate each slice with a contiguous subset of the coding blocks in the raster scan order, the subsets following each other along the raster scan order according to slice order.

13. 12. The encoder of claim 11, wherein, in initializing the symbol probabilities associated with the current portion according to the first mode, the entropy encoder is configured to initialize the symbol probabilities associated with the current portion based on symbol probabilities obtained at the end of context-adaptive entropy coding of the previously coded portion, in response to determining that the first coded block associated with the current portion is not the first coded block of the first row.

14. 12. The encoder of claim 11, wherein the entropy encoder is configured to encode a syntax element portion within the current portion of the plurality of portions, the syntax element portion indicating whether the first mode or the second mode is to be used for encoding.

15. The encoder of claim 14, wherein the entropy encoder is configured to determine a generic syntax element, write the generic syntax element to the data stream, and operate in one of at least two generic operation modes depending on the generic syntax element, i.e., in a first generic operation mode, perform encoding of the syntax element portion of each part, and in a second generic operation mode, unavoidably use another mode other than the first mode of the at least two modes.

16. The encoder of claim 11 , wherein the entropy encoder is configured to continue successively updating the symbol probabilities from the beginning to the end of the current portion according to the first and second modes.

17. The encoder of claim 11 , wherein the entropy encoder is configured to preserve symbol probabilities obtained when context-adaptive entropy encoding the previously encoded portion up to an end of the previously encoded portion.

18. The encoder of claim 11 , wherein the entropy encoder is configured to restrict predictive coding in the first and second modes to tiles into which the image is subdivided.

19. 1. A method for decoding information from a data stream to reconstruct an image partitioned into a plurality of parts, the method comprising: entropy decoding the plurality of portions based on wavefront parallel processing (WPP), each portion including a start syntax element indicating a location in the image where decoding of the respective portion begins, the plurality of portions being grouped into one or more WPP substreams, and for each of the one or more WPP substreams, a first portion in slice order within each WPP substream begins at a left edge of the image as indicated by the start syntax element of the first portion, and a current portion of the plurality of portions being entropy decoded in one of at least two modes, the entropy decoding step comprising: decoding data associated with the current portion from the data stream using context-adaptive entropy decoding according to a first mode of the at least two modes to obtain a residual signal, wherein the context-adaptive entropy decoding includes deriving context across portion boundaries and initializing the symbol probabilities associated with the current portion in dependence on a stored state of symbol probabilities of previously decoded portions, and upon initialization of the symbol probabilities associated with the current portion according to the first mode, the entropy decoding includes: responsive to determining that the first coded block associated with the current portion is the first coded block from the left end of a first row of the image in raster scan order, initializing the symbol probabilities associated with the current portion based on the stored symbol probabilities obtained during context adaptive entropy decoding of the previously decoded portion from the left end of a second row of the image to a second coded block, where the second row is associated with the previously decoded portion and the second coded block is spatially adjacent to and to the right of the first coded block of the second row; otherwise, initializing the symbol probabilities associated with the current portion based on the symbol probabilities obtained at the end of context adaptive entropy decoding of the previously decoded portion; decoding data related to the current portion from the data stream using context-adaptive entropy decoding according to a second mode of a first mode of a second decoding mode to obtain a residual signal, wherein the context-adaptive entropy decoding includes restricting the derivation of the context from crossing the portion boundary and initializing the symbol probabilities independent of a previously decoded portion; storing the symbol probabilities obtained during context-adaptive entropy decoding of the previously decoded portion up to the second coding block of the second row associated with the previously decoded portion according to the raster scan order, wherein the image is partitioned into a plurality of portions, the plurality of portions being slices or slice segments; generating a prediction signal from said data stream based on prediction parameters associated with said current portion; reconstructing a portion of an image related to the current portion of the image based on the residual signal and the prediction signal; A method comprising:

20. 20. The method of claim 19, wherein the image is partitioned into coding blocks arranged in rows and columns and having the raster scan order defined between each other, and each of the plurality of portions is a slice, and the method further comprises associating each slice with a contiguous subset of the coding blocks in the raster scan order such that the subsets follow one another along the raster scan order according to slice order.

21. 20. The method of claim 19, wherein when initializing the symbol probabilities associated with the current portion according to the first mode, the entropy decoding step includes, in response to determining that the first coded block associated with the current portion is not the first coded block of the first row, initializing the symbol probabilities associated with the current portion based on symbol probabilities obtained at the end of context-adaptive entropy decoding of the previously decoded portion.

22. 20. The method of claim 19, wherein the entropy decoding step includes operating in one of at least two generic operating modes in response to generic syntax elements in the data stream, and performing the entropy decoding step in response to syntax element portions of each portion in a first generic operating mode, and using another mode of the at least two modes other than the first mode in a second generic operating mode.

23. 20. The method of claim 19, wherein the entropy decoding step comprises continuously updating the symbol probabilities from the beginning to the end of the current portion according to the first and second modes.

24. 20. The method of claim 19, wherein the entropy decoding step comprises storing symbol probabilities obtained when context-adaptive entropy decoding the previously decoded portion up to an end of the previously decoded portion.

25. 20. The method of claim 19, wherein the entropy decoding step comprises copying, for the current portion, a portion of a slice header syntax from a previous portion decoded in a second mode according to the first mode of the at least two modes.

Images