NO315887B1 - Fremgangsmater ved overforing og soking av videoinformasjon - Google Patents

Description

Oppfinnelsen angår en fremgangsmåte ved overføring på anmodning av videoinformasjon i en delt nettverkressurs, hvor den delte nettverkressurs spesielt er Internett, et intranett eller ekstranett, hvor videoinformasjonen er lagret i form av en kodet videofil på HTTP-tjenere i den delte nettverkressurs og aksesseres av klienter via HTTP (Hypertext Transfer Protocol), hvor hver klient har en videodekoder, og hvor fremgangsmåten tar utgangspunkt i initial videoinformasjon i form av digitaliserte videosignaler.

Oppfinnelsen angår også en fremgangsmåte til klienteksekvert søking og gjenfinning av videoinformasjon i en delt nettverkressurs, spesielt søking og gjenfinning av et ønsket bilde i en videostrøm, hvor den delte nettverkressurs spesielt er Internett, et intranett eller ekstranett, hvor videoinformasjonen er lagret i form av en kodet videofil på HTTP-tjenere i den delte nettverkressurs og aksesseres av klienter via HTTP (Hypertext Transfer Protocol), hvor hver klient har en videodekoder, hvor den kodede videofil er sammenkjedet av multiple, kodede videostrømmer som rommer videoinformasjonens videosignaler komprimert ved gjennomsnittlig bitrater t[c] som dekker klientenes forventede kanalbitrater a, hvor hver kodet videostrøm er delt i p pakker med varierende lengde q, hvor hver pakke omfatter en topptekst og nyttelast, hvor pakkene i en strøm er anordnet i ikke-overlappende, suksessive grupper av to eller flere påfølgende pakker, slik at hver strøm deles i m slike grupper, hvor toppteksten til den første pakke i hver gruppe i tillegg til informasjon om antall n videobilder som pakken inneholder og referanser til andre pakker og strømmer, forsynes med informasjon om en hoppdistanse dj som svarer til den samlede lengde av pakkene i gruppen og antall j bilder som hoppdistansen dj og den første påfølgende pakke i den påfølgende gruppe omfatter, hvor videofilen dessuten omfatter en topptekst som rommer informasjon om parametrene til strømmene, hvor informasjonen om strømmenes parametre inkluderer distansene dk og d\ fra videofilens begynnelse til henholdsvis begynnelsen av hver strøm og til slutten av den første pakke i hver strøm, og hvor overføringen av videoinformasjon skjer båndbreddeskalert.

I en delt nettverkressurs vil de enkelte ressurser ha en varierende kvalitet og varierende operative parametre, slik at en delt nettverkressurs fremstår som et heterogent kommunikasjonsnettverk uten garantert tjenestekvalitet. Selv om oppfinnelsen generelt angår tjenester i delte nettverkressurser, vil i det følgende omtalen spesifikt være rettet mot Internett som er den mest kjente og utbredte eksempel på en offentlig tilgjengelig delt nettverkressurs. Som vel kjent er båndbredden til nettverkforbindelsene til Internett meget variable. Typiske forbindelsesbåndbredder kan variere fra 20-500 kbit/s. Da tjenestekvaliteten på Internett ikke kan garanteres, vil båndbredden og pakkeforsinkelsen for en gitt forbindelse kunne fluktuere på grunn av opphopning i nettverket. Dette er et alvorlig hinder for å overføre båndbreddeintensive og tidsfølsomme data som videoinformasjon over Internett.

Et videosignal må komprimeres for å redusere den nødvendige båndbredde for overføring over Internett. For overføring på anmodning komprimeres signalet en gang med en gjennomsnittlig målbitrate. Når det benyttes tapsbeheftet kompresjon, fås det forvrengning i det dekomprimerte signal. Kvaliteten på det dekomprimerte signal er proporsjonal med målbitraten. Internetts iboende heterogenitet er et dilemma når målbitraten skal bestemmes. På den ene side bør målbitraten være så høy at klienter med stor målbitbredde mottar et høykvalitetssignal, men da vil ikke klienter med lav båndbredde motta det samme signal i sanntid. På den annen side bør målbitraten være så lav at klienter med liten båndbredde mottar signalet i sanntid, men da vil klienter med stor båndbredde få et lavkvalitetssignal. Løsningen på dette vil være å benytte båndbreddeskalerbar kompresjon. Båndbreddeskalerbar kompresjon betyr at en rekke undermengder med forskjellig gjennomsnittlig målbitrate og tilsvarende kvalitet kan utvinnes fra det kodede signal. Når det komprimerte signal overføres til klienten, er følgelig signalet tilpasset klientenes tilgjengelige kanalbåndbredde.

Det skal nå gis en omtale av teknikken stand. Eksisterende båndbreddeskalerbare videostrømarkitekturer for videostrømmer på forespørsel krever en dedisert videotjener (se J. Hunter, V. Witana, M. Antoniades, "A Review of Video Streaming over the Internet", DSTC Technical Report TR97-10, august 1997). Klienten kobler seg opp mot videotjeneren og tjeneren utfører båndbreddeskalering i henhold til en eller annen fremgangsmåte. Den mest vanlig metode er å kode en rekke strømmer med forskjellige gjennomsnittlige bitrater på én fil. Tjeneren svitsjer deretter mellom strømmene avhengig av klientenes kanalbitrate. Denne løsningen har to ulemper. Den første er at en dedisert videotjener er nødvendig for å levere båndbreddeskalerbare videostrømmer på forespørsel og den andre er at brannvegger mellom videotjeneren og klientene må konfigureres spesielt slik at videostrømmene kan gå gjennom dem.

Det er for tiden også kjent videostrømarkitekturer som benytter HTTP som transportprotokoll. Slike arkitekturer er implementert som følger. Klienten

anmoder om en videofil. Når HTTP-tjeneren mottar anmodningen, begynner den å overføre videofil i en HTTP-respons til klienten. Ved å benytte HTTP som transportprotokoll er det ikke nødvendig med noen dedisert videotjener, da en HTTP-tjener er tilstrekkelig. Videre vil strømmene, da de overføres med HTTP, normalt ikke blokkeres av brannvegger og det blir derfor mulig med webtitting, noe som øker antallet klienter som er i stand til å motta strømmen. De eksisterende videostrømarkitekturer basert på HTTP har imidlertid to ulemper (se RealNetworks Inc., "Delivering RealAudio or RealVideo from a Web Server", RealNetworks Technical Blueprint Series, 1998). Den første er at de ikke er båndbreddeskalerbare og den andre er at det ikke er mulig å foreta en slumpmessig søking i videostrømmen.

En egnet versjon av HTTP som versjon 1.1 har to interessante egenskaper, nemlig vedvarende oppkobling og spesifisering av byteområde (se R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, UC Irvine, DEC, and MIT/LCS, januar 1997). Vedvarende oppkobling betyr at en rekke HTTP-forespørsler kan overføres over en såkalt socket-forbindelse, dvs. en identifikator for en bestemt tjeneste på en bestemt node på et nettverk. Det er dermed ikke nødvendig å omkoble til tjeneren for hver HTTP-forespørsel. Byteområdespesifisering åpner for muligheten av å anmode om en undermengde av filen på HTTP-tjeneren. Et koblingsur lukker forbindelsen hvis forespørselen ikke er mottatt av HTTP-tjeneren innenfor et forhåndsbestemt intervall. Det vil dessuten være mulig med et stort antall forespørsler under én oppkobling, f.eks. 100. Disse to egenskaper ved eksempelvis HTTP-versjon 1.1 er grunnlaget for den foreliggende oppfinnelse.

For å overvinne ulempene med den kjente teknikk er en første hensikt med den foreliggende oppfinnelse derfor å realisere båndbreddeskalerbar videooverføring med bruk av HTTP som transportprotokoll, og dernest en annen hensikt å muliggjøre pseudoslumpmessig søking av videoinformasjon med bruk av HTTP som transportprotokoll.

Den ovennevnte første hensikt og andre trekk og fordeler oppnås i henhold til oppfinnelsen med en fremgangsmåte som er kjennetegnet ved at den omfatter trinn for å generere ved hjelp av en videokoder^ multiple, kodede videostrømmer som hver rommer den initiale videoinformasjons videosignaler komprimert ved gjennomsnittlige bitrater t[c] som dekker klientenes forventede kanalbitrater a, idet videokoderen genererer uavhengig dekodbare videobilder med gitte tidsintervaller; å generere _y kodede mellomstrømmer fra de tilsvarende kodede videostrømmer ved å dele en kodet videostrøm i p pakker med varierende lengde q, idet hver pakke omfatter en topptekst og en nyttelast som rommer de kodede videosignaler for et tidssegment som tilsvarer nyttelasten; å forsyne toppteksten med følgende informasjon: (i) distansene d} og ^ henholdsvis til begynnelsen og slutten av den nærmest påfølgende pakke, (ii) antall n videobilder som pakken inneholder, samt (iii) en referanse til den tilsvarende pakke i henholdsvis den kodede mellomstrøm med den nærmestliggende lavere gjennomsnittlig bitrate t[ck.t] og den kodede mellomstrøm med den nærmestliggende høyere gjennomsnittlig bitrate t[ck+i], idet t[ck] er bitraten for den foreliggende mellomstrøm og k, b, a, g y\ å anordne et uavhengig dekodbart videobilde ved begynnelsen av nyttelasten til en pakke; å sammenkjede mellomstrømmene til en sluttfil som lagres på én eller flere HTTP-tjenere; og å forsyne sluttfilen med en topptekst som rommer informasjon om parametrene til strømmene; og dessuten ved følgende trinn iverksatt av klienten: å generere en anmodning om toppteksten og begynnelsen på den første strøm i sluttfilen; å estimere kanalbitraten a og å velge den strøm hvis bitrate t[ck] er den i forhold til den estimerte

A

kanalbitrate o nærmestliggende bitrate, som den initiale strøm i overføringen; og deretter å estimere kanalbitraten a under overføringen og

A

dersom estimatet o er lavere enn den gjennomsnittlig bitrate t[ck] til den foreliggende strøm, å svitsje til strømmen med den nærmestliggende lavere gjennomsnittlige bitrate t[ck.|], eller dersom estimatet er høyere enn gjennomsnittlige bitrate t[ck] til den foreliggende strøm, å svitsje til strømmen med den nærmestliggende høyere gjennomsnittlige bitrate t[ck+i], idet svitsjingen av strømmene skjer på basis av pakkereferansene og realiserer en båndbreddeskalerbar videooverføring over HTTP.

I fremgangsmåten ved overføring i henhold til oppfinnelsen er det spesielt foretrukket at den båndbreddeskalerbare videoovervåking skjer over en versjon av HTTP som tillater vedvarende oppkobling og spesifisering av byteområde.

I utførelsen av fremgangsmåten ved overføring i henhold til oppfinnelsen

A A

estimeres enten kanalbitraten o~ på basis av en estimator o = x/t, hvor o er den estimerte kanalbitrate og x antall bufrede bit i tidsintervallet t, slik at

A

dersom o > t[ck] og bufferlengde mindre enn to ganger minimum pakkelengde, svitsjes det til strømmen med en nærmestliggende høyere

A

målbitrate t[ca], eller dersom o < t[ck] og bufferlengde mindre enn minimum pakkelengde, svitsjes det til strømmen med en nærmestliggende lavere

d2x

målbitrate t[cb]; eller på basis av en estimator da = , slik at dersom

I o I > 0, svitsjes det til strømmen med en nærmestliggende høyere målbitrate t[ca], eller dersom | o | < 0, svitsjes det til strømmen med en nærmestliggende lavere målbitrate t[cb]. I det sistnevnte tilfelle fastsettes en grenseverdi A a , slik at svitsjing finner sted dersom | o \ > Ao .

Alternativt kan i henhold til oppfinnelsen kanalbitraten <j estimeres ved gjentatt å integrere kanalbitraten o over påfølgende tidsintervaller t = ta - tb, idet ta og tb henholdsvis er øvre og nedre grense for intervallet x og et integrasjonsresultat S gitt ved Z = jer dt, og å sammenligne integrasjonsresultatene S2. ^i for respektive påfølgende tidsintervall t2, T|, slik at dersom X2 - Si > 0, svitsjes det til strømmen med en nærmestliggende høyere målbitrate t[ca] eller dersom S2~ < 0, svitsjes det til strømmen med nærmestliggende lavere målbitrate t[cb], idet det fastsettes en grenseverdi AZ, slik at svitsjing finner sted dersom | S2 - Si | <>>AZ.

I en fordelaktig utførelse av fremgangsmåten ved overføring i henhold til oppfinnelsen benyttes en HTTP-tjener tilpasset HTTP-versjon 1.1 og videooverføringen finner da sted over samme versjon av HTTP.

I en annen fordelaktig utførelse av fremgangsmåten ved overføring i henhold til oppfinnelsen anordnes pakkene i strømmene i ikke overlappende suksessive grupper av to eller flere påfølgende pakker, slik hver strøm deles i m slike grupper, og toppteksten til den første pakke i en gruppe forsynes med informasjon om en hoppdistanse dj som svarer til den samlede lengde av pakkene i gruppen og antall j bilder som hoppdistansen dj og den første pakke i den påfølgende gruppe omfatter.

I en tredje fordelaktig utførelse av fremgangsmåten ved overføring i henhold til oppfinnelsen anordnes strømmene slumpmessig i sluttfilen, idet strømmen med lavest bitrate t[cj bare refererer til pakker i strømmen med den nærmestliggende høyere bitrate og strømmen med høyest bitrate t[cn] bare refererer til pakker i strømmen med den nærmestliggende lavere bitrate.

I en fjerde fordelaktig utførelse av fremgangsmåten ved overføring i henhold til oppfinnelsen anordnes strømmene suksessivt med stigende bitrate i sluttfilen, slik at strømmen med lavest bitrate t[cL] utgjør den første videostrøm i filen og strømmen med høyest bitrate t[cH] utgjør den siste videostrøm i filen.

Fortrinnsvis rommer strømmene et uavhengig dekodbart videobilde ved posisjoner svarende til begynnelsen av hver pakke i en foreliggende strøm.

Fortrinnsvis rommer de kodede strømmer det samme antall videobilder.

Hvor strømmene har forskjellig bildedrate, er det i henhold til oppfinnelsen fordelaktig å definere et justeringsbilde som en egen bildetype, og å justere bilderatene i hver strøm til samme rate ved å innsette et passende antall justeringsbilder i de respektive strømmer.

Fortrinnsvis er pakkelengden q høyst lik en konfigurerbar anmodningspause for HTTP-tjeneren, og fortrinnsvis prosesseres de kodede strømmer i parallell bilde for bilde.

Endelig er det ved fremgangsmåten ved overføring i henhold til oppfinnelsen fordelaktig at toppteksten til sluttfilen inneholder informasjon om antall y strømmer i filen, den gjennomsnittlige bitrate t[c] for hver strøm, og distansene d^ og di fra sluttfilens begynnelse til henholdsvis begynnelsen av hver strøm og til slutten av den første pakke i hver strøm, og dessuten at klienten på basis av videostrømmenes parametre genererer undermengder av strømmer, idet svitsjing mellom strømmene bare kan finne sted i disse undermengder.

Den ovennevnte annen hensikt oppnås med en fremgangsmåte til klienteksekvert søking og gjenfinning av videoinformasjon i en delt nettverkressurs, idet denne fremgangsmåte i henhold til oppfinnelsen er kjennetegnet ved å generere en anmodning til HTTP-tjeneren om nedlasting av toppteksten til den første pakke i en gruppe i en videostrøm, å sammenligne nummeret x til det ønskede bilde med j\ og dersom xe j, å gjenoppta overføringen og dekodingen av videostrømmen fra og med første bilde i pakken hvor bildet befinner seg, idet denne pakke er en av pakkene i gruppen samt den første pakke i den påfølgende gruppe, eller dersom jeg j, å anmode om toppteksten til den første pakke i den påfølgende gruppe, og eventuelt å fortsette prosessen inntil det ønskede bilde er funnet, hvoretter nedlasting og dekoding av strømmen gjenopptas fra og med første bilde i pakken hvor det ønskede bilde befinner seg, slik at det realiseres en bildebasert og pakkeformatert søking og gjenfinning av videoinformasjon med bruk av HTTP som transportprotokoll.

Ved fremgangsmåten til klienteksekvert søking og gjenfinning av videoinformasjon i henhold til oppfinnelsen er det spesielt foretrukket at det benyttes en versjon av HTTP som tillater vedvarende oppkobling og spesifisering av byteområde.

Ved framgangsmåten til klienteksekvert søking og gjenfinning av videoinformasjon benyttes fordelaktig en HTTP-tjener tilpasset HTTP-versjon 1.1 og HTTP-versjon 1.1 benyttes som transportprotokoll.

Både i fremgangsmåten ved overføring og i fremgangsmåten til klienteksekvert søking og gjenfinning av informasjon er det fordelaktig at det genereres og vedlikeholdes en stakkliste for HTTP-anmodninger, idet en anmodning legges i stakklisten ved sending og fjernes derfra etter prosessering av den fra HTTP-tjeneren mottatte respons, og at anmodningene i stakklisten sendes på ny ved gjenopprettet forbindelse etter et eventuelt brudd i forbindelsen mellom HTTP-tjener og klient under mottak av responsen. I den forbindelse vil fortrinnsvis den første anmodning oppdateres dersom et brudd i forbindelsen finner sted under mottak av en pakke, idet begynnelsen av pakken justeres for de eventuelt allerede mottatte data.

Oppfinnelsen skal nå forklares mer detaljert ved hjelp av utførelseseksempler og med henvisning til den vedføyde tegning hvor

fig. 1 viser en skjematisk oversikt over genereringen av videofilen samt det ved den foreliggende oppfinnelsen benyttede tjener-klient-system,

fig. 2a strukturen til en videofil som benyttet ved den foreliggende oppfinnelse,

fig. 2b toppteksten til videofilen på fig. 2a,

fig. 3a pakkedelingen av en videostrøm som benyttet i videofilen på fig. 2a,

fig. 3b sammensetningen av en pakke i videostrømmen på fig. 3a,

fig. 3c toppteksten til pakken på fig. 3b,

fig. 4 skjematisk prinsippet for å oppnå båndbreddeskalering ved svitsjing mellom videostrømmer,

fig. 5a hvordan en videostrøm deles i grupper av pakker,

fig. 5b strukturen til den enkelte gruppe i videostrømmen på fig. 5a,

fig. 5c sammensetningen av pakkene i videostrømmen på fig. 5b,

fig. 5d toppteksten til den første pakke i en gruppe i videostrømmen på fig. 5a,

fig. 6a et bufferminne anordnet foran klientens dekoder, og fig. 6b flytdiagrammet for en foretrukket utførelse av den pseudoslumpmessige søking av videoinformasjon overført ved fremgangsmåten for overføring i henhold til oppfinnelsen.

I den etterfølgende detaljerte beskrivelse av en utførelse av den foreliggende oppfinnelse er det underforstått at hvor annet ikke uttrykkelig er sagt, er den delte nettverksressurs representert ved Internett og HTTP-versjon 1.1 benyttes som transportprotokoll. Spesielt oppnår nemlig den foreliggende oppfinnelse båndbreddeskalerbar videooverføring med bruk av HTTP-versjon 1.1 som transportprotokoll ved at det genereres en bitstrøm som er optimert for dette formål. Det er spesielt hensiktsmessig å benytte HTTP-versjon 1.1 som transportprotokoll, og dette innebærer at det må benyttes en koder og en HTTP 1.1 mulig med et minimum av administrasjon. Dessuten vil HTTP-klienten også være i stand til å utføre rask søking i den komprimerte videoinformasjon utenfor det område som allerede er mottatt.

Den foreliggende oppfinnelse vil også sette videoleverandører i stand til å tilby båndbreddeskalerbar video fra en tjener som er tilpasset HTTP-versjon 1.1. Koding av en fil er tilstrekkelig til å dekke båndbreddeområdet til klientene og søkemuligheten som nå tilbys, vil muliggjøre søkbare videoarkiver hvor søkingen utføres på grupper av pakker i en videostrøm, eventuelt med bruk av merkelapper som refererer til forskjellige posisjoner i videofilen, idet disse merkelapper kan være anordnet i toppteksten til den komprimerte videofil. Det vil heller ikke lenger være nødvendig med en dedisert videotjener.

Ved den foreliggende oppfinnelse konstrueres et videostrømfilformat som tillater den å utnytte den vedvarende oppkobling som tilbys av versjoner av HTTP. Særlig gjelder det HTTP-NG-versjoner som versjon 1.1. Spesielt for disse versjoner gjelder at de ikke kobles ned etter hver anmodning eller forespørsel fra klienten, men opprettholder forbindelsen over et spesifikt antall anmodninger. Samtidig er det også mulig for klienten å spesifisere et bestemt byteområde som skal overføres.

Fig. 1 viser skjematisk generering av en videofil som tillater båndbreddeskalerbar overføring, og systemopplegget for overføringen med bruk av HTTP-versjon 1.1 som transportprotokoll. En videosignalkilde

genererer videosignaler som leveres til en analog/digitalomformer ADC som digitaliserer videosignalene og gir dem til en koder som genererer y multiple, kodede videostrømmer VSrVSy. Koderen kompresjonskoder videosignalene med respektive gjennomsnittlige bitrater t[c], slik at disse dekker de forventede kanalbitrater o~ for overføring til klientene. Eksempelvis kan det genereres seks videostrømmer VS|-VS6 som rommer den samme videoinformasjon, men som henholdsvis er kodet med gjennomsnittlige bitrater på 22, 45, 60, 120, 256 og 512 Kb/s. Dermed blir det mulig med en båndbreddeskalerbar videooverføring i området 20-500 Kb/s. Det er nødvendig at videokoderen genererer uavhengig dekodbare videobilder IF ved gitte tidsintervaller. Slike videobilder IF er kjent som intravideobilder for hybride videokodeker. De kodede videostrømmer VS formatteres nå til y kodede mellomstrømmer IS, eksempelvis ved hjelp av en

formateringsprosessor, idet en kodet videostrøm VS deles i p pakker PC. Disse pakkene PC kan ha varierende lengde q og omfatter hver en topptekst Hpc og en nyttelast PL som rommer de kodede videosignaler for et tidssegment som tilsvarer nyttelasten. De nå kodede og formatterte videostrømmer IS blir deretter sammenkjedet til en videofil O for lagring på en HTTP-tjener, spesielt en tjener for HTTP-versjon 1.1 og kan på anmodning fra en HTTP-klient lastes ned til denne. Som vist på fig. 1, bufres den nedlastede videofil på et bufferminne av passende størrelse i HTTP-klienten og dekodes deretter ved hjelp av klientens dekoder, idet dekodingen naturligvis finner sted med den gjennomsnittlige bitrate t[c] som svarer til kodingsbitraten for den aktuelle strøm. Etter dekodingen finner det sted en digital/analog-omforming i klientens digital/analog-omformer DAC, hvoretter den mottatte videoinformasjon kan lagres på et analogt medium eller reproduseres på en egnet avspillingsinnretning. Dette er trivielt og derfor ikke nærmere vist på fig. 1. - Det skal bemerkes at det ikke er nødvendig med et særskilt, ekstra bufferminne for dekoderen, da det i fremgangsmåten til overføring løpende finner sted en avstemning mellom bitraten t[c] og kanalbitraten a. Derimot vil det i klienten være anordnet et ikke vist bufferminne for en eventuell avspilling etter dekoding, noe som vil være innlysende for fagfolk.

Fig. 2a viser den sammenkjedede videofil O slik den ligger lagret på HTTP-tjeneren. Filen 3> er som nevnt sammenkjedet avjy strømmer ISj-ISy og omfatter i tillegg en topptekst H0 som er formatert i 4y+l blokker. Den første blokken Y angir antall strømmer y i filen <I>. Dernest følger y blokker Tj-Ty som henholdsvis angir den gjennomsnittlige kodingsbitrate t[c] for de respektive y strømmer IS. Nå følger det i toppteksten to blokker Dk, D] for hver strøm IS. Disse blokkene inneholder informasjon om distansene of* og d\ henholdsvis fra begynnelsen av filen <t> til begynnelsen av hver strøm IS og til slutten av den første pakke PCi i hver strøm IS. I tillegg er det for hver strøm IS én blokk n som inneholder parametre for strømmen IS, idet blokken n eventuelt kan være segmentert i flere underblokker avhengig av antall innlagte parametre. Disse parametre kan f.eks. angå bildedimensjon og parametre for en audiokoding. Dette forhindrer at det ved båndbreddeskaleringen svitsjes mellom strømmer med forskjellige bildedimensjon, og dersom ikke-båndbreddeskalerbar audioinformasjon er interfoliert sammen med videoinformasjon, forhindres svitsjing mellom strømmer som rommer forskjellige audiokoding. Spesifikt angir på fig. 2b blokken Dkji distansen til begynnelsen av strømmen IS! og blokken distansen til slutten av den første pakke PC( i strømmen IS], mens 11] rommer parameterinformasjon om strømmen IS]. Tilsvarende angir blokken Dky distansen til begynnelsen av den siste strøm ISy i filen <3>, blokken D]jy distansen til slutten av den første pakke PC! i strømmen ISy og blokken ny da naturligvis parameterinformasjon om strømmen ISy. ;Fig. 3 viser hvordan hver strøm IS er delt i p pakker PCrPCp. Hver pakke PC har lengden q og fortrinnsvis er pakkelengden høyst lik en konfigurerbar anmodningspause på HTTP-tjeneren. Dessuten bestemmer pakkelengden q balansen mellom pakkeadministrasjonen, oppløsningen ved en eventuell søking av videoinformasjon og tidsintervallet, slik det skal bli omtalt senere, og tidsintervallet mellom en eventuell svitsjing av strømmene IS. Dersom disse betingelser er oppfylt, kan pakkelengden q ellers godt variere. ;Hver pakke PC rommer en topptekst HPc, og en nyttelast PL som omfatter de kodede videosignaler for et tidssegment som tilsvarer nyttelasten. Nyttelasten PL til hver pakke PC rommer et antall n videobilder F som kan være forskjellig fra pakke til pakke. Videre er det nødvendig at nyttelasten PL starter med et uavhengig dekodbart videobilde, slik at dekoderen i klienten kan dekode hver pakke uavhengig. Toppteksten HPC til en pakke PC er i utgangspunktet formatert i fem blokker, hvor en første blokk Di rommer informasjon om distansen d} til begynnelsen av den påfølgende pakke, en annen blokk D2 informasjon om distansen <k til slutten av den påfølgende pakke, en tredje blokk N informasjon om antall videobilder n i pakken og en fjerde blokk B en referanse til den tilsvarende pakke i den kodede mellomstrøm ISb med en nærmestliggende lavere gjennomsnittlig bitrate t[ck-i] og en femte blokk A en referanse til den tilsvarende pakke i den kodede mellomstrøm ISa med en nærmestliggende høyere gjennomsnittlig bitrate t[ck+i], idet t[ck] er bitraten for den foreliggende strøm ISk, k,b,a € y. ;I tillegg kan toppteksten HPC til en pakke PC dessuten romme informasjon som benyttes dersom det implementeres en fremgangsmåte til søking i videoinformasjon, slik dette skal omtales nærmere nedenfor. ;Det skal forstås at strømmene IS kan være anordnet slumpmessig i filen O. Strømmen ISL som har den laveste bitrate t[cL], vil bare referere til pakker i strømmen med den nærmestliggende høyere bitrate og tilsvarende vil strømmen ISH med en høyeste bitrate t[cH] bare referere til pakker i strømmen med den nærmestliggende lavere bitrate. ;Det er imidlertid foretrukket og hensiktmessig at strømmene IS anordnes suksessivt med stigende bitrate t[c] i filen 4> slik at strømmen ISL med lavest bitrate t[cL] blir den første videostrøm ISi i filen O og strømmen ISH med ;høyest bitrate t[cH] den siste videostrøm ISy i filen <I>. Fortrinnsvis rommer de kodede strømmer VS;IS samme antall videobilder F. Dette forhindrer ikke at det kan benyttes en varierbar videobilderate, da det vil være mulig å definere et justeringsbilde Fs som en egen bildetype og justere hilderåtene i hver strøm IS til samme rate ved at det innsettes et passende antall justeringsbilder Fs i de respektive strømmer IS. Klienten vil da tolke et justeringsbilde Fs som en gjentagelse av det forutgående, dekodede videobilde. Strømmen ISB som har den nærmestliggende lavere bitrate t[ck.i] i forhold til bitraten t[ck] for en foreliggende strøm ISk, skal ha et uavhengig dekodbart videobilde IF ved posisjoner svarende til begynnelsen av hver pakke i den foreliggende strøm ISk. Tilsvarende skal strømmen ISa som har den nærmestliggende høyere bitrate t[ck+J] i forhold til bitraten t[ck] for den foreliggende strøm ISk, også ha et uavhengig dekodbart videobilde IF ved posisjoner svarende til begynnelsen av hver pakke i den foreliggende strøm ISk. Endelig vil hver strøm IS være avhengig av strømmene med henholdsvis den nærmestliggende lavere bitrate og den nærmestliggende høyere bitrate og dette gjør at de kodede strømmer må prosesseres i parallell, bilde for bilde. ;Videofilen $ med de kodede strømmer IS er plassert på en HTTP-tjener som er tilpasset en egnet versjon av HTTP, spesifikt HTTP-versjon HTTP 1.1. Generelt starter overføringen med at klienten først anmoder HTTP-tjeneren om et fast antall byte. Dette faste antall byte skal inkludere toppteksten H„, til videofilen 4> og starten på den første strøm VS t i videofilen O. Under visse omstendigheter vil det imidlertid ikke være mulig å svitsje mellom samtlige videostrømmer IS i filen <£. Dersom eksempelvis videostrømmene har forskjellige rammedimensjon eller audioinformasjonen som er interfoliert med videoinformasjonen ikke er båndbreddeskalerbar og kodet med forskjellige verdier for hver videostrøm, vil det ikke være mulig å svitsje mellom slike videostrømmer, da de ikke er båndbreddeskalerbare. For å forhindre svitsjing mellom videostrømmer som ikke er båndbreddeskalerbare, må klienten tolke parameterne i toppteksten H,,, og avgjøre hvilke videostrømmer det kan svitsjes mellom. Det er imidlertid i noen tilfeller bare mulig å svitsje mellom en undermengde av det totale antall y videostrømmer, og klienten vil da, som ovenfor nevnt, generere undermengder av strømmene IS, slik at svitsjing mellom strømmene IS bare kan finne sted i disse undermengder. ;Det er nødvendig at klienten estimerer kanalbitraten a under overføringen. ;A ;Hvis estimatet o av kanalbitraten a er lavere enn den gjennomsnittlige bitrate t[ck] for den foreliggende strøm ISk, svitsjes det til strømmen ISb med ;A ;den nærmestliggende lavere gjennomsnittlig bitrate t[ck_|]. Hvis estimatet o av kanalbitraten o er høyere enn den gjennomsnittlige bitrate t[ck] for den foreliggende strøm ISk, svitsjes det til strømmen IS„ med den nærmestliggende høyere gjennomsnittlige bitrate t[ck+i]. Dersom strømmene IS er anordnet suksessivt med stigende bitrate i filen O, vil det naturligvis være den foreliggende strøms ISk nabostrømmer ISk.„, ISk+J det alt ettersom svitsjes til. Er den foreliggende strøm ISk strømmen med lavest bitrate t[cL] og anordnet som den første strøm ISj i filen kan det naturligvis bare svitsjes til den påfølgende strøm IS2. Tilsvarende kan det dersom den foreliggende strøm ISk er lik strømmen med høyest bitrate ISH, bare svitsjes til den nærmest foregående strøm ISy.i. Ved å svitsje mellom strømmene kan kodebitraten t[c] tilpasses en foreliggende kanalbitrate a og det oppnås således båndbreddeskalerbar videooverføring over eksempelvis HTTP-versjon 1.1. ;Med henvisning til fig. 4 skal det nå gis en mer spesifikk omtale av hvordan båndbreddeskalerbar videooverføring oppnås ved svitsjing mellom videostrømmene IS i videofilen 3>. På fig. 4 er det med piler antydet de distanser som avstandsblokkene Di, D2 i en topptekst Hpc refererer til. Likeledes er den innbyrdes referanse B, A mellom korresponderende pakker i strømmen antydet ved piler mellom blokkene. En nærmere omtale av hvordan referansene kommer til anvendelse i fremgangsmåten for overføring vil bli gitt i det følgende. ;I eksempelet på fig. 4 er det vist seks strømmer ISi-TS6 som sammenkjedet og med tillegg av en filtopptekst H,,, utgjør videofilen O. Hver strøm IS består som vist på fig. 4 av tre pakker og rommer det samme antall bilder og den samme videoinformasjon. Både antall strømmer og antall pakker i hver strøm er naturligvis et helt skjematisk eksempel, og formatering i strømmer og pakker vil i realiteten naturligvis rette seg etter de omstendigheter som en overføring av den foreliggende videoinformasjon betinger. På fig. 4 kan strømmene henholdsvis være kodet med de bitrater t[c] som er angitt i det ovenstående eksempel og således dekke et forventet kanalbitrateområde på 20-500 kbit/s. Videre er strømmene IS i filen O på fig. 4 vist anordnet med stigende bitrater, slik at den første strøm ISi i filen O har den laveste bitrate t[cj og den siste strøm IS6 i filen <J> den høyeste bitrate t[cH]. ;Generelt er hver strøm IS som vist på fig. 4 formatert i p pakker, idet p = 3 på fig. 4, og hver strøm inneholder altså den samme videoinformasjon. I toppteksten HPC til hver pakke er det anordnet to blokker Di, D2 som rommer byteformatert avstandsinformasjon. Blokken Di angir distansen di til begynnelsen av den påfølgende pakke og blokken D2 distansen ^ til slutten av den påfølgende pakke i strømmen. Straks de to avstandsblokker D], D2 er mottatt for en pakke, anmodes om den påfølgende pakke i strømmen. Sekvenseringen av pakkeanmodninger på denne måte eliminerer rundreiseforsinkelsen i nettverket. Anmodningene om pakker opphører når det mottas to distanseblokker Dj, D2 som inneholder tallet 0. ;Toppteksten HPC til pakkene PC rommer ytterligere to informasjonsblokker som benyttes ved svitsjing mellom strømmer, nemlig informasjonsblokken B som refererer til den tilsvarende pakke i strømmen med den nærmestliggende lavere bitrate og informasjonsblokken A som refererer til videostrømmen med den nærmestliggende høyere bitrate. Slik strømmene IS er anordnet på fig. 4, nemlig med stigende bitrater t[c], vil blokkene B og A henholdsvis referere til den foreliggende strøms nabostrømmer. Som vist på fig. 4, rommer ikke den første pakke i hver av strømmene IS blokkene B og A. Når den foreliggende kanalbitrate a er estimert, noe som skjer når det anmodes om toppteksten H,,, i videofilen O, vil nemlig blokkene T med bitrateinformasjon angi hvilken strøm som er ønskelig, og avstandsblokkene Dk og D] vil angi avstanden fra begynnelsen av filen $ til henholdsvis begynnelsen av den ønskede videostrøm IS og til slutten av den første pakke PCi i denne videostrøm. Det er naturligvis ingenting i veien for at blokkene B, A allikevel kunne legges inn i toppteksten i den første pakke PCi i hver strøm IS, men dette er som det vil ses, en overflødig foranstaltning. Da strømmene som vist på fig. 4, er anordnet med stigende bitrate, vil også strømmen ISj, dvs. strømmen ISL med den laveste bitrate t[cL] bare kunne referere til strømmen med den nærmest høyereliggende bitrate og topptekstene til pakkene i strømmen ISj vil følgelig bare romme avstandsblokken A som refererer strømmen med den nærmestliggende høyere bitrate, nemlig strømmen IS2. Tilsvarende vil strømmen IS6 som svarer til strømmen ISH med den høyeste bitrate t[cL] bare referere til strømmen med den nærmestliggende lavere bitrate, nemlig strømmen IS5. Følgelig inneholder ikke toppteksten til pakken PCj til strømmen IS6 A-blokken, men bare B-blokken som refererer til strømmen med den nærmestliggende lavere bitrate. Det kan nevnes at blokkene B, A bare kan settes inn ved posisjoner hvor både videobildet F i den foreliggende strøm ISk og i strømmene ISk.i, ISk+i (eller ISb,ISa ved slumpmessig anordnede strømmer) er intrabilder IF. Intrabilder IF er uavhengig kodede videobilder. Dessuten må de respektive pakker ha samme lengde i strømmene ISk, ISk.i, og ISk+i. ;For å svitsje fra en foreliggende strøm til strømmene med nærmestliggende høyere eller lavere bitrater t[ck+l], t[ck_i] alt etter som kanalbitraten a forandrer seg, anmodes det om to byteformaterte distanseblokker Di, D2 med fast størrelse og som starter ved den angitte avstand i den strøm det ønskes svitsjet til, idet denne strømmen, slik det er eksemplifisert på fig. 4, naturligvis vil være én av nabostrømmene. I det øyeblikket klientene mottar blokkene Di, D2, brytes anmodningssekvensen, og straks det anmodes om neste pakke, gjenopprettes anmodningssekvensen. Følgelig innfører svitsjing mellom strømmer IS bare én rundreiseforsinkelse, noe som igjen reduserer den effektive kanalbitrate o\ Det ville være mulig å benytte bare en eneste byteformatert distanseblokk i hver pakke, idet denne blokken da angir størrelsen på neste pakke. Dette ville imidlertid føre til to rundreiseforsinkelser under svitsjingen mellom strømmene IS. For å unngå ombufring under nedlasting eller avspilling i klienten, er det essensielt at svitsjingen mellom strømmene skjer raskt. Følgelig benyttes det to distanseblokker D(, D2 i hver pakke, selv om dette øker pakkeadministrasjonen. ;Innlysende vil administrasjonen av båndbreddeskalerbarhet være omvendt proporsjonal med pakkelengden q, idet store pakker resulterer i mindre pakkeadministrasjon. Imidlertid vil store pakker øke intervallet hvorunder en svitsjing mellom strømmene IS kan utføres. For å unngå ombufring under nedlasting eller avspilling i klienten, er det viktig at dette intervallet ikke er for langt. Hensiktsmessig er det i fremgangsmåten ved overføring i henhold til den foreliggende oppfinnelse valgt å benytte pakker med en varighet på ca. 15 s. Dette gir en typisk pakkeadministrasjon på 0,20 Kbit/s, avhengig av størrelsen på HTTP-responsen og -anmodningen. ;Under den initiale oppsetting anmoder klienten om et forhåndsgitt antall byte. Responsen vil omfatte toppteksten H,,, til videofilen $ og den første del av den første strøm IS\. Under responsen estimeres kanalbitraten a. Basert på ;estimatet o sl velges den initiale strøm i overføringen. Hvis den initiale strøm ikke er den første strøm IS i i videofilen blir de initiale byter som allerede er mottatt fra strømmen ISj, lagt vekk. Hvis den initiale strøm er strømmen IS], fortsetter den neste respons fra det sted den initiale anmodning opphørte. Da strømmen ISi som vist i eksempelet, utgjør strømmen som ble kodet med den laveste bitrate t[cj, minimeres initial bufring for kanaler med lav bitrate o\ ;Hva angår estimeringen av kanalbitraten, vil det være innlysende for fagfolk at den kan skje på forskjellige måter. ;Utgangspunktet for en i fremgangsmåten ved overføring foretrukket metode til estimering av kanalbitraten a er at videokoderen genererer bitstrømmen med variabel bitrate. Hver videostrøm kodes med en bestemt gjennomsnittlig målbitrate t[c]. Kvantiseringen og bilderaten under videokodingen justeres av en eller annen passende valgt ratekontrollalgoritme som sikrer at målbitraten t[ c] nås og dessuten at en bufring i koderen holdes på en eller annen forhåndsbestemt størrelse under kodingen av hele videosekvensen. På den annen side må klienten bufre en forhåndsbestemt datamengde før dekodingen starter. ;I tillegg vil klienten også måtte bufre dekodede data for avspilling etter en digital/analog omforming, men dette er som nevnt irrelevant i det foreliggende tilfelle. Hvis kanalbitraten o nå er lik målbitraten t[c] for videostrømmen IS, unngås ombufring hos klienten før dekodingen. Kanalbitraten kan være forskjellig for de forskjellige klienter og dessuten fluktuere systematisk. For å unngå ombufring i klientens bufferminne forut for dekodingen, sørger fremgangsmåten ved overføring i henhold til foreliggende oppfinnelse for båndbreddeskalering ved å svitsje mellom strømmer med forskjellig målbitrate t[c]. Denne svitsjingen blir som nevnt utført på basis av en estimering av kanalbitraten a. Estimatoren er ganske enkelt o = x/t, hvor x er antallet bufrede bit i tidsintervallet x. Da det bare er mulig å svitsje mellom strømmer ved grensene for pakkene PC, er oppløsningen i x lik pakkelengden q. Den følgende heuristikk benyttes til å avgjøre når svitsjing mellom strømmene skal foregå: ;A ;1) hvis o > t[Ck] og bufferlengde mindre enn to ganger minimum pakkelengde, så svitsjes det til strømmen ISa med den nærmestliggende høyere målbitrate t[ca], eller ;A ;2) hvis o < t[ck] og bufferlengde mindre enn minimum pakkelengde, så svitsjes det til strømmen ISb med nærmestliggende lavere målbitrate t[Cb]. - Med minimum pakkelengde skal det forstås den verdi av q som benyttes når videofilen $ genereres. Den her angitte metode til estimering av kanalbitraten a er lett å implementere, da den gjør bruk av bufferlengden og pakkelengden. I prinsippet kan det også benyttes en momentan estimering som ikke er betinget av bufferlengde og pakkelengde. Eksempelvis vil det være mulig å benytte den tidsderiverte av a som estimator for kanalbitraten o\ Estimatoren A d2x o er med andre ord da = —dt5-. Svitsjing finner da sted under følgende forutsetninger: 1) Hvis o > 0, svitsjes det til strømmen ISa med nærmestliggende høyere målbitrate t[ca], 2) hvis o < 0, svitsjes det til strømmen ISb med nærmestliggende lavere målbitrate t[cb]. ;Fortrinnsvis vil i praksis svitsjingen skje ved at o blir lik eller overskrider en grenseverdi A o , slik at | o \ >Ao. Denne grenseverdi kan da være forhåndsbestemt på basis av de valgte kodingsbitrater t[c] og klientens bufringskapasitet i forbindelse med dekoding. På grunn av ulik avstand mellom de gjennomsnittlige valgte kodingsbitrater t[c] er det fordelaktig å skalere Ao avhengig av fortegnet for o og den aktuelle kodingsbitrate t[ck], slik at svitsjing mellom f.eks. 6 strømmer ISi - IS6 finner sted med bruk av 2-4 + 2 = 10 forhåndsvalgte verdier for Ao . For hver av strømmene ISL og ISH vil det bare være tilordnet en eneste respektive grenseverdi da svitsjing bare vil finne sted til strømmen med henholdsvis nærmestliggende høyere eller nærmestliggende lavere kodingsbitrate. ;Alternativt kan estimeringen av kanalbitraten rj også finne sted ved gjentatt å integrere kanalbitraten er over påfølgende tidsintervaller x = ta - tb, hvor ta er den øvre grense og tb den nedre grense for intervallet x, og å foreta svitsjingen ved å sammenligne integrasjonsresultater S1} S2 for respektive påfølgende tidsintervall x1?x2, slik at svitsjing finner sted til en strøm ISa med nærmestliggende høyere bitrate t[ca] finner sted dersom S2 - Si > 0, og tilsvarende til en strøm ISb med nærmestliggende lavere bitrate t[cb], dersom X2 - Si < 0. Fortrinnsvis vil svitsjingen også i disse tilfeller finne sted når en grenseverdi AS nås eller overskrides, slik at | S2 - Si AS. Grenseverdien kan være forhåndsbestemt som på samme grunnlag som grenseverdien A o for den tidsderiverte kanalbitrate a , og fordelaktig skaleres i analogi med skaleringen av A o . ;Hva enten den tidsderiverte eller integrasjonsresultatet benyttes som estimator for kanalbitraten, må det ved fastsettelsen av tidsintervaller og grenseverdier tas hensyn til at det både i kanalbitraten a og kodingsbitraten t[c] vil opptre kortvarige, ikke-periodiske og slumpmessige fluktuasjoner. Tidsintervall og grenseverdier må derfor velges signifikant større enn henholdsvis den maksimale varighet og amplitude til fluktuasjoner av denne art. ;I forbindelse med fremgangsmåten ved overføring av videoinformasjon i henhold til den foreliggende oppfinnelse, vil det være ønskelig at klienten kan eksekvere søking og gjenfinning av den overførbare videoinformasjon som er lagt inn i videofilen i form av videostrømmer IS og kodet med respektive forskjellige bitrater t[c] som svarer til klientens forventede kanalbitrater a. Da strømmene IS er dessuten er formatert med tanke på at overføringen skal kunne skje med en egnet versjon av HTTP som transportprotokoll, kan søkingen benytte den informasjon som allerede foreligger i toppteksten av HPC til pakkene PC i de pakkeformaterte videostrømmer IS. Videoinformasjon kan omfatte sekvenser av videobilder som har en innbyrdes semantisk relasjon, in casu videofilmer, men kan også bestå av enkeltbilder eller stillbilder. Det er derfor ønskelig at søking og gjenfinning av videoinformasjon er rettet mot enkeltbilder. På den annen side er det innlysende at en eksakt søking og gjenfinning av et enkeltbilde og nedlasting av dette vil være svært ressurskrevende. Fremgangsmåten til klienteksekvert søking og gjenfinning av informasjon i henhold til oppfinnelsen er derfor utgangspunktet i søking etter enkeltbilder, men gjenfinningen finner sted ved å lokalisere dette enkeltbilde i en sekvens av bilder som kan omfatte opptil flere pakker PC i en videostrøm IS og deretter å finne og laste ned pakken hvor enkeltbildet forekommer. I praksis innebærer dette at søkingen og gjenfinningen i henhold til oppfinnelsen realiseres som et pseudoslumpmessig søk. Dette oppnås ved å legge inn ytterligere informasjon i toppteksten til noen av pakkene i videostrømmen, slik dette skal forklares nærmere med henvisning til fig. 5a-5d. ;Som vist på fig. 5a, deles en videofil i m grupper Gi...Gm, og hver av disse gruppene omfatter et antall r pakker PC slik det skal forklares nærmere med henvisning til fig. 5b. Det skal forstås at antallet r godt kan være innbyrdes forskjellig i de forskjellige gruppene, men det vil være naturlig at r er et fast tall. Dersom antall pakker i strømmen da ikke er et multiplum av r, vil naturligvis den siste gruppe i strømmen ha et antall pakker som er mindre enn det fast valgte tall r. En vilkårlig valgt gruppe Gk, ke m, omfatter derfor pakker PCkj, PCk2 PCk,r. Den første påfølgende gruppe Gk+i omfatter da naturligvis tilsvarende pakker PCk+i, PCk+j>2,... PCk+1,r. Toppteksten HPc i den første pakke PCk>i i en vilkårlig gruppe Gk, ke m, må for å realisere fremgangsmåten til søking omfatte ytterligere to informasjonsblokker utover de som er vist på fig. 3c, nemlig en informasjonsblokk Dj og en informasjonsblokk J. Informasjonsblokken Dj rommer informasjon om en hoppdistanse d} som svarer til den samlede lengde av pakken i gruppen Gk og informasjonsblokken J rommer informasjon om antall bilder som er omfattet av hoppdistansen dj og den første pakke PCk+i,i i den påfølgende gruppe Gk+i. Det vil nå ses at delingen i grupper G er konvensjonelt gitt ved dj, og ikke fysisk. ;Ved fremgangsmåten til søking og gjenfinning i henhold til oppfinnelsen genereres først en anmodning til HTTP-tjeneren om nedlasting av toppteksten HP til den første pakke PCk>i i en eksempelvis inntreffende gruppe Gk, kem, i en videostrøm ISk, key. Blokken Dj gir distansen dj til begynnelsen av pakken PCk+i,i som allerede nevnt og vist på fig. 5c, mens blokken J angir naturligvis da antall j videobilder omfattet av hoppdistansen og i den første pakke PCfc+u i påfølgende gruppe PCk+1. Dersom nå det ønskede bilde er Fx, sammenlignes nummeret x til dette bildet med j, og dersom xej\ gjenopptas overføringen av dekodingen av videostrømmen fra og med første bilde i pakken hvor bildet Fx befinner seg, idet denne pakke må være en av pakkene i gruppen Gk samt den første pakke PCk+u i den påfølgende gruppe Gk+i. Antall bilder n i hver pakke er nemlig gitt ved blokken N i toppteksten til pakkene, og da det ses at ;j = nk,i + nk,2+--- + nk,r + nk+i,i dvs. summen av alle bildene i gruppen Gk pluss antall bilder i den første påfølgende pakke PCk+1,i i neste gruppe Gk+i, vil nå pakken hvor bildet Fx befinner seg, finnes og overføringen og dekodingen av videostrømmen skjer da fra første bilde i denne pakke. ;Dersom nå x * j anmodes det om toppteksten HP til den første pakke PCk+u i neste gruppe Gk+i, idet toppteksten til denne pakke likeledes inneholder blokken Dj med informasjon om hoppdistansen dj for gruppen Gk+1 og blokken J som angir antall bilder j til pakkene i denne gruppe og den første pakke Gk+2,i i den neste gruppe. Dersom nå xej, overføres og dekodes videostrømmen fra og med første bilde i pakken hvor det søkte bilde befinner seg, og dersom xij, gjentas prosessen på pakkene i den påfølgende gruppe inntil det ønskede bilde Fx er funnet. Dermed realiseres en bilderettet, men pakkeformatert søking og gjenfinning av videoinformasjon med bruk av en egnet versjon av HTTP som er transportprotokoll. Søkingen foregår i hopp over en sekvens av hoppavstander dj, noe som bidrar til å redusere søketiden. Når det ønskede videobildet befinner seg innenfor angitte bildenummer j, blir søkingen begrenset til å finne den pakke som inneholder det ønskede bilde, slik denne vil være gitt i toppteksten til den første pakke i gruppen ved blokkene Dj og J, samt blokken N i toppteksten til hver av pakkene som er inkludert i gruppen og den første påfølgende pakke etter gruppen. Da søkingen er begrenset til å finne bare pakken som inneholder et ønsket bilde, kan den betegnes som en pseudoslumpmessig søking. Det skal bemerkes at hoppdistansen dj påvirker både administrasjonen og responstiden ved pseudoslumpmessig søking. Administrasjonen ved pseudoslumpmessig søking er nemlig omvendt proporsjonal med hoppdistansen dj, idet en større hoppdistanse dj resulterer i mindre pakkeadministrasjon. Bruk av en hoppdistanse på eksempelvis 25 pakker PC, dvs. r = 25, gir typisk en pakkeadministrasjon på 0,02 Kbit/s, noe som er ubetydelig. Søketiden domineres av rundreiseforsinkelsen i nettverket, da det ikke skjer noe pipelining av anmodningene og bare en del av pakketoppteksten Hpc strengt tatt er nødvendig. Det vil også ses at oppløsningen ved en slik pseudoslumpmessig søking bestemmes av pakkelengden q, som igjen hovedsakelig er gitt ved antall bilder n i hver pakke.

Søking og gjenfinning av videoinformasjonen kan finne sted allerede fra initieringen av overføringen, idet det da er naturlig å anmode om toppteksten til den første pakke PCM i den første gruppe Gi i strømmen i den initiale videostrøm ISK. Dersom en del av videostrømmen IS allerede er lastet ned og dekodet, kan naturligvis søking og gjenfinning starte fra en inntreffende pakke Gk, idet sekvensen av bilder Fa,...Fp som ligger i klientens buffer da er bilder inneholdt i den foreliggende gruppes pakker. Det skal i den forbindelse bemerkes at bufferen i høyden lager et fåtall pakker, men bildene som foreligger på bufferen eksempelvis kan godt være fra den siste pakke i en gruppe Gk_i og fra den påfølgende gruppe Gk. Informasjonen om antall bilder og hoppdistanser dj må derfor hensiktsmessig kunne relateres til posisjonen til henholdsvis det første bilde Fa, dvs. bildet med lavest nummer i bufferen, og det siste bilde Fp, dvs. bildet med høyest nummer i bufferen, som vist på fig. 6a. Dette skal forklares nærmere med henvisning til flytskjemaet på fig. 6b.

I henhold til flytskjemaet på fig. 6b spørres det i trinn 601 om x<Fa. Dette betyr at det søkte bildet Fx i en strøm IS har lavere nummer enn F0 og i trinn 602 anmodes det derfor om toppteksten Hpc til den aller første pakke PCU i strømmen. I trinn 603 spørres det om x finnes blant bildene i denne pakke og er svaret ja, anmodes det om nyttelasten PL til pakken PLi.i i trinn 604 og dekoding av nyttelasten i trinn 605, hvoretter bildet Fx vil være funnet og prosessen stopper. Er svaret nei, spørres det i trinn 606 om x finnes blant bildene j som er omfattet av hoppdistansen dj som angitt i første pakke PCU og bildene i den påfølgende gruppes første pakke PC2,i. Et svaret ja, anmodes det i trinn 607 om toppteksten HPC til neste pakke, altså den annen pakke PClt2 både i strømmen IS og den første gruppe G| i strømmen IS. Det spørres så i trinn 608 om x er å finne blant bildenummerne n til denne pakken og dersom svaret er nei, skjer det en iterasjon i trinn 609 og prosessen gjentas for neste pakke PCijnext i trinn 608. Er svaret i ethvert tilfelle ja, anmodes det om nyttelasten til denne pakke i trinn 610 og i trinn 611 dekodes nyttelasten, hvoretter prosessen stopper. Er svaret i trinn 606 derimot at x ikke er inneholdt i j, fortsettes det til trinn 612, hvor det anmodes om toppteksten til den første pakke PCnext>] i den påfølgende gruppe Gnext, altså den annen gruppe i strømmen IS. Svares det i trinn 613 nei på spørsmålet om x er inneholdt i bildenummerne som er omfattet av hoppdistansen dj og bildene til den første pakke i den påfølgende gruppe Gnext+], i dette tilfelle altså den tredje gruppe i strømmen IS, går man i trinn 614 tilbake til trinn 612, idet det nå iterativt anmodes om den første pakke i den neste gruppe Gnext+1, altså i det angjeldende tilfelle den tredje gruppe 3. Er svaret i 613 derimot ja, anmodes det om toppteksten HPC til neste pakke PCnext i gruppen og er x ikke å finne blant bildenummerne naen til denne pakke, gås det via trinn 617 tilbake til trinn 615 og det anmodes om den neste påfølgende pakke, hvoretter prosessen fortsetter. Er derimot svaret i 616 ja, anmodes det om nyttelasten til den angjeldende pakke og i trinn 619 dekodes nyttelasten, hvoretter prosessen stopper.

Er svaret i trinn 601 nei, går prosessen til trinn 621 hvor det spørres om x er større enn nummeret til det siste bildet Fp i bufferen. Er svaret nei, betyr det at det søkte bildet Fx er å finne blant bildene i bufferen og derfor umiddelbart vil dekodes, hvorfor prosessen stopper. Er svaret derimot ja, dvs. at nummeret x til det søkte bildet Fx er større enn nummeret til Fp, anmodes det i trinn 622 om toppteksten til den påfølgende pakke PCk,T og det spørres i trinn 623 om x finnes blant bildenummerne i denne pakke. Er svaret ja, anmodes det i trinn 624 om nyttelasten HPC til pakken PCkf7, og i trinn 625 dekodes nyttelasten PLk>T, hvoretter prosessen stopper. Er svaret derimot nei i trinn 623, spørres det i trinn 626 om blokken J er å finne i toppteksten HPc til pakken PCk>T. Er svaret nei, gås det via trinn 627 tilbake til trinn 622 og det anmodes nå om toppteksten HPC til en neste påfølgende pakke PCk T+|, hvoretter prosessen fortsetter. Er svaret i trinn 626 derimot ja, spørres det i trinn 628 om nummeret x er inneholdt i j som angir bildenummerne omfattet av hoppdistansen dj og nyttelasten til første pakke PCk+1>1 i en påfølgende gruppe Gk+i. Er svaret i trinn 628 ja, anmodes det om toppteksten Hpc til den påfølgende pakke PCk>y+i i trinn 629 og i trinn 630 spørres det om jc er å finne blant bildenummerne i denne pakke. Dersom dette ikke er tilfellet, itereres det via trinn 631 og det anmodes om toppteksten til den neste påfølgende pakke, hvoretter prosessen fortsetter. Er svaret i trinn 630 ja, anmodes det om nyttelasten PLk Y+i til pakken PCk>Y+i i trinn 632 og i trinn 633 dekodes nyttelasten, hvoretter prosessen stopper. Er svaret i trinn 628 nei, anmodes det om toppteksten HPC til den første pakke PCk+u i den påfølgende gruppe Gk+i i trinn 634, og det spørres i trinn 635 om x er inneholdt i bildenummerne omfattet av hoppdistansen dj for gruppen Gk+j og den første pakke PCk+u i den påfølgende gruppe Gk+2. Er svaret nei, itereres det i trinn 636 tilbake til trinn 634 og det anmodes nå om toppteksten til den første pakke i den neste påfølgende gruppe, hvoretter prosessen fortsetter. Er svaret i trinn 635 ja, anmodes det om toppteksten HPC til neste pakke PCk+T next, altså om den annen pakke i gruppen Gk+Y i trinn 637, og er x ikke å finne blant bildenummerne i denne pakke, gås det via trinn 639 videre til neste pakke osv., hvoretter prosessen fortsetter. Er svaret i trinn 638 ja, anmodes det om nyttelasten PLk+iiIjext til pakken PCk+iinm i trinn 640 og nyttelasten dekodes i trinn 641, hvoretter prosessen stopper.

På den her angitte måte blir det mulig å finne et ønsket bilde Fx ved at pakken som rommer Fx, finnes og dekodes. Søkingen etter Fx kan initieres under overføringen av en strøm som vist på fig. 6b, men selvsagt også initieres allerede når selve overføringen av strømmen starter. Det er underforstått at det under søkingen vil være mulig å svitsje mellom strømmene IS ettersom kanalbitraten o varierer med bruk av fremgangsmåten til overføring i henhold til oppfinnelsen.

I forbindelse med både overføringen og søkingen genereres det og vedlikeholdes en stakkliste for HTTP-anmodninger. En anmodning kan da legges i stakklisten når den sendes fra klienten og fjernes først derfra etter at den mottatte respons fra HTTP-tjeneren er prosessert. Dersom det skjer et brudd i forbindelsen mellom HTTP-tjener og klient under overføringen av videoinformasjon, under mottak av responsen, kan anmodningen i stakklisten sendes på ny ved gjenopprettet forbindelse. Dersom det finner sted et brudd i forbindelse med mottaket av pakken, kan den første anmodning i listen oppdateres og begynnelsen av pakken da justeres for de eventuelt allerede mottatte data.

Claims (26)

1. Fremgangsmåte ved overføring på anmodning av videoinformasjon i en delt nettverkressurs, hvor den delte nettverkressurs spesielt er Internett, et intranett eller ekstranett, hvor videoinformasjonen er lagret i form av en kodet videofil på HTTP-tjenere i den delte nettverkressurs og aksesseres av klienter via HTTP (Hypertext Transfer Protocol), hvor hver klient har en videodekoder, og hvor fremgangsmåten med utgangspunkt i initial videoinformasjon i form av digitaliserte videosignaler er karakterisert ved at den omfatter trinn for å generere ved hjelp av en videokoder y multiple, kodede videostrømmer (VS) som hver rommer den initiale videoinformasjons videosignaler komprimert med gjennomsnittlige bitrater t[c] som dekker klientenes forventede kanalbitrater a, idet videokoderen genererer uavhengig dekodbare videobilder med gitte tidsintervaller; å generere y kodede mellomstrømmer (IS) fra de tilsvarende kodede videostrømmer (VS) ved å dele en kodet videostrøm i p pakker (PC) med varierende lengde q, idet hver pakke (PC) omfatter en topptekst (HPC) og en nyttelast (PL) som rommer de kodede videosignaler for et tidssegment som tilsvarer nyttelasten; å forsyne toppteksten (HPC) med følgende informasjon: (i) distansene dj og d^ henholdsvis til begynnelsen og slutten av den nærmest påfølgende pakke, (ii) antall n videobilder (F) som pakken inneholder, samt (iii) en referanse til den tilsvarende pakke i henholdsvis den kodede mellomstrøm (ISb) med den nærmestliggende lavere gjennomsnittlig bitrate t[ck-i] og den kodede mellomstrøm (ISa) med den nærmestliggende høyere gjennomsnittlig bitrate t[ck+i], idet t[ck] er bitraten for den foreliggende mellomstrøm (ISk) og k, b, a e y\ å anordne et uavhengig dekodbart videobilde (IF) ved begynnelsen av nyttelasten (PL) til en pakke (PC); å sammenkjede mellomstrømmene (IS) til en sluttfil (<E>) som lagres på en eller flere HTTP-tjenere; og å forsyne sluttfilen (4>) med en topptekst (HJ som rommer informasjon om parametrene til strømmene (IS); og dessuten ved følgende trinn iverksatt av klienten: å generere en anmodning om toppteksten (H„) og begynnelsen på den første strøm (ISi) i sluttfilen (O); å estimere kanalbitraten a og å velge den strøm (ISk) hvis bitrate t[ck] A er den i forhold til den estimerte kanalbitrate o nærmestliggende bitrate, som den initiale strøm i overføringen, slik t[ck]~ a, og deretter å estimere A kanalbitraten a under overføringen, og dersom estimatet o er lavere enn den gjennomsnittlig bitrate t[ck] til den foreliggende strøm (ISk), å svitsje til strømmen (ISb) med den nærmestliggende lavere gjennomsnittlige A bitrate t[ck.!], eller dersom estimatet o er høyere enn gjennomsnittlige bitrate t[ck] til den foreliggende strøm (ISk), å svitsje til strømmen (ISa) med den nærmestliggende høyere gjennomsnittlige bitrate t[ck+|], idet svitsjingen av strømmene skjer på basis av pakkereferansene og realiserer en båndbreddeskalerbar videooverføring over HTTP.

2. Fremgangsmåte i henhold til krav 1, karakterisert ved at den båndbreddeskalerbare videooverføring skjer over en versjon av HTTP som tillater vedvarende oppkobling og spesifisering av byteområde.

3. Fremgangsmåte i henhold til krav 1, karakterisert ved å estimere kanalbitraten a på basis av en A A estimator o = x/x, hvor o er den estimerte kanalbitrate og x antall bufrede A bit i tidsintervallet x, slik at dersom o > t[ck] og bufferlengde mindre enn to ganger minimum pakkelengde, svitsjes det til strømmen med en A nærmestliggende høyere målbitrate t[ca], eller dersom a < t[ck] og bufferlengde mindre enn minimum pakkelengde, svitsjes det til strømmen med en nærmestliggende lavere målbitrate t[cb].

4. Fremgangsmåte i henhold til krav 1, karakterisert ved estimere kanalbitraten a på basis av en estimator da = ~ d~ ty slik at dersom | o | 0, svitsjes det til strømmen med en nærmestliggende høyere målbitrate t[ca], eller dersom | o \ < 0 svitsjes det til strømmen med en nærmestliggende lavere målbitrate t[cb].

5. Fremgangsmåte i henhold til krav 4, karakterisert ved at det fastsettes en grenseverdi Ao , slik at svitsjing finner sted dersom | o j > Ao .

6. Fremgangsmåte i henhold til krav 1, karakterisert ved å estimere kanalbitraten a ved gjentatt å integrere kanalbitraten a over påfølgende tidsintervaller x = ta - tb, idet ta og tb henholdsvis er øvre og nedre grense for intervallet x og et integrasjonsresultat £ gitt ved S=.|adt, og å sammenligne integrasjonsresultatene 22, £[ for respektive påfølgende tidsintervall x2, Xi, slik at dersom 22 - I>\ > 0, svitsjes det til strømmen med en nærmestliggende høyere målbitrate t[ca], eller dersom S2 - 2j < 0, svitsjes det til strømmen med nærmestliggende lavere målbitrate t[cb].

7. Fremgangsmåte i henhold til krav 6, karakterisert ved at det fastsettes en grenseverdi AS, slik at svitsjing finner sted dersom 122 - Si | >A£.

8. Fremgangsmåte i henhold til krav 1, karakterisert ved å benytte en HTTP-tjener tilpasset HTTP-versjon 1.1.

9. Fremgangsmåte i henhold til krav 8, karakterisert ved at videooverføringen finner sted over HTTP-versjon 1.1.

10. Fremgangsmåte i henhold til krav 1, karakterisert ved å anordne pakkene (PC) i strømmene (IS) i ikke overlappende suksessive grupper (G) av to eller flere påfølgende pakker, slik hver strøm (IS) deles i m slike grupper, og å forsyne toppteksten til den første pakke (PC^i) i en gruppe (Gk, kem) med informasjon om en hoppdistanse dj som svarer til den samlede lengde av pakkene i gruppen (GJ og antall j bilder (F) som hoppdistansen dj og den første pakke i den påfølgende gruppe (Gk+i) omfatter.

11. Fremgangsmåte i henhold til krav 1, karakterisert ved å anordne strømmene (IS) slumpmessig i sluttfilen (O), og at strømmen (ISL) med lavest bitrate t[ciJ bare refererer til pakker i strømmen med den nærmestliggende høyere bitrate og strømmen (ISH) med høyest bitrate t[cH] bare refererer til pakker i strømmen med den nærmestliggende lavere bitrate.

12. Fremgangsmåte i henhold til krav 1, karakterisert ved å anordne strømmene (IS) suksessivt med stigende bitrate t[c] i sluttfilen (<J>), slik at strømmen (ISL) med lavest bitrate t[cL] utgjør den første videostrøm (ISi) i filen (d>) og strømmen (ISH) med høyest bitrate t[cH] utgjør den siste videostrøm (ISy) i filen (O).

13. Fremgangsmåte i henhold til krav 1, karakterisert ved at strømmene (ISb) og (ISa) rommer et uavhengig dekodebart videobilde (IF) ved posisjoner svarende til begynnelsen av hver pakke (PC) i en foreliggende strøm (ISk).

14. Fremgangsmåte i henhold til krav 1, karakterisert ved at de kodede strømmer (VS;IS) rommer det samme antall videobilder (F).

15. Fremgangsmåte i henhold til krav 1, hvor strømmene (IS) har forskjellig bilderate, karakterisert ved å definere et justeringsbilde (Fs) som en egen bildetype, og å justere hilderåtene i hver strøm (IS) til samme rate ved å innsette et passende antall justeringsbilder (Fs) i de respektive strømmer.

16. Fremgangsmåte i henhold til krav 1, karakterisert ved at pakkelengden q er høyst lik en konfigurerbar anmodningspause for HTTP-tjeneren.

17. Fremgangsmåte i henhold til krav 1, karakterisert ved å prosessere de kodede strømmer (IS) i parallell bilde for bilde.

18. Fremgangsmåte i henhold til krav 1, karakterisert ved at toppteksten (H,,,) til sluttfilen (<£) inneholder informasjon om antall y strømmer (IS) i filen, den gjennomsnittlige bitrate t[c] for hver strøm, og distansene dk og d\ fra sluttfilens begynnelse til henholdsvis begynnelsen av hver strøm og til slutten av den første pakke (PCi) i hver strøm (IS).

19. Fremgangsmåte i henhold til krav 1, karakterisert ved at klienten på basis av videostrømmenes parametre genererer undermengder av strømmene (IS), idet svitsjing mellom strømmene (IS) bare kan finne sted i disse undermengder.

20. Fremgangsmåte i henhold til krav 1, karakterisert ved å generere og vedlikeholde en stakkliste for HTTP-anmodninger, idet en anmodning legges i stakklisten ved sending og fjernes derfra etter prosessering av den fra HTTP-tjeneren mottatte respons, og at anmodningene i stakklisten sendes på ny ved gjenopprettet forbindelse etter et eventuelt brudd i forbindelsen mellom HTTP-tjener og klient under mottak av responsen.

21. Fremgangsmåte i henhold til krav 20, karakterisert ved å oppdatere den første anmodning dersom et brudd i forbindelsen finner sted under mottak av en pakke (PC), idet begynnelsen av pakken (PC) justeres for de eventuelt allerede mottatte data.

22. Fremgangsmåte til klienteksekvert søking og gjenfinning av videoinformasjon i en delt nettverkressurs, spesielt søking og gjenfinning av et ønsket bilde (Fx) i en videostrøm, hvor den delte nettverkressurs spesielt er Internett, et intranett eller ekstranett, hvor videoinformasjonen er lagret i form av en kodet videofil på HTTP-tjenere i den delte nettverkressurs og aksesseres av klienter via HTTP (Hypertext Transfer Protocol), hvor hver klient har en videodekoder, hvor den kodede videofil (O) er sammenkjedet av multiple, kodede videostrømmer (IS) som rommer videoinformasjonens videosignaler komprimert ved gjennomsnittlig bitrater t[c] som dekker klientenes forventede kanalbitrater a, hvor hver kodet videostrøm er delt i p pakker (PC) med varierende lengde q, hvor hver pakke (PC) omfatter en topptekst (HP) og nyttelast (PL), hvor pakkene (PC) i en strøm (IS) er anordnet i ikke-overlappende, suksessive grupper (G) av to eller flere påfølgende pakker, slik at hver strøm (IS) deles i m slike grupper, hvor toppteksten (HPC) til den første pakke (PCKii) i hver gruppe (Gk, kem) i tillegg til informasjon om antall n videobilder som pakken inneholder og referanser til andre pakker og strømmer, forsynes med informasjon om en hoppdistanse dj som svarer til den samlede lengde av pakkene i gruppen og antall j bilder (F) som hoppdistansen dj og den første påfølgende pakke (PCfe+i, j) i den påfølgende gruppe (Gk+() omfatter, hvor videofilen (O) dessuten omfatter en topptekst (H,,) som rommer informasjon om parametrene til strømmene (IS), hvor informasjonen om strømmenes (IS) parametre inkluderer distansene dk og d/ fra videofilens (<J>) begynnelse til henholdsvis begynnelsen av hver strøm (IS) og til slutten av den første pakke (PCi) i hver strøm (IS), hvor overføringen av videoinformasjon skjer båndbreddeskalert, og hvor fremgangsmåten er karakterisert ved å generere en anmodning til HTTP-tjeneren om nedlasting av toppteksten (Hp) til den første pakke (PCkfi) i en gruppe (Gk, ke m)) i en videostrøm (ISk, ke y) å sammenligne nummeret x til det ønskede bilde (Fx) med j, og dersom xe j, å gjenoppta overføringen og dekodingen av videostrømmen fra og med første bilde i pakken hvor bildet (Fx) befinner seg, idet denne pakke er en av pakkene i gruppen (Gk) samt den første pakke (PCk+i,i) i den påfølgende gruppe (Gk+i), eller dersom xe j, å anmode om toppteksten (HP) til den første pakke (PCk+u) i den påfølgende gruppe (Gk+i), og eventuelt å fortsette prosessen inntil det ønskede bilde (Fx) er funnet, hvoretter nedlasting og dekoding av strømmen (IS) gjenopptas fra og med første bilde i pakken hvor det ønskede bilde (Fx) befinner seg, slik at det realiseres en bildebasert og pakkeformatert søking og gjenfinning av videoinformasjon med bruk av HTTP som transportprotokoll.

23. Fremgangsmåte i henhold til krav 22, karakterisert ved at det benyttes en versjon av HTTP som tillater vedvarende oppkobling og spesifisering av byteområde.

24. Fremgangsmåte i henhold til krav 22, karakterisert ved å generere og vedlikeholde en stakkliste for HTTP-anmodninger, idet en anmodning legges i stakklisten ved sending og fjernes derfra etter prosessering av den fra HTTP-tjeneren mottatte respons, og at anmodningene i stakklisten sendes på ny ved gjenopprettet forbindelse etter et eventuelt brudd i forbindelsen mellom HTTP-tjener og klient under mottak av responsen.

25. Fremgangsmåte i henhold til krav 24, karakterisert ved å oppdatere den første anmodning dersom et brudd i forbindelsen finner sted under mottak av en pakke (PC), idet begynnelsen av pakken (PC) justeres for de eventuelt allerede mottatte data.

26. Fremgangsmåte i henhold til krav 22, karakterisert ved å benytte en HTTP-tjener tilpasset HTTP-versjon 1.1, og at HTTP-versjon 1.1 benyttes som transportprotokoll.