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 2007-2008
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 2007-2008
i
Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk 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 dit afstudeerwerk.
Ben Backx
29 mei 2008
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 LATEXweer eens niet deed wat het moest doen, is hier uiteraard ook op zijn plaats.
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 2007–2008 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 ´e´en 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
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. I NTRODUCTION
D
IGITAL 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). Iframes are coded as JPEG-images. P-frames are coded as the difference between the frame and the previous I- or P-frame. Bframes 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. T ESTPLATFORM 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. IV. RESULTS A. CPU-load 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
CPU‐load based on number of filtered elementary streams 16 15
A.3 Filtering on driver level
14 13 12 Number of filtered elementaary streams
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.
11 10 9 Application
8
Hardware 7 6 5 4 3 2
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.
1 0
1
2
3
4
5
6
7
CPU‐load (%)
Fig. 1. CPU-load based on number of filtered elementary streams
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.
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. C ONCLUSIONS 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.
INHOUDSOPGAVE
vi
Inhoudsopgave Dankwoord
ii
Overzicht
iii
Extended abstract
iv
Inhoudstafel
vi
Afkortingen
viii
1 Inleiding
1
1.1
Meerdere TV-kanalen uit ´e´en DVB-stroom . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Ontwerpen van een meerkanaalsontvanger . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4.1
Domme DVB-ontvangers
. . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4.2
Slimme DVB-ontvangers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.3
Op Linux gebaseerde DVB-ontvangers . . . . . . . . . . . . . . . . . . . .
7
1.4.4
Media Center Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2 De DVB-standaard
10
2.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
DVB-zender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1
Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
DVB-ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3
INHOUDSOPGAVE
vii
2.4
DVB-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5
DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.6
Latentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6.1
MPEG-2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6.2
Verklaring latentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3 Meerkanaalsontvanger 3.1
3.2
3.3
20
Praktische toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.1
Thuisgebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1.2
Professioneel gebruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Filtering... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1
... door de applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.2
... op driverniveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.3
... in hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4 Testplatform
27
4.1
Digital Everywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3
Firewire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.4
Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.5
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5.1
Firewire-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5.2
DVB-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.6.1
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.6.2
Testapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.6
5 Realisaties 5.1
39
Driver-ontwikkeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.1.1
DVB-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.1.2
DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
INHOUDSOPGAVE 5.2
5.3
viii
Prestatietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.1
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.2
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2.3
Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2.4
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
Latentietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.3.1
Latentie veroorzaakt door de schotelantenne . . . . . . . . . . . . . . . . .
47
5.3.2
Latentie in de ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.3.3
Latentie in de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.3.4
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6 Besluit
52
6.1
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.2
Prestatietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.3
Latentietesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.4
Tot slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
A Structuur configuratiebestand
55
Bibliografie
57
Lijst van figuren
58
Lijst van tabellen
60
INHOUDSOPGAVE
Afkortingen DVB
Digital Video Broadcasting
DVB-C
DVB-Cable
DVB-H
DVB-Handheld
DVB-S
DVB-Satellite
DVB-T
DVB-Terrestrial
EIRP
Equivalent isotropically radiated power
EPG
Elektronische Programmagids
FEC
Forward error correction
GOP
Group Of Pictures
HD
High Definition
HTPC
Home Theatre PC
JPEG
Joint Photographic Experts Group
MPEG
Moving Picture Experts Group
PAT
Program Association Table
PES
Packetized Elementary Stream
PID
Packet IDentifier
ix
INHOUDSOPGAVE PMT
Program Map Table
PSK
Phase-shift keying
QAM
Quadrature Amplitude Modulation
QPSK
Quadrature phase-shift keying
SD
Standard Definition
TDM
Time Division Multiplexing
TS
Transport Stream
x
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
1.1 Meerdere TV-kanalen uit ´e´en 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 ´ e´ en DVB-stroom
Bestaande hardware is, meestal, maar in staat om ´e´en 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 ´e´en 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 ´e´en 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
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 ´e´en 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 ´e´en 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
DVB-stroom
1.3 Aanpak DVB-zender
DVB-stroom
Software 4
DVB-ontvanger
DVB-stroom
DVB-stroom
DVB-zender
Software
DVB-ontvanger (a) Softwarefiltering
DVB-stroom
DVB-zender
DVB-stroom
Software
DVB-ontvanger (b) Hardwarefiltering
Figuur 1.2: Verschil tussen hard- en softwarefiltering
DVB-stroom
DVB-stroom hoe deze de latentie be¨ınvloedt.
DVB-zender
1.3
DVB-ontvanger
Software
Aanpak
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.
1.4 State of the Art
1.4
5
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.
1.4.1
Domme DVB-ontvangers
’Domme’ DVB-ontvangers zijn DVB-ontvangers die slechts ´e´en 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 ´e´en 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 ´e´en 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
1.4 State of the Art
6
Figuur 1.3: Philips DSR2211 DVB-S ontvanger
1.4.2
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 ´e´en’ op ´e´en 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
1.4 State of the Art
7
minder veeleisende gebruiker zal echter meer dan voldoende hebben aan dit soort ontvangers.
1.4.3
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.
1.4.4
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.
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 ´e´en (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.
1.4 State of the Art
9
Figuur 1.7: MythTV voor Linux
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 ´e´en 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¨eren 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
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¨e zenden
momenteel enkel de openbare omroepen uit via DVB-T. De Belgische KPN-dochter Tele2 is aan het onderzoeken of commerci¨ele uitzendingen via DVB-T haalbaar zijn in Belgi¨e. DVB-S zendt uit via satelliet. TV-Vlaanderen doet dit ondertussen 2 jaar in Vlaanderen
en binnenkort waarschijnlijk ook in Walloni¨e. – 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).
2.2 DVB-zender
12
Transmissiemedium (kabel, satelliet, …)
Transportstroom 1
Kanaal 1.1
…
Kanaal 1.n
Transportstroom 2
Kanaal 2.1
Kanaal 2.2
Transportstroom 3
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 ´e´en taal, maar het is mogelijk om meerdere talen of bijvoorbeeld extra commentaar toe te voegen 1
Interdisciplinair instituut voor BreedBand Technologie, http://www.ibbt.be/project/maduf
2.2 DVB-zender
13
Figuur 2.3: Multiplexen tot ´e´en 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 ´e´en, 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 ´e´en 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 ´e´en 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 ´a 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.
2.2 DVB-zender
2.2.1
14
Voorbeeld
Om ´e´en 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 Elementary Elementary Elementary Elementary Elementary Elementary Elementary Elementary
stream stream stream stream stream stream stream stream stream
(PID (PID (PID (PID (PID (PID (PID (PID (PID
0) 100) 101) 102) 103) 104) 106) 200) 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 1 2
PMT-PID 200 201
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.
2.3 DVB-ontvanger
15
Tabel 2.3: PMT-tabel Service 1
PID 100 102 106
2.3
Stream type Video Audio Data
Tabel 2.4: PMT-tabel Service 2
PID 101 103 104
Stream type Video Audio Data
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 ´e´en 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¨encrypteerd 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.
2.4 DVB-S
16
Figuur 2.4: Demultiplexen: ´e´en 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.
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 Modulation & Coding Useful Bitrate (Mbit/s) Number of SDTV Programmes Number of HDTV Programmes
2.5
51 DVB-S QPSK 2/3 33.8 7 MPEG-2 15 MPEG-4 1-2 MPEG-2 3-4 MPEG-4
DVB-S2 QPSK 3/4 46 (gain = 36%) 10 MPEG-2 21 MPEG-4 2 MPEG-2 5 MPEG-4
53.7 DVB-S QPSK 7/8 44.4 10 MPEG-2 20 MPEG-4 2 MPEG-2 5 MPEG-4
DVB-S2 8PSK 2/3 58.8 (gain = 32%) 13 MPEG-2 26 MPEG-4 3 MPEG-2 6 MPEG-4
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 ´ a 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.
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).
2.6.1
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. Hierdoor zijn de I-frames ook groter dan P- en B-frames. 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¨eren 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 pictures2 ) 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
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 I
B
P
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]
2.6.2
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.
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 ´e´en 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 3.1.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.
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¨eren 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 ´e´en van de vele voordelen en mogelijkheden.
3.1.2
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¨ent kan deze dan afspelen. Ook hier zijn de bijkomende mogelijkheden groot: Video on demand als de pati¨ent een bepaalde film wil zien, aanbieden van betaalkanalen, en zo voort.
3.2 Filtering...
22
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
(1)
Demux
Driver
Applicatie
(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
3.2 Filtering...
23
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.
3.2.1
... 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¨ent blijven. Ook de software kan zeer effici¨ent 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.
3.2 Filtering...
(1)
(2)
Frontend
Demux
(3)
Driver
24
Applicatie
Figuur 3.3: PID-filtering door de applicatie
Ook de latentie kanFrontend bij applicatiefiltering indien gewisseld wordt Demux geminimaliseerd Driver worden Applicatie 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¨elimineerd. (1)
3.2.2
(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.
3.2 Filtering...
25
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 worden indien deze tot 16 PID’s laat Demux doorgevoerd Driver Applicatie 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)
3.2.3
(2)
(3)
... in hardware
Frontend
Demux
Driver
Applicatie
Figuur 3.5: PID-filtering door de hardware
Logischerwijs de meest effici¨ente 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.
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-2.
3.3
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?
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. De 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.
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 CPU Geheugen Videokaart Harde schijf Chipset
Merk AMD Corsair nVidia Seagate nVidia
DVB-ontvanger(s)
Digital Everywhere
Model Athlon XP 2500+ 1 GiB DDR 333MHz GeForce 2 GTS 250 GB SATA 7200 rpm nForce 2 FireDTV S/CI FireDTV S2
Het besturingssysteem was Ubuntu 7.10 (32 bits) met kernel versie 2.6.22-14. 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
4.3 Firewire
29
tabel 4.2. Tabel 4.2: Hardwarespecificaties laptop
Onderdeel CPU Geheugen Videokaart Harde schijf Chipset DVB-ontvanger
4.3
Merk Intel Kingston nVidia Seagate Intel Digital Everywhere
Model Pentium M 1,86GHz 1 GiB DDR2 533MHz GeForce GO 6800 100 GB IDE 7200 rpm 915M FireDTV S/CI
Firewire
Firewire (ook gekend als de ieee1394 standaard of iLink) is een seri¨ele bustechnologie, vooral ontwikkeld om een snelle, real-time verbinding mogelijk te maken. Er worden twee transfer modes ondersteund: asynchronous en isochronous. 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 ´e´en 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 ´e´en
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 ´e´en 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.
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.
4.5 Driver
32
User space (applicaties)
Kernel space (modules en drivers)
Hardware
Figuur 4.3: Overzicht kernel- en user-space [4]
4.5.1
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
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.
4.5.2
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 4.6.1 over de werking van een DVB-applicatie). Hoewel de DVB-API maar meespeelt bij ´e´en 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
4.6.1
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).
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: 12226 - MTV Austria bevindt zich dus op de transponder met frequentie
12226MHz Symbolrate: 27500 - De symbolrate bedraagt 27500k symbolen per seconde Polarity: H - De polariteit is horizontaal VID: 515 - PID van de videostroom is 515 AID: 662 - PID van de audiostroom is 662 TT: 578 - PID van teletekst is 578
De eerste 3 waarden (frequentie, symbolrate en polariteit) worden in ´e´en 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
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.
4.6.2
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).
4.6 Applicaties
36
Hardware
Kernel Space
User Space Figuur 4.4: Situering van de driver
37
Applicatie
libraw1394
User space
4.6 Applicaties
ieee1394
ohci1394
Figuur 4.5: Situering van de ieee1394-API
Kernel space
raw1394
4.6 Applicaties
38
DVB-ontvanger
Antenne
Frontend
Demultiplexer
Driver
/dev/dvb/adapter/ demux
Applicatie PC
Figuur 4.6: DVB-datastromen
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 5.1.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 ´e´en 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
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 8191. 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.
´ en van de eerste beelden Figuur 5.1: E´
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¨encrypteerde kanalen te kunnen bekijken). Het was eerst de bedoeling om de common interfa-
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´en 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.
5.1.2
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.
5.2 Prestatietesten
42
Het uitlezen van het ROM-geheugen was dit niet, omdat de bestaande API die hiervoor kan gebruikt worden niet gedocumenteerd is en bovendien ook weinig gebruikt wordt. Omdat de driver (hopelijk) nog enige jaren zal meegaan, is toch besloten om te kiezen voor de moeilijke, maar wel de beste oplossing. Jammer genoeg stopten de problemen niet met de herkenning. Om een reden die mij nog altijd niet duidelijk is, is de bestaande DVB-API verlaten en is men begonnen aan een nieuwe (onder de naam multiproto). Voor ondersteuning van DVB-S2 is men aangewezen op deze nieuwe multiproto-API die bovendien nog in ontwikkeling is. Als we even terug keren naar figuur 4.4, dan zie je dus dat de laag tussen applicatie en driver volledig is vervangen. Dit heeft natuurlijk verstrekkende gevolgen voor driver en applicaties. De volledige driver moet herschreven worden naar deze nieuwe API, iets wat door de beperkte tijd, waarvan dan nog een deel is verloren gegaan aan het correct herkennen van de ontvanger, onmogelijk is gebleken.
5.2
Prestatietesten
5.2.1
Driver
Filtering op driverniveau is niet getest. Er is beslist om deze filtering te laten vallen en dit om volgende redenen: Nut: Het nut van filtering op dit niveau wordt sterk in vraag gesteld. Filtering op
driverniveau gebeurt ook in software. Willen we deze filtering praktisch toepasbaar maken, dan moeten we op driverniveau dezelfde filtering toepassen als op hardwareniveau. Dit wil zeggen: de gevraagde PID’s filteren en opnieuw verpakken in een kleinere ’transport stream’. De applicatie zal dan nogmaals filtering moeten toepassen indien de kleinere stream meerdere kanalen bevat. Je krijgt dus twee filteringen in software, iets wat zeker de prestaties niet ten goede komt. Praktische haalbaarheid: Om de prestaties te verbeteren, kan op driverniveau volledige
filtering ge¨ımplementeerd worden. Dit wil zeggen: de elementary streams apart naar de applicatie sturen, maar ook hier zijn (vooral) praktische bezwaren. Het is niet eenvoudig om verschillende streams naar ´e´en applicatie te sturen en bovendien moeten klank en beeld gesynchroniseerd zijn, wat nog eens extra overhead veroorzaakt en bijgevolg mogelijke prestatiewinst tot niets (of zelfs prestatieverlies) herleidt.
5.2 Prestatietesten
43
Onmogelijk te testen: Uit de testresultaten blijkt dat de CPU-belasting beperkt is. Het
testen van de filtering op driverniveau wordt bijgevolg heel moeilijk, omdat we daarvoor enkel naar de totale CPU-belasting kunnen kijken (het is onmogelijk om de CPU-belasting te bepalen van ´e´en bepaalde driver). Door de lage CPU-belasting heeft iedere onverwachte actie op de test-PC invloed op de resultaten. Dit is niet het geval bij filtering op hardwareen applicatieniveau, omdat de CPU-belasting van de testapplicatie eenvoudig kan bepaald worden.
5.2.2
Hardware
Aantal gefilterde elementaary streams
CPU‐belasting in functie van aantal gefilterde elementary streams 15 13 11 9 7 5 3 1 0
1
2
3
4
5
6
CPU‐belasting (%)
Figuur 5.3: CPU-belasting hardwarefiltering
De resultaten van de hardware-filtering zijn getoond op figuur 5.3. Ze zijn bekomen door de testapplicatie een half uur te laten lopen, gedurende dat half uur iedere twee seconden de CPU-belasting van de applicatie te meten en van al deze waarden het gemiddelde te nemen. De resultaten zijn consistent en de CPU-belasting stijgt naar mate meer elementary streams moeten gefilterd worden, iets wat logisch is omdat de applicatie nog steeds elementary streams
5.2 Prestatietesten
44
moet filteren uit de kleinere stream die door de hardware wordt verstuurd. De grotere sprongen bij het filteren van een oneven aantal elementary streams, zijn te verklaren door de manier van testen: er wordt telkens afwisselend een video- en een geluidsstroom toegevoegd. De eerste stroom die gefilterd wordt, is dus een videostroom. De tweede die erbij komt een geluidsstroom, de derde weer een videostroom enzovoort. Een videostroom bevat uiteraard veel meer data dan een geluidsstroom, waardoor de CPU-belasting meer naar omhoog gaat als er zo’n videostroom extra moet gefilterd worden.
5.2.3
Applicatie
Aantal gefilterde elementaary streams
CPU‐belasting in functie van aantal gefilterde elementary streams 15 13 11 9 7 5 3 1 0
1
2
3
4
5
6
7
CPU‐belasting (%)
Figuur 5.4: CPU-belasting softwarefiltering
Op figuur 5.4 zijn de resultaten in geval van filtering op applicatieniveau te zien. Deze zijn iets minder consistent dan in het geval van hardwarefiltering. De stijgende de CPU-belasting door het filteren van steeds meer elementary streams uit de transport stream, is echter duidelijk zichtbaar. Het feit dat, in sommige gevallen, de filtering van een extra elementary stream (die geluid bevat) zorgt voor een lagere CPU-belasting, heeft 2 oorzaken: Ten eerste moet de applicatie sowieso naar ieder pakketje in de transport stream kijken
5.2 Prestatietesten
45
en het PID vergelijken met de lijst van te filteren PID’s. Een extra elementary stream filteren wil dus eigenlijk niets meer zeggen dan een extra stream wegschrijven naar de harde schijf of /dev/null. Dit verklaart een beperkte of geen stijging, maar nog niet de daling in sommige gevallen. Ten tweede is de CPU-belasting ook afhankelijk van het soort video dat we ontvangen. Zijn
er veel bewegende beelden aanwezig, dan zullen er meer en grotere pakketten in de stroom aanwezig zijn dan wanneer het rustige beelden zijn. Aangezien er gewerkt wordt met live uitzendingen, hebben we hier geen invloed op. Het kan dus gebeuren dat we enkel video filteren, maar video die veel bewegende beelden bevat waardoor er meer CPU-belasting is dan wanner we video ´en geluid filteren waarbij de videobeelden weinig beweging bevatten en dus minder CPU-belasting veroorzaken.
5.2.4
Besluit
Figuur 5.5 toont beide resultaten samen. Hierdoor wordt nog een extra trend duidelijk: naarmate meer en meer elementary streams moeten gefilterd worden, krimpt het voordeel van hardwarefiltering ten opzichte van software-filtering. Dit is logisch te verklaren, omdat de kleinere stream van ontvanger naar PC ook steeds groter wordt en er dus ook meer en meer dient gefilterd te worden door de software. Omdat de gebruikte hardware maximum 16 PID’s kan filteren, is het onmogelijk om de vergelijking door te trekken voor hogere aantallen elementary streams, maar het is te verwachten dat het voordeel van hardware-filtering nog kleiner zal worden. Al bij al biedt hardware-filtering dus zeker een prestatievoordeel, zeker bij kleinere aantallen elementary streams.
5.2 Prestatietesten
46
CPU‐belasting in functie van aantal gefilterde elementary streams 16 15 14 13
Aantal gefilterde elementary streams
12 11 10 9 Applicatie
8
Hardware 7 6 5 4 3 2 1 0
1
2
3
4
5
6
7
CPU‐belasting (%)
Figuur 5.5: CPU-belasting in functie van het aantal gefilterde elementary streams
5.3 Latentietesten
5.3
47
Latentietesten
Naast CPU-belasting is ook latentie een belangrijke factor, niemand wil immers eindeloos wachten om gewoon even tussen twee TV-kanalen te wisselen. Tijdens testen uitgevoerd met Kaffeine werd gemeten dat het veranderen van het ene kanaal naar het andere kanaal een latentie van 3 seconden veroorzaakt indien deze kanalen via dezelfde transponder worden uitgezonden. Worden de kanalen niet via dezelfde transponder uitgezonden, dan duurt het veranderen van het ene naar het andere kanaal gemiddeld 6 seconden (even lang als wanneer het programma nog maar net is opgestart en het eerste kanaal wordt opgevraagd). Op de meer recente laptop werden deze gemiddelde waarden respectievelijk 2 en 4 seconden. We merken hier ook op dat Kaffeine gebruik maakt van hardware filtering en dus zal bij het veranderen van TV-kanaal altijd een opdracht naar de demultiplexer van de DVB-ontvanger gestuurd worden, wat extra latentie met zich meebrengt. Figuur 5.6 toont waar deze latentie kan optreden: aan de schotelantenne (1), in de ontvanger (2) of op de PC (3). In wat volgt wordt hier stuk voor stuk op in gegaan en wordt zo bepaald hoe de totale latentie tot stand komt.
(1)
(2)
(3)
Figuur 5.6: Weergave van de gebruikte opstelling
5.3.1
Latentie veroorzaakt door de schotelantenne
Deze latentie neemt extreme waarden aan. Wisselen we tussen twee kanalen die via dezelfde transponder worden verzonden, dan is deze ongeveer 0,7 seconden indien de polariteit moet worden aangepast (dit blijkt uit timings in de driver-logs1 ). Blijft de polariteit dezelfde, dan is de latentie in de schotelantenne nul. Anders wordt het wanneer de schotelantenne voorzien 1
De tijd van het verzenden van de opdracht werd bijgehouden alsook de tijd van het ontvangen van de bevestiging dat het commando succesvol werd uitgevoerd
5.3 Latentietesten
48
wordt van een motor om zo verschillende satellieten te kunnen ontvangen. Het wisselen tussen 2 satellieten kan enkele seconden in beslag nemen. Het switchen tussen Astra 19.2°E en Astra 23.5°E zal ongeveer 4 seconden duren (± 1°/seconde [1]). In deze scriptie werden steeds signalen van eenzelfde satelliet gebruikt, dus de latentie in de schotelantenne wordt bepaald door het veranderen van polariteit.
5.3.2
Latentie in de ontvanger
In de ontvanger kan latentie op verschillende plaatsen ontstaan: in de tuner, in de frontend en in de demultiplexer. Ter verduidelijking is in figuur 5.7 de structuur van de DVB-ontvanger weergegeven. Tuner: de tuner is een voornamelijk analoge component. Via coax-kabel komt een sig-
naal binnen afkomstig van de schotelantenne dat door de tuner wordt omgezet naar een elektrisch signaal. Dit signaal wordt dan doorgestuurd naar de frontend. Het tunen gaat ook zeer snel (een beetje zoals op een FM-radio tussen voorgeprogrammeerde frequenties wisselen, ook dit gebeurt bijna ogenblikkelijk met zo goed als geen onderbreking). De exacte latentie is echter niet te bepalen. Frontend: het demoduleren en de forward error correction dragen ook hun steentje bij tot
de latentie, het grootste deel komt echter voort uit de initi¨ele synchronisatie. Een analoog signaal wordt afgeleverd aan de frontend en deze moet bepalen waar en wanneer een bit begint. Deze initialisatie is eenmalig, maar als de frequentie gewijzigd wordt, moet deze uiteraard opnieuw gebeuren. Uit de tijdstempels in de driver-logs kan wel bepaald worden hoe lang het tunen en initialiseren van de frontend samen duurt. Uit testen blijkt dat dit gemiddeld 0,7 seconden is. Demultiplexer: de demultiplexer moet in staat zijn om een volledige transport stream
te filteren en een kleinere transport stream die enkel de gevraagde PID’s bevat te genereren. Binnenkomende pakketjes van de transport stream moeten dus onmiddelijk verwerkt kunnen worden, anders ontstaat een buffer die (vroeg of laat) zal vollopen. Bovendien kan een buffer ook onverwachte jitter veroorzaken (als het ene pakketje wat langer in de buffer blijft dan het andere), wat natuurlijk voor de nodige problemen kan zorgen bij het live afspelen van TV. Iets wat wel tijd in beslag neemt, is het initialiseren. Een transport stream
5.3 Latentietesten
49
bestaat uit pakketjes, maar de stroom die van de frontend naar de demultiplexer loopt, bevat enkel bits. De demultiplexer moet dus eerst en vooral bepalen waar de pakketjes beginnen (en waar ze eindigen). Ook deze initialisatie zal bijdragen tot de totale latentie. Ook hier kunnen we tijdstempels uit de driver-logs gebruiken om te bepalen hoe lang deze initialisatie gemiddeld duurt. Dit bleek gemiddeld 0,5 seconden per gefilterde PID te zijn.
Tuner
Frontend
Demux
DVB-ontvanger
Figuur 5.7: Detail van de DVB-ontvanger
5.3.3
Latentie in de software
De relevante software-componenten zijn weergegeven op figuur 5.8. Het gaat hier over de devicedriver, applicatie en MPEG-2-decoders (dit zijn meestal codecs die door de applicatie worden ingeladen en dus te beschouwen als aparte software-componenten). De latentie in de driver zal echter minimaal zijn, omdat deze enkel opdrachten of data ontvangt, vertaalt en doorgeeft. Dit gebeurt zodanig snel dat de latentie die hierdoor wordt veroorzaakt, te negeren is. Ook de applicatie ondervindt nagenoeg geen latentie. Eens deze een transport stream ontvangt, kan ze onmiddelijk beginnen filteren. Indien we wisselen tussen twee TV-kanalen, moeten er telkens maar twee (of maximum 3) elementary streams gefilterd worden. Uit onze eerdere resultaten blijkt dat dit amper CPU-belasting veroorzaakt wat ook wijst op onmiddelijke verwerking van de transport stream. Een MPEG-2-stroom decoderen is onmogelijk zonder I-frame. Deze worden het minst van al verzonden, omdat dit de grootste frames zijn. Willen we naar een TV-kanaal beginnen kijken, dan zal sowieso op een I-frame gewacht moeten worden. De literatuur is echter onduidelijk over de structuur van een GOP-frame bij een DVB-uitzending. Als we de volledige transport-stream naar de applicatie sturen, kunnen we echter een benadering maken.
5.3 Latentietesten
50
Driver
MPEG-2 video decoder
Applicatie
MPEG-2 audio decoder software
Figuur 5.8: Detail van de (relevante) software-componenten
Als de volledige transport-stream naar de video-applicatie wordt verzonden, kunnen we in deze applicatie kiezen welk kanaal uit de transport stream we willen bekijken. Als we dus tussen kanalen wisselen, moet enkel gewacht worden op een I-frame van dat kanaal. De overige parameters (frequentie, polariteit, ...) moeten immers niet gewijzigd worden. Uit testen blijkt dat dit gemiddeld anderhalve seconde in beslag neemt op de oudste test PC. De recentere laptop doet er ongeveer een seconde over en op internet zijn er mensen in geslaagd, na de nodige optimalisaties, in minder dan een seconde van kanaal te wisselen. De latentie die ontstaat door het coderen van een MPEG-2-stroom is dus vooral systeem-afhankelijk. Deze testen werden uitgevoerd met dvbstream, die de volledige transport stream broadcast naar het netwerk, en VLC om deze af te spelen.
5.3 Latentietesten
5.3.4
51
Besluit
De totale latentie wordt op verschillende plaatsen veroorzaakt en hangt ook sterk af van systeem tot systeem. Op het gebruikte testsysteem was het vooral de MPEG-2-decoder die met ongeveer 2 seconden het grootste deel van de latentie veroorzaakte. De latentie veroorzaakt door schotelantenne en DVB-ontvanger hangt minder af van het systeem, maar in meerdere mate van wat ervan verwacht wordt. Indien gewisseld wordt tussen twee TV-kanalen op dezelfde transponder, zal de extra latentie ongeveer 1 seconde bedragen omdat de demultiplexer opnieuw moet ingesteld worden op twee andere te filteren streams. Wordt gewisseld tussen twee kanalen op verschillende transponders, dan komt er nog een extra latentie van de tuner bij en als ook de polariteit moet aangepast worden, zal ook de LNB van de schotelantenne nog een extra latentie veroorzaken. Ook set-top boxen hebben te maken met deze latentie. Grote bedrijven zijn nog steeds aan het onderzoeken hoe deze geminimaliseerd kan worden. Een snelle, hedendaagse PC kan de latentie al beperken tot minder dan ´e´en seconde, iets wat ook het geval is bij de moderne set-top boxen. Latentie is dus zeker geen reden om te kiezen voor een set-top box, maar is wel iets wat door iedereen gemerkt wordt. Het is dus zeker een gebied waarin de nodige optimalisatie kan en moet gebeuren zodat ook dit nadeel van digitale TV ten opzichte van analoge TV kan worden weggewerkt.
BESLUIT
52
Hoofdstuk 6
Besluit Deze thesis bestaat uit twee grote delen: het aanpassen/herschrijven van de bestaande driver en het beoordelen van de verschillende filtermethodes. Het is dus logisch om ook dit besluit op te delen.
6.1
Driver
Het doorgronden van Linux, de manier van werken met kernel-modules, de verschillende API’s die beperkt zijn qua documentatie en de driver die zo goed als geen documentatie bevatte bevorderden de vooruitgang niet echt. Na het updaten van de code bleek ook nog een fout(je) te zitten in een generieke firewire-driver. Hierdoor kon de eigen driver niet kan samenwerken met de ontvanger. Het probleem is meestal eenvoudig op te lossen, maar de oorzaak vinden is een stuk moeilijker. Al bij al heeft het updaten van de bestaande driver dus heel wat langer geduurd dan eerst gedacht. Achteraf kan dus de vraag gesteld worden of niet beter een oude Linux-versie kon gebruikt worden. Het antwoord op deze vraag is echter een overduidelijke nee. Door het updaten van de code naar de nieuwe Linux-kernel en bijhorende API’s, kan op het einde van deze scriptie een bruikbare driver toegevoegd worden aan de Linux-kernel. Hierdoor is deze niet enkel bruikbaar voor eventuele toekomstige onderzoeken, maar ook voor de volledige Linux-community. Het is op zijn minst heel jammer te noemen dat geen tijd meer was voor de DVB-S2 ondersteuning, maar hier zal na deze scriptie zeker nog aan gewerkt worden (onder andere door mezelf). Ondertussen is de driver ook doorgegeven aan Linux-developers die ondersteuning voor de
6.2 Prestatietesten
53
common interface gaan implementeren. Deze is nodig om abonnementkaarten van de providers te kunnen uitlezen zodat ook naar ge¨encrypteerde betaal-TV kan gekeken worden. Deze decryptie zal mogelijks ook de PC extra belasten en initieel was het de bedoeling om ook dit te bestuderen. Jammer genoeg is het toevoegen van de ondersteuning voor ge¨encrypteerde kanalen nog een paar stappen moeilijker dan het updaten en aanpassen van de driver. Het is dus onmogelijk om hier als individu aan te beginnen en dit binnen een redelijke termijn af te werken. Dit heeft ook als gevolg dat het testen van de invloed op CPU-belasting en latentie van ge¨encrypteerde TVkanalen niet mogelijk was.
6.2
Prestatietesten
De resultaten van de prestatietesten hebben niet direct grote verrassingen naar voor gebracht. Hardwarefiltering presteert beter, maar naarmate er meer elementary streams gefilterd moeten worden, neemt dit voordeel af. De sprongen die in de resultaten voorkomen, zijn te verklaren door het afwisselend karakter van de testen (er wordt afwisselend een video- en geluidsstroom toegevoegd). Enkel bij de resultaten van de softwarefiltering werd een onregelmatigheid ontdekt wanneer het toevoegen van een extra geluidsstroom resulteerde in minder CPU-belasting. Dit kan echter verklaard worden door de combinatie van volgende twee factoren: Het live karakter van de testen waardoor video op moment A veel meer afwisseling en dus
data kan bevatten dan video op moment B De applicatie bepaalt sowieso het PID van ieder pakket, dus enkel het wegschrijven van
bepaalde paketten zorgt voor extra CPU-belasting Het eerste puntje verklaart de soms (kleine) daling in CPU-belasting, het tweede punt verklaart waarom hardwarefiltering sneller stijgt dan softwarefiltering. Bij hardwarefiltering bevat ieder gecontroleerd pakket een PID dat gefilterd moet worden. Bij softwarefiltering moet de volledige transport stream gecontroleerd worden op pakketten die gefilterd moeten worden, dit verklaart de hogere CPU-belasting bij het filteren van kleinere aantallen PID’s.
6.3 Latentietesten
6.3
54
Latentietesten
Op gebied van latentie zijn de conclusies minder sluitend. Wel kan het volgende opgemerkt worden: Latentie in de ontvanger is vrij constant en onafhankelijk van de gebruikte PC, iets wat
logisch is aangezien de DVB-ontvanger dezelfde blijft, onafhankelijk van de gebruikte PC. Een opdracht wordt even snel verwerkt en uitgevoerd, of die nu van een trage of snelle PC komt. Latentie in de driver is ook vrij constant, maar het vertalen van een applicatie-opdracht
naar een opdracht die door de DVB-ontvanger kan verstaan worden, zal op een tragere PC langer duren dan op een snelle PC. De latentie die hierdoor ontstaat is echter verwaarloosbaar en bovendien bijna niet te meten. Latentie in de software hangt meer af van de gebruikte PC, omdat een MPEG-2-stroom
decoderen een CPU-belastende taak is. Meer recente CPU’s zijn ook meer geoptimaliseerd om deze taak uit te voeren dan de oudere generaties. Deze latentie weegt doorgaans het meeste door, zeker als we de volledige transport stream naar de applicatie sturen en de TV-kanalen waartussen gewisseld worden in diezelfde transport stream zitten.
6.4
Tot slot
Welke manier van filtering is nu de beste? Kijken we puur naar de CPU-belasting, dan is hardware-filtering de winnaar. De CPU-belasting is echter laag (maxima rond de 6%) zodat we ons de vraag kunnen stellen: is CPU-belasting de belangrijkste test-parameter? Zolang deze laag blijft, kunnen we veilig stellen dat latentie meer invloed zal hebben op de gebruikerservaring. Kijken we naar latentie, dan wint de software-filtering het van de hardwarefiltering. Als we tenminste wisselen tussen twee TV-kanalen in dezelfde transport stream. En aangezien de service providers meestal de meest populaire kanalen zoveel mogelijk in eenzelfde transport stream plaatsen, kunnen we er wel vanuit gaan dat dit vaak zal gebeuren. Op gebied van CPU-belasting wint de hardware-filtering dus weinig verrassend. Kijken we meer naar latentie en de gebruikerservaring, dan zal software-filtering het doorgaans beter doen.
STRUCTUUR CONFIGURATIEBESTAND
55
Bijlage A
Structuur configuratiebestand Onderstaande regel is een voorbeeld van hoe MTV Austria gedefinieerd is in het configuratiebestand dat door de meeste Linux-programma’s wordt gebruikt: MTV AUSTRIA ;MTV Networks : 1 2 2 2 6 : hC34 : S19 . 2 E : 2 7 5 0 0 : . . . ...515:662= ger : 5 7 8 : 0 : 2 8 6 4 1 : 1 : 1 0 9 1 : 0
MTV AUSTRIA is natuurlijk de naam van het TV-kanaal, MTV Networks de naam van
de provider1 . 12226 is de frequentie (in MHz) van de transponder waarop het TV-kanaal is te vinden. hC34 bevat enderzijds de polariteit (h) en anderzijds ook de prioriteit van het kanaal
(C34). S19.2E is de satelliet die de signalen uitzendt, deze waarde wordt bijvoorbeeld gebruikt
indien een motor aanwezig is om op meerdere satellieten te richten of indien via een switch tussen verschillende satellieten kan gekozen worden. 27500 is de symbolrate (in 1000 symbolen per seconde). 515 is het PID van de video-stroom, 662=ger is het PID van de audio-stroom en de taal
(ger = Duits). 578 is het PID van teletekst. De waarde die op het PID van teletekst volgt (in dit geval 0) is een waarde voor conditional
access (CA, of betaalTV). 0 wijst op geen encryptie, een waarde tussen 5 en 100 bepaalt 1
Met provider bedoelen we hier het bedrijf dat betaalt om de zender via de Astra-satellieten uit te zenden, dit is niet noodzakelijk het bedrijf dat voor de beelden zorgt.
STRUCTUUR CONFIGURATIEBESTAND
56
welke methode voor decryptie nodig is (andere waarden zijn ook mogelijk, maar hebben niets met digitale TV te maken). 28641 is het service ID. De 1 en 1091 erna respectievelijk het netwerk ID en het transport
ID (beide zijn momenteel niet gebruikt). 0 tot slot is het radio ID dat gebruikt wordt moesten SID, NID en TID gelijk zijn om zo toch nog het onderscheid te kunnen maken tussen 2 kanalen.
BIBLIOGRAFIE
57
Bibliografie [1] STAB
diseqc
motor
H120.
http://www.schoonebeek-
bas.nl/sat/themes/kategorie/index.php?id=63&katid=65&action=detail. [2] DVB-S2
-
2nd
Generation
Satellite
Broadcasting,
august
2007.
http://www.dvb.org/technology/fact sheets/DVB-S2%20Fact%20Sheet.0408.pdf. [3] Weg met sneeuw op je tv, 2008. http://www.wegmetsneeuwopjetv.be/. [4] Xavier
Calbet.
Writing
device
drivers
in
Linux:
A
brief
tutorial.
http://www.freesoftwaremagazine.com/articles/drivers linux. [5] Nick Kingsburg. The MPEG Standard. http://cnx.org/content/m11144/latest/. [6] Bill McKenzie. 1394 Isochronous Transfers – Part 1, September 2003. http://www.wd3.com/archive/1394IsochronousTransfersPart1.htm.
LIJST VAN FIGUREN
58
Lijst van figuren 1.1
Verduidelijking van huidige situatie en de doelstelling
. . . . . . . . . . . . . . .
3
1.2
Verschil tussen hard- en softwarefiltering . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Philips DSR2211 DVB-S ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Inverto IDL7000PVR DVB-S ontvanger . . . . . . . . . . . . . . . . . . . . . . .
6
1.5
Dreambox DM800 HD PVR DVB-S ontvanger . . . . . . . . . . . . . . . . . . .
7
1.6
Windows Vista Media Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.7
MythTV voor Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1
Vergelijking tussen analoge ruis en artefacten (digitale ’ruist’) . . . . . . . . . . .
11
2.2
Van elementaire datastromen tot transmissiemedium . . . . . . . . . . . . . . . .
12
2.3
Multiplexen tot ´e´en transport stream . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4
Demultiplexen: ´e´en kanaal uit de transport stream halen . . . . . . . . . . . . . .
16
2.5
Demultiplexen: twee kanalen uit de transport stream halen . . . . . . . . . . . .
16
2.6
Zenden en ontvangen van een DVB-S signaal . . . . . . . . . . . . . . . . . . . .
17
2.7
Structuur van een GOP-frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1
Voorbeeld van een praktische (thuis)toepassing . . . . . . . . . . . . . . . . . . .
21
3.2
Voorstelling van de gebruikte opstelling . . . . . . . . . . . . . . . . . . . . . . .
22
3.3
PID-filtering door de applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4
PID-filtering door de driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5
PID-filtering door de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.1
FireDTV ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
MPEG-2-pakket verpakt in een firewire-pakket . . . . . . . . . . . . . . . . . . .
30
4.3
Overzicht kernel- en user-space . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
LIJST VAN FIGUREN
59
4.4
Situering van de driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5
Situering van de ieee1394-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.6
DVB-datastromen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.1
´ en van de eerste beelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E´
40
5.2
Een broadcast van twee live TV-kanalen . . . . . . . . . . . . . . . . . . . . . . .
41
5.3
CPU-belasting hardwarefiltering . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.4
CPU-belasting softwarefiltering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.5
CPU-belasting in functie van het aantal gefilterde elementary streams . . . . . .
46
5.6
Weergave van de gebruikte opstelling . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.7
Detail van de DVB-ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.8
Detail van de (relevante) software-componenten . . . . . . . . . . . . . . . . . . .
50
LIJST VAN TABELLEN
60
Lijst van tabellen 2.1
Overzicht van elementary streams en hun PID . . . . . . . . . . . . . . . . . . . .
14
2.2
PAT-tabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
PMT-tabel Service 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4
PMT-tabel Service 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5
Vergelijking van DVB-S en DVB-S2 . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.1
Hardwarespecificaties test PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2
Hardwarespecificaties laptop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
