ITM30408 Gruppe5 Oblig3
Fra Hiofwiki
Innhold |
Oblig 3 - Dataformidling og nettverk : Streaming
Innledning
Å vise og streame media på datamaskiner har vært forsøkt siden midten av 1900-tallet. På grunn av begrensede dataressurser og høye kostnader har utviklingen uteblitt. Forsøk i akademiske miljøer på 70-tallet viste at det likevel var mulig, men de første streamingløsningene så ikke dagens lys før på 90-tallet. Høyere båndbredde og nye nettverksprotokoller som TCP/IP og HTTP gjorde dette mulig sammen med en kommersialisering av nettet.
Det finnes 2 metoder for streaming: On-demand og sanntids-streaming (live). Sanntids-streaming gjør det mulig å direkte sende strømmer mye på samme måte som når tv-stasjoner kringkaster direktesendinger. On-demand-streaming sender mediastrømmer som allerede er produsert og som må lagres på klientens pc før denkan sees. Ved hjelp av buffering kan man allikevel etter en liten forsinkelse se strømmen mens den lastes opp i en buffer.
Unicast og Multicast protokoller benyttes for streaming. Unicast-protokollen sender separate strømmer fra en server til hver enkelt klient. I sin enkelhet fører disse ofte til stor redundans i nettet.
Multicast-protokollen sender data til virtuelle IP multicast-adresser eller multicast-grupper. En server gir beskjed om hvilken multicast-adresse klientene kan benytte seg av. Når klienten spør etter den bestemte multicast-adressen, blir det opprettet et distribusjons-'tre' for overføring av strømmene. Fordelen med en slik løsning er at sendere og mottakere ikke trenger å vite om hverandre. Det er derfor mulig å motta strømmer fra flere forskjellige noder i nettverket og dermed spare båndbredde. [Wikipedia]
Oppgaver
Sanntidstreaming med multicast
Vi installerte QuickTime Broadcaster (QTBC) på en Mac G4 PowerBook og satte opp denne til å sende videofeed fra et tilkoblet iSight-kamera over nett med h.264 over multicast. QTBC har en funksjon for å generere IP og portnummer for streaming over multicast. Vi eksporterte en SDP-fil (Session Desciption Protocol) fra QTBC og kopierte denne til maskinen som skulle ta i mot strømmen med en streaming klient. Til dette prøvde vi både VLC og QuickTime (QT), som begge fungerte OK. Streaming fungerte når server og klient var på samme nettverk, tilkoblet med TP-kabel. Dersom en av maskinene var tilkoblet høgskolens WLAN, gikk det ikke. Årsaken er at RTSP (Real Time Streaming Protocol) data ikke slipper igjennom på den trådløse delen av Høgskolens nettverk.
Innholdet i DSP-filen:
v=0 o=- 182 98424098 IN IP4 127.0.0.0 s=QuickTime t=0 0 a=range:npt=now- m=audio 5432 RTP/AVP 96 c=IN IP4 234.96.104.130/15 b=AS:63 a=rtpmap:96 mpeg4-generic/22050/1 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1388 a=mpeg4-esid:101 m=video 5434 RTP/AVP 97 c=IN IP4 239.170.58.202/15 b=AS:1000 a=rtpmap:97 X-QT/90000 a=cliprect:0,0,240,320 a=framesize:97 320-240
On demand-streaming med RTSP
Vi lastet ned og installerte Darwin Streaming Server (DSS) på en Mac G4 PowerBook og satte opp denne. DSS har et webgrensesnitt som er tilgjengelig på port 1220. Serveren må startes derfra, i tillegg til broadcast-funksjonen. Sistnevnte skal kunne fjernstyre QTBC, men det forårsaket bare en feilmelding fra et Perl-script. Veien rundt er å benytte QTBC direkte. Vi opprettet en Media Playlist i DSS, laget et videoklipp i QT ved bruk av iSight-kameraet, og la dette i mediafolderen til DSS. Start av playlist feilet, da det viste seg at klippet ikke var hintet. Da QT ikke utfører hinting by default, måtte vi inn og eksportere filen på nytt, denne gangen tilrettelagt for streaming og optimalisert for server. D'oh. Vi koblet oss deretter opp mot DSS-serveren fra QT på en annen maskin, og åpnet strømmen derfra fra en URL på formatet rtsp://servernavn/test.mp4.
Hinting av MPEG-4-filer for publisering via Darwin Streaming Server
Hinting av en MPEG-4-fil medfører at filen som streames tilføres metadata som forteller serveren hvordan den skal dele filen inn i pakker for levering. Tilstedeværelsen av slik metadata betyr at serveren ikke trenger å vite alt om video- og lyd-sporene i filen, da metadata-informasjonen gir nøyaktige instrukser på hvordan filen skal streames.
Med denne framgangsmåten trenger ikke serveren å kunne mer enn å lese instruksene fra fila om hvordan den skal deles og leveres. Hvis serveren skulle ha delt og beregnet hvordan filen skulle leveres for hver eneste forespørsel, ville dette tatt opp unødvendig mye ressurser og tid. Ved å legge denne informasjonen i en fil trengs det bare å gjøres en gang. Akkurat som QuickTime er MPEG-4 en container for forskjellige mediaobjekter, det kan være lydspor, videospor og bilder som også kan være av forskjellige formater. Hintingen forteller hvordan disse elementene skal spilles i forhold til hverandre når man streamer.
Hvis man laster ned en fil som har et hint-spor og spiller av denne i et vanlig avspillingsprogram blir hint-sporet ignorert da det ikke trengs. Dette sporet øker derimot filstørrelsen og derfor bør man ikke bruke hinting hvis man ikke behøver det (les: ved vanlig nedlasting av film/lyd).
Sanntidstreaming med RTSP
Vi koblet et iSight-kamera til en Mac G4 PowerBook, og startet QTBC. Vi konfigurerte applikasjonen til å sende audio og video over RTSP som Automatic Unicast til IP-adressen på maskinen som kjørte DSS. QTBC kan ikke alene sende unicast-strømmer til klientapplikasjoner, men må gjøre dette via en server som DSS (eller QuickTime Streaming Server (QTSS)) som mangfoldiggjør strømmen(e) slik at flere brukere kan laste ned disse samtidig. Vi brukte VLC og QT som klienter til å hente ned unicast-strømmen fra en URL på formatet rtsp://servernavn/uni.sdp
Når er det nyttig å bruke RTSP i stedet for multicast til sanntidstreaming?
Det er nyttig å bruke RTSP når man vil gi brukerne kontroll over avspillingen. Dette får man ikke med multicast da det er samme strømmen som går ut til alle som er koblet på. RTSP går over unicast hvorav alle brukerne får hver sin strøm. Dette belaster serveren mer enn multicast men gir brukeren full kontroll over sin strøm.
En multicast strøm krever like mye båndbredde som en unicast strøm. Derfor, om man har lite linjekapasitet eller tar forbehold om mange brukere bør man gå for multicast. Har man derimot en liten brukerbase og/eller gode linjer kan man bruke RTSP (unicast).
Man kan se på multicast som en tv-kanal. Alle kan skru på kanalen og få servert innholdet, men man har ingen kontroll over avspillingen. RTSP (unicast) kan man sammenligne med å sette på en film, her kan man kontrollere avspillingen selv men dette krever at alle må ha hvert sitt eksemplar av filmen.
Publisering med BitTorrent
Vi genererte først en torrent-fil med Tomato Torrent på en Mac G4 PowerBook, og satte deretter opp applikasjonen som tracker på den samme maskinen. Så kopierte vi torrent-filen over til en annen maskin på labben, og forsøkte vi å laste ned innholdet i torrenten derfra ved bruk av Tomato Torrent som klient. Av ukjente årsaker fungerte ikke dette. Vi installerte derfor Azureus på PowerBook-maskinen. Azureus er en kombinert BitTorrent klient og tracker (server). Etter diverse instillinger i applikasjonen fikk vi konfigurert denne til å fungere som tracker. Så laget vi en torrent av en videofil, og satte Azureus til å hoste denne torrenten via den innebygde trackeren. Ved å gå på en annen maskin på labben og koble oss til announce IP for maskinen som kjørte Azureus, fikk vi lastet ned torrent-filen fra den innebygde webserveren, og gjennomført fullstendig nedlasting av videofilen ved bruk av Tomato Torrent som klient.
Hvordan kan BitTorrent-publisering spare ressurser for en innholdsleverandør som f.eks. NRK eller Ubuntu?
Ved å distribuere innhold over BitTorrent kan folk laste ned fra andre brukere i steden for at alle må belaste serveren(e) til leverandøren. Dette krever mindre båndbredde ut fra leverandøren som igjen vil si lavere kostnader både i forhold til mindre/lavere linjer ut og mindre serverpark for å ta hånd om alle forespørselene.
Som denne artikkelen beskriver (nrkbeta) har NRK spart masse penger på å ta i bruk P2P-teknologi (her: BitTorrent) for å dele 'Lars Monsen'-serien. Tallene de opererer med er at estimerte 10 000 personer har lastet ned alle 8 episodene av 'Lars Monsen'-serien, som tilsier 80 000 x 630 MB = 50 TB med data! Skulle de satt bort all denne distribusjonen til Amazon S3 (Amazon Web Services og deres støtte for BitTorrent i systemet de kaller Simple Storage Service) ville totale kostnader kommet på 50 000 GB * $0.16 pr GB = ca 41 000,-
Totale kostnader ligger derimot på ca 1700,- for all distribusjon! Det er usle 4% av hva det ellers ville kostet og bruke ”gammel” distribusjonsmåte. Brukerene får også høyere nedlastingshastigheter når trafikken deles utover i hele nettet ved bruk av BitTorrent enn dersom hver enkelt bruker hadde måttet laste ned hver sin kopi av filene fra en server i kjelleren til NRK.
Og for Ubuntu er tallene enda høyere da flere brukere laster ned Ubuntu-distribusjonen enn 'Lars Monsen'-serien. Her fant vi dessverre ingen spesifikke tall å henvise til, men har hentet ut trafikkdata fra alexa.com.
Som grafen viser har ubuntu.com gjennomsnittlig dobbelt så mange treff som nrk.no. Dette er ikke reellt ovenfor antall nedlastninger av Ubuntu-distribusjonen men viser litt om trafikken til sidene og hvor store brukerbasene er.
