Ontwerp van een digitale meerkanaalssatellietontvanger in software

Transcriptie

1 Ontwerp van een digitale meerkanaalssatellietontvanger in software Ben Backx Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: dr. ir. Michiel Ronsse, Jonas Maebe Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar

2

3 Ontwerp van een digitale meerkanaalssatellietontvanger in software Ben Backx Promotor: prof. dr. ir. Koen De Bosschere Begeleiders: dr. ir. Michiel Ronsse, Jonas Maebe Scriptie ingediend tot het behalen van de academische graad van Burgerlijk ingenieur in de computerwetenschappen Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar

4 i Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren 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 dit afstudeerwerk. Ben Backx 29 mei 2008

5 ii Dankwoord Deze scriptie zou er niet zijn zonder de hulp van heel wat mensen, het is dus niet meer dan normaal deze hier te bedanken. In de eerste plaats zijn er mijn promotor, prof. dr. ir. Koen De Bosschere, en mijn begeleider, dr. ir. Michiel Ronsse. Zonder hen was het in de eerste plaats al een stuk moeilijker geweest om een eigen onderwerp voor te dragen. Verder werd mij de vrijheid gegeven om met mijn scriptie de richting uit te gaan die ik voor ogen had en hun deuren stonden altijd open indien ik vragen of problemen had. Ten tweede hebben we Marco Nardoni en Christian Dolzer, respectievelijk managing director en software developer bij Digital Everywhere. Ook zij hebben mij de nodige ondersteuning gegeven in de vorm van het ter beschikking stellen van de nodige hardware, het vrijgeven van technische specificaties en de nodige hulp bij vragen over onduidelijkheden in die technische specificaties. Andreas Monitzer kan en mag ook niet vergeten worden. Het is hij die in 2004 begonnen is aan de Linux-driver. Zonder zijn eerdere werk was het onmogelijk geweest om alleen binnen een aanvaardbare tijd een volledige driver te schrijven. Tegelijk vermeld ik hier ook de mensen die actief zijn op de verschillende mailinglists en die mij ook de nodige hints en tips hebben gegeven. Een speciale vermelding gaat naar Stefan Richter, code-maintainer binnen het linux1394-project die mij goed vooruit geholpen heeft met mijn problemen met de firewire-api. Ook mijn ouders hebben hun plaatsje in dit dankwoord meer dan verdiend. Bedankt voor jullie liefde, steun, vertrouwen en hulp die ik heb gekregen om in alle vrijheid te groeien. Ook mijn broer, zus en grootouders ben ik dankbaar voor al de hulp en interesse. Tot slot zijn er ook nog al mijn vrienden dankzij wie de 6 jaar universiteit heel wat aangenamer was. Ze stonden altijd klaar om te helpen waar het kon. Een speciale vermelding voor Michiel, die me goed op weg heeft geholpen met de Linux-modules, en Jens en PJ, die altijd probeerden te helpen als L A TEXweer eens niet deed wat het moest doen, is hier uiteraard ook op zijn plaats.

6 iii Ontwerp van een digitale meerkanaalssatellietontvanger in software door Ben Backx Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen Academiejaar Promotor: Prof. Dr. Ir. Koen De Bosschere Scriptiebegeleiders: Dr. Ir. Michiel Ronsse, Jonas Maebe Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. Jan Van Campenhout Samenvatting De DVB-standaard voor digitale TV maakt gebruik van transport streams om meerdere kanalen via één frequentie te verzenden. In deze scriptie wordt bestudeerd welke filtermethoden bestaan om meerdere TV-kanalen simultaan uit een transport stream te filteren. Er wordt gekeken naar filtering op drie verschillende niveau s: op hardware-, driver- en applicatieniveau. Om de verschillende filtermethodes met elkaar te kunnen vergelijken, wordt zowel CPU-belasting als latentie getest. De hardware die gebruikt wordt voor deze testen bestaat uit een DVB-ontvanger voor digitale satelliettelevisie die via firewire op een Linux-PC wordt aangesloten. Trefwoorden DVB, Meerkanaalssatelietontvanger, PID-filtering, CPU-belasting, Latentie

7 Designing a multi-channel DVB-receiver in software Ben Backx Supervisor(s): prof. dr. ir. Koen De Bosschere, dr. ir. Michiel Ronsse Abstract The DVB-standard describes a method to send multiple channels in one transport stream. This article describes how to implement and test different ways of filtering multiple channels simultaneously from such a transport stream. The focus lays with three different levels: hardware-, driver- and software-level. CPU-load and latency of the different filtermethods is measured and analysed to determine if there is a preferred method. Keywords DVB, Multi-channel receiver, PID-filtering, CPU-load, Latency I. INTRODUCTION DIGITAL TV is becoming more and more important. VRT, the Flemish public broadcasting company, announced it will stop broadcasting analogue terrestrial signals by the end of 2008 and switch to DVB-T. Telenet, the major Flemish cable company, will stop with analogue broadcasting by the end of 2011 and is already using a modified version of the DVB-C standard for digital broadcasting. The change to digital TV brings lots of benefits: less bandwith is needed (1 analogue TV-channel takes as much bandwith as 8 digital TV-channels), sharp images, superb audio quality and so on. The major drawback is the purchase of a set-top box or digital receiver for each television set. The cheaper models don t profit from many of the benefits digital TV has to offer. Using a centralised server-system, one can profit from all the benefits digital TV has to offer (time-shifting, simultaneous recording using one tuner, and so on) at the price of a cheap set-top box (only the server-system has a higher start-up cost). This central server-system broadcasts television over your home network, so even a standard PC can become a multimedia machine. One of the questions one might ask: if we are using a server, what is the most efficient way to filter the requested TV-channels from the complete transport stream? Some more advanced hardware is able to filter, perhaps the device driver should do it or maybe the end-user application? In what follows, we will examine those three approaches and base our conclusions on CPUload and latency. II. DVB AND MPEG-2 To have a good understanding of the results, you have to understand both DVB and MPEG-2. In this section, we will explain the most important properties of those standards. A. DVB DVB, or digital video broadcasting, is Europeans most used standard for digital TV. It s available in three different flavors, depending on the medium: DVB-S for satellite broadcasting, DVB-C for broadcasting using the (coax) cable and DVB-T for terrestrial broadcasting. The results gathered in this article, where collected from DVB-S broadcasts. The bandwith that is used for one analogue TV-channel, is now used to transmit one transport stream. Such a transport stream can contain up to 8 TV-channels. Every channel is build from different elementary streams (separate streams for eg. audio and video), each with a unique program identifier (PID). PID-filtering does exactly what it says: filter the elementary streams with the requested PID s so the receiver can watch one TV-channel from the transport stream. B. MPEG-2 The main characteristic of MPEG-2 is the usage of I, P en B frames (Intra, Predictive and Bi-directional coded frames). I- frames are coded as JPEG-images. P-frames are coded as the difference between the frame and the previous I- or P-frame. B- frames are coded as the difference between the frame and the interpolation off the previous and next I- or P-frames. If you want to start decoding an MPEG-2 stream, you have to wait untill an I-frame comes by. DVB is using MPEG-2, so it s to be expected that this will have a major influence on the latency. III. TESTPLATFORM The tests where executed on a Linux-PC (Ubuntu 7.10) with a FireDTV S/CI receiver from Digital Everywhere. Linux was choosen because of the open character. The driver had to be modified, which resulted in a thorough knowledge of the driver and the API s that were used. This resulted in a driver that was modified to our specific needs. The benchmarks were executed by a custom-build application based on the combination of dvbstream and ts filter. It was able to request the complete transport stream or a filtered version from the FireDTV receiver and filter the requested PID s from the stream. A. CPU-load IV. RESULTS The CPU-load was determined by running the custom-build application for a half an hour. During that run, every 2 seconds the CPU-load caused by the application was measured and written to a file. Afterwards, the average was calculated. The results are shown in figure 1. A.1 Filtering on hardware level The results are as expected: the CPU-load rises as more and more elementary streams are being filtered. This makes sense, because the hardware filters the requested streams, but puts them

8 ary streams Number of filtered elementa CPU load based on number of filtered elementary streams CPU load (%) Fig. 1. CPU-load based on number of filtered elementary streams Application Hardware back in a smaller transport stream to get them from the DVBreceiver to the PC. Software still has to filter the streams from this smaller transport stream, hence the rising CPU-load. The jumps that occur from an even to an odd number of filtered streams, are caused by the nature of the filtered streams. The first stream is a video stream, the second an audio stream, the third is again a video stream and so on. A video stream contains much more data and causes more filtering and thus more CPU-load than an audio stream. A.2 Filtering on application level The rising CPU-load is also noticed when the application has to filter from the complete transport stream. However, sometimes adding an extra audio stream causes the CPU-load to be lower. This is explained by the live TV that was used during the tests. Video can contain lots of moving images and cause a lot more data-traffic or it can contain still images and cause less data-traffic and filtering. If the tests with only video are conducted during a busy period, the CPU-load can be higher than when we are filtering both video and audio during a calm period. Filtering on the application level also has to check every packet to see if it contains a packet that needs to be filtered, that s why the CPU-load is higher in the beginning and not rising as rapidly as was the case with hardware filtering. The only extra CPU-load is caused by the application that writes an extra stream to a file. Finally, we notice that filtering on hardware level is catching up to filtering on application level. This is explained by the nature of hardware filtering. Even when using hardware filtering, the software has to do more and more filtering when adding more and more elementary streams to filter. A.3 Filtering on driver level Filtering on driver level has not been tested. There are three main reasons why this wasn t tested: Use: The use of this method of filtering is questioned. Filtering on this level is as much software-based filtering as filtering on the application level is. Practicality: It is almost impossible to have accurate results, because it is not possible to determine the CPU-load caused by a specific driver. It was hard enough to have accurate results when filtering on application level, where we were able to determine the CPU-load caused only by our test application. Overhead: Filtering on driver level would mean: receiving the complete transport stream, filter the requested packets and put them back in a smaller transport stream to send to the application. This causes a huge overhead. When sending the filtered streams individually to the application, timing problems may occur (audio and video must remain synchronised). Again, unneeded overhead will be necessary to prevent this. B. Latency Latency can be caused in the satellite dish (when polarity needs to be changed), in the tuner (when changing frequencies), in the frontend, in the demultiplexer, in the driver and in the application. The satellite dish, tuner and frontend are causing a latency of about 1.4 seconds (determined from timestamps in the driver-logs). The latency in the demultiplexer is about a half a second for each PID that has to be filterd (setup time, also measured by timestamps in the driver-logs). It was not possible to determine the latency caused by the driver, but since all the driver has to do is translate commands from application- to hardware-commands and the other way around, it s safe to say that this latency will be negligible. Finally, we have the application. Main cause of latency will be the use of MPEG-2 streams and the time to wait for an I-frame. Averages are about 1.5 seconds on an older system (5 years old) and less than a second on more recent PC s. V. CONCLUSIONS The CPU-load that is caused by PID-filtering, is relatively small (about 6% when using software to filter 16 PID s). This will not influence the user experience. The end-user will always notice latency. From our tests, it s measured that changing to a TV-channel that is in the same transport stream as the current one, takes about 1 to 1.5 seconds when software-filtering is used. When using hardware-filtering, this becomes 3 to 3.5 seconds. Changing between channels in different transport streams can take up to 6 seconds. When latency is important, softwarefiltering is the way to go. CPU-load is so low, it will never be of any influence on modern PC s.

9 INHOUDSOPGAVE vi Inhoudsopgave Dankwoord Overzicht Extended abstract Inhoudstafel Afkortingen ii iii iv vi viii 1 Inleiding Meerdere TV-kanalen uit één DVB-stroom Ontwerpen van een meerkanaalsontvanger Aanpak State of the Art Domme DVB-ontvangers Slimme DVB-ontvangers Op Linux gebaseerde DVB-ontvangers Media Center Software De DVB-standaard Inleiding DVB-zender Voorbeeld DVB-ontvanger

10 INHOUDSOPGAVE vii 2.4 DVB-S DVB-S Latentie MPEG Verklaring latentie Meerkanaalsontvanger Praktische toepassingen Thuisgebruik Professioneel gebruik Filtering door de applicatie op driverniveau in hardware Samenvatting Testplatform Digital Everywhere PC Firewire Linux Driver Firewire-API DVB-API Applicaties Werking Testapplicatie Realisaties Driver-ontwikkeling DVB-S DVB-S

11 INHOUDSOPGAVE viii 5.2 Prestatietesten Driver Hardware Applicatie Besluit Latentietesten Latentie veroorzaakt door de schotelantenne Latentie in de ontvanger Latentie in de software Besluit Besluit Driver Prestatietesten Latentietesten Tot slot A Structuur configuratiebestand 55 Bibliografie 57 Lijst van figuren 58 Lijst van tabellen 60

12 INHOUDSOPGAVE ix Afkortingen DVB DVB-C DVB-H DVB-S DVB-T EIRP EPG FEC GOP HD HTPC JPEG MPEG PAT PES PID Digital Video Broadcasting DVB-Cable DVB-Handheld DVB-Satellite DVB-Terrestrial Equivalent isotropically radiated power Elektronische Programmagids Forward error correction Group Of Pictures High Definition Home Theatre PC Joint Photographic Experts Group Moving Picture Experts Group Program Association Table Packetized Elementary Stream Packet IDentifier

13 INHOUDSOPGAVE x PMT PSK QAM QPSK SD TDM TS Program Map Table Phase-shift keying Quadrature Amplitude Modulation Quadrature phase-shift keying Standard Definition Time Division Multiplexing Transport Stream

14 INLEIDING 1 Hoofdstuk 1 Inleiding Digitale TV is niet meer uit onze wereld weg te denken. Kijk maar naar de recente aankondiging van de VRT om op 3 november 2008 te stoppen met de analoge uitzendingen via de ether[3]. Vanaf dan zal je in de ether enkel nog een digitaal TV-signaal terug vinden. Ook Telenet wil einde 2010 of 2011 stoppen met zijn analoge uitzendingen. Of de betere kwaliteit de voornaamste beweegreden is, is maar de vraag. Door de overstap naar digitale TV komt heel wat bandbreedte vrij voor extra (betaal)diensten en moet de eindgebruiker per TV een set-top box aanschaffen. Daarmee hebben we ook onmiddelijk het zwakste punt van digitale TV aangeraakt. Wil je er van genieten, dan moet je zo n set-top box of digitale ontvanger kopen. Sommige duurdere TVtoestellen hebben een digitale ontvanger ingebouwd, maar deze is vaak niet bruikbaar. Je moet op de goodwill van je provider vertrouwen, want bijvoorbeeld Telenet houdt zich niet helemaal aan de DVB-standaard waardoor het onmogelijk is om zelf je hardware te kiezen: enkel de hardware die Telenet verkoopt, zal bij hun werken. Ook bij BelgacomTV is dit het geval. Gelukkig zijn er nog providers die zich wel aan de DVB-standaard houden. DVB is de Europese standaard voor digitale TV-uitzendingen die uitgebreid aan bod komt in hoofdstuk 2. Bij de providers die de DVB-standaard volgen, ben je vrij in de keuze van je hardware. Alle beschikbare ontvangers die zich aan de DVB-standaard houden, zullen ook werken. Hierdoor kan je ook het volledige aanbod aan DVB-ontvangers voor de PC gebruiken, waardoor je in staat bent om een zeer flexibel systeem op te stellen. Meer geavanceerde DVB-ontvangers bieden extra functionaliteit zoals time-shifting (een live uitzending pauzeren en later verder kijken) en opname-mogelijkheden. Als je je eigen Media Center installeert (dit is een PC met DVBontvanger en speciale software zodat alle functionaliteit eenvoudig is te bedienen, ook wel HTPC of home theatre PC genoemd), krijg je nog veel meer mogelijkheden. Niet alleen time-shiften

15 1.1 Meerdere TV-kanalen uit één DVB-stroom 2 en opnemen is mogelijk, je kan je opnames ook wegschrijven naar een DVD, vakantiefilmpjes en -foto s die op een andere PC in je thuisnetwerk staan bekijken, muziek beluisteren en ga zo maar verder. Het grote nadeel van digitale TV is dat je per TV een ontvanger moet aanschaffen. Ook hier kan de PC een goedkopere oplossing aanbieden. Een centraal systeem kan al de belangrijke functionaliteit op zich nemen en digitale TV via je thuisnetwerk beschikbaar stellen. Een veel goedkopere thin client die met je TV-toestel is verbonden zorgt dan dat je overal waar je thuisnetwerk beschikbaar is, je ook over alle functionaliteit van een volwaardig media center kan beschikken zonder hiervoor de prijs te betalen. Met die flexibele, centrale PC zijn we ook aangekomen bij de probleemstelling van deze scriptie. 1.1 Meerdere TV-kanalen uit één DVB-stroom Bestaande hardware is, meestal, maar in staat om één TV-kanaal ter beschikking te stellen. Dit ene kanaal wordt gefilterd uit een stroom die veel meer TV-kanalen bevat (zie hiervoor ook hoofdstuk 2). Meer flexibele hardware stelt ons in staat om meerdere TV-kanalen uit zo n stroom te filteren. Deze hardware bestaat, bijvoorbeeld de Arion AF-9280PVR of de DREAMBOX DM800 HD PVR, maar ook deze is meestal beperkt tot het filteren van twee TVkanalen tegelijk (meer hierover in deel 1.4). Bovendien bieden deze enkel de TV-functionaliteit en niet de vele extra mogelijkheden die een PC ons biedt: meer TV-kanalen tegelijk filteren, vakantiefoto s en filmpjes op je tv bekijken enzoverder. Een centrale PC blijft dus heel wat voordelen bieden. De vraag, en probleemstelling van deze scriptie, wordt dan: hoe filteren we optimaal meerdere TV-kanalen tegelijk uit één stroom? Doen we dit volledig op applicatieniveau? Kan de hardware dit? Of moeten we de device driver van de DVB-ontvanger het vuile werk laten opknappen? Ter verduidelijking is figuur 1.1 toegevoegd. Hierop is de huidige situatie weergegeven (figuur 1.1(a)) waarbij verschillende kanalen in de DVB-stroom worden geplaatst (dit gebeurt bij de netwerkbeheerders, bijvoorbeeld Telenet en TV-Vlaanderen). Bij de eindgebruiker (de TVkijker) wordt hier dan één kanaal uit gefilterd. De uiteindelijke doelstelling wordt getoond op figuur 1.1(b). Hier worden alle TV-kanalen uit de DVB-stroom gefilterd zodat de eindgebruiker

16 1.2 Ontwerpen van een meerkanaalsontvanger 3 DVB-stroom DVB-stroom (a) Huidige situatie DVB-stroom DVB-stroom (b) Doelstelling Figuur 1.1: Verduidelijking van huidige situatie en de doelstelling naar een TV-kanaal kan kijken terwijl een ander wordt opgenomen. Ook kan in dit geval één tuner voldoende zijn om twee verschillende TV-toestellen te voorzien van (verschillende) TVkanalen. 1.2 Ontwerpen van een meerkanaalsontvanger Nu we weten wat de probleemstelling is, kunnen we ook een doelstelling vastleggen: het ontwerpen van een meerkanaalsontvanger en het zoeken naar een optimale filtermethode. De filtering kan op twee plaatsen gebeuren: in hardware (DVB-ontvanger) of in software (driver of applicatie). Het verschil tussen deze 2 manieren van filteren zie je op figuur 1.2. Figuur 1.2(a) toont hoe softwarefiltering in zijn werk gaat: de volledige DVB-stroom wordt door de DVB-ontvanger doorgegeven naar de PC, zonder deze te wijzigen. De software (driver of applicatie) zal deze vervolgens zelf moeten filteren. Op figuur 1.2(b) is de hardwarefiltering weergegeven. Hierbij gaat de DVB-ontvanger de filtering uitvoeren. Om verschillende kanalen via één medium van de DVB-ontvanger naar de PC te verzenden, zullen de gefilterde kanalen opnieuw in een DVB-stroom geplaatst worden. De software zal dus nog steeds moeten filteren, maar dit keer uit een veel kleinere DVB-stroom. De vraag is dus of deze extra filtering in de hardware veel prestatiewinst zal opleveren en

17 DVB-stroom DVB-stroom 1.3 DVB-zender Aanpak DVB-ontvanger Software4 DVB-stroom DVB-stroom DVB-zender DVB-ontvanger (a) Softwarefiltering Software DVB-stroom DVB-stroom DVB-zender DVB-ontvanger (b) Hardwarefiltering Software Figuur 1.2: Verschil tussen hard- en softwarefiltering DVB-stroom DVB-stroom hoe deze de latentie beïnvloedt. DVB-zender 1.3 Aanpak DVB-ontvanger Software Als besturingssysteem werd gekozen voor Linux. Het open karakter biedt heel wat extra mogelijkheden en flexibiliteit waardoor programma s kunnen worden aangepast aan de eigen vereisten. De DVB-ontvanger werd geleverd door Digital Everywhere. Op verschillende internetfora had dit bedrijf te kennen gegeven dat ze de ontwikkeling van een Linux-driver zo goed mogelijk willen ondersteunen. In 2004 was reeds begonnen aan een driver, maar deze was onder het stof beland. De eerste stap was dus de oude driver weer aan de praat krijgen, want de ontwikkelingen binnen de Linux-wereld staan niet stil. De gebruikte API s kregen updates en nieuwe of aangepaste functies. Omdat het de bedoeling is om deze driver ook nog na deze scriptie verder door te ontwikkelen, werd gekozen voor het updaten van de code en niet voor het gebruiken van verouderde API s en Linux-kernels. Op deze manier draagt deze scriptie ook een steentje bij aan het grote Linux-project door het ondersteunen van extra randapparatuur.

18 1.4 State of the Art State of the Art DVB-ontvangers zijn beschikbaar in alle mogelijke vormen en maten. In wat volgt worden deze opgedeeld in drie grote groepen: domme, slimme en op linux gebaseerde DVB-ontvangers. Omdat de tests in deze scriptie werden uitgevoerd met een DVB-ontvanger voor satelliet-tv, wordt ook hier enkel gekeken naar satellietontvangers 1. Waar in de rest van deze scriptie de DVB-ontvanger de set-top box van Digital Everywhere is die via firewire op de PC wordt aangesloten, is in wat volgt de DVB-ontvanger een set-top box die rechtstreeks op een TV kan worden aangesloten Domme DVB-ontvangers Domme DVB-ontvangers zijn DVB-ontvangers die slechts één TV-kanaal aanbieden. De volledige DVB-stroom komt via een coax-kabel van de antenne naar de ontvanger. De ontvanger filtert de PID s die bij één TV-kanaal horen uit deze DVB-stroom. Eventueel wordt deze nog gedecodeerd (in geval van betaaltelevisie met encryptie) om dan uiteindelijk op het TV-toestel afgespeeld te worden. De functionaliteit van deze ontvangers is beperkt (waardoor de prijs dat meestal ook is). Extra s beperken zich tot een elektronische programmagids die via het DVB-signaal wordt meegestuurd. Ieder merk dat DVB-ontvangers produceert, heeft deze wel in zijn gamma. Enkele voorbeelden zijn Arion, Inverto, Lemon en Philips (bijvoorbeeld: Philips DSR2211 in figuur 1.3). Het belangrijkste voordeel van deze klasse ontvangers is de prijs. Voor de prijs van een low-power PC die je bij het systeem met een centrale media-server nog steeds nodig hebt, kan je een eenvoudige DVB-ontvanger kopen. Dit is dan ook het enige voordeel. De ontvanger kan één TV-kanaal weergeven en daar stopt het mee. Geen opnamemogelijkheden, geen time-shifting en al helemaal geen interactie met de rest van je netwerk. Wil je iets opnemen, dan zal je nog altijd een extra (extern) toestel moeten kopen waardoor de prijs natuurlijk ook omhoog gaat. 1 Voor ontvangers die kabel (DVB-C) en ether (DVB-T) ondersteunen, gelden echter dezelfde indeling, dezelfde opmerkingen en dezelfde voor- en nadelen

19 1.4 State of the Art 6 Figuur 1.3: Philips DSR2211 DVB-S ontvanger Slimme DVB-ontvangers De slimme DVB-ontvangers bieden al wat meer functionaliteit. Opnemen en time-shifting is bij deze toestellen mogelijk. Sommige ondersteunen ook meerdere TV-kanalen waardoor je (bijvoorbeeld) naar Zo is er maar één op één kan kijken terwijl een film op 2BE wordt opgenomen. Uiteraard ondersteunen deze ook de elektronische programmagids die via het DVBsignaal wordt meegestuurd. Ook dit soort ontvangers zit in het gamma van de meeste fabrikanten van DVB-ontvangers. Figuur 1.4 toont bijvoorbeeld de Inverto IDL7000PVR DVB-S ontvanger. Figuur 1.4: Inverto IDL7000PVR DVB-S ontvanger Ook deze ontvangers zijn nog goedkoper dan een volledig media-systeem met centrale server en low-power PC s bij het TV-toestel. Ze missen echter nog altijd de interactie met het netwerk en hun functionaliteit is beperkt tot het opnemen en bekijken van TV-programma s. Ze zijn niet in staat om multimedia-content die op andere PC s in je thuisnetwerk staat, af te spelen. De

20 1.4 State of the Art 7 minder veeleisende gebruiker zal echter meer dan voldoende hebben aan dit soort ontvangers Op Linux gebaseerde DVB-ontvangers Een aparte klasse van DVB-ontvangers, is deze met een op Linux gebaseerd besturingssysteem. Het meest bekende voorbeeld van dit soort DVB-ontvangers, is de Dreambox-serie (figuur 1.5 toont de Dreambox DM800 HD PVR), geproduceerd door het Duitse Dream Multimedia. Omdat deze toestellen op Linux gebaseerd zijn, is er een hele community rond ontstaan die aangepaste firmware voor deze toestellen ter beschikking stelt. Hierdoor worden de mogelijkheden natuurlijk onmiddelijk een stuk groter en zijn deze enkel beperkt door de beperkte CPU-kracht en het beperkte RAM-geheugen van deze toestellen. Figuur 1.5: Dreambox DM800 HD PVR DVB-S ontvanger Dankzij de grote mate van aanpasbaarheid van deze toestellen, zijn heel wat nadelen verdwenen. Het voornaamste nadeel blijft echter het niet kunnen streamen van (live) TV-beelden naar je netwerk. Je kan de ontvanger wel aansluiten op je netwerk en filmpjes en foto s vanop een andere pc bekijken, maar je kan niet vanop een PC via de ontvanger TV kijken. Een groot voordeel die de oplossing met een centrale media-server wel biedt Media Center Software Als de keuze gemaakt is om een systeem met een centrale media-server op te zetten, heb je natuurlijk nog steeds de software nodig. Het meest bekende voorbeeld is de Media Center software van Microsoft (figuur 1.6 toont een screenshot van deze software). Deze software is zeer gebruiksvriendelijk, makkelijk in te stellen maar mist de flexibiliteit, vooral omdat het geen open-source project is.

21 1.4 State of the Art 8 Figuur 1.6: Windows Vista Media Center MythTV is de bekendste Media Center software voor Linux (figuur 1.7 toont het beginscherm van deze software). Even eenvoudig in gebruik, wat moeilijker in te stellen, maar veel flexibeler omdat het open source is. Hierdoor kan iedereen de code bekijken en verbeteringen en uitbreidingen schrijven. Bovendien is deze software van in het begin ontwikkeld vanuit het client-server principe. Je hebt dus één (of meerdere) servers waarop de DVB-ontvangers worden aangesloten, die verantwoordelijk zijn voor opnames, waarop foto s en filmpjes kunnen worden opgeslagen en zo voort. Deze server(s) is (zijn) verbonden met je thuisnetwerk. Ook de clients zijn verbonden met dit thuisnetwerk. Een client kan alle vormen aannemen: het kan een low-power PC zijn, die ervoor zorgt dat een TV-toestel beschikt over alle functionaliteit, of een gewone PC. Iedere PC binnen je thuisnetwerk kan genieten van live TV en alle andere content die via de centrale server(s) beschikbaar is.

22 1.4 State of the Art 9 Figuur 1.7: MythTV voor Linux

23 DE DVB-STANDAARD 10 Hoofdstuk 2 De DVB-standaard 2.1 Inleiding DVB, of voluit Digital Video Broadcasting, is een internationaal aanvaarde standaard die in Europa (en heel wat andere werelddelen) de belangrijkste standaard voor digitale televisie is. Door gebruik te maken van MPEG-2 compressie kan men via digitale TV meer TV-kanalen uitzenden (typisch 8) met dezelfde bandbreedte van één analoog TV-kanaal. Behalve deze besparing in bandbreedte, zijn er natuurlijk nog voordelen. Het beeld is altijd ruisvrij en het geluid is kwalitatief gelijk aan dat van een cd. Ook kan men extra informatie, zoals bijvoorbeeld een EPG (Elektronische programmagids), aan het signaal toevoegen. Tot slot kan men de signalen ook eenvoudig versleutelen om zo meer mogelijkheden te creëren voor betaal-tv (u mag zelf kiezen of dit een voor- of een nadeel is). Jammer genoeg is het niet allemaal rozengeur en maneschijn. Het grootste nadeel voor de eindgebruiker is reeds in de inleiding vermeld: de aanschaf van een set-top box (decoder). Bovendien heeft men per tv-toestel zo n decoder nodig. Ondertussen verschijnen er meer en meer tv-toestellen met ingebouwde decoders. Deze voldoen (logischerwijs) aan de DVB-standaard die niet altijd door de providers gevolgd wordt, waardoor deze helaas onbruikbaar wordt. Een ander nadeel is het alles-of-niets karakter van digitale tv: is het signaal te sterk verzwakt of is er teveel ruis aanwezig, dan verschijnen er blokken (artefacten) of lijnen in het beeld (of het beeld kan ook gewoon helemaal weg zijn). Dit is vaak storender dan analoge ruis (u kan zelf vergelijken

24 2.1 Inleiding 11 (a) Analoge ruis (b) Digitale ruis Figuur 2.1: Vergelijking tussen analoge ruis en artefacten (digitale ruist ) door figuur 2.1(a) met analoge ruis te vergelijken met figuur 2.1(b) die artefacten bevat). Op basis van het medium dat gebruikt wordt om de signalen te verzenden, maakt men onderscheid tussen 4 DVB-vormen: DVB-C zendt uit via de kabeldistributie. In Vlaanderen gebruiken Telenet en indi (een aangepaste vorm van) deze standaard. DVB-T maakt gebruik van de ether om de signalen uit te zenden. In België zenden momenteel enkel de openbare omroepen uit via DVB-T. De Belgische KPN-dochter Tele2 is aan het onderzoeken of commerciële uitzendingen via DVB-T haalbaar zijn in België. DVB-S zendt uit via satelliet. TV-Vlaanderen doet dit ondertussen 2 jaar in Vlaanderen en binnenkort waarschijnlijk ook in Wallonië. DVB-S2 is de opvolger van DVB-S en is ontwikkeld om uitzendingen in HD-kwaliteit mogelijk te maken, onder andere door de MPEG-4 codec toe te voegen aan de bruikbare codecs (de MPEG-2 codec blijft nog steeds bruikbaar). DVB-SH kan gezien worden als een combinatie van DVB-S en DVB-H: waar mogelijk, wordt DVB-S gebruikt. In gebieden waar geen DVB-S signaal beschikbaar is, wordt overgestapt op een signaal via de ether dat echter hogere frequenties gebruikt dan DVB-H (en DVB-T).

25 2.2 DVB-zender 12 Transmissiemedium (kabel, satelliet, ) Transportstroom 1 Transportstroom 2 Transportstroom 3 Kanaal 1.1 Kanaal 1.n Kanaal 2.1 Kanaal 2.2 Kanaal 2.3 Bouquet Video Audio 1 Audio 2 Data Figuur 2.2: Van elementaire datastromen tot transmissiemedium DVB-H is de meest recente toevoeging aan de DVB-standaard en is bedoeld voor het uitzenden naar draagbare toestellen zoals PDA en GSM. Het IBBT 1 heeft, in Gent, een DVB-H proefopstelling staan en is hierdoor koploper in Europa. 2.2 DVB-zender Op figuur 2.2 is een overzicht gegeven van wat er aan de zenderkant van een DVB-netwerk gebeurt. De content-providers (bijvoorbeeld VRT en VMMa) leveren de data aan (we gaan er vanuit dat dit digitaal gebeurt, indien dit niet het geval is, moet er nog een analoog-naardigitaal omzetting gebeuren). Deze data bestaat uit elementary streams: video, geluid (meestal één taal, maar het is mogelijk om meerdere talen of bijvoorbeeld extra commentaar toe te voegen 1 Interdisciplinair instituut voor BreedBand Technologie,

26 2.2 DVB-zender 13 Figuur 2.3: Multiplexen tot één transport stream in een tweede audio stream) en mogelijks extra data (ondertiteling, interactieve toepassing,...). Iedere elementary stream heeft een uniek PID (Packet IDentifier) en de PID s die bij een kanaal horen (bijvoorbeeld één, 2BE,...) worden opgeslagen in een program map table (PMT). Een elementary stream heeft een bandbreedte die varieert van 1 Mbps voor bijvoorbeeld geluid tot 5 Mbps voor bijvoorbeeld beeld in standaard kwaliteit (voor HD-beelden zal dit eerder rond de 20 Mbps draaien). Ook de PMT s krijgen een uniek PID, dat wordt opgeslagen in de program association table (PAT) zodat de ontvanger kan bepalen welke elementary streams samen een kanaal vormen. De elementary streams worden, samen met de PAT, gemultiplexed tot een transport stream (TS). Figuur 2.3 toont in meer detail hoe zo n transport stream tot stand komt. Iedere elementary stream wordt opgedeeld in pakketten (packetized elementary stream of PES) die niet noodzakelijk dezelfde lengte hebben. De transport stream heeft echter wel een vaste pakket-lengte. Het kan dus zijn dat één PES-pakket wordt verdeeld over verschillende TS-pakketten. Het kan ook zijn dat een bepaalde stroom gedurende een periode geen data bevat. Als dit het geval is, worden lege pakketten in de transport stream gezet. Het multiplexen zelf is Time Division Multiplexing (TDM): iedere stream krijgt één of meerdere tijdsloten per PES-pakket (afhankelijk van de lengte). Een transport stream bevat typisch 8 kanalen (dus ongeveer 20 elementary streams) goed voor een totale bandbreedte van 40 á 50 Mbps (per transport stream). Tot slot wordt, door gebruik te maken van bekende modulatieschema s zoals QPSK en QAM, de transport stream op het analoog transmissiemedium gemoduleerd. Voor de volledigheid zie je op figuur 2.2 ook nog de mogelijkheid om een bouquet samen te stellen: verschillende kanalen, vaak met een gelijkaardig thema, die niet noodzakelijk in dezelfde transport stream zitten. Deze bouquets worden, vaak voor een meerprijs, door de netwerkproviders (Telenet, TV-Vlaanderen,...) aangeboden aan de klanten.

27 2.2 DVB-zender Voorbeeld Om één en ander te verduidelijken, wordt hier een voorbeeld gegeven van hoe elementary streams, PID, PAT en PMT met elkaar verbonden zijn. Tabel 2.1 toont een overzicht van de verschillende elementary streams en hun PID die zich in de transport stream bevinden. Tabel 2.1: Overzicht van elementary streams en hun PID Elementary stream (PID 0) Elementary stream (PID 100) Elementary stream (PID 101) Elementary stream (PID 102) Elementary stream (PID 103) Elementary stream (PID 104) Elementary stream (PID 106) Elementary stream (PID 200) Elementary stream (PID 201) Per definitie wijst PID 0 naar de program association table, die gegeven is in tabel 2.2. Deze bevat gegevens over de services (in dit geval zijn dit TV-kanalen) en welk PID de program map table heeft die bij deze services hoort. Tabel 2.2: PAT-tabel Service PMT-PID Tabellen 2.3 en 2.4 tonen de program map tables van deze twee services. Hieruit kunnen we bepalen dat de video van service 1 te vinden is in de elementary stream met PID 100, het geluid is te vinden in de elementary stream met PID 102 en extra data (meestal teletekst) is te vinden onder PID 106. Analoog vinden we dat de video van service 2 PID 101 heeft, het geluid heeft PID 103 en de extra data heeft PID 104. Dankzij deze program association en program map tabellen zal de DVB-ontvanger in staat zijn te achterhalen welke PID s bij welk TV-kanaal horen.

28 2.3 DVB-ontvanger 15 Tabel 2.3: PMT-tabel Service 1 Tabel 2.4: PMT-tabel Service 2 PID Stream type 100 Video 102 Audio 106 Data PID Stream type 101 Video 103 Audio 104 Data 2.3 DVB-ontvanger De belangrijkste functie van de ontvanger zie je op figuur 2.4: het demultiplexen. Allereerst zal een tuner worden ingesteld op een bepaalde frequentie. Het signaal dat hierdoor ontvangen wordt, wordt gedemoduleerd en vormt de volledige transport stream. Uit deze transport stream worden de elementary streams met PID s die bij een kanaal horen gefilterd. Dankzij de program association table met PID 0 en bijhorende program map tables (waarnaar vanuit de program association table wordt verwezen) is de DVB-ontvanger in staat te bepalen welke PID s dit zijn. Zie hiervoor ook het voorbeeld hierboven (paragraaf 2.2.1). Eens de elementary streams uit de transport stream gefilterd zijn, worden ze samengevoegd om zo het gewenste TV-kanaal te vormen. De filtering gebeurt vooral in hardware en is meestal beperkt tot één TV-kanaal tegelijk. Het onderwerp van deze thesis is het onderzoeken hoe we meerdere kanalen tegelijk kunnen demultiplexen (zoals het voorbeeld op figuur 2.5) en dit op 3 verschillende niveau s: Hardware Driver Applicatie De bedoeling is om deze 3 manieren te onderzoeken: wat hun voor- en nadelen zijn, hoe ze presteren, etc... Uiteraard stopt het niet bij demultiplexen alleen: voor heel wat kanalen heb je een abonnement nodig. Deze kanalen zijn geëncrypteerd en niet zomaar te bekijken. Naast het demultiplexen, moeten deze ook nog gedecrypteerd worden. Deze decryptie zal vooral de CPU-belasting beïnvloeden, het is dus zeker interessant om nader te bestuderen in welke mate de CPU-belasting beïnvloed wordt.

29 2.4 DVB-S 16 Figuur 2.4: Demultiplexen: één kanaal uit de transport stream halen Figuur 2.5: Demultiplexen: twee kanalen uit de transport stream halen 2.4 DVB-S Het ontvangen van een DVB-S signaal is grafisch voorgesteld op figuur 2.6. Een basisstation (Service provider basestation), zendt de signalen door naar een satelliet die in een geostationaire baan rond de aarde draait (uplink). Deze satelliet zend de signalen vervolgens terug naar de aarde, zodat de eindgebruiker deze thuis kan ontvangen (downlink). De meest gekende en meest gebruikte service provider voor satellietuitzendingen in Europa is SES-Astra. In tabel 2.5 zijn enkele technische details over DVB-S (en DVB-S2) weergegeven. In de tabel staan de gegevens van 2 mogelijke EIRP s (Equivalent isotropically radiated power, ofwel het vermogen waarmee de satelliet zijn signalen uitzend). Bij DVB-S gebeurt het moduleren volgens het QPSK-schema (Quadrature phase-shift keying). De FEC of Forward Error Correction kan oplopen tot 7/8 (7 informatie-bits met 1 extra controle-bit). De nuttige bitrate (per transponder) hangt af van de EIRP. Bij een EIRP van 51 dbw bedraagt deze 33,8 Mbit/s. Verhoog je de EIRP tot 53,7 dbw, dan kan de FEC verlaagd worden (minder controle-bits) en stijgt de bitrate tot 44,4 Mbit/s. Het aantal SD- en HD-kanalen per transponder is ook weergegeven. De aantallen MPEG-4 stromen die verzonden kunnen worden via DVB-S zijn louter ter vergelijking opgenomen, want DVB-S ondersteunt enkel MPEG-2.

30 2.5 DVB-S2 17 Figuur 2.6: Zenden en ontvangen van een DVB-S signaal Tabel 2.5: Vergelijking van DVB-S en DVB-S2 [2] (MPEG-4 gegevens bij DVB-S zijn enkel ter vergelijking) Satellite EIRP (dbw) System DVB-S DVB-S2 DVB-S DVB-S2 Modulation & Coding QPSK 2/3 QPSK 3/4 QPSK 7/8 8PSK 2/3 Useful Bitrate (Mbit/s) (gain = 36%) (gain = 32%) Number of SDTV Programmes 7 MPEG-2 10 MPEG-2 10 MPEG-2 13 MPEG-2 15 MPEG-4 21 MPEG-4 20 MPEG-4 26 MPEG-4 Number of HDTV Programmes 1-2 MPEG-2 2 MPEG-2 2 MPEG-2 3 MPEG MPEG-4 5 MPEG-4 5 MPEG-4 6 MPEG DVB-S2 Met de overstap naar HDTV-uitzendingen, kwamen ook enkele beperkingen van DVB-S naar boven. Vooral het gebruik van MPEG-2 en het feit dat enkel MPEG-2 gebruikt kon worden, werd een probleem. De bandbreedte voor een HDTV-kanaal dat met MPEG-2 gecodeerd wordt, bedraagt 12 á 20 Mbps. Als dezelfde HDTV-uitzending via MPEG-4 gecodeerd wordt, is dit maar de helft. Daarom werd besloten om MPEG-4-ondersteuning toe te voegen aan de opvolger van DVB-S. Dit is dan ook het voornaamste verschil tussen DVB-S en DVB-S2: het toevoegen van MPEG-4 (naast MPEG-2), naast het toevoegen van meer geavanceerde modulatietechnieken.

31 2.6 Latentie 18 Het resultaat is zichtbaar in tabel 2.5: een hogere bandbreedte en dus meer kanalen per transponder. Uiteraard zorgt het gebruik van MPEG-4 voor een grotere belasting van en- en decoders. Er bestaat specifieke hardware voor deze decodering, maar als we de flexibiliteit van softwarefiltering willen behouden, zal ook de decodering in software moeten gebeuren wat (vermoedelijk) zal resulteren in een hogere CPU-belasting. 2.6 Latentie Door het gebruik van MPEG-2 (of MPEG-4) komt ook een fenomeen naar boven dat bij analoge TV niet gekend was: latentie. Het veranderen van TV-kanalen zal nooit onmiddelijk gebeuren, er zal altijd een kleine latentie aanwezig zijn. Om dit fenomeen te kunnen begrijpen, gaan we eerst wat dieper in op MPEG-2 (MPEG-4 werkt ongeveer op dezelfde manier) MPEG-2 Een MPEG-2 video-stroom bestaat uit 3 soorten frames (of beelden). I-, P- en B-frames: I-frames of Intra coded frames: deze frames worden als JPEG-beelden gecodeerd en zijn bijgevolg volledig onafhankelijk van andere frames. groter dan P- en B-frames. Hierdoor zijn de I-frames ook P-frames of Predictive coded frames: bij dit soort frames wordt het verschil genomen tussen het frame en het voorgaande I- of P-frame. Vervolgens wordt dit verschil gecodeerd waardoor de grootte van dit frame een stuk kleiner is (het verschilframe bevat immers veel kleinere waarden dan een gewoon frame). B-frames of Bi-directional coded frames: om deze frames te creëren wordt eerst een interpolatie gemaakt van het voorgaande en volgende I- of P-frame. Vervolgens wordt het verschil gecodeerd tussen de interpolatie en het originele frame. Omdat interpolatie het huidige frame doorgaans goed benadert, zal het verschil nog kleiner zijn en zal de grootte van het B-frame nog kleiner zijn. Om een vooorstelling te kunnen maken van hoe dit in zijn werk gaat, is figuur 2.7 toegevoegd. Hierop is duidelijk de afhankelijkheid tussen de frames te zien. De structuur van een GOP (group of pictures 2 ) is ook weergegeven, alsook de volgorde waarin deze verzonden wordt. De volgorde 2 Een group of pictures is de groep beelden van I- tot I-frame

32 2.6 Latentie 19 waarin frames verzonden worden, is dezelfde volgorde als waarin de frames gecodeerd worden, maar dit is (door de afhankelijkheden) verschillend van de volgorde waarin de frames moeten worden afgespeeld. Op deze manier moet de decodering niet op frames wachten, de gedecodeerde frames moeten enkel nog in de juiste volgorde geplaatst worden. Het verzenden van een MPEG-2-stroom begint bij een I-frame. Na dit eerste I-frame volgt een P-frame, omdat dit enkel afhangt van het voorgaande I-frame (het tweede P-frame zal uiteraard afhangen van het eerste P-frame, en niet van het I-frame). Pas na een I- en een P-frame zal een B-frame verzonden worden. B-frames zijn (zoals eerder vermeld) afhankelijk van 2 frames (I- of P-frames) en kunnen dus ook niet eerder gecodeerd worden. I I I P P I B P B I B P B I Voorbeeld van een GOP... I B B P B B P B B I en de volgorde waarin de frames van een GOP worden verzonden I P B B P B B I B B Figuur 2.7: Structuur van een GOP-frame [5] Verklaring latentie Als we wisselen tussen kanalen, zal eerst moeten gewacht woren op een I-frame, omdat alle erop volgende frames afhangen van dit I-frame. Deze wachttijd is de voornaamste veroorzaker van de latentie die gemerkt wordt tijdens het wisselen. Of dit nu specifieke DVB-hardware is of een software-implementatie van een MPEG-2 decoder, zonder I-frame kan gewoon niet (correct) gedecodeerd worden.

33 MEERKANAALSONTVANGER 20 Hoofdstuk 3 Meerkanaalsontvanger De set-top boxen voor DVB-S ontvangst die vandaag bestaan, passen hardwarefiltering toe maar zijn hierbij beperkt in het aantal kanalen dat ze tegelijk kunnen filteren. Meestal is dit beperkt tot één kanaal. Sommige, meer geavanceerde, toestellen kunnen twee kanalen aan, maar daar blijft het dan ook bij. Het doel van deze thesis is om te gaan kijken hoe we dit flexibeler kunnen oplossen door een DVB-S-ontvanger aan een Linux-PC te koppelen en zo op verschillende niveau s filtering toe te passen. In dit hoofdstuk bekijken we eerst kort enkele praktische toepassingen, waarna we dieper ingaan op de verschillende niveau s waarop we de filtering gaan toepassen. 3.1 Praktische toepassingen Thuisgebruik Figuur 3.1 toont een mogelijke toepassing voor thuisgebruikers. Er wordt gebruik gemaakt van een centrale PC waarop een DVB-S ontvanger wordt aangesloten. Deze PC/server streamt vervolgens verschillende kanalen naar het thuisnetwerk zodat de ouders in de huiskamer naar hun favoriete show kunnen kijken terwijl zoonlief op zijn PC naar MTV kijkt en de dochter ondertussen naar haar favoriete kinderprogramma kan kijken. De centrale server kan tegelijk nog een vierde programma opnemen. De prijs van de centrale server ligt natuurlijk hoger dan die van de meeste off-the-shelve set-top boxen. Het voornaamste voordeel is echter dat, eens dit centrale systeem op poten staat, je voor de prijs van de goedkoopste set-top box iedere TV kan voorzien van alle functionaliteit die in de veel duurdere set-top boxen aanwezig is.

34 3.1 Praktische toepassingen 21 Figuur 3.1: Voorbeeld van een praktische (thuis)toepassing Als extraatje kan je ook de volledige DVD-, muziek- en foto-collectie kopiëren naar de centrale server zodat je bijvoorbeeld nooit meer door je DVD-collectie moet zoeken als je naar een film wilt kijken. Ook backups van belangrijke bestanden kunnen op deze server geplaatst worden. Digitale TV wordt zo maar één van de vele voordelen en mogelijkheden Professioneel gebruik In een meer professionele omgeving kan deze opstelling ook gebruikt worden. Bijvoorbeeld een hospitaal dat digitale TV wil implementeren (omdat analoge TV minder en minder wordt aangeboden). Een centrale server kan de verschillende TV-kanalen over het netwerk streamen. Een thin client in de kamer van de patiënt kan deze dan afspelen. Ook hier zijn de bijkomende mogelijkheden groot: Video on demand als de patiënt een bepaalde film wil zien, aanbieden van betaalkanalen, en zo voort.

35 3.2 Filtering Bovendien is het gebruik van een thin client een stuk eenvoudiger dan per kamer een set-top box. Om te beginnen is er de configuratie die volledig via het netwerk kan gebeuren: aanpassingen aan de kanalenlijst, toevoegen van extra services,... Het gebeurt allemaal automatisch door de nodige aanpassingen op de centrale server in te geven. Thin clients hoeven bovendien ook niet duur te zijn. Voor de prijs van een eenvoudige set-top box kan al een thin client aangeschaft worden. Er zal enkel nog een netwerkverbinding moeten voorzien worden, maar dit is in de meeste (moderne) omgevingen reeds aanwezig. 3.2 Filtering... Frontend Demux Driver Applicatie (1) (2) (3) Figuur 3.2: Voorstelling van de gebruikte opstelling Op figuur 3.2 zie je de opstelling die voor deze scriptie werd gebruikt. Helemaal links heb je de schotelantenne die gericht is op de satelliet (tijdens deze scriptie werd Astra 19.2E gebruikt). Deze is via een coax-kabel (1) verbonden met de FireDTV-ontvanger. De data die over deze verbinding loopt is nog analoog en moet in de FireDTV-ontvanger omgezet worden naar digitale signalen door gebruik te maken van demodulatie. Via firewire (2) is de FireDTVontvanger verbonden met de PC/server en zal een transport stream over de firewire-verbinding naar de PC/server gezonden worden. Deze PC/server is op zijn beurt via een (thuis)netwerk (3) verbonden is met de verschillende clients. Hiervoor wordt het gekende TCP- of UDP-protocol gebruikt. Voor de duidelijkheid zijn ook de belangrijkste componenten van de ontvanger en de server weergegeven. De ontvanger bestaat uit een frontend en een demultiplexer (afgekort tot demux

36 3.2 Filtering op de afbeelding). De frontend zorgt ervoor dat de tuner is ingesteld op de juiste frequentie. Hij zal ook het analoge signaal via demodulatie omzetten naar een digitaal signaal en via forward error correctie zal gepoogd worden om eventuele fouten in het signaal op te vangen. De output van de frontend is een transport stream die door de demultiplexer verder kan gefilterd worden. De demultiplexer van de gebruikte FireDTV-ontvanger is in staat om tot 16 PID s tegelijk uit de transport stream die hij van de frontend ontvangt te filteren. Hij kan de transport stream ook gewoon doorgeven om via firewire naar de PC verzonden te worden. Indien er wel filtering wordt toegepast, zal de demultiplexer de gewenste PID s uit de volledige transport stream filteren en ze in een kleinere transport stream plaatsen om deze zo ook via de firewire-verbinding door te kunnen geven aan de PC. De server bestaat uit twee belangrijke componenten: de driver die nodig is om de DVBontvanger te kunnen gebruiken en de applicatie die verantwoordelijk is voor het afspelen van het TV-kanaal. Als we een volledige transport stream van de ontvanger krijgen, kan de filtering op driver-niveau gebeuren of ze kan afgehandeld worden door de applicatie. Nu wordt wat dieper ingegaan op de verschillende niveau s waar filtering mogelijk is om zo een eerste beeld te kunnen vormen van welke resultaten verwacht kunnen worden door de applicatie In dit geval geven zowel driver als ontvanger de transport stream door aan de applicatie, zonder hierbij zelf wijzigingen aan te brengen in de transport stream. De applicatie is dus verantwoordelijk voor al de filtering. Het voordeel is dat deze situatie het meest flexibel is: er wordt een aanvraag naar de driver gestuurd en deze antwoordt hierop met de transport stream. De driver kan hierdoor minimaal en zeer efficiënt blijven. Ook de software kan zeer efficiënt te werk gaan: ofwel filtert deze enkel de opgevraagde kanalen, ofwel wordt de volledige transport stream via het netwerk gebroadcast zodat het zwaardere filterwerk door de eindgebruiker moet gedaan worden waardoor de server zelf weinig werk te verrichten heeft. In mijn afstudeerwerk bekijk ik enkel de situatie waarin de applicatie op de server wel degelijk gaat filteren om zo een eerlijke vergelijking te kunnen maken met de twee andere methodes.

37 (1) (2) (3) 3.2 Filtering Frontend Demux Driver Applicatie Figuur 3.3: PID-filtering door de applicatie Ook de latentie kanfrontend bij applicatiefiltering Demux geminimaliseerd Driver worden Applicatie indien gewisseld wordt tussen twee TV-kanalen die zich in dezelfde transport stream bevinden. Er moet immers enkel op het eerstvolgende I-frame van het TV-kanaal gewacht worden, driver en hardware worden ongemoeid gelaten. De latentie die in de driver en de hardware kan ontstaan, wordt hierdoor dan ook geëlimineerd. (1) (2) (3) op driverniveau Frontend Demux Driver Applicatie Figuur 3.4: PID-filtering door de driver Het vermoeden is dat er weinig verschil in prestaties zal zijn tussen filtering op applicatieen op driverniveau. Filtering op driverniveau is uiteindelijk ook softwarematige filtering.

38 3.2 Filtering Voor de latentie geldt hetzelfde als bij de filtering op applicatieniveau: zolang gewisseld wordt tussen TV-kanalen in dezelfde transport stream, is de enige latentie deze veroorzaakt door het gebruik van MPEG-2. De latentie veroorzaakt door de extra aanvraag die nodig is vanuit de applicatie naar de driver, is verwaarloosbaar indien client en server op dezelfde PC staan. Indien de client via een netwerk verbonden is met de server, zal een extra latentie ontstaan door het netwerk tussen client en server. Deze is echter verwaarloosbaar klein ten opzichte van de latentie die ontstaat door het gebruik van MPEG-2. Op driverniveau kanfrontend wel een optimalisatie Demuxdoorgevoerd Driver wordenapplicatie indien deze tot 16 PID s laat filteren door de hardware en zelf filtert indien meer PID s aangevraagd worden. De voornaamste vraag is of de overgang tussen hardware- en softwarefiltering ongemerkt kan gebeuren, aangezien het onmogelijk is om tegelijkertijd een gefilterde en de volledige transport stream aan de DVBontvanger te vragen. (1) (2) (3) in hardware Frontend Demux Driver Applicatie Figuur 3.5: PID-filtering door de hardware Logischerwijs de meest efficiënte manier (filtering zelf veroorzaakt geen CPU-belasting), maar ook de minst flexibele: de gebruikte hardware kan tot 16 PID s filteren en dan is het gedaan. Driver en applicatie kennen deze beperking niet en zijn dus heel wat flexibeler. Bovendien worden de verschillende gefilterde elementary streams opnieuw samengevoegd tot een kleinere transport stream om transport via firewire van de DVB-ontvanger naar de PC mogelijk te maken. De applicatie of driver zal dus nog steeds een deel van de filtering op zich moeten nemen.

39 3.3 Samenvatting 26 De latentie zal het grootst zijn bij hardwarefiltering. Ook bij het wisselen tussen twee kanalen in dezelfde transport stream zal immers een aanvraag naar de hardware gestuurd worden, waardoor de latentie alleen maar groter wordt. De voornaamste vraag zal dan ook zijn of de latentie veroorzaakt door deze aanvragen merkbaar is ten opzichte van de latentie veroorzaakt door het gebruik van MPEG Samenvatting We vermoeden dat de prestaties van hardwarefiltering het best zullen zijn (dus de laagste CPUbelasting zal veroorzaken). Aan de andere kant zal de latentie bij hardwarefiltering naar alle waarschijnlijkheid het grootst zijn, omdat de aanvraag naar een ander TV-kanaal ook de langste weg moet afleggen. Volgende vragen zullen dus in deze scriptie beantwoord moeten worden: Wat is het verschil in CPU-belasting tussen de verschillende filterniveau s? Welk filterniveau veroorzaakt de kleinste latentie?

40 TESTPLATFORM 27 Hoofdstuk 4 Testplatform Voor deze scriptie werd gebruik gemaakt van hardware van het Oostenrijkse Digital Everywhere, meer precies de FireDTV S/CI en de FireDTV S2. Zoals de naam misschien al doet vermoeden, ondersteunt de eerste de DVB-S standaard en de tweede de DVB-S2 standaard (inclusief backwards compatibility voor DVB-S). Deze ontvanger wordt, via firewire, verbonden met een PC waarop Linux geïnstalleerd staat. Figuur 4.1: FireDTV ontvanger 4.1 Digital Everywhere Digital Everywhere is een jong Oostenrijks bedrijf, opgericht in maart 2003 in Villach. corebusiness is het ontwikkelen, produceren en verkopen van TV-ontvangers voor desktop, laptop en HTPC. Sinds de oprichting staan ze bekend als de enige fabrikant ter wereld die digitale TV mogelijk maakt in Windows Media Center 1. 1 Om volledig correct te zijn, dient vermeld te worden dat DVB-T standaard ondersteund wordt door Windows Media Center, maar enkel voor niet gecodeerde kanalen. De ontvanger van Digital Everywhere doet zich voor als DVB-T ontvanger, onafhankelijk van het gebruikte medium, en biedt gedecodeerde kanalen aan, hoewel deze gecodeerd (kunnen) verzonden zijn. De

41 4.2 PC 28 In 2004 werd ook een begin gemaakt aan Linux-ondersteuning. Deze Linux-driver kwam echter nooit verder dan het beta-stadium. Digital Everywhere was (en is nog steeds) van mening dat Linux-ondersteuning geen prioriteit is, maar ze zijn wel bereid om alle mogelijk ondersteuning te geven aan personen die een Linux-driver willen ontwikkelen. Op deze manier ben ik met hun in contact gekomen, zijn de nodige afspraken gemaakt en kon ik beginnen. 4.2 PC De hardware-specificaties van de PC waarop alle testen en een groot deel van de ontwikkeling werd uitgevoerd, worden getoond in tabel 4.1 Tabel 4.1: Hardwarespecificaties test PC Onderdeel Merk Model CPU AMD Athlon XP Geheugen Corsair 1 GiB DDR 333MHz Videokaart nvidia GeForce 2 GTS Harde schijf Seagate 250 GB SATA 7200 rpm Chipset nvidia nforce 2 DVB-ontvanger(s) Digital Everywhere FireDTV S/CI FireDTV S2 Het besturingssysteem was Ubuntu 7.10 (32 bits) met kernel versie De hardware is, zoals u kan zien, niet de meest recente. Op geen enkel moment is dit echter een probleem gebleken: alle prestatietesten zijn zonder problemen uitgevoerd en op geen enkel moment was de hardware de beperkende factor. Enkel bij de latentie heeft de verouderde hardware waarschijnlijk een rol gespeeld waardoor deze hoger ligt dan in de literatuur vermeld wordt. Het is echter belangrijker om te bepalen WAAR de latentie vooral optreedt en hoe groot de invloed is van het onderdeel dat deze veroorzaakt. Het bepalen van de relatieve invloed is echter ook niet eenvoudig omdat met zoveel verschillende factoren moet worden rekening gehouden. De CPU en videokaart zullen vooral een invloed hebben op de latentie veroorzaakt door het gebruik van MPEG-2, de CPU zal vooral de latentie in de driver en door het filteren beïnvloeden en de chipset zal de snelheid van de firewire-communicatie beïnvloeden. Daarom zijn de latentietesten ook op een tweede systeem uitgevoerd. De specificaties van dit systeem (een Dell Inspiron 9300 laptop) worden getoond in

42 4.3 Firewire 29 tabel 4.2. Tabel 4.2: Hardwarespecificaties laptop Onderdeel Merk Model CPU Intel Pentium M 1,86GHz Geheugen Kingston 1 GiB DDR2 533MHz Videokaart nvidia GeForce GO 6800 Harde schijf Seagate 100 GB IDE 7200 rpm Chipset Intel 915M DVB-ontvanger Digital Everywhere FireDTV S/CI 4.3 Firewire Firewire (ook gekend als de ieee1394 standaard of ilink) is een seriële bustechnologie, vooral ontwikkeld om een snelle, real-time verbinding mogelijk te maken. modes ondersteund: asynchronous en isochronous. Er worden twee transfer Asynchronous transfer mode: Bij deze transfer mode vindt er geen klok-synchronisatie plaats, er wordt gebruik gemaakt van request- en response-berichten. Dit is vergelijkbaar met TCP. Isochronous transfer mode: Deze methode is een pak sneller, maar er wordt geen ontvangstbevestiging verstuurd (deze transfer mode zou je dus kunnen vergelijken met UDP). De berichten worden in broadcast uitgestuurd naar alle firewire-nodes die verbonden zijn (rechtstreeks of via andere firewire-apparaten). Er kan telkens één node zenden, de andere nodes kunnen (maar zijn niet verplicht te) luisteren. De FireDTV-ontvanger maakt gebruik van isochronous transfer mode. Iedere 125 µs wordt een frame met vaste grootte verzonden, maar er wordt dus niet gewacht op bevestiging en verloren frames zijn bijgevolg ook echt verloren (worden niet opnieuw verzonden). De beschikbare bandbreedte van Firewire bedraagt 400Mbps, waarvan 80% overblijft voor isochronous transfer mode [6]. Theoretisch kunnen dus tot 8 transport streams over de firewire-bus verzonden worden. Om dit te doen, wordt de transport stream die door de demultiplexer van de DVB-ontvanger wordt gegenereerd, verpakt in firewire-pakketten. In het voorbeeld op figuur 4.2 wordt één

43 4.4 Linux 30 MPEG-2-pakket met een vaste grootte van 188 Bytes verpakt in een firewire-pakket. Op deze manier kunnen tot vier MPEG-2-pakketten in één firewire-pakket verpakt worden. MPEG-2-pakket Firewire-pakket 188 Bytes 188 Bytes Firewire-header Figuur 4.2: MPEG-2-pakket verpakt in een firewire-pakket 4.4 Linux Als besturingssysteem werd voor Linux gekozen, vooral om volgende 2 redenen: Open: Linux is een open systeem, alle code is vrij beschikbaar wat bugfixen een stuk eenvoudiger maakt. Tegelijk is er ook een grote community wat gericht vragen stellen eenvoudig maakt, iets wat niet mogelijk is bij de bekende concurrenten (Microsoft Windows en Apple MacOS). Ondersteuning: Door de ontwikkeling van de oude driver weer op te pakken, wordt de Linux-community ook ondersteund. Op het einde van deze scriptie is een werkende driver beschikbaar waardoor weer extra randapparatuur ondersteund is onder Linux. Het voordeel van open-source werd snel duidelijk toen een applicatie moest worden ontwikkeld die de performance van de hardware/software-oplossing moest testen. Hiervoor werd gekeken naar bestaande applicaties om zo te achterhalen wat er allemaal geïnitialiseerd moest worden, hoe dit best gebeurde enzovoort. Tijdens het aanpassen van de driver is de nodige hulp gekomen van mailinglists, vooral het oplossen van het probleem met het binden van de driver aan de DVB-ontvanger is dankzij die mailinglist opgelost (meer hierover in het volgende hoofdstuk). Net als ieder besturingssysteem bevat Linux ook een kernel space en een user space.

44 4.5 Driver 31 De kernel space is het eigenlijke hart van het besturingssysteem en biedt diensten aan aan de user space. De gebruiker kan hier niets (rechtstreeks) uitvoeren. Hij kan enkel opdracht geven om iets te doen, maar hij heeft geen controle over hoe dit gebeurt. De meeste drivers bevinden zich in de kernel space. De user space is de plaats waar alle applicaties van de gebruikers uitgevoerd worden. Via system calls kan de gebruiker services van de kernel space gebruiken, zoals input, output, aanmaken van een proces enzoverder. Figuur 4.3 geeft een overzicht van de belangrijkste lagen. Uiteraard zijn er heel wat system calls die de user space toelaten om opdrachten te geven aan de kernel space. Voor driverontwikkeling zijn de volgende functies de belangrijkste: Modules: toevoegen en verwijderen van de module (= driver) Hardware: toevoegen en verwijderen van de hardware, lezen van en schrijven naar de hardware Tussen de kernel space en de hardware zijn slechts twee functies nodig: het lezen van en het schrijven naar de hardware. Met deze basisfuncties is het mogelijk om alle benodigde functionaliteit te implementeren. 4.5 Driver Op figuur 4.4 is weergegeven waar de driver zich precies situeert. Zoals je kan zien, bevindt hij zich (logischerwijs) tussen de hardware en de applicatie (in de kernel space), maar tegelijk ook tussen twee API s: de firewire-api en de DVB-API. De firewire-api zorgt voor de vertaling van driverniveau naar hardware, zodat communicatie tussen kernel space en hardware eenvoudiger wordt (bijvoorbeeld een commando naar de ontvanger sturen wordt vereenvoudigd naar een functieoproep). De DVB-API zorgt voor een standaardisatie van de sytem calls vanuit de user space naar de kernel space. Door deze API te implementeren in de driver, kan iedere applicatie die de DVB-API ondersteunt ook overweg met de driver die deze implementeert. Door de driver te baseren op de DVB-API, kunnen dus alle bestaande applicaties die de DVB-API ondersteunen ook onmiddelijk samenwerken met de FireDTV-ontvanger.

45 4.5 Driver 32 User space (applicaties) Kernel space (modules en drivers) Hardware Figuur 4.3: Overzicht kernel- en user-space [4] Firewire-API Op figuur 4.5 wordt de firewire-api gesitueerd. Deze bevat verschillende onderdelen (libraw1394, raw1394, ieee1394 en ohci1394) en bevindt zich tussen de hardware en de applicatie. ohci1394 (voluit de 1394 Open Host Controller Interface driver) is de driver voor de firewire-poort die zich in de PC bevindt. Deze zorgt er dus voor dat signalen die via de firewire-kabel aankomen vertaald worden naar een formaat dat het besturingssysteem begrijpt en ook dat pakketjes van de PC naar de firewire-hardware (hier de DVB-ontvanger) kunnen verstuurd worden. Een low-level driver zal rechtstreeks gebruik maken van deze driver. De driver die in deze scriptie werd doorontwikkeld, bevindt zich een niveau hoger (high-level driver) en maakt gebruik van de ieee1394-module. Het grootte voordeel van deze module is de mogelijkheid tot registreren van bepaalde functies. Zo kan bijvoorbeeld een functie geregistreerd

46 4.6 Applicaties 33 worden die, als een nieuwe DVB-ontvanger gedetecteerd wordt, de nodige initialisatie-stappen doorloopt. De intellegentie die nodig is om te achterhalen of de nieuw aangesloten randapparatuur wel een DVB-ontvanger is, wordt zo verstopt. Een low-level driver moet deze herkenning en functie-oproepen zelf nog voorzien. raw1394 is ook het vermelden waard, omdat deze de nodige problemen heeft veroorzaakt. Het is een generieke driver voor firewire-randapparatuur die zich als driver voor de DVB-ontvanger registreerde voor de juiste driver de kans had om zich te registreren. Hierdoor werd de verkeerde driver gebruikt en deed de DVB-ontvanger ook niet wat hij moest doen. Op libraw1394 wordt niet dieper ingegaan. Deze module bevat een set functies om de communicatie met een firewire-apparaat nog verder te vereenvoudigen, maar is verder niet belangrijk voor deze scriptie DVB-API De DVB-API speelt zijn rol bij de communicatie tussen applicatie en driver (vetgedrukte pijl tussen applicatie en driver op figuur 4.6, meer uitleg over deze figuur volgt in deel over de werking van een DVB-applicatie). Hoewel de DVB-API maar meespeelt bij één deeltje van de figuur, speelt deze toch een belangrijke rol. Als iedere applicatie zijn eigen structuren gebruikt om tune- en demultiplex-parameters door te geven, is het een onbegonnen werk om een driver te schrijven. Het omgekeerde is natuurlijk ook waar: als iedere driver een andere structuur verwacht, kan geen enkelen applicatie deze allemaal ondersteunen. Daarom is de DVB-API in het leven geroepen. De DVB-API bevat gestandaardiseerde structuren en functies om parameters door te geven en opdrachten uit te voeren zodat implementatie van deze API ervoor zorgt dat alle applicaties met alle DVB-ontvangers kunnen werken die deze API ondersteunen. 4.6 Applicaties Werking Figuur 4.6 toont de verschillende datastromen die komen kijken bij het bekijken van een TVkanaal. We gaan er vanuit dat de nodige initialisatie is gebeurd, maar dat nog geen TV-kanaal is opgevraagd. Concreet houdt dit volgende beginvoorwaarden in: De driver is geladen en de DVB-ontvanger is correct herkend (en uiteraard aangesloten aan de (schotel)antenne).

47 4.6 Applicaties 34 De kanaallijst is gekend. Zo goed als alle Linux-applicaties voor digitale TV gebruiken eenzelfde standaard om de kanaallijst op te slaan. Deze bevat naast de kanaalnaam, ook de frequentie, polariteit, symbolrate en PID s (van audio- en video-stroom, ondertitels, teletekst, enzoverder). Op deze manier kan eenvoudig achterhaald worden welke frequentie nodig is voor welk kanaal en welke PID s moeten opgevraagd worden (bijlage A geeft wat meer uitleg over dit bestand). De applicatie is opgestart, maar er wordt nog geen TV gekeken. We gaan nu uit van volgende situatie: de gebruiker wil naar MTV Austria kijken. De applicatie gaat de gegevens hiervan opzoeken in het bestand met alle kanaalgegevens en leest volgende gegevens uit: Frequency: MTV Austria bevindt zich dus op de transponder met frequentie 12226MHz Symbolrate: De symbolrate bedraagt 27500k symbolen per seconde Polarity: H - De polariteit is horizontaal VID: PID van de videostroom is 515 AID: PID van de audiostroom is 662 TT: PID van teletekst is 578 De eerste 3 waarden (frequentie, symbolrate en polariteit) worden in één structuur opgeslagen, de te filteren PID s in een tweede. Daarna wordt een tune-commando naar de driver gezonden met als parameter de eerste structuur. Dit commando wordt vertaald naar een command frame dat de DVB-ontvanger verstaat en via firewire naar de DVB-ontvanger verzonden. Deze verwerkt het binnengekomen command frame en doet twee dingen: Hij stuurt een antwoord naar de driver terug zodat deze weet dat het command frame goed is aangekomen en de applicatie hiervan op de hoogte kan brengen. Hij zorgt dat de LNB van de schotelantenne (dit is het onderdeel van de schotelantenne dat de satelliet-signalen opvangt) op de juiste frequentie wordt ingesteld. De frontend

48 4.6 Applicaties 35 ontvangt de (analoge) signalen en zet deze, met behulp van de meegegeven symbolrate, om naar een digitaal signaal dat naar de demultiplexer wordt doorgestuurd. Als de applicatie van de driver te horen krijgt dat het tune-commando goed is aangekomen, zal een tweede commando naar de driver gestuurd worden. Deze keer met als parameter de structuur die de PID s bevat. De driver zal deze lijst met PID s doorsturen naar de demultiplexer (opnieuw via een command frame dat de DVB-ontvanger kan verstaan). De DVB-ontvanger zal opnieuw antwoorden als het command frame goed is aangekomen en zal de demultiplexer opdracht geven de gevraagde PID s te filteren en deze door te sturen naar de PC via een (kleinere) transport stream. De PC zal deze transport stream wegschrijven naar /dev/dvb/adapter/demux (een buffer op de Linux-PC). De applicatie kan dan uiteindelijk de transport stream uitlezen uit deze buffer en video en audio filteren zodat deze op de juiste manier verwerkt en weergegeven/afgespeeld kunnen worden Testapplicatie Om de prestaties van de verschillende oplossingen tegen elkaar te zetten, werd een applicatie ontwikkeld die in staat is om de volledige transport stream op te vragen of de gefilterde versie die enkel de gevraagde PID s bevat. Uit die stream worden vervolgens de gevraagde elementary streams gefilterd en weggeschreven naar de harde schijf of naar /dev/null (dit is gelijk met de streams onmiddelijk verwijderen om te voorkomen dat de harde schijf een bottleneck zou worden). De test-applicatie ging eerst niets meer zijn dan een aangepaste versie van de bestaande dvbstream-applicatie. Deze bood echter te veel mogelijkheden en bijkomende overhead zodat beslist werd om van nul te beginnen met een eigen applicatie. Voor sommige delen werd nog gekeken naar dvbstream, maar enkel om een idee te krijgen hoe wat moest gebeuren. Het overgrote deel van de applicatie werd zelf geschreven. De filtering zelf is vrij eenvoudig gehouden: van ieder binnenkomend pakket in de transport stream wordt het PID bepaald om zo te achterhalen of het een pakket is dat moet gefilterd worden of niet. Als het pakket niet moet gefilterd worden, wordt het gewoon genegeerd. Moet het pakket wel gefilterd worden, dan wordt het weggeschreven naar het bestand horend bij het PID (of naar /dev/null indien het niet nodig is om de gefilterde pakketten bij te houden).

49 4.6 Applicaties 36 Hardware Kernel Space User Space Figuur 4.4: Situering van de driver

50 4.6 Applicaties 37 Applicatie libraw1394 User space raw1394 ieee1394 Kernel space ohci1394 Figuur 4.5: Situering van de ieee1394-api

51 4.6 Applicaties 38 DVB-ontvanger Antenne Frontend Demultiplexer Driver /dev/dvb/adapter/ demux Applicatie PC Figuur 4.6: DVB-datastromen

52 REALISATIES 39 Hoofdstuk 5 Realisaties De realisaties van deze scriptie bestaan grofweg uit 2 delen: ten eerste is er de ontwikkeling van een linux-driver en ten tweede het implementeren en het testen van de verschillende filtermethodes. In dit hoofdstuk wordt eerst dieper ingegaan op de ontwikkeling van de driver en daarna op het testen van de verschillende filtermethodes. 5.1 Driver-ontwikkeling DVB-S Stap 1 van deze scriptie was het updaten en aan de praat krijgen van driver-code die 4 jaar geleden (in 2004) was geschreven. De Linux-developers staan natuurlijk niet stil en in de tussentijd zijn de nodige aanpassingen gebeurd aan de Linux-kernel en aan de API s die door de driver gebruikt worden. Allereerst moest onderzocht worden hoe een Linux-driver in elkaar zit en hoe kernel-modules werken. Eens dit gebeurd was, was het tijd voor de volgende stap: het aanpassen en compileren van de driver. Hier kwamen de eerste problemen kijken. Linux heeft een handig systeem dat gebruik maakt van bestanden (Makefiles) om zo met één commando (make) verschillende modules en de driver te builden. De bestaande Makefile bevatte echter de nodige fouten, waardoor het ook nodig was om wat dieper in te gaan op de structuur van zo n bestand en hoe het zelf kon aangemaakt worden. Na een paar maand (eind december) lukte dit uiteindelijk, waardoor in het tweede semester de nodige achterstand moest worden ingehaald. Ook het tweede semester begon met de nodige problemen. Om te beginnen was er een generieke Linux-driver (raw1394 ) die zich, foutief, zag als driver van de DVB-ontvanger waardoor

53 5.1 Driver-ontwikkeling 40 de eigen driver zich niet meer aan de ontvanger kon binden. Dit was echter niet onmiddelijk duidelijk, maar uiteindelijk bood de linux-ieee1394-mailinglist hulp. Een patch die het probleem in de firewire-library oplostte bleef ook niet lang uit. Begin maart was dus een eerste versie van de werkende driver beschikbaar. Getuige daarvan is figuur 5.1 die een screenshot is van Kaffeine (een Linux-programma waarmee onder andere TV kan gekeken worden). Het aanpassen van deze driver om filtering op hardware en op software-niveau te ondersteunen bleek vooral uitzoekwerk en in mindere mate programmeerwerk. PID s lopen van 0 tot en met Wordt PID 8192 aan de driver gevraagd, dan zal deze automatisch de volledige transport stream aan de hardware vragen. Worden andere PID s opgevraagd, dan wordt in de hardware een kleinere transport stream gevormd die enkel de gevraagde PID s bevat. Figuur 5.2 toont dat ook deze functionaliteit werkt. Op de Linux-PC werden twee TV-kanalen uit de transport stream gefilterd en via een netwerk gebroadcast. Een Windows-PC had geen problemen om deze stream op te vangen en beide kanalen tegelijk weer te geven. Figuur 5.1: Één van de eerste beelden Begin maart werd, in samenspraak met Digital Everywhere, beslist om de code door te geven aan professionele kernel-developers. Op deze manier kon ik verder werken aan mijn scriptie en bijhorende prioriteiten (meerkanaalsontvanger), terwijl de developers meer naar de prioriteiten van Digital Everywhere konden luisteren (implementatie van de common interface om geëncrypteerde kanalen te kunnen bekijken). Het was eerst de bedoeling om de common interfa-

54 5.1 Driver-ontwikkeling 41 Figuur 5.2: Een broadcast van twee live TV-kanalen ce ook als deel van deze scriptie te implementeren, maar dit bleek te veel werk voor e e n persoon. Ondertussen is de code aangepast om te voldoen aan de eisen die aan kernelcode worden gesteld en zijn al twee patches gecommit die nog wat kleinere problemen oplossen DVB-S2 Om de filtering van HDTV kanalen te kunnen testen, was een DVB-S2 ontvanger nodig. De hardware was beschikbaar, maar de driver was nog niet aangepast om met DVB-S2-signalen te werken. Vooral bij het tunen zijn meer parameters nodig die nog niet geı mplementeerd waren. Al snel bleek dat dit niet het enige probleem was: de originele code die detecteert welk soort ontvanger aangesloten is (DVB-S, DVB-C, DVB-T of DVB-S2) bleek niet voorzien op de komst van de nieuwe DVB-S2 ontvanger. Eenvoudig gesteld: de driver stuurde een commando naar de ontvanger om zo gegevens terug te krijgen. Deze gegevens zijn echter afhankelijk van het soort ontvanger en de hardwarerevisie. Dit had als resultaat dat de DVB-S2 ontvanger als DVB-S ontvanger werd herkend. Bij het tunen werden bijgevolg ook de verkeerde parameters doorgegeven. De beste oplossing voor dit probleem bleek niet de eenvoudigste. In plaats van een commando te sturen en te wachten op een antwoord, wordt het ROM-geheugen van de ontvanger uitgelezen. In dat ROM-geheugen is een rij van karakters aanwezig die het soort ontvanger bevat. Eens deze rij van karakters is uitgelezen, is het bepalen van het soort ontvanger eenvoudig.