CopyrightIEEE/TransactionsonNetworking,June1996 VideoconferencingintheInternet ThierryTurlettiandChristianHuitema Abstract ThispaperdescribestheINRIAVideoconferencingSystem(ivs),alowbandwidthtool forreal-timevideobetweenworkstationsonthe InternetusingUDPdatagramsandtheIPmulticastextension.Thevideocoder-decoder(codec) isasoftwareimplementationoftheuit-trecommendationh.261originallydevelopedforthe IntegratedServicesDigitalNetwork(ISDN).Our focusinthispaperisonadaptingthiscodecfor theinternetenvironment.weproposeapacketizationscheme,anerrorcontrolschemeandan outputratecontrolschemethatadaptstheimage codingprocessbasedonnetworkconditions.this workshowsthatitispossibletomaintainvideoconferenceswithreasonablequalityacrosspacketswitchednetworkswithoutrequiringspecialsupportfromthenetworksuchasresourcereservationoradmissioncontrol. 1Introduction Asthebandwidthavailableonnetworksandthe speedofcomputersincreases,real-timetransmissionofvideobetweengeneralpurposeworkstationsbecomesamoreandmorerealisticapplication.however,evenwithahighspeednetwork, videohastobecompressedbeforetransmission. Forexample,sendinguncompressedNTSCvideo requiresabout60mb/s.fortunately,thereisso muchredundancyinmostvideosequencesthat evenarelativelysimplecompressionschemecan signicantlydecreasetherateofvideoows.videocompressionisgenerallyperformedbysome formofdierentialcoding,i.e.bysendingonly thedierencesbetweentwoconsecutiveimages. Thisleadstohighlyvariabletransmissionrates becausetheamountofinformationtocodebetweentwoimagesgreatlyvaries,rangingfrom verylowforstillscenestoveryhighforsequences withmanyscenechanges.packetswitchednetworkssuchastheinternetareverywellsuited fortransmittingsuchvariablebitratetrac[8]. T.TurlettiandC.HuitemaarewithINRIA,SophiaAntipolis,France. However,videoconferencingrequiresaminimum levelofqualityandtheinternetdoesnotprovidesuchqualityofservice(qos)guarantees yet.nevertheless,weshowthatitispossible toobtaingoodqualityusingcontrolcongestion mechanismstopreventclobberingoftheshared resources. Onecanndmanyvideocompressionalgorithmsintheliterature.Someofthemhavebeen standardizedsuchasjpeg[2]forstillimages, ormpeg[18]andh.261[25],[19]formoving images.mpeg-1codingissuitedforhighdenitionvideostorageandretrieval[20].mpeg-2 extendsmpeg-1tohighdenitiontelevision Coding(HDTV)applications[21]. TheH.261standarddescribesacomplexvideo compressionalgorithmwhichallowstoachievea veryhighcompressionrate1.thisstandardwas designedforuseovertheintegratedservicesdigitalnetwork(isdn),i.e.foranetworkwithxed ratechannels(p64kb=s,p2[1;32]).wehave implementedasoftwareversionofanh.261codec foruseovertheinternet.thisimplementationis thecoreoftheinriavideoconferencingsystem (ivs)[31].byadoptingastandardizedalgorithm, ivscaneasilyinteroperate2withalargenumber ofh.261-basedcommercialvideocodecs[14]. However,thisstandardisnotdesignedfora packetswitchednetworkssuchastheinternet. SincetheInternetdoesnotprovidethesameQuality-of-Service(QoS)asISDN,weproposeaset ofschemestoadapttheh.261videocompression algorithmtothisenvironment.inthispaper,we describeapacketizationscheme,anerrorcontrol schemeandanoutputratecontrolschemewhich adaptstheimagecodingprocessaccordingtothe networkconditions. 1H.261videocompressionratecanbeeasilyadjusted,see section5.3. 2Seealsotheon-linehtmldocument<http://www-.cs.ucl.ac.uk/mice/codecmanual/doc.html>. 1
Thesethreeschemesarerespectivelydeveloped insections3,4and5.section6evaluatestheperformancesofivs.section7concludesthepaper. 2RelativeWork WithouttheIPmulticasttechnology[10],theset ofvideoconferencingtoolsrecentlydevelopedin thenetworkresearchcommunitycouldneverbe widelyadopted.ipmulticasttechnologyextends thetraditionaliproutingmodelbyprovidingan ecientmulti-partypacketdelivery.theincrementaldeploymentofipmulticasthasbeenrealizedthroughthemulticastbackbone(mbone),a virtualmulticastnetworkbuiltontopthecurrent Internet[6],[26]. ivsisnottheonlyvideoconferencingapplicationusedbythembonecommunity.atthesame timewhenwedevelopedivs,ronfrederickfrom XeroxParcwasdevelopingtheNetworkVideo tool(nv).morerecently,stevemccanneatucb- /LBLdevelopedthevicvideoconferencingtool. nvusesacustomcodingschemetailoredforthe Internetandtargetedforecientsoftwareimplementation[11].Itscompressionalgorithmis basedonahaartransform,alowcomputational complexitytransformcomparedtothediscrete CosineTransformusedinH.261.Inspiteofa lowercompressionrateperformance,nvcoding ispreferedbythembonecommunitymainlybecauseofitsbetterrun-timeperformances. vichasbeenbuiltuponthelessonslearned frombothivsandnv[27].itisaexibleapplicationwhichsupportsmultiplenetworkabstractionsandseveralvideocompressionalgorithms. viccaninteroperatewithbothivsandnv.vic's H.261encoderusesonlyINTRA3encodingmode whichgreatlysimpliesthealgorithmandimprovestherun-timeperformances(inspiteofa lowercompressionrateachievedasshowninfigure17). Allthesevideoconferencingtoolsareregularly improvedandupgradedversionsareavailablein thepublicdomain.currently,ivsistheonly videoconferencingtoolwhichimplementsacontrolcongestionalgorithmbyadaptingitsoutput ratetothenetworkconditions. 3Seedenitioninsection3.1. 3TheH.261packetization scheme WerstgiveabriefoverviewoftheH.261video compressionstandardinordertobetterunderstandthefollowingsections. 3.1OverviewoftheITU-TrecommendationH.261 TheH.261recommendationdescribesacodec schemetouseforaudiovisualservicesatp64 kb/s(p=1;2;:::;30).anh.261coderanalyses thesuccessiveimagesofthevideostreamassets ofblocksof88pixels.thealgorithmcanbedecomposedinseveralsteps:movementdetection, DiscreteCosineTransform(DCT),Quantization andhumanencoding. Afterperformingmovementdetection,thecodercaneitherdecidetoencodethedierencebetweentheblockanditspreviousencoded/decoded occurrence,or,ifthereisnotenoughcorrelation, tosimplyencodethenewvalue.thisisrespectivelyreferredasinter-framesandintra-framescoding.intra-codedcodesrelyonlyon theredundancywithinasinglevideoframewhen inter-codedcodealsousesthetemporalredundancyofvideotoperformcompression.infact, H.261doesnottransmitdirectlythepixelvalues orthedierences,butratherthecoecientsof theirdiscretecosinetransform(dct)[22].once transformed,thesecoecientsarethenquantized andhumanencodedbeforeactualtransmission. ThecoderschemeisshowninFigure1. TheH.261layers TheH.261codingisorganizedasahierarchyof groupings.thevideostreamiscomposedofa sequenceofimages(orpictures)whicharethemselvesorganizedasasetofgroupsofblocks (GOB)(seeFigure2).NotethatH.261\pictures"arereferredas\frames"inthisdocument. EachGOBholdsasetof3linesof11macro blocks(mb).eachmbcarriesinformationona groupof16x16pixels:luminanceinformationis speciedfor4blocksof8x8pixels,whilechrominanceinformationisgivenbytwo\red"and \blue"colordierencecomponentsataresolutionofonly8x8pixels.thesecomponentsand thecodesrepresentingtheirsampledvaluesareas 2
Figure1:BasicH.261codingloop Intraframe coding DCT AttheGOBlevel,onespeciestheGOB Quantization Huffman Movement Encoding numberandthedefaultquantierthatwill H.261 Detection video Raw video Interframe coding data Picture Inverse Inverse Memory DCT Quantization Picture Picture GOB data... Layer Header GOB data GOB andquartercif(qcif).thereare12gobs denedintheitu-rrecommendation601[7]. Twomainsizesofimagesaredened:CIF4 Figure2:H.261layers 3.2Considerationsforpacketization AttheMBlevel,onespecieswhichblocks optionallyaquantizerandmotionvectors. arepresentandwhichhavenotchanged,and beusedforthembs. MB data... Layer MB data Header foracifpictureand3foraqcifpictureas showninfigure3. circuitsproduceabitstreamcomposedofseverallevelsofencodingspeciedbyh.261and overtheinternet H.261codecsdesignedforoperationoverISDN companionrecommendations.thebitsresulting MB MB B data... Layer B data Header B Transform coefficients EOB Layer anaudiostreamandtransmittedoverp64kb/s code.the512-bitframesaretheninterlacedwith 492bitsofdataand18bitsoferrorcorrecting fromthehumanencodingarearrangedin512- bitframes,containing2bitsofsynchronization, circuitsaccordingtospecicationh.221[24]. Figure3:GOBsarrangementinCIFandQCIF requiresadierentapproach.forinstance,an application-levelerrorcontrolschemeismoreef- TransmittingavideoowacrosstheInternet 352 pixels Thisgroupingisusedtospecifyinformationat 1 2 176 pixels eachlevelofthehierarchy: 3 4 1 144 5 6 3 pixels Attheframelevel,onespeciesinformation 288 7 8 pixels suchasthedelayversusthepreviousframe, 5 9 10 theimageformat,andvariousindicators. 11 12 UIT;itisaninterchangeformatforvideoimageswith288 4CIFistheCommonInterchangeFormatdenedbythe ure4. overisdnandh.261overipisdepictedinfig- (seesection3.3).acomparisonbetweenh.261 beprovidedbytherealtimeprotocol(rtp) cientthanthe512-bitframing(seesection4). mostofmultimediaapplicationrequirementscan Similarly,insteadofusingtheH.221framing, DirectlytransmittingtheresultoftheHuman lineswith352pixelsperlineofluminanceand144lineswith 176pixelsperlineofchrominanceinformation. presentinthegobheadertodecodethembs. todecodethegobs,aswellastheinformation tureofh.261bitstreamisthatoneneedstore- ceivetheinformationpresentintheframeheader gramswouldhaveverypoorerrorresistancechar- encodingoveranunreliablestreamofudpdataacteristics.theresultofthehierarchicalstruc- 3
H.261 H.261 RTP UDP IP H.221 ISDN H.261 Figure4:H.261overISDNvsH.261overIP However,avideoimage(orevenaGOB)can sometimesbebiggerthanthemaximaltransmissionunit(mtu)5.theh.261recommendation speciesthatthemaximalsizeofacifimage is32kbytes(whichmeans3kbytesforagob, 90bytesforaMBand15bytesforablock).In practice,weobservethattheh.261imagesizeis highlyvariableaccordingtothequantityofmovementsanddetailsintheencodedscene:itvaries fromafewbytestoabouttwentykbytes.first versionsoftheh.261packetizationschemeused agobunitoffragmentation.toachievebetterperformancesonlossyenvironment,thelatest versionofthepacketizationschemetakesthemb asunitoffragmentation.inthescheme,packetsmuststartandendonanmbboundary,i.e. anmbcannotbesplitacrossmultiplepackets. MultipleMBscanbecarriedinasinglepacket whentheytwithinthemaximalpacketsizeallowed.thispracticeisrecommendedtoreduce thepacketsendrateandpacketoverhead. InthespiritoftheApplicationLevelFraming (ALF)model[9],theH.261packetizationscheme allowseachpacketreceivedatthedecodertobe processedindependently.toprovideanecient resynchronizationinthepresenceofpacketloss, alltheinformationrequiredtodecodeanmb independentlyissentinaspecicrtp-h.261 headerconjoinedtotheh.261data.thisheader includesthegobnumberineectatthestart ofthepacket,areferencetothepreviousmbencodedinthisgob,thequantizervalueineect priortothestartofthispacketandthereference MotionVectorData(MVD)forcomputingthe truemvdscontainedwithinthispacket. Moreover,sincethecompressedMBmaynot llanintegernumberofoctets,theh.261header containstwothree-bitintegers,sbitandebit, 5TheMTUsizedependsonthenetwork:e.g.itis1536 bytesforanethernetnetworkanditcanbeaslowas576 bytesfortheinternet. toindicatethenumberofunusedbitsintherst andlastoctetsoftheh.261data,respectively. 3.3OverviewofRTP TheRealTimeProtocol(RTP)aimstosatisfy theneedsofmulti-partymultimediaapplications: source-identier,content-identier,timestamp, demultiplexing,etc[29].moreover,rtpallows interoperabilitybetweentheexistingmbone tools. TheRTPspecicationdescribesaverythin transportprotocolwhichisthemostoftenintegratedintotheapplicationprocessingratherthan beingimplementedasaseparatelayer.thisisin accordancewiththeapplicationlayerframing (ALF)spirit[9].IntheIPprotocolstack,RTP issituatedontopofudp(seefigure4).asa matteroffact,thertpspecicationdescribes twoprotocols:thedatatransferprotocol(rtp) andthecontrolprotocol(rtcp). EachRTPdatapacketiscomposedofanRTP headerfollowedbythertppayload(i.e.the data).thertpheadercontainsasequencenumber,amedia-specictimestampandasynchronizationsourcepacketidentier(ssrc).receiversdemultiplexpacketsusingthessrcwhich isgloballyuniquewithinanrtpsession. TheRTPcontrolprotocol(RTCP)manages controlinformationprovidingmechanismsfordatadistributionmonitoring,cross-mediasynchronizationandsenderidentication.rtcppackets aretransmittedperiodicallytoallparticipantsin thesessionandtheperiodisadjustedaccording tothesizeofthesession.inthisway,thertcp bandwidthislimitedinordertoavoidthenack explosionproblem. 3.4Specicationofthepacketizationscheme TheH.261informationiscarriedaspayloaddata withinthertpprotocol.thefollowingeldsof thertpheaderarespecied: ThepayloadtypeshouldspecifyH.261payloadformat(seethecompanionRTPprole documentrfc1890). TheRTPtimestampencodesthesampling instantoftherstvideoimagecontained inthertpdatapacket.ifavideoimage 4
occupiesmorethanonepacket,thetimestampwillbethesameonallofthosepackets. Packetsfromdierentvideoimagesmusthave dierenttimestampssothatframesmaybe distinguishedbythetimestamp.forh.261 videostreams,thertptimestampisbased ona90khzclock:thisclockrateisamultipleofthenaturalh.261framerate(i.e. 30000/1001,orapproximatively29.97Hz). Thatway,theclockissimplyincremented bythemultipleforeachframetime. ThemarkerbitoftheRTPheaderissetto oneinthelastpacketofavideoframe,and otherwise,mustbezero.thus,itisnotnecessarytowaitforafollowingpacket(which containsthestartcodethatterminatesthe currentframe)todetectthatanewframe shouldbedisplayed. TheRTP-H.261headerwillfollowtheRTPheader andprecedestheh.261dataasshowningure 5:TheeldsintheRTP-H.261headerhavethe followingmeanings: Startbitposition(SBIT) Numberofbitsthatshouldbeignoredinthe rstdataoctet. Endbitposition(EBIT) Numberofbitsthatshouldbeignoredinthe lastdataoctet. INTRA-frameencodeddata(I) Setto1ifthisstreamcontainsonlyINTRAframecodedblocks.Setto0ifthisstream mayormaynotcontainintra-framecoded blocks. Motionvectorag(V) Setto0ifmotionvectorsarenotusedin thisstream.setto1ifmotionvectorsmay ormaynotbeusedinthisstream. GOBnumber(GOBN) EncodestheGOBnumberineectatthe startofthepacket.setto0ifthepacket beginswithagobheader. Macroblockaddresspredictor(MBAP) Encodesthemacro-blockaddresspredictor (i.e.thelastmbaencodedintheprevious packet). Quantizer(QUANT) Quantizervalueineectpriortothestart ofthispacket.setto0ifthepacketbegins withagobheader. Horizontalmotionvectordata(HMVD) Referencehorizontalmotionvectordata (MVD).Setto0ifVagis0orifthepacket beginswithagobheader,orwhenthemtype ofthelastmbencodedinthepreviouspacket wasnotmotioncompensated.hmvdisencodedasatwo'scomplementnumber. Verticalmotionvectordata(VMVD) Referenceverticalmotionvectordata (MVD).Setto0ifVagis0orifthepacket beginswithagobheader,orwhenthemtype ofthelastmbencodedinthepreviouspacket wasnotmotioncompensated.vmvdisencodedasatwo'scomplementnumber. Recommendationsforhardwarecodecs PacketizersforhardwarecodecscantriviallygureoutGOBboundariesusingtheGOB-start patternincludedintheh.261data.thecheapest packetizationimplementationconsiststosplitthe videoowatthegoblevelbysendinganentire numberofgobsinapacket.butwhenagob istoolarge,thepacketizerhastoparseitinordertoperformmbfragmentation.notethatthis requiresrelativelylittleprocessingsinceitisnot necessarytofullydecompresstheh.261stream tollintheh.261specicheader.however,we recommendtousemblevelfragmentationwhen feasibleinordertoreducetheoutputpacketrate andthereforedecreasetheoverhead. Atthereceiver,thedatastreamcanbedepacketizedanddirectedtoahardwarecodec'sinput. Ifthehardwaredecoderoperatesataxedbit rate,synchronizationmaybemaintainedbyinsertingthestungpatternbetweenmbs(i.e., betweenpackets)whenthepacketarrivalrateis slowerthanthebitrate. ThepacketizationschemedescribedinthissectioniscurrentlyproposedasstandardtotheAudio-VideoTransportWorkingGroup(AVT-WG) attheinternetengineeringtaskforce(ietf) [32]. 4Theerrorcontrolscheme Errorsinavideostreamrequireadierentform ofcorrectionthanerrorsinanormaldatastream. Teststransmittingvideostreamoverastandard TCPconnectionallowedustotransmitdataover 5
RTP Header SBIT EBIT I V GOBN MBAP QUANT HMVD VMVD } RTP H.261 arenotacceptableforreal-timeapplicationssuch Figure5:TheH.261headerformat Header asvideoconferencing.itismoreconvenienttouse theinternetwithoutconcernoflostorout-ofsequencepacketsbecauseoftcpreliability[15]. UDPandconstructapplicationspecicreliability However,retransmissionintroducesdelayswhich Video Stream services. arenotintraencoded.thereareseveralways tocongestionratherthantransmissionerrors[3], [28].Alternatively,packetscanbedelayedorreceivedoutoforder.Thiscouldhappenasarework.Duetoreal-timerequirements,delayesultoftheroutingandowcontrolinthenet- videopacketsareconsideredaslostpacketsif OntheInternet,mostpacketlossesaredue nishment7.intracodingismuchlessecient tomitigatepacketloss: RemovingtheINTERcodingwillresultinsignificantlydecreaseofthecompressionratio8frameencodingandMBlevelconditionalreple- thanintercodingbecausealargeamountof ThesafestwayconsiststouseonlyINTRA- delayexceedsamaximumdelayvalue6.using knowifapackethasbeensuccessfullyreceived. UDP,nomechanismisavailableatthesenderto INTRAmode,onlytheMBsconcernedbythe temporalredundancyexistsinimagesequences. Amoreecientwayconsiststoreplenish,in sequencenumbereldandtimestamparestored. Thesequencenumberisincrementedbyonefor outoforderpackets. coder)tohandlepacketlossandre-sequencingof Itisuptotheapplication(i.e.coderandde- eachpacketsentwhereasthetimestampreects thetimewhentheframewasgrabbed.packet lossescanbedetectedusingthertpsequence number. EachRTPpacketincludesaheaderinwhicha \NegativeAcknowledgement"(NACK)packetis loss.asallgobbelongingtoagivenvideo moreecientthanrequestingacompleterefresh- imagecarrythesametimestamp,thereceiver mentoftheimagethrougha\fullintrare- quest"(fir)packet.figure6showsthenack ferentpackets.whenthedecodernoticesthatit didn'treceivepacketb,itsendsanackpacket tothecoder.thenackinformationmeansthat \GOB3,imagenislost."Theencoderwillput allthembencodedinthelostpacketbinto packete,usingintramode.actually,this receivedforthattimestampandthusidentifyinitializationofthesemissingblocksthrougha candeterminealistofgobswhichwerereally emissionafterapacketloss.inthisexample,the ingthemissingblocks.requestingaspecicre- calledmissamerica.theimageontheleftshows isthatdierentialcoding(orintercoding)is dancyofvideotoperformcompression.thepoint cal\headandshoulders"videosequenceusually theeectofpacketlossoneimageaftertheloss sensitivetopacketloss.figure7showsaclassi- TheH.261algorithmusesthetemporalredun- coderusesqcifandallgobsaresentindif- headwasmovingtotheright.wenotethata tually,thepartofimageaectedbythelosswill remainblurredaslongasallcorrespondingmbs lotofblocksaroundthefacearecorrupted.ac- occured.inthisexperiment,themissamerica's isaforcedreplenishmentandnotaretransmissionprocedurebecauseencodingoccursforanew frameandnotforthepreviouslostframe.the replenishmentprocedure9.however,thenackbasedmethodcanleadtothefeedbackexplosion leftimageonfigure7showstheimageafterthe ivs. 6Themaximumdelayvalueisempiricallysetto100msin experiment). ingtool. pressionrationbyabout30%,seefigure17. tertheblurredimage(i.e.300msafterforthis10f/s 8WeestimatethattheINTERmodeincreasesthecom- 9Inthiscase,thereplenishmenthappened3imagesaf- 7Thismethodiscurrentlyusedbythevicvideoconferenc- 6
Figure7:INTRArefreshmentafterNACKreceipt sizeofthesession:weempiricallysetthethresholdto10participants.whentherearelessthan lossrateinformation10. INTRArefreshmentrateisadaptedtothenetworkcongestionstate.Letusexaminewhatit ivsimplementsthesecondandthethirdmeth- 10receivers,NACKspacketsareused.Else,the meansintermofbandwidth.thetwoextreme ods,andthemethodisselectedaccordingtothe Decoder participantsgeneratenackspacketseachtime problemwhenreceiversaretoonumerous.ifall apacketislost,networkcongestionproblemswill Figure6:DataandNACKpackets andthe\chain"networktopologies,seefigure8. Inthefollowinganalysis,pistheaveragepacket casesformulticastingdistributionarethestar error,theh.261recommendationrequirestoin- ofaccumulationofinversetransformmismatch theimageinintraencodingmode.forcontrol codecsarenotdesignedtoacceptnackpackets. appearverysoon.also,regularhardwareh.261 132timesitistransmitted.Inordertospeed TRAencodingofeachMBatleastonceevery therecoveryprocedure,thecodercanadaptthe Athirdwayconsiststoperiodicallyrefresh lossobservedbyreceivers,risthenumberofreceiversinthesessionandnisthenumberofdata Figure8:StarandChainnetworktopologies starnetwork,duringthetintervaloftime,(rn) packetssentduringthetintervaloftime.inthe INTRArefreshmentrateaccordingtothepacket are(n)and(prn)forachainnetwork,respectively.then,theproportionofnackpacketsto packetsaresentbythereceivers.thenumbers packetsaresentbythesenderand(prn)nack 7thepacketlossratetheyobserve[5]. 10Receiverscanperiodicallysendbacktothevideocoder Image n Image n+1 Coder Packet A (GOB 1) Packet B (GOB 3) Packet C (GOB 5) Packet D (GOB 1) Packet E (GOB 3) Packet F (GOB 5) NACK (Image n, GOB 3) R 1 R 2 R R S R 3 S R R R R 1 2 3 R
datapacketsiswithintheinterval[p;pr].the correspondingbandwidthproportionmusttake intoaccountthelengthofthedataandfeedback packets.withanaverageof500-bytesperdata packetand12bytespernackpacketsent,the proportionofbandwidthusedbythefeedback channeliswithintheinterval[12 500p;12 500pR].In ivs,themaximalrvalueis10.forexample,if thesessionhastenparticipantsandiftheaveragepacketlossrateis20%,thecorresponding feedbacktracremainsbelow5%ofthedata trac(between0.48and4.8%dependingonthe networktopology). 5Thecongestioncontrol scheme VideoconferenceontheInternetcouldwellbea \killerapplication";thenetworkadministrators nightmaresareprobablyalreadypopulatedby thousandsofhostsallsendingmegabitsofvideos overthenetandswampingthet3basedbackbones.thetextbooksolutionforcontrolling videooverthenetworkiscalled\resourcereservation,"generallycombinedwith\admissioncontrol."toputitshortly,whoeverwantstostart avideotransmissionissupposedtoaskforpermissionrst,requestingacertainamountofresources.itisassumedthatthecharacteristicsof thedataowisknownbeforestartingthesessionandthatthenetworkhasenoughknowledge todecideifsuchaowshouldbeadmittedornot. Thereisoneadvantagetothismodel:onceaccepted,onehasaguaranteedQoS.Butthereare alsomanydrawbacks,liketheneedtocoupleadmissionwithaccounting,theneedtoenforcecomplexreservationschemes,and,lastbutnotleast, theneedtointroduceavirtualcircuitphilosophy inanotherwisepurelydatagramnetwork.intensiveworkiscurrentlyinprogressintheietfto provideinternetapplicationstheqosrequired fortheirdataows(seethereservationsetup Protocol(RSVP)[34]).However,sincesuchresourcereservationarenotyetcurrentlydeployed, weinvestigatedanothersolution,tryingtovalidate,forvideo,the\endtoend"controlmodel thathadbeensosuccessfulforclassicdataexchange. Endtoendcontrolneedstwocomponents:a networksensorandathroughputcontroller.feedbackmechanismsforvideosourceshavebeenproposedfornetworkswithvariablecapacitychannelssuchastheinternet.there,thegoalistoadjusttheparameters(andhencetheoutputrate) ofvideocodersbasedonfeedbackinformation aboutchangingnetworkconditions,i.e.changing capacityinthenetwork.gilgeandal.propose tousefeedbackcontrol,buttheydonotdescribe speciccontrolmechanisms[12].wakemanat UCLdescribesaspecicscheme[33].However, thisschemerequiresthatthesourceofaconnectionknowstheservicerateofthebottleneck onthisconnection.thisserviceratecanbeestimatedinnetworkswheretheswitchesusea so-calledfairqueueingorequivalentdiscipline, forexampleusingthepacketpairmechanismdescribedin[17].however,itisnotavailablein networkswithfcfsswitchessuchastheinternet.otherwork[16]describesafeedbackcontrol schemewhichrequiresthatswitchessendtheir bueroccupanciesandserviceratesbacktothe source.nextwedescribethenetworksensorand thethroughputcontrollerimplementedinivs.11 5.1Thenetworksensor TheInternetinfrastructuredoesnotprovidesourcesoftracwithexplicitfeedbackinformation aboutthestateofthenetwork(e.g.queueoccupanciesattheswitches).theonlyeasilyavailableinformationisimplicitinformationsuchas measuresoflossesand/orround-tripdelays.in ivs,weuseafeedbackinformationwhichisbased onmeasuredpacketlosses. Inordertomonitorhowmanyvideopackets arriveattheirdestinationsviamulticasting,a sourceshouldobtaininformationfromeachreceiverindicatingpacketlossonthepathfromthe sourcetothatreceiver.onepossibleapproachis toleteachreceiversendanackpacketwheneveritdetectsaloss.however,thiscanleadto thewell-knownnackexplosionwhenthenetworkiscongested.anotherapproachconsiststo periodicallysendaqualityofservice(qos)measurewhichisthepacketlossrateobservedby receiversduringatimeintervaloflengtht.we refertotastheaveraginginterval.inivs,we takettobethetimerequiredatareceiver12to get100packets.assuggestedinthertpdraft 11Amoredetaileddescriptioncanbefoundin[4]. 12Observethatintervalslengthsmightbeslightlydierent fordierentreceivers. 8
minutes. sendsfeedbackinformationatleastonceevery2 document,wealsomakesurethateachreceiver sagebyarandomamountoftimedrawnfrom network,eachreceiverdelaysitsfeedbackmes- decreasetheimpactoffeedbacktraconthe mostalwaysthecaseontheinternet.tofurther packetlossrateishigherthan1%,whichisal- cientthanthenackapproachassoonasthe ItisclearthattheQoSapproachismoreeftothesourceusingRTP13.Thenthesourceconbackatthesametimewhichcouldcreateperiodic topreventreceiversfromsendingbacktheirfeed- congestiononthenetwork. therange[0:::t].thistechniqueisemployed vertsthedierentmeasuresofqosintoa\global" thereceivers.ourapproachistousethemedian measurecharacterizinghowwellpacketsarriveat lossrate. Eachreceiversendsitsmeasuredlossrateback 5.2Thethroughputcontroller backinformationiscomputedatthereceivers. matelyequaltotheintervaloverwhichthefeed- cretepointsintime,specicallywheneverase- quenceof100packetshasbeenencodedandsent. intervalbetweensuccessivecontrolsisapproxi- Ofcourse,thenumber100ischosensothatthe Controlactionsaretakenbythecoderatdis- adjuststhemaximumoutputrateofthecoder maxratesothatthemedianlossratestaysbelowatolerablelossrate.themedianlossrateis denotedbymedloss,andthetolerablelossrate Duringacontrolaction,thecontrolalgorithm bytolloss.specically,maxrateisdecreased byafactoroftwoifthemedianlossrateislarger thantolloss.otherwise,itisincreasedbyaxed fractionofitscurrentvalue.wealsomakesure thattheoutputrateisalwayslargerthansome minimumratetoguaranteeaminimumquality expectedtoeitherobtainmoreresourcethrough somereservationmechanism,orleavetheconference. whoseconnectionshaveaninsucientqualityare ofthevideoconferenceatthereceivers.receivers information[29]. 13TheRTPspecicationprovidesaframeworktosendQoS Thus,thecontrolalgorithmisasfollows: if(medloss>tolloss) 9 valueofmaxrateto100kb/s.intheseexperiments,thevideosourceisanivssourceatinriaceiverssendqospacketsperiodicallybacktothe source.weanalyzetheconnectionbetweenthe mentisa\largemulticast"environment,i.e.re- INRIAisamulticastconnection,i.e.thepackceiveratUniversityCollegeLondon(UCL).Note ivssourceatinriasophiaantipolisandare- howeverthattheconnectionbetweenucland etssentovertheconnectionarecarriedoverthe MBone.Atthistime14,themulticastpathfrom FrancetoGreatBritaingoesthroughCERNin Inivs,wesetminrate=10kb/s,gain=1:5, andtolloss=10%.wealsosetthemaximum else maxrate=gainmaxrate; maxrate=max(maxrate=2;minrate); Thenumberofreceiversissuchthattheenviron- onthex-axisistheframenumber,theaverage ceiver(dashedline)during20minutes.theunit andtheaveragepacketlosscomputedatthere- GenevaandAmsterdamintheNetherlands. frameratewasabout4imagespersecond. outputratemaxrateatthesource(plainline) Figure9showstheevolutionofthemaximum 100 "ratemax_pq_tole5" "loss_pq_tole5" 80 Figure9:Evolutionsofmaxrate(inkb/s)and 60 40 20 detectedatthereceiver.whenthepacketloss thelossrateatthereceiver(in%). 0 decreasedbyhalf.then,theivsvideosourceis rateishigherthan10%,themaxratevalueis maxrateatthesourcedecreasesaslossesare Asexpected,weobservethatthevalueof 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 14ThisexperimenthasbeenmadeinOctober1993.
abletoadaptitsoutputratetothenetworkconditionsobserved. ratecanbeadjustedinh.261codecsandtheway information.next,wedescribehowtheoutput ofthecoderisadjustedbasedonthefeedback usedinivs,i.e.howthemaximumoutputrate itisimplementedinivs. Wehavedescribedabovethecontrolalgorithm SeveralparametersofaH.261codercanbeadjustedtochangetheoutputrateofthecoder. codec 5.3OutputratecontrolforH.261 isonlyappropriatewhentherefreshmentrateis Theeasiestmethodconsistsofmodifyingtheframerateoftheapplication.However,thissolutiorienceshowsthattherenditionofmovementis oftenaveryimportantrequirement. notakeyparameteroftheapplication:expe- istoadjustthevalueofthequantizer.byusing onereducestheprecisionoftheimage{thisis alooserquantizationfactorforthecoecients, approximatelyequivalenttoreducingthenumberofbitsperpixel.theresultingcoecients arelessvariablethantheoriginalvalues,andre- Asecondwaytocontroltheoutputofthecoder sultinfewerencodingbitsafterimagecompres- sion.however,whenthequantizervalueisset toohigh,theimagebecomesblurredduringthese changes. coderasafunctionofthequantizer.theseresultshavebeenobtainedforthewellknown\misure5.3). quantizerdecreases,theoutputrateofthecoder increasesandsodoestheimagequality(seefig- America"test-sequence.Whenthevalueofthe Figure12showsthattheoutputrateofthe foreachimage.thiscanbedonebyraisingthe reducethenumberofblockswhichareencoded controlsthenumberoftheblockswhichare\suf- thethresholdvalueincreases,thenthenumber cientlydierent"fromthepreviousframe.if movementdetectionthreshold.thisthreshold Athirdwaytoreducethedatarateistosimply toencodeeachimagedecreases.increasingthe thresholddecreasesthesensitivityofthecoderto movementandhenceyieldsalowerqualityimage. codingtimeandthenumberofbytesrequired ofblockstoprocessdecreasesandhencetheen- 10 rate (kb/s) 80.00 quantizer = 3 quantizer = 7 quantizer = 11 70.00 60.00 samevideosequenceusingdierentquantizers Figure12:Outputrate(kb/s)vsframefora 50.00 40.00 30.00 20.00 10.00 ratestaysbelowmaxrate.15 temodes.themodecharacterizeswhatparame- tersareadjustedinthecodersothattheoutput Withinivs,theusercanselecttwodierent modes:privilegequalityandprivilegeframera- 0.00 PrivilegeQuality(PQ)modeisconvenientfor 0 10 20 30 40 50 60 70 thresholdareconstantandmatchthemaximal applicationswhichrequirehighprecisioninthe slidesorstillimages).inthismode,thevaluesofthequantizerandthemovementdetection renditionofindividualimages(e.g.totransmit nientwhentheperceptionofmovementisaim- visualquality.thenthecoderwaitsforasuportantfactorofquality.theoutputrateiscontrolledusingdierentquantizerandmovement couplethequantizerwiththemovementdetec- PrivilegeFrameRate(PFR)modeisconvecientamountoftimebeforeencodingthefollowingimagesothattheoutputratestaysbelowthe detectionthresholdvalues.wehavedecidedto maxratevalue. tionthresholdusingempiricalset-ups. variablessincewhenthequantizerincreases,the creases.thestateofthecodec,inpfrmode,is precisionoftherenditiondecreases,andthelikelinessofalargedierencebetweentwoframesin- characterizedbythetargetdataratemaxrate Actually,itislegitimatetocouplethesetwo trolcongestionalgorithm. 15Themaxratevalueisadjustableontheybythecon-
Figure10:CIFimageencodedwithquantizervalues3(left)and7(right) severalpairs(quantizer,threshold)havebeenpreselectedinordertohavealinearvariationofthe andacoupleofquantizeranddetectorvalues: outputrate.thisselectionhasbeenobtained Figure11:CIFimageencodedwithaquantizervalueof11 tween3and13,andthethresholdbetween10 and35. byexperimentationrestrictingthequantizerbeteresisof30%ofthemaximumbandwidthdamps downtheoutputrate.iftheinstantaneousrate ratemeasuredisincludedinthisband,thecouplingispreserved.experimentsshowthathysteresisisrequiredtopreventundesirableoscillationsinthecontrolloop.iftheinstantaneous Sincetheoutputrateisrapidlyvarying,hysneousrateandthemaximumbandwidthallowed. accordingtothedierencebetweentheinstanta- isoutsidethisband,thenanewcoupleischosen sequence. sequenceismoreanimatedthantherestofthe uesofthebandwidth.therstquarterofthe ingapre-digitizedsequenceof200frames,with QCIFencodingformatandthreedierentval- Thefollowingdiagramshavebeenobtainedus- 11Figures13,14and15showtheinstantaneous
Instantaneousrate(kb/s) Quantizervalue Figure13:Outputrateandquantizervaluevsframenumberformaxrate=10kb/s "Rate.qcif.10" Figure14:Outputrateandquantizervaluevsframenumberformaxrate=30kb/s 30kb/sand50kb/s,respectively.Figure16shows thesignal-to-noiseratio(snr)obtainedforthesethreeexperiments. rateandthequantizerwithmaxrate=10kb/s, Figure15:Outputrateandquantizervaluevsframenumberformaxrate=50kb/s pressedindbasshowninequations(1). SNR=?10log(MSE),with: TheSNRisamean-squareerrormeasureex- valueofthispixelafterencoding/decodingand ofthepixel(j;k),^g(j;k)denotestheluminance MSE=1 whereg(j;k)denotestheoriginalluminancevalue JKPJj=1PKk=1[G(j;k)?^G(j;k)]2 A2 (1) proportionaltotheoutputrateandthatthequalityoftheimage(snr)isinverselyproportional tothequantizerselected.notealsothatthe teroftheexperimentbecausethevideosequence ismoreanimated,requiringmoreinformationto quantizerselectedislargerduringtherstquar- Notethatthequantizerselectedisinversely encode. AdenotesthemaximumvalueofG(j;k). 126Performance TheoutputdataowgeneratedbytheH.261 coderisnon-stationaryandrapidlyvarying.it 60 50 40 30 20 10 0 0 50 100 150 200 60 50 40 30 20 10 "Rate.qcif.30" 0 0 50 100 150 200 60 50 40 30 20 10 "Rate.qcif.50" 0 0 50 100 150 200 14 12 10 8 6 4 2 "Quantizer.qcif.10" 0 0 50 100 150 200 14 12 10 8 6 4 2 "Quantizer.qcif.30" 0 0 50 100 150 200 14 12 10 8 6 4 2 "Quantizer.qcif.50" 0 0 50 100 150 200
40 38 "SNR.qcif.10" "SNR.qcif.30" "SNR.qcif.50" 36 34 32 dependsonthequalityofthevideocameraand threeexperiments10,30and50kb/s Figure16:SNR(dB)vsframenumberforthe 28 0 100 150 200 thetypeoftheimagesbeingencoded,ascharacterizedbythenumberofscenechanges,thescene structure,thescenelighting,etc.italsodepends machine. SPARCIPXworkstation,withcodinganddecodingprocessesrunningonthesamephysical Thefollowingexperimentshavebeenmadeona eration:thecomputationpowerofourcodecs. Wealsohavetotakeanotherelementinconsid- onthedenitionoftheimages:ciforqcif. Format Expt.16.01.5 Expt.24.0 Unit(f/s)(kb/s)(f/s)(kb/s) QCIF13 2.0 3.61.5 CIF thereisnomovement,onlygrabbingandmovementdetectionhavetobeprocessed.so,the Therstexperimentiswithastillimage.When Expt.31.9 24 0.5 16 speedlimitationismainlyduetotheunderlyinghardware,inourcasethevideopixboard 25 solutelynomovement,weonlyencodeforeach framethepictureandgobheaders. attachedtothesparcstation.whenthereisab- rateishighlydependentontheimagesize,while classicvideoconferencingimage,i.e.headand shouldersmoving.wecanobservethattheframe theoutputrateremainsalmostconstant:this Thesecondexperimentischaracteristicofa 13 ischaracteristicofacpuboundapplication.in fact,themostdemandingpartofthecodecisthe computationofthedctcoecients;thepower ingvideoscene.insuchacase,fullintra mittedandthenumberofbitssentonthelines. ofthecpudirectlylimitsthenumberofblocks thatcanbecomputedpersecond,hencelimiting cumulationoferrorsfromintermodeencod- ing.intramodeencodingusageincreasesthe byblocks.imageratedecreasesbecauseallthe outputratebecausemorecoecientsareencoded Thethirdexperimentisforarapidlychang- modeencodingischoseninordertosuppressac- thenumberofcoecientsthathavetobetranscessingisnecessary;thedatarateincreasesbecausethecoecientsaremuchmoredispersed blockshavetobeencodedandmorecpupro- frameratedependsonboththevideograbbing remoteteachingapplications.wefoundthatthe mightnotbesuitableforhighqualityvideoor Humancompressionlessecient. thanwithdierentialcoding,whichmakesthe boardandthecpuspeed.therefore,wewould expectmuchbetterperformancewithhigherperformancemachines.toillustratethispoint,we TheframerateshowninTable6islowand measuredtheperformanceofivsonasparcstation20/501(bi-processor275mhz)withthe forivs,nvandviconass10/20(41mips)platformwiththesunvideo17board.thevideoinputsequenceisveryanimated(i.e.allthembs areencodedineachframe)andqcifcolorvideo encodingisselectedwithoutvideodecodingneitherlocaldisplayfunctions.weusedversion2.6 Figure17showstheperformanceobtainedboth VigraPix16board.Onthisplatform,version3.5 ofivsisabletoencode/decodebetween25and30 fpsinqcifandbetween12and30fpsincif. whenthevideosequenceisveryanimated.this thatneitherivsnorviccanreachthisframerate QCIFframespersecondonthisplatform.Note ofvictoencodebothnvandvic-h.261modes isduetothehighcpupowerrequiredforthe andversion3.5ofivs18. H.261compressionalgorithm.Ontheotherhand, TheSunvideoboardallowsgrabbingupto20 nounce.html>. ducts-n-solutions/hw/wstns/sunvideo.html>. ratecontroldisabled. 18Inthisexperiment,ivsisusedwiththeautomaticoutput 17SeeURL<http://www.Sun.COM/cgi-bin/show?pro- 16SeeURL<http://www.vigra.com/products/vigrapix.an-
0 2 4 6 8 10 12 14 16 18 20 0 200 400 600 800 1000 Frame rate (f/s) Output rate (kb/s) "nv" "ivs-q3" "vic-q3" "vic-q13" Figure17:Framerate(f/s)vsoutputrate(kb/s) nvallowsobtainingahigherframerate(inspite ofalowercompressionrate)becauseitusesa lowcomputationalcomplexityalgorithm.note thattheivs-h.261compressionrateisabout30% higherthanvic-h.261compressionratewiththe same(q=3)quantizer.thisisbecauseivsuses theinterencodingmodeontopoftheintra encodingmode.however,theivs-h.261coderis moregreedyofcputhanthevic-h.261[only8.5 framescanbeencodedpersecondinsteadof13 forthesamequantizer(q=3)].finally,wenote thata(q=13)quantizergivesacompressionrate about4timeshigherthana(q=3)quantizer. 7Conclusion Inthispaper,wedescribedavideoconferencing softwareapplicationfortheinternet.thisapplication,availableinthepublicdomain19isused overtheinternettoholdvideoconferences,multicastconferences(e.g.the4thjointeuropean NetworkingconferenceheldinTrondheim,Norway,inMay1993),andweeklyMICE20seminars [14]. Itsmainassetsarethelowbandwidthrequired, thecompatibilitywithhardwarecodecs,andthe newdimensionitbringstoclassicworkstations withouthighcost,sinceminimalhardwareisnec- 19ivssourcesandbinariesareavailableby <ftp://zenon.inria.fr/rodeo/ivs/lastversion>.seealsourl <http://www.inria.fr/rodeo/ivs.html>. 20MICEstandsforMultimediaInternationalConferencing foreuropeanresearchers.miceisaneuropeanproject, whichaimsatprovidingappropriatemultimedia,multipartyconferencingtoresearchersineurope.seealsourl <http://www.cs.ucl.ac.uk/mice/mice.html>. essary.thelowbandwidthrequirementisvery attractive:forinstance,low-qualityvideocanbe sentona9600b/slink.moreover,thefeedback mechanismwedescribedinthispaperallowsivs tobehaveasa\goodnetworkcitizen." Furtherworkisongoingtoimprovethecongestioncontrolalgorithmforaheterogeneousmulticastenvironment.WithintheInternet,thebandwidthavailablebetweenseveralsender-receiver pathscanbeslightlydierent.videogateways canbeusedtoprovidedierentlevelsofvideo quality:anapplication-levelgatewayfortranscodinghardwaremotion-jpeg21toh.261videoow hasbeenrecentlyimplemented[1].however,a smartersolutiontotheproblemofmulticastvideo transmissionoverheterogeneousnetworksconsistsofusingahierarchicalvideocodingscheme. Insuchascheme,thevideoissplitinseveral ows:thebaseowincludesthelowresolution information,whereastheenhancementinformationissentinadditionalows.theideaisto transmitthebaseowtoallthereceiversinthe sessionbuttotransmittheadditionalowsonly touncongestedreceivers.thismethodwillbe ecientontheinternetwhenweareable22to associateahigherprioritytotheessentialbase ow[30].wearecurrentlyworkingonawaveletbasedvideocodingschemewhichweexpectto includeinivs. Acknowledgments WearegratefultoSteveMcCanne,SteveCasnerandMarkHandleyforprovidinghelpfulcommentsontheH.261packetizationscheme.Jean Bolotcontributedtoimprovethecongestioncontrolschemedescribedinthispaper.Wethank themiceresearchteamandthembonecommunitywhohavekindlytestedtheivsimplementation,reportedbugsandprovidedsupportfornew platforms.finally,wewouldliketothankhenry Houhandtheanonymousreviewersfortheirconstructivefeedback. 21Motion-JPEGstandsforJPEGcodingappliedtomovingimages.ItisbasedonINTRAcodingwithoutmovement detection. 22NextIPgeneration(IPng)speciesaprioritymechanism associatedtothepacketssentfromasamesourceusingthe TCLASSeld[23]. 14
References [1]Amir,E.,McCanne,S.,andZhang,H.\An Application-levelVideoGateway",ACM Multimedia'95,SanFrancisco,Nov.1995. [2]AravindR.etal.\Imageandvideocoding standards",at&ttech.journal,pp.67-89, Jan/Feb.1993. [3]Bolot,J.C.\End-to-endpacketdelayand lossbehaviorintheinternet",proc.acm Sigcomm'93,pp.289-298,SanFransisco, CA,Sept.1993. [4]Bolot,J.C.andTurletti,T.\AratecontrolmechanismforpacketvideointheInternet",Proc.IEEEInfocom'94,pp.1216-1223,Toronto,Canada. [5]Bolot,J.C.andTurletti,T.\Scalablefeedbackcontrolformulticastvideodistribution intheinternet",.proc.acmsigcomm'94, Vol.24,No4,pp.58-67,Oct.1994. [6]Casner,S.andDeering,S.\FirstIETFInternetaudiocast",ACMCCR,Vol.22,No 3,July1992. [7]\CCIRrecommendation601-2:Encodingparametersofdigitaltelevisionfor studios",internationaltelecommunication Union,1990. [8]Clark,D.\TheDesignPhilosophyofthe DarpaInternetProtocols",Sigcomm'88 Symposium,pp.106-114,Stanford,CA, Aug.16-19,1988. [9]Clark,D.andTennenhouse,D.L.\Architecturalconsiderationsforanewgeneration ofprotocols",proc.acmsigcomm'90,pp. 200-208,Sept.1990,Philadelphia. [10]Deering,S.\Multicastroutinginadatagraminternetwork",Phddissertation,StanfordUniversity,California,Dec.1991. [11]Frederick,R.\Experienceswithreal-time softwarevideocompression",sixthinterna- tionalworkshopofpacketvideo,pp.f1.1-1.4,portland,or,sept.1994. [12]Gilge,M.andGusella,R.\Motionvideo codingforpacket-switchingnetworks-an integratedapproach",proc.spieconferenceonvisualcommunicationsandimage Processing,Boston,MA,Nov.1991. [13]GuichardJ.,Eude,G.andTexier,N.\State oftheartinpicturecodingforlowbitrate applications",proc.icc'90,pp.120-125. [14]Handley,M.,Kirstein,P.T.andSasse,M.A. \MultimediaintegratedconferencingforEuropeanresearchers(MICE):pilotingactivitiesandtheconferencemanagementand multiplexingcentre",computernetworks andisdnsystems,pp.275-290,vol.26,no 3,Nov.93. [15]Huitema,C.andTurletti,T.\Software codecsandworkstationvideoconferences", ProceedingsofINET'92,pp.501-508,Kobe, Japan. [16]Kanakia,H.,Mishra,P.andReibman,A. \Anadaptivecongestioncontrolschemefor real-timepacketvideotransport",proc. ACMSigcomm'93,pp.20-31,SanFransisco,CA,Sept.1993. [17]Keshav,S.\Acontrol-theoreticapproachto owcontrol",proc.acmsigcomm'91,pp. 1-11,Zurich,Switzerland,Aug.1991. [18]LeGall,D.J.\MPEG:Avideocompressionstandardformultimediaapplications", CommunicationoftheACM,No4,Apr. 1991. [19]Liou,M.\Overviewofthep64kb/s videocodingstandard",communicationof theacm,no4,apr.1991. [20]\Codingofmovingpicturesandassociated audio(mpeg)",iso/iecjtc1sc29. [21]\MPEG2Videostandard",ISO/IEC 13818-2. [22]Rao,K.R.andYip,P.\DiscreteCosine Transform:Algorithms,Advantages,Applications",AcademicPressInc,1990. [23]Bradner,S.andMankin,A.\TherecommendationfortheIPNextGenerationprotocol",RFC1752,Jan.1995. [24]\p64Channelframestructureforaudio/videoconferencing",ITU-TRecommendationH.221,1993. [25]\Videocodecforaudiovisualservicesatp 64kb/s",ITU-TRecommendationH.261, 1993. [26]Macedonia,M.R.andBrutzman,D.P. \MBoneprovidesaudioandvideoacrossthe Internet",IEEEComputerMagazine,pp. 30-36,Apr.1994. [27]McCanne,S.andJacobson,V.\vic:aexibleframeworkforpacketvideo",ACMMultimedia,pp.511-522,SanFrancisco,CA, Nov.1995. [28]Sanghi,D.,Agrawala,A.K.andJain,B. \Experimentalassessmentofend-to-endbehavioronInternet",Proc.IEEEInfocom '93,pp.867-874,SanFransisco,CA,Mar. 15
[29]Schulzrinne,H.,Casner,S.Frederick,R. colforreal-timeapplications",rfc1889, andjacobson,v.\rtp:atransportproto- 1993. [31]Turletti,T.\TheINRIAVideoconferencing [30]Turletti,T.andBolot,J-C.\Issueswith F3.1-3.4,Portland,Oregon,26-27Sept.94. Nov.1995. tionalworkshoponpacketvideo,pp. multicastvideodistributioninheterogeneouspacketnetworks",proc.6thinterna- [33]Wakeman,I.\Packetizedvideo-Optionsfor [32]Turletti,T.andHuitema,C.\RTPPayload 1996. interactionbetweentheuser,thenetwork System(IVS)",ConnexionsMagazine,pp. andthecodec",thecomputerjournal,vol. formatforh.261videostreams",rfctbd, 20-24,Oct.1994. [34]Zhang,L.,DeeringS.,Estrin,D.,Shenker, Sept.1993. reservationprotocol",proc.ieeenetwork, S.andZappala,D.\RSVP:anewresource 36,No1,1993. 16