ITM30408 gruppe3 oblig3
Fra Hiofwiki
Innhold |
Oblig 3
Sanntidstreaming med multicast
Først lastet vi ned og innstallerte QuickTime Broadcaster. Vi brukte en Mac med innebygget kamera, slik slapp vi og løpe ned til Hans Olav og låne oss et kamera, og valgte at vi skulle streame med det. På transmission valgte vi mulitcast, og genererte IP Adresser automatisk. Deretter eksporterte vi en sdp-fil som vi sendte til en annen mac via IM. Dette fungerte fint, mottaker maskinen åpnet sdp filen (vi prøvde også med .mov filer) i quicktime player og fikk se streamen med 3-4 sekunders delay. For å teste, tok vi med denne macen opp til 2. etasje, mens macen som streamet satt på et datarom i D-blokka, dette fungerte også veldig fint. I tillegg til og prøve med Quicktime Player, prøvde vi og spille av streamen i VLC noe som også fungerte fint.
Vi testet også og se på en multicast stream over det trådløste nettet ved og åpne .sdp fila på en maskin som ikke var koblet til med kabel, da fikk vi aldri koblet til og streamen startet da aldri. Vi prøvde og finne ut hvorfor det ikke fungerte, men eneste vi fant ut var at det ikke var støtte for det i det trådløse nettet til høgskolen. Det er tydeligvis ikke vanlig og ha støtte for det i trådløse nett. Noe av grunnen til dette er at det krever veldig mye båndbredde, noe det trådløse nettet har begrenset av og det er større sjangse for bit-errors i motsetning til et kablet nettverk.[Kilde]. Det er tatt høyde for multicast i 802.11 standarden, men det er ikke veldig utbredt, noe av grunnen trur vi er at det er veldig komplekst og sette opp.
On demand-streaming med RTSP
Som fortalt i oppgaven, lastet vi først ned Darwin Streaming Server. Vi forsøkte først å få den til å fungere på OS X 10.5 Leopard, men der serveren ville ikke starte. Vi lastet den deretter ned på en Mac som kjørte OS X 10.4 Tiger, og da funkerte det bra.
Etter vi hadde logget inn, var det å klargjøre en film til publisering. Vi tok en film i MPEG-4-format og eksporterte den med hinting. Denne la vi i mappen QuickTimeStreaming/movies under Biblioteket. Det første prøvde var å lage en playlist, og det så ut til å fungere på serveren. Men vi hadde problemer med å la andre få se på denne fila.
Etter å ha prøvd utallige forskjellige metoder, måtte vi tilslutt få litt hjelp fra Audun. Det første vi måtte gjøre var å stoppe streamingserveren via Terminal, fordi den ikke lot seg stoppe i webgrensesnittet. Deretter måtte vi også starte den fra termial. For å få tak i filmen som vi hadde lagt ut, trengte vi ikke å bruke playlist, men bare skrive inn adressa og fila vi ønsket å få tak i, i QuickTime: rtsp://127.0.0.1/sara_320.mp4
Dette fungerte fint og alle maskinene vi prøvde klarte og se fila uten problemer.
Forklar kort hvorfor det er nødvendig å hinte MPEG-4-filer før publisering med DSS
En film som er hintet, får to tracks i tillegg til vanlig lyd og video. I disse trackene ligger informasjon (metadata) som er nødvendig for publisering med DSS. De hintede trackene inneholder instruksjoner som streamingserverene bruker til å vite blant annet hvordan de skal pakke dataene til streamen. Når filmen er hintet kan streamingserveren streame filmen uten å bry seg om hvilken medietype eller codec som filmen er kodet i. Serveren trenger heller ikke å oppdateres hver gang en ny codec skal streames. På den måten kan streamingserveren bare tenke på hvordan den skal publisere filmen i forhold til nettverk og protokoller.
Kilde: [DSSguide]
Sanntistreaming med RTSP
Første dagen vi jobbet med dette, så fikk vi ikke til on demand-streaming med RTSP, og heller ikke sanntidstreaming med RTSP. Vi brukte QuickTime Broadcaster til å logge inn på RTSP serveren og sende det som lå der. Men vi fikk error hele tiden. Dette måtte da Audun hjelpe oss med. Det første som vi ikke hadde gjort var å lage en ny bruker på streaming serveren som fikk lov til å styre broadcasten. Da klarte vi å se filmen på den maskinen som serveren kjørte på. Men fortsatt klarte ikke andre maskiner å koble seg på eller å få kontakt med macen. Det viste seg å være så enkelt som at det sto på en brannmur på maskinen med serveren på. Når den brannmuren var av, så funket også dette.
Når er det nyttig å bruke RTSP i stedet for multicast til sanntidstreaming?
Når vi publiserer noe med multicast, sender man bare en fil eller informasjon til et antall noder samtidig. Dette er også det mest effektive når det gjelder å sanntidstreame, for man trenger bare å sende en stream og dermed har alle nodene i mulitcast tilgang til streamen. Men det kan likevel være nyttig å bruke RTSP i stedet for mulitcast til sanntidstreaming, for med multicast når man bare de brukerne som er koblet til multicastnettet. Multicast i felles miljøer hvor alle rutere er koblet til multicastnettet kan spare en masse tid på båndbredden. Men dersom man ønsker å nå alle som er på internett kan man bruke RTSP. RTSP er også nyttig for store broadcaster og audio/video ondemand streaming.
RTSP gir også muligheten til å kontrollere multimedia sendingene som blir levert ved hjelp av videospiller-lignende kontrollfunksjoner, som for eksempel det å sette på pause, spole forover og bakover, opptak, osv. Med dette kan RTSP også ta opp det som blir vist.
RTSP tar fordel i streamingen som bryter opp dataen i mange pakker i den størrelsen som passer båndbredden mellom klienten og serveren. Når nok pakker har blitt mottatt av klienten, kan brukerens software spille én pakke, pakke opp en annen, og laste ned den tredje. Brukeren har mulighet til å begynne å høre/se nesten med en gang uten å ha mottatt hele medie-filen.
Kilde: RTSP
Publisering med BitTorrent
Vi lastet ned Azureuz og brukte det som en BitTorrent tracker. Denne prosessen i seg selv var overraskende enkel. Når vi hadde satt opp trackeren med riktig IP-adresse og de portene vi ønsket og bruke var trackeren klar til bruk. Vi laget deretter en Torrent (.torrent) med Azureuz av NRKs serie Nordkalotten som allerede kan lastes ned via BitTorrent fra NRK Betas nettsider. Før vi viste om Azureuz sin torrent tracker nettportal distribuerte vi .torrent filen til de andre på gruppa via filoverføring. Men senere fant vi ut at Azureuz automatisk lager en torrent tracker nettportal og publiserer torrents du lager på denne portalen, dette gjør distribuering av .torrent filene veldig enkelt.
Vi testet nedlasting av .torrent filene med to forskjellige klienter på Mac OS X 10.4 Tiger og det fungerte utmerket på begge. Klientene vi brukte var Transmission og den offisielle BitTorrent klienten. Vi opplevde ingen store problemer med BitTorrent delen og vi ble overrasket over hvor enkelt man faktisk kan sette opp en tracker selv. Selv om Azureuz sin tracker ikke er den mest effektive eller beste Trackeren fungerer den fint til "amatør" bruk.
BitTorrent teknologien er en veldig mye omtalt teknologi, og den har desverre fått et litt dårlig rykte på seg. Grunnen til dette er at piratnettverkene har skjønt at dette er en utrolig effektiv og skalerbar teknologi. Det er stort sett pirater som har tatt i bruk denne distribusjonsteknologien og den har dermed fått et litt frynsete rykte på seg. Men det er heldigvis ikke bare piratkopiert materiale man kan laste ned via BitTorrent. De aller fleste Linux distribusjoner bruker BitTorrent som et alternativ for nedlasting av sine distribusjoner.
BitTorrent fungerer slik at alle som laster ned filen også automatisk deler denne filen til andre nedlastere, det er altså et P2P (Peer 2 Peer) nettverk. Dette gjør at teknologien er utrolig skalerbar, jo flere som laster ned jo kraftigere blir "serveren" som distribuerer filen også. Og siden filene man ønsker og distribuere blir delt av brukerene som laster ned er det potensiale for distributøren og spare masse penger. Det er lettest og beskrive dette med eksempel, og det er her NRK Beta kommer inn.
NRK Beta er noe NRK har startet med for lettere å kunne teste nye muligheter innenfor teknologi. De gjorde et omfattende prosjekt med BitTorrent da de valgte og distribuere TV serien med Lars Monsen, Nordkalotten 365, med BitTorrent. Prøveprosjektet har fått utrolig mye omtale og positive tilbakemeldinger både innenlands og utenlands. Etter at serien hadde ligget ute for nedlasting en god periode, la de ut en rapport som sier noe om kostnadene ved BitTorrent distribuering.
Når rapporten ble skrevet hadde de hatt ca 80 000 nedlastinger à 630 MB, noe som tilsvarer ca 50 TB med data. I en typisk situasjon måtte man betalt for den båndbredden det kreves for og distribere 50 TB med data. Men siden de brukte BitTorrent stod deres servere (de "leide" servere hos Amazon) for bare ca 4% av all distribusjonen, altså har de også bare betalt for ca 4% av den totale kostnaden. NRK Beta brukte Amazon S3 som torrent tracker noe som koster $0,16 pr. GB. Hadde de selv stått for all distribusjonen hadde det kostet de ca 41 000,-, men siden de brukte BitTorrent og dermed avlastet Amazon sine servere til fordel for brukernes deling har de betalt hele 1700 kroner for distribusjon av ca 50 TB med data.
Som Eirik Solheim fra NRK Beta selv skriver: "Hadde jeg vært en knivselger ville jeg kalt det 96% rabatt…"
Dette er et godt eksempel på hvordan det kan være store økonomiske fordeler ved bruk av BitTorrent fremfor andre og mer tradisjonele distribusjonsteknologier. Les hele rapporten fra NRK Beta her. I etterkant av NRKs prøveprosjekt har vi sett at det har inspirert flere til og bruke BitTorrent, f.eks CBC
