Oblig3-Gruppe1)
Fra Hiofwiki
Innhold |
Innledning
Hva er streaming? En teknikk for overføring av data. Denne sørger for at den datamengden som skal sendes/mottas hele tiden er forholdsvis lik gjennom hele prosessen. Teknologier for streaming har de siste årene blitt viktigere og viktigere etter som Internett har vokst. De fleste brukerene har ikke kjapp nok tilkobling til å laste ned store video og musikk-filer uten at det tar irriterende langt tid. Når man bruker streaming kan man med en nettleser og riktig avspiller og plug-in begynne å se/høre den delen av filen mens den overføres. Dette betyr at hvis streamingklienten mottar data fortere enn nødvendig, må overflødig data lagres i en "buffer". Hvis klienten ikke mottar nok data derimot, vil ikke presentasjonen av dataen kjøres uten at det hakker og stopper opp. En mediastrøm kan enten være "on demand" eller live (sanntidsstrøm). On demand-strømmer blir lagret på en server i lang tid og kan overførest om brukeren ønsker det. Sanntidsstrømmer er bare tilgjengelig én gang, til et spesielt tidspunkt, som f.eks en live videostrøm fra en fotballkamp.
Noen av fordelene med (live)streaming er dataen ikke lagres hos klientene når de har blitt lastet ned, og kan fjernes etter kort tid. Man trenger ikke å vente på å se/høre filen fordi ikke hele filen trenger å lastes ned. Det er også negative sider ved streaming: det krever veldig mye båndbredde, og i de tilfeller der flere brukere vil spille av en fil samtidig må de dele på båndbredden. Man er heller ikke garantert topp kvalitet, siden avsenderen ofte ikke har kontroll på overføringen.
Sanntidstreaming med multicast
Vi begynte med å laste ned og installere Quicktime Broadcaster. Vi brukte en Powerbook G4 og et mini dv videokamera til å streame med. I Broadcaster krysset vi av på "multicast" på spørsmålet om transmission og fikk generert ip-adresser. Henrik ekporterte en videofil til sdp format og prøvde å sende den til våre maskiner. Vi fikk til å spille av filen i Quicktime og det funket. Mens vi gjorde denne delen av obligen var vi koblet opp til nettverket med kabel, vi prøvde også å gjøre det trådløst, men fant senere ut at Multicast ikke har støtte for trådløst nettverk.
On demand-streaming med RTSP
Praktisk gjennomføring og problemløsning
Sandra lastet ned Darwin Streaming Server (heretter kalt DSS) fra apple sine sider. Samtidig konverte Henrik et kort videoklipp til hintet MPEG-4. Etter at Sandra hadde innstallert DSS la hun inn videoklippet i mappa "movies" under QuickTimeStreaming. Når Sandra startet opp DSS første gang la hun inn brukernavn og passord. Vi valgte ikke å hake av SSL men valgte å huke av port 80 slik at innholdet også kunne nåes utenfor det lokale nettverket (altså internett). Deretter fikk vi opp at hovedvinduet igjen og det sto da øverst i vinduet "Server is Running". Nå prøvde vi med en annen maskin og koble oss til innholdet på streaming-serveren (maskinen til sandra) via "åpne URL" i Quicktime Player. Adressen vi brukte var rtsp://pc162-253.hiof.no/robotboy.mp4. "robotboy.mp4" var den hintede filmen vi hadde lastet opp. Dette fungerte ikke, så vi forsøkte også rtsp://pc162-253.hiof.no/sample_300kbit.mov som var en annen fil som skulle ligge i samme mappe, men dette fungerte ikke. Til slutt prøvde vi å legge ved informasjon om porten (slik det sto i adresse-linjen på Safari når vi var inne på serveren) slik: rtsp://pc162-253.hiof.no:1220/sample_300kbit.mov. Heller dette fungerte ikke, så da begynte vi å søke litt etter svar på nettet.
Da fant vi en side som mente at det var en veldig dårlig ide å hake av port 80 under innstallasjonen av serveren. Vi tok derfor vekk dette alternativet igjen. Dette ville føre til at strømmen ville kreve å bli åpnet av standard-porten for RTSP som var 554. I samme slengen endret vi hvilke porter mp3 ville bruke ved streaming da Icecast ville bruke samme port (port 8000). Dette gikk vi manuelt inn i /Library/QuickTimeStreaming/Config/streamingserver.xml og endret. MP3 er satt til å bruke portene 8000 og 8001. Vi endret disse til 9000 og 9001 slik at de ikke kom i konflikt med Icecast som bruker 8000. Dette er kanskje ikke nødvendigvis nødvendig for å gjennomføre obligen, men på tidspunktet vi gjorde det så fulgte vi bare guiden slavisk uten egentlig å vite hva vi gjorde, så derfor ble det gjort!
Etterpå måtte vi restarte DSS, noe som måtte gjøres i Terminal. Vi brukte kommandoen "ps -ax | grep QuickTimeStreamingServer"
Det ga følgende svar:
231 ?? Ss 0:00.00 /usr/sbin/QuickTimeStreamingServer 232 ?? S 0:20.60 /usr/sbin/QuickTimeStreamingServer 3024 p1 S+ 0:00.01 grep QuickTimeStreamingServer
Deretter kjørte vi kommandoen "sudo kill 231 232". Til slutt startet vi DSS igjen med denne kommandoen "sudo QuickTimeStreamingServer".
Nå kunne vi nå strømmen vår via adressen "rtsp://pc162-253.hiof.no/robotboy.mp4" og det fungerte akkurat som beskrevet.
Hvorfor hintet MPEG-4
Man må benytte hintet MPEG-4 ved streaming fordi DSS bruker det hintede sporet i MPEG-4 filen til å finne ut hvordan den skal dele opp innholdet i RTP-pakker. Prosessen med hinting kan ikke gjøres av serveren selv da det bruker veldig mye tid . Ved å gjøre det med selve filen på forhånd slipper man samtidig å gjøre det mer enn en gang. Dersom serveren skulle gjort hintingen ville det i tillegg til at det tok lang tid, måtte gjøres hver gang en fil ble forespurt.
Sanntidstreaming med RTSP
Quicktime Broadcaster er allerede lastet ned, så her er det bare å kjøre på! Vi kobler til videokameraet og krysser i stedet av for “Automatic Unicast (Announce)” under Transmission. Host name “pc162-253.hiof.no” blir generert og vi skiver inn “gruppe1” som filnavn. Nå er det bare å skrive inn adressen rtsp://pc162-253.hiof.no/gruppe1.sdp i for eksempel Quicktime eller en annen videoavspiller, og denne gangen fungerer det også over det trådløse nettverket.
Under sanntidsstreaming er det ofte trafikkbesparende å bruke multicasting. Grunnen til dette er at man da kun trenger å sende ut en strøm, så sprer routeren med støtte for multicasting dataen ut til enten flere routere eller brukere som har bedt om å motta datastrømmen. Det kreves derfor ikke alt for mye av nettkapasiteten til avsenderen. Ved unicasting derimot, sender avsenderen ut én strøm per mottager, og hvis det er for mange mottagere, strekker ikke båndbredden til. Det finnes likevel ganger når det er nyttig å bruke unicast. Ved få eller ingen mottagere er unicast foretrukket, for man sender sa kun ut data når noen ber om å motta den. Ved multicasting sender man konstant ut data, noe som virkelig er sløseri så lenge ingen mottar den.
Bruk av RTSP gjør også at man kan nå alle brukere av Internettet. Ettersom ikke alle routere støtter multicasting er det heller ikke mulig å nå alle ved å bruke denne metoden. RTSP er derfor ofte brukt ved broadcaster og audio/video ondemand streaming.
Mottagerene av unicast kan også kontrollere strømmen selv. De kan pause sendingen, spole og lagre sendingen, noe som ikke er mulig ved bruk av multicast.
Publisering med BitTorrent
Vi lagde en ny torrent og brukte den åpne piratebay trackeren. Så sendte vi torrent-fila til alle på gruppa. Noen på gruppa brukte BitTorrent og andre brukte Transmission. Det fungerte for alle.
“BitTorrent (av «torrent» – strid strøm, storm) er et p2p-system å distribuere filer i et nettverk. BitTorrent ble kjent ved å gjøre det mulig for mange brukere å laste ned samme filer uten at det går tregere for andre. Dette oppnåes ved å tvinge alle som laster ned til å også laste opp deler av fila de har med andre som laster ned, så hvert medlem i en «sverm» bidrar til distribusjonen av innholdet.” 4
“Siden BitTorrent er en peer-to-peer protokoll hvor brukerene laster ned fra hverandre vil den orginale utgiveren ha behov for mindre båndbredde med vanlig web-publisering, noe som gjør det tilgjengelig for flere som ikke har ressurser til å publisere video på vanlig måte.” 5
Hvordan kan BitTorrent-publisering spare ressurser for en innholdsleverandør som f.eks. NRK eller Ubuntu?
NRK sparer penger ved å gi det ut på BitTorrent! De slipper båndbredde-kostnader ved å bruke denne metoden. Bittorrent gjør at NRK kan sende programmer i høy kvalitet, til og med høyere kvalitet enn i ordinære tv-sendinger, uten at deres servere kneler. Alle som laster ned hjelper samtidig til med å laste programmet opp til andre. Ved å bruke bittorrent kan NRK tilby programmer i HDTV-kvalitet. Altså kan vi se NRK-programmer som er tilgjengeliggjort via bittorrent når det passer oss og i høyere kvalitet enn når programmet går live på tv-en.
Referanser
1 http://developer.apple.com/opensource/server/streaming/qtss_admin_guide.pdf
2 http://www.geektimes.com/macintosh/os/x/10_3/and/dss_install.html
3 http://lists.apple.com/archives/Streaming-server-developers/2001/Dec/msg00016.html
