Faculteit Ingenieurswetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout
Implementatie van een streaming extensie voor The Core Pocket Media Player door Bart Defauw
Promotor: Prof. Dr. Ir. R. Van de Walle Scriptiebegeleider: Lic. C. Poppe
Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de Informatica
Academiejaar 2006–2007
Dankwoord In de eerste plaats zou ik mijn promotor prof. dr. ir. Rik Van de Walle en mijn begeleider Chris Poppe willen bedanken voor het aanbieden van dit onderwerp. Chris wil ik zeker ook bedanken voor de tijd die hij voor me vrijgemaakt heeft en de hulp om me in de goede richting te sturen. Tevens wil ik Frederik De Keukelaere bedanken voor de raad die hij me vorig jaar heeft gegeven. Mijn ouders wil ik ook bedanken omdat ze me de kans geven om deze opleiding te volgen en deze thesis te maken. Voor de steun die ze me gegeven hebben ben ik mijn ouders en andere familieleden ook heel dankbaar. Mijn vader bedank ik in het bijzonder omdat hij me meegeholpen heeft bij de controle van deze thesis op spelfouten. Verder gaat mijn dank ook uit naar de medebewoners van home Astrid voor hun constante steun, interesse in de vorderingen in mijn thesis en hun aangenaam gezelschap in momenten van ontspanning. Tevens wens ik mijn vrienden uit de scouts te bedanken voor de aanmoedigingen en het begrip voor het feit dat ik me niet ten volle voor de scouts kon inzetten, omdat de thesis belangrijker was. Ten slotte wil ik ook mijn vrienden uit de informatica bedanken. Enerzijds voor de bemoedigingen en de aangename momenten van ontspanning en anderzijds – wat dan vooral geldt voor de afgestudeerden onder hen – voor de tips omtrent het schrijven van een thesis.
i
Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Bart Defauw, mei 2007
ii
Implementatie van een streaming extensie voor The Core Pocket Media Player door Bart Defauw Scriptie ingediend tot het behalen van de academische graad van Licentiaat in de Informatica Academiejaar 2006–2007 Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout Promotor: Prof. Dr. Ir. R. Van de Walle Scriptiebegeleider: Lic. C. Poppe
Samenvatting Deze thesis heeft als doel om een streaming implementatie te realiseren voor Pocket PC. We nemen de bestaande The Core Pocket Media Player als basis om een streaming uitbreiding aan toe te voegen. We doen eerst de gebruikte streaming protocols (RTSP, RTP en RTCP) uit de doeken. Tevens geven we enkele voordelen van streaming en redenen om streaming te voorzien op Pocket PC. Later hebben we het over de benodigdheden voor streaming en leggen we de implementatie uit met de belangrijkste ontwerpbeslissingen. Tot slot bespreken we het resultaat en wat er nog aan verbeterd kan worden. Trefwoorden: Streaming, RTSP, RTP, RTCP, Pocket PC, The Core Pocket Media Player
iii
Implementation of a streaming extension for The Core Pocket Media Player Bart Defauw Supervisor(s): Chris Poppe, Rik Van de Walle Abstract—The purpose of this thesis is to implement a streaming extension for The Core Pocket Media Player, a media player for Pocket PC. We will give an introduction to streaming and summarize some applications and advantages of streaming. Moreover, we will expound the function and working of the implemented protocols briefly. This abstract will also explain how we implemented this extension, the sources we used and what the extension is capable of. Keywords—Streaming, RTSP, RTP, RTCP, Pocket PC, The Core Pocket Media Player
I. I NTRODUCTION
N
OWADAYS streaming is a popular way to access media. Streaming support is already present in many media players for pc. Conversely, on Pocket PCs very few media players offer streaming support. For streaming we need a server, a device with a media player and a connection between the server and the device. Pocket PCs can connect in several ways to a network, consequently they can also establish a connection with a streaming server. Many media players for Pocket PC exist already, but very few of them offer support for streaming. In this thesis we would like to implement a streaming extension for an open source media player for Pocket PC, called The Core Pocket Media Player (TCPMP). TCPMP supports many audio, video and container formats. We will search for suitable streaming protocols and streaming implementations and decide whether to implement the extension to TCPMP by ourselves or use an already existing implementation.
file can be viewed shortly after downloading has started. The intermediate step between download-and-play and true streaming is progressive download. Rather than waiting for the complete file to be downloaded to the local disk before playback, the file can be opened while the remainder is still being downloaded. If the transfer is slower than the encoded rate, the player can run out of material, which results in an interruption of the playback. Streaming can avoid these interruptions, since streaming servers can adjust the data rate to an optimum rate for the prevailing network conditions and available bandwidth. By using streaming we do not need to provide disk space to download the file to. For small storage devices this is to great advantage. Some applications of streaming are: • Distance learning • Web-based channels (IP-TV, Internet radio) • Video-on-demand • Music-on-demand • Communication • Advertising B. Streaming protocols The main streaming protocols are MMS and the combination of RTSP, RTP and RTCP. Windows Media originally used the Microsoft Media Server (MMS) for the delivery framework, but in the latest versions MMS has been replaced by RTSP, RTP and RTCP[2]. B.1 Real-Time Streaming Protocol (RTSP)
II. S TREAMING A. General Information Streaming is the delivery of media direct from the source to the player in real-time. This is a continuous process, without intermediate storage of a file. We can divide streaming into three categories: • Streaming of live content • Streaming of pre-recorded content (on-demand delivery) • Real-time interactive audio and video The latter is beyond the scope of this thesis because the user has to be able to record and transmit its own video and audio, a function that exceeds the capabilities of our media player. Applications of this category are internet telephony and videoconferencing. It is plain that streaming is a prerequisite for the delivery of live content. Delivery of pre-recorded content can be realized in alternative ways. We can download the files first and watch them afterwards (download-and-play). Streaming does not let the user wait until the file has been downloaded completely; the
The Real-Time Streaming Protocol is an application-level protocol for the control of real-time multimedia data. RTSP provides an extensible framework rather than a protocol. It allows interactive VCR-like control of the playback: Play, Pause, and so on. RTSP was developed intentionally to be similar in syntax and operation to HTTP1 version 1.1. It does differ in several important aspects, however. Re-using HTTP functionality facilitates the adoption of HTTP work for RTSP on caches, proxies and authentication. As already stated above, RTSP controls real-time multimedia data. This multimedia data consists of a number of streams of continuous media such as audio and video. The set of streams to be controlled is defined by a presentation description. Client applications can get these descriptions by sending an RTSP DESCRIBE request with the identifying URL2 for the media object. To initiate a presentation a client has to send a SETUP request. This request, sent for each stream, specifies the transport 1 HTTP: 2 URL:
HyperText Transfer Protocol Uniform Resource Locator
mechanism to be used for the streamed media. It also causes the server to allocate resources for a stream and start an RTSP session. A PLAY method tells the server to start sending data via the mechanism specified in SETUP. A range can be specified in this request. Sending a TEARDOWN request stops the stream delivery for the given URL and frees the resources associated with it. The RTSP session ceases to exist on the server. Figure 1 shows how client and server communicate with these methods for a simple RTSP session. The methods we explained are the most important, but RTSP also provides a number of other methods. We list them here for completeness: ANNOUNCE, GET PARAMETER, SET PARAMETER, OPTIONS, PAUSE, RECORD and REDIRECT[3].
Streaming Server for testing, yet our implementation should be able to communicate with other servers as well[5]. B. Client Research to already existing implementations on client side brought us to the LIVE555 Streaming Media libraries. Among other media players, VLC media player and MPlayer provide streaming support with LIVE555. We added the source code of LIVE555 to the source code of The Core Pocket Media Player[6]. The Core Pocket Media Player is an open source media player for Pocket PC. Supported operating systems include Windows CE, Windows Mobile, Palm OS and Symbian OS. TCPMP offers a whole range of supported audio and video formats. It also supports many container formats[7]. C. Implementation
Fig. 1. Interaction between client and server for a simple RTSP session
B.2 Real-Time Transport Protocol (RTP) RTP is a transport protocol that was developed for streaming data. In addition to the multimedia data, RTP packets include extra data such as sequence numbers and timestamps. RTP usually runs on UDP3 , but TCP4 can be used as well. Nevertheless, UDP is the most suitable protocol for the transport of streamed data[4]. B.3 Real-Time Control Protocol (RTCP) Real-Time Control Protocol is used in conjunction with RTP. It gives feedback to each participant in an RTP session that can be used to control the session. The messages include reception reports, including the number of packets lost and statistics about early or late arrivals of packets. RTP senders can use this information to modify the transmission; for example they change the bit rate of a stream to counter network congestion[4].
The source code of TCPMP consists of several projects, each with a function. Some projects are for decompression of a particular audio or video format, others handle specific container formats and others provide common functionality. There was also a network project. Mainly in this project we added our source code. We looked closely at how a local file was played and built a new file format to deal with the streaming part. Basically there were two functions, for which we needed to use the LIVE555 libraries. The first one was an initialization function. In this function we send a DESCRIBE-request, SETUPrequests and PLAY requests to the server. LIVE555 automatically starts dealing with RTCP packets and starts receiving the RTP-streams. The second function we implemented was in order to read the data out of the RTP-streams. IV. C ONCLUSIONS We succeeded in building a basic streaming extension. We can play a streamed mp4-file with MPEG-4 audio and MPEG-4 video. But still, improvements can be made. The quality of the video could be raised. Support for more audio and video formats can be added. Network errors can be dealt with in a more userfriendly way. The capabilities of the streaming protocols have not yet been exploited entirely. ACKNOWLEDGMENTS The author would like to thank Rik Van De Walle for the opportunity to do this research, as well as Chris Poppe for helping the author to achieve these results. R EFERENCES
III. M ETHOD OF WORKING A. Server The server we chose for is the Darwin Streaming Server, the open source version of Apple’s commercial QuickTime Streaming Server. Darwin Streaming Server provides a high level of customizability and runs on a variety of platforms (Mac OS X, Linux and Windows). The server can offer both live broadcast and the playback of pre-recorded content. We chose Darwin 3 UDP: 4 TCP:
User Datagram Protocol Transmission Control Protocol
[1] D. Austerberry. The technology of video and audio streaming. Focal Press, second edition, October 2004. [2] Microsoft. Windows Media Services FAQ. http://www.microsoft.com/windows/windowsmedia/forpros/server/faq.aspx. [3] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol (RTSP). RFC 2326 (Proposed Standard), April 1998. [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 3550 (Standard), July 2003. [5] Apple. Darwin Streaming Server. http://developer.apple.com/opensource/server/streaming/index.html. [6] Live Networks, Inc. LIVE555 Streaming Media. http://www.live555.com/liveMedia/. [7] CoreCodec, Inc. The Core Pocket Media Player. http://tcpmp.corecodec.org/.
Inhoudsopgave 1 Inleiding
1
1.1
Probleemstelling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Het beoogde doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Opbouw van de thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Streaming
4
2.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Real-Time Streaming Protocol (RTSP) . . . . . . . . . . . . . . . . . . . .
6
2.3
Real-Time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . 11
2.4
RTP Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5
Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Werkwijze 3.1
3.2
3.3
16
Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1
Serversoftware: Darwin Streaming Server . . . . . . . . . . . . . . . 16
3.1.2
Bestaande implementaties voor streaming aan clientzijde . . . . . . 19
3.1.3
De gebruikte mediaspeler: The Core Pocket Media Player . . . . . . 20
Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.1
Overzicht broncode The Core Pocket Media Player . . . . . . . . . 21
3.2.2
Afspelen van een bestand
3.2.3
Afspelen met de streaming implementatie
. . . . . . . . . . . . . . . . . . . . . . . 22 . . . . . . . . . . . . . . 25
Gebruikte toestellen, bestanden en verbinding . . . . . . . . . . . . . . . . 29 3.3.1
Gebruikte toestellen . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2
Gebruikte bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3
Verbinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 vi
3.4
Verloop van de ontwikkeling . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4.1
Zelf RTSP voorzien . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2
LIVE555 en de functie om streams naar een bestand te schrijven . . 34
3.4.3
Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.4
Audio en Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Conclusies
36
4.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2
Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3
Verder werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4
4.3.1
Verbetering video en uitbreiding naar andere bestanden . . . . . . . 37
4.3.2
Netwerkfouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.3
Extra functies en uitbreidingsmodules . . . . . . . . . . . . . . . . . 38
Algemeen besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A Voorbeeld van RTSP-interactie
40
Bibliografie
44
vii
Tabel van afkortingen en symbolen 3GPP AAC AC3 AMR GSM HTTP IANA MIME MMS MP4V-ES MPEG PCM PDA QCELP RFC RTCP RTP RTSP SIP SSRC TCP TCPMP UDP UML URL USB WAV
3rd Generation Partnership Project Advanced Audio Coding Adaptive Transform Coder 3 (Dolby Digital) Adaptive Multi-Rate Global System for Mobile communications Hypertext transfer protocol Internet Assigned Numbers Authority Multipurpose Internet Mail Extensions Microsoft Media Services MIME Type voor MPEG-4 Visual Stream Motion Pictures Experts Group Pulse-code Modulation Personal Digital Assistant Qualcomm Code Excited Linear Prediction Request For Comments Real-Time Control Protocol Real-Time Transport Protocol Real-Time Streaming Protocol Session Initiation Protocol Synchronization Source Identifyer (bronidentificatie) Transmission Control Protocol The Core Pocket Media Player User Datagram Protocol Unified Modeling Language Uniform Resource Locator Universal Serial Bus Waveform audio formaat Tabel 1: Lijst van de gebruikte afkortingen
viii
Hoofdstuk 1 Inleiding 1.1
Probleemstelling
Streaming is momenteel een populaire techniek om videobestanden te bekijken, audiobestanden te beluisteren en live-uitzendingen te volgen. Bij mediaspelers voor pc’s is ondersteuning voor streaming steeds meer en meer aanwezig. Verder is er ook de trend om toepassingen die ontwikkeld zijn voor pc over te hevelen naar toepassingen voor Pocket PC. Zo zijn er al e-mailprogramma’s, tekstverwerkers, webbrowsers, chatprogramma’s, mediaspelers enz. ontwikkeld voor Pocket PC. Het aanbod aan mediaspelers voor Pocket PC met ondersteuning voor streaming is daarentegen echter schaars. Pocket PC’s kunnen doorgaans op vele manieren een verbinding tot stand brengen met andere toestellen. Enkele van de manieren zijn draadloze lokale netwerken, Bluetooth, infrarood, USB ... Gezien dit ruime aanbod aan verbindingstypes om deze Pocket PC’s met het internet te verbinden, zijn de voorzieningen dus aanwezig om deze toestellen gebruik te laten maken van streaming. Dit, in combinatie met het feit dat draadloze lokale netwerken op tal van plaatsen aangeboden worden, maakt het voor de Pocket PC-gebruiker mogelijk om op vele locaties de voordelen van internet te benutten. Van zodra men een servercomputer heeft en een manier om de Pocket PC te verbinden met de servercomputer kan men met behulp van software voor streaming op beide eindsystemen, multimediale data streamen naar de Pocket PC. Hoewel alle genoemde benodigdheden bestaan, laat het aanbod van de software voor Pocket PC te wensen over. Dit tekort wensen we op te vullen.
1
1.2
Het beoogde doel
Het aanbod aan mediaspelers voor Pocket PC is wel al voldoende groot, althans groot genoeg om er een speler uit te kiezen die gemakkelijk uitbreidbaar is voor streaming. De mediaspeler die daarvoor werd gekozen, is The Core Pocket Media Player (TCPMP). Dit is een mediaspeler die ondersteuning biedt voor een ruime set aan video- en audiocodecs1 . De speler richt zich vooral tot het Windows CE platform, maar draait ook op Palm OS en Symbian. Zowel Pocket PC’s als smartphones kunnen deze toepassing uitvoeren. De prestaties op smartphones zullen over het algemeen wel minder goed zijn, wat te wijten is aan de nog beperktere hardwarebronnen. Een vereiste voor gemakkelijke uitbreidbaarheid is uiteraard dat de broncode vrij beschikbaar is. TCPMP voldoet aan die voorwaarde. TCPMP is ge¨ımplementeerd in C en is al in staat om lokale bestanden af te spelen. Het is dus de bedoeling de basisfunctionaliteit van de speler te behouden en een uitbreiding te schrijven, zodat de gebruiker eenvoudig een streaming presentatie kan afspelen. We moeten ook op zoek gaan naar een streaming protocol dat we kunnen gebruiken om de multimediale data te ontvangen. Tevens is het van belang om te onderzoeken of er al bestaande implementaties zijn en of die bruikbaar zijn voor onze implementatie. Vervolgens moeten we dan beslissen of we enerzijds het allemaal zelf implementeren of anderzijds een reeds bestaande implementatie kiezen en integreren in de onze[3].
1.3
Opbouw van de thesis
We beginnen in hoofdstuk 2 met het begrip streaming te introduceren. We geven een overzicht van de soorten streaming. Daarna behandelen we alternatieven voor streaming, het nut van streaming en de toepassingen ervan. Verder bespreken we kort het aanbod aan streaming protocols en uiteindelijk verklaren we de algemene werking van de streaming protocols waar we voor gekozen hebben. In hoofdstuk 3 bespreken we eerst de opstelling om een streaming demonstratie tot stand te brengen. We motiveren de keuze en de mogelijkheden van de gebruikte softwarepakketten. Daarna geven we uitleg over de belangrijkste onderdelen van de im1
Een codec is een compressie- en decomressie-algoritme. De codeertoepassing zal de codec gebruiken om het mediabestand te comprimeren en later gebruikt de mediaspeler de codec dan om dit bestand te decomprimeren.
2
plementatie. We eindigen het hoofdstuk met het verloop van de ontwikkeling van de implementatie en de problemen die ons pad kruisten. Tot slot bespreken we de behaalde resultaten in hoofdstuk 4 en op welke vlakken de implementatie nog uitgebreid kan worden.
3
Hoofdstuk 2 Streaming 2.1
Inleiding
Streaming is een techniek om via een netwerk in real-time audio en/of video te verzenden als een stroom van pakketten in plaats van het downloaden van een bestand. Er bestaan drie soorten streaming: streamen van live audio en video, streamen van vooraf opgeslagen audio en video en real-time interactieve audio en video. Deze laatste categorie is niet van toepassing op deze thesis. Hierbij stuurt de gebruiker zelf ook audio of video over het netwerk, een functie waarvoor de gebruikte speler niet gemaakt is. Toepassingen hiervan zijn internettelefoon en videoconferencing. De categorie streamen van live audio en video lijkt sterk op de traditionele radioen televisie-uitzendingen, met dit verschil dat de verzending via internet gebeurt. De client heeft enkel toegang tot het deel dat juist uitgezonden wordt. Pauzeren kan niet omdat de stream niet opgeslagen wordt. Vooruitspoelen kan uiteraard ook niet omdat de audio/video nog niet beschikbaar is. Bij de categorie van streamen van vooraf opgeslagen audio en video vragen clients op een willekeurig moment gecomprimeerde audio- of videobestanden op die op een server zijn opgeslagen. Omdat de media-inhoud vooraf opgenomen en opgeslagen is, wordt het mogelijk om de weergave ervan te onderbreken, versneld weer te geven of ongezien verder te spoelen. Men kan live streaming ook simuleren. Internet radio- en TV-producenten, leerkrachten op afstand en gezamenlijke trainers kunnen live uitzendingen simuleren door afspeellijsten
4
te maken met muziek, lessen, interviews en ander vooraf opgenomen materiaal. Zoals met live uitzendingen zien de verbonden gebruikers hetzelfde moment in de uitzending op hetzelfde tijdstip. Het is duidelijk dat streaming noodzakelijk is voor het afspelen van live audio en video en voor real-time interactieve audio en video. Een alternatief voor streamen van vooraf opgeslagen audio en video is het bestand downloaden en dan afspelen. De tijd die nodig is om een bestand af te spelen is dan de duur om het bestand te downloaden vermeerderd met de speelduur van het bestand. Met behulp van streaming kan dit korter. De gebruiker kan al beginnen kijken kort nadat het streamen gestart is. Wanneer de gebruiker het bestand niet interessant vindt, kan hij het spelen direct stopzetten en moet hij niet eerst wachten tot het bestand gedownload is. Dankzij streaming verloopt het zoeken naar een bestand met een bepaalde inhoud dus ook veel vlotter. Een tussenoplossing tussen streamen en volledig downloaden is de techniek van het progressief downloaden. In plaats van te wachten tot het volledige bestand gedownload is, kan het bestand al geopend worden terwijl de rest van het bestand nog gedownload wordt. Wanneer de downloadtijd groter is dan de afspeeltijd van het bestand kan het hierbij wel gebeuren dat op een bepaald moment de rest van het bestand nog niet beschikbaar is. Het afspelen wordt dan onderbroken tot weer voldoende bytes beschikbaar zijn. Streaming kan dit probleem van onderbrekingen oplossen. Bij streaming kan er gecommuniceerd worden over de kwaliteit van de verbinding en afhankelijk daarvan kan de server aan lagere snelheid streamen. Er wordt dan een kleiner bronbestand verstuurd van lagere kwaliteit, dat echter wel een continue weergave bij de client garandeert. Nog een voordeel van streaming is dat geen schijfruimte moet voorzien worden om het volledige bestand op te slaan. Op een toestel met beperkte opslagcapaciteit kan dit dan de enige oplossing zijn om toch een groot bestand te kunnen afspelen. Streaming heeft gezorgd voor het ontstaan en de verbetering van verschillende toepassingen, zoals: • leren op afstand • televisie- en radiozenders via internet • video op aanvraag • muziek op aanvraag 5
• communicatie • reclame De belangrijkste protocols voor streaming zijn MMS en de combinatie van RTSP, RTP en RTCP. MMS is het protocol van Microsoft Media Server. Dit protocol werkt met UDP en TCP. Standaard wordt gekozen voor UDP, maar als de speler geen goede verbinding kan hebben via UDP schakelt deze over op TCP. Als dat dan nog problemen oplevert, wordt een verbinding gemaakt met behulp van HTTP over TCP. Aangezien MMS niet meer ondersteund wordt in de nieuwste versies van de Microsoft Media Server, was de keuze voor RTSP, RTP en RTCP voor deze thesis vanzelfsprekend[13]. In de volgende paragrafen bekijken we kort de werking van RTSP, RTP en RTCP. In het kader van streaming protocols dienen we voor de volledigheid ook SIP en H.323 te vermelden. Deze protocols zijn echter niet ontwikkeld in functie van bezorging van audio en video in een client-serveropstelling. Het zijn protocols voor real-time audio- en videoconferencing tussen eindsystemen op internet.
2.2
Real-Time Streaming Protocol (RTSP)
Het Real-Time Streaming Protocol, gedefinieerd in RFC 2326[20], is een protocol om het afspelen van streams te regelen. Het levert zelf geen audio of video. Welke streams tot een presentatie horen, is vastgelegd in een presentatiebeschrijving. Bij dit protocol is het niet nodig een constante verbinding te hebben tussen client en server. Gedurende een RTSP-sessie kan de client meerdere keren een verbinding openen en sluiten om RTSP-berichten te versturen. Normaal gezien wordt gebruik gemaakt van een TCP-verbinding, maar RTSP-berichten kunnen even goed verzonden worden via een UDP-verbinding. Omdat het wel nodig is om een idee te hebben met welke client de server bezig is, hoe ver die zit met het afspelen of waar hij een stream gepauzeerd heeft, houdt de server per sessie de toestand bij, ge¨ıdentificeerd door een sessienummer. Nadat een sessienummer afgesproken is tussen client en server, zal dit nummer telkens aan de RTSP-berichten toegevoegd worden. RTSP vertoont vele gelijkenissen met HTTP/1.1 1 . Het kan ook interageren met HTTP in die zin dat het initi¨ele contact met het streaming aanbod kan gebeuren via 1
HTTP/1.1 : Hypertext transfer protocol, versie 1.1 (momenteel de meest recente versie)
6
een webpagina. De presentatiebeschrijving kan bijvoorbeeld zowel met HTTP als RTSP verkregen worden. Toch zijn er enkele verschillen met HTTP, waarvan we de belangrijkste even opsommen. • Het versturen van data gebeurt in een ander out-of-band protocol. Hierdoor lijkt het RTSP-protocol zelfs op een deel van het File Transfer Protocol (FTP). FTP gebruikt twee paren sockets: ´e´en socketpaar voor de client en de server wordt gebruikt voor een TCP-verbinding voor de controle-informatie. Het andere socketpaar wordt gebruikt voor een TCP-verbinding waarover het eigenlijke bestand wordt verzonden. Het RTSP-kanaal kan dus vergeleken worden met het controlekanaal van FTP. • HTTP is een asymmetrisch protocol waar de client verzoekberichten stuurt en de server antwoordt. Bij RTSP kunnen zowel client als server verzoekberichten sturen. • RTSP verzoekberichten zijn ook niet toestandloos. Ze kunnen parameters aanpassen en media stream bedienen, lang nadat een verzoekbericht bevestigd werd. Zoals bij HTTP bevatten RTSP-antwoordberichten van de server een statuscode. Zo’n statuscode bestaat uit een integer van 3 cijfers. Samen met de statuscode bevat het antwoordbericht ook de reden. Deze reden is dan een korte tekstuele beschrijving van de fout. Computerprogramma’s kunnen dan beter overweg met de statuscode en kunnen daar gepast op reageren. De beschrijving van de fout is bedoeld voor de gebruiker, zodat die de fout kan begrijpen. Het eerste cijfer van de statuscode bepaalt de antwoordcategorie. Het merendeel van de statuscodes voor RTSP is overgenomen van HTTP. Er zijn 5 waarden voor het eerste cijfer: • 1xx: Informatie - Verzoek ontvangen, de behandeling verloopt verder. • 2xx: Succes - De actie was succesvol ontvangen, verstaan en aanvaard. • 3xx: Doorsturing (Eng. Redirection) - Verdere actie moet ondernomen worden om het verzoek af te werken. • 4xx: Fout aan clientzijde - Het verzoek bevat een syntaxfout of kan niet volbracht worden. • 5xx: Fout aan serverzijde - De server slaagde er niet in een klaarblijkelijk geldig verzoek in te willigen. 7
Hergebruik van HTTP-functionaliteit heeft als voordeel dat de vereisten voor RTSP en HTTP heel gelijklopend zijn. Daardoor is het gemakkelijk om voor HTTP ontwikkelde caches, proxies en authenticatiesystemen aan te passen zodat ze ook voor RTSP werken. Onderstaande tabel geeft een overzicht van de verschillende methoden van RTSP. Methode DESCRIBE ANNOUNCE GET PARAMETER OPTIONS
Richting (C=client,S=server) C→S C → S, S → C C → S, S → C C → S, S → C
Object (P=presentatie, S=stream) P, S P, S P, S P, S
PAUSE PLAY RECORD REDIRECT SETUP SET PARAMETER TEARDOWN
C→S C→S C→S S→C C→S C → S, S → C C→S
P, S P, S P, S P, S S P, S P, S
Vereiste Aanbevolen Optioneel Optioneel Vereist(server), optioneel(client) Aanbevolen Vereist Optioneel Optioneel Vereist Optioneel Vereist
Tabel 2.1: Methoden RTSP
We zullen nu eerst chronologisch de methoden doorlopen van een eenvoudige RTSPsessie en de gebruikte methoden een voor een uitleggen. Een voorbeeld van hoe de berichten eruitzien, is te vinden in de appendix. Eerst moet de client aan een presentatiebeschrijving geraken. Dit kan via HTTP of via een omschrijvingsbestand dat op een andere manier bij de client geraakt, maar ook met behulp van een RTSP-methode, namelijk de DESCRIBE-methode. De client verstuurt een DESCRIBE-verzoekbericht met de URL van de presentatie die hij wil afspelen en krijgt als antwoord een gedetailleerde beschrijving van die presentatie. Bij deze beschrijving wordt vaak gebruik gemaakt van het Session Description Protocol (RFC 2327[7], RFC 4566[8] en RFC 3266[15]). Het bevat informatie over: • naam en doel van de sessie; • contact informatie voor de persoon die verantwoordelijk is voor de sessie; • tijd dat de sessie actief is; • media van de sessie; • informatie om die media te ontvangen (adressen, poorten, formaten, ...); 8
Figuur 2.1: Interactie tussen client en server bij een eenvoudige RTSP-sessie
• informatie over de bandbreedte die gebruikt kan worden. Als de client over de presentatiebeschrijving beschikt, kan hij per stream een SETUPbericht sturen. Hierbij wordt dan per stream een sessienummer afgesproken. Aan alle berichten die van toepassing zijn voor die stream zal dit afgesproken sessienummer toegevoegd worden. Het SETUP-antwoordbericht bevat naast dit sessienummer ook alle informatie die nodig is voor de verzending van de stream in kwestie zoals protocol voor de verzending van de data, of het unicast is of multicast, poortnummers, ... Daarna kan de client een PLAY-verzoek sturen. Als de server dit ontvangt kan hij de stream beginnen afspelen via het transportmechanisme van het SETUP-antwoordbericht. In het PLAY-verzoekbericht kan de client ook aangeven vanaf welk tijdstip in het bestand 9
het afspelen mag beginnen. Wanneer de client een containterformaat 2 wil afspelen, moet de client ´e´en PLAY-bericht sturen voor dat bestand. Het is zelfs zo dat sommige servers het niet toelaten dat voor streams afzonderlijk dan een PLAY-bericht gestuurd wordt. Om de sessie te be¨eindigen stuurt de client een TEARDOWN-bericht. De server maakt alle bronnen die hij voor de sessie had voorzien vrij. Het sessienummer is niet langer geldig. De presentatie is volledig voorbij wanneer dit TEARDOWN-bericht voor elke sessie en dus elke stream verstuurd is en de server er positief op gereageerd heeft. Als tijdens de sessie de presentatiebeschrijving moet aangepast worden, bijvoorbeeld omdat er een nieuwe stream aan de presentatie toegevoegd is, kan met een ANNOUNCEbericht een update van de beschrijving verstuurd worden. Methoden GET PARAMETER en SET PARAMETER vragen een waarde van een parameter op en stellen een waarde in. Hoe de inhoud van deze berichten eruitziet, is niet gespecificeerd en is afhankelijk van de implementatie. Een GET PARAMETER-bericht waarbij eigenlijk geen parameter gegeven is om de waarde van op te vragen, kan gebruikt worden om te controleren of de server nog bereikbaar is (“ping”). Met een OPTIONS-verzoekbericht kan men nagaan welke methoden ge¨ımplementeerd zijn. Als bijvoorbeeld een client een methode wil gebruiken die niet noodzakelijk ondersteund moet zijn, kan de client eerst verifi¨eren met deze methode of de methode wel beschikbaar is. Een PAUSE-verzoekbericht onderbreekt de stream tijdelijk. Als de URL van het bericht een enkele stream aanduidt, wordt het afspelen of opnemen van alleen die stream gepauzeerd. In het geval dat de URL de volledige presentatie of een groep streams aanwijst stopt de levering van alle actieve streams van de presentatie of de groep van streams. Hoewel het afspelen nu is gestopt, moet de server nog alle informatie over de sessies bijhouden. Ook het tijdstip waarop nu gestopt is kan opgeslagen worden. De server zou de sessies wel kunnen sluiten en bronnen vrijgeven wanneer de sessies voor een duur zouden gepauzeerd zijn, langer dan de duur aangegeven door een timeout parameter uit het SETUP-bericht. Naast het afspelen van presentaties kunnen streaming servers ook presentaties opnemen. Hiervoor dient het RECORD-bericht. De client suggereert een locatie om de presentatie op te slaan en duidt de presentatie aan die moet opgenomen worden. 2
Containerformaat: Een bestandsformaat waarin verschillende mediatypes samen opgeslagen zijn.
10
Met een REDIRECT-bericht wordt aan de client gemeld dat hij verbinding moet maken met een andere server. Het bevat het adres van de andere server. Er kan ook een tijdstip aan toegevoegd worden waarop de doorverwijzing moet plaatsvinden. De client moet dan een TEARDOWN-bericht sturen naar de huidige server en een SETUP-bericht naar de gegeven server.
2.3
Real-Time Transport Protocol (RTP)
Het RTP-protocol, gedefinieerd in RFC 1889[6] en RFC 3550[19], is een manier om porties audio- of videobestanden te versturen. Naast de eigenlijke gegevens bevatten de verstuurde pakketten ook controlegegevens. Deze controlegegevens komen terecht in de zogenaamde header van het pakket. RTP voegt deze deze headervelden samen met de porties audio- of vidoebestanden in pakketten. De headerinformatie bestaat onder andere uit volgnummers en tijdstempels. RTP kan gebruikt worden voor het transporteren van media met veelgebruikte compressietechnieken zoals PCM of GSM voor geluid en MPEG1 en MPEG2 voor video. Het kan ook gebruikt worden voor het transporteren van geluid en video met niet-standaard compressietechnieken. Voor een beschrijving van de vermelde compressietechnieken kan men terecht in referentie [2]. Hoewel voornamelijk UDP kan en zal gebruikt worden, is RTP ook in staat om TCP te gebruiken. We zullen kort even de werking van dit protocol bekijken. Stel dat we een geluidsbestand willen streamen via RTP. De server zal dan het bestand opsplitsen in porties. Per portie voegt de server een RTP-header toe met daarin het type audiocodering, een volgnummer en een tijdstempel. De audioportie vormt samen met de RTP-header het RTP-pakket. Het RTP-pakket wordt vervolgens verzonden. De ontvanger ontvangt het RTP-pakket. De toepassing aan clientzijde filtert de audiogegevens uit het RTP-pakket en gebruikt de headervelden van het RTP-pakket om de gegevens op de juiste manier te decoderen en weer te geven. Door deze standaard, voorzien van informatie over het gegevenstype, volgnummers en tijdstempels, is het mogelijk dat toepassingen van twee totaal verschillende producenten toch met elkaar kunnen communiceren. RTP levert zelf geen mechanismen voor een tijdige bezorging van gegevens of de kwaliteit van de diensten. RTP garandeert zelfs niet eens dat pakketten aankomen en ook niet dat ze in de juiste volgorde aankomen. RTP doet niets anders dan het samenvoegen van header en gegevens tot pakketten op de eindsystemen, waarna de pakketten verstuurd worden over het netwerk. Elke bron (bijvoorbeeld een 11
camera of een microfoon) kan een eigen onafhankelijke RTP-pakketstream hebben, maar dit is geen vereiste. Coderingstechnieken zoals MPEG1 en MPEG2 bundelen de audioen videogegevens tijdens het coderingsproces in ´e´en stream. RTP-pakketten kunnen niet alleen voor unicast toepassingen3 worden gebruikt. Ze kunnen ook worden verzonden via ´e´en-naar-veel en veel-naar-veel multicast4 bomen. We zullen nog even een blik werpen op de belangrijkste headervelden van een RTPpakket. Zoals weergegeven in de figuur, zijn dit velden voor het aanduiden van het gegevenstype, het volgnummer, de tijdstempel, en de bronidentificatie.
Figuur 2.2: Headervelden RTP-pakket
Bij een audiostream wordt het gegevenstypeveld gebruikt voor het aanduiden van het gebruikte type audiocodering. Als een verzender tijdens een sessie besluit om een andere manier van coderen te gaan gebruiken, kan deze de ontvanger daarvan op de hoogte brengen door de gegevens in het gegevenstypeveld te veranderen. De verzender kan dat bijvoorbeeld doen om een betere audiokwaliteit te leveren, maar ook om de bitsnelheid van de RTP-stream te verlagen. Voor een videostream wordt het gegevenstype gebruikt om het type videocodering aan te duiden. Ook hier kan de verzender de videocodering tijdens een sessie veranderen. Elk pakket krijgt een volgnummer dat wordt ingevuld in het volgnummerveld. Het volgnummer van een verzonden RTP-pakket is ´e´en hoger dan het volgnummer van het vorige verzonden pakket. De ontvanger kan het volgnummer gebruiken om pakketverlies te detecteren en de volgorde van pakketten te herstellen. De tijdstempel van het tijdstempelveld is gelijk aan het tijdstip in de presentatie dat overeenkomt met de eerste byte in het RTP-gegevenspakket. De ontvanger kan deze tijdstempels gebruiken om pakketten met dezelfde snelheid weer te geven als waarin ze werden verzonden. 3
Unicast toepassingen zijn toepassingen waarbij slechts ´e´en verzender en ´e´en ontvanger betrokken is. Multicast is een techniek voor het in ´e´en handeling verzenden van een pakket door een verzender naar verschillende ontvangers. 4
12
Het bronidentificatieveld (Eng. Synchronization source identifier ; SSRC) duidt de bron van de RTP-stream aan. Elke stream in een RTP-sessie heeft een unieke bronidentificatie. De bronidentificatie is niet het IP-adres van de verzender, maar een nummer dat de bron willekeurig kiest wanneer een nieuwe stream wordt gestart. Als een zender verschillende streams verstuurt, kiest hij voor elke stream een verschillende SSRC. In het geval dat een verzender merkt dan een zelfde SSRC gebruikt wordt als zijn eigen, moet deze verzender een RTCP BYE bericht sturen voor de oude identificatie en een nieuwe waarde kiezen voor de SSRC. De andere verzender kiest dan ook een nieuwe waarde.
2.4
RTP Control Protocol (RTCP)
In de RFC’s van RTP (RFC 1889[6] en RFC 3550[19]) wordt ook RTCP besproken. Het RTP Control Protocol is een protocol dat een multimedianetwerktoepassing kan gebruiken in combinatie met RTP. RTCP-pakketten bevatten geen audio- of videogegevens. RTCPpakketten worden periodiek verzonden en bevatten meldingen van de verzender en/of ontvanger met statistische gegevens die voor de toepassing van nut kunnen zijn. Wat de toepassing met deze informatie moet doen, maakt geen onderdeel uit van de beschrijving van het protocol. De ontwikkelaar van de toepassing is daar helemaal vrij in. Verzenders kunnen uit de informatie bijvoorbeeld afleiden of de verzendsnelheid aangepast moet worden. De informatie kan ook gebruikt worden voor het stellen van diagnoses. Ontvangers kunnen bijvoorbeeld zo bepalen of problemen een lokale, regionale of andere oorzaak hebben. Voor elke RTP-stream die een ontvanger aankrijgt als onderdeel van een sessie, genereert de ontvanger een ontvangstmelding. De ontvanger verpakt een aantal ontvangstmeldingen in ´e´en RTCP-pakket. De ontvangstmeldingen bevatten verschillende velden, waarvan de belangrijkste hierna zijn opgesomd. • De SSRC of bronidentificatie van de RTP-stream waarvoor de ontvangstmelding wordt gegenereerd. • Het percentage verloren pakketten in de RTP-stream. Dit is het resultaat van de deling van het aantal kwijtgeraakte RTP-pakketten door het aantal verzonden RTPpakketten in de stream. Als een verzender ontvangstmeldingen ontvangt waaruit blijkt dat de ontvangers slechts een klein deel van de verzonden pakketten ontvangen,
13
kan de verzender de coderingssnelheid verlagen om de belasting van het netwerk te verlagen en daardoor het ontvangstpercentage verhogen. • Het laatst ontvangen volgnummer in de stream RTP-pakketten. • De jitter die wordt berekend als de gemiddelde aankomstverschiltijd tussen opeenvolgende pakketten in de RTP-stream. De verzender stuurt zelf ook voor elke RTP-stream pakketten. verzendmeldingspakketten bevatten onder andere:
Deze RTCP-
• de SSRC van de RTP-stream; • de tijdstempel en lokale tijd van het laatst gegenereerde RTP-pakket in de stream; • het aantal verzonden pakketten in de stream; • het aantal verzonden bytes in de stream. De verzendmeldingen kunnen gebruikt worden om verschillende mediastreams binnen een RTP-sessie te synchroniseren. Stel dat we een sessie hebben met een audioen videostream. De tijdstempels van de RTP-pakketten in deze streams worden gekoppeld aan de audio- en videosampleklokken5 en niet aan de lokale tijd. Elke RTCPverzendmelding bevat de tijdstempel van het laatst verzonden RTP-pakket en de lokale tijd voor het moment waarop het pakket werd gemaakt. Zodoende koppelen de RTCPverzendmeldingspakketten de sampleklok aan de werkelijke lokale klok. Ontvangers kunnen die gebruiken om de weergave van audio en video te synchroniseren.
2.5
Samenvatting
In dit hoofdstuk hebben we het begrip streaming besproken. We hebben gezien dat er drie categorie¨en bestaan in streaming, namelijk het streamen van live uitzendingen, het streamen van vooraf opgenomen bestanden (audio en video op aanvraag) en streaming voor real-time interactieve audio en video. De eerste twee categorie¨en zijn van toepassing op deze thesis. We vermeldden ook enkele alternatieven voor streaming en toonden aan 5
Een sampleklok is een klok die de tijd weergeeft in de opname van het bestand. Bij het begin van het bestand en dus ook het begin van de opname staat deze klok op nul.
14
waarom streaming een betere oplossing is. Vervolgens gaven we een opsomming van enkele toepassingsdomeinen. We zagen dat het MMS-protocol een tegenhanger is van RTSP, RTP en RTCP en dat tegenwoordig de voorkeur gegeven wordt aan de laatstgenoemde protocols. Verder bespraken we de werking van RTSP, RTP en RTCP. We vergeleken RTSP met HTTP en gaven een overzicht van de soorten RTSP-berichten. Ook hebben we gezien dat RTSP dient om het afspelen van streams te regelen, dat met RTP de eigenlijke multimediale data verpakt en verzonden worden en dat met RTCP gecommuniceerd wordt over de kwaliteit van de verbinding[2, 10].
15
Hoofdstuk 3 Werkwijze In dit hoofdstuk bekijken we hoe de implementatie tot stand gekomen is. Eerst werpen we een blik op wat we allemaal nodig hebben en waarvan we vertrekken. We bespreken de kandidaat-softwarepakketten en de keuze van het meest geschikte softwarepakket. Daarna lichten we toe wat er juist ge¨ımplementeerd is en wat de functie ervan is. Aan het einde van dit hoofdstuk bespreken we de belangrijkste ontwerpsbeslissingen in het verloop van de ontwikkeling.
3.1
Opstelling
In Figuur 3.1 zien we de belangrijkste componenten van de architectuur. We zullen ze eerst afzonderlijk bespreken.
3.1.1
Serversoftware: Darwin Streaming Server
Bij de serversofware kozen we voor Darwin Streaming Server. Dit is de gratis versie van de commerci¨ele QuickTime Streaming Server. Met deze Darwin Streaming Server kan je media streamen via RTP en RTSP. Deze open-source server bevat broncode die rechtstreeks uit de broncode van de QuickTime Streaming Server komt, is gemakkelijk aanpasbaar en draait op verschillende besturingssystemen (Mac OS X, Linux en Windows). Gebruikers kunnen met deze server live-uitzendingen volgen of vooraf opgenomen media bekijken. De bestanden die aangeboden worden, moeten wel gecomprimeerd worden, om bandbreedtegebruik te beperken. De QuickTime Streaming Server en Darwin Streaming 16
Figuur 3.1: Opstelling
Server ondersteunen verscheidene videocompressietechnieken en drie bestandsformaten voor video (zie tabel 3.1). Bestandsformaat .mov .mp4 .3gp
Ondersteunde compressiestandaard Cinepak, H.261, H.263, H.264, MPEG-4 Video, Sorenson Video, Sorenson Video 3 MPEG-4 Video MPEG-4 Video
Tabel 3.1: Ondersteunde bestandsformaten en compressiestandaarden voor video van QuickTime/Darwin Streaming Server
Hoewel audio al een veel lagere bitsnelheid heeft dan video, is het toch nog voordelig audio ook te comprimeren. De ondersteunde audiocompressiestandaarden staan in tabel 3.2. Om de bestanden te streamen moeten er hintsporen aan toegevoegd worden. Zulke hintsporen worden gebruikt om de verzending te optimaliseren. Ze bevatten informatie 17
Bestandsformaat .mov .mp4 .3gp
Ondersteunde compressiestandaard IMA 4:1, MPEG-4 Audio (AAC Low Complexity), QDesign Music 2, Qualcomm PureVoice, uLaw 2:1 MPEG-4 Audio (AAC Low Complexity) AMR-NB (Speech), AAC Low Complexity
Tabel 3.2: Ondersteunde bestandsformaten en compressiestandaarden voor audio van QuickTime/Darwin Streaming Server
over hoe en wanneer elk stuk media moet afgeleverd worden en wanneer de mediaspeler de stream raadpleegt. De hintsporen worden zelf nooit verzonden over het netwerk[1, 5, 21]. Naast Darwin Streaming Server hadden we ook nog kunnen kiezen voor: • Helix Server. Dit is een streaming server van RealNetworks. Onder andere RealAudio, RealVideo, Windows Media, QuickTime, MP3, MPEG-4, 3GPP (H.263 en H.264) kan hiermee aangeboden worden. Helix Server draait op verschillende platforms, waaronder Windows, Linux en Solaris. Toch zijn er een aantal redenen waarom we niet kozen voor deze server om de streaming implementatie te testen. De gratis versie van de Helix Server laat slechts 5 streams tegelijk toe. Op zich is het geen probleem om een dergelijke server te gebruiken voor de ontwikkeling van een applicatie aan de clientkant, maar een groter obstakel voor mogelijk lange programmeerprojecten is dat deze gratis versie slechts bruikbaar is voor ´e´en jaar. Na een jaar verloopt de licentie[17]. • pvServer. Deze server, die vroeger PacketVideo Streaming Server heette, is ontwikkeld door PacketVideo Network Solutions, een bedrijf dat eigendom is van Alcatel-Lucent. pvServer ondersteunt de belangrijkste compressiestandaarden zoals AMR, AAC, QCELP, Enhanced aacPlus, MPEG-4, H.263 en H.264. De server richt zich vooral tot mobiele toestellen, die verbonden zijn via draadloze netwerken. De server draait enkel op HP-UX, Sun Solaris en Linux. Helaas is pvServer niet gratis. Voor een periode van 60 dagen kan je hem wel gratis uittesten. Het niet in het bezit zijn van een geschikt platform en de voorkeur voor een gratis server elimineerden deze servertoepassing uit de mogelijke kandidaten[16]. • LIVE555 Media server. Dit is de streaming server van Live Networks, hetzelfde bedrijf waar de clientimplementatie uit Figuur 3.1 vandaan komt. Deze open-source server kan volgende mediabestanden streamen: MPEG Transport Stream bestand
18
(“.ts”), MPEG-1 en 2 Programma Stream bestand (“.mpg”), MPEG-4 Video Elementair Stream bestand (“.m4e”), MPEG-1 of 2 (inclusief layer III) audio bestand (“.mp3”), WAV (PCM) audio bestand (“.wav”), AMR audio bestand (“.amr”) en AAC audio bestand (“.aac”). De vooraf gecompileerde versies van deze server zijn beschikbaar voor Windows, MacOS X (op Intel x86 processoren), Linux (op Intel x86 processoren)en FreeBSD(op Intel x86 processoren). De eerste versie van deze server is uitgebracht op 9 december 2006. Met de implementatie van deze thesis werd al vroeger gestart, dus deze server behoorde in het begin nog niet tot de keuzemogelijkheden[11]. Bij de aanvang van de implementatie was Darwin Streaming Server dus de beste keuze. Darwin Streaming Server draait op verschillende besturingssystemen, ondersteunt voldoende compressietechnieken en was uit het aanbod van de meest bekende streaming servers de enige server die bij het begin van de implementatie voor onbeperkte duur gratis was. De implementatie is niet specifiek gericht tot de gekozen server, normaal gezien zou het ook met de andere vermelde servers moeten werken.
3.1.2
Bestaande implementaties voor streaming aan clientzijde
Bij de implementatie gebruiken we het LIVE555 Streaming Media pakket[12]. Dit is een verzameling programmeerbibliotheken voor streaming met RTP/RTCP, RTSP en SIP. Het is geprogrammeerd in C++ en is volledig open-source. De broncode kan gecompileerd worden voor Unix (inclusief Linux en Mac OS X), Windows en QNX (en andere POSIXsystemen). Enkele programma’s van LIVE555 zelf maken er gebruik van, zoals LIVE555 Media Server, liveCaster, playRTPMPEG, vobStreamer en enkele eenvoudige testprogramma’s om streams te versturen en te ontvangen. Die testprogramma’s zijn vaak gespecialiseerd voor ´e´en bepaalde compressietechniek. Meer bekende toepassingen waar de LIVE555 Streaming Media software als basis dient voor het streaming gedeelte, zijn onder andere VLC media player (VideoLan)[22] en MPlayer[14]. De laatste mediaspeler werd ook gebruikt bij de ontwikkeling van de streaming extensie. Het was handig om te vergelijken op welke manier het LIVE555 Streaming Media pakket werd aangewend in de broncode van MPlayer. Bijgevolg zijn ook enkele stukken broncode van MPlayer overgenomen. 19
Deze MPlayer is een open-source mediaspeler voor Linux, Windows en Mac OS X. De broncode van deze speler is gemakkelijk uitbreidbaar met het LIVE555 pakket. Daarvoor moet men eerst de LIVE555 Streaming Media programmeerbibliotheken compileren. Met een bijgeleverd configuratiescript wordt de aanwezigheid van de streaming ondersteuning van LIVE555 opgemerkt en een aangepast makefile-bestand wordt dan gemaakt. De compiler gebruikt dan een dergelijk bestand om de speler te bouwen en om te zetten naar een uitvoerbaar bestand. De implementaties van Henning Schulzrinne, een mede-ontwerper van het RTP en RTSP protocol (http://www.cs.columbia.edu/IRT/software/rtptools/) hadden we ook kunnen gebruiken. Het LIVE555 scoort beter op vlak van gebruiksvriendelijkheid. Het is gemakkelijker om een toepassing met LIVE555 uit te te breiden dan de RTP Tools te gebruiken. Bij LIVE555 hadden we dan nog het voordeel dat er toonaangevende voorbeelden zijn die een bron van inspiratie konden zijn.
3.1.3
De gebruikte mediaspeler: The Core Pocket Media Player
The Core Pocket Media Player (TCPMP) is een mediaspeler voor Pocket PC, ontwikkeld door CoreCodec. De speler is begonnen als een open-source mediaspeler voor Windows CE en Windows Mobile. Aanvankelijk heette de speler Betaplayer, maar in 2005 vond een naamsverandering plaats. De speler werd toen ook beschikbaar gemaakt voor Palm OS en Symbian. Later onderging TCPMP weer een naamsverandering en werd het CorePlayer Mobile. Helaas is CorePlayer Mobile open-source noch gratis. TCPMP kan een ruime hoeveelheid compressietechnieken aan: • Audio: MPEG 1 Layer III, Ogg Vorbis, Musepack, Windows Media Audio (op Windows Mobile toestellen), AC-3, AMR, Adpcm en uLaw. • Video: DivX, XviD, MPEG4-SP (plus B-frame ondersteuning), MPEG1, M-JPEG en Windows Media Video (op Windows Mobile toestellen). • Ondersteunde containerformaten: AVI (“.avi”), Matroska (“.mkv”, “.mka”), MP4 (“.mp4”,“.m4a”), Ogg Media (“.ogg”, “.ogm”), ASF (“.asf”). Een alternatief om audio en video te streamen naar pda is RealPlayer for Mobile[18]. RealPlayer is beschikbaar voor Symbian AS en Palm OS 5 voor PDA’s en enkele telefoon20
toestellen waaronder de Nokia 9200 Series Communicators en Nokia Series 60 telefoons (zoals Nokia 7650 en 3650). De belangrijkste kenmerken zijn: • lokaal afspelen van audio- en videobestanden vanuit geheugen of multimedia kaart; • streaming van live presentaties en audio en video op aanvraag; • ondersteunde formaten: Bestandsformaat RealAudio (“.ra”, “.rm”) RealVideo (“.rm”) 3GPP (“.3gp”)
Ondersteunde compressiestandaard RealAudio G2, RealAudio 8 en Sipro Voice RealVideo G2 en RealVideo 8 codecs MPEG4 en H.263 (enkel lokaal, geen streaming)
Tabel 3.3: Ondersteunde bestandsformaten en compressiestandaarden van RealPlayer for Mobile
• bestandsoverdracht via Infrarood, BlueTooth, MMS en Multimedia kaartlezer; • toegang tot nieuws, sport en entertainment updates. Door TCPMP uit te breiden, kunnen we het aantal ondersteunde bestandsformaten en codecs voor streaming overtreffen. Met RealPlayer zijn we beperkt tot RealAudio en RealVideo bestandsformaten, bestandsformaten die enkel door een Helix Server aangeboden kunnen worden. Kiezen voor RealPlayer als streaming oplossing voor Pocket PC zou al direct de keuze voor de streaming server vastleggen. Ook bij het aanbod van lokaal afspeelbare bestandsformaten scoort The Core Pocket Media Player beter. Bovendien is TCPMP open-source waardoor het zich goed leent voor aanpassingen en uitbreidingen[3].
3.2 3.2.1
Implementatie Overzicht broncode The Core Pocket Media Player
Wanneer we een blik werpen op de broncode van The Core Pocket Media Player zien we dat deze opgesplitst is in verschillende deelprojecten: • projecten die voor de basisfunctionaliteit van de speler zorgen: – grafische gebruikersinterface 21
– een project waarmee je het programma opstart – een algemeen project met datastructuren die overal gebruikt worden en van waaruit bestanden ingelezen en verwerkt worden • projecten voor specifieke bestandformaten zoals matroska en een project voor bestanden van het type asf, avi, mov, mpg, wav ... • een netwerkproject waar http-streaming al in ge¨ımplementeerd is • projecten voor video hardwareversnelling met Intel2700G en ATI3200 • projecten voor het decomprimeren van audio en video. De implementatie van de streaming extensie bevindt zich bijna volledig in het netwerkproject. Enkele kleine aanpassingen situeren zich ook in het project met de naam “common”, het project met de datastructuren van waaruit bestanden ingelezen en verwerkt worden.
3.2.2
Afspelen van een bestand
De speler start men op door player ce2.exe of player ce3.exe te activeren. Het verschil tussen beide is dat bij player ce3.exe een menubalk getoond wordt met een menu voor bestand en opties, bij player ce2.exe ontbreken deze menu’s. Als men een bestand wil openen, klikt men in het bestandsmenu op “Open bestand...”. Dan typt men de locatie van het bestand in de balk bovenaan of men klikt op de map waar het bestand in zit en men klikt uiteindelijk op het bestand dat men wil openen. Vanaf het moment dat de speler geopend is, speelt het common-project een centrale rol. In het common-project en meer specifiek in player.c wordt de te openen url geanalyseerd. Er wordt nagegaan of het een lokaal bestand is of een bestand dat via http (of rtsp met de streaming uitbreiding) geopend moet worden. Aan de hand van de extensie van het bestand bepaalt de speler welk bestandsformaat het is. Voor we verdergaan met de werking van de speler, moeten we een belangrijke datastructuur introduceren, de zogenaamde node. Die node wordt gebruikt om van een type datastructuur de juiste functies in te stellen. We leggen het uit met een voorbeeld. Stel dat de url verwijst naar een bestand. De url begint dan met “file://”. Aan de hand van een integer gevormd met 32 bits die een opeenvolging zijn van de vier 8-bit karaktercodes van ‘F’, ‘I’, ‘L’ en ‘E’ wordt gezocht naar de juist node. In de bestanden lang std.txt 22
en de bestanden met bestandsnaam gevormd door lang + taalcode + .txt (bijvoorbeeld lang en.txt) vinden we een lijst met de vier benodigde karakters, gevolgd door vier cijfers, een gelijkheidsteken en tekst. Eerst wordt naar de tekst gezocht en daarna komt men bij de juiste karakters om de integer te vormen waarmee de node kan gezocht worden. Deze berekening schept iets meer duidelijkheid omtrent de bepaling van de integer: Op big endian toestellen is de integer voor karakters ‘a’, ‘b’, ‘c’, ‘d’ gevormd door: (((unsigned char)a << 24) | ((unsigned char)b << 16) | \ ((unsigned char)c << 8) | ((unsigned char)d << 0)) Op low endian toestellen hebben we: (((unsigned char)a << 0) | ((unsigned char)b << 8) | \ ((unsigned char)c << 16) | ((unsigned char)d << 24)) De File-node ziet er als volgt uit: static const nodedef File = { sizeof(filestream), FILE_ID, STREAM_CLASS, PRI_MINIMUM, (nodecreate)Create, (nodedelete)Delete, }; Deze node wordt dan gebruikt om de juiste streamklasse aan te maken. Met behulp van de Create-functie worden de benodigde functies ingesteld voor de streamklasse. Voor een streamklasse zijn dit dan Get, Set, Read, ReadBlock, Seek, EnumDir en Write. Het instellen van die functies gebeurt op de volgende manier: static int Create(filestream* p) { p->Stream.Get = (nodeget)Get, ... } 23
Na de creatie van de streamklasse worden, nog steeds in player.c, enkele parameters ingesteld. Later maakt de speler nog een andere klasse aan, deze keer niet van het type STREAM CLASS, maar van het type FORMATBASE CLASS. Deze klasse kiest men op basis van het bestandstype. Stel dat we nu voor een mp4-bestand gekozen hebben, dan wordt het splitterproject aangesproken. Dit is het project dat instaat voor de verwerking van asf-, avi-, wav-, mpg- en mp4-bestanden. Dit project laadt de mp4-node in. Die ziet er als volgt uit: static const nodedef MP4 = { sizeof(mp4), MP4_ID, FORMATBASE_CLASS, PRI_DEFAULT, (nodecreate)Create, }; De Create-functie maakt hier evenwel andere functies aan dan de streamklasse. Voor mp4 zijn dit Init, Seek, ReadPacket en FreeStream. De volgende functie die de speler oproept is de init-functie. De init-functie haalt essenti¨ele informatie voor de decodering van audio en video al uit het bestand. Met die informatie wordt een gepaste codec gezocht. Deze keer wordt enkel gekeken in het bestand lang std.txt om de integer voor de codec te zoeken. De broncode voor de codec komt dan uit een van de projecten voor decompressie. Ook hier gebruikt men een node om de codecfuncties aan te maken. In vorige paragraaf vermeldden we al dat er een stuk van een bestand ingelezen werd. Dit inlezen gebeurt eigenlijk via de streamklasse die eerder werd aangemaakt. Wanneer men iets uit het bestand wil lezen, wordt er eerst uit een buffer gelezen. Als die buffer leeg is wordt een volledig blok weer ingelezen en wordt de buffer opgevuld. Nu de initialisatie voltooid, is kan het afspelen beginnen. De speler roept de functie ReadPacket uit mov.c aan. Deze functie leest – zoals de naam al doet vermoeden – een pakket in. Nadien worden uit het ingelezen pakket de feitelijke gegevens ge¨extraheerd die de codec vervolgens verwerkt en naar het uitvoerapparaat stuurt. Het inlezen van pakketten in ReadPacket gebeurt ook met de koppeling aan de streamklasse. 24
3.2.3
Afspelen met de streaming implementatie
Nu we weten hoe de speler met bestanden omgaat, kunnen we bekijken hoe het streaminggedeelte zich daar naar kan schikken, zodat de basis van de speler dezelfde kan blijven. We zullen hier ook de belangrijkste methoden bespreken en de verschillen uitleggen. Eveneens zullen we de rol van LIVE555 toelichten. De gebruiker start de speler en kiest voor “Open bestand...” uit het bestandsmenu. Daarna typt hij de url in de adresbalk. De url moet er dan als volgt uitzien: rtsp :// www.server.com {z } / bestand.mp4 | | | {z } {z }
protocol
serveradres
bestandsnaam
Men kan het poortnummer nog vermelden na het serveradres door er een dubbelepunt achter te plaatsen, gevolgd door het poortnummer. Standaard wordt voor poort 554 gekozen, het door IANA geregistreerde poortnummer voor rtsp[9]. Na de invoer van de url wordt er opnieuw gezocht naar de gepaste node voor de streamklasse. Dit keer komt men terecht bij een node van het type RTPSTREAM. De Create-functie ervan zorgt voor de creatie van volgende functies: static int Get(rtpstream* p, int No, void* Data, int Size) static int Open(rtpstream* p, const tchar_t* URL, bool_t ReOpen) static int Set(rtpstream* p, int No, const void* Data, int Size) static int Read(rtpstream* p, void* Data, int Size) static int ReadBlock(rtpstream* p, block* Block, int Ofs, int Size) static int Seek(rtpstream* p, int Pos, int SeekMode) static int Write(rtpstream* p, const void* Data, int Size) static int EnumDir(rtpstream* p, const tchar_t* URL, const tchar_t* Exts, bool_t ExtFilter, streamdir* Item) De invulling van deze functies is echter miniem. Eigenlijk gebruiken we de rtpstream niet om van te lezen, zoals dat bij een bestand wel gebeurt. De nodige functies zijn enkel voorzien om te vermijden dat er veel aanpassingen moeten gebeuren in het commonproject van de speler. De reden waarom we niet werken via de rtpstream is omdat er te grote verschillen zijn met een gewoon bestand. Bij RTP/RTSP is het namelijk zo dat de inhoud van een bestand aankomt bij de speler in een of meerdere streams. Als men 25
bijvoorbeeld een filmpje met geluid wil afspelen, zal er meestal een stream zijn enkel voor video en een stream met de audio. Zomaar een hoeveelheid bytes inlezen zal dus niet werken, omdat niet duidelijk is of audio of video moet ingelezen worden. Later is het de beurt aan het FORMATBASE CLASS-type. Om er voor te zorgen dat de speler altijd terechtkomt bij de streaming implementatie en niet bij de implementatie voor een bepaald bestandstype, voegen we “.rtp” aan de url toe. Op die manier gaat de speler dan op zoek naar bestandsformaat met “.rtp” als extensie. Deze toevoeging gebeurt uiteraard enkel als de url met “rtsp://” begint. De node die hier van toepassing is, kreeg de naam RTP en wordt gevonden aan de hand van de integer gevormd door ‘R’, ‘T’, ‘P’ en ‘ ’ op dezelfde manier als bij FILE. De functies die hier van belang zijn, zijn hieronder opgesomd. De functie Create is de functie waarnaar verwezen wordt in de RTP-node. Ze stelt Init en ReadPacket in. static int ReadPacket(rtp* p, format_reader* Reader, format_packet* Packet) static int Init(rtp* p) static int Create(rtp* p) Analoog aan het openen van een bestand roept de speler na de vondst van de juiste node en de creatie van de benodigde functies de functie Init op. Init is verantwoordelijk voor het verzamelen van de informatie voor de codecs en het in gereedheid brengen van alles, zodat later zonder problemen de functie ReadPacket kan aangeroepen worden. In het belang van de begrijpelijkheid van de werking van Init en ook ReadPacket geven we eerst de opbouw van de rtp-datastructuur. typedef struct rtp { format_base Format; int id_ReadBuffer; stream_t* stream; demuxer_t* demuxer; demux_stream_t* d_audio; demux_stream_t* d_video; sh_audio_t* sh_audio; sh_video_t* sh_video; 26
int startedplaying; } rtp; Voor de implementatie van Init en ReadPacket werd inspiratie opgedaan bij de broncode van MPlayer. Enkele methoden en datastructuren werden daarbij overgenomen. Binnen de Init-functie wordt een stream t gemaakt. Dit gebeurt op basis van het protocol uit de url. Bij het aanmaken van de stream t stellen we ook het type demuxer1 in, in ons geval is dit DEMUXER TYPE RTP. Vervolgens openen we een demuxer van dit type. Hierbij verzenden we al direct een DESCRIBE-bericht (pagina 8). Per RTP-stream maakt de LIVE555-implementatie een ontvanger aan. Zo’n ontvanger bevat onder meer een RTCP-instantie. De RTCP-instantie verzendt bij creatie al meteen een RTCP-bericht en plant daarna het tijdstip waarop het volgende RTCP-bericht gestuurd moet worden. De RTCP-instantie begint ook onmiddellijk binnenkomende RTCPberichten af te wachten. Vervolgens sturen we een SETUP-bericht (pagina 9). Zoals de RTSP-specificatie het voorschrijft, doen we dat per stream van het bestand dat we willen afspelen. Direct na het versturen wachten we ook het antwoord af en verwerken dit bij ontvangst. Wanneer de SETUP-interactie afgerond is, versturen we een PLAY-bericht (pagina 9). Bij containerformaten hoeven we maar ´e´en bericht te sturen.
Eens dit allemaal afgelopen is, kunnen we beginnen met de informatie met betrekking tot de codecs te verzamelen en in te stellen. Bij MPlayer zijn daar de methoden rtpCodecInitial en rtpCodecInitialize video voor voorzien. We laten die eerst hun werk doen en halen dan later de benodigde informatie uit de datastructuren van MPlayer. Dit is de laatste fase van onze Init-functie. Tot slot hebben we nog de functie ReadPacket. We krijgen als argumenten rtp* p, format reader* Reader en format packet* Packet. Afhankelijk van de actieve stream van de Reader zullen we audio of video inlezen. We stellen die stream in als stream van het Packet. Voorts kopi¨eren we informatie over de vorm van de audio of video naar variabelen van de stream. Voor video zijn dit bijvoorbeeld hoogte, breedte, codec ... Enkele van de voor audio in te stellen variabelen zijn variabalen met betrekking tot codec, kanalen, aantal bits per sample, aantal samples per seconde. 1
Demuxer is de term die gebruikt wordt voor een systeem dat ´e´en invoersignaal heeft en dat opsplitst naar meerdere signalen. Het woord is afgeleid van “demultiplexer”.
27
Eens we dit allemaal ingesteld hebben, gaan we over tot het effectief inlezen van de bits van de audio- of videodata uit de RTP-stream met ds get packet, een functie van MPlayer. De functie krijgt de bijhorende demux stream t en een pointer naar het begin van de in te vullen buffer mee en schrijft dan het pakket naar de buffer. Tenslotte vullen we nog twee variabelen in: het aantal bytes dat we ingelezen hebben en de tijd die overeenkomt met het begin van de buffer. Afbeelding 3.2 laat de opeenvolging van de functies zien wanneer alles goed verloopt.
Figuur 3.2: Interactie tussen player.c, rtp win32.c/LIVE555 en de server
28
Afbeeldingen 3.3 en 3.4 tonen aan de hand van uml-klassediagrammen[4] de positie van respectievelijk rtp en rtpstream in de implementatie. De opsomming van attributen is niet exhaustief, enkel de belangrijkste zijn getoond.
Figuur 3.3: De positie van rtp in de implementatie
3.3 3.3.1
Gebruikte toestellen, bestanden en verbinding Gebruikte toestellen
Tabel 3.4 en 3.5 geven de eigenschappen van de toestellen weer die gebruikt werden om de implementatie te testen.
29
Figuur 3.4: De positie van rtpstream in de implementatie
3.3.2
Gebruikte bestanden
Tot slot geven we nog wat informatie over de gebruikte bestanden met hun codecs. Om de streaming uitbreiding te testen gebruikten we de bij de Darwin Streaming Server bijgeleverde bestanden. In de eindfase van de ontwikkeling fungeerden enkel sample 100kbit.mp4 en sample 300kbit.mp4 als testbestanden om zo snel mogelijk tot een demonstreerbaar resultaat te komen. Door ons vast te pinnen op bestanden met dezelfde codecs, was het veel eenvoudiger om te volgen wat er gebeurde en te achterhalen wat er mis ging. Het tweede bestand is van betere kwaliteit dan het eerste. De codecs van deze bestanden zijn: • Audio: MPEG-4 Audio (AAC) 30
Model: Processortype: Processorsnelheid: RAM-geheugen: ROM-geheugen: Besturingssysteem:
Dell Axim X30 R Intel PXA270 624 MHz 64 MB 64 MB Microsoft Windows MobileTM 2003 Second Edition Tabel 3.4: Systeemeigenschappen Pocket PC
Model: Processortype: Processorsnelheid: RAM-geheugen: Besturingssysteem:
Medion MD 42200 R R Intel Pentium
M 1.70 GHz 512 MB Microsoft Windows XP Home Edition Versie 2002 Service Pack 2 Tabel 3.5: Systeemeigenschappen servercomputer
• Video: MPEG-4 Video (MP4V-ES)
3.3.3
Verbinding
Tijdens de ontwikkeling van het programma gebruikten we een TCP-verbinding. Eigenlijk zijn er verschillende manieren om de Pocket PC fysiek te verbinden met de servercomputer. Die verbinding kan gemaakt worden via USB, infrarood, draadloze netwerkverbinding en Bluetooth. De server beschikt niet over Bluetooth, konden we dit al elimineren. Problemen met de draadloze netwerkverbinding en infrarood tussen de Pocket PC en de servercomputer noodzaakten ons om te kiezen voor USB als fysieke verbindingsmanier. Om dan vlot te kunnen communiceren dienen we de toepassing ActiveSync te gebruiken. Dit programma moet dan op beide systemen ge¨ınstalleerd worden. Men kan er dan bestanden mee overzetten en de Pocket PC kan dan via de pc verbinding maken met het internet. Er is echter wel een beperking aan verbonden, namelijk dat ActiveSync geen UDP-verkeer doorlaat. In de beginfase was het ook wenselijk om voor de meest betrouwbare verbindingsmanier te kiezen. Pas wanneer men een werkende basisversie heeft kan men zich gaan concentreren op meer geavanceerde problemen, zoals het omgaan met pakketverlies. De twee bovenvermelde redenen lagen aan de basis van de keuze voor de TCPverbinding. Het vergt slechts een kleine aanpassing in de implementatie om over te schakelen op UDP voor RTP en RTCP. UDP is echter beter geschikt voor de levering 31
van multimediale data. We leggen in de volgende paragrafen uit waarom. Een van de sterke punten van TCP is zijn betrouwbaarheid. TCP voorziet bescherming tegen fouten, waardoor TCP een uitmuntend protocol is voor de overdracht van data, maar de manier waarop dit ge¨ımplementeerd is, blijkt nadelig te zijn voor streaming toepassingen. Bij TCP is er verkeer in twee richtingen: de ene computer stuurt de gegevens en de andere computer stuurt ontvangstbevestigingen terug. TCP voegt volgnummers en bevestigingsnummers toe aan de pakketten. Een volgnummer van een pakket is het bytestreamnummer van de eerste byte in het pakket. Een bevestigingsnummer is een nummer dat de ontvanger in zijn pakket plaatst. Het is het volgnummer van de volgende byte die de ontvanger verwacht. Als bytes niet bevestigd zijn voor ontvangst binnen een bepaalde termijn worden ze opnieuw verzonden. Dit kenmerk van TCP laat toestellen toe verloren pakketten te detecteren en retransmissie aan te vragen. Een herhaalde transmissie zal een extra vertraging veroorzaken bij de communicatie, wat normaal geen probleem is bij de overdracht van data. TCP voorziet ook flow control en congestion control, technieken waarbij de snelheden van verzender en ontvanger op elkaar worden afgestemd. Flow control zorgt ervoor dag geen van de uiteinden van een verbinding overbelast raakt doordat er te veel pakketten te snel worden verzonden. Wanneer routers2 tussen de uiteinden overbelast dreigen te raken en buffers overlopen waardoor pakketten verloren gaan, treedt congestion control in werking door de verzendsnelheid te verlagen. Met audio en video, wenst de kijker een continue weergave in real-time. Retransmissie van data voegt vertragingen toe en verbruikt ook extra bandbreedte. Uiteindelijk zal bij een grote hoeveelheid fouten de ontvangstbuffer bij de mediaspeler leeg raken. De onderbreking in de stream zal uiteindelijk leiden tot onderbrekingen in de weergave. Het alternatief is om verloren pakketten te negeren. Daardoor kan een beeld verloren gaan of slecht weergegeven worden, maar dat is een voorbijgaande gebeurtenis die amper als storend ervaren zal worden door de gebruiker. Voor real-time toepassingen is tijdige levering belangrijker dan foutvrije overdracht. UDP is een transmissieprotocol dat datafouten kan negeren. Technieken zoals foutcorrectie, flow control en congestion control ontbreken bij UDP. Door het gebrek aan deze mechanismen kunnen hogere snelheden gehaald worden met UDP. Het verlies van enkele pakketten kan ook getolereerd worden. Als pakketten in de verkeerde volgorde aankomen is er nog het RTP-protocol dat er voor zorgt dat pakketten in de juiste volgorde afgespeeld 2
Een router is een tussenstation op knooppunten in een netwerk dat zorgt voor de verzending van gegevens naar de juiste bestemming.
32
worden. UDP werkt maar in ´e´en richting, de ontvanger hoeft geen ontvangstbevestigingen te sturen. In tegenstelling tot TCP kunnen we met UDP dus wel data aan constante snelheid versturen. Daardoor kunnen we met UDP wel een continue weergave bereiken, evenwel met mogelijk hier en daar een foutje in de weergave. Aangezien we een continue foutbevattende weergave verkiezen boven een onderbroken foutloze weergave mogen we besluiten dat UDP het meest geschikt is voor streamingtoepassingen[10].
3.4
Verloop van de ontwikkeling
Afgezien van de gebruikelijke programmeerproblemen waren er ook structurele problemen en ontwerpsbeslissingen waarvan we de belangrijkste hier op een rijtje zetten.
3.4.1
Zelf RTSP voorzien
Na studie van het RTSP-protocol en onderzoek naar de werking van de broncode zijn we begonnen met ´e´en voor ´e´en de belangrijkste RTSP-methodes te implementeren. Eerst hebben we achterhaald op welke plaats in de broncode welk RTSP-bericht verstuurd moest worden. Dan hebben we methodes voorzien per RTSP-methode. Op basis van de informatie over het af te spelen bestand werd dan een bericht samengesteld. Dan werd met behulp van een TCP/IP-socket het bericht verzonden en het antwoord afgewacht. Wanneer het antwoord ontvangen was, werd de nuttige informatie er uit gehaald en naar variabelen gekopieerd. Eens de DESCRIBE-methode, de SETUP-methode en de PLAYmethode van RTSP ge¨ımplementeerd waren, kon overgegaan worden naar het effectief ontvangen van de multimediale data. Wegens de complexiteit van het RTP-protocol zijn we beginnen zoeken naar bestaande implementaties voor dit RTP-gedeelte. Dan hebben we eerst de programma’s van professor Henning Schulzrinne, een mede-ontwerper van het RTP en RTSP protocol, (http://www.cs.columbia.edu/IRT/software/rtptools/) onder de loep genomen, maar na enig verder zoekwerk kwamen we bij LIVE555 terecht. De DESCRIBE-methode behielden we toen, omdat we daarmee gemakkelijk aan de informatie uit het antwoord op het DESCRIBE-verzoekbericht konden geraken.
33
3.4.2
LIVE555 en de functie om streams naar een bestand te schrijven
Testprogramma’s bij het LIVE555-pakket bezaten de mogelijkheid om streams naar een bestand weg te schrijven. Met het oog op het beperken van aanpassingen aan de speler zelf hebben we getracht om te simuleren dat de speler van een bestand las. Het testprogramma lieten we dan in plaats van naar een bestand te schrijven naar een datastructuur in het geheugen schrijven. Met deze datastructuur kon men hetzelfde doen als met een FILE uit C, met dat verschil dat het zich allemaal in het geheugen afspeelde. De speler kon dan van dit bestand in het geheugen lezen op dezelfde manier als hij van een opgeslagen bestand las. Er waren echter wel problemen met de structuur van het bestandsformaat. We gebruikten de structuur van een mp4-bestand, maar wanneer de speler het bestand begon in te lezen, moest al informatie aanwezig zijn die pas beschikbaar was nadat de hele stream afgespeeld was. Een mp4-bestand bestaat uit verschillende atomen. Elk atoom kan nog eens uit meerdere andere atomen bestaan. Het was zo dat de speler eerst over het eerste atoom wou springen om, dan direct atomen in te lezen die informatie bevatten over audio- en videocompressie. We hebben dan de atomen herschikt, maar het probleem bleef bestaan dat cruciale informatie pas na volledige ontvangst van de stream kon ingevuld worden. Omdat eigenlijk ook overbodig werk werd gedaan, beslisten we om voor het RTPgedeelte toch een structuur te voorzien, gelijkaardig aan de structuur die mp4-bestanden inleest. Wat overbodig is aan de manier van het eerst omzetten naar een mp4-bestand, is de stap waarin streams weer samengevoegd worden in ´e´en geheel, terwijl ze er later weer moeten uitgehaald worden omdat ze apart moeten gedecodeerd worden.
3.4.3
Audio
Nadat de datastructuren voorzien waren zoals ze besproken zijn bij de werking van de streamingimplementatie, moesten deze uitgetest worden. Daarvoor kozen we eerst voor een eenvoudig audiobestand. De keuze voor de stream waaruit gelezen moest worden was dan ondubbelzinnig. Hierbij konden we dan zonder al te veel hindernissen uitzoeken hoe de stream moest gelezen worden. Na enig zoekwerk slaagden we er in geluid uit de speler te krijgen. Eerst was dit geluid er onder de vorm van geruis, maar na enkele aanpassingen werd de muziek van het oorspronkelijk bestand wel herkenbaar. Het geproduceerde geluid
34
was echter nog niet optimaal. Het was eerder een afwisseling van stukjes muziek en stiltes. Omdat de aanwezigheid van video minstens even belangrijk was als het geluid, hebben we niet langer naar de oorzaak gezocht en zijn we begonnen aan de uitbreiding tot video.
3.4.4
Audio en Video
Het inlezen van video diende op nagenoeg dezelfde manier te gebeuren als bij audio, doch enige aanpassingen waren nodig. Zo hebben we bij het zoeken naar de passende methode om videodata in te lezen een goede methode gevonden in de broncode van MPlayer om in ´e´en bewerking een volledig geheel aan databytes in te lezen. Dit had aanvankelijk tot gevolg dat al het eerste beeld te zien was, maar dat de speler nog niet startte met de weergave van de rest van het bestand. Na enig verder onderzoek bekwamen we dan uiteindelijk een vooruitgaande weergave. Gebruik makend van de vondsten voor het inlezen van videodata werden ook aanpassingen aangebracht aan de manier van inlezen van audiodata, met vloeiend ononderbroken geluid tot gevolg. Een van de aanpassingen voor het geluid was het gebruik van dezelfde inleesmethode als bij video. De weergave van video staat echter nog niet op punt. Groene blokken verstoren het beeld nog af en toe.
35
Hoofdstuk 4 Conclusies 4.1
Inleiding
We starten dit hoofdstuk met de bespreking van de behaalde resultaten. De belangrijkste eigenschappen van de implementatie worden aangehaald. Voorts bespreken we enkele tekortkomingen aan de implementatie en reiken we enkele idee¨en aan die voor een verbetering kunnen zorgen.
4.2
Resultaten
We hebben in de eerste plaats aangetoond dat The Core Pocket Media Player kon uitgebreid worden met streaming en dat de uitbreiding werkt op een toestel met beperkte capaciteiten. Het toestel waarvan de eigenschappen in tabel 3.4 staan, voldeed alleszins aan de minimumvereisten. We hebben de uitbreiding gerealiseerd met behulp van de in C++ ge¨ımplementeerde programmeerbibliotheken van LIVE555. Bijgevolg kunnen we nu audio en video streamen naar TCPMP gebruik makend van RTSP, RTP en RTCP. We zijn in staat enkele van de voorbeeldbestanden af te spelen die meegeleverd werden bij de installatiebestanden van Darwin Streaming Server. De bestanden die we kunnen afspelen zijn mp4-bestanden met MPEG-4 audio (AAC) en MPEG-4 video (MP4V-ES). In het beeld verschijnen nog wel groene blokken af en toe.
36
De verbinding waarlangs alle protocolpakketten verstuurd worden is een TCP-verbinding. Voor de levering van RTP- en RTCP-pakketten is dit niet de meest optimale verbinding. Een UDP-verbinding is daarvoor beter geschikt. We kozen deze verbinding omwille van de beperking tot een USB-verbinding bij de testtoestellen en de daaruit volgende beperking tot een verbinding via ActiveSync, dat geen UDP-verkeer doorlaat. Van de RTSP-methoden maken we nu via LIVE555 gebruik van de DESCRIBEmethode, de SETUP-methode, de PLAY-methode en de TEARDOWN-methode. Deze methoden volstaan om een presentatie af te spelen. Samenvattend kunnen we stellen dat we tot een basisversie gekomen zijn die streaming mogelijk maakt, maar deze versie is nog op enkele punten verbeterbaar. We bespreken deze punten in de volgende paragraaf.
4.3 4.3.1
Verder werk Verbetering video en uitbreiding naar andere bestanden
Het probleem met de groende blokken in het videobeeld moet nog verder onderzocht worden. Als we daar een oplossing voor gevonden hebben, kunnen we andere bestanden beginnen uitproberen. Nu er al enkele bestanden afgespeeld kunnen worden, is het maar een kleine stap naar de uitbreiding voor andere bestanden. Aan de hand van de codecbenaming die we van LIVE555 mee krijgen, kunnen we op zoek gaan naar de juiste codec uit de speler.
4.3.2
Netwerkfouten
Bij de huidige implementatie is het zo dat – als er iets fout gaat – er simpelweg niets afgespeeld wordt. Het zou beter zijn, mocht er bij een fout een foutmelding gegenereerd worden die duidelijk de oorzaak van de fout weergeeft. Daarbij kunnen de statuscodes en foutbeschrijvingen van RTSP, waarvan sprake op pagina 7, nog van nut zijn. Ook de fouten die niet van RTSP afkomstig zijn, dienen nog op elegante manier afgehandeld te worden.
37
4.3.3
Extra functies en uitbreidingsmodules
Wanneer men vooraf opgenomen media wil afspelen, is het in vele gevallen mogelijk om vooruit te spoelen naar een positie in het bestand. Ondersteuning voor deze mogelijkheid ontbreekt echter in de implementatie. In het hoofdstuk over streaming zagen we dat men met de PLAY-methode van RTSP het tijdstip kan aangeven in het bestand waar het afspelen moet starten. Hier zouden we gebruik van kunnen maken. De gebruiker zou dan op de tijdsbalk van de speler een tijdstip kunnen aanklikken, waarop de speler deze positie in de het PLAY-verzoek verwerkt en de streams vervolgens begint af te spelen. Een andere nog onbenutte methode van RTSP waar LIVE555 ondersteuning voor biedt, is de PAUSE-methode. In de huidige implementatie versturen we nog geen PAUSEverzoekbericht wanneer de presentatie gepauzeerd moet worden. In het hoofdstuk over streaming hebben we gezien dat er drie manieren zijn om aan een presentatiebeschrijving te geraken. De manier via de DESCRIBE-methode van RTSP is al voorzien in de implementatie. Een andere manier was via een omschrijvingsbestand. Een dergelijk omschrijvingsbestand bevat dan de volledige presentatiebeschrijving volgens het Session Description Protocol ([7], [8] en [15]). Deze manier van werken heeft als voordeel dat de gebruiker de omschrijvingsbestanden van zijn favoriete presentaties kan bewaren om opnieuw te beluisteren/bekijken en dat hij zich niet moet bekommeren om het opslaan van URL’s. De LIVE555-implementatie luistert ook nog niet naar RTSP-verzoekberichten afkomstig van de server. Bijgevolg wordt dan ook geen gevolg gegeven aan ANNOUNCE-, GET PARAMETER-, SET PARAMETER-, OPTIONS- en REDIRECT-berichten die de server verstuurt. In het geval dat men met een streaming server werkt die deze berichten wel gebruikt, zou een ondersteuning voor deze methoden wel tot een optimaler resultaat kunnen leiden.
4.4
Algemeen besluit
Het doel van de thesis is bereikt. We zijn er in geslaagd een streaming extensie te ontwikkelen voor The Core Pocket Media Player. Helaas kunnen we het nog niet beschouwen als een flexibel, gebruiksvriendelijk product, maar mits enige aanpassingen en uitbreidingen kunnen we er snel naar evolueren. De voornaamste aanpassingen zijn de verruiming van het aantal afspeelbare bestanden en de elegante afhandeling van eventuele fouten. Een 38
invoering van het PAUSE-bericht van RTSP zou ook een enorme verbetering opleveren. Andere suggesties om het gebruiksgemak te verhogen, zijn de toevoeging van een module om presentatiebeschrijvingsbestanden af te spelen en het gebruik van de mogelijkheid om in bepaalde bestanden het afspelen te starten op een zelf gekozen tijdstip in het bestand.
39
Bijlage A Voorbeeld van RTSP-interactie C = Client S = Server waar de presentatiebeschrijving op staat A = Server die de audiostream levert V = Server die de videostream levert Opmerking: S, A en V zouden dezelfde server kunnen zijn. In dat geval zou de waarde CSeq bij elk gegeven verzoek-antwoordpaar verhoogd worden.
C->S: DESCRIBE rtsp://server.example.com/twister RTSP/1.0 CSeq: 1 Accept: application/sdp S->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 40
A->C:
C->V:
V->C:
C->V:
V->C:
C->A:
A->C:
C->A:
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 RTSP/1.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001 SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 RTSP/1.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003 PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00RTSP/1.0 200 OK CSeq: 2 Session: 23456789 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811 PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: 12345678 Range: smpte=0:10:00RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181 TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 41
CSeq: 3 Session: A->C: RTSP/1.0 CSeq: 3 C->V: TEARDOWN CSeq: 3 Session: V->C: RTSP/1.0 CSeq: 3
12345678 200 OK rtsp://video.example.com/twister/video RTSP/1.0 23456789 200 OK
42
Bibliografie [1] Apple. Darwin Streaming Server. http://developer.apple.com/opensource/server/streaming/index.html. [2] D. Austerberry. The technology of video and audio streaming. Focal Press, second edition, October 2004. [3] CoreCodec, Inc. The Core Pocket Media Player. http://tcpmp.corecodec.org/. [4] H. Eriksson and M. Penker. De UML toolkit. Academic Service, 1999. [5] O. Frommel. Darwin streaming server. Linux-Magazine, 6(52):60–62, 2005. [6] Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 1889 (Proposed Standard), January 1996. Obsoleted by RFC 3550. [7] M. Handley and V. Jacobson. SDP: Session Description Protocol. RFC 2327 (Proposed Standard), April 1998. Obsoleted by RFC 4566, updated by RFC 3266. [8] M. Handley, V. Jacobson, and C. Perkins. SDP: Session Description Protocol. RFC 4566 (Proposed Standard), July 2006. [9] IANA. Internet Assigned Numbers Authority (Port number delegation). http://www.iana.org. [10] J. F. Kurose and K. W. Ross. Computernetwerken: Een ‘top-down’-benadering. Pearson Addison Wesley, second edition, 2003. [11] Live Networks, Inc. http://www.live555.com/mediaServer/.
43
LIVE555
Media
Server.
[12] Live Networks, Inc. http://www.live555.com/liveMedia/.
LIVE555
Streaming
Media.
[13] Microsoft. Windows Media Services FAQ. http://www.microsoft.com/windows/windowsmedia/forpros/server/faq.aspx. [14] The MPlayer Project. MPlayer. http://www.mplayerhq.hu. [15] S. Olson, G. Camarillo, and A. B. Roach. Support for IPv6 in Session Description Protocol (SDP). RFC 3266 (Proposed Standard), June 2002. Obsoleted by RFC 4566. [16] PacketVideo Network Solutions. pvServer. http://www.pvnetsolutions.com/products/pvserver.html. [17] RealNetworks, Inc. Helix Server. http://www.realnetworks.com/products/media delivery.html.
[18] RealNetworks, Inc. RealPlayer for Mobile. http://www.realnetworks.com/industries/serviceproviders/mobile/products/pla [19] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 3550 (Standard), July 2003. [20] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol (RTSP). RFC 2326 (Proposed Standard), April 1998. [21] soundscreen. Compressing and Hinting Media for http://www.soundscreen.com/streaming/compress hint.html. [22] VideoLAN. VLC media player. http://videolan.org/vlc/.
44
Streaming.
Lijst van figuren 2.1
Interactie tussen client en server bij een eenvoudige RTSP-sessie . . . . . .
2.2
Headervelden RTP-pakket . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1
Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2
Interactie tussen player.c, rtp win32.c/LIVE555 en de server . . . . . . 28
3.3
De positie van rtp in de implementatie . . . . . . . . . . . . . . . . . . . . 29
3.4
De positie van rtpstream in de implementatie . . . . . . . . . . . . . . . . 30
45
9
Lijst van tabellen 1
Lijst van de gebruikte afkortingen . . . . . . . . . . . . . . . . . . . . . . . viii
2.1
Methoden RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Ondersteunde bestandsformaten en compressiestandaarden voor video van QuickTime/Darwin Streaming Server . . . . . . . . . . . . . . . . . . . . . 17
3.2
Ondersteunde bestandsformaten en compressiestandaarden voor audio van QuickTime/Darwin Streaming Server . . . . . . . . . . . . . . . . . . . . . 18
3.3
Ondersteunde bestandsformaten en compressiestandaarden van RealPlayer for Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4
Systeemeigenschappen Pocket PC . . . . . . . . . . . . . . . . . . . . . . . 31
3.5
Systeemeigenschappen servercomputer . . . . . . . . . . . . . . . . . . . . 31
46
8
