NO336215B1 - Simultan og sløyfefri vektorberegning av alle run-level par i videokomprimering. - Google Patents

Description

Simultan og sløyfefri vektorberegning av alle run-level par i videokomprimering

Teknikkens område

Den foreliggende oppfinnelse angår implementering av entropikoding/ -dekoding av transformasjonskoeffisientdata fra videokompresjonssystemer i datamaskinenheter eller systemer.

Oppfinnelsens bakgrunn

Transmittering av levende bilder i sanntid benyttes i flere anvendelser slik som, men ikke begrenset til, videokonferanser, nettmøter, fjernsynskringkasting (TV), og videotelefoni. Å representere levende bilder krever store mengder informasjon da digital video vanligvis beskrives ved å representere hvert piksel i et bilde med 8 bits, noe som tilsvarer 1 byte. Slike ukomprimerte videodata resulterer i store bit-volumer, og kan ikke overføres via konvensjonelle kommunikasjonsnett og overføringslinjer i sanntid, grunnet begrenset båndbredde.

Dermed vil transmittering av video i sanntid kreve en stor grad av datakomprimering. Datakomprimering kan imidlertid gå ut over bildekvaliteten. Derfor er store anstrengelser gjort for å utvikle komprimeringsteknikker slik at video med høy kvalitet kan transmitteres i sanntid mellom datakoblinger med begrenset båndbredde. I videokomprimeringssystemer er hovedmålet å representere videoinformasjonen med så lite påkrevet kapasitet som mulig. Kapasitet er definert med bits, enten som en konstant verdi eller som bits/tidsenhet. I begge tilfellene er det et mål å redusere antall bits. En konvensjonell videokodingsmetode er beskrevet i 'Moving Picture Experts Group' (MPEG) og H.26 standardene. Videodataene gjennomgår fire hovedprosesser før transmittering (det vil si: prediksjonsprosess, transformasjonsprosess, kvantiseringsprosess og entropikoding).

Prediksjonsprosessen reduserer antall bit som kreves for representasjon av hvert enkeltbilde som skal transmitteres av en videosekvens. Prosessen utnytter likheten i deler av sekvensen med andre deler av sekvensen. Siden prediksjonsdelen er kjent for både kode- og dekoderen heten, vil bare differansen måtte transmitteres. Denne differansen krever typisk mye mindre kapasitet for sin representasjon. Prediksjonen er hovedsaklig basert på vektorer som representerer bevegelser. Prediksjonsprosessen blir konvensjonelt utført på kvadratiske, firkantete blokkstørrelser (for eksempel 16x16 piksler). Merk at i noen tilfeller blir prediksjon av piksler basert på de tilstøtende piksler i det samme bildet, i stedet for pikslene fra de foregående bilder. Dette er referert til som "intra-prediksjon" (intra prediction) (som ikke må forveksles med "inter-prediksjon" (inter prediction)). Residualen, representert som en blokk av data (foreksempel 4x4 piksler), inneholder fortsatt intern korrelasjon. En konvensjonell metode utnytter dette, og utfører en todimensjonal blokktransformasjon. I H.263 benyttes en 8x8 "discret cosinus transformasjon" (DCT), mens det i H.264 benyttes en 4x4 heltallstransformasjon. Dette transformerer 4x4 piksler til 4x4 transformasjonskoeffisienter som vanligvis kan representeres med færre Obits enn pikselrepresentasjonen. Transformasjon av en 4x4 matrise av piksler med intern korrelasjon kan resultere i en 4x4 blokk med transformasjonskoeffisienter med mange færre ikke-null verdier enn den opprinnelige 4x4 pikselblokken.

Direkte representasjon av transformasjonskoeffisienter er for kostbart for mange anvendelser. En kvantiseringsprosses utføres for en ytterligere reduksjon av datarepresentasjonen. Dermed gjennomgår transformasjonskoeffisientene en kvantisering. En metode å kvantisere på er å dividere parameterverdiene med et tall, noe som resulterer i et lavere tall som kan representeres med færre bits. Denne kvantiseringsprosessen resulterer i at den rekonstruerte videosekvensen er noe forskjellig fra den ukomprimerte sekvensen. Dette fenomenet omtales som "koding med kvalitetstap" (lossy coding). Resultatet fra kvantiseringstrinnet refereres til som kvantiserte transformasjonskoeffisienter.

Entropikoding er en spesiell form for tapsfri datakomprimering. Entropikoding innebærer å arrangere bildekomponentene i en "sikksakk" orden, ved å benytte en "run-length encoding" (RLE) algoritme som grupperer lignende frekvenser sammen, setter inn lengdekodingsnuller (length coding zeros), og deretter benytte en Huffman koding på det som er igjen.

I H.264 koding, omordnes DCT-koeffisientene for en blokk til å gruppere ikke-null koeffisienter i en rekke (array), noe som tillater en effektiv representasjon av de resterende koeffisientene med verdi lik null. Figur 1 viser forløpet for omordningen av sikksakkordenen (det vil si skanningsrekkefølgen). Mønsteret til rekkefølgen av sikksakkskanningen er konfigurert i henhold til sannsynligheten for ikke-null koeffisienter i hver stilling. Pa grunn av egenskapene til den foregående DCT, reduseres sannsynligheten for ikke-null koeffisienter i en blokk i diagonal retning, nedover til høyre, i en DCT blokk. Når man omordner koeffisientene til en sikksakkorden, som illustrert i figur 1, har ikke-null koeffisienter generelt en tendens til å konsentrere seg til de første posisjonene i rekken.

Resultatet av omordningsprosessen inkluderer en endimensjonal rekke som inneholder én eller flere grupperinger av ikke-null koeffisienter nær begynnelsen, etterfulgt av strenger av null-koeffisienter. På grunn av det store antallet nullverdier, er rekkene ytterligere representert som en serie run, level) par, der "run" indikerer antallet nuller før en ikke-null koeffisient, og "level" angir størrelsen til ikke-null koeffisienten. Som et eksempel vil inndatatabell: [7, -3, 0, 0, 0, 0, 3, -1, 2, -1, 0, 0, 0, 1, 0,] ha de følgende tilsvarende run-level verdier: (0, 7), (0, -3), (4, 3), (0, -1), (0, 2), (0, -1), (3, 1), (1, 1). Når sikksakk rekken transformeres til run-level verdier, er det beregningsmessig dyrt å kjøre en sløyfe (loop) over alle koeffisientene og undersøke om de er ikke-null.

Koding av video til HD formater øker kravene til minne- og prosseseringskraft, og krever effektiv og høy båndbredde til minneorganiseringene, kombinert med beregningsintensive kapabiliteter. På grunn av disse kravene, må man finne en tilnærming med fleksibel parallellprosessering for å møte behovet på en kostnadseffektiv måte.

Videokodeker er vanligvis installert på spesialtilpasset maskinvare i videoendepunkter med prosessorer basert på DSP. Imidlertid har det i den senere tid blitt mer vanlig å installere videokodeker i generiske prosessorer i et SIMD prosessormiljø.

Det er derfor et behov for en tidsbesparende og prosessoreffektiv run/level eller CAVLC (Context Aware Variable Length Coding) fremgangsmåte, som utnytter egenskapene til de generelle prosessorene i et SIMD prosessormiljø uten bruk av sløyfer og uten å kompromisse på datakvaliteten.

WO 2010 077148 Al redegjør for en prosess for å beregne kjør- og-nivårepresentasjoner av kvantiserte transformkoeffisienter inkludert å pakke hver kvantiserte transformkoeffisient i et verdiintervall (maks, min) ved å sette alle kvantiserte transformkoeffisienter større enn maks er lik maks, og alle kvantiserte transformkoeffisienter mindre enn min er lik min; å omorganisere de kvantiserte transformkoeffisientene som resulterer i et array C av omorganiserte transformkoeffisienter; å maske C ved å generere et array M som inneholder enere i posisjoner som korresponderer til posisjoner i C som har ikke-nullverdier, og nuller i posisjoner som korresponderer til posisjoner i C som har nullverdier; og for hver posisjon som inneholder en ener i M, generere en kjøring og en nivårepresentasjon ved å sette nivåverdien lik en forekomst av en verdi i en korresponderende posisjon C, og å sette kjøreverdien lik antallet posisjoner framover relativt til en nåværende posisjon i M siden en forrige forekomst av ener i M.

Oppsummering av oppfinnelsen

Anvendelser av oppfinnelsen presenterte heri, beskriver en fremgangsmåte i en videokodings- eller dekodingsprosess utført i en datamaskinenhet for beregning av run- og/eller level representasjoner av de respektivt kvantiserte transformasjonskoeffisienter som representerer pikselverdier i en blokk i et videobilde innsatt i en koeffisientrekke (coefficient array), som omfatter trinnene; å generere en bitmaskrekke (bitmask array) ved å sette inn "+1" i posisjoner tilhørende ikke-null koeffisienter i koeffisientrekken og "0" i tilsvarende posisjoner for null-koeffisienter i koeffisientrekken, å utføre et oppslag for de respektivt 8 minst signifikante bits og de 8 mest signifikante bits i bitmasken i en oppslagstabell som mapper alle de mulige 8 bits punktgrafikkverdier med de korresponderende nedre del og øvre del bytemapverdier, å sy sammen de oppslåtte nedre del og øvre del bytemapverdier og i en første bytemaprekke, å sette inn bytene til den første bytemaprekken fra indeksposisjon 8 minus antallet ikke-nuller de 8 minst signifikante bits i bitmasken i en andre bytemaprekke.

I anvendelser av oppfinnelsen presentert heri, omfatter fremgangsmåten også et trinn for å bestemme level-representasjon ved å avlese påfølgende bytes fra koeffisientrekkene som er indeksert med verdier av den andre bytemaprekken.

I noen anvendelser av oppfinnelsen presentert heri, omfatter fremgangsmåten også trinnene å opprette en kopi av den andre bytemaprekken i en tredje bytemaprekke, å legge til "+l"til hver verdi i den tredje bytemaprekken, å skifte verdiene i den tredje bytemaprekken til høyre, å subtrahere den tredje bytemaprekken fra den andre bytemaprekken, resulterende i verdier som tilsvarer run-representasjonen.

I noen anvendelser av oppfinnelsen presentert heri, er oppføringene i oppslagstabellen på 8 bytes størrelse, at de nedre del verdier er høyrejustert, de øvre del verdier er venstrejustert, og de byte som ikke er okkupert av nedre del og øvre del verdier er stuffet (stuffed) med -lere.

I noen anvendelser av oppfinnelsen presentert heri, er trinnene i fremgangsmåten utført med SIMD instruksjoner.

Anvendelser av oppfinnelsen presentert heri, beskriver også en kodings- eller dekodingsenhet tilpasset for å beregne run- og/eller levelrepresentasjoner av de respektivt kvantiserte transformasjonskoeffisienter som representerer pikselverdier til en blokk av et videobilde innsatt i en koeffisientrekke, som omfatter et middel for å generere en bitmaskrekke (bitmask array) ved å sette inn "+1" i posisjoner tilhørende ikke-null koeffisienter i koeffisientrekken og "0" i tilsvarende posisjoner for null-koeffisienter i koeffisientrekken, et middel for respektivt å utføre et oppslag for de respektivt 8 minst signifikante bits og de 8 mest signifikante bits i bitmasken i en oppslagstabell som mapper alle de mulige 8 bits punktgrafikkverdier med de korresponderende nedre del og øvre del bytemapverdier, et middel for å sy sammen de oppslåtte nedre del og øvre del bytemapverdier og i en første bytemaprekke, et middel for å sette inn bytene til den første bytemaprekken fra indeksposisjon 8 minus antallet ikke-nuller de 8 minst signifikante bits i bitmasken i en andre bytemaprekke.

I anvendelser av oppfinnelsen presentert heri, omhandler kodings- eller dekodingsenheten også et middel for å bestemme level-representasjon ved å avlese påfølgende bytes fra koeffisientrekkene som er indeksert med verdier av den andre bytemaprekken.

I noen anvendelser av oppfinnelsen presentert heri, omhandler kodings- eller dekodingsenhet også et middel for å opprette en kopi av den andre bytemaprekken i en tredje bytemaprekke, et middel for å legge til "+1" til hver verdi i den tredje bytemaprekken, et middel for å skifte verdiene i den tredje bytemaprekken til høyre, et middel for å subtrahere den tredje bytemaprekken fra den andre bytemaprekken, resulterende i verdier som tilsvarer run-representasjonen.

I noen anvendelser av kodings- eller dekodingsenheten presentert heri, er oppføringene i oppslagstabellen er på 8 bytes størrelse, at de nedre del verdier er høyrejustert, de øvre del verdier er venstrejustert, og de byte som ikke er okkupert av nedre del og øvre del verdier er stuffet (stuffed) med -lere.

I noen anvendelser av kodings- eller dekodingsenheten presentert heri, er midlene utført med SIMD instruksjoner.

Kort beskrivelse av te<g>nin<g>ene

Figur 1 viser et sikksakkmønster som angir koeffisientrekkefølgen til en koeffisient rekke i en blokk, Figur 2 viser et flytskjema som illustrerer hvordan run-level koden beregnes i en konvensjonell implementering, Figur 3 viser et flytskjema som illustrerer hovedtrinnene i en utførelse i henhold til den foreliggende oppfinnelse her presentert,

Tabell 1 er en tabell som viser en oppslagstabell som benyttes i anvendelser i henhold til den foreliggende oppfinnelse her presentert.

Detaljert beskrivelse av en eksempelutførelsesform

Figur 2 er et flytskjema som illustrerer hvordan run-level koden, i henhold til Moving Picture Experts Group (MPEG-4) og H.264, beregnes i en konvensjonell implementering. Etter kvantisering av transformasjonskoeffisientene (Quant C) 201 i en blokk, er run-variabelen og posisjonsindeksen (I) satt til null 203. Deretter blir de kvantiserte koeffisientene omordnet 205 til en endimensjonal rekke i henhold til den nevnte sikksakkordenen 100 som vist i figur 1. Prosessen går deretter inn i en sløyfe for å analysere rekken, og bestemme run- og levelverdier. Først undersøkes det om antall posisjoner i rekken er overskredet (det vil si I > 16) 207. Hvis ikke, undersøkes det så om den nåværende posisjonen i rekken inneholderen null 209. Hvis ja, blir både run-variabelen, og posisjonsindeksen (I) inkrementert med ett trinn, ved trinn 217 og 219, og prosessen fortsetter til starten av sløyfen. Dersom den gjeldende posisjonen inneholderen ikke-null verdi, blir den gjeldende run-variabelen og verdien til den aktuelle posisjonen lagret som run-level verdien, ved trinnene 211 og 213. Run- variabelen blir så tilbakestilt 215, før både run-variabelen, og posisjonsindeksen (I) inkrementeres, ved trinnene 217 og 219, og prosessen fortsetter til starten av sløyfen. Prosessen avsluttes når posisjonsindeksen (I) overskrider den maksimale størrelsen på rekken, som i det viste eksempel i figur 2, er 16.

Som det kan ses i de konvensjonelle implementeringene vist i figur 2, må prosessen alltid kjøre igjennom kodingssløyfen for run-level så mange ganger som det er posisjoner i rekken (det vil si 16 ganger i eksempelet vist i figur 2). Dette blir svært lite effektivt ettersom de fleste koeffisienter i C er null, og det er beregningsmessig kostbart å kjøre en sløyfe over alle koeffisientene og undersøke om de er ikke-null verdier.

I henhold til anvendelser av oppfinnelsen presentert heri, presenteres en enkel og beregningsmessig billig metode hvor alle ikke-null koeffisienter raskt bestemmes simultant med tabelloppslag og SIMD (Single Instruction, Multiple Data).

I den følgende diskusjon, vil det samme eksempel på en sekvens av koeffisienter i en 4x4 blokk som har blitt kvantisert og omordnet i henhold til den standarden som anvendes i den ovennevnte bakgrunnsdelen benyttes, satt inn i den følgende endimensjonale koeffisientrekken:

Som allerede antydet, er det nødvendig å beregne level og run, der "level" simpelthen er ikke-null koeffisienter lagret sekvensielt, og "run" er avstanden mellom to påfølgende koeffisienter i henhold til deres opprinnelige plassering.

Resultatet som skal oppnås er derfor som følger:

For å oppnå dette resultatet, blir en såkalt "bitmaske" (bitmask) generert hvor "1" betegner en ikke-null koeffisient og "0" betegner en koeffisient som er null.

Merk at det i bitmasken ovenfor er bitet lengst til venstre som er det minst signifikante bit, og er derfor indeksert som 0. Dette vil implisitt bli tatt hensyn til i den videre beskrivelse, for eksempel når det refereres til den "nedre" og "øvre".

Da run og level normalt beregnes manuelt i en ineffektiv sløyfe som gjentas over koeffisientene sekvensielt, foreslår oppfinneren i stedet, basert på bruk av bitmasken, å generere et kompakt såkalt "bytemap" som betegner posisjonen av ikke-null koeffisientene, som følger:

Som man kan se, angir bytemapen de respektive bitposisjonene til ikke-null koeffisienter i sekvensen av koeffisienter.

Tilsynelatende finnes det én unik bytemap for hver mulige bitmaskeorden. Oppfinneren foreslår derfor videre å kartlegge bytemapen for de tilsvarende bitmasker i en oppslagstabell. Siden én tabell imidlertid vil bli for stor for praktiske formål, da den vil inneholde 256 elementer med 16 byte, til sammen 1 MB, benyttes to tabeller, der én tabell betegner en nedre del av bytemapen, og en annen tabell betegner en øvre del, hver med 256 elementer med 8 byte, til sammen bare 4KB. Mappingen av bytemapen og bitmasken til eksempelet over vil da være som følger:

Øvre del:

Dec: 8,9, 13, 15 Hex: 08090d0f => Dec: 163 Bin:10100011

Nedre del:

Dec: 0, 1, 6, 7 Hex: 00010607 => Dec: 195 Bin:11000011

Merk at de binære tallene ovenfor er snudd om sammenlignet med den illustrerte bitmasken, dette på grunn av det faktum at det minst signifikante bit er indeksert til 0 (som tidligere beskrevet).

De to tabellene er videre flettet sammen og justert slik at bytemapet til den nedre og den øvre del korresponderer til den samme nedre og øvre del av punktgrafikkverdiene. En slik sammenslått tabell er illustrert i tabell 1. Her er alle mulige heksadesimale representasjoner av den øvre og nedre del av bytemapen plassert side ved side sammen med den tilsvarende desimalrepresentasjon av punktgrafikken. Merk også at elementene i den nedre tabellen er høyrejustert, og elementene i den øvre tabellen er venstrejustert, grunnen til dette vil bli åpenbar i den videre diskusjonen. Merk også at overflødige bytes er fylt med heksadesimalet ff, som i den følgende diskusjonen også blir referert til som -1.

I eksempelet ovenfor, gir et oppslag av den nedre 8 bits "11000011" = 195 i tabellen tilbake,

Ikke innfylte bytes er med intensjon satt til "-1".

Et oppslag på den øvre 8 bits "11000101" = 163 i tabellen returnerer,

Disse to blir så satt sammen og resulterer i,

Denne 16 bytes rekken lagres deretter i en 24 bytes buffer, på en måte som alltid sikrer at element 8 tilfeldigvis blir startposisjonen til bytemapet. Således foreslås det å beregne antallet bitsett (lik 1) i den øvre 8 bits delen av masken, for eksempel ved hjelp av SIMD instruksjonen POPCNT og lagre 16 bytes vektoren med denne offseten. I eksemplet er det 4 bitsett i den øvre del av masken, og resultatet blir:

Her betegner C ikke initialiserte bytes. Deretter avleses de 16 bytes fra posisjon 8 som følger:

Level-verdiene oppnås deretter i ett enkelt trinn, ved for eksempel å kalle opp SIMD instruksjonen PSHUFB, med koeffisientene og bytemapen som argument, noe som gir følgende resultat:

Deretter beregnes run-verdiene ved å subtrahere bytemapen med den skiftede bytemapen + 1 som følger. Grunnen til at ikke innfylte byte er satt til -1, er at den fylte verdien etter skiftingen og å addere +1 bør bli null for å gi riktig run etter subtraksjonen.

Til slutt blir antall ikke-null byte for hele bitmasken beregnet, for eksempel ved hjelp av SIMD instruksjonen POPCNT. I dette eksemplet returnerer POPCNT 8 og, som ønsket, blir det endelige resultatet:

Hovedelementene i anvendelense av den foreliggende oppfinnelse som er beskrevet ovenfor, er illustrert i flytdiagrammet i figur 3.

Som allerede antydet, kan anvendelsene av den foreliggende oppfinnelse som er beskrevet ovenfor med fordel implementeres med SIMD instruksjoner i et SIMD-prosessor miljø. I det følgende vil eksemplet ovenfor bli beskrevet ved å henvise til et konkret kjørbart SIMD-instruksjonssett. Funksjonene som brukes er alminnelig kjente funksjoner for personer med kunnskap innenfor fagområdet. Instruksjonssettet er uthevet i kursiv, og slås sammen med forklaringene til de ulike delene av i n st ru ksj o n ssettet. Denne bitmasken kan faktisk betraktes som et tall, og hvert slikt unike tall beskriver hvilken av de 16 koeffisientene som ikke er null. For å unngå for mange oppføringer (entries) i oppslagstabellen, blir dette tallet delt inn i en nedre og øvre del på følgende måte: unsigned char bitmask_ lo = bitmask& Oxff;

unsigned char bitmask_ hi = bitmask»0x8;

Resultatet av denne operasjonen er:

Nedre maske { 1, 1, 0, 0, 0, 0, 1, 1}

Øvre maske { 1, 0, 1, 0, 0, 0, 1, 1}

Disse to rekkene er på 8 bit hver, og 8 bits heltall er i området fra 0 til 255.

I eksemplet er de to tallene:

Nedre maske: 195

Øvre maske: 163

Med disse to tallene vil et oppslag i bytemaptabellen identifisere de korresponderende bytemapene.

I plassering 195 i venstre del av bytemaptabellen, finner man det heksadesimale tallet 0xffffffff00010607, og i plassering 163 i høyre del av bytemaptabellen, finner man det heksadesimale tallet 0x08090d0fffffffff. Dermed,

long long bytemap_ lo = magic[ bitmask_ lo][ 0] ;

resulterer i ff ff ff ff 00 01 06 07, og

long long bytemap_ hi = magic[ bitmask_ hi][ l] ;

resulterer i 08 09 Od Of ff ff ff ff.

Tallene ovenfor er skrevet i heksadesimalt format, og de tilsvarende desimaltallene er:

Nedre bytemap { -1, -1, -1, -1, 0, 1, 6, 7}

Øvre bytemap { 8, 9, 13, 15, -1, -1, -1, -1}

Det er ikke tilfeldig at de "ubrukte" bytene er satt til -1, da dette kan hjelpe oss til å oppnå de riktige run-verdiene senere. De to bytemapene trenger nå å bli sydd sammen for å oppnå én enkel bytemap.

Den mest naive måte for å gjøre dette vil føre til:

bytemap { -1, -1, -1, -1, 0, 1, 6, 7, 8, 9, 13, 15, -1, -1, -1, -1}

Dette vil imidlertid ikke være så enkelt å anvende, da de bytene, som run og level skal beregnes av, er lagret i midten av rekken, i posisjonene fra 4 til 12.

De "ubrukte" bytene på hver side av rekken må derfor elimineres. For å gjøre dette, må bytemapet skiftes som en funksjon av antallet ikke-null byte. I det følgende betegner X plasseringene i det øvre bytemapet som er forskjellig fra null, og Y betegner plasseringene i det nedre bytemapet.

shift = 0 { Y, Y, Y, Y, Y, Y, Y, Y, X, X, X, X, X, X, X, X}

shift =1{ Y, Y, Y, Y, Y, Y, Y, Y, X, X, X, X, X, X, X,-l}

shift = 2 { Y, Y, Y, Y, Y, Y, Y, Y, X, X, X, X, X, X,-l,-l}

shift = 3 { Y, Y, Y, Y, Y, Y, Y, Y, X, X, X, X, X,-l,-l,-l}

shift = 4 { Y, Y, Y, Y, Y, Y, Y, Y, X, X, X, X,-l,-l,-l,-l}

shift = 5 { Y, Y, Y, Y, Y, Y, Y, Y, X, X, X,-l,-l,-l,-l,-l}

shift = 6 { Y, Y, Y, Y, Y, Y, Y, Y, X, X,-l,-l,-l,-l,-l,-l}

shift = 7 { Y, Y, Y, Y, Y, Y, Y, Y, X,-l,-l,-l,-l,-l,-l,-l}

shift = 8 { Y, Y, Y, Y, Y, Y, Y, Y,-l,-l,-l,-l,-l,-l,-l,-l}

Således, hvis alle bytes i det øvre bytemapen er ubrukt og "-1", vil det være nødvendig å skifte bytemapen med 8, noe som vil bety at den første byten i den resulterende bytemapen vil være den første byten i den nedre bytemapen. For å oppnå dette, kan bytemapen enkelt flyttets med det antallet bit som er angitt i den øvre bitmasken. En måte å oppnå dette på vil være og først telle antallet ikke-null bits i den øvre bitmasken: int nonzero_ hi = _ mm_ popcnt_ u32( bitmask_ hi) ;

Hvis den sammensydde bytemap er lagret i en buffer på den plasseringen som er lik antallet bits satt i den øvre bitmasken, vil det følgende oppnås for alle mulige kombinasjoner:

hvor C betegner ikke-initialiserte bytes.

v(& buffer[ nonzero_ hi]) =

_ mm_ set_ epi64x( bytemap_ lo, bytemap_ hi) ;

Deretter blir bytes fra posisjon 8 i dette bufferet avlest og man oppnår, i eksempeltilfellet:

{cc, cc, cc, cc, ff, ff, ff, ff, 00, 01, 06, 07, 08, 09, Od, Of}

Skrevet på desimalform blir ikke-null bytemapen da: {0, 1,6, 7, 8, 9, 13, 15}

v(& bytemap) = v(& buffer[ 8]) ;

Level-verdiene kan nå enkelt beregnes ved å bruke en funksjon for tabelloppslag på koeffisientene, med den sistnevnte bytemaprekken som argument, for å oppnå: {1, 1,-1, 2,-1, 3,-3, 7}

v(& level) = _ mm_ shuffle_ epi8( v(& coeffs), v(& bytemap)) ;

For å beregne run-verdiene må imidlertid bytemapen først forskyves med 1 og legges til +1 for å få et "shiftmap".

v(& shiftmap) = mm_ srli_ sil28(_ mm_ add_ epi8( v(& bytemap),_ mm_ setl_ epi8( l)), l) ;

Deretter vil run-verdiene bli oppnådd ved å subtrahere shiftmapet fra bytemapet:

v(& run) = _ mm_ subs_ epu8( v(& bytemap), v(& shiftmap)) ;

Da oppnås både run og level.

For å fullføre instruksjonssettet, er instruksjonene for visning av run/level til en skjerm vist under:

Den største fordelen med den her presenterte oppfinnelse er at run og level hurtig kan bestemmes ved hjelp av et enkelt tabelloppslag og effektive vektorinstruksjoner, i motsetning til de forskjellige konvensjonelle metodene som manuelt itererer over koeffisientene, én om gangen. Å behandle level-verdiene som signerte byte er en tilnærming, og en reserveløsningsmetode må implementeres i tilfellet det skulle være nødvendig med to bytes for å representere level. Mens reserveløsningsmetoden er betydelig tregere, har undersøkelser vist at dette representerer en neglisjerbar mengde ettersom tilnærmingen med signerte bytes gjelder i mer enn 99 % av tilfellene.

Claims (8)

1. En fremgangsmåte i en videokodings- eller dekodingsprosess utført i en datamaskinenhet for beregning av run- og/eller levelrepresentasjoner av de respektivt kvantiserte transformasjonskoeffisienter som representerer pikselverdier i en blokk i et videobilde innsatt i en koeffisientrekke (coefficient array),karakterisert ved at fremgangsmåten omfatter trinnene: Å generere en bitmaskrekke (bitmask array) ved å sette inn "+1" i posisjoner tilhørende ikke-null koeffisienter i koeffisientrekken og "0" i tilsvarende posisjoner for null-koeffisienter i koeffisientrekken, Å utføre et oppslag for de respektivt 8 minst signifikante bits og de 8 mest signifikante bits i bitmasken i en oppslagstabell som mapper alle de mulige 8 bits punktgrafikkverdier med de korresponderende nedre del og øvre del bytemapverdier, Å sy sammen de oppslåtte nedre del og øvre del bytemapverdier og i en første bytemaprekke, Å sette inn bytene til den første bytemaprekken fra indeksposisjon 8 minus antallet ikke-nuller de 8 minst signifikante bits i bitmasken i en andre bytemaprekke, Å bestemme level-representasjon ved å avlese påfølgende bytes fra koeffisientrekkene som er indeksert med verdier av den andre bytemaprekken.

2. En fremgangsmåte som angitt i krav 1,karakterisert ved at den videre omfatter følgende trinn: å opprette en kopi av den andre bytemaprekken i en tredje bytemaprekke, å legge til "+1" til hver verdi i den tredje bytemaprekken, å skifte verdiene i den tredje bytemaprekken til høyre, å subtrahere den tredje bytemaprekken fra den andre bytemaprekken, resulterende i verdier som tilsvarer run-representasjonen.

3. En fremgangsmåte som angitt i et av kravene 1-2, karakterisert vedat oppføringene i oppslagstabellen er på 8 bytes størrelse, at de nedre del verdier er høyrejustert, de øvre del verdier er venstrejustert, og de byte som ikke er okkupert av nedre del og øvre del verdier er stuffet (stuffed) med -lere.

4. En fremgangsmåte som angitt i et av kravene 1-3, karakterisert vedat trinnene utføres med SIMD instruksjoner.

5. En kodings- eller dekodingsenhet tilpasset for å beregne run- og/eller levelrepresentasjoner av de respektivt kvantiserte transformasjonskoeffisienter som representerer pikselverdier til en blokk av et videobilde innsatt i en koeffisientrekke,karakterisert ved Et middel for å generere en bitmaskrekke (bitmask array) ved å sette inn "+1" i posisjoner tilhørende ikke-null koeffisienter i koeffisientrekken og "0" i tilsvarende posisjoner for null-koeffisienter i koeffisientrekken, Et middel for respektivt å utføre et oppslag for de respektivt 8 minst signifikante bits og de 8 mest signifikante bits i bitmasken i en oppslagstabell som mapper alle de mulige 8 bits punktgrafikkverdier med de korresponderende nedre del og øvre del bytemapverdier, Et middel for å sy sammen de oppslåtte nedre del og øvre del bytemapverdier og i en første bytemaprekke, Et middel for å sette inn bytene til den første bytemaprekken fra indeksposisjon 8 minus antallet ikke-nuller de 8 minst signifikante bits i bitmasken i en andre bytemaprekke, Et middel for å bestemme level-representasjon ved å avlese påfølgende bytes fra koeffisientrekkene som er indeksert med verdier av den andre bytemaprekken.

6. En kodings- eller dekodingsenhet i henhold til krav 5,karakterisert ved Et middel for å opprette en kopi av den andre bytemaprekken i en tredje bytemaprekke, Et middel for å legge til "+1" til hver verdi i den tredje bytemaprekken, Et middel for å skifte verdiene i den tredje bytemaprekken til høyre, Et middel for å subtrahere den tredje bytemaprekken fra den andre bytemaprekken, resulterende i verdier som tilsvarer run-representasjonen.

7. En kodings- eller dekodingsenhet i henhold til et av kravene 5-6,karakterisert vedat oppføringene i oppslagstabellen er på 8 bytes størrelse, at de nedre del verdier er høyrejustert, de øvre del verdier er venstrejustert, og de byte som ikke er okkupert av nedre del og øvre del verdier er stuffet (stuffed) med -lere.

8. En kodings- eller dekodingsenhet i henhold til et av kravene 5-7,karakterisert vedat midlene utføres med SIMD instruksjoner.