convertedav

HARDWARECO-PROCESSORSFORREAL-TIMEANDHIGH-QUALITYH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCVIDEOCODINGM.
Martina#,G.
.
Masera#,L.
Fanucci+,S.
Saponara++Dip.
IngegneriadellaInformazione,UniversitàdiPisa,56122,Pisa,Italy,{l.
fanucci,s.
saponara}@iet.
unipi.
it#CERCOM–Dip.
diElettronica,PolitecnicodiTorino,I-10129,Torino{maurzio.
martina,guido.
masera}@polito.
itABSTRACTReal-TimeandHigh-Qualityvideocodingisgainingawideinterestintheresearchcommunity,mainlyforentertainmentandleisureapplications.
FurthemoreH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC,themostrecentstandardforhighperformancevideocoding,canbesuccessfullyexploitedinsuchacriticalscenario.
Theneedforhigh-qualityimposestosustainuptotensofMbits/s.
TothatpurposeinthispaperoptimizedarchitecturesforH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCmostcriticaltasks,MotionEstimation(ME)andContextAwareBinaryArithmeticCoding(CABAC)arepro-posed.
Postsynthesisresultsona0.
18mstandardcellstechnologyshowthattheproposedarchitecturescanactu-allyprocessinrealtime720x480videosequencesat30Hzandgrantmorethan20Mbits/sinthesimplestconfiguration.
Keywords:Videocoding,H.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC,Hardwarearchitec-tures,motionestimation,entropycoder1.
INTRODUCTIONH264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCisthenewvideocodingstandardreleasedbyITU-TandISO/IEC.
Comparedtopreviousstandards,H.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCsuperiorperceptualqualityandhighscalability,makeitsuitablefordifferentscenarios.
Theimplementationofhardwareco-processors,abletosustainreal-timeandhighqualityH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCvideocoding,isparticularlyrelevanttogranthighperformance.
Figure1showsablockdiagramoftheH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCencodingscheme.
Withrespecttopreviouscodingstandards,H.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCincludesadditionalfeatures,particularlyintheMotionEstimation(ME)task,adoptingmulti-referenceframesandvariableblocksizes,andintheEntropyCoding(EC)task,adoptingaContextAdaptiveBinaryArithmeticCoder(CABAC).
AperformanceandcomplexityprofilinganalysisontheC-levelmodelofthecoderprovesthatthesefeaturesimprovethecodingeffi-ciencybyafactortwoattheexpenseofanincreasedim-plementationcost(computationandmemory)byoneorderofmagnitude[1,2].
Hencethedesignofhardwareco-processorsforMEandCABACismandatory.
Twodedi-catedarchitecturesarepresentedinthepaperallowingforreal-timeimplementationofH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCvideocoding.
ThesearchitecturesarewellsuitedforhighqualityscenarioswhereuptotensofMbits/sarereached,asintheMainPro-fileofthestandard.
IntheliteratureseveralworkshCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avebeenproposedconcern-ingtheimplementationofsingleblocksoftheH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCstandard.
In[3]H.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCintegertransformimplementa-tionisaddressed.
FewrecentworksconcerntheCABACimplementation:in[4]and[5]mixedHW/SWsystemsareproposed,whereas[6]concentratesonaCABACcoproces-sor.
ManyfastMEengineshCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avebeenproposedinliterature[7-11]toreducethecomplexityofconventionalFullSearch(FS).
AmongthemUMHexagonS[7]hasbeenofficiallyacceptedasthestandardfastMEsolutionintheJMrefer-encesoftwaremodel[12,13].
Itrealizesapredictivesearchwhichadoptsahexagonalwindowintherefiningphaseplusproperstopcriteria.
Inmostofknownmotionestimationalgorithms,thebasicsearchisrepeatedmultipletimes.
Figure1.
BlockdiagramoftheH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCencodingschemeThisiscriticalincaseofmultiplereferenceframesorvari-ableblocksizes.
SinceMEoperationsincreasewiththenumberofblocksandreferenceframes,unnecessaryredun-dancyisintroducedincomputationsandmemoryaccesses.
ItisworthpointingoutthatthispaperconcentratesonthewholeH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCframeworkanddealswiththemostcom-putationallyintensivetasks,showingarchitecturessuitedforreal-time,high-qualityvideocoding.
AsfarasCABACisconcernedamodularimplementationhasbeendevelopedinordertograntanincomingratescalablewiththenumberofCABACcoresemployed.
ForMEanadaptivealgorithmwithitsrelevanthardwarearchitectureisproposed.
ThenoveltechniqueCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avoidsunnecessarycomputationsandmemoryaccesses,whereasitallowsthesamehighcodingqualityofFS.
HereafterSection2dealswithCABACandMEalgorithmicdescription.
Relevanthardwarearchitec-turesaredescribedinSection3.
ConclusionsaredrawninSection4.
2.
ALGORITHMSDESCRIPTION2.
1CABACCABAC[14],whosestructureisreportedinFigure2,istheContextAdaptiveBinaryArithmeticCoderusedinH.
264astheentropyencodingengine.
ItcanbeemployedintheMainProfiletoimprovethecodingefficiencywithrespecttotheContextAdaptiveVariableLengthCoding(CCOLOR:#000000;BACKGROUND-COLOR:#ffff00">AVLC).
Infact,asprovedin[14],fortherangeofacceptablevideoqualityforbroadcastapplications(about30-38dB)bit-ratesCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avingsof9%to14%canbeachieved.
Figure2.
CABACstructureSinceCABACarithmeticencodingengineworksonlyonabinaryalphabet,itrequirestobinarizetheinputsymbols.
InfactmanysymbolsemployedinH.
264arenotbinarysym-bols(e.
g.
motionvectors),thustheyoughttobeconvertedinasequenceofbinarysymbols(bins).
Furthermore,asCABACisacontextadaptivecoder,foreachbinapropercontextoughttobeselectedamongtheprobabilitymodelsdefinedbythestandard.
Thentheencodingengineperformsdatacompressionwhileupdatingtheprobabilityestimation(seeFigure2).
Thebinarizationisachievedthroughdifferenttechniquesdependingonthesymboltobebinarized.
UnaryBinarization(U):itisusedforunsignedsyntaxelements.
Theyarerepresentedasasequenceof'1'ter-minatedbya'0'.
TruncatedUnaryBinarization(TU):itisusedforalimitednumberofunsignedsyntaxelements.
GivenathresholdcMax,forasyntaxelementlessthancMax,Uisemployed.
AsyntaxelementequaltocMaxiscodedasasequenceof'1'withlengthcMax.
ConcatenatedUnary/k-thorderExp-Golomb(UEGk)Binarization:itisusedforsignedelements.
ItismadeofaprefixgeneratedwithTUandasuffixgeneratedwithk-thorderExp-Golombcodes.
Fixedlengthbinarization(FL):itisusedforalimitednumberofsyntaxelementswhosevaluesareintegers∈[0,cMax].
DuringthebinarizationaContextIdentifierisassignedtoeachsyntaxelement.
Thisidentifierandthecurrentbinposi-tion,throughsomethresholds,generateanindex(ctxIdx),thatallowsfindingthecorrectcontext.
Infactcontextsarestoredinatablethatcontainsthedifferentinitialprobabilityvaluesforthearithmeticencoder.
Eachcontextcanbeunivo-callyidentified,throughctxIdx.
Thecodingengineisbasedonthearithmeticencodingofabinwithitscontext.
Asthearithmeticcoderisbinary,onlytwosymbolsareallowed,namelytheleastprobablesymbol(LPS)andthemostprob-ablesymbol(MPS).
Thearithmeticcodingisbasedontherecursivepartitionoftheprobabilityinterval[0,1]insub-intervalswhosewidthisproportionaltotheprobabilityofthesymboltobecoded.
GiventheprobabilitiesoftheLPS(pLPS)andoftheMPS(pMPS=1-pLPS),thesub-intervalswidth(RLPS,RMPS)canbeupdatedasLPSMPSLPSLPSRRRpRR==whereRisthecurrentintervalwidth.
Let'sintroducelowasthelowerpointofthecurrentinterval,itholdstruethat:LPSRRRRlowlowMPSRRRlowlowLPSnewLPSnewLPSnewnew=+===ToCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avoidtheuseofmultiplicationstoperformthearithmeticcoding,inH.
264significantvaluesoftheintervalwidth(R)andoftheLPSprobability(pLPS)arepre-calculatedandstoredintwovectors,calledQandP.
FurthermoreRpLPSvalues,obtainedwithQandP,arestoredintoa4x64matrix(M)[14].
GiventhecurrentintervalwidthandthecurrentLPSprobability,afinitestatemachine(FSM)managesthetransitionsontheMmatrixvalues;thisFSMwillbereferredasFSMM.
FurthermoretoCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avoidtheintervaltobecometoosmallsomerenormalizationsareemployed.
2.
2Variableblocksize,multiframesMEAtalgorithmiclevelweproposetoaddalowcomplexitycontextawarecontrollertobasicMEsearchengines,FSorFasttechniqueasUMHexagonS.
Thecontrollerextractsfromthesearchenginesomepartialresults:1)MotionVectors(MV),2)SumofAbsoluteDifference(SAD)cost,3)infor-mationontheinputsignalstatistic.
ThenthecontrollerusesthemtoautomaticallyconfiguretheMEsearchparameters:numberofreferenceframes,validblockmodesandsearchareaforeach16x16blockanditssub-partitionsdownto4x4-pixelblocks.
Theglobalcontrolcombinesthreebasicalgo-rithms:A)TheSearchAreaControl,originallyproposedforaFSenginein[10].
TheoptimalsearchsizefortheblockunderestimationisderivedbycomparingwithproperthresholdstheSADandMVvaluesofalreadyencodedneighbouringblocks:3spatialand1temporal.
Inthispaperthesamecon-trolhasbeensuccessfullyappliedtoUMHexagonS.
B)TheModesControl.
ProfilinganalysisofthestandardprovesthatusingthesmallerblocksizesisusefulforimageswithcomplextexturewhileitcanbeCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avoidedforhomoge-nousonestoreducecomplexity.
Thecontroloversmallerblocksizes(4x8,8x4and4x4partitions)decideswhichofthemmustbeenabledforMEeachtimea16x16blockisencoded.
MoreoveritaccomplishesitstaskbycomparingtheSADcostofthecurrent16x16partitionwithtwothresh-olds.
DependingontheresultsofthecomparisontheMEwillcontinueusingother6,5(COLOR:#000000;BACKGROUND-COLOR:#ffff00">avoiding4x4)or3(COLOR:#000000;BACKGROUND-COLOR:#ffff00">avoiding4x4,4x8and8x4)blocksizes.
C)TheFrameControl,whichdecidesthemaximumnumberofreferenceframestobeusedfortheMEofa16x16blockanditsselectedsubpartitions.
Thedata(SADcost,MVandoptimalreferenceframe)ofthealreadyencoded16x16par-titionareusedtodecidehowmanyreferenceframesareuseful:fortheenabledsmallersubpartitions,forthesame16x16partitioninthenextframe.
Theencodingprocess,usingthethreecontrolsisaccom-plishedaccordingtothisprocessingflow:(i)theoptimalsearchareaandreferenceframenumberforthe16x16blockarepreliminarilysizedusingthealgorithmsinA)andC).
(ii)Thebasicsearchengine,UMHexagonSorFS,performstheMEforthe16x16partition.
(iii)usingdata(MV,SADvalueandoptimalreferenceframe)fromthepreviousopera-tionthecontrolsinB)andC)decidewhichsubpartitionsmustbeenabledforMEandhowmanyreferenceframesmustbeusedfortheirsearch.
Thesearchsizeisthesamederivedforthe16x16partition.
Table1comparesourcontrolappliedtoUMHexagonSvs.
conventionalFS:ourtechniqueallowsforacomplexityre-ductionoftwoordersofmagnitudewithanCOLOR:#000000;BACKGROUND-COLOR:#ffff00">averagebit-ratelossbelow1%.
Resultsareexpressedas%changesofbit-rateforagivenPSNRquality(BR%)andofMEprocess-ingtime(MET%)whenintegratingourcontrollerintotheJMmodelandrunningitonaAMD2.
4+processor.
Figure3comparesfortheTennisCCIRvideotheJM9en-coderwithFSandtheJM9encoderwithUMHexagonSplusourcontrollerintermsofabsolutePSNRandbit-ratevalues.
ThesamehighcodingqualityofFSiskeptunalteredforbit-rateapplicationsupto55Mbits/s.
Table1–UMHexagonSwithallthreecontrolsvs.
FSFigure3.
Rate-distortioncurveforTennisCCIR3.
COPROCESSORSARCHITECTURES3.
1.
CABACcoprocessorThissectiondescribesthemostcriticalaspectstoimplementaCABACcoprocessor.
First,analyzingindetailtheJMreferencesoftwaremodel[12],ithasbeenobservedthatmostoftheencodingtimeisrequiredbytheEncodeDecisionandEncodeBypassroutines(roughly20%oftheCABACprocessingtime).
Moreover,sincethevalueRpLPSdependsonR,anAsLateAsPossible(ALAP)strategycanbeemployed,assuggestedin[5].
InfactRisquantizedononly4values(vectorQcontainsonly4elements),the4correspondingRpLPSvaluescanbereadtogetherfromamemory(wheretheFSMMtransitionsarestored)andloadedinto4registers.
ThentherightvaluecanbeselectedbasedonthecorrectRvalue.
Furthermoresincethearithmeticcoderproducesavariablenumberofoutputbits,theoutputregisterneedstobecarefullydesigned.
Basedonasimulativeapproacha48bitsoutputregisterhasbeenemployedasdetailedinthefollowing.
TheprocessingblocksshowninFigure4hCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avebeendevel-opedwithamodulardesignmethodology.
Thearchitectureiscomposedofamaincontrolunit,ECCUinFigure4,withasixteenstatesFSMdevotedtosendtheproperstartsignalandcommandstothedifferentCABACencoderblocks.
Twosimpleblocks,namelyInitFSMandCTX,areenabledbytheECCU.
TheformerisdevotedtosendtheproperinitialprobabilityvaluestoFSMM.
ThelatterismadeoftwosmallRAMsdevotedtostore,foreachcontext,theMPSandthecurrentstateoftheFSMthatmanagessymbolprobabilities.
ThecomputationpartoftheproposedarchitectureismadeofaROMwheretheFSMMtransitionsarestoredandaunittocomputeRandlow(RlowUnit).
TheRlowUnitismadeofa16bitscounterforalreadycodedsymbolsanda16bitscounterforthesyntaxelements.
AnadderandasubtracterareusedtocalculateRandlowrespectivelywiththeafore-mentionedALAPstrategy.
StefanTempeteCoastguardForemanAkiyoSIFCIFQCIFCIFCIFMET%-93,98-95,35-95,88-96,48-99,53BR%1,011,570,11,54-0,75Figure4.
ProposedarchitectureblockschemeAmultiplexerallowstocorrectlyselecttheinputvaluesfortheRlowUnitdependingonthecurrentsymbolsencodingmethod.
TheintervalrenormalizationismanagedbytheRenormUnit.
Inordertokeeptherenormalizationsimple,ithasbeenimplementedasa16bitssubtracterandashifter.
ObservingthatthesmallestvalueforRis0x0001andthattherenormalizationstopswhenR0x0100,theworstcaseiseightiterations.
Theoutputoftheencoderisman-agedbythePutByteUnit.
Thisblockhasbeenimple-mentedthroughsomeadders,fewlogicandtwo32bitsshiftregisters(left-shiftandright-shift)asdepictedinFigure5.
Figure5.
PutbyteUnitThroughsimulationsontheJMsoftwaremodel,ithasbeenfoundthat32bitsgranttobeabletostorethecodedbitsintheworstcase.
Astheworstcaseweconsideredthecasewhenonecodedbitisgeneratedafterthemaximumnumberof"follow"bits.
Theoutputregister,devotedtostorethecodedbytesneedstobecarefullysizedinordertoaccom-modatetheoutputbitswithoutdroppingorstoppingthecodingprocess.
Consideringthattherenormalizationcangenerateupto8bits(oneforeachrenormalizationstep),thatthefollowrequiresupto32bitsandthatthelastgener-atedbitcouldcompleteabyte,theoutputregistershouldbe48bitswide.
FinallythecontentofthisregisterisstoredintotheOutputBuffer.
Theflushingprocedurerequiredtotermi-natethecodingofaslice[13]isimplementedbytheFlushUnit(seeFigure4).
ItsinternalstructureisthesameasforthePutByteUnit.
Theonlydifferenceisthatthefollowisnotrequiredandthat,ifnecessary,acertainnumberofpad-dingbitsareaddedtocompletethelastbyte.
Theproposedarchitecturerequires11clockcyclestoencodeasymbol.
TheVHDLmodeldevelopedfortheproposedar-chitecturehasbeensynthesizedona0.
18mCMOSstan-dard-cellstechnology.
SincetheamountofROMandRAMrequiredbytheproposedarchitectureisextremelysmall,theuseofmacrosgeneratedbyROMandRAMgeneratorswouldproduceanexcessiveoverheadintermsofarea.
Asaconsequence,theROMhasbeenmappedaslogiccellsandtheRAMasanarrayofflip-flops.
Postsynthesisresultsshowthatupto250MHzclockfre-quencycanbeusedwithanoccupationof176kgates.
Thustheproposedarchitectureisabletosustainanincomingrateof22.
73Mbits/s.
Thisrateallowstoprocessinrealtime720x480videoat30Hzevenatlowcompressionratios(e.
g.
5:1).
Comparedwiththesolutionsdescribedin[4],[5]and[6]theproposedarchitectureshowssomecommonpointsandsomedifferences.
Inparticular,sincein[4]anFPGAimplementationisconsideredafaircomparisonisnotpossi-ble.
Ontheotherhandwecancomparetheproposedarchi-tecturewith[5]and[6].
Theperformanceofthearchitecturedescribedin[5]isgivenintermsoffulladders.
Sothatweevaluatedtheperformanceofafulladderonthesame0.
18mtechnologyemployedforourdesign.
Theresultisthat[5]cansustainupto20Mbits/swithnearthesamecomplexityoftheproposedarchitecture.
Consideringthearchitectureproposedin[6]wecanstatethatitachievesamorethan3timeshigherthroughputwithanearlydoublecomplexitywithrespecttotheproposedarchitecture.
Nevertheless,itisworthpointingoutthatthereducedcomplexityandthemodularityshownbytheproposedarchitecturemakesitsuit-ableforaparallelimplementation.
Asanexampleresortingtotwoinstancesoftheproposedarchitecturethetotalincom-ingratecanbedoubledattheexpenseofroughly350kgates.
3.
2.
AdaptiveMEcoprocessorTheresultsreportedinSection2forMErefertoasoftwareimplementation.
TheoriginalFSandUMHexagonSsoftwareimplementationsarequitefarfromreal-timecoding.
How-ever,thankstothecomplexityreductionofourtechnique,real-timeisachievedforthe30HzQCIFvideos;forCIFonesthereal-timeisallowedataframeratebetween15and30Hzdependingonthesequencedynamism.
Toachievereal-timeforlargerformatsand/ortoreducethepowercon-sumptionofthesoftwareapproachforlow-powerterminalsadedicatedhardwarearchitectureisneeded.
InthiscasetheproposedtechniquecanbeimplementedaccordingtothearchitecturesketchedinFigure6.
Thecontext-awarecontrolsystemcanbeeasilyrealizedinreal–time,alsoforlargervideoformats(e.
g.
CCIR,VGA,4CIF).
Asimplemicrocon-trollersuchasthe8051,publicCOLOR:#000000;BACKGROUND-COLOR:#ffff00">availableasreusableVHDLmacrocell,withanimplementationcomplexityofroughly10kgatesin0.
18mCMOSstandard-cellstechnologyiswellsuitedforthistask.
Thebasicsearchenginecanberealizedreusingoneofthesystolicarchitecturesproposedinthelit-eratureforFS,e.
g.
[11].
Infact[11]featuresanarrayof256SADprocessingelementswithacircuitcomplexityofroughly105kgatesandathroughputof1macroblock(MB)matchingperclockcycle.
Alocalmemoryof13kBytescanbeusedasMBsearchareabuffertoreduceaccessfrequencytolargebackgroundframememories.
Theoperationflowforbothsearchengineandcontext-awarecontrollerisdescribedhereafter.
HardwareSearchEngineMEparameters&I/OControlSAD,MV,RCurrentPixelsReferencePixelsData_I/OExt_ctrl_I/OLocalMemorySearchSize&n.
ref.
frames&validmodesMem.
ctrl.
Figure6.
BlockdiagramoftheMEhardwarearchitectureThesearchenginestartsperformingthe16x16partitionMEwhilethesystemcontrolwaitsforpredictioncostandopti-malreferenceframedata(step1).
Afterthat,suchinforma-tioncanbeprocessedtofigureouttheallowedpartitionsandtheirrelativemaximumnumberofreferenceframeswhiletheMEengineiswaiting(step2).
Instep3theMEenginecon-cludestheestimationwhilethecontrolsystemcanworkonthe16x16partitionforthenextMB.
Accordingtothisflowthesystolicsearchengineisstalledonlyinstep2andtheestimatedpercentagestalltimeisroughly2%.
Therequiredsystemclockfrequencytoprocessinreal-timea720x480videoat30Hzisabout70MHzconsideringthethroughputof1MBmatchingperclockcycleandthe2%processingstall.
4.
CONCLUSIONSInthispapertwooptimizedhardwareco-processors,oneforCABACandoneforvariableblocksizemultiframesME,hCOLOR:#000000;BACKGROUND-COLOR:#ffff00">avebeenpresented.
BothconcernthefastimplementationofthemostdemandingH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCparts;sothattheyareparticularlysuitedforreal-timeandhigh-qualityvideocod-ing.
Postsynthesisresultsona0.
18mstandardcellstech-nologyshowthat720x480videoat30Hzandmorethan20Mbits/scanbesustained,provingtheproposedcoprocessorseffectiveness.
REFERENCES[1]S.
Saponaraetal.
,"Performanceandcomplexityco-evaluationoftheAdvancedVideoCodingstandardforcost-effectivemultimediacommunications",J.
AppliedSignalProcessing,vol.
2,2004,pp.
220-235[2]J.
Ostermannetal.
,"VideocodingwithH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC:tools,performanceandcomplexity",IEEECirc.
andSyst.
Magazine,vol.
4,2004,pp.
7–28[3]L.
H.
-Yao,C.
Y.
-Chih,C.
C.
-Hong,L.
B.
-Da,Y.
J-Ferr,"Combined2-DtransformandquantizationarchitecturesforH.
264videocoders",IEEEInternationalSymposiumonCir-cuitsandSystems,pp.
23-26,2005[4]V.
H.
S.
Ha,W.
S.
Shim,J.
W.
Kim,"Real-timeMPEG-4COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC/H.
264CABACentropycoder",inIEEEInternationalConferenceonConsumerElectronics,pp.
255–256,2005[5]R.
Osorio,J.
Bruguera,"ArithmeticcodingarchitectureforH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCCABACcompressionsystem",IEEEEu-romicro-DigitalSystemDesign,pp.
62–69,2004[6]H.
Shojania,S.
Sudharsanan,"AhighperformanceCABACencoder",inInternationalIEEE-NEWCASCon-ference,pp.
19–22,2005.
[7]Z.
Chen,J.
Xu,Y.
He,"EfficientfastMEpredictionsandearly-terminationstrategybasedonH.
264statisticalcharac-ters",ICICS–PCM2003,Dec.
2003,Singapore,pp.
213-218[8]H.
Tourapis,A.
Tourapis,"FastmotionestimationwithintheH.
264codec",Proc.
IEEEICME'03,July2003,pp.
517-520[9]P.
Kuhn,Algorithms,complexityanalysisandVLSIar-chitecturesforMPEG-4motionestimation,KluwerAca-demicPublisher,1999[10]S.
Saponaraetal.
,"AdaptivealgorithmforfastmotionestimationinH.
264/MPEG-4COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC",Proc.
Eusipco2004,Wien,Sept.
2004,pp.
569–572[11]Y.
W.
Huangetal.
,"HardwarearchitecturedesignforvariableblocksizemotionestimationinMPEG-4COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC/JVT/ITU-TH.
264",Proc.
IEEEISCAS,pp.
796-799,Bangkok,2003[12]http://iphome.
hhi.
de/suehring/tml[13]JVTandITU-T,"DraftITU-Trecommendationandfinaldraftinternationalstandardofjointvideospecification(ITU-TRec.
H.
264—ISO/IEC14496-10COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVC)[14]D.
Marpe,H.
Schwarts,T.
Wiegand,"Context-basedAdaptiveBinaryArithmeticCodingintheH.
264/COLOR:#000000;BACKGROUND-COLOR:#ffff00">AVCvideocompressionstandard",IEEETrans.
onCircuitsandSys-temsforVideoTech.
,vol.
13,pp.
620–636,July2003ACKNOWLEDGMENTThisworkhasbeensupportedbyEUfunds(underNEWCOMNoE)andNationalfunds(PRIMOproject).