TWI578763B - Coding unit bit number limitation - Google Patents

Description

Coding unit bit number limit

The present invention relates to the coding unit bit number limitation.

High Efficiency Video Coding (HEVC), currently developed as a video by the Joint Coordination Group for Video Coding (JCT-VC) formed by the ISO/IEC Motion Picture Experts Group (MPEG) and the ITU-T Video Coding Experts Group (VCEG) The compression standard is expected to be completed in 2013. Similar to previous video coding standards, HEVC includes basic functional modules such as internal/inter-frame prediction, transform, quantization, loop filtering, and entropy coding. The HEVC defines the largest coding unit (LCU) of the picture and then divides into coding units (CUs) in the form of rectangular blocks having a variable size. The CU contains square blocks of Luma pixels and chrominance pixels of two corresponding blocks. The size of the CU can be configured as an 8x8, 16x16, 32x32 or 64x64 Luma component. The LCU is considered to be the basic unit when implementing the HEVC codec.

To reduce decoder complexity, HEVC constrains the number of bits of any coded LCU to a limit value. Because of the limit of the number of LCU bits, the decoder Knowing the worst case bit size of the encoded LCU, and as long as the number of bits is not exceeded, a buffer of sufficient size to accommodate the decoding of any size LCU may be allocated. However, it should be noted that the restriction bit value is chosen because although larger limit values may significantly reduce the likelihood of coded LCUs breaking constraints, they also increase the need for decoder memory resources. In the recent draft HEVC specification (see ISO/IEC JTC/SC29/WG11 and ITU-T SG16 WP3, "High Efficiency Video Coding (HEVC) Text Specification Draft 9" (JCTVC-J1003_d9), October 2012), The bit digit limit value (LCUBitNumLimit) is set to a single specific ratio of the LCU's uncompressed original data bit number (LCURawDataNum), as shown in Equation (1) and Equation (2) below: LCURawDataNum=sizeY*sizeY*bitdepthY +2*sizeC*sizeC*bitdepthC (1)

LCUBitNumLimit=(4/3)*LCURawDataNum (2)

Where sizeY and bitdepthY are the block size and bit depth of the Luma component of the LCU, respectively, and sizeC and bitdepthC are the block size and bit depth of the chrominance component of the LCU, respectively.

100‧‧‧ system

101‧‧‧ Input image

102‧‧‧Encoder

104‧‧‧Code Unit Partitioning Module

106‧‧‧Transformation and Quantization Module

108‧‧‧Anti-quantization and inverse transformation module

110‧‧‧Internal forecasting module

112‧‧‧Deblocking filter module

114‧‧‧sample adjustable offset filter module

116‧‧‧Inter-frame prediction module

117‧‧‧ mode decision module

118‧‧‧Entropy coding module

119‧‧‧ bit flow

120‧‧‧Decoder

122‧‧‧ Entropy decoding module

124‧‧‧Anti-transformation module

126‧‧‧Internal forecasting module

127‧‧‧ grammar control module

128‧‧‧Deblocking filter module

130‧‧‧sample adjustable offset filter module

132‧‧‧Inter-frame prediction module

134‧‧‧ coding unit assembly module

135‧‧‧ output image

200‧‧‧ bit flow

202‧‧‧ head

204‧‧‧Information Department

206‧‧‧ indicators

208‧‧‧ indicators

210‧‧‧Information package

300‧‧‧ procedures

302‧‧‧ squares

304‧‧‧ square

306‧‧‧ squares

308‧‧‧ squares

310‧‧‧ square

312‧‧‧ square

400‧‧‧Video Coding System

402‧‧‧Processor

406‧‧‧Video Codec Module

408‧‧‧ memory

500‧‧‧ system

502‧‧‧ platform

505‧‧‧ chipsets

510‧‧‧ processor

512‧‧‧ memory

513‧‧‧Antenna

514‧‧‧Storage

515‧‧‧Graphics Subsystem

516‧‧‧Application

518‧‧‧ radio

520‧‧‧ display

522‧‧‧User interface

530‧‧‧Content service device

540‧‧‧Content delivery device

550‧‧‧Navigation controller

560‧‧‧Network

600‧‧‧ device

602‧‧‧ Shell

604‧‧‧ display

606‧‧‧Input/Output (I/O) devices

608‧‧‧Antenna

612‧‧‧ navigation function

700‧‧‧Program

701‧‧‧ Input image

702‧‧‧Encoder

704‧‧‧ squares

705‧‧‧Maximum coding unit

706‧‧‧ square

708‧‧‧ square

710‧‧‧ square

712‧‧‧ square

719‧‧‧ bit flow

720‧‧‧Decoder

722‧‧‧ squares

724‧‧‧ square

725‧‧‧Maximum coding unit

726‧‧‧ square

735‧‧‧ output image

800‧‧‧Video coding program

802‧‧‧ square

804‧‧‧ square

900‧‧‧Video coding program

901‧‧‧ square

902‧‧‧ square

903‧‧‧ square

904‧‧‧ square

905‧‧‧ square

906‧‧‧ square

907‧‧‧ square

908‧‧‧ square

909‧‧‧ square

910‧‧‧ square

911‧‧‧

912‧‧‧ squares

913‧‧‧ squares

914‧‧‧ square

920‧‧‧Logic Module

930‧‧‧Encoder

940‧‧‧Decoder

950‧‧‧bit limit module

960‧‧‧bit limit module

1000‧‧‧Video Coding System

1001‧‧‧ imaging device

1002‧‧‧Video Encoder

1003‧‧‧Antenna

1004‧‧‧Video Decoder

1006‧‧‧ processor

1008‧‧‧ memory storage

1010‧‧‧ display

1040‧‧‧Logic Module

The materials described herein are illustrated by way of example and not limitation. For the sake of simplicity and clarity of the illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to the other elements for clarity. In addition, if deemed appropriate, the reference number has been Repeat between the figures to indicate corresponding or similar components. In the drawings: FIG. 1 is an explanatory diagram of an example video encoding system; FIG. 2 is an explanatory diagram of an example video encoding scheme; FIG. 3 is a flowchart illustrating an example program; FIG. 4 is an explanatory diagram of an example video encoding system; FIG. 6 is a flowchart illustrating an example program; FIG. 8 is a flowchart illustrating an example video encoding program; FIG. 9 is an explanatory diagram in an operation of an example video encoding program; 10 is an illustration of an example video coding system, all configured in accordance with some implementations of the present invention.

SUMMARY OF THE INVENTION AND EMBODIMENT

One or more embodiments or implementations are now described with reference to the drawings. While specific configurations and configurations are discussed, it should be understood that this is for illustrative purposes only. Those skilled in the art will recognize that other configurations and configurations may be utilized without departing from the spirit and scope of the present description. It will be readily apparent to those skilled in the art that the techniques and configurations described herein may also be utilized in a variety of other systems and applications in addition to those described herein.

Although the following description presents various implementations that may behave in a structure such as a system single-chip (SoC) structure, the techniques and/or configurations described in the text are not limited to a particular configuration and/or computing system and may be utilized. Any structure and/or computing system is implemented for similar purposes. example For example, various structures, such as a plurality of integrated circuit (IC) chips and/or packages, and/or various computing devices such as set-top boxes, smart phones, and/or consumer electronics (CE) devices may be utilized to implement the text. Technology and / or configuration. Furthermore, although the following description may suggest many specific details such as logic implementation, type and linkage of system components, logical partitioning/integration selection, etc., the claimed subject matter may not be implemented with such specific details. In other examples, some materials, such as control structures and complete software instruction sequences, may not be shown in detail so as not to obscure the materials disclosed herein.

The materials disclosed herein may be implemented in hardware, firmware, software, or any combination thereof. The materials disclosed herein may also be implemented as instructions stored on a machine readable medium, which may be read and executed by one or more processors. Machine readable media may include any medium and/or mechanism for storing or transmitting information in a form readable by a machine (eg, a computing device). For example, machine readable media may include read only memory (ROM); random access memory (RAM); disk storage media; optical storage media; flash memory devices; electrical, optical, acoustic or other forms. Propagating signals (eg, carrier waves, infrared signals, digital signals, etc.), among others.

References to "one implementation," "implementation," "example implementation," and the like in the specification are intended to include a particular feature, structure, or characteristic, but each embodiment may not necessarily include a particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same implementation. Furthermore, when a particular feature, structure, or characteristic is described with respect to the embodiments, it is proposed that This feature, structure, or characteristic is realized in the knowledge of those skilled in the art, and in other implementations that are specifically described herein.

The following describes systems, devices, objects, and methods related to video coding that includes coding unit bit number limits.

As described above, in video coding, the maximum number of coded unit (LCU) bits of any code may be limited by the limit value (eg, the LCU bit number limit). Based on the LCU bit number limit, the decoder can be configured to allocate, for example, a buffer of sufficient size to accommodate the number of bits. In general, a larger number of bit numbers may reduce the likelihood that the encoded LCU will violate the constraint. Violation of the constraints on the encoder may cause the encoder to enter the internal block pulse code modulation (I_PCM) mode, which does not apply compression (for example, directly transmitting the original data) and usually excludes the standard encoder pipeline. A violation may result in the encoder suspending the encoder pipeline and starting the I_PCM branch. This type of operation can significantly impair the performance of the encoder and, in general, the encoder may require a larger number of bit limits. However, it should be noted that in selecting the bit value of the limit, although a larger limit value may significantly reduce the likelihood that the encoded LCU violates the constraints described above, a larger number of bit limits may increase the decoder. Memory resource requirements (for example, allocated buffer size), as described earlier. Therefore, selecting the LCU bit number limit may be an important factor in video coding and may affect performance at the encoder, decoder, or both.

Techniques for selecting and executing the LCU bit number limit will be described in more detail below. In some examples, the LCU bit number limit (eg, the number of bits used for or associated with a video data block) may be It can be determined according to the coding mode of the video encoder. For example, according to the active video coding mode, the bit number limit scale factor can be determined from a plurality of bit number limit scale factors, and the bit number limit scale factor can be multiplied by the original video data size of the video data block to determine the bit element. Number limit. In general, an encoding mode that tends to generate fewer bits may have a smaller bit number limit scaling factor, while an encoding mode that tends to generate more bits may have a larger bit number limit scaling factor. In general, the bit scale limit factor may be in the range of about 1 to 2, as further described herein. On the encoder side, the implementation of this technique may reduce the frequency of violations of the video block coding constraints, and in the decoder, this technique may limit or reduce the amount of memory dedicated to the video block (eg, buffer size) ).

In other examples, the bit number limit scale factor may be predetermined to have a value of 5/3, which is applicable to all coding modes. In such an example, the number of bits associated with or associated with the largest coding unit (LCU) of the video material may be determined by multiplying the maximum number of coding unit original data by the 5/3 number of bits limiting scale factor. . The video material can be encoded according to the determined number of bits. Such an implementation may again provide for reducing encoder intrusion and limiting decoder-specific memory while providing further advantages of implementation simplification.

As used herein, the term "coder" may refer to an encoder and/or a decoder. Similarly, the term "encoding" as used herein may refer to performing video encoding through an encoder and/or performing video decoding through a decoder. For example, video encoders and videos Both decoders may be examples of encoders capable of encoding video material. Moreover, as used herein, the term "codec" can refer to any program, program, or set of operations, such as, for example, any combination of software, firmware, and/or hardware that can perform an encoder and/or decode. Device.

1 is an illustration of an example video encoding system 100 in accordance with at least some implementations of the present disclosure. In various implementations, system 100 can perform video compression and decompression and/or perform video codecs in accordance with one or more standards or specifications, such as, for example, the High Efficiency Video Coding (HEVC) standard (see ISO/IEC JTC/ SC29/WG11 and ITU-T SG16 WP3, "High Efficiency Video Coding (HEVC) Text Specification Draft 8" (JCTVC-J1003_d7), July 2012). Although system 100 and/or other systems, programs, or programs may be described herein within the context of the HEVC standard, the disclosure is not limited to any particular video coding standard or specification or extension thereof.

The HEVC standard specifies that images can be divided into non-overlapping maximum coding units (LCUs) and each LCU can then be divided into coding units (CUs), which take the form of rectangular blocks of variable size. Within each LCU, the quaternary tree-based splitting scheme specifies the CU partitioning mode. HEVC also defines a prediction unit (PU) and a transform unit (TU) that specify how to partition a given CU for the purpose of prediction and transformation, respectively. A CU typically includes a luma coded block (CB) and two chroma CBs with associated syntax, and the PU can be further divided into prediction blocks (PBs) ranging from 64x64 samples to 4x4 sample size ranges. As used herein, the term "block" can refer to any partition or sub-partition of a video image. For example, the block can Refers to video material corresponding to LCU, PU, PB, TU or CU.

As shown, system 100 can include an encoder 102 and a decoder 120. After processing the input image with the coding unit partition module 104, the encoder 102 may encode the input image 101 using an encoding loop, which may include a transform and quantization module 106, an inverse quantization and inverse transform module 108, And, the first path including the internal prediction module 110, that is, the second path including the deblocking filtering module 112, the sample adaptive offset filtering module 114, and the inter-frame prediction module 116 (depending on the encoder 102) The mode implemented by the mode decision module 117 is determined). After converting the input image 101, the encoder 102 can use the entropy encoding module 118 to entropy encode the compressed image. Finally, encoder 102 can generate a bitstream 119 that combines the encoded video material. The functionality of modules 104, 106, 108, 110, 112, 114, 116, 117, and 118 is well known in the art and will not be described in greater detail herein.

The decoder 120 can receive the video data encoded in the form of the bit stream 119, and after processing the data by the entropy decoding module 122 and the inverse quantization and inverse transform module 124, the internal prediction module 126 can be used and used. The first path, or the second path including the deblocking filtering module 128, the sample adaptive offset filtering module 130, and the inter-frame prediction module 132 (depending on the syntax represented by the bitstream 119 and the syntax control module 127) The decoding mode of the implemented coding mode) and the decoded result data. The decoder 120 can then utilize the coding unit assembly module 134 to produce a decoded output image 135 that can be presented to the user, for example, via a display. The functionality of modules 122, 124, 126, 127, 128, 130, 132, and 134 is well known In this technique, it will not be described in more detail herein.

Although FIG. 1 illustrates a system 100 that utilizes a particular encoding and decoding module, various other encoding modules or components not depicted in FIG. 1 may be utilized in accordance with the present disclosure for clarity. Moreover, the present disclosure is not limited to the particular elements shown in FIG. 1 and/or the manner in which various elements of system 100 are configured. The various components of the system described herein can be implemented in software, firmware, and/or hardware and/or any combination thereof. For example, the various components of system 100 may be provided at least in part by hardware of a computing system single chip (SoC), such as may be found in a computing system such as a mobile phone.

Moreover, it will be appreciated that the encoder 102 of the system 100 can be associated with and/or provided by a content provider system including, for example, a video content server system, and the bitstream 119 can be represented by, for example, FIG. Various communication elements and/or systems of transceivers, antennas, network systems, and the like, not shown, are transmitted or communicated to decoder 120. It will be appreciated that the decoder 120 can be associated with a client system such as a computing device (eg, a desktop, laptop, tablet, convertible laptop, mobile phone, or the like) that is encoded The remote end of the device 102 receives the bit stream 119 through various communication elements and/or systems, such as transceivers, antennas, network systems, and the like, not shown in FIG. Thus, in various implementations, the encoder subsystem 101 and the decoder subsystem 103 can be implemented together or independently of one another. Furthermore, although the systems, devices, and methods described herein can be referred to as input and output image and video data blocks and the like, the disclosure is not limited in this respect, and the techniques discussed can be implemented in architecture or any suitable video. Data element, such as, for example, a sequence, Layer, image, slide or block.

In accordance with the present disclosure, as explained in more detail below, in some implementations, in an encoded program, video material encoder 102 can be selected from various bit number limit values and can associate selected values with video data blocks. . In different implementations, these blocks can be LCUs. In some examples, depending on which encoding mode encoder 102 is used to encode the video material, the encoder 102 may associate different ones of the various bit number limit values with the encoded LCU. In doing so, the encoder can assign a higher number of bit limits to the LCU when the particular set of coding modes utilized will be more likely to generate more bits. For example, if all encoding modes in the HEVC primary profile other than the transform skip mode are utilized, the encoder 102 can assign a higher number of bit limits to the LCU, while utilizing the HEVC primary profile including the transform skip mode. In all of the encoding modes, encoder 102 can assign a lower number of bit limits.

In some implementations, video material encoder 102 and/or video data decoder 120 may determine the number of bits limit from a plurality of bit number limit scale factors by determining a bit number limit scale factor. The determination of the bit number limit scale factor from the plurality of bit number limit scale factors may be based on the active video coding mode of the video material encoder 102, and the bit number limit may be determined based on the bit number limit scale factor. For example, the bit number limit can be determined by multiplying the bit number limit scale factor by the original video material size of the video data block. Such techniques may be applied to both video material encoder 102 and video material decoder 120, for example, via a profile or table of both video material encoder 102 and video data decoder 120 via standard applications.

In other examples, video material encoder 102 may encode a plurality of bit number limit scale factors and corresponding coding modes through bit stream 119. As described further below, the bit number limit scale factor and corresponding coding mode may be included in a portion of the Supplemental Enhancement Information (SEI) packet of bit stream 119. In such an example, video material encoder 102 may customize the combination of coding mode and corresponding bit number limit scale factor values, and thereby manage the constraints and details of the restrictions in the encoding process. Video material decoder 120 may then implement the received coding mode and corresponding bit number limit scale factor values as described herein. In some examples, the preset number of bits limit scale factor may be used if not otherwise specified. In a different example, the preset number of bits limit scale factor may be 3/2 or 5/3 or a similar number.

In some implementations, video material encoder 102 and/or video data decoder 120 may implement a bit number limit scale factor having a predetermined value of 5/3, which may be applied to all coding modes. In such an example, the number of bits of the maximum coding unit (LCU) used or associated with the video material (eg, LCUBitNumLimit) may maximize the number of original data of the unit (eg, as LCAUawDataNum through equation (1) above) Determined by multiplying by the 5/3 number of bits of the limit scale factor shown in equation (3): LCUBitNumLimit=(5/3)*LCURawDataNum (3)

The video material may be encoded at video material encoder 102 and/or video data decoder 120 in accordance with a determined number of bit limits as described herein.

As used in the text, the phrase "coding mode" refers to no In one of the same compression modes, the encoder can use this mode to compress video material, including but not limited to internal mode, mutual mode, transform skip mode, and the like. As those skilled in the art will recognize that by utilizing the transform skip mode, the encoder can encode some video material using fewer bits and, correspondingly, the decoder can store with a smaller buffer size. Encoded video material. In a different example, as described further below, the coding mode may include all coding modes in the HEVC primary profile allowing for transform skipping, all coding modes in the HEVC primary profile except for disabling transform skip, HEVC primary still image settings All encoding modes in the file allow for transform skipping, all encoding modes in the HEVC main still image profile, except that the transform skip is disabled, all encoding modes in the HEVC main 10 profile allow for transform skipping, or HEVC main 10 profiles All encoding modes in the middle are disabled except for transform skipping, or the like.

In general, the HEVC primary profile may include profiles for encoding I (internal coding), P (predictive) or B (bi-predictive) images, while HEVC primary still image profiles may include for encoding only I images. The profile allows the HEVC primary still image profile to be a subset of the HEVC primary profile. Additionally, for example, the HEVC primary profile may include a profile encoding a bit depth of 8 bits, and the HEVC primary 10 profile may include a profile encoded with a bit depth of 10 bits.

Generally, in accordance with the present disclosure, a wide variety of scaling factors can be selected based on the encoding mode used by the encoder or decoder, as described. The selected scale factor can then be used to assign the number of bits based on equation (4): LCUBitNumLimit=scale_factor(coding modes)*LCURawDataNum (4)

Where scale_factor(.) represents a function of mapping the set of coding modes to the range of [1.0, 2.0] or [1.0, 2.0] or a rational number within a similar range. The usage of Scale_factor(.) can be described in the form of a mapping table. For example, determining the number of bit limit scale factors can include accessing a table having a plurality of bit number limit scale factors and corresponding coding modes. First, all possible coding modes can be managed into a set of numbers, with each set assigning input metrics in the mapping table. Then, a specific number can be assigned to all inputs.

For example, the following table illustrates an instance scale factor mapping:

Thus, encoder 102 or decoder 120 may assign, specify, or select different scale factors depending on the combination of coding modes utilized to compress the image (or general video material). As a non-limiting example, the following table illustrates a specific instance scale factor mapping:

As shown in the non-limiting example of Table 2, encoder 102 or decoder 120 may assign, specify, or select when all HEVC primary profile encoding modes with a first index value corresponding to a scale factor value of 4/3 are utilized. The first index value. In contrast, when all HEVC primary profile encoding modes that utilize a second index value equivalent to a scale factor value of 3/2 (or 1.5), in addition to the transform skip mode, the encoder 102 can assign, assign, or select a second Index value. Furthermore, as for the coding modes in the HEVC main profile, whether or not those coding modes include a transform skip mode, the encoder 102 may assign, specify or select a second index value equivalent to a 5/3 scale factor value. In various implementations, the scale factor utilized may be any number greater than or equal to one and less than or equal to two. In other words, in different limits, the scale factor can have a span [1.0, 2.0] or [1.0, 2.0] Value or similar value.

As described, the bit number limit scale factor can be determined from a plurality of bit number limit scale factors based on the coding mode. In general, any number and combination of coding modes and corresponding bit number scaling factors can be implemented. In some examples, the encoded video data block may include High Efficiency Video Coding (HEVC) video material. In such an example, the first coding mode may include all coding modes in the HEVC primary profile allowing for transform skipping and the corresponding first number of bits limit scaling factor may include 4/3, and the second coding mode may include HEVC primary All encoding mode disable transform skips in the profile and the corresponding second bit number limit scale factor may include 3/2, and the third encoding mode may include all encoding modes in the HEVC main still image profile allowing the transform to skip And the corresponding third bit number limit scale factor may include 4/3, and the fourth coding mode may include all coding mode disable transform skips and corresponding fourth bit number limit scale factors in the HEVC main still image profile May include 3/2, the fifth encoding mode may include all encoding modes in the HEVC primary 10 profile allowing transform skipping and the corresponding fifth bit number limit scaling factor may include 5/3, and the sixth encoding mode may include HEVC All encoding modes in the main 10 profile disable the transform skip and the corresponding sixth bit limit scale factor may include 5/3.

As noted above, in various implementations, the scale factor can be assigned to various video specification profiles and/or horizontal portions in a predetermined manner. For example, the HEVC primary profile can be assigned a scale factor for determining the LCU bit number limit, while the HEVC primary 10 profile can be assigned a different scale factor for determining the LCU bit number limit. Therefore, depending on the application The decoder may then apply a predetermined scaling factor to the encoding type of the received video material (eg, primary profile or primary 10 profile) to determine the corresponding LCU bit number limit using equation (3), and thus Buffering requirements.

In other implementations, the scaling factor can be predetermined to have an applicable value of 5/3 regardless of the encoding mode utilized. Thus, regardless of the type of encoded video material received (eg, primary profile, primary still image profile, or primary 10 profile or similar), the decoder can apply a predetermined scale factor of 5/3 to use the equation (3) to determine the corresponding LCU bit number limit, and thus determine the buffering requirement.

As described, in different implementations, the scale factor can be associated with the coding mode and the determined or selected scale factor can be used to determine the number of bits limit. In other examples, the bit number limit may be associated with a corresponding encoding mode and used directly to determine the bit number limit for use in or associated with an encoding mode and a video data block (such as, for example, an LCU). In such an example, the amount of original data for the video data block may be constant or assumed to be constant or similar.

7 is a flow diagram illustrating an example process in accordance with at least some of the implementations of the present disclosure. As shown, the routine 700 can be implemented by the encoder 702 and the decoder 720. The process 700 can include receiving an input image 701 through the encoder 702, and dividing the input image 701 into a maximum coding unit (LCU) 705, at block 704, "dividing the image into LCUs." Although the input image 701 and the LCU 705 are discussed, the techniques are applicable to any input video and video data blocks as described herein. LCU 705 is transparent The encoder 702 is encoded at block 706 to "encode the LCU using the normal encoding mode" using a periodic or typical encoding mode, as described herein. In addition, the bit number limit of the LCU 705 can be applied as described. In some examples, the bit number limit of the LCU 705 can be determined based on the number of bit limit scale factors, which are determined from a plurality of bit number limit scale factors based on the coding mode. In other examples, the bit number limit of the LCU 705 can be determined based on the multiplication of the LCU raw data quantity and the 5/3 scale factor.

In any event, at block 708, "Check if the LCU bit size violates the limit", the LCU bit size of the encoded LCU 705 can be compared to the bit number limit. If the encoded LCU has fewer bits than the number of bits (eg, no violation has occurred), the encoded LCU or LCUs may be encoded or wrapped into a bitstream 719 at block 710, "encapsulated bitstream." If the encoded LCU has more bits than the number of bits (eg, a violation has occurred), the violated LCU may be re-encoded using the internal block pulse code modulation (I_PCM) mode at block 712, "Re-use I_PCM mode Code LCU". The re-encoded LCU may be included in bit stream 719 at block 710. As stated, the I_PCM mode does not apply compression (eg, directly transfer raw material) and typically excludes standard encoder pipelines. Thus, a violation at block 708 may cause encoder 702 to suspend the standard encoder pipeline and initiate the I_PCM branch. This operation can greatly impair the performance of the encoder 702.

The process 700 can continue at block 722, "Retrieve and mitigate LCU data from the bitstream" so that the received bitstream 719 can be received and fetched from the bitstream 719 and mitigate the LCU data. Again, just as the text As described therein, in some examples, the bitstream 719 can include a bit number limit scaling factor and a corresponding encoding mode, and in other examples, the bit number scaling factor and corresponding encoding mode can be implemented directly by the decoder 720. . Moreover, in some examples, a constant scale factor, such as a scale factor of 5/3, can be applied. In any event, at decoder 720, the bit number scale factor and the LCU bit number limit may determine a dedicated or allocated buffer size, as described. If the LCU bit number limit is too large, the performance of the decoder 720 may have a negative impact, or the decoder 720 may typically perform unnecessary and expensive memory resources. As shown, at block 724, "Decode LCU", the LCU data can be decoded to produce LCUs 725, which can be combined at block 726, "combined images" to produce an output image 735. For example, the output image 735 can be presented to the user via the display device.

As described, FIG. 7 illustrates an example program 700. Figure 7 also illustrates the importance of selecting the number of bits of the video coding block. As stated, for example, too small a bit number limit may result in poor performance at the encoder 702, while too large a bit number limit may result in poor performance at the decoder 720.

As noted above, in some implementations, the determination of the scale factor and the number of bits of the video data block may be determined at both the encoder and the decoder using the same or similar techniques. In some examples, a constant scale factor (eg, a 5/3 scale factor) can be used, while in other examples, the scale factor can be determined from multiple scale factors based on the coding mode. In other implementations, the encoder can have multiple bit number limit scale factors The bit stream is encoded with the corresponding coding mode such that the decoder can use the information provided to implement the scale factor and number of bits limits as described herein, and in particular, with respect to Figure 9 below. In still other implementations, the encoder can provide information to the decoder informing the decoder of the scale factor with which the encoder has assigned, specified, or selected any particular encoded video material.

In other implementations, the encoder can place an indicator, a message, or a portion thereof in a bit stream or portion thereof that the encoder provides to the decoder. The decoder can then use this information to identify the selected scale factor, and then Equation (4) can be used to determine the LCU bit number limit and the corresponding buffer size for storing the encoded video material.

Thus, referring again to FIG. 1, encoder 102 may include indicators, messages, or portions thereof in bitstream 119 or portions thereof to inform decoder 120 that associated portions of encoded video material communicated by bitstream 119 are associated. The selected scale factor. 2 is an illustration of an example video coding scheme configured in accordance with at least some implementations of the present disclosure. For example, FIG. 2 illustrates an example bitstream 200, such as bitstream 119, in accordance with the present disclosure. As shown in FIG. 2, the bit stream 200 can include a header 202 and a data portion 204. Header 202 can include one or more indicators 206. For example, indicator 206 can include an index 208 whose value is equivalent to an index value (described in the above table) and a particular scale factor as described herein, for encoded video material such as one or more blocks of LCUs. In various implementations, header 202 and/or data portion 204 can include a data package 210, such as a Supplemental Enhancement Information (SEI) package, which can include an indicator that specifies the selected scale factor.

As mentioned above, in some examples, the encoder can be multiple The bit number limit scale factor and the corresponding coding mode encode the bit stream such that the decoder can use the information provided to implement the scale factor as described (eg, based on the corresponding coding mode is active) and the number of bits limit (For example, the scale factor is multiplied by the size of the original video material). Referring to FIG. 1, encoder 102 may encode bitstream 119 with the plurality of bit number limit scaling factors and corresponding encoding modes. For example, the bitstream 200 as shown in FIG. 2 can include a data package 210 that can include the plurality of bit number limit scaling factors and corresponding encoding modes. For example, the bit number limit scale factor and the corresponding coding mode may be provided in the bitstream 200 as part of a Supplemental Enhancement Information (SEI) packet or a Supplemental Enhancement Information (SEI) packet.

FIG. 3 illustrates a flow diagram of an example program 300 in accordance with various implementations of the present disclosure. Program 300 may include one or more operations, functions, or actions, as illustrated in one or more of blocks 302, 304, 306, 308, 310, and 312 of FIG. By way of a non-limiting example, program 300 can form at least a portion of a video decoding process performed by decoder system 120 of FIG.

Moreover, the program 300 will also be described herein with respect to the video encoding system 400 of FIG. 4, wherein the system 400 includes a processor 402, a video codec module 406, and a memory 408. The processor 402 can exemplify the codec module 406 to provide a video encoding program in accordance with the present disclosure. In an example of system 400, memory 408 can store video content, such as LCUs, including encoded video material. The codec module 406 can implement an HEVC codec provided by any combination of software, firmware, and/or hardware. Memory 408 can be any type of memory, such as volatile memory (eg, static random access memory (SRAM), dynamic random access) Memory (DRAM), etc.) or non-volatile memory (eg, flash memory, etc.), and the like. In a non-limiting example, memory 408 can be implemented by a cache memory.

Returning to the discussion of FIG. 3, routine 300 can begin at block 302, "Receiving a bitstream that includes an indicator," a bitstream can be received, wherein the bitstream includes an indicator of a specified scale factor (eg, the indicator is a bit Part of the meta stream). For example, the indicator can be a bit stream flag or a portion of a Supplemental Enhancement Information (SEI) package or the like. The indicator can then be accessed at block 304, "Access Indicators" to determine the value of the indicator. For example, decoder 120 may receive bitstream 119 at block 302, where bitstream 119 includes an indicator such as indicator 208 of FIG. For example, the indicator may have different values corresponding to the index values of the mapping table as described above such that each value of the indicator (and corresponding coding mode) may correspond to a different one of the complex number limits. This indicator can be associated with a block of video data such as, for example, a maximum coding unit (LCU).

The process 300 may continue at block 306, "Select a bit number limit from a complex number of bits based on the determined index value," wherein the number of bit limits may be selected from a plurality of bit limits based on the determined index value. As previously described, the decoder 120 may proceed to block 306 to determine a scale factor based on the determined index value (block 308, "Determining the scale factor based on the determined index value"), and then using the original data size of the video data block of equation (4) Multiplying by the scale factor (block 310, "The size of the original data of the video data block is multiplied by the scale factor"). For example, referring to a non-limiting example of Table 2, if the index value specified by the index value is 1, the corresponding scale factor will 4/3, if the index value specified by the index value is 2, the corresponding scale factor will be 3/2, and if the index value specified by the index value is 5, the corresponding scale factor will be 5/3, etc. . In general, the scale factor can have any suitable value, such as, for example, a number equal to or greater than one and less or equal to two, 3/2, 4/3, or 5/3, or the like.

The program 300 may then end at block 312, "Determine Buffer Size Based on Byte Number Limits," where the decoder determines the buffer size (e.g., the selected number of bit limits) based on the number of bit numbers. For example, as for a given raw video material size, a larger scale factor would result in determining a higher number of bit limits at block 306 and a corresponding larger buffer size at block 312, while a smaller scale factor would result in a corresponding The smaller buffer size is at block 312.

FIG. 8 is a flow diagram illustrating an example video encoding process 800 configured in accordance with at least some implementations of the present disclosure. In the implementations described, program 800 can include one or more operations, functions, or actions, as illustrated by one or more blocks 802 and/or 804. In a non-limiting example, the routine 800 will be described herein with reference to the example video encoding system 100. Program 800 can generally be coded such that the concepts and/or operations described can be applied to encoding and/or decoding in the same or similar manner.

Program 800 can be utilized as a computer implemented method of performing video encoding. The process 800 can begin at operation 802, "determine a bit number limit scale factor from a plurality of bit number limit scale factors according to an active video coding mode," wherein the maximum number of bits is determined based on an active video coding mode from a plurality of bit number limit scale factors. The number of bits is the limit scale factor. For example, coding The 102 or decoder 120 may determine a bit number limit scale factor. In some examples, determining the number of bit limit scale factors can include accessing a table having a plurality of bit number limit scale factors and corresponding coding modes (eg, Table 1 or Table 2). In some examples, a 5/3 bit number limit scale factor can be used for all coding modes. Moreover, in some examples, it may be determined that the active coding mode is invalid through the table, and in such an example, the bit number limit scale factor may be set to a preset number of bits limit scale factor. In general, the number of bits limit scale factor can be any suitable value such as, for example, a number equal to or greater than one and less than or equal to two: 3/2, 4/3, or 5/3, or the like.

Processing may continue from operation 802 to operation 804, "determining the number of bit numbers associated with the video data block based on the number of bit limit scale factors", wherein the bit number limit of the video data block may be at least partially based on the number of bit limit ratios The factor is determined. For example, encoder 102 or decoder 120 may determine the number of bits limit. In some examples, determining a bit number limit for or associated with a video data block may include multiplying the bit number limit scaling factor and the original video material size of the video data block (eg, as shown in equation (4)) . As described above, in some examples, the bit number limit scale factor for all coding modes may be 5/3, and in such an example, the maximum number of bits for the maximum coding unit of the video material may be limited by the maximum coding. The number of unit raw data is multiplied by the 5/3 number of bits and the maximum scale factor is determined.

In general, encoder 102 and/or decoder 120 may encode the video material based on the determined number of bit numbers. At encoder 102, encoding The video material can be encoded in bit stream 119. For example, at decoder 120, the encoded video material can be used to produce an output image that can be presented to the user via the display device.

In general, program 800 can be repeated any number of times for any number of blocks of video material. Again, the process 800 can be initiated when the encoding mode changes or periodically or similarly. The number of synthesized bits can be used to encode the bit stream or produce an output image, as described. Some additional and/or alternative details associated with the program 800 may illustrate one or more examples of the implementations described herein, and in particular, with respect to FIG. 9 below.

9 is an illustration of an example video encoding system program 900 and a video encoding program 900 in operation configured in accordance with at least some implementations of the present disclosure. In the implementations described, the program 900 can include one or more operations, functions, or actions, such as by one or more operations 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911. , 912, 913, and/or 914 are shown. By way of a non-limiting example, the routine 900 will be described herein with reference to the example video encoding system 100 of FIG.

In the illustrated implementation, video encoding system 100 can include logic module 920, the like, and/or combinations thereof. For example, logic module 920 can include an encoder 930 (eg, which can be equivalent to encoder 102 or encoder 702), which can include a bit number limit module 950 and a decoder 940, which can be a bit number limit mode Group 960. Although video encoding system 100, as shown in FIG. 9, may include a particular set of blocks or operations associated with a particular module, these blocks or operations may be associated with modules other than the particular modules shown herein. Although the program 900, as shown, is for editing Code and decoding, the concepts and/or operations described may be applied separately to encoding and/or decoding, and more generally to video encoding.

The process 900 can begin at block 901, "Determine a Bit Number Scale Factor," wherein the bit number limit scale factor can be determined from the complex bit number limit scale factor based, at least in part, on the active video coding mode. For example, the encoder 930 can determine the number of bit limit scale factors by the bit number limit module 950. In some examples, determining the number of bit limit scale factors can include accessing a table having a plurality of bit number limit scale factors and corresponding coding modes (eg, Table 1 or Table 2). In other examples, a 5/3 bit number limit scale factor can be used for all coding modes.

The process 900 can continue from block 901 to block 902, "Determine the number of bits associated with the video data block," wherein the number of bits associated with or associated with the video data block can be based, at least in part, on the number of bits. Be determined. For example, encoder 930 can determine the number of bit limits via bit number limit module 950. In some examples, determining a bit number limit for or associated with a video data block may include multiplying the bit number limit scaling factor and the original video material size of the video data block (eg, as shown in equation (4)) . As described above, in some examples, the bit number limit scale factor for all coding modes may be 5/3, and in such an example, the maximum number of bits for the maximum coding unit of the video material may be limited by the maximum coding. The number of unit raw data and the 5/3 number of bits limit scale factor (for example, as shown in equation (3)) are multiplied to determine.

The process 900 can continue from block 902 to block 903, "encoding the video material according to the number of bit numbers", wherein the video material is available Coding is done in part based on the number of bits. For example, encoder 930 can encode the video material based on the number of bit numbers.

The process 900 can continue from block 903 to block 904, "Encode a bitstream based on the encoded data," wherein the bitstream can be encoded at least in part based on the encoded video material. For example, encoder 930 can encode a stream of bits included in the material encoded in block 903. For example, the encoded bit stream can be equivalent to a bit stream 119 or a bit stream 719.

The process 900 can continue from block 904 to block 905, "Encode the bitstream with the bit number limit scale factor and the corresponding encoding mode", wherein the plurality of bit number limit scale factors and the corresponding complex code mode can be encoded in bits In the stream. In some examples, the bit number limit scale factor and the corresponding complex code mode coded bit stream may be provided as part of a Supplemental Enhancement Information (SEI) packet of the bit stream. As noted above, in some examples, the decoder can implement the techniques described using information received through the bitstream. In other examples, the decoder may use the preload or predetermined scale factor at the decoder and the corresponding coding mode to implement the techniques described. In still other examples, a constant scale factor of 5/3 can be used. In such an example, block 905 can be skipped.

The process 900 can continue at block 906, "Transfer Bit Stream," where the encoded bitstream can be transferred. As shown, the encoded bitstream can be transferred to decoder 940. As noted, encoder 930 can be associated with and/or provided by a content provider system, and decoder 940 can be associated with a client system. Thus, in various implementations, encoder 930 and decoder 940 can be implemented substantially independently of one another. In different instances, bits The meta stream can be transferred via a network device via a memory device or the like. As will be appreciated, in some implementations, bitstreams can be transferred to multiple devices in series or in parallel.

The process 900 can continue from block 906 or begin at block 907, "Receive Bitstream," in which the bitstream associated with the video material can be received at decoder 940.

The process 900 can continue from block 907 to block 908, "Access Bit Stream to Determine Bit Number Limit Scale Factor and Corresponding Encoding Mode", wherein the received bit stream can be accessed to determine the number of complex bits. The scale factor and the corresponding complex coding mode. As noted above, in some examples, the bit number limit scale factor and the corresponding complex code mode can be implemented by decoder 940 without being encoded in the bit stream. In such an example, block 908 can be skipped.

The process 900 can continue at block 909, "Determine the bit number scale factor," wherein the bit number limit scale factor can be determined from the complex bit number limit scale factor based at least in part on the active video coding mode. For example, decoder 940 can determine the number of bits limit scale factor by bit number limit module 960. In some examples, determining the number of bit limit scale factors can include accessing a table having a plurality of bit number limit scale factors and corresponding coding modes (eg, Table 1 or Table 2). In other examples, a 5/3 bit number limit scale factor can be used for all coding modes.

The process 900 can continue from block 909 to block 910, "Determine the number of bits associated with the video data block," wherein the number of bits associated with or associated with the video data block can be based, at least in part, on the number of bits. The factor is determined. For example, decoder 940 can determine the number of bit limits via bit number limit module 950. In some examples, determining a bit number limit for or associated with a video data block may include multiplying the bit number limit scaling factor and the original video material size of the video data block (eg, as shown in equation (4)) . As described above, in some examples, the bit number limit scale factor for all coding modes may be 5/3, and in such an example, the maximum number of bits for the maximum coding unit of the video material may be limited by the maximum coding. The number of unit raw data and the 5/3 number of bits limit scale factor (for example, as shown in equation (3)) are multiplied to determine.

The process 900 can continue from block 910 to block 911, "determine the buffer size based on the number of bit numbers", wherein the buffer size can be determined based on the determined number of bit limits. For example, decoder 940 can determine an allocation or dedicated memory buffer size equal to or similar to the determined number of bit limits. In some examples, the size of the buffer may not be changed according to the number of bits, and in such an example, block 911 may be skipped.

The process 900 can continue at block 912, "Encoding the video material based on the number of bit numbers", wherein the video material can be encoded based, at least in part, on the number of bit numbers. For example, video decoder 940 can decode the video material based on the number of bits.

The process 900 can continue from block 912 to block 913, "Determine buffer size based on the number of bit numbers", wherein the generation of the output image can be encoded, at least in part, based on the video material. For example, decoder 940 can generate an output image based on the video material decoded at block 912.

The process 900 can continue from block 912 to block 913, "Transfer the output image for rendering", where the output image can be transferred for presentation. For example, the output image can be presented to the user via the display device. Although the implementation of the example program 300, 700, 800, or 900 may include the performance of all of the blocks shown in the order, the disclosure is not limited in this respect, and, in different examples, the program 300, 700, 800 or 900 The implementation may include only the illustrated blocks of a subset and/or in a different order.

In addition, any one or more of the blocks described herein can be responsive to instructions provided by one or more computer program products. Such a program product may include a signal bearing medium that provides instructions that, when executed by, for example, a processor, may provide the functionality described herein. A computer program product can be provided in any form of one or more computer readable media. Thus, for example, a processor including one or more processor cores can perform one or more blocks of the example program in response to the code and/or instructions or instructions communicated to the processor by one or more machine readable media. set. In general, machine readable media may convey software in the form of code and/or instructions or sets of instructions that may cause any device and/or system described herein to perform at least a portion of system 100 and/or video codec mode. Group 406, or other systems or modules described herein.

As used in any implementation described herein, the term "module" means any combination of software logic, firmware logic, and/or hardware logic configured to provide the functionality described herein. Software may be embodied as packaged software, code and/or instruction sets or instructions, and "hardware", as used in any implementation described herein, and may include, for example, hardwired circuits, alone or in any combination. Programmable circuit, state machine circuit, and/or bank The firmware of the instructions executed by the programmable circuit. Modules may be collectively or individually embodied as circuits that may form part of a larger system, such as integrated circuits (ICs), system chips (SoCs), and the like.

FIG. 10 is an illustration of an example video encoding system 1000 configured in accordance with at least some implementations of the present disclosure. In the illustrated implementation, video encoding system 1000 can include imaging device 1001, video encoder 1002, antenna 1003, video decoder 1004, one or more processors 1006, one or more memory banks 1008, a display 1010, and/or logic module 1040. The logic module 1040 can include a bit number limit module 960, the like, and/or a combination thereof. In some examples, video encoder 1002 can implement one or more logic modules including a bit number limit module, such as, for example, a bit number limit module 940.

As shown, antenna 1003, video decoder 1004, processor 1006, memory storage 1008, and/or display 1010 can communicate with each other and/or with portions of logic module 1040. Likewise, imaging device 1001 and video encoder 1002 can communicate with each other and/or with portions of logic module 1040. Thus, video decoder 1004 may include all or a portion of logic module 1040, and video encoder 1002 may include similar logic modules. Although video encoding system 1000, as shown in FIG. 10, may include a particular set of blocks or actions associated with a particular module, such blocks or actions may be associated with modules other than the particular modules illustrated herein.

In some examples, video encoding system 1000 can include antenna 1003, video decoder 1004, the like, and/or combinations thereof. antenna 1003 can be configured to receive a stream of encoded bitstreams of video material. Video decoder 1004 is communicatively coupled to antenna 1003 and is configurable to decode the encoded bitstream. Video decoder 1004 can be configured to determine a bit number limit scale factor from a plurality of bit number limit scale factors based at least in part on the active video coding mode, and to determine for or with video data based at least in part on the number of bit limit scale factors The number of bits associated with the block, or by multiplying the maximum number of coding unit original data by the 5/3 number of bits limit scaling factor to determine the number of bits associated with or associated with the largest coding unit of the video material, And encoding the video material based, at least in part, on the number of bit numbers, as described herein.

In other examples, video encoding system 1000 can include display device 1010, one or more processors 1006, one or more memory banks 1008, bit number limit modules 960, the like, and/or combinations thereof. Display device 1010 can be configured to present video material, such as an output image. The processor 1006 is communicatively coupled to the display device 1010. Memory storage 1008 is communicatively coupled to one or more processors 1006. Video decoder 1004 (or video encoder 1002 in other examples) may be communicatively coupled to one or more processors 1006 and configurable to determine from a plurality of bit number limit scale factors based at least in part on the active video coding mode a bit number limit scaling factor that determines a bit number limit for use in or associated with a video data block based at least in part on the bit number limit scaling factor, and encodes the video material based at least in part on the bit number limit, or by The maximum number of coding unit original data is multiplied by a 5/3 number of bits limit scale factor to determine the number of bits used or associated with the largest coding unit of the video material and to The video material is encoded in part based on the number of bit numbers such that the presentation of the image data through the display device 1010 can be based, at least in part, on the encoded video material.

In various embodiments, the bit number limit module 960 (and the bit number limit module implemented by the encoder 1002, if present) can be implemented hardware, and the software can implement other logic modules. For example, in some embodiments, the bit number limit module 960 can be implemented by application specific integrated circuit (ASIC) logic, while other logic modules can be provided by software instructions such as those executed by the logic of the processor 1006. However, the disclosure is not limited in this respect, and the bit number limit module 960 (and the bit number limit module implemented by the encoder 1002, if present) and/or other logic modules may be hardware, Any combination of firmware and/or software is implemented. In addition, the memory storage 1008 can be any type of memory, such as volatile memory (eg, static random access memory (SRAM), dynamic random access memory (DRAM), etc.) or non-volatile. Memory (for example, flash memory, etc.), and so on. In a non-limiting example, memory storage 1008 can be implemented by cache memory. FIG. 5 shows an example system 500 in accordance with the present disclosure. In various implementations, system 500 can be a media system, although system 500 is not limited in this respect. For example, the system 500 can be incorporated into a personal computer (PC), a laptop, an ultra-laptop, a tablet, a touchpad, a portable computer, a handheld computer, a palmtop computer, a personal digital assistant (PDA). ), mobile phones, combined cellular phones/PDAs, televisions, smart devices (eg smart phones, smart tablets or smart TVs), mobile internet devices (MID), messaging device, data communication device, camera (eg, camera, super zoom camera, single eye digital (DSLR) camera), and the like.

In various implementations, system 500 includes a platform 502 coupled to display 520. Platform 502 can receive content from a content device, such as content service device 530 or content delivery device 540 or other similar content source. A navigation controller 550 that includes one or more navigation functions can be used to interact with, for example, platform 502 and/or display 520. Each of these elements is described in more detail below.

In various implementations, platform 502 can include any combination of chipset 505, processor 510, memory 512, antenna 513, storage 514, graphics subsystem 515, application 516, and/or radio 518. Wafer set 505 can provide interworking between processor 510, memory 512, storage 514, graphics subsystem 515, application 516, and/or radio 518. For example, wafer set 505 can include a storage adapter (not depicted) that can provide interworking with storage 514.

Processor 510 can be implemented as a Complex Instruction Set Computer (CISC) or Reduced Instruction Set Computer (RISC) processor, an x86 instruction set compatible processor, multiple cores, or any other microprocessor or central processing unit (CPU). In various implementations, processor 510 can be a dual core processor, a dual core mobile processor, or the like.

Memory 512 can be implemented as a volatile memory device such as, but not limited to, random access memory (RAM), dynamic random access memory (DRAM), or static RAM (SRAM).

The storage 514 can be implemented as a non-volatile storage device such as, but not limited to, a disk drive, a CD player, a tape drive, an internal storage device, an attached storage device, a flash memory, a battery backup SDRAM (synchronous DRAM) ), and/or network accessible storage devices. In various implementations, for example, the storage 514 can increase the storage performance enhancement protection of valuable digital media when multiple hard disks are included.

Graphics subsystem 515 can perform processing of images, such as static or video displayed. Graphics subsystem 515 can be, for example, a graphics processing unit (GPU) or a visual processing unit (VPU). An analog or digital interface can be used to communicatively couple graphics subsystem 515 and display 520. For example, the interface can be any of a high definition multimedia interface, display port, wireless HDMI, and/or wireless HD compatible technology. Graphics subsystem 515 can be incorporated into processor 510 or chipset 505. In some implementations, graphics subsystem 515 can be a stand-alone device communicatively coupled to chipset 505.

The graphics and/or video processing techniques described herein may be implemented in different hardware architectures. For example, graphics and/or video functions can be integrated within a chipset. Alternatively, a separate graphics and/or video processor can be used. As still another implementation, the graphics and/or video functions may be provided by a general purpose processor including a multi-core processor. In further embodiments, the functions can be implemented in a consumer electronic device.

Radio 518 may include one or more radios capable of transmitting and receiving signals using different suitable wireless communication technologies. This technique can involve communication across one or more wireless networks. Example wireless networks include, but are not limited to, wireless local area networks (WLANs), wireless personal area networks Roads (WPANs), wireless metropolitan area networks (WMANs), cellular networks, and satellite networks. In communication over such a network, the radio 518 can operate in accordance with one or more applicable standards of any version.

In various implementations, display 520 can include any television type monitor or display. For example, display 520 can include a computer display screen, a touch screen display, a video monitor, a television-like device, and/or a television. Display 520 can be digital and/or analog. In various implementations, display 520 can be a holographic display. Additionally, display 520 can be a transparent surface that can receive a visual projection. This projection conveys different forms of information, images and/or objects. For example, such a projection can be a visual overlay of a mobile augmented reality (MAR) application. Platform 502 can display user interface 522 on display 520 under the control of one or more software applications 516.

In various implementations, for example, the content services device 530 can be primarily hosted by any national, international, and/or independent service, and thus can be accessed to the platform 502 via the Internet. Content services device 530 can be coupled to platform 502 and/or to display 520. Platform 502 and/or content services device 530 can be coupled to network 560 for communicating (e.g., transmitting and/or receiving) media information to and from network 560. Content delivery device 540 can also be coupled to platform 502 and/or to display 520.

In various implementations, the content service device 530 can include a cable box, a personal computer, a network, a telephone, an internet enabled device or device capable of providing digital information and/or content, and can communicate over the network 560 or Directly unidirectional or two-way communication of content providers and platforms 502 and/or Any other similar device of content between displays 520. It will be appreciated that content can be communicated to and from any of the components and content providers in system 500 unidirectionally and/or bidirectionally via network 560. Examples of content may include any media information including, for example, video, music, medical and gaming information, and the like.

Content services device 530 can receive content, such as cable television programming including media information, digital information, and/or other content. Examples of content providers may include any cable or satellite television or radio or internet content provider. The examples provided are not intended to limit the implementation in accordance with the present disclosure in any way.

In various implementations, platform 502 can receive control signals from navigation controller 550 having one or more navigation functions. For example, the navigation function of controller 550 can be used to interact with user interface 522. In various embodiments, the navigation controller 550 can be a pointing device, which can be a computer hardware component (specifically, a human interface device) that allows a user to input spatial (eg, continuous and multi-dimensional) data to a computer. Many systems, such as graphical user interfaces (GUIs), televisions, and monitors, allow users to control and provide information to a computer or television using physical gestures.

The motion of the navigation function of controller 550 can be replicated on the display (e.g., display 520) by movement of indicators, cursors, focus rings, or other visual indicators displayed on the display. For example, under the control of the software application 516, navigation functions located on the navigation controller 550 can be mapped to, for example, virtual navigation functions displayed on the user interface 522. In different implementations, the controller 550 may not be a separate component, but may be The platform 502 and/or display 520 are incorporated. However, the disclosure is not limited to the elements or the context shown or described herein.

In various implementations, the driver (not shown) may include techniques by which the user can immediately turn the platform 502 on and off, for example, when enabled, as if the television was initially activated after the button was touched. Program logic may allow platform 502 to stream content to a media adapter or other content service device 530 or content delivery device 540 even when the platform is "off." In addition, chipset 505 can include hardware and/or software to support, for example, 5.1 surround sound and/or high definition 7.1 surround sound. The driver can include a graphics driver for the integrated graphics platform. In various embodiments, the graphics driver can include a Peripheral Component Interconnect (PCI) fast graphics card.

In various implementations, any one or more of the elements shown in system 500 can be integrated. For example, platform 502 and content services device 530 can be integrated, or platform 502 and content delivery device 540 can be integrated, or platform 502, content service device 530, and content delivery device 540 can be integrated. In various embodiments, platform 502 and display 520 can be an integrated unit. For example, display 520 and content service device 530 can be integrated, or display 520 and content delivery device 540 can be integrated. These examples are not intended to limit the disclosure.

In various embodiments, system 500 can be implemented as a wireless system, a wired system, or a combination of both. When implemented as a wireless system, system 500 can include elements and interfaces suitable for communicating over a wireless shared medium, such as one or more antennas, transmitters, receivers, transceivers, amplifiers, filters, control logic, and the like. Example of wireless shared media The sub-segment may include a portion of the wireless spectrum, such as the RF spectrum and the like. When implemented as a wired system, system 500 can include components and interfaces suitable for communicating over wired communication media, such as input/output (I/O) adapters, connecting I/O adapters, and corresponding wired communication media. Physical connectors, network interface cards (NICs), optical disk controllers, video controllers, audio controllers, and the like. Examples of wired communication media may include wires, cables, metal wires, printed circuit boards (PCBs), backplanes, switch structures, semiconductor materials, twisted pairs, coaxial wires, optical fibers, and the like.

Platform 502 can establish one or more logical or physical channels for communication of information. This information can include media information and control information. Media information may refer to any material that represents user content. Examples of content may include, for example, information from voice conversations, video conferencing, streaming video, email ("email") messages, voicemail messages, alphanumeric symbols, graphics, images, video, text, and the like. . The information from the voice conversation can be, for example, voice information, silence period, background noise, comfort noise, tones, and the like. Control information may refer to any material that represents a command, instruction, or control word that is meant to be an automated system. For example, control information can be used to route media information through the system or to instruct nodes that process media information in a predetermined manner. However, embodiments are not limited to the elements or context shown or described in FIG.

As described above, system 500 can be implemented with different physical styles or form factors. FIG. 6 illustrates an implementation of a small form factor device 600 in which system 600 can be implemented. In various embodiments, for example, device 600 can be implemented as a wireless computing enabled mobile computing device. Action meter The computing device can reference, for example, any device having a processing system and a mobile power source or supply, such as one or more batteries.

As mentioned above, examples of mobile computing devices may include personal computers (PCs), laptops, ultra-laptops, tablets, touchpads, portable computers, handheld computers, palmtop computers, personal digital devices. Assistant (PDA), mobile phone, combined cellular phone/PDA, TV, smart device (such as smart phone, smart tablet or smart TV), mobile internet device (MID), communication device, data communication device, Camera (eg, camera, super zoom camera, single eye digital (DSLR) camera, etc.).

Examples of mobile computing devices may also include computers that are configured to be worn by people, such as wrist-worn computers, finger computers, ring computers, eyeglass computers, belt buckle computers, arm-band computers, shoe computers, clothing computers, and other wearable computers. In various embodiments, for example, the mobile computing device can be implemented as a smart phone capable of executing a computer application, as well as voice communication and/or data communication. While some embodiments may be described by way of example to implement a mobile computing device as a smart phone, it will be appreciated that other embodiments may be implemented using other wireless mobile computing devices. The embodiments are not limited thereto.

As shown in FIG. 6, device 600 can include a housing 602, a display 604, an input/output (I/O) device 606, and an antenna 608. Device 600 can also include a navigation function 612. Display 604 can include any suitable display unit for displaying information suitable for the mobile computing device. I/O device 606 can include any suitable I/O device for entering information into an action meter Calculation device. Examples of I/O device 606 may include a text keypad, a numeric keypad, a touchpad, input keys, buttons, switches, rocker switches, microphones, speakers, voice recognition devices and software, and the like. Information can also be input to device 600 via a microphone (not shown). Such information can be digitized by a speech recognition device (not shown). The embodiments are not limited thereto.

Different embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware components can include processors, microprocessors, circuits, circuit components (eg, transistors, resistors, capacitors, inductors, etc.), integrated circuits, special application integrated circuits (ASICs), Program Logic Device (PLD), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), Logic Gate, Scratchpad, Semiconductor Device, Wafer, Microchip, Wafer Set, and more. Examples of software may include software components, programs, applications, computer programs, applications, system programs, machine programs, operating system software, intermediate software, firmware, software modules, routines, subroutines, functions, methods, programs. , software interface, application interface (API), instruction set, calculation code, computer code, code segment, computer code segment, word, value, symbol, or any combination thereof. Determining whether to use hardware components and/or software components to implement an embodiment may vary according to any number of factors, such as required computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, Memory resources, data bus speeds, and other design or performance constraints.

One or more aspects of at least one embodiment can be performed by representative instructions stored on a machine readable medium representing different logic within a processor, which causes the machine to construct logic when the machine reads The technique described in the text. This representation, referred to as "IP core", can be stored on tangible machine readable media and provided to different customers or manufacturing facilities to load manufacturing machines that actually produce logic or processors.

Although some of the features presented herein have been described with reference to various embodiments, this description is not to be construed in a limiting sense. Therefore, various modifications of the implementations described herein, as well as other implementations, are apparent to those skilled in the art and are considered to be within the spirit and scope of the disclosure.

The following examples are for further embodiments.

In an example, a computer implemented method for performing video encoding can include determining a bit number limit scale factor from a complex number of bits limit scale factor based at least in part on an active video coding mode. The bit number limit can be determined for the video data block based, at least in part, on the number of bit limit scale factors.

In another example, a computer implemented method for performing video encoding can further include encoding video material based at least in part on a bit number limit. The bitstream can be encoded, at least in part, based on the encoded video material. The complex bit number limit scale factor and the corresponding complex code mode can be encoded in the bit stream. The complex bit number limit scale factor and the corresponding complex code mode may be encoded as part of a Supplemental Enhancement Information (SEI) packet of the bit stream. This bit stream can be received. The bit stream can be accessed to determine the complex bit number limit scale factor and the corresponding complex code mode. The buffer size can be determined based on the determined number of bits. The output image can be generated, at least in part, based on encoding of the video material. Determining the number of bits to limit the scale factor may include accessing including complex bits A table of the number limit scale factor and the corresponding complex coding mode. Determining the number of bits limit scale factor may include determining that the active coding mode is not available through the table and the number of bit limit scale factors may be set to a preset number of bits limit scale factor. Determining the bit number limit of the video data block may include multiplying the bit number limit scale factor by the original video material size of the video data block. The scale factor may include a number equal to or greater than one and less than or equal to two: 3/2, 4/3, or 5/3. The complex coding mode may include a lower bit generation coding mode and a higher bit generation coding mode, the higher bit generation coding mode producing more bits than the lower bit generating coding mode to enable lower bits The number of bits of the element-generated coding mode association may be a scale factor that is less than the number of bits associated with the higher bit-generating coding mode. The video data block can be a maximum coding unit (LCU). The video data block may include High Efficiency Video Coding (HEVC) video material. The first coding mode may include all coding modes in the HEVC primary profile allowing for transform skipping and the corresponding first number of bits limit scaling factor may be 4/3. The second encoding mode may include all encoding mode disable transform skips in the HEVC main profile and the corresponding second bit number limit scale factor may be 3/2. The third coding mode may include all coding modes in the HEVC primary still image profile allowing the transform skip and the corresponding third bit number limit scale factor may be 4/3. The fourth encoding mode may include all encoding mode disable transform skips in the HEVC main still image profile and the corresponding fourth bit number limit scale factor may be 3/2. The fifth coding mode may include all coding modes in the HEVC primary 10 profile allowing the transform skip and the corresponding fifth bit number limit scale factor may be 5/3. The sixth encoding method may include HEVC main All encoding modes in the 10 profile are disabled. The transition skip and the corresponding sixth bit limit scale factor can be 5/3. Determining the number of bits limit may include determining a limit on the number of bits in the video decoder. The video decoder can be implemented at least partially in hardware. Determining the number of bits limit may include determining a limit on the number of bits in the video encoder. The video encoder can be implemented at least partially in the hardware.

In still another example, a computer implemented method for performing video encoding may include determining, by multiplying a maximum coding unit original data number and a 5/3 bit number limit scaling factor, a maximum coding unit associated with the video material. The number of bits is limited. The video material can be encoded, at least in part, based on the number of bits.

In another further example, a computer implemented method for performing video encoding can further include encoding a bitstream based at least in part on the encoded video material. The bit stream can be received. The buffer size can be determined based on the determined number of bits. The output image can be generated, at least in part, based on encoding of the video material. The video data block may include High Efficiency Video Coding (HEVC) video material. Determining the number of bits limit may include determining a limit on the number of bits in the video decoder. The video decoder can be implemented at least partially in hardware. Determining the number of bits limit may include determining a limit on the number of bits in the video encoder. The video encoder can be implemented at least partially in the hardware.

In another example, a system for video encoding on a computer can include a display device, one or more processors, one or more memory stores, a video encoder, the like, and/or combinations thereof. Display device Configure to present video material. One or more processors are communicably coupled to the display device. One or more memory stores are communicably coupled to one or more processors. A video encoder communicably coupled to the one or more processors and configured to determine a bit number limit scale factor from a plurality of bit number limit scale factors based at least in part on the active video coding mode, and at least in part based on the number of bits The limit scale factor determines the number of bits associated with the video data block. The presentation of the image data through the display device can be based, at least in part, on the encoded video material.

In a further example system, the video encoder is configurable to encode a bitstream based at least in part on the encoded video material, encoding a complex bit number limit scale factor and a corresponding complex coding mode in the bitstream, wherein the complex bit The element limit scale factor and the corresponding complex coding mode comprise a portion of a Supplemental Enhancement Information (SEI) packet of the bitstream, receive the bitstream, access the bitstream to determine the complex number of bits and the corresponding scale factor and the corresponding The complex coding mode determines the buffer size based on the determined number of bit limits and/or produces an output image based at least in part on the encoded video material. The video encoder can be configured to determine a bit number limit scaling factor by accessing a table including the complex bit number limit scaling factor and the corresponding complex encoding mode. The video encoder may be configured to determine the bit number limit scale factor by determining that the active coding mode is unavailable through the table and wherein the bit number limit scale factor is set to a preset number of bits limit scale factor. The video encoder is configurable to determine the number of bits associated with the video data block by multiplying the bit number limit scaling factor by the original video material size of the video data block. The scale factor may include a number equal to or greater than one and less than or equal to two: 3/2, 4/3 or 5/3. The complex coding mode may include a lower bit generation coding mode and a higher bit generation coding mode, the higher bit generation coding mode producing more bits than the lower bit generating coding mode to enable lower bits The number of bits of the element-generated coding mode association may be a scale factor that is less than the number of bits associated with the higher bit-generating coding mode. The video data block can be a maximum coding unit (LCU). The video data block may include High Efficiency Video Coding (HEVC) video material. The first coding mode may include all coding modes in the HEVC primary profile allowing for transform skipping and the corresponding first number of bits limit scaling factor may be 4/3. The second encoding mode may include all encoding mode disable transform skips in the HEVC main profile and the corresponding second bit number limit scale factor may be 3/2. The third coding mode may include all coding modes in the HEVC primary still image profile allowing the transform skip and the corresponding third bit number limit scale factor may be 4/3. The fourth encoding mode may include all encoding mode disable transform skips in the HEVC main still image profile and the corresponding fourth bit number limit scale factor may be 3/2. The fifth coding mode may include all coding modes in the HEVC primary 10 profile allowing the transform skip and the corresponding fifth bit number limit scale factor may be 5/3. The sixth encoding mode may include all encoding mode disable transform skips in the HEVC main 10 profile and the corresponding sixth bit number limit scale factor may be 5/3. The video encoder can include a video decoder. The video decoder can be implemented at least partially in the hardware. A video encoder may include a video encoder. The video encoder can be implemented at least partially in the hardware.

In still another example, for video encoding on a computer The system can include a display device, one or more processors, one or more memory stores, a video encoder, the like, and/or combinations thereof. The display device is configurable to present video material. One or more processors are communicably coupled to the display device. One or more memory stores are communicably coupled to one or more processors. The video encoder is communicably coupled to the one or more processors and configured to determine the maximum coding unit associated with the video material by multiplying the maximum number of coding unit original data by a 5/3 number of bits limit scaling factor The bit number limit, and the video material is encoded based, at least in part, on the number of bit numbers. The presentation of the image data through the display device can be based, at least in part, on the encoded video material.

In another further example system, the video encoder can be configured to, at least in part, encode the bitstream based on the encoded video material, receive the bitstream, determine a buffer size based on the determined number of bit limits, and/or An output image is generated based, at least in part, on the encoded video material. The video data block may include High Efficiency Video Coding (HEVC) video material. The video encoder can include a video decoder. The video decoder can be implemented at least partially in the hardware. A video encoder may include a video encoder. The video encoder can be implemented at least partially in the hardware.

In a further example, the at least one machine readable medium can include a plurality of instructions that are executed on the computing device in response to causing the computing device to perform the method according to any of the above examples.

In still further examples, a device can include a mechanism for performing the method according to any of the above examples.

The above examples may include specific combinations of features. however, Such examples are not limited in this respect, and in various implementations, the above examples may include performing only a subset of such features, performing such features in a different order, performing different combinations of such features, and/or Additional features in addition to these explicitly listed features are made. For example, all of the features described with respect to the example methods can be implemented with respect to example devices, example systems, and/or example objects, and vice versa.

100‧‧‧ system

101‧‧‧ Input image

102‧‧‧Encoder

104‧‧‧Code Unit Partitioning Module

106‧‧‧Transformation and Quantization Module

108‧‧‧Anti-quantization and inverse transformation module

110‧‧‧Internal forecasting module

112‧‧‧Deblocking filter module

114‧‧‧sample adjustable offset filter module

116‧‧‧Inter-frame prediction module

117‧‧‧ mode decision module

118‧‧‧Entropy coding module

119‧‧‧ bit flow

120‧‧‧Decoder

122‧‧‧ Entropy decoding module

124‧‧‧Anti-transformation module

126‧‧‧Internal forecasting module

127‧‧‧ grammar control module

128‧‧‧Deblocking filter module

130‧‧‧sample adjustable offset filter module

132‧‧‧Inter-frame prediction module

134‧‧‧ coding unit assembly module

135‧‧‧ output image

Claims (22)

An apparatus for decoding compressed video data, comprising: a video decoder for accessing a bit stream of compressed video data, the compressed video material comprising at least one coding unit of the encoded video material; and the video decoder Determining, according to an active coding mode of the coding unit corresponding to the encoded video material, a bit number limit scale factor corresponding to the coding unit of the encoded video material from a plurality of bit number limit scale factors; and the video decoder for Determining, according to the bit number limit scale factor, a bit number limit associated with the coding unit, wherein, to determine the bit number limit, the video decoder multiplies the original data size of the coding unit by the bit number limit Scale Factor. The device of claim 1, further comprising a memory, wherein the video decoder determines the size of the buffer in the memory based at least in part on the determined number of bit limits. The device of claim 1, wherein the video decoder determines the size of the original data by accessing at least one of the grammars of the bitstream. The device of claim 1, wherein when the active coding mode includes a first active coding mode allowed by a transform skip, the bit number limit scale factor includes a first value, and when the active coding mode includes a transform When the forbidden second active coding mode is skipped, the bit number limit scale factor includes a second value, and wherein the first value is less than the second value. For example, the device of claim 4, wherein the first initiative The difference between the coding mode and the second active coding mode is allowed or disabled for the transform skip. The device of claim 4, wherein the first value is 4/3 and the second value is 3/2. The device of claim 1, wherein when the active coding mode includes a first active coding mode having a first bit depth, the bit number limit scaling factor includes a first value, and when the active coding mode When the second active coding mode having the second bit depth is included, the bit number limit scale factor includes a second value, and wherein the first bit depth is less than the second bit depth and the first value is less than the The second value. The device of claim 7, wherein the first bit depth is 8 bits, the second bit depth is 10 bits, the first value is 4/3, and the second value is 5 /3. The device of claim 1, wherein the active coding mode is accessed via the bitstream. A system comprising the apparatus of any one of claims 1 to 9 further comprising: a display, wherein the video decoder decodes the at least one coding unit to generate decoded video material; and a processor for displaying The decoded video material is on the display. A system as claimed in claim 10, further comprising one or more radios for receiving the bit stream. A computer implementation method for decoding compressed video data, comprising: accessing a bit stream of compressed video data, the compressed video material including At least one coding unit of the code video material; and determining, according to an active coding mode of the coding unit corresponding to the coded video material, a bit number limit scale factor corresponding to the coding unit of the coded video data from a plurality of bit number limit scale factors And determining a bit number limit associated with the coding unit, wherein determining the bit number limit comprises multiplying the original data size of the coding unit by the bit number limit scale factor. The computer-implemented method of claim 12, further comprising determining a buffer size based at least in part on the determined number of bit limits. The computer-implemented method of claim 12, wherein determining the original data size comprises at least one of a grammar for accessing the bit stream. The computer-implemented method of claim 12, wherein when the active coding mode includes a first active coding mode allowed by a transform skip, the meta-digit limit scale factor includes a first value, and when the active coding mode When the second active coding mode including transform skip inhibition is included, the bit number limit scale factor includes a second value, and wherein the first value is less than the second value. The computer-implemented method of claim 15, wherein the difference between the first active coding mode and the second active coding mode is allowed or disabled for the transform skip. The computer implemented method of claim 15, wherein the first value is 4/3 and the second value is 3/2. The computer-implemented method of claim 12, wherein when the active coding mode includes a first active coding mode having a first bit depth, the bit number limit scaling factor includes a first value, and when the active When the encoding mode includes a second active encoding mode having a second bit depth, the bit number limit scaling factor includes a second value, and wherein the first bit depth is less than the second bit depth and the first value Less than the second value. The computer implementation method of claim 18, wherein the first bit depth is 8 bits, the second bit depth is 10 bits, the first value is 4/3, and the second value is It is 5/3. The computer-implemented method of claim 12, wherein the active coding mode is accessed via the bit stream. An apparatus for decoding a compressed video material, comprising a mechanism for performing the computer implemented method of any one of claims 12 to 14. A machine readable storage, comprising machine readable instructions, when executed, for performing the method of any one of claims 12-14.