HK1198235B

HK1198235B - Signaling of deblocking filter parameters in video coding

Info

Publication number: HK1198235B
Application number: HK14111633.4A
Authority: HK
Inventors: 格尔特．范德奥维拉; 王益魁; 马尔塔.卡切维奇
Original assignee: 高通股份有限公司
Priority date: 2012-01-19
Filing date: 2013-01-18
Publication date: 2018-05-04

Description

Signaling deblocking filter parameters in video coding

The present application claims the benefit of united states provisional application No. 61/588,454, filed on day 1, 19, 2012, united states provisional application No. 61/593,015, filed on day 1, 31, 2012, and united states provisional application No. 61/620,339, filed on day 4, 2012, the entire contents of each of which are incorporated herein by reference.

Technical Field

This disclosure relates to video coding, and more particularly, to deblocking video data.

Background

Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, Personal Digital Assistants (PDAs), laptop or desktop computers, tablet computers, electronic book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video gaming consoles, cellular or satellite radio telephones, so-called "smart phones," video conferencing devices, video streaming devices, and the like. Digital video devices implement video compression techniques such as those described in the standards and extensions of the standards defined by the MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4 part 10 Advanced Video Coding (AVC), the High Efficiency Video Coding (HEVC) standard currently under development. Video devices may more efficiently transmit, receive, encode, decode, and/or store digital video information by implementing such video compression techniques.

Video compression techniques perform spatial (intra-picture) prediction and/or temporal (inter-picture) prediction to reduce or remove redundancy inherent in video sequences. For block-based video coding, a video slice (i.e., a video frame or a portion of a video frame) may be partitioned into video blocks, which may also be referred to as treeblocks, Coding Units (CUs), and/or coding nodes. Video blocks in an intra-coded (I) slice of a picture are encoded relative to reference samples in neighboring blocks in the same picture using spatial prediction. Video blocks in inter-coded (P or B) slices of a picture may use spatial prediction with respect to reference samples in neighboring blocks in the same picture or temporal prediction with respect to reference samples in other reference pictures. A picture may be referred to as a frame and a reference picture may be referred to as a reference frame.

Spatial or temporal prediction produces a predictive block for a block to be coded. The residual data represents pixel differences between the original block to be coded and the predictive block. An inter-coded block is encoded according to a motion vector that points to a block of reference samples that forms a predictive block and residual data that indicates a difference between the coded block and the predictive block. An intra-coded block is encoded according to intra-coding modes and residual data that define how the prediction block is created. For further compression, the residual data may be transformed from the pixel domain to a transform domain, producing residual transform coefficients, which may then be quantized. The quantized transform coefficients initially arranged in a two-dimensional array may be sequentially scanned to generate a one-dimensional vector of transform coefficients, and entropy coding may be applied to achieve more compression.

Disclosure of Invention

In general, techniques are described for signaling deblocking filter parameters for a current slice of video data with reduced bitstream overhead. The deblocking filter parameters define a deblocking filter for removal of blocking artifacts from decoded video blocks of the slice. The deblocking filter parameters include a syntax element defined to indicate whether deblocking filtering is enabled or disabled, and if enabled, to indicate a threshold value t_cThe deblocking filter parameters may be coded in one or more of a picture layer parameter set and a slice header.

The techniques may reduce the number of bits used to signal deblocking filter parameters by: coding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header, and coding only a second syntax element in the slice header when deblocking filter parameters are present in both the picture layer parameter set and the slice header. The second syntax element is defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header is used to define a deblocking filter applied to a current video slice. In this case, when deblocking filter parameters are present in only one of the picture layer parameter set or the slice header, a video encoder may eliminate encoding of the second syntax element in the slice header, and a video decoder may determine, based on the first syntax element, that the second syntax element is not present in the slice header to be decoded.

In one example, this disclosure is directed to a method of decoding video data, the method comprising: decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; decoding a second syntax element in the slice header when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and determine that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In another example, this disclosure is directed to a video decoding device comprising: a memory storing video data; and a processor configured to decode a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header. The processor is configured to, when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, decode a second syntax element in the slice header that is defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice. In another aspect, the processor is configured to determine that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In a further example, this disclosure is directed to a video decoding device comprising: means for decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; means for decoding a second syntax element in the slice header when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and means for determining that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In another example, this disclosure is directed to a computer-readable medium comprising instructions for: decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; decoding a second syntax element in the slice header when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and determine that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In an additional example, this disclosure is directed to a method of encoding video data, the method comprising: encoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; encoding a second syntax element in the slice header when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, eliminating encoding of the second syntax element in the slice header.

In a further example, this disclosure is directed to a video encoding device comprising: a memory storing video data; and a processor configured to encode a first syntax element defined to indicate whether deblocking filter parameters are present in both the picture layer parameter set and the slice header. The processor is configured to, when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, encode a second syntax element in the slice header that is defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice. In another aspect, the processor is configured to eliminate encoding of the second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In another example, this disclosure is directed to a video encoding device comprising: means for encoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, means for encoding a second syntax element in the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and means for eliminating encoding of the second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

In a further example, this disclosure is directed to a computer-readable medium comprising instructions for: decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header; encoding a second syntax element in the slice header when the first syntax element indicates that the deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, eliminating encoding of the second syntax element in the slice header.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

Drawings

Fig. 1 is a block diagram illustrating an example video encoding and decoding system that may code deblocking filter parameters in accordance with the techniques described in this disclosure.

Fig. 2 is a block diagram illustrating an example of a video encoder that may implement the techniques described in this disclosure to encode deblocking filter parameters with reduced bitstream overhead.

Fig. 3 is a block diagram illustrating an example of a video decoder that may implement the techniques described in this disclosure to decode deblocking filter parameters used to define deblocking filters applied to video slices.

Fig. 4 is a block diagram illustrating components of an exemplary deblocking filter defined based on deblocking filter parameters signaled in accordance with the techniques described in this disclosure.

Fig. 5 is a conceptual diagram illustrating pixel locations near the edges of video blocks between sub-blocks.

Fig. 6 is a flow diagram illustrating example operations for encoding deblocking filter parameters for a current video slice with reduced bitstream overhead in accordance with the techniques described in this disclosure.

Fig. 7 is a flow diagram illustrating example operations for decoding deblocking filter parameters for a current video slice with reduced bitstream overhead in accordance with the techniques described in this disclosure.

Fig. 8 is a flow diagram illustrating example operations of encoding deblocking filter parameters for a current video slice in a Picture Parameter Set (PPS) that may be overridden by deblocking filter parameters in a slice header.

Fig. 9 is a flow diagram illustrating example operations of decoding deblocking filter parameters of a current video slice in a Picture Parameter Set (PPS) that may be overridden by deblocking filter parameters in a slice header.

Detailed Description

Some example techniques of this disclosure reduce the number of bits used to signal deblocking filter parameters for a current video slice by: coding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header, and coding only a second syntax element in the slice header when deblocking filter parameters are present in both the picture layer parameter set and the slice header. The second syntax element is defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header is used to define a deblocking filter applied to a current video slice. In this case, when deblocking filter parameters are present in only one of the picture layer parameter set or the slice header, the video encoding device may eliminate encoding of the second syntax element in the slice header, and the video decoding device may determine, based on the first syntax element, that the second syntax element is not present in the slice header to be decoded.

Fig. 1 is a block diagram illustrating an example video encoding and decoding system 10 that may code deblocking filter parameters in accordance with the techniques described in this disclosure. As shown in fig. 1, system 10 includes a source device 12 that generates encoded video data to be decoded by a destination device 14 at a later time. Source device 12 and destination device 14 may comprise any of a wide variety of devices, including desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets (e.g., so-called "smart" phones), so-called "smart" tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, and so forth. In some cases, source device 12 and destination device 14 may be equipped for wireless communication.

Destination device 14 may receive encoded video data to be decoded over link 16. Link 16 may comprise any type of media or device capable of moving encoded video data from source device 12 to destination device 14. In one example, link 16 may comprise a communication medium to enable source device 12 to transmit encoded video data directly to destination device 14 in real-time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to destination device 14. The communication medium may comprise any wireless or wired communication medium, such as a Radio Frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the internet. The communication medium may include a router, switch, base station, or any other apparatus that may be used to facilitate communications from source device 12 to destination device 14.

In another example, link 16 may correspond to a storage medium that may store encoded video data generated by source device 12 and that destination device 14 may access via disk access or card access, as desired. The storage medium may comprise any of a variety of locally accessed data storage media such as blu-ray discs, DVDs, CD-ROMs, flash memory, or any other suitable digital storage medium for storing encoded video data. In a further example, link 16 may correspond to a file server or another intermediate storage medium that may hold encoded video generated by source device 12 and that destination device 14 may access via streaming or download, as needed. The file server may be any type of server capable of storing encoded video data and transmitting the encoded video data to destination device 14, with example file servers including a web server (e.g., for a website), an FTP server, a Network Attached Storage (NAS) device, or a local disk drive. Destination device 14 may access the encoded video data over any standard data connection, including an internet connection. This may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., DSL, cable modem, etc.), or a combination of both suitable for accessing encoded video data stored on a file server. The transmission of the encoded video data from the file server may be a streaming transmission, a download transmission, or a combination of both.

The techniques of this disclosure are not necessarily limited to wireless applications or environments. The techniques may be applied to video coding in support of any of a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, streaming video transmission (e.g., via the internet), encoding of digital video for storage on a data storage medium, decoding of digital video stored on a data storage medium, or other applications. In some examples, system 10 may be configured to support one-way or two-way video transmission to support applications such as video streaming, video playback, video broadcasting, and/or video telephony.

In the example of fig. 1, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. In some cases, output interface 22 may include a modulator/demodulator (modem) and/or a transmitter. In source device 12, video source 18 may include a source such as a video capture device (e.g., a video camera, a video archive containing previously captured video, a video feed interface to receive video from a video content provider), and/or a source of a computer graphics system used to generate computer graphics data as the source video, or a combination of such sources. As one example, if video source 18 is a video camera, source device 12 and destination device 14 may form so-called camera phones or video phones. In general, however, the techniques described in this disclosure may be applicable to video coding, and may be applicable to wireless and/or wired applications.

Captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video data may be transmitted directly to destination device 14 via output interface 22 of source device 12. The encoded video data may also be stored onto a storage medium or file server for later access by destination device 14 for decoding and/or playback.

Destination device 14 includes input interface 28, video decoder 30, and display device 32. In some cases, input interface 28 may include a receiver and/or a modulator. Input interface 28 of destination device 14 receives the encoded video data over link 16. The encoded video data communicated over link 16 or provided on the data storage medium may include a variety of syntax elements generated by video encoder 20 for use by a video decoder, such as video decoder 30, in decoding the video data. Such syntax elements may be included with encoded video data transmitted on a communication medium, stored on a storage medium, or stored on a file server.

The display device 32 may be integrated with the destination device 14 or external to the destination device 14. In some examples, destination device 14 may include an integrated display device and also be configured to interface with an external display device. In other examples, destination device 14 may be a display device. In general, display device 32 displays the decoded video data to a user, and may comprise any of a variety of display devices, such as a Liquid Crystal Display (LCD), a plasma display, an Organic Light Emitting Diode (OLED) display, or another type of display device.

Video encoder 20 and video decoder 30 may operate according to a video compression standard, such as the High Efficiency Video Coding (HEVC) standard currently under development, and may conform to the HEVC test model (HM). Alternatively, video encoder 20 and video decoder 30 may operate in accordance with other proprietary or industry standards, such as the ITU-T h.264 standard (alternatively referred to as MPEG4 part 10, Advanced Video Coding (AVC)) or an extension of such a standard. However, the techniques of this disclosure are not limited to any particular coding standard. Other examples of video compression standards include MPEG-2 and ITU-T H.263.

Although not shown in fig. 1, in some aspects, video encoder 20 and video decoder 30 may each be integrated with an audio encoder and decoder, and may include appropriate MUX-DEMUX units, or other hardware and software, to handle encoding of both audio and video in a common data stream or separate data streams. In some examples, the MUX-DEMUX unit may conform to the ITU h.223 multiplexer protocol or other protocols such as the User Datagram Protocol (UDP), if applicable.

Video encoder 20 and video decoder 30 may each be implemented as any of a variety of suitable encoder circuits, such as one or more microprocessors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), discrete logic, software, hardware, firmware or any combinations thereof. When the techniques are implemented in part in software, a device may store instructions for the software in a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the techniques of this disclosure. Each of video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, either of which may be integrated as part of a combined encoder/decoder (CODEC) in the respective device.

The joint collaborative group of video coding (JCT-VC) has focused on the development of the HEVC standard. HEVC standardization work is based on an evolution model of the video coding device known as the HEVC test model (HM). The HM assumes additional capabilities of the video coding device relative to existing devices in accordance with, for example, ITU-T H.264/AVC. For example, although h.264 provides nine intra-prediction encoding modes, the HM may provide up to thirty-three intra-prediction encoding modes.

In general, the working model of the HM describes a video frame or picture that may be divided into a sequence of treeblocks or Largest Coding Units (LCUs) that include both luma and chroma samples. Treeblocks have a similar purpose as macroblocks of the h.264 standard. A slice includes a number of consecutive treeblocks in coding order. A video frame or picture may be partitioned into one or more slices. Each treeblock may be split into Coding Units (CUs) according to a quadtree. For example, a treeblock that is the root node of a quadtree may be split into four child nodes, and each child node may in turn be a parent node, and into the other four child nodes. The final, non-split child node, which is a leaf node of the quadtree, comprises a coding node, i.e., a coded video block. Syntax data associated with a coded bitstream may define a maximum number of times a treeblock may be split, and may also define a minimum size of a coding node.

A CU includes a coding node and a Prediction Unit (PU) and a Transform Unit (TU) associated with the coding node. The size of the CU corresponds to the size of the coding node. The size of a CU may range from 8 x 8 pixels up to a size of a treeblock with a maximum of 64 x 64 pixels or more. Each CU may contain one or more PUs and one or more TUs. Syntax data associated with a CU may describe, for example, partitioning the CU into one or more PUs. The partition mode may be different between whether the CU is skipped, coded by direct mode, coded by intra prediction mode, or coded by inter prediction mode. The shape of the PU may be partitioned into squares, non-squares. Syntax data associated with a CU may also describe partitioning the CU into one or more TUs, e.g., according to a quadtree. The shape of a TU may be divided into squares, non-squares.

In general, a PU includes data related to a prediction process. For example, when intra-mode encoding a PU, the PU may include data describing an intra-prediction mode of the PU. As another example, when inter-mode encoding a PU, the PU may include data defining a motion vector for the PU. The data defining the motion vector for a PU may describe, for example, a horizontal component of the motion vector, a vertical component of the motion vector, a resolution of the motion vector (e.g., one-quarter pixel precision or one-eighth pixel precision), a reference frame to which the motion vector points, and/or a reference picture list (e.g., list 0 or list 1) of the motion vector.

In general, TUs are used for transform and quantization processes. A CU with one or more PUs may also include one or more TUs. After prediction, video encoder 20 may calculate residual values corresponding to the PUs. The residual values comprise pixel difference values that may be transformed into transform coefficients, quantized using TUs, and scanned to generate serialized transform coefficients for entropy coding. This disclosure generally refers to the term "video block" to a coding node of a CU. In some particular cases, this disclosure may also use the term "video block" to refer to treeblocks, i.e., LCUs or CUs, that include coding nodes and PUs and TUs.

A video sequence typically includes a series of video frames or pictures. A group of pictures (GOP) generally includes a series of one or more video pictures. The GOP may include syntax data in a header of the GOP, a header of one or more of the pictures, or elsewhere, that describes the number of pictures included in the GOP. Each slice of a picture may include slice syntax data that describes an encoding mode for the respective slice. The audio encoder 20 typically operates on video blocks within individual video slices in order to encode the video data. The video block may correspond to a coding node within a CU. The video blocks may have fixed or varying sizes, and may be different sizes according to a specified coding standard.

As an example, the HM supports prediction in various PU sizes. Assuming that the size of a particular CU is 2N × 2N, the HM supports intra prediction in PU sizes of 2N × 2N or N × N, and inter prediction in symmetric PU sizes of 2N × 2N, 2N × N, N × 2N, or N × N. The HM also supports asymmetric partitioning for inter prediction in PU sizes of 2 nxnu, 2 nxnd, nL × 2N, and nR × 2N. In asymmetric partitioning, one direction of a CU is not partitioned, while the other direction is partitioned into 25% and 75%. The portion of the CU corresponding to the 25% partition is indicated by an indication of "n" followed by "up", "down", "left", or "right". Thus, for example, "2N × nU" refers to a 2N × 2N CU that is horizontally partitioned with 2N × 0.5N PU at the top and 2N × 1.5N PU at the bottom.

In this disclosure, "nxn" and "N by N" may be used interchangeably to refer to the pixel size of a video block, such as 16 x 16 pixels or 16 by 16 pixels, in terms of vertical and horizontal dimensions. In general, a 16 × 16 block will have 16 pixels in the vertical direction (y 16) and 16 pixels in the horizontal direction (x 16). Likewise, an nxn block typically has N pixels in the vertical direction and N pixels in the horizontal direction, where N represents a non-negative integer value. The pixels in a block may be arranged in rows and columns. Further, the block does not necessarily have to have the same number of pixels in the horizontal direction as in the vertical direction. For example, a block may comprise N × M pixels, where M is not necessarily equal to N.

After intra-prediction coding or inter-prediction coding using PUs of the CU, video encoder 20 may calculate residual data for the TUs of the CU. A PU may comprise pixel data in the spatial domain, also referred to as the pixel domain, and a TU may comprise coefficients in the transform domain (e.g., after applying a transform such as a Discrete Cosine Transform (DCT), an integer transform, a wavelet transform, or a conceptually similar transform to the residual video data). The residual data may correspond to pixel differences between pixels of the unencoded picture and prediction values corresponding to the PU. Video encoder 20 may form TUs that include the residual data of the CU, and then transform the TUs to generate transform coefficients for the CU.

After any transform is performed to generate transform coefficients, video encoder 20 may perform quantization of the transform coefficients. Quantization generally refers to a process of quantizing transform coefficients to possibly reduce the amount of data used to represent the coefficients, thereby providing further compression. The quantization process may reduce the bit depth associated with some or all of the coefficients.

In some examples, video encoder 20 may utilize a predefined scan order to scan the quantized transform coefficients to generate a serialized vector that may be entropy encoded. In other examples, video encoder 20 may perform adaptive scanning. After scanning the quantized transform coefficients to form a one-dimensional vector, video encoder 20 may entropy encode the one-dimensional vector, e.g., according to Context Adaptive Variable Length Coding (CAVLC), Context Adaptive Binary Arithmetic Coding (CABAC), syntax-based context adaptive binary arithmetic coding (SBAC), probability interval partition entropy coding (PIPE), or another entropy encoding method. Video encoder 20 may also entropy code syntax elements associated with the encoded video data for use by video decoder 30 in decoding the video data.

To perform CABAC, video encoder 20 may assign contexts within the context model to symbols to be transmitted. The context may relate to, for example, whether neighboring values of a symbol are non-zero. To perform CAVLC, video encoder 20 may select a variable length code for a symbol to be transmitted. Codewords in VLC may be constructed such that relatively shorter codes correspond to more probable symbols and longer codes correspond to less probable symbols. In this way, bit savings may be achieved using VLC as compared to, for example, using codewords of equal length for each symbol to be transmitted. The probability determination may be based on the context assigned to the symbol.

In addition to signaling encoded video data to video decoder 30 in destination device 14 in the bitstream, video encoder 20 may decode the encoded video data and reconstruct blocks within a video frame or picture for use as reference data during an intra-prediction or inter-prediction process for subsequently coded blocks. After a video frame or picture is divided into blocks (e.g., LCUs and their sub-CUs), the blocks are encoded, and then decoded, however, perceptible artifacts may occur at the edges between the blocks. To remove these "blockiness" artifacts, video encoder 20 may apply a deblocking filter to the decoded video block prior to storage as a reference block. Similarly, video decoder 30 may be configured to decode video data received in the bitstream from video encoder 20 of source device 12, and apply the same or similar deblocking filters to the decoded video data for display of the video data and for use of the video data as reference data for subsequently decoded video data.

Deblocking filtering performed by a video coding device, such as video encoder 20 or video decoder 30, prior to storing the processed data for use as reference data is generally referred to as "in-loop" filtering, since the filtering is performed within the coding loop. By configuring both video encoder 20 and video decoder 30 to apply the same deblocking techniques, the video coding devices may be synchronized such that deblocking does not introduce errors for subsequently coded video data that uses the deblocked video data as reference data.

Video encoder 20 and video decoder 30 are generally configured to determine, for each edge of a video block that includes PU and TU edges, whether to apply a deblocking filter to deblock the edge. A video coding device may be configured to determine whether to deblock an edge based on an analysis of one or more lines of pixels perpendicular to the edge (e.g., a line of 8 pixels). Thus, for example, for a vertical edge, a video coding device may determine whether to deblock the edge by examining the four pixels to the left and the four pixels to the right of the edge along a common line. The number of pixels selected generally corresponds to the smallest block for deblocking, e.g., 8 x 8 pixels. In this way, the line of pixels used for analysis runs across the PU and TU edges of the video block that have pixels on either side of the edge (e.g., left and right of the edge and above and below the edge). The line of pixels used to analyze whether to perform deblocking on an edge is also referred to as a set of support pixels, or simply "support.

A video coding device may be configured to perform deblocking decision functions based on support for particular edges. In general, the deblocking decision function is configured to detect high frequency variations within the support pixels. Typically, when high frequency variations are detected, the deblocking decision function provides an indication that perceptible artifacts are present at the edges and that deblocking should be done. The deblocking decision function may also be configured to determine, based on the support, a type and strength of a deblocking filter to be applied to the edge. The type and strength of the deblocking filter may be defined by a threshold t_cAnd β.

This disclosure describes techniques for signaling deblocking filter parameters for a current slice of video data with reduced bitstream overhead. The deblocking filter parameters define a deblocking filter for reducing or removing blocking artifacts from decoded video blocks of a current slice. The deblocking filter parameters include a syntax element configured to indicate whether deblocking filtering is enabled or disabled, and if enabled, a threshold value t_cAnd β deblocking filter parameter offset。

Deblocking filter parameters may be coded in one or more of a picture layer parameter set and a slice header. The picture layer parameter set may comprise a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS). A PPS is a picture layer parameter set that contains data that is unlikely to change between pictures that relate to the PPS. APS is a picture layer parameter set intended for use with picture adaptation data that is likely to vary between pictures. In one example, the APS includes parameters for a deblocking filter, an Adaptive Loop Filter (ALF), and a Sample Adaptive Offset (SAO). Including these parameters in the APS rather than the PPS may reduce the number of bits transmitted for the video sequence, as constant PPS data need not be repeated as deblocking filter, ALF, or SAO parameters change.

Fig. 2 is a block diagram illustrating an example of a video encoder 20 that may implement the techniques described in this disclosure to encode deblocking filter parameters with reduced bitstream overhead. Video encoder 20 may perform intra-coding and inter-coding of video blocks within a video slice. Intra-coding relies on spatial prediction to reduce or remove spatial redundancy in video within a given video frame or picture. Inter-coding relies on temporal prediction to reduce or remove temporal redundancy in video within adjacent frames or pictures of a video sequence. Intra-mode (I-mode) may refer to any of a number of space-based compression modes. An inter mode, such as uni-directional prediction (P-mode) or bi-directional prediction (B-mode), may refer to any of several time-based compression modes.

In the example of fig. 2, video encoder 20 includes mode select unit 40, motion estimation unit 42, motion compensation unit 44, intra prediction processing unit 46, reference picture memory 64, summer 50, transform processing unit 52, quantization unit 54, and entropy encoding unit 56. For video block reconstruction, video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and a summer 62. A deblocking filter 63 is also included to filter block boundaries to remove blockiness artifacts from the reconstructed video block.

As shown in fig. 2, video encoder 20 receives a current video block to be encoded within a video slice. A slice may be divided into a plurality of video blocks. Mode select unit 40 may select one of the coding modes (intra or inter) for the current video block based on the error result. If intra or inter mode is selected, mode select unit 40 provides the resulting intra-coded or inter-coded blocks to summer 50 to generate residual block data, and to summer 62 to reconstruct the encoded blocks for use as reference blocks within reference pictures stored in reference picture memory 64. Intra-prediction processing unit 46 performs intra-prediction coding of the current video block relative to one or more neighboring blocks in the same frame or slice as the current block to be coded to provide spatial compression. Motion estimation unit 42 and motion compensation unit 44 perform inter-prediction coding of the current video block relative to one or more prediction blocks in one or more reference pictures to provide temporal compression.

In the case of inter-coding, motion estimation unit 42 may be configured to determine an inter-prediction mode for a video slice according to a predetermined mode of a video sequence. The predetermined pattern may designate a video slice in the sequence as a P-slice or a B-slice. Motion estimation unit 42 and motion compensation unit 44 may be highly integrated, but are illustrated separately for conceptual purposes. Motion estimation, performed by motion estimation unit 42, is the process of generating motion vectors that estimate the motion of video blocks. A motion vector, for example, may indicate a displacement of a PU of a video block within a current video frame relative to a prediction block or picture within a reference picture.

A prediction block is a block of PUs found to closely match a video block to be coded in terms of pixel differences, which may be determined by Sum of Absolute Differences (SAD), Sum of Squared Differences (SSD), or other difference metrics. In some examples, video encoder 20 may calculate values for sub-integer pixel positions of reference pictures stored in reference picture memory 64. For example, video encoder 20 may calculate values for a quarter-pixel position, an eighth-pixel position, or other fractional-pixel positions of a reference picture. Thus, motion estimation unit 42 may perform a motion search relative to the full pixel position and the fractional pixel position and output a motion vector at the fractional pixel position.

Motion estimation unit 42 calculates motion vectors for PUs of video blocks in inter-coded slices by comparing the locations of the PUs to locations of prediction blocks of reference pictures. The reference picture may be selected from a first reference picture list (list 0) or a second reference picture list (list 1), each of which identifies one or more reference pictures stored in reference picture memory 64. Motion estimation unit 42 sends the calculated motion vectors to entropy encoding unit 56 and motion compensation unit 44.

The motion compensation performed by motion compensation unit 44 may involve obtaining or generating a prediction block based on a motion vector determined by motion estimation. Upon receiving the motion vector for the PU of the current video block, motion compensation unit 44 may locate the prediction block to which the motion vector points in one of the reference picture lists. Video encoder 20 forms a residual video block by subtracting pixel values of a prediction block from pixel values of the current video block being coded, forming pixel difference values. The pixel difference values form residual data of the block and may include both luminance difference components and chrominance difference components. Summer 50 represents the component that performs this subtraction operation. Motion compensation unit 44 may also generate syntax elements associated with the video blocks and the video slice for use by video decoder 30 in decoding the video blocks of the video slice.

After motion compensation unit 44 generates the prediction block for the current video block, video encoder 20 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be included in one or more TUs and applied to transform processing unit 52. Transform processing unit 52 may use a transform, such as a Discrete Cosine Transform (DCT) or a conceptually similar transform, to transform the residual video data into residual transform coefficients. Transform processing unit 52 may convert the residual video data from the pixel domain to a transform domain (e.g., the frequency domain).

Transform processing unit 52 may send the resulting transform coefficients to quantization unit 54. Quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all of the coefficients. The quantization level may be modified by adjusting a quantization parameter. In some examples, quantization unit 54 may then perform a scan of a matrix that includes quantized transform coefficients. Alternatively, entropy encoding unit 56 may perform scanning.

After quantization, entropy encoding unit 56 entropy encodes the quantized transform coefficients. For example, entropy encoding unit 56 may perform Context Adaptive Variable Length Coding (CAVLC), Context Adaptive Binary Arithmetic Coding (CABAC), or another entropy encoding technique. Following entropy encoding by entropy encoding unit 56, the encoded bitstream may be transmitted to video decoder 30 or archived for later transmission or retrieval by video decoder 30. Entropy encoding unit 56 may also entropy encode the motion vectors and other syntax elements of the current video slice being coded.

Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain for a reference block that is later used as a reference picture. Motion compensation unit 44 may calculate the reference block by adding the residual block to a predictive block of one of the reference pictures within one of the reference picture lists. Motion compensation unit 44 may also apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values for use in motion estimation. Summer 62 adds the reconstructed residual block to the motion compensated prediction block produced by motion compensation unit 44 to produce a reference block of a reference picture for storage in reference picture memory 64. The reference block is filtered by a deblocking filter 63 in order to remove blocking artifacts. The reference block is then stored in reference picture memory 64. The reference block may be used by motion estimation unit 42 and motion compensation unit 44 as a reference block to inter-predict a block in a subsequent video frame or picture.

In accordance with the techniques of this disclosure, video encoder 20 includes a deblocking filter 63 that selectively filters the output of summer 62. In particular, deblocking filter 63 receives reconstructed video data from summer 62 that corresponds to prediction data received from motion compensation unit 44 or intra-prediction unit 46 added to the inverse quantized and inverse transformed residual data. In this way, deblocking filter 63 receives decoded blocks of video data, such as decoded blocks of LCUs corresponding to CUs and/or slices or pictures of LCUs, and selectively filters the blocks to remove blockiness artifacts.

Deblocking filter 63 in video encoder 20 filters certain TU and PU edges of the decoded video block based on results from the boundary strength calculations and deblocking decisions. Deblocking filter 63 is generally configured to analyze pixels of a video block near a given edge of the block to determine whether and how to filter the edge. More particularly, the deblocking decision may include whether the deblocking filter is on or off, whether the deblocking filter is weak or strong, and the strength of the weak filter for a given video block. Deblocking filter 63 may alter the values of pixels near a given edge when high frequency changes in the values are detected in order to remove blocking artifacts perceptible at the edge.

The boundary strength calculation and the deblocking decision depend on a threshold value t_cAnd β threshold t of deblocking filter_cAnd β depend on a parameter Q derived from the Quantization Parameter (QP) value and boundary strength (Bs) of the current video block as follows:

If Bs＝2，then TcOffset＝2

If Bs≤1，then TcOffset＝0

For t_C：Q＝Clip3(0，MAX_QP+2，QP+TcOffset)；MAX_QP＝51

Forβ：Q＝Clip3(0，MAX_QP，QP)

Clip3(th1，th2，value)＝min(th1，max(th2，value))

threshold value t_cAnd β may be stored in a table, which may be based on QP from video blocksThe parameter Q of the value. The deblocking process is described in more detail below with respect to deblocking filter 100 illustrated in fig. 4.

This disclosure describes techniques for signaling deblocking filter parameters for deblocking filter 63 used to define a current slice of video data with reduced bitstream overhead. Video encoder 20 determines and then signals deblocking filter parameters that define deblocking filter 63 such that video decoder 30 may apply the same or similar deblocking filter to the decoded video blocks. The deblocking filter parameters include a syntax element defined to indicate whether deblocking filtering is enabled or disabled, and if enabled, to indicate a threshold value t_cAnd β.

Deblocking filter parameters may be coded in one or more of a picture layer parameter set and a slice header for signaling to video decoder 30. The picture layer parameter set may comprise a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS). A PPS is a picture layer parameter set that contains data that is unlikely to change between pictures that relate to the PPS. APS is a picture layer parameter set intended for use with picture adaptation data that is likely to vary between pictures.

Entropy encoding unit 56 of video encoder 20 encodes a first syntax element defined to indicate whether deblocking filter parameters are present in both the picture layer parameter set and a slice header of a picture that refers to the picture layer parameter set. In accordance with the techniques described in this disclosure, when deblocking filter parameters are present in both the picture layer parameter set and the slice header, entropy encoding unit 56 encodes the deblocking filter parameters for the current video slice with reduced bitstream overhead by encoding only the second syntax element in the slice header.

When the deblocking filter parameters are not present in both the picture layer parameter set and the slice header, entropy encoding unit 56 eliminates coding a second syntax element in the slice header that is defined to indicate which set of deblocking filter parameters to use to define deblocking filter 63 for the current video slice. In the case where deblocking filter parameters are present in only one of the picture layer parameter set or the slice header, deblocking filter 63 for the current video slice is defined based on the set of deblocking filter parameters present in the picture layer parameter set or the slice header. Thus, no second syntax element is needed to indicate deblocking filter parameters to video decoder 30, as a decision between a picture layer parameter set and a slice header as to which set of deblocking filter parameters to use to define the deblocking filter at video decoder 30 need not be made.

When the deblocking filter parameters are present in both the picture layer parameter set and the slice header, entropy encoding unit 56 encodes a second syntax element in the slice header that is defined to indicate whether to use a first set of deblocking parameters included in the picture layer parameter set or a second set of deblocking parameters included in the slice header. In this case, deblocking filter 63 for the current video slice is defined based on one of the first set or the second set of deblocking parameters. Thus, the second syntax element is needed to indicate deblocking filter parameters used to define deblocking filter 63 in video encoder 20 so that video decoder 30 may apply the same or similar deblocking filter to decoded video blocks.

In some cases, entropy encoding unit 56 may also encode a control present syntax element defined to indicate whether any deblocking filter control syntax elements are present in the picture layer parameter set or the slice header. The control presence syntax element may be signaled in a picture layer parameter set or from a higher layer parameter set, such as a Sequence Parameter Set (SPS). The deblocking filter control syntax elements comprise the first and second syntax elements described above. Thus, the entropy encoding unit 56 encodes the control present syntax element, followed by the first syntax element. If no deblocking filter control syntax element is present, video encoder 20 notifies video decoder 30 and does not encode the first or second syntax element. In this case, video encoder 20 may use default deblocking filter parameters to define deblocking filter 63 applied to decoded video blocks.

In other cases, entropy encoding unit 56 may encode a deblocking filter enable syntax element defined to indicate whether deblocking filter 63 is enabled for one or more pictures of the video sequence prior to encoding the first syntax element. The deblocking filter enable syntax element may be signaled in a higher layer parameter set, such as a Sequence Parameter Set (SPS). If deblocking filter 63 is disabled for the video sequence, video encoder 20 notifies video decoder 30 and does not encode the first or second syntax elements because deblocking filter 63 is not applied to the decoded video block. In this case, video encoder 20 does not encode the control present syntax element.

In one example, the first syntax element comprises an override enabled flag coded in a PPS of the given picture. In this case, the first set of deblocking filter parameters is coded in the PPS and the override enabled flag indicates whether there is a second set of deblocking filter parameters in slice headers of one or more slices of the given picture that may be used to override the parameters from the PPS. In addition, the second syntax element comprises an override flag that may be coded in the slice header. When the override enabled flag in the PPS indicates that the second set of deblocking filter parameters is present in the slice header, entropy encoding unit 56 encodes the override flag to indicate to video decoder 30 whether to use the first set of deblocking filter parameters in the PPS or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define a deblocking filter at video decoder 30. Otherwise, when the override enabled flag in the PPS indicates that only the first set of deblocking filter parameters in the PPS is present, entropy encoding unit 56 eliminates encoding of the override flag in the slice header. The particular syntax elements of this example are described in more detail below with respect to video decoder 30 in fig. 3.

In another example, the first syntax element comprises an inherit enable flag coded in an SPS and/or an APS of the given picture. In this case, the second set of deblocking filter parameters is coded in the slice header, and the inherit enable flag indicates that the first set of deblocking filter parameters that may be inherited by the slice header are present in the APS. The second syntax element comprises an inherit flag that can be coded in the slice header. When the inheritance enable flag in the SPS and/or the APS indicates that the first set of deblocking filter parameters is present in the APS, entropy encoding unit 56 encodes the inheritance flag to indicate to video decoder 30 whether to use the second set of deblocking filter parameters in the slice header or the first set of deblocking filter parameters in the inheritance APS to define the deblocking filter at video decoder 30. Otherwise, when the SPS and/or the inherit enabled flag in the APS indicate that only the second set of deblocking filter parameters in the slice header is present, entropy encoding unit 56 eliminates encoding of the inherit flag in the slice header. The particular syntax elements of this example are described in more detail below with respect to video decoder 30 in fig. 3.

Fig. 3 is a block diagram illustrating an example of a video decoder 30 that may implement the techniques described in this disclosure to decode deblocking filter parameters used to define deblocking filters applied to video slices. In the example of fig. 3, video decoder 30 includes entropy decoding unit 80, prediction processing unit 81, inverse quantization unit 86, inverse transform processing unit 88, summer 90, deblocking filter 91, and reference picture memory 92. Prediction processing unit 81 includes motion compensation unit 82 and intra prediction processing unit 84. Video decoder 30 may, in some examples, perform a decoding pass generally reciprocal to the encoding pass described with respect to video encoder 20 from fig. 2.

During the decoding process, video decoder 30 receives an encoded video bitstream representing decoded video slices and video blocks of associated syntax elements from video encoder 20. When the represented video block in the bitstream includes compressed video data, entropy decoding unit 80 of video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors, and other syntax elements. Entropy decoding unit 80 forwards the motion vectors and other syntax elements to prediction processing unit 81. Video decoder 30 may receive syntax elements at the sequence level, picture level, slice level, and/or video block level. In some cases, entropy decoding unit 80 decodes deblocking filter control syntax elements that include deblocking filter parameters to define deblocking filter 91 for a given video slice.

When coding a video slice as an intra-coded (I) slice, intra-prediction processing unit 84 of prediction processing unit 81 may generate prediction data for a video block of the current video slice based on the signaled intra-prediction mode and data from previously decoded blocks of the current frame or picture. When a view frame is coded as an inter-coded (i.e., B or P) slice, motion compensation unit 82 of prediction processing unit 81 generates a prediction block for a video block of the current video slice based on the motion vectors and other syntax elements received from entropy decoding unit 80. The prediction block may be generated from one of the reference pictures within one of the reference picture lists. Video decoder 30 may construct reference frame lists, list 0 and list 1, using default construction techniques based on the reference pictures stored in reference picture memory 92.

Motion compensation unit 82 determines prediction information for video blocks of the current video slice by parsing the motion vectors and other syntax elements, and uses the prediction information to generate a prediction block for the current video block being decoded. For example, motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra-prediction or inter-prediction) for coding video blocks of the video slice, an inter-prediction slice type (e.g., a B-slice or a P-slice), construction information for one or more of a reference picture list of the slice, a motion vector for each inter-coded video block of the slice, an inter-prediction state for each inter-coded video block of the slice, and other information used to decode video blocks in the current video slice.

Motion compensation unit 82 may also perform interpolation based on the interpolation filter. Motion compensation unit 82 may calculate interpolated values for sub-integer pixels of the reference block using interpolation filters as used by video encoder 20 during encoding of the video block. Motion compensation unit 82 may determine the interpolation filters used by video encoder 20 from the received syntax elements and use the interpolation filters to generate prediction blocks.

Inverse quantization unit 86 inverse quantizes (i.e., dequantizes) the quantized transform coefficients provided in the bitstream and decoded by entropy decoding unit 80. The inverse quantization process may include using quantization parameters calculated by video encoder 20 for each video block in the video slice to determine the degree of quantization that should be applied and the same degree of inverse quantization. The inverse transform processing unit 88 applies an inverse transform (e.g., an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process) to the transform coefficients in order to generate residual blocks in the pixel domain.

After motion compensation unit 82 generates a prediction block for the current video block based on the motion vector and other syntax elements, video decoder 30 forms a decoded video block by summing the residual block from inverse transform processing unit 88 with the corresponding prediction block generated by motion compensation unit 82. Summer 90 represents the component that performs this summation operation. A deblocking filter 91 is applied to filter the block received from summer 90 in order to remove blocking artifacts. The decoded video blocks in a given picture are then stored in reference picture memory 92, which stores reference pictures used for subsequent motion compensation. Reference picture memory 92 also stores decoded video for later presentation on a display device (e.g., display device 32 of fig. 1).

Deblocking filter 91 in video decoder 30 filters certain TU and PU edges of the decoded video block based on results from boundary strength calculations and deblocking decisions. The boundary strength calculation and the deblocking decision depend on a threshold value t that may be signaled from video encoder 20 to video decoder 30 using a syntax element_cAnd β deblocking filter 91 may alter video blocks for videoThe values of the pixels near the edge are fixed in order to remove blocking artifacts perceptible at the edge. Deblocking filter 91 substantially conforms to deblocking filter 63 from fig. 2, where deblocking filter 91 may be configured to perform any or all of the techniques described with respect to deblocking filter 63. The deblocking process is described in more detail below with respect to deblocking filter 100 illustrated in fig. 4.

In accordance with the techniques of this disclosure, entropy decoding unit 80 in video decoder 30 decodes deblocking filter control syntax elements included in the bitstream received from video encoder 20. The deblocking filter control syntax element includes a deblocking filter parameter that indicates whether deblocking filtering is enabled or disabled, and if enabled, indicates a threshold value t_cVideo encoder 30 determines, from deblocking filter control syntax elements included in the bitstream, deblocking filter parameters to be used for deblocking filter 91 video decoder 30 then defines deblocking filter 91 based on the deblocking filter parameters to operate the same as or similar to deblocking filter 63 in video encoder 20 in order to decode the video blocks in the bitstream.

This disclosure describes techniques for signaling deblocking filter parameters for a deblocking filter 91 used to define a current slice of video data with reduced bitstream overhead. Deblocking filter parameters may be coded in one or more of a picture layer parameter set and a slice header for signaling to video decoder 30. The picture layer parameter set may comprise a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS). A PPS is a picture layer parameter set that contains data that is unlikely to change between pictures that relate to the PPS. APS is a picture layer parameter set intended for use with picture adaptation data that is likely to vary between pictures.

Entropy decoding unit 80 of video decoder 30 decodes a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header of a picture that refers to the picture layer parameter set. According to the techniques described in this disclosure, entropy decoding unit 80 only decodes the second syntax element in the slice header when deblocking filter parameters are present in both the picture layer parameter set and the slice header.

When deblocking filter parameters are not present in both the picture layer parameter set and the slice header, entropy decoding unit 80 determines that a second syntax element defined to indicate which set of deblocking filter parameters to use to define deblocking filter 91 for the current video slice is not present in the slice header to be decoded. In the case where deblocking filter parameters are present in only one of the picture layer parameter set or the slice header, deblocking filter 91 for the current video slice is defined based on the set of deblocking filter parameters present in the picture layer parameter set or the slice header. Thus, the second syntax element is unnecessary because video decoder 30 does not need to decide which set of deblocking filter parameters to use to define deblocking filter 91 in video decoder 30.

When the deblocking filter parameters are present in both the picture layer parameter set and the slice header, entropy decoding unit 80 decodes a second syntax element in the slice header, the second syntax element defined to indicate whether to use a first set of deblocking parameters included in the picture layer parameter set or a second set of deblocking parameters included in the slice header. In this case, deblocking filter 91 for the current video slice is defined based on one of the first set or the second set of deblocking parameters. Thus, the second syntax element is necessary so that video decoder 30 knows which set of deblocking filter parameters to use to define deblocking filter 91 as the same as or similar to deblocking filter 63 in video encoder 20.

In some cases, entropy decoding unit 80 may also decode a control present syntax element defined to indicate whether any deblocking filter control syntax elements are present in the picture layer parameter set or the slice header. The control present syntax element may be decoded from a picture layer parameter set or from a higher layer parameter set, such as a Sequence Parameter Set (SPS). The deblocking filter control syntax elements comprise the first and second syntax elements described above. Accordingly, the entropy decoding unit 80 decodes the control present syntax element, followed by decoding the first syntax element. If the control present syntax element indicates that no deblocking filter control syntax element is present, video decoder 30 knows that it does not need to decode the first or second syntax element because the first and second syntax elements are not present in the bitstream to be decoded. In this case, video decoder 30 may use default deblocking filter parameters to define deblocking filter 91 applied to decoded video blocks.

In other cases, entropy decoding unit 80 may decode a deblocking filter enable syntax element defined to indicate whether deblocking filter 91 is enabled for one or more pictures of the video sequence prior to decoding the first syntax element. The deblocking filter enabled syntax element may be decoded from a higher layer parameter set, such as a Sequence Parameter Set (SPS). If deblocking filter 91 is disabled for a video sequence, video decoder 30 knows that it does not need to decode the first or second syntax elements because deblocking filter 91 is not applied to the decoded video block. In this case, video decoder 30 also does not need to decode the control presence syntax element.

In one example, the first syntax element comprises an override enabled flag coded in a PPS of the given picture. In this case, the first set of deblocking filter parameters is coded in the PPS and the override enabled flag indicates whether there is a second set of deblocking filter parameters in slice headers of one or more slices of the given picture that may be used to override the parameters from the PPS. In addition, the second syntax element comprises an override flag that may be coded in the slice header. When the override enabled flag in the PPS indicates that the second set of deblocking filter parameters is present in the slice header, entropy decoding unit 80 decodes the override flag to determine whether to use the first set of deblocking filter parameters in the PPS or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define deblocking filter 91. Otherwise, when the override enabled flag in the PPS indicates that only the first set of deblocking filter parameters in the PPS is present, entropy decoding unit 80 determines that the override flag is not present in the slice header to be decoded.

Table 1 provides an exemplary portion of a PPS syntax including an override enabled flag (i.e., deblocking _ filter _ override _ enabled _ flag) and a control presence syntax element (i.e., deblocking _ filter _ control _ present _ flag).

TABLE 1 PPS syntax with override Enable flag

pic_parameter_set_rbsp(){	Descriptor(s)
		...
deblocking_filter_control_present_flag	u(1)
		if(deblocking_filter_control_present_flag){
deblocking_filter_override_enabled_flag	u(1)
		pic_disable_deblocking_filter_flag	u(1)
if(！pic_disable_deblocking_filter_flag){
		beta_offset_div2	se(v)
tc_offset_div2	se(v)
		}
}
		...

The semantics of the PPS syntax of table 1 are defined as follows. deblocking _ filter _ control _ present _ flag equal to l specifies the presence of deblocking filter control syntax elements in the picture layer parameter set and in the slice header of the picture referring to the picture layer parameter set. deblocking _ filter _ control _ present _ flag equal to 0 specifies that no deblocking filter control syntax elements are present in the picture layer parameter set and in the slice header of the picture referring to the picture layer parameter set.

deblocking _ filter _ override _ enabled _ flag equal to 1 specifies the presence of deblocking _ filter _ override _ flag in slice headers of pictures referring to the picture layer parameter set. deblocking _ filter _ override _ enabled _ flag equal to 0 specifies that the deblocking _ filter _ override _ flag is not present in slice headers of pictures referring to the picture layer parameter set. When not present, deblocking _ filter _ override _ enabled _ flag is inferred to be equal to 0.

pic _ disable _ deblocking _ filter _ flag equal to 1 specifies an operation that a deblocking filter should not be applied for a picture related to a picture layer parameter set when deblocking _ filter _ override _ enabled _ flag is equal to 0. pic _ disable _ deblocking _ filter _ flag equal to 0 specifies the operation that the deblocking filter should be applied for pictures related to the picture layer parameter set when deblocking _ filter _ override _ enabled _ flag is equal to 0. When not present, pic _ disable _ deblocking _ filter _ flag is inferred to be equal to 0.

The beta _ offset _ div2 and tc _ offset _ div2 syntax elements specify β and t for picture applications that refer to a picture layer parameter set_cUnless overridden by a deblocking parameter offset present in a slice segment header of a picture that refers to a picture layer parameter set (divide by 2). The values of the beta _ offset _ div2 and tc _ offset _ div2 syntax elements should both be in the range of-6 to 6, including-6 and 6. When not present, it is inferred that the values of the beta _ offset _ div2 and tc _ offset _ div2 syntax elements are equal to 0.

Table 2 provides an exemplary portion of a slice header syntax that includes an override flag (i.e., deblocking _ filter _ override _ flag) that is conditionally coded based on an override enable flag and a control present syntax element in the PPS syntax.

TABLE 2 slice header syntax with override flag

slice_segment_header(){	Descriptor(s)
		...
if(deblocking_filter_control_present_flag){
		if(deblocking_filter_override_enabled_flag)
deblocking_filter_override_flag	u(1)
		if(deblocking_filter_override_flag){
slice_disable_deblocking_filter_flag	u(1)
		if(！slice_disable_deblocking_filter_flag){
beta_offset_div2	se(v)
		tc_offset_div2	se(v)
}
		}
}
		...

The semantics of the slice header syntax of table 2 are defined as follows. deblocking _ filter _ override _ flag equal to 0 specifies the deblocking parameters from the active picture parameter set for deblocking the current slice. deblocking _ filter _ override _ flag equal to 1 specifies the deblocking parameters from the slice segment header for deblocking the current slice. When not present, deblocking _ filter _ override _ flag is inferred to be equal to 0.

slice _ disable _ deblocking _ filter _ flag equal to 1 specifies an operation of not applying a deblocking filter for the current slice. slice _ disable _ deblocking _ filter _ flag equal to 0 specifies the operation of applying a deblocking filter for the current slice. When slice _ disable _ deblocking _ filter _ flag is not present, it is inferred to be equal to pic _ disable _ deblocking _ filter _ flag in the PPS syntax.

The beta _ offset _ div2 and tc _ offset _ div2 syntax elements specify β and t for the current slice_cIs offset (divided by 2). The values of the beta _ offset _ div2 and tc _ offset _ div2 syntax elements should be in the range of-6 to 6, including-6 and 6.

In another example, the first syntax element comprises an inherit enable flag coded in an SPS and/or an APS of the given picture. In this case, the second set of deblocking filter parameters is coded in the slice header, and the inherit enable flag indicates that the first set of deblocking filter parameters that may be inherited by the slice header are present in the APS. The second syntax element comprises an inherit flag that can be coded in the slice header. When the inheritance enabled flag in the SPS and/or the APS indicates that the first set of deblocking filter parameters is present in the APS, entropy decoding unit 80 decodes the inheritance flag to determine whether to use the second set of deblocking filter parameters in the slice header or the first set of deblocking filter parameters in the inheritance APS to define deblocking filter 91. Otherwise, when the SPS and/or the inherit enable flag in the APS indicates that only the second set of deblocking filter parameters in the slice header is present, entropy decoding unit 80 determines that the inherit flag is not present in the slice header to be decoded.

The signaling of deblocking filter parameters to a video decoder is proposed in "BoG reports (BoG report on deblocking filtering description issues) on solving deblocking filter description problems" of 7 th JCT-VC conference doc, JCT-VC G1035_ r1+ update, a.norkin, geneva, 11 months, switzerland, 2011. Table 3 provides an example of an SPS syntax that includes a legacy enable flag (i.e., deblocking _ filter _ in _ aps _ enabled _ flag).

TABLE 3 SPS syntax with legacy Enable flag

seq_parameter_set_rbsp(){	Descriptor(s)
		profile_idc	u(8)
(omitted)
		chroma_pred_from_luma_enabled_flag	u(1)
deblocking_filter_in_aps_enabled_flag	u(1)
		loop_filter_across_slice_flag	u(1)
sample_adaptive_offset_enabled_flag	u(1)
		adaptive_loop_filter_enabled_flag	u(1)
pcm_loop_filter_disable_flag	u(1)
		cu_qp_delta_enabled_flag	u(1)
temporal_id_nesting_flag	u(1)
		inter_4x4_enabled_flag	u(1)
rbsp_trailing_bits()
		}

Table 4 provides an example of an APS syntax that includes an inherited enable flag (i.e., APS _ deblocking _ filter _ flag).

TABLE 4 APS syntax with inherited Enabled flag

aps_rbsp(){	Descriptor(s)
		aps_id	ue(v)
aps_deblocking_filter_flag	u(1)
		aps_sample_adaptive_offset_flag	u(1)
aps_adaptive_loop_filter_flag	u(1)
		if(aps_sample_adapt ive_offset_flag\|\|aps_adaptive_loop_filter_flag){
aps_cabac_use_flag	u(1)

if(aps_cabac_use_flag){
		aps_cabac_init_idc	ue(v)
aps_cabac_init_qp_minus26	se(v)
		}
}
		if(aps_deblocking_filter_flag){
disable_deblocking_filter_flag	u(1)
		if(！disable_deblocking_filter_flag){
beta_offset_div2	se(v)
		tc_offset_div2	se(v)
}
		}
if(aps_sample_adaptive_offset_flag){
		sao_data_byte_count	u(8)
byte_align()
		sao_param()
byte_align()
		}
if(aps_adaptive_loop_filter_flag){
		alf_data_byte_count	u(8)
byte_align()
		alf_param()
}
		rbsp_trailing_bits()
}

The semantics of the SPS and APS syntax of tables 3 and 4 are defined as follows. Deblocking _ filter _ in _ APS _ enabled _ flag in SPS equal to 0 means that deblocking filter parameters are present in the slice header, and equal to 1 means that deblocking filter parameters are present in the APS. The APS _ deblocking _ filter _ flag in the APS is equal to the deblocking _ filter _ in _ APS _ enabled _ flag in the SPS. APS _ deblocking _ filter _ flag indicates that deblocking filter parameters are present in the APS (equal to 1) or absent from the APS (equal to 0).

One problem with signaling deblocking filter parameters is that an inherit flag is signaled in the slice header even when the deblocking filter parameters are not present in the APS. As described above, when deblocking filter parameters are only present in the slice header and not present in the APS, a deblocking filter is defined based on the deblocking filter parameters present in the slice header and an inherit flag is not necessary. Table 5 provides an exemplary portion of the slice header syntax that includes an inherit flag (i.e., inherit _ dbl _ params _ from _ APS _ flag) that is conditionally coded based on the inherit enable flag in the APS syntax and the SPS syntax.

TABLE 5 slice header syntax with inherit flags

As an alternative, table 6 provides an exemplary portion of the slice header syntax that includes an inherit flag (i.e., inherit _ dbl _ params _ from _ APS _ flag) that is conditionally coded based on the inherit enable flag in the SPS syntax.

TABLE 6 slice header syntax with inherit flag

The semantics of the slice header syntax of tables 5 and 6 are defined as follows.disable _ deblocking _ filter _ flag equal to 0 means that the deblocking filter is enabled, and equal to 1 means that the deblocking filter is disabled. The beta _ offset _ div2 and tc _ offset _ div2 syntax elements indicate t_cAnd a deblocking parameter offset of β (divided by 2.) inherit _ dbl _ params _ from _ APS _ flag equal to 1 means that deblocking filter parameters present in APS should be used, and equal to 0 means that deblocking filter parameters following in the slice header should be used.

A second problem with signaling deblocking filter parameters is that an SPS level enable/disable flag is not defined to indicate whether deblocking filters are enabled for pictures of a video sequence. When the deblocking filter is disabled, deblocking filter parameters are not needed to define the deblocking filter, and coding the deblocking filter parameters is not necessary. Table 7 provides an example of SPS syntax that includes an inherited enable flag (i.e., deblocking _ in _ aps _ enabled _ flag) that is conditionally coded based on a deblocking filter enable flag (i.e., deblocking _ filter _ enabled _ flag).

TABLE 7 SPS syntax with deblocking filter Enable flag and inheritance Enable flag

The semantics of the SPS syntax of table 7 are defined as follows. deblocking _ filter _ enabled _ flag equal to 0 means that the deblocking filter is disabled, and equal to 1 means that the deblocking filter is enabled.

In this way, when the deblocking filter is disabled at the SPS level, it may be inferred that the deblocking parameters are not signaled in the APS (i.e., deblocking _ filter _ in _ APS _ enabled _ flag in the SPS is equal to 0 and APS _ deblocking _ filter _ flag in the APS is equal to 0). In addition, when deblocking filter is disabled at the SPS level, it may be inferred that disable _ deblocking _ filter _ flag in the slice header is equal to 1, indicating that deblocking filter is disabled at the slice level.

Table 8 provides an example of APS syntax, where when the deblocking filter is disabled at the SPS level, it is inferred that the relay enabled flag (i.e., APS _ deblocking _ filter _ flag) is equal to 0.

TABLE 8 APS syntax with inherited Enabled flag

aps_rbsp(){	Descriptor(s)
		aps_id	ue(v)
aps_deblocking_filter_flag	u(1)
		aps_sample_adaptive_offset_flag	u(1)
aps_adaptive_loop_filter_flag	u(1)
		if(aps_sample_adapt ive_offsetflag\|\|aps_adaptive_loop_filter_flag){
aps_cabac_use_flag	u(1)
		if(aps_cabac_use_flag){
aps_cabac_init_idc	ue(v)
		aps_cabac_init_qp_minus26	se(v)
}
		}
if(aps_deblocking_filter_flag){
		disable_deblocking_filter_flag	u(1)
if(！disable_deblocking_filter_flag){
		beta_offset_div2	se(v)
tc_offset_div2	se(v)
		}
}
		...

Table 9 provides exemplary portions of slice header syntax that includes deblocking filter parameters that are conditionally coded based on a deblocking filter enabled flag (i.e., deblocking filter enabled flag) in the SPS syntax.

TABLE 9 slice header syntax with inherited flags and conditionally coded deblocking filter parameters

As an alternative, instead of introducing conditions for coding deblocking filter parameters in a slice header based on a deblocking filter enabled flag in SPS, the techniques may infer that deblocking filter control syntax elements are not signaled in the slice header when deblocking filters are disabled at the SPS level. A control present syntax element (i.e., deblocking _ filter _ control _ present _ flag) included in the PPS syntax is defined to indicate whether deblocking filter control syntax elements including deblocking filter parameters are signaled in the slice header. In this case, deblocking filter parameters are coded in the slice header only when deblocking filter control syntax elements are signaled in the slice header (which only occurs when deblocking filters are enabled at the SPS level). The presence of a syntax element for control in PPS is proposed in "High Efficiency Video Coding (HEVC) text specification draft6 (HEVC) of blocs, w. -j. korean, j. -r. ohm, g.j. sorun, t. vicrd (Bross, w. -j.han, j. -r.ohm, g.j.sublivan, t.wiegand) at the 8 th JCT-VC conference in san jose, ca, 2.2012, also known as HEVC" working draft6 ", HEVC WD6 or, shortly, WD 6.

Table 10 provides an example of SPS syntax that includes an inherit enabled flag that is conditionally coded based on the deblocking filter enabled flag, and where when the deblocking filter is disabled at the SPS level, it is inferred that the control present syntax element (i.e., deblocking _ filter _ control _ present _ flag) in the PPS is equal to 0.

TABLE 10 SPS syntax with deblocking filter Enable flag and inheritance Enable flag

Table 11 provides an exemplary portion of slice header syntax that includes deblocking filter parameters that are conditionally coded based on a control present syntax element (i.e., deblocking _ filter _ control _ present _ flag) in the PPS syntax.

TABLE 11 slice header syntax with inherited flags and conditionally coded deblocking filter parameters

The difference between the examples described with respect to tables 10 and 11 and the examples described with respect to tables 7 to 9 is that when deblocking _ filter _ enable _ flag in SPS is equal to 0, deblocking _ filter _ control _ present _ flag in PPS is also inferred to be equal to 0. In this way, the result of disabling the deblocking filter at the SPS level is that the deblocking filter parameters will not be signaled in the APS or slice header, and the deblocking filter is actually disabled at the slice level. More specifically, when deblocking filter is disabled at the SPS level, video decoder 30 may infer that no deblocking filter parameters are present in the APS (i.e., deblocking _ filter _ in _ APS _ enabled _ flag in SPS is equal to 0 and APS _ deblocking _ filter _ flag in APS is equal to 0) and that deblocking filter block parameters are not signaled in the slice header (i.e., deblocking _ filter _ control _ present _ flag in PPS is equal to 0). In addition, video decoder 30 may infer that disable _ deblocking _ filter _ flag in the slice header is equal to 1, indicating that the deblocking filter is disabled at the slice level. In this case, it may not be necessary to add an additional condition in the slice header syntax, since when deblocking _ filter _ control _ present _ flag in PPS is equal to 0, no deblocking filter parameters are signaled in the slice header.

A third problem with signaling deblocking filter parameters is that an SPS level flag is not defined to indicate when deblocking filter control syntax elements are signaled and default parameters such as zero values should be used to define the deblocking filter. When no deblocking filter control syntax element is signaled in either the APS or slice header, no deblocking filter parameters are signaled to define the deblocking filter. Table 12 provides an example of SPS syntax that includes an inherited enable flag (i.e., deblocking _ in _ aps _ enabled _ flag) that is conditionally coded based on a control present syntax element (i.e., deblocking _ filter _ control _ present _ flag).

TABLE 12 SPS syntax with legacy Enable flag that controls the presence of syntax elements and is conditionally coded

Table 13 provides an example of an APS syntax, in which the relay enabled flag (i.e., APS _ deblocking _ filter _ flag) is inferred to be equal to 0 when no deblocking filter control syntax element is present in the APS or slice header, i.e., when deblocking _ filter _ control _ present _ flag in the SPS syntax is equal to 0.

TABLE 13 APS syntax with inherited Enabled flag

Table 14 provides an example of slice header syntax that includes deblocking filter parameters that are conditionally coded based on a control present syntax element (i.e., deblocking _ filter _ control _ present _ flag) in the SPS syntax.

TABLE 14 slice header syntax with inherited flags and conditionally coded deblocking filter parameters

Fig. 4 is a block diagram illustrating components of an exemplary deblocking filter 100 defined based on deblocking filter parameters signaled in accordance with the techniques described in this disclosure. In general, either or both of deblocking filter 63 from fig. 2 and deblocking filter 91 from fig. 3 may include components that are substantially similar to components of deblocking filter 100. Other video coding devices, such as video encoders, video decoders, video encoder/decoders (CODECs), may also include components substantially similar to deblocking filter 100. Deblocking filter 100 may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software or firmware, corresponding hardware (e.g., one or more processors or processing units and memory for storing instructions for the software or firmware) may also be provided.

In the example of fig. 4, deblocking filter 100 includes a deblocking determination unit 104, support definitions 102 stored in memory, a deblocking filtering unit 106, deblocking filter definitions 108 stored in memory, an edge location unit 103, and an edge location data structure 105. Any or all of the components of deblocking filter 100 may be functionally integrated. The components of deblocking filter 100 are illustrated separately for purposes of illustration only. In general, deblocking filter 100 receives data for a decoded block, for example, from a summing component that combines prediction data and residual data for the block. The data may further include an indication of how to predict the block. In the examples described below, deblocking filter 100 is configured to receive data that includes decoded video blocks associated with LCUs and CU quadtrees of the LCUs, where the CU quadtrees describe how the LCUs are partitioned into prediction modes for PUs and TUs of the CUs and leaf nodes of the CUs.

Deblocking filter 100 may maintain edge position data structure 105 in a memory of deblocking filter 100, or in an external memory provided by a corresponding video coding device. In some examples, edge location unit 103 may receive a CU quadtree corresponding to an LCU that indicates how to partition the LCU into CUs. Edge location unit 103 may then analyze the CU quadtree to determine edges between decoded video blocks associated with TUs and PUs of the CU in the LCU as candidates for deblocking.

The edge location data structure 105 may include an array having a horizontal dimension, a vertical dimension, and dimensions representing a horizontal edge and a vertical edge. In general, edges between video blocks may occur between two video blocks associated with a smallest-sized CU of an LCU or a TU and a PU of a CU. Assuming that the LCU has a size of N × N, and assuming that the two smallest-sized CUs of the LCU have a size of M × M, the array may include a size of [ N/M ] × 2, where "2" represents two possible directions (horizontal and vertical) of the edge between CUs. For example, assuming that an LCU has 64 × 64 pixels and 8 × 8 minimum-sized CUs, the array may include [8] × [8] × [2] entries.

Each entry may generally correspond to a possible edge between two video blocks. The edge may not actually exist at each of the locations within the LCU corresponding to each of the entries of the edge location data structure 105. Thus, the value of the data structure may be initialized to false. In general, edge location unit 103 may analyze the CU quadtree to determine the location of an edge between two video blocks associated with TUs and PUs of a CU of an LCU and set a corresponding value in edge location data structure 105 to true.

In general, an entry of an array may describe whether a corresponding edge is present in an LCU as a candidate for deblocking. That is, when edge location unit 103 determines that an edge between two neighboring video blocks associated with TUs and PUs of a CU of an LCU exists, edge location unit 103 may set a value of a corresponding entry in edge location data structure 105 to indicate that an edge exists (e.g., to a value of "true").

Deblocking determination unit 104 typically determines, for two neighboring blocks, whether an edge between the two blocks should be deblocked. The deblocking determination unit 104 may use the edge position data structure 105 to determine the position of the edge. In some examples, when the value of the edge location data structure 105 has a boolean value, the deblocking determination unit 104 may determine that a "true" value indicates the presence of an edge and a "false" value indicates the absence of an edge.

In general, deblocking determination unit 104 is configured with one or more deblocking determination functions. The function may include a plurality of coefficients applied to a line of pixels spanning an edge between blocks. For example, the function may be applied to a line of eight pixels perpendicular to an edge, where four of the pixels are located in one of two blocks and the other four pixels are located in the other of the two blocks. The support definition 102 defines the support of functions. In general, "support" corresponds to the pixels to which the function is applied. Various examples of multiple sets of support are described in more detail below with respect to fig. 5.

Deblocking determination unit 104 may be configured to apply one or more deblocking determination functions to one or more sets of support defined by support definitions 102 to determine whether a particular edge between two blocks of video data should be deblocked. The dotted line originating from the deblocking determination unit 104 indicates that data of a block is output without being filtered. In a case where the deblocking determination unit 104 determines that an edge between two blocks should not be filtered, the deblocking filter 100 may output data of the blocks without changing the data. That is, the data may bypass the deblocking filter unit 106. On the other hand, when deblocking determination unit 104 determines that an edge should be filtered, deblocking determination unit 104 may cause deblocking filtering unit 106 to filter values of pixels near the edge in order to deblock the edge.

The deblocking filtering unit 106 retrieves the definition of the deblocking filter from deblocking filter parameters 108 for the edge to be deblocked, as indicated by the deblocking determination unit 104. In general, filtering of an edge uses values of pixels from neighbors of the current edge to be deblocked. Thus, the deblocking decision function and deblocking filter may have some support area on both sides of the edge. By applying a deblocking filter to pixels in the neighborhood of the edge, the deblocking filtering unit 106 may smooth the values of the pixels so that high frequency transitions near the edge are attenuated. In this way, applying a deblocking filter to pixels near an edge may reduce blocking artifacts near the edge.

Fig. 5 is a conceptual diagram illustrating pixel locations near an edge 134 of a video block between sub-blocks 130 and 132. As one example, edge 134 may comprise an internal CU edge, such as a TU edge between two TUs defined in a CU, or a PU edge between two PUs defined in a CU. Usage Format [ plq]I_JDesignating each of the pixel locations, where p corresponds to block sub-block 130 and q corresponds to sub-block 132, I corresponds to the distance from edge 134, and J corresponds to the row indicator from the top to the bottom of sub-blocks 130 and 132. In some examples, support for deblocking decision functions and deblocking filters has a line of eight pixels. In such examples, for a given line X, where 0 ≦ X ≦ 7, each of pixels p3X through q3X may be used as support.

Fig. 6 is a flow diagram illustrating example operations for encoding deblocking filter parameters for a current video slice with reduced bitstream overhead in accordance with the techniques described in this disclosure. The operation illustrated in fig. 6 is described with respect to video encoder 20 from fig. 2.

Entropy encoding unit 56 of video encoder 20 encodes a first syntax element defined to indicate whether deblocking filter parameters are present in both the picture layer parameter set and a slice header of a picture that refers to the picture layer parameter set (140). If deblocking filter parameters are not present in both the picture layer parameter set and the slice header (no branch of 141), entropy encoding unit 56 eliminates encoding of the second syntax element in the slice header (142). The second syntax element is defined to indicate which set of deblocking filter parameters to use to define a deblocking filter for the current video slice. In the case where deblocking filter parameters are only present in one of the picture layer parameter set or the slice header, a second syntax element is unnecessary because a decision need not be made as to which deblocking filter parameters to use to define a deblocking filter. Rather, deblocking filter 63(144) for the current video slice is defined based on a single set of deblocking filter parameters present in the picture layer parameter set or the slice header.

If the deblocking filter parameters are present in both the picture layer parameter set and the slice header (yes branch of 141), entropy encoding unit 56 encodes a second syntax element in the slice header that is defined to indicate whether to use the first set of deblocking parameters included in the picture layer parameter set or the second set of deblocking parameters included in the slice header (146). In this case, deblocking filter 63(148) for the current video slice is defined based on the indicated set of deblocking parameters. According to the techniques described in this disclosure, therefore, when deblocking filter parameters are present in both the picture layer parameter set and the slice header, the deblocking filter parameters for the current video slice are encoded with reduced bitstream overhead by encoding only the second syntax element in the slice header.

Fig. 7 is a flow diagram illustrating example operations for decoding deblocking filter parameters for a current video slice with reduced bitstream overhead in accordance with the techniques described in this disclosure. The operation illustrated in fig. 7 is described with respect to video decoder 30 from fig. 3.

Entropy decoding unit 80 of video decoder 30 decodes a first syntax element configured to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header of a picture that refers to the picture layer parameter set (150). If deblocking filter parameters are not present in both the picture layer parameter set and the slice header (no branch of 151), entropy decoding unit 80 determines that a second syntax element is not present in the slice header to be decoded (152). The second syntax element is defined to indicate which set of deblocking filter parameters to use to define a deblocking filter for the current video slice. In the case where deblocking filter parameters are only present in one of the picture layer parameter set or the slice header, a second syntax element is unnecessary because a decision need not be made as to which deblocking filter parameters to use to define a deblocking filter. Rather, deblocking filter 91(154) for the current video slice is defined based on a single set of deblocking filter parameters present in the picture layer parameter set or the slice header.

If the deblocking filter parameters are present in both the picture layer parameter set and the slice header (yes branch of 151), entropy decoding unit 80 decodes a second syntax element in the slice header, the second syntax element defined to indicate whether to use a first set of deblocking parameters included in the picture layer parameter set or a second set of deblocking parameters included in the slice header (156). In this case, deblocking filter 91(158) for the current video slice is defined based on the indicated set of deblocking parameters. According to the techniques described in this disclosure, therefore, when deblocking filter parameters are present in both the picture layer parameter set and the slice header, the deblocking filter parameters for the current video slice are decoded with reduced bitstream overhead by decoding only the second syntax element in the slice header.

Fig. 8 is a flow diagram illustrating example operations of encoding deblocking filter parameters for a current video slice in a Picture Parameter Set (PPS) that may be overridden by deblocking filter parameters in a slice header. The operation illustrated in fig. 8 is described with respect to video encoder 20 from fig. 2.

Entropy encoding unit 56 encodes a control present syntax element in the PPS, the control present syntax element defined to indicate whether any deblocking filter control syntax elements are present in the PPS and slice header (160). The deblocking filter control syntax elements include an override enable flag signaled in the PPS, an override flag signaled in the slice header, and deblocking filter parameters signaled in the PPS and/or the slice header. When the deblocking filter control syntax element is not present in the PPS or slice header (no branch of 162), entropy encoding unit 56 eliminates encoding of any of the deblocking filter control syntax elements (164). In this case, video encoder 20 signals to video decoder 30 that deblocking filter 63 is not defined based on coded deblocking filter parameters. Instead, deblocking filter 63 is defined based on default deblocking filter parameters (166).

When the deblocking filter control syntax element is present in the PPS or the slice header (yes branch of 162), entropy encoding unit 56 encodes an override enabled flag in the PPS that indicates whether the first set of deblocking filter parameters included in the PPS is enabled to be overridden by the second set of deblocking filter parameters included in the slice header (168).

If override of the deblocking filter parameters in the PPS is not enabled (no branch of 170), entropy encoding unit 56 eliminates encoding of the override flag in the slice header (172). The override flag indicates which set of deblocking filter parameters to use to define the deblocking filter for the current video slice. In the case where deblocking filter parameters are only present in the PPS, an override flag in the slice header is unnecessary, as no decision need be made as to which deblocking filter parameters to use to define the deblocking filter. Rather, deblocking filter 63(174) for the current video slice is defined based on deblocking filter parameters present in the PPS.

If overriding of deblocking filter parameters in the PPS by deblocking parameters in the slice header is enabled (yes branch of 170), entropy encoding unit 56 encodes an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the PPS or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header (176). In this case, deblocking filter 63(178) for the current video slice is defined based on the indicated set of deblocking parameters.

Fig. 9 is a flow diagram illustrating example operations of decoding deblocking filter parameters of a current video slice in a Picture Parameter Set (PPS) that may be overridden by deblocking filter parameters in a slice header. The operation illustrated in fig. 9 is described with respect to video decoder 30 from fig. 3.

Entropy decoding unit 80 decodes a control present syntax element in the PPS, the control present syntax element defined to indicate whether any deblocking filter control syntax elements are present in the PPS and slice header (180). The deblocking filter control syntax elements include an override enable flag signaled in the PPS, an override flag signaled in the slice header, and deblocking filter parameters signaled in the PPS and/or the slice header. When the deblocking filter control syntax element is not present in the PPS or slice header (no branch of 182), entropy decoding unit 80 determines that no deblocking filter control syntax element is present in the bitstream to be decoded (184). In this case, video decoder 30 knows that deblocking filter 91 was not defined based on coded deblocking filter parameters. Instead, deblocking filter 91(186) is defined based on default deblocking filter parameters.

When the deblocking filter control syntax element is present in the PPS or the slice header (yes branch of 182), entropy decoding unit 80 decodes an override enabled flag in the PPS, the override enabled flag indicating whether the first set of deblocking filter parameters included in the PPS is enabled to be overridden by the second set of deblocking filter parameters included in the slice header (188).

If override of deblocking filter parameters in the PPS is not enabled (no branch of 190), entropy decoding unit 80 determines that an override flag is not present in the slice header to be decoded (192). The override flag indicates which set of deblocking filter parameters to use to define the deblocking filter for the current video slice. In the case where deblocking filter parameters are only present in the PPS, an override flag in the slice header is unnecessary, as no decision need be made as to which deblocking filter parameters to use to define the deblocking filter. Rather, deblocking filter 91(194) for the current video slice is defined based on deblocking filter parameters present in the PPS.

If overriding of deblocking filter parameters in the PPS by deblocking parameters in the slice header is enabled (yes branch of 190), entropy decoding unit 80 decodes an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the PPS or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header (196). In this case, deblocking filter 91(198) for the current video slice is defined based on the indicated set of deblocking parameters.

In the example described above where a set of deblocking filter parameters is included in the APS, the APS may be signaled to video decoder 30 at any time the parameters of ALF, SAO, or deblocking change. The ALF and SAO parameters are likely to change more frequently than the deblocking filter parameters. In this case, whenever the SAO or ALF parameters change, bits may be wasted when the same deblocking filter parameters are repeated in the APS. As one solution to reducing APS bitstream overhead, in some examples, the techniques introduce multiple APSs to update deblocking filter parameters separately from ALF and SAO parameters. To avoid signaling duplicates of constant deblocking parameters in subsequent APSs, the slice header may refer to multiple APSs to decode video data of the slice. Several options for signaling deblocking filter parameters using multiple APSs are described below. Syntax for APS and slice headers is presented in the table below, with strikethrough representing syntax elements and conditions that can be removed from the APS and slice header syntax.

As a first example, the slice header may reference multiple different APSs using a unique APS identifier (e.g., APS _ id [ i ]) for each valid APS. In this case, the techniques include deblocking filter parameters in a Multiple APS method, such as the Multiple APS method set forth in "Multiple Adaptation Parameter set SetsReferring" of m.li, p.wu (m.li, p.wu), where the Multiple APS method may be similar to m.li, p.wu of 7 th JCT-VC conference doc.jctvc-G332 in 11-month switzerland geneva, 2011.

TABLE 15 slice header syntax with APS identifier

The semantics of the slice header syntax of table 15 are defined as follows. deblocking _ filter _ enabled _ flag equal to 0 means that the deblocking filter is disabled, and equal to 1 means that the deblocking filter is enabled. The number _ of _ valid _ APS syntax element specifies the number of valid APSs for decoding a slice. The value of number _ of _ valid _ aps should be in the range of [0, MaxUMBERValidAPs ], including 0 and MaxUMBERValidAPs. The value of maxnumberbalidaps is specified in the profile/level. If number _ of _ valid _ aps does not exist, then it can be inferred that its value is 0. If number _ of _ valid _ APS is equal to 0, it is inferred to be a non-valid APS. APS _ ID [ i ] specifies a valid APS ID for decoding a slice, where i should be in the range of [0, number _ of _ valid _ APS-1], including 0 and number _ of _ valid _ APS-1.

According to the above slice header syntax, the decoding rules for a slice according to the potential multiple APSs are as follows. When the number _ of _ valid _ APS value is equal to 0 or not present, i.e., APS is not involved in the slice header, flags of APS _ sample _ adaptive _ offset _ flag and APS _ adaptive _ loop _ filter _ flag and APS _ deblocking _ filter _ flag in decoding this slice should be set to 0, and SAO or ALF should not be applied in decoding the slice. If the value of inherit _ dbl _ params _ from _ APS _ flag is equal to 0, then the deblocking filter should be applied in decoding this slice, and the deblocking parameters included in this slice header should be used.

When the number _ of _ valid _ APS value is equal to 1, i.e., only one APS is involved in the slice header, the flags of APS _ sample _ adaptive _ offset _ flag and APS _ adaptive _ loop _ filter _ flag and APS _ deblocking _ filter _ flag in decoding this slice and the tool parameters of SAO and ALF should be set equal to the values of the corresponding syntax elements presented in the APS involved. If the value of inherit _ dbl _ params _ from _ APS _ flag is equal to 1, the deblocking parameter should be set equal to the value of the corresponding parameter in the APS involved.

When number _ of _ valid _ APS is greater than 1, i.e., when multiple APS methods are applied for the deblocking filter, if all APS _ deblocking _ filter _ flag in the APS involved are equal to 0, then APS _ deblocking _ filter _ flag in decoding this slice should be set to 0, and if inherit _ dbl _ params _ from _ APS _ flag is equal to 0, then the deblocking filter should be applied to this slice using the deblocking parameters present in this slice header. Otherwise, if one and only one APS contains APS _ deblocking _ filter _ flag equal to 1, APS _ deblocking _ filter _ flag in decoding this slice should be set to 1 and if inherit _ dbl _ params _ from _ APS _ flag is equal to 1, a deblocking filter with deblocking parameters parsed from this APS should be applied in decoding this slice. Otherwise, if there is more than one APS containing APS _ deblocking _ filter _ flag equal to 1, APS _ deblocking _ filter _ flag in decoding this slice should be set to 0 and if inherit _ dbl _ params _ from _ APS _ flag is equal to 0, the deblocking filter should be applied to this slice using the deblocking parameters present in this slice header.

In accordance with the techniques of this disclosure, APS _ deblocking _ filter _ flag may indicate that deblocking parameters are present in the APS, as provided in table 16 below.

TABLE 16 APS syntax with inherited Enabled flag

The semantics of the APS syntax of table 16 are defined as follows. APS _ sample _ adaptive _ offset _ data _ present _ flag equal to 1 specifies that SAO parameters are present in this APS and equal to 0 specifies that SAO parameters are not present in this APS, wherein SAO parameters relate to a SAO enable flag and the SAO parameters when the SAO enable flag is 1.

APS _ sample _ adaptive _ offset _ flag equal to 1 specifies that SAO is on for slices related to the current APS, and equal to 0 specifies that SAO is off for slices related to the current APS. If there is no valid APS or an APS _ sample _ adaptive _ offset _ flag value equal to 0, then the APS _ sample _ adaptive _ offset _ flag value is inferred to be 0.

APS _ adaptive _ loop _ filter _ data _ present _ flag equal to 1 specifies that the ALF parameter is present in such an APS, and equal to 0 specifies that the ALF parameter is not present in such an APS, wherein the ALF parameter relates to the ALF enable flag and the ALF parameter when the ALF enable flag is 1. APS _ adaptive _ loop _ filter _ flag equal to 1 specifies that ALF is on for slices related to the current APS, and equal to 0 specifies that ALF is off for slices related to the current APS. If there is no valid APS or an APS _ adaptive _ loop _ filter _ data _ present _ flag value equal to 0, then the APS _ adaptive _ loop _ filter _ flag value is inferred to be 0.

According to the above APS syntax, the decoding rules for a slice according to the underlying multiple APSs are as follows. When number _ of _ valid _ APS is greater than 1 (as in other cases before), the APS whose ID is equal to APS _ ID [0] can be assumed to be the base APS in decoding the current slice, while the other APSs whose ID is equal to APS _ ID [1], APS _ ID [2],. and APS [ number _ valid _ APS-1] can be assumed to be modified APSs. The presented information in the modified APS whose APS ID is APS _ ID [ i ] (i > 0) (which relates to tool information that is presented in the APS when APS _ deblocking _ filter _ flag is equal to 1 and/or APS _ sample _ adaptive _ offset _ present _ flag is 1 and/or APS _ adaptive _ loop _ filter _ data _ present flag is 1 (i.e., APS _ deblocking _ filter _ flag and deblocking parameters of the deblocking filter and/or APS _ sample _ adaptive _ offset _ flag and SAO _ param () of the SAO and/or APS _ adaptive _ loop _ flag and ALF _ param ()) of the ALF) is previously and temporarily overwritten by the corresponding tool information whose APS ID is APS _ ID [ i-1], [0] of APS _ ID. Further, the finally obtained values of APS _ deblocking _ filter _ flag and deblocking parameters are used to deblock the current slice (additionally depending on the value of the inherit _ dbl _ params _ from _ APS _ flag). The parameters in the finally obtained aps _ sample _ adaptive _ offset _ flag and SAO _ param () are used to implement SAO in decoding the current slice, and the parameters in the finally obtained aps _ adaptive _ loop _ filter _ flag and ALF _ param () are used to implement ALF in decoding the current slice.

In other words, when a slice refers to multiple APSs, for each tool, according to the presentation order of the APS IDs, the last APS containing the data _ present _ flag equal to/of this tool (i.e., APS _ deblocking _ filter _ flag or APS _ sample _ adaptive _ offset _ data _ present flag or APS _ adaptive _ loop _ filter _ data _ present _ flag) is activated to initialize this tool before decoding this slice.

As a second example for signaling deblocking filter parameters using multiple APSs, the slice header may reference multiple different sub-APSs using a unique sub-APS identifier for each type of APS. In this case, the techniques include deblocking filter parameters in sub-APS methods, such as j.tanaka, y.morigami, t.suzuki "non-CE 4subtest3 at 7 th JCT-VC conference doc.jctvc-G295 of 11-month switzerland geneva 2011: the sub-APS method proposed in the Extension of the Adaptation Parameter set syntax for Quantization matrices (Non-CE4Subtest 3: Extension of the Adaptation Parameter set syntax for Quantization matrix).

In accordance with the technique of the present invention, it is proposed to include APS _ dbl _ id in the APS, as immediately in tables 17 and 18. If the inherit _ dbl _ params _ from _ APS _ flag is 1, the deblocking parameters are copied from the APS with APS _ dbl _ id.

TABLE 17 APS syntax with inherited Enabled flag and conditionally coded deblocking APS ID

aps_rbsp(){	Descriptor(s)
		aps_id	ue(v)
aps_deblocking_filter_flag	u(1)
		aps_sample_adaptive_offset_flag	u(1)
aps_adaptive_loop filter_flag	u(1)
		....
if(aps_deblocking_filter_flag){
		aps_dbl_id	ue(v)
disable_deblocking_filter_flag	u(1)
		if(！disable_deblocking_filter_flag){
beta_offset_div2	se(v)

tc_offset_div2	se(v)
		}
}

if(aps_sample_adaptive_offset_flag){
		aps_sao_id	ue(v)
sao_data_byte_count	u(8)
		byte_align()
sao_param()
		byte_align()
}
		if(aps_adaptive_loop_filter_flag){
aps_alf_id	ue(v)
		alf_data_byte_count	u(8)
byte_align()
		alf_param()
byte_align()
		}
rbsp_trailing_bits()
		}

TABLE 18 slice header syntax with sub-APS identifiers

The problem with the above slice header syntax is that APS _ dbl _ id is signaled even when the inherit _ dbl _ params _ from _ APS _ flag is 0. As an alternative, aps _ dbl _ id may be signaled in the slice header, as provided in table 19 below.

TABLE 19 slice header syntax with conditionally coded sub-APS identifiers

As a third example for signaling deblocking filter parameters using multiple APSs, a slice header may reference multiple different sub-APSs using a linked list APS. In this case, the techniques include deblocking filter parameters in a linked list APS-based APS reference approach, for example, as described in "APS reference (APS Referencing)" of santa hese, 2 month, 2011, 8 th JCT-VC conference m. li, p. wu, s. wengi, j. bovises (m.li, p.wu, s.wenger, j.boyce).

The APS reference document is built based on part of the APS update method proposed in JCTVC-G332 in the following sense: it also introduces a flag in the APS to signal the presence of the loop filter and scaling list parameters. In addition, ref _ APS _ flag and ref _ APS _ id syntax elements are introduced into the APS to enable partial updating of parameters through a linked list mechanism. In accordance with the techniques of this disclosure, APS _ deblocking _ filter _ flag may indicate that deblocking parameters are present in the APS, as provided in table 20 below. The associated changes to the syntax of the slice header are provided in table 21 below.

TABLE 20 APS syntax with inherited Enabled flag and Linked List APS

TABLE 21 slice header syntax with Linked List APS identifier

The semantics of the APS and slice header syntax of tables 20 and 21 are defined as follows. The aps _ id identifies an adaptation parameter set referred to by a slice header or by ref _ aps _ id in another adaptation parameter set. The value of aps _ id should be in the range of 0 to 7, including 0 and 7. ref _ aps _ flag equal to 1 specifies that this adaptation parameter set refers to another adaptation parameter set. ref _ aps _ flag equal to 0 specifies that this adaptation parameter set does not refer to any other adaptation parameter set. ref _ aps _ id specifies that this adaptation parameter set refers to a previous adaptation parameter set having an aps _ id equal to ref _ aps _ id.

APS _ deblocking _ filter _ flag indicates that the deblocking parameter is present in the APS (equal to 1) or absent (equal to 0). aps _ scaling _ list _ data _ present _ flag equal to 1 specifies that the scaling list parameters are present in the adaptation parameter set and equal to 0 specifies that the scaling list parameters are not present in the adaptation parameter set. aps _ sample _ adaptive _ offset _ data _ present _ flag equal to 1 specifies that SAO parameters are present in this adaptation parameter set, and equal to 0 specifies that SAO parameters are not present in this adaptation parameter set. aps _ adaptive _ loop _ filter _ data _ present _ flag equal to 1 specifies that ALF parameters are present in this adaptation parameter set, and equal to 0 specifies that ALF parameters are not present in this adaptation parameter set.

scaling _ list _ flag equal to 1 specifies that the scaling matrix is applied for the current slice, and equal to 0 specifies that the scaling matrix is not applied for the current slice. The value of scaling _ list _ flag _ flag should be the same for all slices in the current frame. adaptive _ loop _ filter _ flag equal to 1 specifies that the adaptive loop filter is applied for the current slice, and equal to 0 specifies that the adaptive loop filter is not applied for the current slice. The value of adaptive _ loop _ filter _ flag should be the same for all slices in the current frame. sample _ adaptive _ offset _ flag equal to 1 specifies that sample adaptive offset is applied for the current slice, and equal to 0 specifies that sample adaptive offset is not applied for the current slice. The value of sample _ adaptive _ offset _ flag should be the same for all slices in the current frame.

As a fourth example for signaling deblocking filter parameters using multiple APSs, the slice header may include a partial update of the deblocking filter parameters specified in the APSs. In this case, the techniques include partial updates of deblocking filter parameters. These techniques may be applied, for example, in a method of updating APS parameters using slice header signaling described in "partial update On APS parameters (On partial update of APS parameters)" by the 8 th JCT-VC conference doc, jctvc-H0255, san jose, ca, k.sugimoto, s.

The techniques of this disclosure may update the deblocking filter adjustment parameter in the APS identified by the APS _ id in the slice header based on the deblocking filter adjustment parameter included in the slice header. The techniques may introduce update _ dbl _ params _ in _ APS _ flag in the slice header to indicate when the deblocking filter adjustment parameters in the APS are to be updated by the deblocking filter adjustment parameters in the slice header, as presented in table 22 below.

Table 22. slice header syntax with updated deblocking parameters in the APS flag

slice_header(){	Descriptor(s)
		entropy_slice_flag	u(1)
if(！entropy_slice_flag){
		slice_type	ue(v)
pic_parameter_set_id	ue(v)
		if(sample_adaptive_offset_enabled_flag\|\|adaptive_loop_filter_enabled_flag)
aps_id	ue(v)
		....
if(！entropy_slice_flag){
		slice_qp_delta	se(v)
inherit_dbl_params_from_APS_flag	u(1)
		update_dbl_params_in_APS_flag	u(1)
if((！inherit_dbl_params_from_APS_flag)\|\|update_dbl_params_in_APS_flag){
		disable_deblocking_filter_flag	u(1)
if(！disable_deblocking_filter_flag){
		beta_offset_div2	se(v)
tc_offset_div2	se(v)
		}
}
		.....
}

The semantics of the slice header syntax of table 22 are defined as follows. update _ dbl _ params _ in _ APS _ flag equal to 1 means that the deblocking filter adjustment parameter in APS with ID equal to APS _ ID should be updated using the deblocking filter adjustment parameter in the slice header, and equal to 0 means no update.

Additionally, the techniques of this disclosure may include updating the deblocking filter adjustment parameter in the APS identified by APS _ dbl _ id in the slice header based on the deblocking filter adjustment parameter included in the slice header. The APS _ dbl _ id of the APS that will be updated using the slice header deblocking filter adjustment parameters may be separately signaled in the slice header as presented in table 23 below.

Table 23 slice header syntax with updated deblocking parameters and sub-APS identifiers in the APS flag

slice_header(){	Descriptor(s)
		entropy_slice_flag	u(1)
if(！entropy_slice_flag){
		slice_type	ue(v)
pic_parameter_set_id	ue(v)
		if(sample_adaptive_offset_enabled_flag\|\|adaptive_loop_filter_enabled_flag)
aps_id	ue(v)
		....

if(！entropy_slice_flag){
		slice_qp_delta	se(v)
inherit_dbl_params_from_APS_flag	u(1)
		update_dbl_params_in_APS_flag	u(1)
if(update_dbl_params_in_APS_flag)
		aps_dbl_id
if((！inherit_dbl_params_from_APS_flag)\|\|update_dbl_params_in_APS_flag){
		disable_deblocking_filter_flag	u(1)
if(！disable_deblocking_filter_flag){
		beta_offset_div2	se(v)
tc_offset_div2	se(v)
		}
}
		.....
}

In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media (which corresponds to tangible media such as data storage media) or communication media, including any medium that facilitates transfer of a computer program from one place to another, such as according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a tangible computer-readable storage medium that is not transitory or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. The computer program product may include a computer-readable medium.

By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are directed to non-transitory, tangible storage media. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The instructions may be executed by one or more processors, such as one or more Digital Signal Processors (DSPs), general purpose microprocessors, Application Specific Integrated Circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor," as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware modules and/or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques may be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including wireless handsets, Integrated Circuits (ICs), or groups of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit in conjunction with suitable software and/or firmware or provided by a collection of interoperating hardware units (including one or more processors as described above).

Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method of decoding video data, the method comprising:

decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header;

decoding a second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and

determine that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

2. The method of claim 1, wherein the picture layer parameter set comprises one of a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS).

3. The method of claim 1, wherein decoding the first syntax element comprises decoding the first syntax element in one of the picture layer parameter set or a Sequence Parameter Set (SPS).

4. The method of claim 1, further comprising, when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, defining the deblocking filter applied to the current video slice based on deblocking filter parameters present in one of the picture layer parameter set and the slice header.

5. The method of claim 1, wherein decoding the first syntax element comprises decoding an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

6. The method of claim 5, wherein, when the override is enabled, decoding the second syntax element comprises decoding an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

7. The method of claim 5, wherein, when the override is not enabled, determining that the second syntax element is not present in the slice header comprises determining that an override flag is not present in the slice header to be decoded, further comprising defining the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

8. The method of claim 1, wherein decoding the first syntax element comprises decoding an inherit enabled flag that indicates whether the first set of deblocking filter parameters is present in the picture layer parameter set to be inherited by the slice header.

9. The method of claim 8, wherein, when the first set of deblocking filter parameters is present to be inherited by the slice header, decoding the second syntax element comprises decoding an inherit flag in the slice header that indicates whether to use the second set of deblocking filter parameters included in the slice header or to inherit the first set of deblocking filter parameters from the picture layer parameter set to define the deblocking filter applied to the current video slice.

10. The method of claim 8, wherein, when the first set of deblocking filter parameters is not present to be inherited by the slice header, determining that the second syntax element is not present in the slice header comprises determining that an inherit flag is not present in the slice header to be decoded, further comprising defining the deblocking filter applied to the current video slice based on the second set of deblocking filter parameters included in the slice header.

11. The method of claim 1, further comprising decoding a third syntax element defined to indicate that deblocking filter control syntax elements are present in the picture layer parameter set and the slice header prior to decoding the first syntax element, wherein the deblocking filter control syntax elements comprise the first syntax element and the second syntax element.

12. The method of claim 11, wherein decoding the third syntax element comprises decoding a control present syntax element in one of the picture layer parameter set and Sequence Parameter Set (SPS).

13. The method of claim 1, further comprising decoding a fourth syntax element defined to indicate that the deblocking filter is enabled for the current video slice.

14. The method of claim 13, wherein decoding the fourth syntax element comprises decoding a deblocking filter enabled flag in a Sequence Parameter Set (SPS) prior to decoding the first syntax element.

15. A video decoding device, comprising:

a memory storing video data; and

a processor configured to decode a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header,

wherein the processor is configured to, when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, decode a second syntax element in the slice header, the second syntax element defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header are used to define a deblocking filter applied to a current video slice, and

wherein the processor is configured to determine that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

16. The video decoding device of claim 15, wherein the picture layer parameter set comprises one of a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS).

17. The video decoding device of claim 15, wherein the processors are configured to decode the first syntax element in one of the picture layer parameter set or a Sequence Parameter Set (SPS).

18. The video decoding device of claim 15, wherein the processor is configured to, when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, define the deblocking filter applied to the current video slice based on deblocking filter parameters present in one of the picture layer parameter set and the slice header.

19. The video decoding device of claim 15, wherein the processor is configured to decode an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

20. The video decoding device of claim 19, wherein the processor is configured to, when the override is enabled, decode an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

21. The video decoding device of claim 19, wherein the processor is configured to determine that an override flag is not present in the slice header to be decoded when the override is not enabled, and define the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

22. The video decoding device of claim 15, wherein the processor is configured to decode an inherit enabled flag that indicates whether the first set of deblocking filter parameters is present in the picture layer parameter set to be inherited by the slice header.

23. The video decoding device of claim 22, wherein the processors are configured to, when the first set of deblocking filter parameters is present to be inherited by the slice header, decode an inherit flag in the slice header that indicates whether to use the second set of deblocking filter parameters included in the slice header or to inherit the first set of deblocking filter parameters from the picture layer parameter set to define the deblocking filter applied to the current video slice.

24. The video decoding device of claim 22, wherein the processor is configured to, when the first set of deblocking filter parameters is not present to be inherited by the slice header, determine that an inherit flag is not present in the slice header to be decoded, and define the deblocking filter applied to the current video slice based on the second set of deblocking filter parameters included in the slice header.

25. A video decoding device, comprising:

means for decoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header;

means for decoding a second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header is used to define a deblocking filter applied to a current video slice; and

means for determining that the second syntax element is not present in the slice header to be decoded when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

26. The video decoding device of claim 25, wherein the picture layer parameter set comprises a Picture Parameter Set (PPS).

27. The video decoding device of claim 25, wherein the means for decoding the first syntax element comprises means for decoding an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

28. The video decoding device of claim 27, wherein, when the override is enabled, the means for decoding the second syntax element comprises means for decoding an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

29. The video decoding device of claim 27, wherein, when the override is not enabled, the means for determining that the second syntax element is not present in the slice header comprises means for determining that an override flag is not present in the slice header to be decoded, further comprising means for defining the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

30. A computer-readable medium comprising instructions for decoding video data that, when executed, cause one or more processors to:

31. A method of encoding video data, the method comprising:

encoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header;

encoding a second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, the second syntax element defined to indicate whether to use a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header to define a deblocking filter applied to a current video slice; and

when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, eliminating encoding of the second syntax element in the slice header.

32. The method of claim 31, wherein the picture layer parameter set comprises one of a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS).

33. The method of claim 31, wherein encoding the first syntax element comprises encoding the first syntax element in one of the picture layer parameter set or a Sequence Parameter Set (SPS).

34. The method of claim 31, further comprising, when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, defining the deblocking filter applied to the current video slice based on deblocking filter parameters present in one of the picture layer parameter set and the slice header.

35. The method of claim 31, wherein encoding the first syntax element comprises encoding an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

36. The method of claim 35, wherein, when the override is enabled, encoding the second syntax element comprises encoding an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

37. The method of claim 35, wherein, when the override is not enabled, eliminating encoding of the second syntax element comprises eliminating encoding of an override flag in the slice header, further comprising defining the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

38. The method of claim 31, wherein encoding the first syntax element comprises encoding an inherit enabled flag that indicates whether the first set of deblocking filter parameters is present in the picture layer parameter set to be inherited by the slice header.

39. The method of claim 38, wherein, when the first set of deblocking filter parameters is present to be inherited by the slice header, encoding the second syntax element comprises encoding an inherit flag in the slice header that indicates whether to use the second set of deblocking filter parameters included in the slice header or to inherit the first set of deblocking filter parameters from the picture layer parameter set to define the deblocking filter applied to the current video slice.

40. The method of claim 38, wherein, when the first set of deblocking filter parameters is not present to be inherited by the slice header, eliminating encoding of the second syntax element comprises eliminating encoding of an inherit flag in the slice header, further comprising defining the deblocking filter applied to the current video slice based on the second set of deblocking filter parameters included in the slice header.

41. The method of claim 31, further comprising encoding, prior to encoding the first syntax element, a third syntax element defined to indicate that deblocking filter control syntax elements are present in the picture layer parameter set and the slice header, wherein the deblocking filter control syntax elements comprise the first syntax element and the second syntax element.

42. The method of claim 41, wherein encoding the third syntax element comprises encoding a control present syntax element in one of the picture layer parameter set and a Sequence Parameter Set (SPS).

43. The method of claim 31, further comprising encoding a fourth syntax element defined to indicate that the deblocking filter is enabled for the current video slice.

44. The method of claim 43, wherein encoding the fourth syntax element comprises encoding a deblocking filter enabled flag in a Sequence Parameter Set (SPS) prior to encoding the first syntax element.

45. A video encoding device, comprising:

a memory storing video data; and

a processor configured to encode a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header,

wherein the processor is configured to, when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, encode a second syntax element in the slice header, the second syntax element defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header are used to define a deblocking filter applied to a current video slice, and

wherein the processor is configured to eliminate encoding of the second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

46. The video encoding device of claim 45, wherein the picture layer parameter set comprises one of a Picture Parameter Set (PPS) or an Adaptation Parameter Set (APS).

47. The video encoding device of claim 45, wherein the processors are configured to encode the first syntax element in one of the picture layer parameter set or a Sequence Parameter Set (SPS).

48. The video encoding device of claim 45, wherein the processors are configured to, when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header, define the deblocking filter applied to the current video slice based on deblocking filter parameters present in one of the picture layer parameter set and the slice header.

49. The video encoding device of claim 45, wherein the processor is configured to encode an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

50. The video encoding device of claim 49, wherein the processor is configured to, when the override is enabled, encode an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

51. The video encoding device of claim 49, wherein the processor is configured to eliminate encoding of an override flag in the slice header when the override is not enabled, and to define the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

52. The video encoding device of claim 45, wherein the processor is configured to encode an inherit enabled flag that indicates whether the first set of deblocking filter parameters is present in the picture layer parameter set to be inherited by the slice header.

53. The video encoding device of claim 52, wherein the processors are configured to, when the first set of deblocking filter parameters is present to be inherited by the slice header, encode an inherit flag in the slice header that indicates whether to use the second set of deblocking filter parameters included in the slice header or to inherit the first set of deblocking filter parameters from the picture layer parameter set to define the deblocking filter applied to the current video slice.

54. The video encoding device of claim 52, wherein the processor is configured to, when the first set of deblocking filter parameters is not present to be inherited by the slice header, eliminate encoding of an inherit flag in the slice header, and define the deblocking filter applied to the current video slice based on the second set of deblocking filter parameters included in the slice header.

55. A video encoding device, comprising:

means for encoding a first syntax element defined to indicate whether deblocking filter parameters are present in both a picture layer parameter set and a slice header;

when the first syntax element indicates that deblocking filter parameters are present in both the picture layer parameter set and the slice header, means for encoding a second syntax element in the slice header, the second syntax element defined to indicate whether a first set of deblocking filter parameters included in the picture layer parameter set or a second set of deblocking filter parameters included in the slice header is used to define a deblocking filter applied to a current video slice; and

means for eliminating encoding of the second syntax element in the slice header when the first syntax element indicates that deblocking filter parameters are not present in both the picture layer parameter set and the slice header.

56. The video encoding device of claim 55, wherein the picture layer parameter set comprises a Picture Parameter Set (PPS).

57. The video encoding device of claim 55, wherein the means for encoding the first syntax element comprises means for encoding an override enabled flag in the picture layer parameter set that indicates whether an override of the first set of deblocking filter parameters by the second set of deblocking filter parameters is enabled.

58. The video encoding device of claim 57, wherein, when the override is enabled, the means for encoding the second syntax element comprises means for encoding an override flag in the slice header that indicates whether to use the first set of deblocking filter parameters from the picture layer parameter set or to override the first set of deblocking filter parameters with the second set of deblocking filter parameters included in the slice header to define the deblocking filter applied to the current video slice.

59. The video encoding device of claim 57, wherein, when the override is not enabled, the means for eliminating encoding of the second syntax element comprises means for eliminating encoding of an override flag in the slice header, further comprising means for defining the deblocking filter applied to the current video slice based on the first set of deblocking filter parameters included in the picture layer parameter set.

60. A computer-readable medium comprising instructions for encoding video data that, when executed, cause one or more processors to: