NO332357B1

NO332357B1 - Implementation of run / level coding

Info

Publication number: NO332357B1
Application number: NO20101088A
Authority: NO
Inventors: Lars Petter Endresen; Stian Selnes
Original assignee: Cisco Tech Inc
Priority date: 2010-07-30
Filing date: 2010-07-30
Publication date: 2012-09-03
Also published as: WO2012015312A1; NO20101088A1

Abstract

SAMMENDRAG Den foreliggende oppfinnelsen vedrører en implementering av en prosess for å representere transformkoeffisienter i komprimering/dekomprimering i digitale videosystemer i prosessorer for flere formål. Den tilveiebringer en fremgangsmåte som på betydelig måte reduserer den nødvendige prosessorkapasiteten sammenliknet med implementering i henhold til tidligere kjent teknikk.SUMMARY The present invention relates to an implementation of a process for representing transform coefficients in compression / decompression in digital video systems in multi-purpose processors. It provides a method that significantly reduces the required processor capacity compared to prior art implementation.

Description

Område for oppfinnelsen Field of the invention

Oppfinnelsen vedrører implementering av entropikoding/-dekoding av transformkoeffisientdata i videokompresjonssystemer i datamaskininnretninger. The invention relates to the implementation of entropy coding/decoding of transform coefficient data in video compression systems in computer devices.

Bakgrunn for oppfinnelsen Background for the invention

Transmisjon av bevegelige bilder i sann tid anvendes i flere applikasjoner, slik som f.eks. videokonferanser, nettmøter, TV-kringkasting og videotelefoni. Transmission of moving images in real time is used in several applications, such as e.g. video conferences, online meetings, TV broadcasting and video telephony.

Å representere bevegelige bilder krever imidlertid store mengder informasjon, idet digital video typisk beskrives ved representasjon av hver piksel i et bilde med 8 bits (1 byte). Slike ukomprimerte videodata resulterer i store bitvolumer, og kan ikke overføres over konvensjonelle kommunikasjonsnettverk og transmisjonslinjer i sann tid på grunn av begrenset båndbredde. However, representing moving images requires large amounts of information, as digital video is typically described by representing each pixel in an image with 8 bits (1 byte). Such uncompressed video data results in large bit volumes, and cannot be transmitted over conventional communication networks and transmission lines in real time due to limited bandwidth.

Muliggjøring av sanntids videotransmisjon krever således en stor grad av datakompresjon. Datakompresjon kan imidlertid gå på bekostning av bildekvalitet. Derfor er det lagt et stort arbeid i utvikling av kompresjonsteknikker som tillater sanntidstransmisjon av høykvalitetsvideo over båndbreddebegrensede dataforbindelser. Enabling real-time video transmission thus requires a large degree of data compression. However, data compression can come at the expense of image quality. Therefore, a great deal of effort has gone into developing compression techniques that allow real-time transmission of high-quality video over bandwidth-limited data connections.

I videokompresjonssystemer er hovedmålet å representere videoinformasjon med så liten kapasitet som mulig. Kapasitet er definert med bits, enten som en fast verdi eller som bits/tidsenhet. I begge tilfeller er hovedmålet å redusere antallet bits. In video compression systems, the main goal is to represent video information with as little capacity as possible. Capacity is defined in bits, either as a fixed value or as bits/time unit. In both cases, the main goal is to reduce the number of bits.

De mest utbredte videokodingsmetodene er beskrevet i standardene MPEG<*>og H.26<*>. Videodataene gjennomgår fire hovedprosesser før transmisjon, nemlig prediksjon, transformasjon, kvantisering og entropikoding. The most widespread video coding methods are described in the standards MPEG<*>and H.26<*>. The video data undergoes four main processes before transmission, namely prediction, transformation, quantization and entropy coding.

Prediksjonsprosessen reduserer signifikant mengden av bits som er påkrevet for at hvert bilde i en videosekvens skal overføres. Den drar fordel av likheten mellom deler av sekvensen og andre deler av sekvensen. Siden prediktordelen er kjent for både koderen og dekoderen, behøver bare forskjellen overføres. Denne forskjellen krever typisk mye mindre kapasitet for sin representasjon. Prediksjonen er i hovedsak basert på vektorer som representerer bevegelser. Prediksjonsprosessen utføres typisk på kvadratiske blokkstørrelser (f.eks. 16x16 piksler). Bemerk at i enkelte tilfeller anvendes prediksjoner av piksler basert på tilstøtende piksler i samme bilde, i stedet for piksler i foregående bilder. Dette omtales som intraprediksjon, i motsetning til interprediksjon. The prediction process significantly reduces the amount of bits required for each frame in a video sequence to be transmitted. It takes advantage of the similarity between parts of the sequence and other parts of the sequence. Since the predictor part is known to both the encoder and the decoder, only the difference needs to be transmitted. This difference typically requires much less capacity for its representation. The prediction is mainly based on vectors representing movements. The prediction process is typically performed on square block sizes (eg 16x16 pixels). Note that in some cases predictions of pixels are used based on adjacent pixels in the same image, instead of pixels in previous images. This is referred to as intraprediction, as opposed to interprediction.

Residualet representert som en datablokk (f.eks. 4x4 piksler) inneholder fortsatt intern korrelasjon. En velkjent metode for å dra fordel av dette, er å utføre en todimensjonal blokktransform. I H.263 anvendes en 8x8 diskret cosinustransform, mens H.264 anvender en 4x4 heltallstype transform. Denne transformerer 4x4 piksler til 4x4 transformkoeffisienter, og disse kan vanligvis representeres med færre bits enn pikselrepresentasjonen. Transformasjon av en 4x4-oppstilling av piksler med intern korrelasjon vil sannsynligvis resultere i en 4x4-blokk med transformasjonskoeffisienter med mye færre ikke-nullverdier enn den originale 4x4-pikselblokken. The residual represented as a block of data (eg 4x4 pixels) still contains internal correlation. A well-known method to take advantage of this is to perform a two-dimensional block transform. In H.263, an 8x8 discrete cosine transform is used, while H.264 uses a 4x4 integer-type transform. This transforms 4x4 pixels into 4x4 transform coefficients, and these can usually be represented with fewer bits than the pixel representation. Transforming a 4x4 array of pixels with internal correlation is likely to result in a 4x4 block of transform coefficients with much fewer non-zero values than the original 4x4 block of pixels.

Direkte representasjon av transformasjonskoeffisientene er fortsatt for kostbart for mange anvendelser. En kvantiseringsprosess utføres for en ytterligere reduksjon av datarepresentasjonen. Følgelig gjennomgår transformasjonskoeffisientene kvantisering. En enkel versjon av kvantisering er å dividere parameterverdier med et tall - hvilket resulterer i et mindre tall som kan representeres med færre bits. Det skal nevnes at denne kvantiseringsprosessen har som resultat at den rekonstruerte videosekvensen er noe forskjellig fra den ukomprimerte sekvensen. Dette fenomenet omtales som "tapskoding" (eng: "lossy coding"). Resultatet fra kvantiseringsdelen omtales som kvantiserte transformasjonskoeffisienter. Direct representation of the transformation coefficients is still too expensive for many applications. A quantization process is performed to further reduce the data representation. Accordingly, the transform coefficients undergo quantization. A simple version of quantization is to divide parameter values by a number - resulting in a smaller number that can be represented with fewer bits. It should be mentioned that this quantization process results in the reconstructed video sequence being somewhat different from the uncompressed sequence. This phenomenon is referred to as "lossy coding". The result from the quantization part is referred to as quantized transformation coefficients.

Entropikoding er en spesiell form for tapsfri datakomprimering. Den involverer bl.a. anordning av bildekomponentene i en "sikksakk-"rekkefølge som anvender run-length encoding- (RLE-) algoritme som grupperer liknende frekvenser sammen, innsetter lengdekoding-nuller, og deretter benytter Huffman-koding på det gjenværende. Entropy coding is a special form of lossless data compression. It involves, among other things, arranging the image components in a "zigzag" order using a run-length encoding (RLE) algorithm that groups similar frequencies together, inserts length-encoding zeros, and then applies Huffman encoding to the remainder.

I H.264-koding blir DCT-koeffisientene for en blokk re-ordnet for å gruppere sammen ikke-null-koeffisienter i en gruppe (eng.: an array), noe som muliggjør effektiv representasjon av de gjenværende null-verdi-koeffisientene. Sikksakk-omordnings-banen (eng.: the zigzag reordering path; skanningsrekkefølge) er vist i figur 1. Mønsteret for rekkefølgen av sikk-sakk-skanningen er konfigurert i samsvar med sannsynligheten for ikke-null koeffisienter i hvert posisjon. På grunn av karakteristikkene til den foregående DCT, minsker sannsynligheten for ikke-null-koeffisienter i en blokk i den nedadgående høyre diagonale retning for en DCT-blokk. Ved re-ordning av koeffisientene i et sikksakk-mønster som illustrert i figur 1, vil ikke-null koeffisientene tendere til å konsentrere seg i de første posisjonene i gruppen (eng.: the array). In H.264 coding, the DCT coefficients of a block are rearranged to group together non-zero coefficients in an array, enabling efficient representation of the remaining zero-valued coefficients. The zigzag reordering path (eng.: the zigzag reordering path; scan order) is shown in figure 1. The pattern of the order of the zigzag scan is configured according to the probability of non-zero coefficients at each position. Due to the characteristics of the preceding DCT, the probability of non-zero coefficients in a block decreases in the downward right diagonal direction of a DCT block. When re-arranging the coefficients in a zigzag pattern as illustrated in Figure 1, the non-zero coefficients will tend to concentrate in the first positions in the array.

Resultatet av re-ordningsprosessen er altså en endimensjonal array som vanligvis inneholder en eller flere klynger av ikke-null-koeffisienter nær start, etterfulgt av strenger med null-koeffisienter. På grunn av det store antallet nullverdier, blir gruppen videre representert som en serie av (run, level)-par der run angir antall nuller som går foran en nullkoeffisient, og level angir magnituden av ikke-null-koeffisienten. Som et eksempel vil inngangs-gruppen 16, 0, 0, -3, 5, 6, 0, 0, 0, 0, -7, ... vil ha følgende korresponderende run-level-verdier: (0,16), (2, -3), (0,5), (0,6), (4, -7)... The result of the reordering process is thus a one-dimensional array that usually contains one or more clusters of non-zero coefficients near the start, followed by strings of zero coefficients. Due to the large number of zero values, the group is further represented as a series of (run, level) pairs where run denotes the number of zeros preceding a zero coefficient, and level denotes the magnitude of the non-zero coefficient. As an example, the input group 16, 0, 0, -3, 5, 6, 0, 0, 0, 0, -7, ... will have the following corresponding run-level values: (0,16), (2, -3), (0.5), (0.6), (4, -7)...

Når sikksakk-gruppen transformeres til run-level-verdier, er det beregningsmessig kostbart å gjennomkjøre alle koeffisienter og sjekke om de er ikke-null. Ettersom bilde oppløsningen øker, vil dette kreve en betydelig mengde prosessorkapasitet og til og med introdusere for mye forsinkelse, spesielt hvis kodingsprosessen implementeres på generelle, delte prosessorer, f.eks. på personlige datamaskiner. WO-2010/077148 beskriver en implementasjon av en prosess for å representere transformkoeffisienter ved komprimering/dekomprimering av digitale videosystemer i fleranvendelsesprosessorer. Kvantiserte transform koeffisienter som representerer en blokk av piksler i en videobilde er pakket til den halve minnestørrelsen, og deretter maskert, for derved å generere en gruppe av 1-ere og 0-er som definere posisjonene av ikke-null koeffisienter i den tilsvarende gruppen av pakkede transformkoeffisienter. Denne klargjøringen unngår parsing gjennom posisjoner i arrayen av transformkoeffisienter der null-verdier forekommer ved generering av run-level-representasjoner av koeffisientene, og dermed reduseres vesentlig redusere det nødvendige antall sløyfer som skal utføres. Denne metoden krever imidlertid at en viss shuffle-funksjon-re-ordningsdata-oppføringer er tilgjengelig i minnet for enhver re-ordning, som en hardkodet prosess i prosessoren. Denne funksjonen er p.t. bare tilgjengelig i nye generasjoners Intel-prosessorer. Dermed er det behov for en alternativ metode som trengs for å utnytte effektiviteten av denne oppfinnelsen også uten tilgang til shuffle-funksjonen. When the zigzag group is transformed into run-level values, it is computationally expensive to run through all coefficients and check if they are non-zero. As the image resolution increases, this will require a significant amount of processor capacity and even introduce too much delay, especially if the encoding process is implemented on general purpose, shared processors, e.g. on personal computers. WO-2010/077148 describes an implementation of a process for representing transform coefficients when compressing/decompressing digital video systems in multi-use processors. Quantized transform coefficients representing a block of pixels in a video image are packed to half the memory size, and then masked, thereby generating a group of 1s and 0s that define the positions of non-zero coefficients in the corresponding group of packed transform coefficients. This provision avoids parsing through positions in the array of transform coefficients where zero values occur when generating run-level representations of the coefficients, thus significantly reducing the required number of loops to be performed. However, this method requires that some shuffle function reorder data entries be available in memory for any reorder, as a hardcoded process in the processor. This function is currently only available in new generations of Intel processors. Thus, there is a need for an alternative method needed to utilize the effectiveness of this invention even without access to the shuffle function.

US-2008/046698 vedrører en fremgangsmåte for videodatakoding som innbefatter bl.a. kvantisering av romlige frekvenskoeffisienter for hver blokk i en ramme, og generering av en maske som har en bit for hver romlige frekvens i blokken. US-2008/046698 relates to a method for video data coding which includes i.a. quantizing spatial frequency coefficients for each block in a frame, and generating a mask having one bit for each spatial frequency in the block.

Sammenfatning av oppfinnelsen Summary of the Invention

Foreliggende oppfinnelse tilveiebringer en fremgangsmåte i en videokodings- eller The present invention provides a method in a video coding or

-dekodingsprosess i en datamaskininnretning for beregning av run- og level-representasjoner av respektive kvantiserte transformkoeffisienter som representerer pikselverdier i en blokk i et videobilde som er innsatt rad for rad i en endimensjonal gruppe C, hvor fremgangsmåten innbefatter trinnene å pakke hver kvantisert transformkoeffisient i C i et verdiintervall ([Max, Min]) ved å sette alle kvantiserte transformkoeffisienter større enn Max til å være lik Max, og alle kvantiserte transformkoeffisienter mindre enn Min til å være lik Min, å maskere C ved å generere en gruppe M som inneholder 1-ere i posisjoner som korresponderer med posisjonene til C som har ikke-null-verdier, og O-er i posisjoner som korresponderer med posisjoner i C som har null-verdier, å sette en nåværende rasterposisjon til null, hvor en rasterposisjon refererer til en rasterskanningsrekkefølge av koeffisientene i blokken, og for hver posisjon som inneholder en l-er i M, å avlede en nåværende sikksakk-posisjon fra nåværende rasterposisjon ved hjelp av en tabell som mapper rasterposisjoner til sikksakk-posisjoner, der en sikksakk-posisjon refererer til en sikksakk-skanningsrekkefølge av koeffisientene i blokken, og hvis nåværende sikksakk-posisjon ikke er null, og hvis nåværende sikksakk-posisjon minus siste sikksakk-posisjon minus 1 er mindre enn null, å forkaste alle lagrede runs og levels og å beregne nye runs og levels med en alternativ reservemetode, og hvis ikke, å sette run lik nåværende sikksakk-posisjon minus siste sikksakk-posisjon minus 1, og level lik forekommende verdi i posisjonen i C som tilsvarer nåværende raster- decoding process in a computer device for calculating run and level representations of respective quantized transform coefficients representing pixel values in a block of a video image inserted row by row in a one-dimensional array C, the method comprising the steps of packing each quantized transform coefficient into C in an interval of values ([Max, Min]) by setting all quantized transform coefficients greater than Max to be equal to Max, and all quantized transform coefficients less than Min to be equal to Min, to mask C by generating an array M containing 1 -ers in positions corresponding to positions of C that have non-zero values, and O's in positions corresponding to positions in C that have zero values, to set a current raster position to zero, where a raster position refers to a raster scan order of the coefficients in the block, and for each position containing an l's in M, to derive a current zigzag position from current raster position using a table mapping raster positions to zigzag positions, where a zigzag position refers to a zigzag scan order of the coefficients in the block, and if current zigzag position is not zero, and if current zigzag position minus last zigzag -position minus 1 is less than zero, to discard all saved runs and levels and to calculate new runs and levels with an alternative backup method, and if not, to set run equal to current zigzag position minus last zigzag position minus 1, and level equal occurring value in the position in C that corresponds to the current raster

posisjon, å lagre run og level, å sette siste sikksakk-posisjon lik nåværende sikksakk-posisjon, og å inkrementere nåværende rasterposisjon med antall posisjoner frem til neste l-er i M. position, to store run and level, to set the last zigzag position equal to the current zigzag position, and to increment the current raster position by the number of positions until the next l's in M.

Kort beskrivelse av tegningene Brief description of the drawings

For å gjøre oppfinnelsen enklere å forstå, og vi den følgende drøftingen vise til de medfølgende tegninger. Figur 1 illustrerer sikksakk-mønsteret som er brukt i tidligere kjent teknikk for å ordne transformkoeffisienter før entropikoding, Figur 2 illustrerer raster-skanningsmønster som anvendes i den foreliggende oppfinnelsen, Figur 3 er et flytskjema som illustrerer hvordan run-level-koding beregnes i henhold til MPEG4 og H.264, Figur 4 er et flytskjema som illustrerer en metode av typen beskrevet i WO-2010/077148, og Figur 5 er et flytskjema som illustrerer en eksempelimplementering i henhold til den foreliggende oppfinnelsen. To make the invention easier to understand, we refer the following discussion to the accompanying drawings. Figure 1 illustrates the zigzag pattern used in the prior art to arrange transform coefficients before entropy coding, Figure 2 illustrates the raster scan pattern used in the present invention, Figure 3 is a flowchart illustrating how run-level coding is calculated according to MPEG4 and H.264, Figure 4 is a flowchart illustrating a method of the type described in WO-2010/077148, and Figure 5 is a flowchart illustrating an example implementation according to the present invention.

Detaljert beskrivelse av oppfinnelsen Detailed description of the invention

I den etterfølgende beskrivelsen vil det vises til noen standardfunksjoner i biblioteket for den generelle programmeringsspråket C++, og som er direkte koblet til kompakte og effektive lavnivå-CPU-instruksjoner. C++ er mye brukt i programvareindustrien. Noen av dets anvendelsesområder innbefatter systemprogramvare, device-drivere, innebygd (eng.: embedded) programvare, høyytelses-server- og -klient-applikasjoner, og underholdnings-software, samt software for implementering av koding og dekoding av sanntidsvideo i generelle datamaskiner. In the following description, reference will be made to some standard functions in the library of the general programming language C++, which are directly connected to compact and efficient low-level CPU instructions. C++ is widely used in the software industry. Some of its applications include system software, device drivers, embedded software, high-performance server and client applications, and entertainment software, as well as software for implementing real-time video encoding and decoding in general purpose computers.

Figur 3 er et flytskjema som illustrerer hvordan run-level-kode i henhold til MPEG4 og H.264 beregnes i en første implementasjon i henhold til tidligere kjent teknikk. Etter kvantisering av transformkoeffisientene (Quant C) i en blokk, blir de kvantiserte koeffisienter om-ordnet til en endimensjonal gruppe (eng.: array) i henhold til det tidligere nevnte sikksakk-mønsteret. Prosessen går deretter inn i en sløyfe for parsing av gruppen for fastsettelse av run-level-verdier. Først sjekkes om antall posisjoner i gruppen er overskredet (I > 16). Hvis ikke, sjekkes hvorvidt nåværende posisjon i tabellen inneholder en null. I så fall blir både Run-variabelen og posisjonsindeksen (I) inkrementert, og prosessen går videre til starten av loopen igjen. Hvis ikke (nåværende posisjon inneholder en annen verdi enn null), blir den nåværende Run-variabelen og verdien av nåværende posisjon lagret som Run-Level verdi. Run-variabelen blir da nullstilt, før både Run-variabelen og posisjonsindeksen (I) inkrementeres, og prosessen går til starten av sløyfen igjen. Figure 3 is a flowchart illustrating how run-level code according to MPEG4 and H.264 is calculated in a first implementation according to prior art. After quantization of the transform coefficients (Quant C) in a block, the quantized coefficients are rearranged into a one-dimensional group (eng.: array) according to the previously mentioned zigzag pattern. The process then enters a loop for parsing the array to determine run-level values. First, it is checked whether the number of positions in the group has been exceeded (I > 16). If not, it is checked whether the current position in the table contains a zero. In that case, both the Run variable and the position index (I) are incremented, and the process continues to the start of the loop again. If not (current position contains a value other than zero), the current Run variable and the value of current position are stored as the Run-Level value. The Run variable is then set to zero, before both the Run variable and the position index (I) are incremented, and the process goes to the start of the loop again.

Prosessen avsluttes når posisjonsindeksen overskrider den maksimale størrelsen på gruppen, som i eksempelet illustrert i figur 3 er 16. The process ends when the position index exceeds the maximum size of the group, which in the example illustrated in Figure 3 is 16.

Slik det kan sees fra eksempelet på en tidligere kjent implementasjon som illustrert i figur 3, må den alltid kjøre gjennom run-level-kodings-sløyfen så mange ganger som det finnes posisjoner i gruppen (16 ganger i eksempelet). Dette blir svært ineffektivt, idet de fleste koeffisientene i C er null, og det er beregningsmessig kostbart å gjennomløpe over alle koeffisienter og sjekke om de er ikke-null. As can be seen from the example of a previously known implementation as illustrated in Figure 3, it must always run through the run-level coding loop as many times as there are positions in the group (16 times in the example). This becomes very inefficient, as most of the coefficients in C are zero, and it is computationally expensive to run through all the coefficients and check if they are non-zero.

Figur 4 er et flytskjema som illustrerer en andre implementasjon i henhold til den ovennevnte metoden beskrevet i WO-2010/077148.1 denne implementasjonen benyttes bit-masker og bit-scan-instruksjoner som gjør det mulig effektivt å hoppe over alle nullverdi-koeffisientene. Det starter ved kvantisering av transformkoeffisientene i blokken. I eksemplet er det 16 koeffisienter som er lagret i vektoren C. Figure 4 is a flowchart illustrating a second implementation according to the above-mentioned method described in WO-2010/077148.1 this implementation uses bit-masks and bit-scan instructions which make it possible to efficiently skip over all the zero value coefficients. It starts by quantizing the transform coefficients in the block. In the example, there are 16 coefficients stored in the vector C.

Prosessen fortsetter så med pakking og re-ordning alle de kvantiserte koeffisientene. Dette gjøres av C++instruksjonen PACKUSWB, som transformerer 16 ord med fortegn (eng.: signed words) til heltall uten fortegn, med metning. Dette betyr at hvis en koeffisient er større eller mindre enn omfanget av en byte uten fortegn, settes koeffisienten til henholdsvis max- eller min-verdien for området, som i denne implementeringen er 255 og 0. På denne måten blir minnestørrelsen for hver koeffisient redusert fra to til én byte. The process then continues with packing and re-arranging all the quantized coefficients. This is done by the C++ instruction PACKUSWB, which transforms 16 signed words into unsigned integers, with saturation. This means that if a coefficient is greater or less than the extent of an unsigned byte, the coefficient is set to the max or min value of the range, respectively, which in this implementation are 255 and 0. In this way, the memory size for each coefficient is reduced from two to one byte.

Neste trinn er å maskere de kvantiserte, pakkede og re-ordnede koeffisientene. Dette gjøres ved f.eks. å anvende C++funksjonene PCMPGTB og PMOVMSKB. PCMPGTB-funksjonen fyller en hel byte av 1-ere i posisjonen for ikke-null-verdier, og lar O-ene forbli uendret i nullenes posisjon. PMOVMSKB-funksjonen oppretter en 16-bits maske fra de mest signifikante bits av 16 bytes. Resultatet av disse to funksjonene, når de brukes på gruppen av kvantiserte, pakkede og re-ordnede koeffisienter (C), er en 16-bits gruppe (M) hvor l'ere indikerer korresponderende posisjoner av ikke-null-verdiene i C. The next step is to mask the quantized, packed and reordered coefficients. This is done by e.g. to use the C++ functions PCMPGTB and PMOVMSKB. The PCMPGTB function fills a full byte of 1's in the nonzero position, leaving the 0's unchanged in the zero position. The PMOVMSKB function creates a 16-bit mask from the most significant bits of 16 bytes. The result of these two functions, when applied to the array of quantized, packed, and reordered coefficients (C), is a 16-bit array (M) where l'ers indicate corresponding positions of the non-zero values in C.

Hvis M er ikke-null, kan C++funksjonen BSF brukes til å beregne indeksen for de første ikke-null-verdiene i C. BSF returnerer bit-indeksen for den minst signifikante bit av et heltall, dvs. - i tilfelle av M - den første plasseringen av en 1, startende fra høyre side. If M is non-zero, the C++ function BSF can be used to calculate the index of the first non-zero values in C. BSF returns the bit index of the least significant bit of an integer, i.e. - in case of M - the first position of a 1, starting from the right side.

Derfor er denne indeksen returnert av BSF, når den brukes på M, lik run, og den brukes direkte som oppslag i C-gruppen for å bestemme level. Dette er mulig siden C allerede er stokket ved bruk av PSHUFB-instruksjonen. Therefore, this index returned by BSF, when applied to M, is equal to run, and it is used directly as a lookup in the C group to determine level. This is possible since C is already shuffled using the PSHUFB instruction.

Æww-verdien som angitt av BSF-funksjonen blir så lagret, og etter oppslag, blir verdien lokalisert ved denne posisjonen i C lagret som nivået level. The Æww value as specified by the BSF function is then stored, and after lookup, the value located at this position in C is stored as the level level.

M blir endelig forskjøvet til høyre run+ 1 ganger for å nullstille indeksbiten fra M og forberede M for neste iterasjon i sløyfen. Ved å gjøre dette, vil innholdet i M som samsvarer med allerede beregnede Run-Level-verdier, bli fjernet fra M, og sløyfen kan anvendes på samme måte for å beregne de gjenværende Run-Level-verdier. M is finally shifted right run+ 1 times to reset the index bit from M and prepare M for the next iteration in the loop. By doing this, the contents of M that correspond to already calculated Run-Level values will be removed from M, and the loop can be used in the same way to calculate the remaining Run-Level values.

Siden alle nullene effektivt blir hoppet over ved bruk av BSF-instruksjonen, er bare ikke-null-koeffisient-kjøringer nødvendig for å beregne alle level- og rww-verdier. Since all zeros are effectively skipped when using the BSF instruction, only non-zero coefficient runs are required to calculate all level and rww values.

Den foreliggende oppfinnelsen er bl.a. basert på den observasjonen at runs av null-koeffisienter i 4x4 raster-skanning som illustrert i figur 2, i praksis oftest er ekvivalent med runs i 4x4 sikksakk-orden som illustrert i figur 1.1 de tilfeller der et kriterium for denne konverteringen er oppfylt, benytter en metode som likner den andre implementeringen i henhold til teknikkens stilling som beskrevet, men med shuffle-funksjonen utelatt, og i de tilfeller der et kriterium for denne konverteringen ikke er oppfylt, benyttes en reserve-metode f.eks i henhold til den første implementeringen av teknikkens beskrevet ovenfor. Virkninger er at sikksakk-skanning i de fleste tilfeller ikke utføres, men bare den mer effektive raster-skanning og en run-konvertering for ikke-null koeffisientene. The present invention is, among other things, based on the observation that runs of zero coefficients in 4x4 raster scanning as illustrated in figure 2 are in practice most often equivalent to runs in 4x4 zigzag order as illustrated in figure 1.1 the cases where a criterion for this conversion is met use a method similar to the second implementation according to the state of the art as described, but with the shuffle function omitted, and in those cases where a criterion for this conversion is not met, a reserve method is used, e.g. according to the first implementation of the technique described above. Effects are that in most cases zigzag scanning is not performed, but only the more efficient raster scanning and a run conversion for the non-zero coefficients.

Run-konvertering er gyldig for alle tilfeller der ikke-null koeffisientene opptrer i samme rekkefølge for begge skanninger. I teorien er dette ikke det mest sannsynlige tilfellet, alle mulige permutasjoner tatt i betraktning, men i praksis er det. Målinger gjort av oppfinnerne har vist at ikke-null-koeffisienter opptrer i den samme rekkefølge for begge skanninger i 98,5% av kodingstiden. Run conversion is valid for all cases where the non-zero coefficients appear in the same order for both scans. In theory this is not the most likely case, all possible permutations taken into account, but in practice it is. Measurements made by the inventors have shown that non-zero coefficients appear in the same order for both scans in 98.5% of the coding time.

Ifølge visse aspekter av den foreliggende oppfinnelsen, hvis koeffisienter med raster-skanningsindeks 0, 1, 4 og 5 er ikke-null, så vil begge skanninger returnere de fire koeffisientene i samme rekkefølge, men med forskjellige runs. Raster-skannings-runs kan deretter konverteres til ekvivalente sikksakk-runs. Som det fremgår av figurene 1 og 2, gjelder følgende mapping mellom rasterskanningspos isj onene og sikksakk-skanningsposisjonene: 0-0, 1-1, 2-5, 3-6, 4-2, 5-4, 6 -7, 7-12, 8-3, 9-8, 10-11, 11-13, 12-9, 13-10, 14-14, 15-15.1 eksempelet ovenfor, når runs for en rasterskanning indikerer ikke-nuller for skanningsindeks 0, 1, 4 og 5, vil denne mappingen innebære 0, 1, 2 og 4 som tilsvarende sikksakk-skanningsindeks. Derfor, når rekkefølgen av ikke-nuller er de samme for raster-skanning og sikksakk-skanning, kan den andre og mest effektive tidligere kjente implementering beskrevet ovenfor benyttes, men det er ikke noe behov for å endre rekkefølgen på koeffisientene, og shuffle-funksjonen kan utelates. According to certain aspects of the present invention, if coefficients with raster scan index 0, 1, 4 and 5 are non-zero, then both scans will return the four coefficients in the same order but with different runs. Raster scan runs can then be converted to equivalent zigzag runs. As can be seen from Figures 1 and 2, the following mapping applies between the raster scan positions and the zigzag scan positions: 0-0, 1-1, 2-5, 3-6, 4-2, 5-4, 6 -7, 7 -12, 8-3, 9-8, 10-11, 11-13, 12-9, 13-10, 14-14, 15-15.1 example above, when runs for a raster scan indicate non-zeros for scan index 0, 1, 4 and 5, this mapping will involve 0, 1, 2 and 4 as the corresponding zigzag scan index. Therefore, when the order of non-zeros is the same for raster scan and zigzag scan, the second and most efficient prior art implementation described above can be used, but there is no need to change the order of the coefficients, and the shuffle function can be omitted.

Hvis for eksempel raster-skanningsindeksene 0, 2 og 4 derimot er ikke-null, vil rekkefølgen som de fremtrer i, være forskjellig for de to skanningene, og siden shuffle-funksjonen ikke er tilgjengelig, må en reservemetode, for eksempel etter den første implementering i henhold til den tidligere kjente teknikken som beskrevet ovenfor, brukes. If, however, the raster scan indices 0, 2 and 4 are non-zero, the order in which they appear will be different for the two scans, and since the shuffle function is not available, a fallback method, for example after the initial implementation according to the previously known technique as described above, is used.

Kriteriet for å utløse reserveløsningen er å teste om et beregnet run for rasterskanningsrekkefølgen gir et negativt resultat. The criterion for triggering the backup solution is to test whether a calculated run for the raster scan sequence gives a negative result.

Run-beregningen utføres ved å måle om en eller flere run-verdier i rasterskanningsrekkefølgen er negativ ved bruk av tilsvarende sikksakk-skanningsindeks i beregningen. Altså avledes gjeldende rasterskanningsindeks, og den tilordnes til den korresponderende sikksakk-indeksen, ved bruk av en normal sikksakk-tabell som definert i H.264-anbefalingen. Beregningen er beskrevet i detalj i det følgende. The run calculation is performed by measuring whether one or more run values in the raster scan order are negative using the corresponding zigzag scan index in the calculation. Thus, the current raster scan index is derived, and it is assigned to the corresponding zigzag index, using a normal zigzag table as defined in the H.264 recommendation. The calculation is described in detail below.

La XK betegne sikksakk-posisjonen til ikke-null-koeffisientene der k indekserer forekomsten av ikke-null-koeffisienter. La videre Rkbetegne run-verdien for k'te forekomsten av en ikke-null-verdi i sikksakk-skanningsrekkefølgen, R'k run-verdien av den k'te forekomsten av en ikke-null verdi i rasterskanningsrekkefølgen ved bruk av sikksakk-skanning-indeks i beregningen. N er den siste k indeks slik at N+l er det totale antall ikke-nuller. En run-verdi for en ikke-nullkoeffisientposisjonXkkan beregnes somXk-Xk-i - 1. For sikksakk-skanningsrekkefølgen er dette alltid en positiv verdi, siden Let XK denote the zigzag position of the nonzero coefficients where k indexes the occurrence of nonzero coefficients. Further, let Rk denote the run value of the k'th occurrence of a non-zero value in the zigzag scan order, R'k the run value of the k'th occurrence of a non-zero value in the raster scan order using zigzag scan- index in the calculation. N is the last k index so that N+l is the total number of non-zeros. A run value for a non-zero coefficient position Xkkan is calculated as Xk-Xk-i - 1. For the zigzag scan order this is always a positive value, since

Den totale run RT for N +1 runs, Men generelt kan rasterskanningsrekkefølgen av ikke-null-koeffisientene imidlertid være forskjellig fra sikksakk-skanningsrekkefølgen. Ved bruk av sikksakk-posisjonene xki beregningen av korresponderende rasterposisjoner, vil dette alltid føre til minst én negativ rasterskanning-run, siden enhver permutasjon av posisjonene i (1) vil være i strid med (1). Betrakt for eksempel tre ikke-null-koeffisienter og at sikksakk-rekkefølgen returnerer xo, xi,X2, mens rasterskanningen returnerer xo,X2, xi. Den totale run for de to tilfellene blir da The total run RT for N +1 runs, However, in general, the raster scan order of the non-zero coefficients can be different from the zigzag scan order. When using the zigzag positions xki in the calculation of corresponding raster positions, this will always result in at least one negative raster scan run, since any permutation of the positions in (1) will violate (1). For example, consider three nonzero coefficients and that the zigzag sequence returns xo, xi,X2, while the raster scan returns xo,X2, xi. The total run for the two cases then becomes

Den forrige run R'2i (4) er negativ, siden xi <X2. Derfor er kriteriet for reservemetoden utløst. The previous run R'2i (4) is negative, since xi <X2. Therefore, the criterion for the reserve method is triggered.

Figur 5 er et flytskjema som illustrerer en eksempel-implementering i henhold til den foreliggende oppfinnelsen. Som tidligere angitt, kan prosedyren ha en viss likhet med den andre gjennomføring av kjent teknikk som beskrevet ovenfor, men uten behov for å re-ordne data, siden dataene prosesseres i rasterskannings-rekkefølgen, som er den samme rekkefølgen som dataene allerede er lagret med i minnet. Forskjellene er forklart nedenfor. Derfor bør figur 5 og den følgende beskrivelse leses i sammenheng med den øvrige beskrivelsen, spesielt figur 4 og den korresponderende beskrivelsen ovenfor. Figure 5 is a flowchart illustrating an example implementation according to the present invention. As previously indicated, the procedure may have some similarity to the second implementation of the prior art as described above, but without the need to re-arrange data, since the data is processed in the raster scan order, which is the same order in which the data is already stored in memory. The differences are explained below. Therefore figure 5 and the following description should be read in conjunction with the other description, especially figure 4 and the corresponding description above.

I "Quant C" kvantiseres de transformerte koeffisientene til en 4x4-blokk C. C er ganske enkelt en endimensjonal datagruppe hvor koeffisientene er satt inn fortløpende rad etter rad, med start fra øverste rad i blokken. Koeffisientene er dermed ordnet i en rasterskannings-rekkefølge. "Mask M = C" oppretter en 16-bits maske M fra pakkekoeffisientene C, der en 1-bit angir en ikke-null-koeffisient. I beslutningsboksen "M = 0" avsluttes prosedyren når det ikke er flere ikke-null-koeffisienter igjen å prosessere. "Sean M" skanner masken M for å finne raster-run R'k. I "Avled Run" avledes run Rkfra R'k via raster-indekskalkulering og sikksakk-tabelloppslag. I beslutningsboksen "Run <0", blir det besluttet om det skal falles tilbake til en konvensjonell run-levelkoding i henhold til den første implementeringen av kjent teknikk som beskrevet ovenfor og illustrert i fig 5, ignorere de tidligere lagrede runs og levels, eller å fortsette ved å lagre nåværende level og deretter gå i sløyfe tilbake til beslutningsboksen "M = 1". Beslutningen om å falle tilbake, gjøres hvis en negativ run Rker detektert. In "Quant C", the transformed coefficients are quantized into a 4x4 block C. C is simply a one-dimensional data group where the coefficients are inserted consecutively row by row, starting from the top row of the block. The coefficients are thus arranged in a raster scan order. "Mask M = C" creates a 16-bit mask M from the packet coefficients C, where a 1 bit indicates a non-zero coefficient. In the "M = 0" decision box, the procedure ends when there are no more non-zero coefficients left to process. "Sean M" scans the mask M to find the raster-run R'k. In "Derived Run", run Rk is derived from R'k via raster index calculation and zigzag table lookup. In the "Run <0" decision box, it is decided whether to fall back to a conventional run-level encoding according to the first implementation of the prior art as described above and illustrated in Fig. 5, to ignore the previously stored runs and levels, or to continue by saving the current level and then looping back to the "M = 1" decision box. The decision to fall back is made if a negative run is detected.

Claims

1. Procedure in a video coding or decoding process in a computer device for calculating run and level representations of respective quantized transform coefficients representing pixel values in a block in a video image inserted row by row in a one-dimensional group C, which method comprises the following steps: packing each quantized transform coefficient in C into an interval of values ([Max, Min]) by setting all quantized transform coefficients greater than Max to be equal to Max, and all quantized transform coefficients less than Min to be equal Min, to mask C by generating an array M containing 1's in positions corresponding to the positions of C that have non-zero values, and O's in positions corresponding to positions in C that have zero values, to set a current raster position to zero, where a raster position refers to a raster scan order of the coefficients in the block, characterized in that the method further comprises: for each position containing an l's in M, deriving a current zigzag position from current raster position through a table mapping raster positions to zigzag positions, where a zigzag position refers to a zigzag scan order of the coefficients in the block, if current zigzag position is not zero, and if current zigzag position minus last zigzag position minus 1 is less than zero, to discard all saved runs and levels, and calculate new runs and levels with an alternative backup method, and if not, to set run equal to the current zigzag position minus the last zigzag position minus 1 and level equal to the occurring value in the position in C that corresponds to the current raster position, to save run and level, to set the last zigzag position equal to the current zigzag position, and to increment the current raster position by the number of positions until the next l's in M.

2. Procedure in accordance with claim 1, characterized in that the table which maps raster positions to zigzag positions has the following entries: 0-0, 1-1, 2-5, 3-6, 4-2, 5-4, 6-7, 7-12, 8 - 3, 9-8, 10-11, 11-13, 12-9, 13-10, 14-14, 15-15.

3. Procedure in accordance with claim 1 or 2, characterized in that the step of further masking includes the following steps: creating a group C from C where positions corresponding to positions for non-zero values in C are filled with 1's, and positions corresponding to positions for zero values in C filled with 0's, to create M from C' by extracting the most significant bits from values in the respective positions of C, and to insert set bits in corresponding positions in M.

4. Procedure in accordance with claim 3, characterized by the step of creating a group C is performed by a C++ function PCMPGTB, and the step of creating M from C is performed by a C++ function PMOVMSKB.

5. Procedure in accordance with claim 4, characterized in that the step of determining positions containing non-zero values in C is performed by a C++ function BSF.

6. Method in accordance with one of claims 1-5, characterized by Max being 255 and Min being 0.

7. Method in accordance with one of claims 1-6, characterized in that the zigzag scan order follows a zigzag path of transform coefficient positions in the block starting at the upper left corner towards the lower right corner, and the raster scan order follows a raster path of transform coefficient positions in the block starting at the upper left corner, proceeding through coefficient positions from left to right , row after row, and ends in the lower right corner.