Low-complexity intra prediction for video coding
Abstract
The present invention provides a unique intra prediction process which improves the efficiency of video coding. H.264/AVC uses reference pixels in a horizontal boundary located immediately above a target block to be predicted and reference pixels in a vertical boundary located immediately left of the target block. In the present invention, at least some of one of an array of horizontal boundary pixels and an array of vertical boundary pixels are retrieved. Then, the retrieved pixels are added to the other boundary pixels to extend the array thereof. Intra prediction is performed, based solely on the extended array of boundary pixels.
Term
4.8 yearsto projected expiry
Projected expiry 14 July 2031, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
1 claim: 1 independent, 0 dependent
- 1Claims Zastrzeżenia patentowe 1. Sposób kodowania wideo wykonywany przez procesor urządzenia do kodowania wideo, obejmuj ący:A video coding method performed by a video encoder processor, comprising: a step of acquiring at least some pixels from a vertical border pixel array, the vertical border pixels being pixels on the vertical border that lies directly to the left of the target block to be encoded and in the vertically adjacent blocks that have been previously encoded, restored and saved;etap pozyskiwania co najmniej niektórych pikseli z układu pikseli granicy pionowej, przy czym piksele granicy pionowej są pikselami na granicy pionowej, która leży bezpośrednio na lewo od bloku docelowego do zakodowania i w sąsiaduj ących pionowo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;etap dodawania pozyskanych pikseli do układu pikseli granicy poziomej, przy czym piksele granicy poziomej są pikselami na granicy poziomej, która leży bezpośrednio ponad blokiem docelowym do zakodowania i w sąsiaduj ących poziomo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane, aby rozszerzyć układ pikseli granicy poziomej;i etap przeprowadzania predykcji wewnątrzramkowej na podstawie rozszerzonego układu pikseli granicy poziomej, gdzie etap pozyskiwania co najmniej kilku pikseli z układu pikseli granicy pionowej obejmuje: step of adding the acquired pixels to the horizontal border pixel system, the horizontal border pixels being pixels on the horizontal border that lies directly above the target block to be encoded and in the horizontal horizontally blocks that have been previously coded, restored and saved to extend the horizontal border pixel layout ;and the step of performing intra-frame prediction based on the expanded horizontal pixel layout, where the acquisition of at least a few pixels from the vertical border pixel array includes: getting InvAngle from the search table, which represents the InvAngle values with respect to the angle * value representing the direction of the prediction;and identifying at least a few pixels from the vertical border pixels by using the vertical pixel identifier which is expressed by the function using [col * InvAngle], where col is the counter which is decreased by 1 from -1 to (size * angle * / rangelimit ), where size is the size of the target block, and rangelimit specifies the angle * range, and where the step of adding the acquired pixels to the horizontal border pixel system includes: adding a pixel identified by the vertical pixel identifier to the horizontal border pixels at the position determined by the vertical pixel identifier [col] . uzyskiwanie InvAngle z tablicy wyszukiwania, która przedstawia wartości InvAngle w odniesieniu do wartości angle* przedstawiaj ącej kierunek predykcji;i identyfikowanie co najmniej kilku pikseli spośród pikseli granicy pionowej, przez wykorzystanie identyfikatora piksela pionowego, który jest wyrażony przez funkcję wykorzystująca [col * InvAngle], gdzie col jest licznikiem, który jest zmniejszany o 1 od -1 do (size * angle*/rangelimit), gdzie size jest rozmiarem bloku docelowego, a rangelimit określa zakres angle*, i gdzie etap dodawania pozyskanych pikseli do układu pikseli granicy poziomej obejmuje: dodawanie piksela zidentyfikowanego przez identyfikator piksela pionowego do pikseli granicy poziomej w położeniu wyznaczonym przez identyfikator piksela pionowego [col]. 2. A video coding method according to claim 1, wherein rangelimit is a integer being power 2. 2. Sposób kodowania wideo według zastrzeżenia 1, w którym rangelimit jest liczbą całkowitą będącą potęgą 2. 3. A video coding method according to claim 1, wherein the rangelimit is 32, and (size * angle * / rangelimit) is implemented as size * angle * >> 5. 3. Sposób kodowania wideo według zastrzeżenia 1, w którym rangelimit wynosi 32, a (size * angle*/rangelimit) jest zrealizowane jako size * angle* >> 5. 4. Sposób kodowania wideo według jednego z zastrzeżeń 1 do 3, w którym wielkość InvAngel jest uzyskiwana z następującej tablicy wyszukiwania: A video coding method according to one of claims 1 to 3, in which the InvAngel size is obtained from the following search table: 5. A video decoding method performed by the processor of the video decoding apparatus, comprising: 5. Sposób dekodowania wideo wykonywany przez procesor urządzenia do dekodowania wideo, obejmujący: a step of acquiring at least a few pixels from a vertical border pixel array, the vertical border pixels being pixels on the vertical border that lies directly to the left of the target block to be encoded and in the vertically adjacent blocks that have been previously encoded, restored and saved;etap pozyskiwania co najmniej kilku pikseli z układu pikseli granicy pionowej, przy czym piksele granicy pionowej są pikselami na granicy pionowej która leży bezpośrednio na lewo od bloku docelowego do zakodowania i w sąsiadujących pionowo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;a step of adding the acquired pixels to the horizontal border pixel array to expand the horizontal border pixel array, the horizontal border pixels being pixels on the horizontal boundary that lies directly above the target block to be encoded and in the horizontally adjacent blocks that have been previously encoded, restored and saved;and the step of performing intra-frame prediction based on the expanded horizontal pixel layout, where the acquisition of at least a few pixels from the vertical border pixel array includes: etap dodawania pozyskanych pikseli do układu pikseli granicy poziomej, aby rozszerzyć układ pikseli granicy poziomej, przy czym piksele granicy poziomej są pikselami na granicy poziomej, która leży bezpośrednio ponad blokiem docelowym do zakodowania i w sąsiadujących poziomo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;i etap przeprowadzania predykcji wewnątrzramkowej na podstawie rozszerzonego układu pikseli granicy poziomej, gdzie etap pozyskiwania co najmniej kilku pikseli z układu pikseli granicy pionowej obejmuje: getting InvAngle from the search table, which represents InvAngle values with respect to the angle * value representing the direction of the prediction;and identifying at least a few pixels from the vertical border pixels by using the vertical pixel identifier which is expressed by the function using [col * InvAngle], where col is the counter which is decreased by 1 from -1 to (size * angle * / rangelimit ), where size is the size of the target block, and rangelimit specifies the angle * range, and where the step of adding the acquired pixels to the horizontal border pixel circuit comprises adding a pixel identified by the vertical pixel identifier to the horizontal border pixels at the location designated by the vertical pixel identifier [col]. uzyskiwanie InvAngle z tablicy wyszukiwania, która przedstawia wartości InvAngle w odniesieniu do wartości angle* przedstawiającej kierunek predykcji;i identyfikowanie co najmniej kilku pikseli spośród pikseli granicy pionowej, przez wykorzystanie identyfikatora piksela pionowego, który jest wyrażony przez funkcję wykorzystująca [col * InvAngle], gdzie col jest licznikiem, który jest zmniejszany o 1 od -1 do (size * angle*/rangelimit), gdzie size jest rozmiarem bloku docelowego, a rangelimit określa zakres angle*, i gdzie etap dodawania pozyskanych pikseli do układu pikseli granicy poziomej obejmuje dodawanie piksela zidentyfikowanego przez identyfikator piksela pionowego do pikseli granicy poziomej w położeniu wyznaczonym przez identyfikator piksela pionowego [col]. 6. Sposób dekodowania wideo według zastrzeżenia 5, w którym rangelimit jest liczbą całkowitą będącą potęgą 2. The video decoding method according to claim 5, wherein the rangelimit is a integer being a power of 2. 7. Sposób dekodowania wideo według zastrzeżenia 5, w którym rangelimit wynosi 32, a (size * angle*/rangelimit) jest zrealizowane jako size * angle* >> 5. 7. Video decoding method according to claim 5, wherein the rangelimit is 32, and (size * angle * / rangelimit) is implemented as size * angle * >> 5. 8. A video decoding method according to one of claims 5 to 7, wherein the size of InvAngel is obtained from the following search table: 8. Sposób dekodowania wideo według jednego z zastrzeżeń 5 do 7, w którym wielkość InvAngel jest uzyskiwana z następuj ącej tablicy wyszukiwania: 9. A video coding device containing: 9. Urządzenie do kodowania wideo zawieraj ące: means for acquiring at least a few pixels from the vertical border pixel array, the vertical border pixels being pixels on the vertical border that lie directly to the left of the target block to be encoded and in the vertically adjacent blocks that have been previously encoded, restored and saved;środki do pozyskiwania co najmniej kilku pikseli z układu pikseli granicy pionowej, przy czym piksele granicy pionowej są pikselami na granicy pionowej które leżą bezpośrednio na lewo od bloku docelowego do zakodowania i w sąsiaduj ących pionowo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;means for adding acquired pixels to the horizontal border pixel array to extend the horizontal border pixel array, the horizontal border pixels being pixels on the horizontal boundary that lies directly above the target block to be encoded and in the horizontally adjacent blocks that have been previously encoded, restored and saved;and means for performing intra-frame prediction based on the expanded horizontal pixel array, where these acquisition means obtain InvAngel from the search table, which represents the InvAngle values with respect to the angle * value representing the prediction direction;and identify at least a few pixels from the vertical border pixels by using the vertical pixel identifier that is expressed by the use function [col * InvAngle], środki do dodawania pozyskanych pikseli do układu pikseli granicy poziomej w celu rozszerzenia układu pikseli granicy poziomej, przy czym piksele granicy poziomej są pikselami na granicy poziomej, która leży bezpośrednio ponad blokiem docelowym do zakodowania i w sąsiaduj ących poziomo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;i środki do przeprowadzania predykcji wewnątrzramkowej na podstawie rozszerzonego układu pikseli granicy poziomej, gdzie te środki do pozyskiwania uzyskuj ą InvAngel z tablicy wyszukiwania, która przedstawia wartości InvAngle w odniesieniu do wartości angle* przedstawiaj ącej kierunek predykcji;i identyfikuj ą co najmniej kilka pikseli spośród pikseli granicy pionowej, przez wykorzystanie identyfikatora piksela pionowego, który jest wyrażony przez funkcj ę wykorzystuj ąca [col * InvAngle], gdzie col jest licznikiem, który jest zmniejszany o 1 od -1 do (size * angle*/rangelimit), gdzie size jest rozmiarem bloku docelowego, a rangelimit określa zakres angle*, i gdzie te środki do dodawania dodaj ą piksel zidentyfikowany przez identyfikator piksela pionowego do pikseli granicy poziomej w położeniu wyznaczonym przez identyfikator [col] piksela pionowego. 10. A video decoding apparatus comprising: 10. Urządzenie do dekodowania wideo zawieraj ące: means for acquiring at least a few pixels from a vertical border pixel array, the vertical border pixels being pixels on the vertical border that lies directly to the left of the target block to be encoded and in the vertically adjacent blocks that have been previously encoded, restored and saved;środki do pozyskiwania co najmniej kilku pikseli z układu pikseli granicy pionowej, przy czym piksele granicy pionowej są pikselami na granicy pionowej która leży bezpośrednio na lewo od bloku docelowego do zakodowania i w sąsiaduj ących pionowo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;means for adding acquired pixels to the horizontal border pixel array to extend the horizontal border pixel array, the horizontal border pixels being pixels on the horizontal boundary that lies directly above the target block to be encoded and in the horizontally adjacent blocks that have been previously encoded, restored and saved;and means for performing intra-frame prediction based on the expanded horizontal pixel array, where acquisition means obtain InvAngel from a search table that represents InvAngle values with respect to the angle * value representing the prediction direction;and identify at least a few pixels from the vertical border pixels by using the vertical pixel identifier, which is expressed by the function using [col * InvAngle], środki do dodawania pozyskanych pikseli do układu pikseli granicy poziomej w celu rozszerzenia układu pikseli granicy poziomej, przy czym piksele granicy poziomej są pikselami na granicy poziomej, która leży bezpośrednio ponad blokiem docelowym do zakodowania i w sąsiaduj ących poziomo blokach, które zostały wcześniej zakodowane, odtworzone i zapisane;i środki do przeprowadzania predykcji wewnątrzramkowej na podstawie rozszerzonego układu pikseli granicy poziomej, gdzie środki do pozyskiwania uzyskuj ą InvAngel z tablicy wyszukiwania, która przedstawia wartości InvAngle w odniesieniu do wartości angle* przedstawiaj ącej kierunek predykcji;i identyfikuj ą co najmniej kilka pikseli spośród pikseli granicy pionowej, przez wykorzystanie identyfikatora piksela pionowego, który jest wyrażony przez funkcj ę wykorzystuj ącą [col * InvAngle], gdzie col jest licznikiem, który jest zmniejszany o 1 od -1 do (size * angle*/rangelimit), gdzie size jest rozmiarem bloku docelowego, a rangelimit określa zakres angle*, i gdzie te środki do dodawania dodaj ą piksel zidentyfikowany przez identyfikator piksela pionowego do pikseli granicy poziomej w położeniu wyznaczonym przez identyfikator [col] piksela pionowego. Authorized: NTT DOCOMO, INC. Uprawniony: NTT DOCOMO, INC. Pełnomocnik: Proxy: dr inż. Robert Teofilak Patent attorney dr inż. Robert Teofilak Rzecznik patentowy Fig. 1 angle> 0? Fig. 1 angle>0? int col + 1 + <0? int+col+1<0? col <size? col<size? row <size? row<size? 902 pos <-angle χ row + 1 int <-pos »log2_size frac <-pos &. (Size-1) 902 pos<—angle χ row+1 int<—pos»log2_size frac<-pos&.(size-1) 903 903 904 comO 904 comO 913 913 Nie No 910 910 915 v ^ refH [mt + col + 1] 915 v^refH[mt+col+1 ] 918 918 907 p rea [ro w] [co /] afisize-frac) χ refH [int + col + 1] b <-frac χ refH [int + col + 2] pos2 <- (sizrx (col + 1)) l \ angie \ a ^ (size-frac) x refH [int + col + 1 vWa + b) »log2 size mt2 ^ pos2» log2_size b <-frac x refH [int + col + 2] pred [row '] [co / ] <- and / frac2 <-pos2 & (s / ze-1) v <- (a + b) »log2_size pred [row] [col] ^ v 907 p rea [ro w] [co/] afisize-frac) χ refH[int+col+1] b<-frac χ refH[int+col+2] pos2<-(sizrx(col+1 ))l\angie\ a^(size-frac) x refH[int+col+1 vWa+b)»log2 size mt2^pos2»log2_size b<—frac x refH[int+col+2] pred[row'][co/]<-i/ frac2<-pos2&(s/ze-1) v<—(a+b)»log2_size pred[row][col]^v 916 a <- (s / ze-frac2 xreM / nf2 + row + 1 col <- every 1 + 1 J 916 a<-(s/ze-frac2 xreM/nf2+row+1 col<— co 1+1 J 908 frac2 χ refv [/ nf2 + ro in + 2] col <-col + 1 908 frac2 χ refv[/nf2+ro w+2] col<—col+1 912 v <- (a + b) »log2_size every m every 1 + 1 912 v<-(a+b)»log2_size co m co 1+1 917 preciirow] [co / l <-iz 917 preciirow][co/l<-iz 909 909 919 919 920 row ^ row + 1 j Fi9-9 ^ Begin ^ θθθ get reference samples and optionally filter them <ro 0 < 920 row^row+1 j Fi9-9 ^Początek^ θθθ pobierz próbki odniesienia i opcjonalnie je przefiltruj ro tv<—0 Początek int < lastlnt? The beginning of int <lastlnt? row <size? row<size? End Koniec Fig. 14 Fig. 14 1401 ro / m and so on n <1 1401 ro i/imO ast nt<—1 902 pos ^ angle x (row + 1) int <^ pos »log2_size frac ^ pos & isize-)) 902 pos^angle x (row+1) int<^pos»log2_size frac^pos&isize-)) 1402 1402 1403 □ 1403 □ refH [int + i] ^ refv [row] refH[int+i]^refv[row] 900 pobierz próbki odniesienia i opcjonalnie je przefiltruj 900 take reference samples and optionally filter them 1405 row- ^ row + 1 lastlnt <-int 1405 row-^row+1 lastlnt<—int 1404 1404 Generate a lima that has been predicted Wygeneruj limę, która została poddana predykcji
157 paragraphs, as filed
Technical Field The present invention relates to video coding, and in particular to intra-frame prediction, in which a sample block is predicted using previously coded and reproduced pixels from the same video frame.
2. General information [0002] Digital video requires a large amount of data to represent each frame of a digital video sequence (e.g. a series of frames) in an uncompressed manner. In most applications, it is not feasible to send uncompressed digital video over a computer network due to bandwidth constraints. In addition, uncompressed digital video requires large storage space. Digital video is usually coded in some way to reduce storage space requirements and reduce bandwidth requirements.
[0003] One of the techniques for encoding digital video is inter-frame prediction or inter prediction. Interframe prediction uses temporary redundancy among different frames. Temporarily adjacent video frames usually contain pixel blocks that are substantially the same. During the encoding process, the motion vector determines the traffic dependencies between the block of pixels in one frame and a block of similar pixels in another frame. Accordingly, the system is not required to encode a block of pixels twice, but rather encodes a pixel block once and provides a traffic vector for another block of pixels.
[0004] Another technique for encoding digital video is intra-frame prediction. Intra-frame prediction encodes a frame or part of it with no reference to pixels in other frames. Intra-frame prediction uses spatial redundancy among the pixel blocks within the frame. Because the spatially adjacent pixel blocks generally have similar attributes, the efficiency of the coding process is increased by referring to the spatial mutual correlation between adjacent blocks. This correlation can be used by prediction of the target block based on the prediction modes used in adjacent blocks.
Summary of the Invention [0005] The present invention provides, in a first aspect, a video coding method performed by a video encoder processor as defined in claim 1, in a second aspect a video decoding method performed by a video decoding device processor as defined in claim 5, in a third aspect of a video encoding apparatus as defined in claim 9 and a fourth aspect of a video decoding apparatus as defined in claim 10. In an embodiment, a unique prediction process can be provided that will increase the efficiency of video coding. H.264 / AVC uses reference pixels on the horizontal border placed directly above the target block, ktto be predicted and reference pixels on the vertical border placed directly to the left of the target block. In the present invention, at least some of the horizontal or vertical pixel array system is acquired. Then, the acquired pixels are added to other border pixels to enlarge the system, intra-frame prediction is made, solely on the basis of this enlarged system. In an embodiment of the present invention, at least some of the vertical border pixels are acquired and added to the pixels of the horizontal boundary for enlarging the array arrangement.
[0006] The present invention eliminates the decision-making process of selecting either a horizontal boundary or a vertical boundary from which reference pixels are acquired. The present invention also eliminates the process of repeating the calculation of the position of a vertical boundary crossing the direction of prediction, where typically the process of repeating the calculation involves a dividing operation. The elimination of these processes allows the intra-frame prediction process to be carried out in Single-Instruction Multiple Data (SIMD) architectures, thus improving the computational efficiency of video coding.
[0007] In an embodiment of the present invention, at least some of the pixels from the vertical border are acquired using a vertical pixel identifier expressed by:
size X col angle where size means the size of the target block to be predicted, angle means the direction of prediction, and col is the counter that is reduced by 1 from -1 to angle. The acquired pixels are added to the horizontal pixels in the location identified by the [col] identifier of the horizontal pixel.
[0008] In another embodiment, when acquiring at least some pixels of the vertical boundary, InvAngle is calculated from
N * size angle <sub>.</sub> where N is an integer being the power of 2. Then, at least some of the pixels from the vertical border are acquired using the vertical pixel identifier, which is expressed as [col * InvAngle >> log2N]. The acquired pixels are added to the horizontal pixels at the location specified by the [col] identifier of the horizontal pixel.
[0009] In another embodiment, InvAngle is obtained from a look-up table that lists InvAngle values with respect to the angle value.
[0010] In another embodiment, a pixel is identified from among the vertical border pixels using a vertical pixel [row], where the row is a counter increments of 1 from 0 to size. The acquired pixel is added to the pixels of the horizontal boundary in the position identified by the identifier [int + 1] of the horizontal pixel, where int is an integer representing the position of the pixel crossing the prediction direction.
[0011] Embodiments of the present invention also provide an encoding device and decoding apparatus that employs an intra-frame prediction operation in which at least some of either a horizontal dot pixel array or a vertical border pixel array are acquired. Then, the acquired pixels are added to other border pixels to enlarge the pixel layout. Intra-frame prediction is carried out only on the basis of an extended set of border pixels.
BRIEF DESCRIPTION OF THE DRAWING FIGURES [0012]
FIG. 1 is a block diagram showing an exemplary hardware architecture on which the present invention may be implemented.
FIG. 2 is a block diagram showing a video encoding device in general to which the present invention may be applied.
FIG. 3 is a block diagram showing a video decoding device in general to which the present invention may be applied.
FIG. 4 is a block diagram showing functional modules of an encoding device according to an embodiment of the present invention.
FIG. 5 is a flowchart showing the intra-frame prediction process performed by an intra-frame prediction module in accordance with an embodiment according to the present invention.
FIG. 6 is a block diagram showing function modules of a decoding apparatus according to an embodiment of the present invention.
FIG. 7 is a diagram showing the prediction directions illustrating the 4x4 prediction modes supported by H.264 / AVC.
FIG. 8 is a diagram showing the prediction directions proposed in document No. JCT-VC A119.
FIG. 9 is a flowchart showing the process proposed in JCT-VC A119 for generating a block that was predicted according to one of the prediction directions shown in FIG. 7.
FIG. 10 is a flowchart showing a low complexity intra-frame prediction process performed according to an embodiment of the present invention.
FIG. 11A is a schematic view showing a prediction block and pixel layouts of the horizontal and vertical boundaries.
FIG. 11B is a schematic view showing a horizontal border pixel arrangement plus vertical pixel pixels.
FIG. 12 is a flowchart showing the process of enlarging a horizontal border pixel arrangement performed according to an embodiment of the present invention.
FIG. 13 is a flowchart of another embodiment of magnifying a horizontal border pixel arrangement.
FIG. 14 is a flowchart showing a low complexity intra-frame prediction process performed in accordance with another embodiment of the present invention.
DETAILED DESCRIPTION OF THE DRAWING AND CURRENT FIGURES FOR USE [0013] FIG. 1 shows an exemplary hardware architecture of a computer 100, wherein the present invention may be implemented. It should be noted that the hardware architecture shown in FIG. 1 may be common to both the video encoding apparatus and the video decoding apparatus that employ embodiments of the present invention. The computer 100 includes a processor 101, memory 102, storage device 105, and one or more input and / or output devices (I / O) 106 (or peripherals) that are connected so as to be able to communicate via the local interface 107. Local the interface 105 may be, e.g., but not limited to one or more buses or other wired or wireless connections, which are known in this field of technology. The processor 101 is a hardware device for running software, in particular that stored in memory 102. The processor 101 may be any specialized or commercially available processor, a main computing unit (CPU), or an auxiliary computing unit among a plurality of processors associated with the computer 100, a microprocessor based on semiconductor technology (in the form of a microchip or a set of system structures), or generally any device for running software instructions.
[0015] The memory 102 consists of a computer readable medium that can include any memory or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements. (for example, ROM, hard disk, tape, CDROM, and the like). Furthermore, the memory 102 can use electronic, magnetic, optical and other types of storage media. The computer-readable medium may be any means capable of storing, connecting, broadcasting or transmitting a program for use by, or in combination with, an instruction execution system, subassembly or device. It should be noted that the memory 102 may have a distributed architecture in which the various components are located at a distance from each other,
[0016] The software 103 in memory 102 may include one or more separate programs, each of which includes an ordered set of executable instructions to perform the logic functions of the computer 100, as described below. In the example of FIG. 1, the software 103 in the memory 102 determines the functionality of the video encoding or video decoding of the computer 100 according to the present invention. Furthermore, although it is not required, it is possible for the memory 102 to include an operating system (O / S) 104. The operating system 104 primarily controls the execution of computer programs and provides queuing, input control, data and file management, memory management and communications control and related services.
[0017] The storage device 105 of the computer 100 may be one of many types of storage devices, including stationary storage devices or portable storage devices. For example, the storage device 105 may be a magnetic tape, disk, flash memory, volatile memory, or other storage device. Furthermore, the storage device 105 may be a secure digital memory card, or any other type of removable storage device 105.
The I / O devices 106 may include input devices, e.g., but not limited to, a touch screen, a keyboard, a mouse, a scanner, a microphone, or other input device. Furthermore, the I / O devices 106 may also include output devices, e.g., but not limited to, a display or other output devices. The I / O devices 106 may further include devices that connect via both inputs and outputs, e.g., but not limited to, a modulator / demodulator (modem: for accessing another device, system or network), a radio frequency transceiver (RF), wireless or other, telephone interface, bridge, router, or other device acting as both input and output.
[0019] As is well known to those skilled in the art, video compression is obtained by removing repetitive information in a video sequence. There are many different video coding standards, examples of which include MPEG-1, MPEG-2, MPEG-4, H.261, H.263, and H.264 / AVC. It should be noted that the present invention is not limited to applications for a specific video coding standard. However, the following description of the present invention is provided using the example of the standard H.264 / AVC. H.264 / AVC is the latest video encoding standard and achieves significant performance improvements over existing coding standards, such as MPEG-1, MPEG-2, H.261 and H.263.
[0020] In H.264 / AVC, each frame or video image can be separated into several slices. These clippings are then divided into blocks (sizes) 16 * 16 pixels called macroblocks, which can then be further divided into blocks 8 * 16, 16 * 8, 8 * 8, 4 * 8, 8 * 4, up to 4 * 4 pixels. H.264 / AVC supports five types of slices. In sections I, all macroblocks are coded using intra-frame prediction. In macroblocks, macroblocks can be coded using intra-frame or inter-frame prediction. P-slices allow the use of only one motion compensated prediction (MCP) signal per macroblock. In B sections macroblocks can be coded using intra-frame or inter-frame prediction. Two MCP signals can be used for one prediction.
The SI slice is an exact match for the SP slice for random access, or for restoring to the state before the error occurred, when only intra-frame prediction is used.
[0021] In FIG. 2 shows a general form of a video coding apparatus in which the present invention may be applied. The blocks shown in the figure show the functional modules implemented by the processor 101 that executes the program 103 in memory 102. The image of the video frame 200 is input into the video encoding device 201. The video coding device considers the image 200 in the units of the macroblocks 200A. Each macroblock includes several pixels of image 200. On each macroblock a transformation is carried out into transformation coefficients, followed by quantization to conversion factor levels. In addition, intra-frame or inter-frame prediction is used to avoid coding steps directly on the image data, but on their differences to the pixel values that have been predicted,
[0022] For each slice, the coding device 201 generates several syntax elements that form a coded version of the macroblocks of the respective slice. All other data components in syntax elements that are associated with the coding of transform coefficients, such as transform coefficient levels or a materiality map indicating the omitted transform coefficient levels, are called the syntax elements of the remaining data. In addition to these syntax elements of the remaining data, the syntax elements generated by the video encoding device 201 include control information syntax elements including control information about how to encode each macroblock and how to decode it accordingly. In other words, the syntax elements can be divided into two categories. The first category of control information syntax elements includes elements that relate, for example, to a type of macroblock, a sub-macroblock type, and information about prediction modes of both spatial and temporal type, as well as control information based on a macroblock or segment. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data. and information on the prediction modes of both spatial and temporal type, as well as control information based on a slice or based on a macroblock. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data. and information on the prediction modes of both spatial and temporal type, as well as control information based on a slice or based on a macroblock. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data.
[0023] The coding apparatus 201 comprises an entropy encoder that encodes the syntax elements and generates arithmetic codewords for each slice. When generating arithmetic codewords for a slice, the entropy coder uses statistical relationships between the values of the data elements of the syntax in the bitstream of the video signal. Video encoding device 201 outputs the encoded video signal for the image slice 200 to the video decoding device 301 shown in FIG. 3.
[0024] In FIG. 3 is a pictorial view of a video decoding apparatus in which the present invention may be applied. The blocks shown in the figure show similar functional modules implemented by a processor 101 executing program 103 in memory 102. Video decoding device 301 receives the encoded signal and first decodes the entropy signal back to the syntax elements. The video decoding device 301 uses the syntax elements to reproduce the macroblock after the macroblock and then a clipping section of the image 300A patterns of the pixels image in the image 300.
[0025] In FIG. 4 shows the functional modules of the video encoding device 201.
These functional modules are implemented by a processor 101 executing program 103 in memory 102. The input video image is a frame or field of an ordinary (uncompressed) video image determined by sampling points representing primary color components such as chrominance ("chroma") and luminance ("luma"). ") (Other components are possible, for example hue, saturation and value). The input video image is divided into macroblocks 400, each of which represents a rectangular image area consisting of 16 * 16 pixels of the luma component for the image color. The input image is also divided into macroblocks, each of which represents 8 * 8 pixels of each of the two chroma components for the image color. In the general operation of the coding equipment, input macroblocks can be temporally or spatially predicted using intra-frame or inter-frame prediction. However, it was accepted for the purpose of discussing that macroblocks 400 are all type I macroblocks and are subject to only intra prediction.
[0026] Intra-frame prediction is made in intra-frame prediction module 401, the operation of which will be discussed in detail below. The intra-frame prediction module 401 generates a prediction block 402 from the horizontal and vertical border pixels of adjacent blocks that have been previously encoded, restored, and stored in frame memory 403. The residue 404 from the prediction block 402, which is the difference between the target block 400 and the prediction block 402, is transformed, scaled, and quantized by the transformation / quantization module 405, using methods and techniques known to those skilled in the video coding field.
[0027] Video encoding device 201 includes decoding functionality for performing intra-frame prediction on target blocks. This decoding functionality includes a reverse transformation / quantization module 409 that performs inverse quantization and inverse transformation of the quantized transformation coefficients 406 to obtain a decoded prediction residue 410 that is added to the prediction block 402. The sum of the decoded prediction residue 410 and the prediction block 402 is a reconstructed block 411 that is stored in the frame memory 403 and will be read and used by the intra-frame prediction module 401 to create the prediction block 402 to decode the succeeding target block 400.
[0028] In FIG. 5 is a flowchart of processes performed by intra-frame prediction module 401. According to the H.264 / AVC standard, intra-frame prediction uses the prediction of each pixel of the target block 400 in multiple prediction modes, using interpolation of the border pixels ("reference pixel") of adjacent blocks previously encoded and reproduced. These prediction modes are distinguished by positive integers 0, 1, 2 ... each of which is associated with another instruction or algorithm for predicting specific pixels in the target block 400. Intra-frame prediction module 401 performs intra-frame prediction with appropriate prediction modes and creates different prediction blocks. With the full search algorithm ("FS"), each of the prediction blocks formed is compared to the target block 400 to find the optimal prediction algorithm that minimizes the prediction residue 404, or creates the smallest prediction 404 prediction among the prediction modes. The recognition of the optimal prediction mode is compressed and sent to the device 301 for decoding together with other elements of the control information syntax.
[0029] Each prediction mode can be described by a general prediction direction as described in words (e.g., upward, upright, diagonal downwards to the left).
The direction of the prediction can be described graphically by an angular direction, which is expressed by an arrow diagram, such as shown in FIG. 7. In this type of diagram, each arrow can be considered as representing the direction of the prediction or the prediction mode. The angle corresponding to the prediction mode has a general relationship with the direction from the position of the weighted average reference pixels used to predict the target pixel to the position of the target pixel. It should be noted that the prediction modes include a DC prediction mode that is not associated with any predictive direction and therefore can not be described graphically in the diagram as opposed to other prediction modes. In the DC prediction mode, the prediction block 402 is created in such a way,
[0030] Returning to FIG 5, the prediction mode is started in Step 501. Next, in Step 502, it is determined whether the prediction mode indicates DC prediction. If this is the case, proceed to Step 503 where the DC prediction block 402 is created with the average value of the reference pixels in Step 503. If the prediction mode indicates otherwise, the prediction block 402 is created according to the instruction or algorithm associated with the prediction mode in the Step. 504, which process will be discussed in detail below. After Step 503 or Step 504, proceed to Step 505, where it is determined whether prediction blocks are created for all prediction modes. If the intra-frame prediction works for all prediction modes, go to Step 506. Otherwise, the prediction mode is increased in Step 507,
[0031] In FIG. 6 shows functional modules of the device 301 for video decoding. These functional modules are implemented by a processor 101 executing program 103 in memory 102. The encoded video signal from the video encoding device 201 is first received by the entropy decoder 600 and entropy decoded back to the transformed transformation coefficients 601. The quantized transformation coefficients 601 are inversely quantized and converted by the inverse quantization / transformation module 602 to create the prediction residue 603. The intra-frame prediction module 604 is notified of the prediction mode selected by the coding device 201. According to the selected prediction mode, the intra-frame prediction module 604 performs an intra-frame prediction process similar to that performed in Steps 502, 503 and 504 in FIG. 5 to create a prediction block 605, using pixel boundaries of adjacent blocks previously reproduced and stored in frame memory 606. A prediction block 605 is added to the prediction residue 603 to reproduce the block 607 of the decoded video signal. The restored block 607 is stored in the frame memory 606 to be used in the prediction of the subsequent block.
[0032] In the following, a detailed description of the process from Step 504 performed by the intra-frame prediction modules 401 and 604 to create the prediction block at one of the prediction modes except for the DC prediction mode will be presented. H.264 / AVC supports Intra 4 4 intra prediction, Intra 8 8 prediction and Intra 16 prediction. 16. Intra 4 4 prediction is commonly used where there are many important details in the image. Intra 4 4 prediction makes a separate prediction of sixteen luma 4 * 4 blocks within a macroblock. Intra 4 4 is predicted with nine prediction modes, including one DC prediction mode. The spatial directions of prediction with Intra_4 * 4 prediction are performed as shown in FIG. 7. Intra_8 * 8 is predicted with nine prediction modes, including one DC prediction mode. Intra_16 * 16 is predicted with four prediction modes, including one DC prediction mode. [0033] Recent studies show that an increase in the number of predictive directions, or an increase in the number of prediction modes, generally improves the efficiency of video compression. See, for example, document No. JCT-VC A119 ("Angular Intra Prediction") and JCT-VC A124 ("Arbitrary Direction Intra") transmitted to the Joint Collaborative Team on Video Coding (JCT-VC). The increase in the number of prediction directions leads to an increase in the number of angular divisions of the available prediction directions, and thus to an increase in the number of candidates for the prediction block. The increased number of candidates for the prediction block simply increases the chances of getting a prediction block, which is almost the same as the target block, which is to be encoded. In FIG. 8 is a diagram showing the prediction directions proposed in document No. JCT-VC A119. In FIG. 8, the reference pixels consist of seventeen (17) horizontal pixels and seventeen (17) vertical pixels, where the upper-left pixel is common for both the horizontal and vertical boundaries. Therefore, 33 different prediction directions are available to create prediction pixels in block 8 * 8. JCT-VC A124 offers arbitrarily targeted intra-frame prediction, in which the number of prediction directions is adjusted according to the size of the block to be predicted. reference pixels consist of seventeen (17) horizontal pixels and seventeen (17) vertical pixels, where the upper-left pixel is common for both the horizontal and vertical boundaries. Therefore, 33 different prediction directions are available to create prediction pixels in block 8 * 8. JCT-VC A124 offers arbitrarily targeted intra-frame prediction, in which the number of prediction directions is adjusted according to the size of the block to be predicted. reference pixels consist of seventeen (17) horizontal pixels and seventeen (17) vertical pixels, where the upper-left pixel is common for both the horizontal and vertical boundaries. Therefore, 33 different prediction directions are available to create prediction pixels in block 8 * 8. JCT-VC A124 offers arbitrarily targeted intra-frame prediction, in which the number of prediction directions is adjusted according to the size of the block to be predicted.
[0034] In FIG. 9 is a flowchart showing the process proposed in JCT-VC A119 to form a block along one of the prediction directions shown in FIG. 8. In the following description of this process, some algorithms are simplified to facilitate clarification. Furthermore, the described process is limited to intra-frame prediction along a direction that is substantially vertical. Intra-frame prediction along a direction that is essentially horizontal can be implemented symmetrically with the process of FIG. 9, as shown in the software provided by JCT-VC A119. Although FIG. 8 shows the block 8 * 8 to be predicted, the process shown in FIG. 9 can be extended to various amounts of pixels in a variety of configurations. For example, the block to be predicted may contain a 4 * 4 pixel layout. The prediction block may also include an 8 * 8 pixel layout, a 16 * 16 pixel layout, or larger pixel layouts. Other pixel configurations, including both square and rectangular systems, can also create a prediction block.
[0035] In Step 900 of FIG. 9, reference pixels on the horizontal and vertical borders that lie, respectively, directly above and to the left of the target block, are read from adjacent blocks that have been previously encoded, restored and stored in the frame memory such as the memory 403 shown in FIG. 4. Pixels from the horizontal border are stored in the memory space called "refH". Pixels from the vertical border are saved in the memory space called "refV". Returning to FIG. 8, the reference pixels are recognized by their coordinates in the coordinate system starting from the upper-left position in block 8 * 8. Thus, the horizontal border pixels have the coordinates expressed by p [x, y] where x = 0, 1 ... 16 ay = 0. The vertical pixel has coordinates expressed by p [x, y] where x = 0, y = 0 , -1, -2 ...- 16. [0036] Accepted, that the horizontal border pixels stored in the memory refH area are recognized by the logical address (x) where x = 0, 1 ... 16, and the horizontal border pixels stored in the refV area of the memory are analogously recognized by the logical address (y) where y = 0 , -1, -2 ...- 16, where each pixel is written at the address having the number in the coordinate from which it is read. Thus, as the horizontal and vertical pixels are graphically depicted in FIG. 8, the refH and refV areas of the memory can be considered as expanding linearly and perpendicular to each other, and each have a length of 2 * size + 1, where "size" is a parameter representing the size of the target block. It has been assumed that size has a value equal to a integer being 2, such as 4, 8, 16 ... Low-pass filter as described in chapter 8.3.2.2.1 in H.
[0037] In Step 901, the counter referred to as "row" is set to zero ("0"). The row counter takes a value from 0 to size and indicates the position of the row of the prediction pixel in the prediction block. In Step 902, a parameter called "pos" is calculated as angle * (row + 1). angle is a parameter having a fractional number in a fixed-point record. For this reason, angle consists of a full part and a fractional part, and the fractional part has a fixed number of binary numbers. angle represents one of the prediction directions shown in FIG. 8. For example, "angle = -size" equates the prediction direction that passes through the coordinates [x = 0, y = 0] in FIG. 8. A positive angle identifies the prediction direction that only crosses the horizontal boundary, while an angle with a negative value identifies the prediction direction that intersects both horizontal and vertical boundaries. angle changes within the range defined by the number of prediction directions that you intend to use. As proposed in JCT-VC A124, the number of prediction directions to be used can be determined according to the size of the block to be predicted. In the following description, it is assumed that the angle occupies a fractional number which varies within the range "-size" to "size". It should be noted that the range limits for angle can be determined by other values. [0038] Like angle, the pos parameter consists of a fractional part and a fractional part, and its fractional part consists of a fixed number of binary digits, which is equal to the logarithm of base 2 from the range boundary for angle, which can be expressed by log2_size accordingly to the above assumption, that the range limit for angle is set to size. pos identifies the intersection between the horizontal boundary and the prediction direction represented by angle. Returning to Step 902, the action "pos >> log2_size specifies an integer in pos, which is stored in the parameter" inf ", and the action" pos & (size - 1) "specifies the fractional number wpos, which is saved in the parameter" frac " . The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and". which is saved in the "frac" parameter. The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and". which is saved in the "frac" parameter. The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and".
[0039] In Step 903, it is determined whether the angle has a value equal to or greater than zero ("0"). If angle is equal to or greater than zero, go to Step 904. Otherwise, Step 913. Angle equal to or greater than zero suggests that you can rely only on reference pixels located on the horizontal boundary, or stored in refH, in order to to obtain prediction pixels in the prediction block. On the other hand, angle less than zero suggests that reference pixels located on the vertical boundary, or stored in refV, are necessary to obtain prediction pixels in the prediction block.
[0040] In step 904, it is determined if the frac is not zero. If frac is not zero, go to Step 905. If frac is zero, Step 906 occurs. A zero frac suggests that the prediction pixel in the prediction block can be copied directly from the reference pixel at the horizontal boundary. A non-zero frac suggests that the direction of the prediction crosses the horizontal boundary at a non-integer location, and it is necessary to interpolate more than one reference pixel to obtain prediction pixels in the prediction block.
[0041] In step 905, the counter called "col" is set to zero ("0"). The col counter is used to address the reference pixel in refH. In Step 907, the two reference pixels identified by "int + col + 1" and "int + col + 2" are obtained from refH. These two reference pixels are averaged to weighted or interpolated at frac to obtain a reference pixel v. In particular, the reference pixel in refH identified by "int + col + 1" is multiplied by "size-frac" and stored in parameter a. The reference pixel in refH identified by "int + col + 2" is multiplied by "frac" and stored in parameter b. Parameters a and b are then added and divided by size, i.e. (size - frac) + frac. Dividing by size can be replaced by moving to the right by log2_size. The received prediction pixel is stored in an array of memory regions called "pred" that represents the prediction block for the target block in a particular direction of prediction. Each memory area in pred is identified by the row and col parameters. Then, the col is increased by 1 in Step 908 and compared to the size in Step 909. Until col is smaller than size, Steps 907 and 908 are repeated. When col becomes equal to size, go to Step 920.
[0042] If it is determined that frac is zero in Step 904, the col counter is set to zero in Step 906. In Step 910, the prediction pixel is copied directly from refH (int + col + 1) and then stored in the appropriate area memory in pred. col is then incremented by 1 in Step 911 and compared to size in Step 912. Until col is smaller than size, Steps 910 and 912 are repeated. When col becomes equal to size, Step 920 follows.
[0043] Referring to Step 903, an angle of less than zero requires reference pixels with refV to obtain prediction pixels in the prediction block. The col counter is set to zero in Step 913. Next, in Step 914, it is determined whether "int + col + 1" is less than zero. "Int + col + 1" equal to or greater than zero suggests that you can still rely only on reference pixels written in refH to obtain prediction pixels in the prediction block, and Step 915 follows. The process performed in Step 915 is similar to that of Stage 907, and its description will not be repeated here. col is then incremented by 1 in Step 916 and compared to size in Step 917. As long as col is smaller than size, Steps 914, 915 and 916 are repeated. When col becomes equal to size, Step 920 follows.
[0044] If it is determined that "int + col + 1" is less than zero in Step 914, reference pixels stored in refV are needed to obtain prediction pixels in the prediction block. In Step 918, the intersection between the vertical limit and the prediction direction is determined first. In step 918, the position is represented by pos2. It should be noted that in Step 902, pos, i.e. the location of the intersection between the horizontal boundary and the prediction direction, is determined by "angle x (row + 1)". Given that angle expresses the ratio of horizontal and vertical differences, the angle is calculated<sup>-1</sup> x (col + 1) ", instead of" angle x (row + 1) ", to establish the intersection between the vertical boundary and the prediction direction. As assumed above, angle is in the range -size to size (-size <angle <size). Therefore, the ratio a between angle and size is determined by:
angle then angle '<sup>1</sup>, is determined by:
size (-1 <α <1).
<img file="PL2934008T3_D0001.tif" />
And if so, then pos2 is determined in Step 918 as the square size multiplied by col + 1 and then divided by the absolute value of the angle as follows:
_ size<sup>2</sup> χ (col + X)
POS2 = -: - \ angle [0045] Like pos, pos2 has a fractional number in a fixed-point record that consists of a full and a fractional part. The fractional part consists of the number of binary digits set by log2_size. The whole part pos2 is saved in parameter int2, and the fractional part pos2 is written in the parameter frac2. In Step 919, the two reference pixels identified by "int2 + row + 1" and "int2 + row + 2" are obtained from refV. These two reference points are averaged weighted or interpolated with frac2 to obtain a reference pixel v. In particular, a reference pixel with refV (int2 + row + 1) is multiplied by "size - frac2" and stored in parameter a. The reference pixel with refV (int2 + row + 2) is multiplied by "frac2" and stored in parameter b . These parameters a and b are then added and divided by size, or are shifted to the right by log2_size. The resulting prediction pixel is stored in the corresponding memory "pred" area. Steps 914, 918 and 919 and 916 are repeated until col becomes equal to size, in Step 917.
[0046] In Step 920, the row is incremented by 1. Then, in Step 921, the row is smaller than size. As long as the row is smaller than size, Steps 902 are repeated to obtain a reference pixel in the prediction block. This operation ends when the ditch becomes equal in size in Step 921.
[0047] As mentioned above, increasing the number of candidates in the prediction block contributes to the improvement of the coding efficiency, and at the same time increasing the number of candidates in the prediction block leads to an increase in computational load. For this reason, in order to increase the number of candidates of the prediction block to thereby improve the coding efficiency, the process of creating the prediction block candidates should be reviewed in order to achieve further efficiency of the process. Considering the process shown in FIG. 9, you can see two computing bottlenecks. The first computational bottleneck is the comparison and branching operations of Step 914, which are repeated in a loop. The second bottleneck is the splitting operation from Step 918, which is also performed in the loop.
[0048] Nowadays, for the efficient calculations, the Single-Instruction Multiple Data (SIMD) architecture is available. SIMD allows computers with multiple processor components to perform the same operation on multiple data simultaneously. However, typical SIMD architectures do not support performing splitting or joining / branching in a loop, and thus can not be used to implement the process shown in FIG. 9 due to the fact that it comprises looped steps 914 and 918, although the loops starting from Step 907 and 910 are sufficiently fault tolerant to be implemented by SIMD. It is therefore an object of the present invention to get rid of computational bottlenecks from the process shown in FIG. 9 and providing intra-frame prediction with low complexity, which will allow ordinary SIMD architectures to be used to perform parallel processing for all of the prediction directions shown in FIG. 8.
[0049] In FIG. 10 is a flowchart showing a low complexity intra-frame prediction process performed according to an embodiment of the present invention that is designed to replace the process of FIG. 9 in carrying out the process in Step 504 of FIG. 5. In FIG. 10, the same steps that were carried out in FIG. 9 have the same step numbers as those in FIG. 9, e.g. Stages 900, 901, 902, 904, 905, 906, 907, 908, 909, 910, 911, 912, 920 and 921. The description of these common steps will not be repeated here. Steps 1000 and 1001 are specific steps for the process of FIG. 10. As can be seen from the comparison of the process shown in FIG 9, the process of FIG 10 eliminates the comparison step from Step 903 and all of the branched steps to the left of Step 903 that is realized when the angle is less than zero,
[0050] In the added Steps 1000 and 1001, it is determined whether the angle is equal to or greater than -1. When angle is equal to or greater than -1, reference pixels located on the horizontal border are sufficient to generate a prediction pixel in the prediction block, and reference pixels on the vertical border are not needed. On the other hand, when angle is less than -1, reference pixels on the vertical boundary are needed to generate a prediction pixel in the prediction block. In Step 1001, reference pixels written in refH are expanded in the negative direction using at least some of the pixels stored in refV. In FIG. 11A and 11B are schematic views showing the refH expansion performed in Step 1001. In FIG. 11A, the reference pixels 1102 written in refH come from the horizontal border located above the target block 1101. The reference pixels 1103 stored in refV come from the vertical border located to the left of the target block 1101. As shown in FIG. 11B, after Step 1001 of FIG. 10, some of the reference pixels in refV are copied to refH, and refH has an enlarged portion 1104 widening in the negative direction.
[0051] In FIG. 12 is a flowchart showing details of the process being performed in Step 1001. In Step 1201, the col counter is set to -1. col is used to identify the address of the extended refH part. In Step 1202, the reference pixel in refV to be copied to the extended portion of the refH is identified by:
size x col <sup>angle</sup><sub>.</sub>
Dividing in the above equation is a division of integers, and the result of the equation is an integer. This equation works similar to the process from Step 918 of FIG. 9. In Step 918, the total value of pos2 is calculated by:
(size<sup>2</sup> X (col + 1)) <sup>2</sup>-<sup>Σ</sup>log2_ size.
angle
It should be noted that shifting to the right by log2_size is equivalent to dividing by size.
[0052] In Step 1203, col is reduced by 1. Then, it is determined in Step 1204 to determine whether col is equal to angle. If col is not equal to angle, then the action returns to Step 1202. Steps 1202 and 1203 are repeated until the col becomes equal to the angle. Thus, reference pixels are read from refV in descending order, or from top to bottom of the vertical boundary, and copied to refH also in descending order, or from right to left side of the horizontal boundary. In addition, not all of the reference pixels in refV are copied to refH. Only reference pixels in the range from the top to the intersection point of the prediction direction are copied from refV to refH.
[0053] Returning to FIG. 10, process steps beginning with Step 902 are copied from FIG. 9, and include those steps of generating the predicted branched pixels to the right from the comparison step of Step 903 in FIG. 9. However, it should be noted that these steps of FIG. 10 use the extended refH (sum of parts 1102 + 1104 in FIG. 11B), while the corresponding steps of FIG. 9 use the original refH (part 1102 in FIG. 10A). Because refH is expanded in the negative direction, no separate intra-frame prediction function specifically designed to use reference pixels stored in refV, such as branched to the left of Step 903 in FIG. 9.
[0054] In FIG. 13 is a flowchart of another embodiment of refH enlargement using reference pixels in refV. The process shown in FIG. 11 and 12 eliminates the bottleneck steps of Steps 914 and 918 shown in FIG. 9, and therefore the efficiency of the intra-frame prediction process is expected to increase. The process shown in FIG. 13 eliminates the division operations performed in Step 1202 of FIG. 12 from the reference pixel copy loops from refV to refH. By eliminating the splitting operation, it is expected that the process shown in FIG. 13 will further increase the efficiency of the intra-frame prediction process.
[0055] The process shown in FIG. 13 replaces Step 1202 of FIG. 12 Steps 1301 and 1302. Step 1302 is included in the reference pixel copy loop from refV to refH, while Step 1301 is outside this loop. Step 1301 introduces a new parameter called "InvAngle". InvAngle is determined by:
size
256 x angle <sub>.</sub>
Multiplying by 256 is equivalent to shifting to the left by 8 and ensures that each bit resulting from the "size / angle" operation is included in the calculation of the reference pixel identification in refV. In Step 1302, the address of the reference pixel in refV to be copied to the extended portion of the refH is determined by:
col χ InvAngle >> 8.
The result "col χ InvAngle" is shifted to the right by 8 to reverse the left-shift operation carried out in Step 1301. Note that the right shift operation from Step 1302 works for rounding down the result "col χ
InvAngle. " To round to the nearest whole number, a round off offset of 128 may be added to the result of "col * InvAngle" before performing the right shift operation. It should be noted that the number "256" is only an example, and Step 1301 may adapt a different number of offset, preferably an integer being power 2, until the number is large enough to keep all bits resulting from the "size / angle" operation. . For example, this number may be 64 in Step 1301, instead of 256, and the number of the right shift may be 6 in Step 1302, instead of 8. If 64 is used, the rounding shift should be 32.
[0056] The calculations performed in Step 1301 can be replaced by a search operation to further reduce the computational load. In other words, a search table has been prepared that stores the InvAngle values with respect to the angle value. Table 1 below is an exemplary search table in Step 1301.
Table 1
<td>angle</td><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td>
<td>InvAngle</td><td>512</td><td>410</td><td>341</td><td>293</td><td>256</td>
It is assumed that in the table above, the size size is 8, and the angle takes the integer values from 4 to 8. However, it should be noted that the size is not limited to 8, and can take a different value, such as 4 and 16. In addition, angle can be a fraction number in a fixed-point record as defined above.
[0057] When the reference pixel is copied from refV to refH in Step 1202 of FIG. 12 or in Step 1302 of FIG. 13, the reference pixel may pass through a low-pass filter to reduce possible aliasing in the prediction block. The strength of this low pass filter can vary according to the angle value. For example, when angle is -size, a low pass filter can be used, and when angle is -2, a strong lowpass filter can be used.
[0058] As explained above, not all reference pixels are copied from refV to refH. Since not all of the reference pixels in refV are copied, some information is lost when copying pixels. To mitigate this loss of information, the resolution of reference pixels in refH and refV can be doubled so that refH and refV contain not only pixels from previously coded and reconstructed blocks, but also one pixel between two adjacent reproduced pixels that is generated by interpolating two neighboring pixels. Two adjacent pixels can simply be averaged to generate an interpolation pixel. The interpolation process can be performed when the reference pixels in Step 900 of FIG. 9. When the pixel resolution is doubled in refH and refV, identifying the reference pixel addresses stored in refH and refV, such as performed in Steps 907, 910, 915 and 919 in FIG. 9, and Step 1001 in FIG. 10, must be rescaled. For example, "int + col + 1" carried out in Steps 907, 910 and 915 must be changed to "int + 2 * col + 2". "Int + col + 2" implemented in Steps 907, 910, 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively. 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively. 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively.
[0059] In another embodiment, the process of Step 1202 of FIG. 12 can be simply changed to "" refH \ col \ <refV [-col] "to further simplify the copying process. Despite the deterioration of prediction accuracy, this embodiment provides the least complexity for intra-frame prediction operations.
[0060] FIG. 11B shows the extended portion 1104 added to refH. The extended portion 1104 does not need to be created by reference pixels with refV. The extended portion 1104 may be formed of pixels from the area of the previously reproduced block that spatially corresponds to the position of the expanded portion 1104. In FIG. 11B, because refH (parts 1102 and 1104) is extended in the negative direction, it is in the range from -size to 2 * size. The extended refH range can be scaled to a range from 0 to 3 size - 1 by adding the appropriate offset when addressing the reference pixels in the extended refH. The same applies to rescaling the refV range.
[0061] In another embodiment, the range constraint angle can be chosen freely. In the above embodiments, it has been assumed that the angle assumes a value in the range of -size to size (-size <angle <size). In other words, in the above embodiments, the limits of the angle range are determined by the size of the target block. Note that the limits of the angle range can be specified regardless of the size of the target block, although it is still preferred that the range constraint be specified as an integer being power 2, so that log2_rangelimit is a positive integer and the equation "rangelimit = 1 << log2_rangelimit "remained true. Choosing a large number as a rangelimite,
[0062] If the range constraint angle is determined irrespective of the size of the target block, the size appearing in FIG. 9 and 10 must be replaced by rangelimit, and log2_size must be replaced by log2_rangelimit, except for Steps 909, 912, 917 and 921. The comparison "angle> -1" implemented in Step 1000 of FIG. 10 must also be replaced by "angle * sizel / rangelimit> -1" or "angle * size> -rangelimit". In addition, the size appearing in Steps 1202 and 1301 of FIG. 12 and 13 must be replaced by rangelimit, and the comparison "col = angle?" Performed in Step 1204 must be replaced by "col = angle * size / rangelimit?" If rangelimit is introduced as a limitation of the angle range, then Table 1 (presented above) can be changed as follows:
Table 2
<td>angle *</td><td>13</td><td>17</td><td>21</td><td>26</td><td>32</td>
<td>InvAngle</td><td>630</td><td>482</td><td>390</td><td>315</td><td>256</td>
In Table 2, rangelimit is set to 32. Angle * is equal to the approximate integer "rangelimit * tan (π / 4 * angle / 8)", where angle = 4, 5, 6, 7 and 8. InvAngle equals 256 * rangelimit / angle *. The values from Table 2 are all integers that were obtained by rounding up. Instead of being rounded up, these numbers can be rounded down. In Table 3 below, InvAngle equals 32 * rangelimit / angle *. Since "32" is used instead of "256", the accuracy of the prediction is necessarily smaller than that of Table 2.
Table 3
<td>angle *</td><td>13</td><td>17</td><td>21</td><td>26</td><td>32</td>
<td>InvAngle</td><td>78</td><td>60</td><td>48</td><td>39</td><td>32</td>
[0064] In FIG. 14 is a flow chart showing a different embodiment that further simplifies the process shown in FIG. The process shown in FIG. 10 copying reference pixels from refV to refH is performed before the process enters the main prediction loop, while the copying process shown in FIG. 14 is made within the main prediction loop. In addition, the process shown in FIG. 14 eliminates the InvAngle variable. Steps 900, 902 and 921 shown in FIG. 14 are derived from the respective steps of FIG. 10. [0065] In Step 1401, the lastInt counter is initiated with the value -1. lastInt shows the last pixel index that has been added to refH. In Step 902, pos is calculated by angle * (row + 1). As explained above, pos determines the location of the intersection point between the boundaries and the prediction direction shown as angle. In the context of FIG. 9, Step 902 results in a pos that identifies the position of the intersection between the horizontal boundary and the prediction direction determined by angle. In addition, in Step 902, the part being an integer in pos is stored in int and the fractional part in pos is saved in the parameter "frac". In Step 1402, it is determined whether the int is smaller than the lastInt. If int is smaller than lastInt, the reference pixel in refV identified by the row is copied to refH under the address identified by "int + 1". Step 1402 consists of Steps 904, 905, 906, 907, 908, 909, 910, 911 and 912 shown in FIG. 9 and 10, the description of which is not repeated here. In Step 1405, the int is copied to lastInt. The copying operation int to lastInt can be performed in Step 1403, instead of in Step 1405. which identifies the location of the intersection between the horizontal boundary and the prediction direction determined by angle. In addition, in Step 902, the part being an integer in pos is stored in int and the fractional part in pos is saved in the parameter "frac". In Step 1402, it is determined whether the int is smaller than the lastInt. If int is smaller than lastInt, the reference pixel in refV identified by the row is copied to refH under the address identified by "int + 1". Step 1402 consists of Steps 904, 905, 906, 907, 908, 909, 910, 911 and 912 shown in FIG. 9 and 10, the description of which is not repeated here. In Step 1405, the int is copied to lastInt. The copying operation int to lastInt can be performed in Step 1403, instead of in Step 1405. which identifies the location of the intersection between the horizontal boundary and the prediction direction determined by angle. In addition, in Step 902, the part being an integer in pos is stored in int and the fractional part in pos is saved in the parameter "frac". In Step 1402, it is determined whether the int is smaller than the lastInt. If int is smaller than lastInt, the reference pixel in refV identified by the row is copied to refH under the address identified by "int + 1". Step 1402 consists of Steps 904, 905, 906, 907, 908, 909, 910, 911 and 912 shown in FIG. 9 and 10, the description of which is not repeated here. In Step 1405, the int is copied to lastInt. The copying operation int to lastInt can be performed in Step 1403, instead of in Step 1405.
[0066] The copy operation in Step 1403 copies the same pixel that was copied in Steps 1202 and 1302, where rounding down is used in these steps. Step 1403 can be modified to make the roundings to the nearest integer by conditionally using "row + 1" instead of "row" in Step 1403 when the fractional frac position calculated in Step 902 is greater than the offset that is specified by rangelimit + (angle> > 1). It should be noted that the angle is -ve, and frac is + ve. The use of "row + 1" causes rounding up. To cause a conditional row increase of 1, the process performed in Step 1403 is changed to refH [int +1] refV [row - ((offset frac) >> 31)], assuming that in a 32-bit arithmetic, right shift o "offset frac" gives -1 when frac is greater than offset and gives 0 otherwise. Thus, the address identifier "" row - ((offset - frac) >> 31) "becomes" row + 1 "when frac is greater than offset and becomes" row "otherwise. When the offset is set to rangelimit, then "Offset - frac" will always be positive and therefore no rounding will occur [0067] The following is a listing of source code written in C ++ programming language that implements the process shown in FIG 14. The source code has been modified from the TComPrediction function: xPredIntraAng find in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at row - ((offset - frac) >> 31) "becomes" row + 1 "when frac is bigger than offset and becomes" row "otherwise. When the offset is set to rangelimit, then "offset - frac '" will always be positive and therefore no rounding will occur. [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at row - ((offset - frac) >> 31) "becomes" row + 1 "when frac is bigger than offset and becomes" row "otherwise. When the offset is set to rangelimit, then "offset - frac '" will always be positive and therefore no rounding will occur. [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at<a href="http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7">http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7</a>.
// Function for deriving the simplified angular intra predictions
Void TComPrediction:: xPredIntraAng (Int * pSrc, Int iSrcStride, Pel * &
rpDst,
Int iDstStride, UInt iWidth, UInt iHeight, UInt uiDirMode, Bool bAbove, Bool bLeft) {
Int k, l;
Int deltaInt, deltaFract, refMainIndex;
Int intraPredAngle = 0;
Int absAng = 0;
Int signAng = 0;
Int blkSize = iWidth;
Bool modeDC = false;
Bool modeVer = false;
Bool modeHor = false;
Pel * pDst = rpDst;
// map the mode index to main prediction direction and angle if (uiDirMode == 0) modeDC = true; else if (uiDirMode <18) modeVer = true; else modeHor = true;
intraPredAngle = modeVer? uiDirMode - 9: modeHor? uiDirMode - 25:
0;
absAng = abs (intrapredAngle); signAng = intraPredAngle <0? -1: 1;
// Set bitshifts and scale the angle parameter to size2 Int iAngTable [9] = {0, 2, 5, 9, 13, 17, 21, 26, 32}; absAng = iAngTable [absAng];
intraPredAngle = signAng * absAng;
// Do the DC prediction if (modeDC) {
Pel dcval = predIntraGetPredValDC (pSrc, iSrcStride, iWidth, iHeight, bAbove, bLeft); for (k = 0; k <blkSize; k ++) {for (1 = 0; 1 <blkSize; 1 ++) {pDst (k * iDstStride + 1] = dcval;
}}
} // Do angular predictions
<td>else</td><td colspan="2">{</td>
<td>Pel</td><td>tmp;</td><td></td>
<td>int</td><td>* pSrcTL = pSrc - iSrcStride</td><td>- 1;</td>
<td>int</td><td>iStepMain = (modeVer)? 1:</td><td>iSrcStride;</td>
<td>f</td><td>(intraPredAngle == 0) {</td><td></td>
for (k = 0; k <blkSize; k ++) {for (1 = 0; 1 <blkSize; l ++) {pDst [k * iDstStride + 1] = pSrcTL [(1 + 1) * iStepMain];
}}
} else {
Int iStepSide = (modeVer)? iSrcStride 1; int lastDeltaInt = -1;
Int iOffset = 32 + (intraPredAngle >> 1); // enables rounding to nearest side reference // Int iOffset = 32; // no rounding.
Pel ref [2 * MAX_CU_SIZE];
Pel * refMain = ref + ((intraPredAngle <0)? BlkSize: 0); if (intraPredAngle> 0) {for (k = 0; k <2 * blkSize; k ++) refMain [k] = pSrcTL [(k + 1) * iStepMain];
} else {for (k = -1; k <blkSize; k ++) // the rest are copied later in step
1403, as and when required refMain [k] = pSrcTL [(k + 1) * iStepMain];
} for (k = 0; k <blkSize; k ++) {
Int deltaPos = (k + 1) * intraPredAngle; deltaInt = deltaPos >> 5;
deltaFract = deltaPos & (32 - 1); if (deltaInt <lastDeltaInt) {// step 1402 lastDeltaInt = deltaInt;
refMain [deltaInt] = pSrcTL [(k - ((iOffsetdeltaFract) >> 31)) * iStepSide];
// step 1403} // step 1404 if (deltaFract) {// Do linear filtering for (1 = 0; 1 <blkSize; 1 ++) {refMainIndex = 1 + deltaInt; pDst [k * iDstStride + 1] = (Pel) (((32-deltaFract) * refMain [refMainIndex] + deltaFract * refMain [refMainlndex + 1] + 16) >> 5);
}}
else {// Just copy the integer samples for (1 = 0; 1 << blkSize; l ++) {pDst [k * iDstStride + 1] = refMain [1 + deltaInt];
}}
}}
// Flip the block if it is the horizontal mode if (modeHor) {for (k = 0; k <blkSize-1; k ++) {for (1 = k + 1; 1 <blkSize; 1 ++) {tmp = pDST [1iDstStride k * + 1]; pDst (k * iDstStride + 1] = pDst (1 * iDstStride + k]; pDst [1 * iDstStride + k] = tmp;
}}
} <sup>}</sup> [0068] Given that many changes and modifications of the present invention will undoubtedly become apparent to a person of average skill in the field after reading the above description, it should be taken into account that each particular embodiment shown and described for explanation, not is in any way considered as limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims, which in themselves discuss only those features considered relevant to the present invention.
125 members in 16 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 36432210 | United States of America | P | |
| 36432210 | United States of America | P | |
| 38854110 | United States of America | P | |
| 38854110 | United States of America | P | |
| 151696044 | – | – | – |
| 364322P | – | – | – |
| 388541P | – | – | – |
| US20100364322P | – | – | – |
| US20100388541P | – | – | – |
Members125
| Document | Office | Kind | |
|---|---|---|---|
| CA2804762A1 | Canada | A1 | |
| CA2934184A1 | Canada | A1 | |
| CA3014042A1 | Canada | A1 | |
| CA3014052A1 | Canada | A1 | |
| CA3014131A1 | Canada | A1 | |
| CA3096445A1 | Canada | A1 | |
| CA3098217A1 | Canada | A1 | |
| WO2012009540A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2011279139A1 | Australia | A1 | |
| MX2013000372A | Mexico | A | |
| AU2011279139A8 | Australia | A8 | |
| CN103004210A | China | A | |
| SG187065A1 | Singapore | A1 | |
| US2013114713A1 | United States of America | A1 | |
| EP2594076A1 | European Patent Office (EPO) | A1 | |
| KR20130088125A | Republic of Korea | A | |
| JP2013534797A | Japan | A | |
| EP2594076A4 | European Patent Office (EPO) | A4 | |
| JP2014158306A | Japan | A | |
| RU2013106296A | Russian Federation | A | |
| JP5687341B2 | Japan | B2 | |
| JP2015053728A | Japan | A | |
| EP2934008A1 | European Patent Office (EPO) | A1 | |
| EP2934009A1 | European Patent Office (EPO) | A1 | |
| JP5808839B2 | Japan | B2 | |
| CN105120263A | China | A | |
| CN105120264A | China | A | |
| US9225986B2 | United States of America | B2 | |
| CN105227960A | China | A | |
| US2016021392A1 | United States of America | A1 | |
| CN103004210B | China | B | |
| AU2011279139B2 | Australia | B2 | |
| US2016057448A1 | United States of America | A1 | |
| RU2579947C2 | Russian Federation | C2 | |
| BR112013000963A2 | Brazil | A2 | |
| KR20160092055A | Republic of Korea | A | |
| KR20160093087A | Republic of Korea | A | |
| EP2934008B1 | European Patent Office (EPO) | B1 | |
| PT2934008T | Portugal | T | |
| CA2804762C | Canada | C | |
| JP2017005720A | Japan | A | |
| MX344987B | Mexico | B | |
| PL2934008T3This record | Poland | T3 | |
| ES2605530T3 | Spain | T3 | |
| RU2613722C1 | Russian Federation | C1 | |
| RU2613725C1 | Russian Federation | C1 | |
| EP2594076B1 | European Patent Office (EPO) | B1 | |
| PT2594076T | Portugal | T | |
| KR101745928B1 | Republic of Korea | B1 | |
| ES2621902T3 | Spain | T3 | |
| EP2934009B1 | European Patent Office (EPO) | B1 | |
| JP6169554B2 | Japan | B2 | |
| PL2594076T3 | Poland | T3 | |
| PT2934009T | Portugal | T | |
| EP3226560A1 | European Patent Office (EPO) | A1 | |
| ES2637446T3 | Spain | T3 | |
| EP3232666A1 | European Patent Office (EPO) | A1 | |
| PL2934009T3 | Poland | T3 | |
| KR101811360B1 | Republic of Korea | B1 | |
| KR20170141289A | Republic of Korea | A | |
| KR101835460B1 | Republic of Korea | B1 | |
| KR20180026788A | Republic of Korea | A | |
| US9942565B2 | United States of America | B2 | |
| JP6321091B2 | Japan | B2 | |
| CN105227960B | China | B | |
| CN105120264B | China | B | |
| RU2658880C1 | Russian Federation | C1 | |
| US2018184120A1 | United States of America | A1 | |
| KR20180073720A | Republic of Korea | A | |
| KR20180075706A | Republic of Korea | A | |
| KR101878293B1 | Republic of Korea | B1 | |
| JP2018129850A | Japan | A | |
| JP2018129851A | Japan | A | |
| CN105120263B | China | B | |
| CA2934184C | Canada | C | |
| US10116960B2 | United States of America | B2 | |
| KR101924885B1 | Republic of Korea | B1 | |
| MX361484B | Mexico | B | |
| KR101927281B1 | Republic of Korea | B1 | |
| JP6479237B2 | Japan | B2 | |
| KR101927283B1 | Republic of Korea | B1 | |
| JP6484740B2 | Japan | B2 | |
| EP3232666B1 | European Patent Office (EPO) | B1 | |
| RU2687031C1 | Russian Federation | C1 | |
| PT3232666T | Portugal | T | |
| JP2019092208A | Japan | A | |
| EP3522535A1 | European Patent Office (EPO) | A1 | |
| US10397608B2 | United States of America | B2 | |
| PL3232666T3 | Poland | T3 | |
| EP3226560B1 | European Patent Office (EPO) | B1 | |
| MX367865B | Mexico | B | |
| PT3226560T | Portugal | T | |
| MX2019010417A | Mexico | A | |
| ES2729031T3 | Spain | T3 | |
| US2019335201A1 | United States of America | A1 | |
| US2019335202A1 | United States of America | A1 | |
| EP3570545A1 | European Patent Office (EPO) | A1 | |
| BR112013000963B1 | Brazil | B1 | |
| PL3226560T3 | Poland | T3 | |
| RU2710946C1 | Russian Federation | C1 |
Numbers
- Publication
- 2934008
- Publication, DOCDB
- 2934008
- Publication, EPODOC
- PL2934008T
- Application
- 15169604
- Application, DOCDB
- 15169604
- Application, EPODOC
- PL20150169604T
Titles2
- English
- LOW-COMPLEXITY INTRA PREDICTION FOR VIDEO CODING
- Polish
- PREDYKCJA WEWNĄTRZRAMKOWA O NISKIEJ ZŁOŻONOŚCI DO KODOWANIA WIDEO
Classification
- CPC, 6
- H04N19/11
- H04N19/593
- H04N19/44
- H04N19/176
- H04N19/61
- H04N19/82
- IPC, 5
- H04N19 176
- H04N19 11
- H04N19 593
- H04N19 61
- H04N19 82