IPTV služba v síti malého poskytovatele internetu

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

IPTV služba v síti malého poskytovatele internetu Bc. Zdeněk Kopřivík

Vedoucí práce: Ing. Jan Kubr

Studijní program: Elektrotechnika a informatika, strukturovaný, navazující magisterský Obor: Výpočetní technika 10. kvetna 2012

iv

v

Poděkování Děkuji společnosti MX-NET Telekomunikace s.r.o. za umožnění realizace tohoto projektu a vývojářům open-source aplikací za množství kvalitního a dostupného software a za spolupráci při zahrnování navržených úprav do nových verzí.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Bruntále dne 10. 5. 2012

.............................................................

viii

Abstract This thesis describes the design and implementation of IPTV (IP television) service in the network of MX-NET Telekomunikace s.r.o. including set-top box and server for receiving television signal.

Abstrakt Tato práce se zabývá návrhem a implementací služby IPTV (IP televize) v síti společnosti MX-NET Telekomunikace s.r.o., a to včetně set-top boxu a vlastního serveru pro příjem televizního signálu.

ix

x

Obsah 1 Úvod

1

2 Specifikace cíle, požadavky na systém

3

2.1

Specifikace cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Požadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3 Analýza sítě, návrh topologie systému

5

3.1

Cílové lokality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.2

Analýza sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.3

Požadavky na umístění hlavního serveru . . . . . . . . . . . . . . . . . . . . . 10

3.4

Návrh topologie systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5

Metody přenosu datového proudu . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5.1

3.6

IP multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Navrhované řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Návrh hardware 4.1

19

Server pro příjem signálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1

Hardwarová konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2

DVB tunery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.3

Antény . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.4

Čtečka karet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2

Re-streamovací server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3

Set-top box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Výběr software 5.1

23


Operační systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2

Příjem signálu a streamování . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.2.1

VideoLAN Client . . . . . . . . . . . . . . . . . . . . . . . . 24

xi

xii

OBSAH

5.1.3 5.2

5.3

5.1.2.2

The Video Disk Recorder . . . . . . . . . . . . . . . . . . . . 24

5.1.2.3

Getstream 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.2.4

MuMuDVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Čtečka karet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Re-streamovací server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1

VideoLAN Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2

The Video Disk Recorder . . . . . . . . . . . . . . . . . . . . . . . . . 27

Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Realizace 6.1

6.2

29


Operační systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1.2

DVB tunery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.2.1

TT-budget S2-3200 . . . . . . . . . . . . . . . . . . . . . . . 30

6.1.2.2

GIGABYTE GT-PS700 . . . . . . . . . . . . . . . . . . . . . 30

6.1.2.3

Genius TVGo DVB-T03 . . . . . . . . . . . . . . . . . . . . . 31

6.1.3

Open-SASC-NG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.4

Čtečka karet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.5

MuMuDVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1.6

MRouteD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Re-streamovací server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2.1

Operační systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.2

The Video Disk Recorder . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2.2.1

Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.2.2

Konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2.2.3

Testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.2.4

Analýza problému . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.2.5

Návrh řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3

Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.4

Set-top box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.5

Zabezpečení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Testování

47

8 Závěr

49

A Seznam použitých zkratek

53

B Obsah přiloženého CD

55

Seznam obrázků 3.1

Topologie sítě z pohledu cílových lokalit . . . . . . . . . . . . . . . . . . . . .

6

3.2

Zatížení spoje mezi páteřní sítí a cílovou lokalitou 1 . . . . . . . . . . . . . .

6

3.3


7

3.4


7

3.5

Topologie sítě v cílových lokalitách 1 a 2 . . . . . . . . . . . . . . . . . . . . .

8

3.6

Topologie sítě v cílové lokalitě 3 . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.7

Ukázka vytížení cílové sítě při směrování typu unicasting . . . . . . . . . . . . 11

3.8

Ukázka vytížení cílové sítě při směrování typu broadcasting . . . . . . . . . . 12

3.9

Ukázka vytížení cílové sítě při směrování typu multicasting . . . . . . . . . . 13

3.10 Ukázka topologie navrhovaného systému s re-streamovacím serverem . . . . . 16 6.1

Webové rozhraní aplikace OSCam . . . . . . . . . . . . . . . . . . . . . . . . 34

7.1

Zatížení re-streamovacího serveru v cílové lokalitě 1 . . . . . . . . . . . . . . . 47

7.2

Zatížení re-streamovacího serveru v cílové lokalitě 3 . . . . . . . . . . . . . . . 48

B.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

xiii

xiv

SEZNAM OBRÁZKŮ

Kapitola 1

Úvod Společnost MX-NET Telekomunikace s.r.o. vznikla v roce 20041 . Hlavním předmětem jejího podnikání je poskytování kvalitního připojení k síti Internet v Moravskoslezském kraji (Bruntál, Vrbno pod Pradědem, Světlá Hora a další města a obce[12]). V důsledku konkurenčního boje je v poslední době nucena zabývat se možnostmi rozšíření portfólia služeb o VoIP (telefony přes IP síť) a IPTV (příjem televizního vysílání přes IP síť). Tato diplomová práce se zabývá právě návrhem a implementací služby IPTV. Vzhledem k sociálně ekonomické situaci v kraji (vysoká nezaměstnanost a nízké platy) a na základě průzkumu u uživatelů dospělo vedení společnosti k závěru, že o tradiční placenou IPTV službu nemají zákazníci zájem. Místo toho přišlo s návrhem neplacené služby, která by byla automaticky přístupná všem klientům v oblastech, kde je to technicky možné, a kterou by bez investice do zařízení u klienta bylo možné provozovat přímo v počítači nebo po zakoupení set-top boxu na televizním příjimači. Ačkoliv nelze bezplatně nabídnout placené kanály, lze nabídnout více kanálů než je v dané oblasti k dispozici prostřednictvím signálu DVB-T. Služba MX-TV, jak byla nazvána pro účely propagace[12], tedy nemá za cíl soutěžit s televizními službami konkurenčních operátorů (UPC, Telefónica O2 a další). Předpokládá se, že ji kromě technických nadšenců ocení uživatelé mobilních zařízení (notebooků a tabletů), kteří na nich budou moci pohodlně sledovat televizi bez nutnosti pořizování tunerů a bez připojení k anténě, dále domácnosti, které disponují pouze jedním TV přijímačem, a v neposlední řadě klienti v místech, kde je špatné pokrytí signálem DVB-T (hlavně Vrbno pod Pradědem).

1

Společnost MX-NET Telekomunikace s.r.o. jako společnost s ručením omezeným byla založena až dne 10. 5. 2007. Vznikla přímou transformací z OSVČ současného jednatele založeného 20. 9. 2004.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Specifikace cíle, požadavky na systém 2.1

Specifikace cíle

Cílem projektu je navrhnout, implementovat a otestovat službu IPTV v síti společnosti MX-NET Telekomunikace s.r.o.

2.2

Požadavky na systém

Vzhledem k tomu, že má být výsledná služba nabízena zdarma, je nutné, aby byla zcela autonomní. Nestačí tedy vyřešit distribuci signálu v síti společnosti MX-NET Telekomunikace s.r.o. a jako zdroj signálu využít některého z komerčních poskytovatelů IPTV, protože to by znamenalo vysoké provozní náklady, je nutné navrhnout a implementovat vlastní server (tzv. headend), který bude schopen signál přijímat z veřejně dostupných zdrojů, např. digitálního terestriálního (pozemního) vysílání standardu DVB-T nebo digitálního satelitního vysílání standardu DVB-S. Tyto způsoby příjmu televizního vysílání za účelem následné redistribuce sice vyžadují v souladu s platnými zákony České Republiky zakoupení licence od Rady pro rozhlasové a televizní vysílání (RRTV[16]), ale ty představují náklady jednorázové a nepromítnou se do nákladů provozních. Analýzu právního prostředí v ČR v kontextu příjmu a redistribuce televizního vysílání a kalkulaci nákladů neprováděl autor této diplomové práce, proto nejsou její součástí. Dalším důležitým požadavkem je, aby byla služba funkční v existující síti bez nutnosti výměny zařízení nebo dokonce změn topologie. Důvodem je, že zadavatel předpokládá relativně nízké vytížení služby, ale chce ji nabídnout v několika rozsáhlých částech sítě, jejichž

3

4

KAPITOLA 2. SPECIFIKACE CÍLE, POŽADAVKY NA SYSTÉM

případné úpravy by představovaly neúnosně vysoké náklady. Tento požadavek se vztahuje také na případné domácí routery klientů. Služba má být dostupná na počítačích koncových zákazníků, aniž by byli nuceni investovat do zařízení. To znamená, že je potřeba navrhnout způsob přehrávání televize v PC, který bude multiplatformní a dostupný zdarma. Protože se předpokládá občasná změna programové nabídky nebo IP adres serverů, je požadováno automatické aktualizování těchto informací na straně klientů. Posledním požadavkem je návrh cenově dostupného set-top boxu, který bude možné nabídnout v případě, že klient projeví zájem provozovat službu přímo na televizním přijímači nezávisle na počítači. Set-top box by měl být kompatibilní jak se staršími televizními přijímači prostřednictvím kompozitního analogového výstupu, tak s novými prostřednictvím digitálního výstupu HDMI.

2.3

Shrnutí

• vlastní server pro příjem DVB-T a DVB-S signálu • funkčnost na existující síti • použití volně šiřitelného software • automatická aktualizace programové nabídky a adres serverů • set-top box s kompozitním a HDMI výstupem

Kapitola 3

Analýza sítě, návrh topologie systému 3.1

Cílové lokality

Cílem projektu je službu zpřístupnit ve všech lokalitách, kde společnost MX-NET Telekomunikace s.r.o. nabízí připojení v tarifní skupině NaOptice[12]. To v době návrhu této práce zahrnuje z hlediska topologie sítě celkem 3 samostatné oblasti ve 2 městech.

3.2

Analýza sítě

Všechny obrázky pocházejí z monitorovacího systému The Dude[9], který se ve společnosti MX-NET Telekomunikace s.r.o. používá pro dohled nad sítí, a jsou výsledkem zjednodušení reálné mapy sítě (vynecháním nepodstatných uzlů, resp. vybráním pouze některých, a odstraněním názvů a adres). Páteřní síť je tvořena optickými spoji, zahrnuje několik hlavních bodů a připojení do sítě Internet a z hlediska kapacity má obrovské rezervy1 .

1

Na přání společnosti MX-NET Telekomunikace s.r.o. neuvádím konkrétní čísla.

5

6

KAPITOLA 3. ANALÝZA SÍTĚ, NÁVRH TOPOLOGIE SYSTÉMU

Zjednodušenou topologii sítě z pohledu cílových lokalit znázorňuje obrázek 3.1. paterni sit

1 Gbps 1 Gbps

lokalita 1

100 Mbps 100 Mbps

100 Mbps 100 Mbps

lokalita 2

lokalita 3

Obrázek 3.1: Topologie sítě z pohledu cílových lokalit

Propojení páteřní sítě s lokalitou 1 je realizováno optickým spojem o kapacitě 1 Gbps, jehož běžné vytížení v průběhu dne zachycuje graf 3.2. Z něj je patrné, že spoj je i ve večerní špičce vytížen přibližně pouze z 10 %, což znamená, že volná kapacita je skoro 900 Mbps. 150 M 125 M 100 M 75 M 50 M 25 M 0

Apr 24

12:00

GigabitEthernet1/0/23 (10123) @ sw-dru3br tx

Apr 25

12:00

GigabitEthernet1/0/23 (10123) @ sw-dru3br rx

Obrázek 3.2: Zatížení spoje mezi páteřní sítí a cílovou lokalitou 1

3.2. ANALÝZA SÍTĚ

7

V případě propojení páteřní sítě s lokalitou 2 se jedná o bezdrátový spoj na frekvenci 10 GHz. Jeho běžné zatížení v průběhu dne je na grafu 3.3, ze kterého je vidět, že zbývající volná kapacita v době večerní špičky je přibližně 40 Mbps. 80 Mbit/s

60 Mbit/s

40 Mbit/s

20 Mbit/s

0bit/s

Apr 22

12:00

FastEthernet0/20 (20) @ sw-pio1br tx

Apr 23

12:00

FastEthernet0/20 (20) @ sw-pio1br rx


Síť v lokalitě 3 byla vybudována teprve v roce 2010 a stále se rozrůstá, čemuž odpovídá i vzrůstající zatížení optického spoje, který ji spojuje s páteřní sítí. Ten je v současné době omezen na rychlost 100 Mbps, ale v nejbližší době je plánováno navýšení jeho kapacity. Jeho aktuální zatížení zobrazuje graf 3.4, ze kterého vyplývá, že volná kapacita spoje ve špičce je přibližně 20 Mbps. 100 Mbit/s

80 Mbit/s

60 Mbit/s

40 Mbit/s

20 Mbit/s

0bit/s

Apr 22

FastEthernet0/10 (10) @ sw-pio1br tx

12:00

Apr 23

12:00

FastEthernet0/10 (10) @ sw-pio1br rx


8


Všechny cílové lokality v tarifní skupině NaOptice[12] jsou velká sídliště tvořená panelovými domy. Topologie sítě v prvních dvou lokalitách je podobná. Ve středu je router s operačním systémem RouterOS a switch řady Cisco Catalyst s 1 Gbps porty a z něj optické vedení do jednotlivých domů. V jednotlivých domech jsou pak už jen jednoduché 100 Mbps switche bez managementu (v některých případech i několik za sebou), ke kterým se připojují koncoví uživatelé prostřednictvím UTP kabelů rychlostí 100 Mbps. Zjednodušenou topologii sítě v prvních dvou lokalitách ukazuje obrázek 3.5. router cpu(%): 28, 22 29d 04:59:25.00

1 Gbps 1 Gbps

switch WS-C2950T-24 140d 19:45:17.55

1 Gbps 1 Gbps

switch

100 Mbps 100 Mbps

user 1

100 Mbps 100 Mbps

user 2

100 Mbps 100 Mbps

switch

100 Mbps 100 Mbps

100 Mbps 100 Mbps

user 3

Obrázek 3.5: Topologie sítě v cílových lokalitách 1 a 2

user 4

3.2. ANALÝZA SÍTĚ

9

Ve třetí lokalitě, jejíž výstavba proběhla o několik let později, jsou již všechny switche s managementem a topologie je typu hvězda. Rozdíl proti prvním dvěma lokalitám je patrný z obrázku 3.6. router cpu(%): 20, 20 116d 02:03:05.00

1 Gbps 1 Gbps

switch MS400870M 114d 23:30:51.95

1 Gbps 1 Gbps

switch WS-C2950T-24 62d 15:10:16.87

100 Mbps 100 Mbps

user 1

100 Mbps 100 Mbps

user 2

1 Gbps 1 Gbps

switch 065-7726S 51d 21:03:39.21

100 Mbps 100 Mbps

user 3

Obrázek 3.6: Topologie sítě v cílové lokalitě 3

100 Mbps 100 Mbps

user 4

10


3.3

Požadavky na umístění hlavního serveru

Server je nutné umístit tak, aby bylo v jeho blízkosti možné namontovat antény pro příjem signálu. To znamená najít přístupový bod sítě, který je blízko střechy s dostatečným místem pro stožár na umístění antény DVB-T a parabolické antény DVB-S, má zálohované napájení a je buď přímo součástí páteřní sítě, nebo je k ní připojen optickým spojem přes minimální počet mezistupňů (switchů a routerů), aby se zajistila nejvyšší možná dostupnost služby.

3.4

Návrh topologie systému

V úvahu připadají 2 možnosti, jak pokrýt požadované oblasti. 1. Vybudovat samostatný server pro příjem signálu v každé ze 3 cílových lokalit. 2. Zvolit nejlepší umístění pro jediný hlavní přijímací server a z něj data přenášet do cílových lokalit prostřednictvím datových spojů popsaných výše. S ohledem na výše zmíněné požadavky na umístění hlavního serveru, které splňuje jen několik přístupových bodů sítě, na očekávané nízké vytížení služby a na volnou kapacitu spojů mezi cílovými lokalitami a páteřní sítí, která je buď dostatečná, nebo je plánováno její brzké navýšení, upřesnil zadavatel požadavky na systém volbou 2. varianty. Pro umístění jediného přijímacího serveru zvolil přístupový bod, který se nachází v oblasti páteřní sítě. Při výběru byla zohledněna ještě další kritéria, např. náklady na zřízení serveru spojené s nákupem hardwaru (digitální tunery a antény), předpokládané provozní náklady na údržbu serveru a antén a možnost priorizovat krátkodobě provoz televize na případně přetížených spojích na úkor rychlosti stahování.

3.5

Metody přenosu datového proudu

Nejefektivnější způsob přenosu datového proudu z hlavního serveru do cílových lokalit a dál v cílových lokalitách ke koncovým zákazníkům z hlediska optimálního využití přenosových linek a nejmenší zátěže serveru (nejlepší škálovatelnosti) je tzv. IP multicasting.

3.5.1

IP multicasting

IP multicasting je metoda směrování IP datagramů (UDP paketů) skupině příjemců. Byla navržena jako doplněk ke směrování typu unicasting a broadcasting v IP sítích verze 4, protože ty nejsou vhodné pro některé typy nových aplikací, především pro vysílání multimediálního obsahu skupině příjemců.

3.5. METODY PŘENOSU DATOVÉHO PROUDU

11

Problémem směrování typu unicasting je, že je potřeba stejná data odeslat každému příjemci zvlášť, což způsobuje zbytečné vytížení zdroje dat a především přenosových cest, pokud má více příjemců část cesty společnou. Příklad směrování typu unicast v cílové lokalitě 1 ukazuje obrázek 3.7. Typický datový tok jednoho televizního kanálu v rozlišení SD je průměrně 4 Mbps, obrázek tedy znázorňuje situaci, kdy uživatelé 2, 3 a 4 chtějí všichni sledovat stejný TV program. Červená barva označuje části sítě, kterými protéká stejný datový tok několikrát duplikovaný a vytížení tedy není optimální. router cpu(%): 12, 34 30d 08:31:59.00

12 Mbps 0 Mbps

switch WS-C2950T-24 141d 23:17:53.26

12 Mbps 0 Mbps

switch

0 Mbps 0 Mbps

user 1

4 Mbps 0 Mbps

user 2

8 Mbps 0 Mbps

switch

4 Mbps 0 Mbps

4 Mbps 0 Mbps

user 3

Obrázek 3.7: Ukázka vytížení cílové sítě při směrování typu unicasting

user 4

12


Duplikování datového toku lze předejít použitím směrování typu broadcasting, které posílá každý paket všem stanicím, z toho ale plyne ještě větší problém. Situaci při použití směrování broadcasting zachycuje obrázek 3.8. Z něj je patrné, že při počtu 10 nabízených televizních programů bude každým místem v síti nepřetržitě procházet datový tok 40 Mbps, případně ještě větší, pokud dojde k rozšíření nabídky programů. Navíc data přicházejí i k uživatelům, kteří službu MX-TV vůbec nepoužívají. Směrování typu broadcasting je tedy nepřijatelné. router cpu(%): 17, 7 30d 08:53:47.00

40 Mbps 0 Mbps

switch WS-C2950T-24 141d 23:39:36.52

40 Mbps 0 Mbps

switch

40 Mbps 0 Mbps

user 1

40 Mbps 0 Mbps

user 2

40 Mbps 0 Mbps

switch

40 Mbps 0 Mbps

40 Mbps 0 Mbps

user 3

Obrázek 3.8: Ukázka vytížení cílové sítě při směrování typu broadcasting

user 4

3.5. METODY PŘENOSU DATOVÉHO PROUDU

13

Směrování multicasting spojuje výhody obou předchozích, data neduplikuje, ale posílá je pouze stanicím, které si o ně požádají, takže využití sítě je optimální. Ukázka situace, kdy uživatelé 2, 3 a 4 přijímají stejný TV program při směrování multicasting, je na obrázku 3.9. router cpu(%): 20, 17 30d 08:57:51.00

4 Mbps 0 Mbps

switch WS-C2950T-24 141d 23:43:52.87

4 Mbps 0 Mbps

switch

0 Mbps 0 Mbps

user 1

4 Mbps 0 Mbps

user 2

4 Mbps 0 Mbps

switch

4 Mbps 0 Mbps

4 Mbps 0 Mbps

user 3

Obrázek 3.9: Ukázka vytížení cílové sítě při směrování typu multicasting

user 4

14


Standard IP multicasting je definován v celé řadě dokumentů RFC[2]. Základní princip je, že datovému toku je přidělena tzv. multicastová IP adresa. K tomuto účelu je vyhrazen blok IP adres od 224.0.0.0 do 239.255.255.255. Zjednodušené rozdělení adres je následující[8]: • rezervované adresy (224.0.0.0 – 224.0.0.255) - rezervované pro směrovací protokoly a správu skupin • adresy s limitovaným rozsahem (239.0.0.0 - 239.255.255.255) - adresy určené pro provoz ve vnitřních sítích • veřejné adresy - ostatní multicastové adresy Televizní vysílání v síti společnosti MX-NET Telekomunikace s.r.o. by tedy mělo využívat adresy z rozsahu 239.0.0.0 - 239.255.255.255. Pro řízení datového toku při multicastovém směrování se v koncových sítích využívá protokol IGMP[2]. Stručný popis fungování: 1. Stanice, která chce dostávat data z multicastové skupiny, pošle IGMP join zprávu s adresou skupiny. 2. Tuto IGMP zpávu odposlechne nejbližší switch (tzv. IGMP snooping), přidá příchozí port do své tabulky multicastových klientů a začne stanici posílat pakety, které mají jako cílovou IP adresu příslušnou multicastovou skupinu. 3. Záznam v tabulce na switchi má nastavenou platnost po omezený čas (typicky několik minut). Pokud do vypršení času nepřijde z příslušného portu obnovující IGMP zpráva, je z tabulky odstraněn a data se na něj přestanou posílat. 4. Mechanismus obnovování členství ve skupinách zařizuje tzv. IGMP querier. Ten pravidelně posílá IGMP query zprávy, na které jsou klienti nuceni odpovědět obnovovací IGMP zprávou. Switche, které funkci IGMP snooping nemají, se k multicastem posílaným datům chovají, jako by byly posílány broadcastem. To vyplývá ze skutečnosti, že multicastová data se na spojové vrstvě posílají na adresy začínající 01:00:5e, přičemž 01 na začátku obsahuje tzv. broadcast bit.

3.6. NAVRHOVANÉ ŘEŠENÍ

15

Z toho vyplývají 2 požadavky na síť společnosti MX-NET Telekomunikace s.r.o., aby bylo možné použít IP multicasting: 1. Některé ze zařízení musí plnit funkci IGMP querier. 2. Všechny switche mezi zdrojem vysílání (nebo multicastovým routerem) a cílovou stanicí musí podporovat IGMP snooping.

3.6

Navrhované řešení

První z požadavků na použití IP multicastingu lze v případě, že funkci IGMP querier nebude podporovat žádný ze switchů, splnit instalováním softwarového řešení přímo na server, který bude zdrojem vysílání. Druhý požadavek ale splněn není a nelze ho splnit bez nákladné úpravy sítě a výměny switchů za takové, které podporují funkci IGMP snooping. Pouze síť v lokalitě 3 požadavek splňuje alespoň teoreticky, ale i tam se vyskytují switche, u nichž je známo, že v praxi mají s funkcí IGMP snooping problémy (jsou nestabilní a nespolehlivé). Další problém představují domácí routery klientů, které také ve většině případů multicasting nepodorují. IP multicasting tedy v tuto chvíli v síti společnosti MX-NET Telekomunikace s.r.o. použít nelze. Je nutné systém navrhnout tak, aby multicasting podporoval a umožnil na něj v budoucnu plynule přejít, ale prozatím musí být hlavním způsobem přenosu dat vysílání typu unicast, což přináší několik problémů. Jednak vyšší zatížení hlavního serveru a jeho odchozího spojení se sítí, protože musí každý sledovaný pořad odesílat zvlášť každému klientovi, který ho sleduje, ale především vyšší zatížení spojů s omezenou kapacitou mezi jednotlivými lokalitami. Z technických důvodů popsaných dříve nelze v každé z cílových lokalit postavit vlastní hlavní server, je ale možné do nich alespoň umístit tzv. re-streamovací servery, a tím částečně kompenzovat problémy způsobené použitím unicastu. Tyto servery se budou chovat tak, že při připojení prvního klienta k programu 1 začnou stahovat program 1 z hlavního serveru a přeposílat mu ho, ale pro každého dalšího klienta už budou pouze příchozí data duplikovat a nebudou tak více zatěžovat hlavní server ani kritické spojení s páteřní sítí. Jediným požadavkem na hardware re-streamovacích serverů je dostatečně rychlé propojení s centrálním switchem v cílové lokalitě (nejlépe 1 Gbps), což umožňuje velkou flexibilitu při jejich návrhu. Lze například použít starší hardware vyřazený odjinud, nebo naopak postavit nový server s ohledem na parametry cílové lokality (rozměry a příkon).

16


headend cpu(%): 44, 41 71d 10:47:29.48

4 Mbps 0 Mbps

switch WS-C2950T-24 255d 04:05:06.34

4 Mbps 0 Mbps

router cpu(%): 13, 9 31d 04:02:42.00

4 Mbps 0 Mbps

switch WS-C2950T-24 142d 18:48:41.01

re-streamer cpu(%): 4 141d 13:52:26.75

4 Mbps 12 Mbps

12 Mbps 0 Mbps

switch

0 Mbps 0 Mbps

user 1

4 Mbps 0 Mbps

user 2

8 Mbps 0 Mbps

switch

4 Mbps 0 Mbps

user 3

4 Mbps 0 Mbps

user 4

Obrázek 3.10: Ukázka topologie navrhovaného systému s re-streamovacím serverem

3.6. NAVRHOVANÉ ŘEŠENÍ

17

Na obrázku 3.10 je navrhovaná topologie celého IPTV systému v cílové lokalitě 1 s restreamovacím serverem znovu v situaci, kdy uživatelé 2, 3 a 4 přijímají stejný TV program. Je vidět, že kritický spoj mezi páteřní sítí a cílovou lokalitou (označený modrou barvou) je vytížený stejně jako při směrování typu multicasting, tedy optimálně. Výhodou použití směrování typu unicast je možnost datový tok přenášet protokolem TCP místo UDP, které by bylo nutné používat v případě multicastového směrování. To jednak zaručuje doručení všech odeslaných dat, a tedy bezztrátovost spojení, ale hlavně v kombinaci s bufferem (vyrovnávací pamětí) vyrovná špičky v přenášeném datovém proudu. Běžný televizní pořad totiž nemá konstantní datový tok 4 Mbps, velikost přenášených dat reálně kolísá přibližně od 2 Mbps do 8 Mbps. Obecně se dá říct, že čím více je v obrazu pohybu, tím je aktuální datový tok vyšší. Při přenášení takového datového toku spojem s volnou kapacitou 4 Mbps protokolem TCP se při špičce data pozdrží a se zpožděním doručí do vyrovnávací paměti, takže nedojde k žádné ztrátě, zatímco při použití protokolu UDP se při špičce data, která se do volné kapacity spoje nevejdou, ztratí, což se projeví tzv. kostičkováním obrazu. U protokolu TCP lze tedy reálně počítat s potřebnou kapacitou 4 Mbps na jeden TV program. Ideální protokol pro službu IPTV na aplikační vrstvě (využívající transportní protokol TCP) je protokol HTTP. Minimalizuje výskyt problémů na straně klienta spojených s nastavením firewallu a je široce podporován jak softwarovými video přehrávači, tak IPTV set-top boxy. Navrhovaná simulace předpokládaného zatížení sítě a jednotlivých serverů by neposkytla relevantní výsledky, protože nejsou k dispozici žádné údaje o budoucím počtu uživatelů v jednotlivých cílových lokalitách, o předpokládané četnosti jejich využívání služby, ani není známa konkrétní implementace hlavního serveru a re-streamerů, aby bylo možné odhadovat, jaké zatížení jim jednotliví klienti způsobí. Navíc je nutné při návrhu počítat vždy s nejhorším případem, tedy se situací, kdy budou službu využívat všichni uživatelé současně, a pro tento případ je možné zatížení sitě v každém místě stanovit jednoduchým výpočtem. Problémy se zatížením sítě v cílových lokalitách se nepředpokládají, protože většina spojů v nich má kapacitu 1 Gbps. Nejproblematičtějším místem tedy budou spoje mezi cílovými lokalitami a páteřní sítí. V teoretickém nejhorším případě, kdy se v 1 cílové lokalitě připojí ke každému z 10 nabízených programů alespoň jeden uživatel, bude zatížení spoje 40 Mbps, což by měly všechny 3 spoje krátkodobě zvládnout. K takové situaci by navíc mělo docházet vzácně, protože obvykle (především ve večerní špičce) naláká většinu diváků několik nejsledovanějších pořadů. V budoucnu se může teoretická nejvyšší zátěž spojů zvýšit, pokud dojde k rozšíření programové nabídky, v takovém případě by ale provozovatel byl schopen zajistit zvýšení kapacity spojů.

18


Kapitola 4

Návrh hardware 4.1

Server pro příjem signálu

Server pro příjem signálu bude umístěn v technické místnosti pod střechou na páteřní síti. Rack, do kterého má být namontován, obsahuje kromě standardních pozic pro 1900 zařízení formátu xU1 i police pro umístění počítačů formátu ATX. Server je tedy možné navrhnout ve formátu ATX, což je výhodnější z hlediska pořizovacích nákladů.

4.1.1

Hardwarová konfigurace

Protože nejsou kladeny žádné specifické požadavky, bude základem hlavního serveru běžný počítač x86 formátu ATX s následující konfigurací: • CPU Intel Core2 Duo E7500 • 2 GB RAM • 32 GB SSD • 1 Gbps NIC • 5x PCI a 8x USB 2.0 Konkrétní konfigurace byla zvolena s ohledem na cenu a na aktuální nabídku v době nákupu. 1

U nebo také RU (rack unit) je jednotka používaná pro označení výšky zařízení určeného pro montáž do 1900 a 2300 racků.

19

20

KAPITOLA 4. NÁVRH HARDWARE

4.1.2

DVB tunery

Server má být schopen přijímat jak pozemní vysílání standardu DVB-T, tak satelitní vysílání standardu DVB-S. V době vývoje projektu IPTV ještě nebylo zahájeno pozemní digitální vysílání z vysílače Praděd, proto musely být dočasně i programy, které budou jeho prostřednictvím k dispozici, přijímány ze satelitu. Později se plánuje využít satelitní tunery pro příjem dalších programů, které se na DVB-T vysílat nebudou. V budoucnu se pak plánuje i příjem základních programů v rozlišení HD. Na pokrytí základní programové nabídky ze satelitu Astra 3A, tedy pro příjem 10 tzv. FTA (free-to-air) programů, byly v době návrhu potřeba 4 DVB-S tunery2 . Vysílání z Pradědu se pak plánuje na 3 multiplexech, což znamená potřebu 3 tunerů DVB-T. Server má k dispozici celkem 5 slotů pro rozšiřující karty PCI a 8 portů USB 2.0. Vzhledem k výrazně vyšší ceně USB tunerů DVB-S ve srovnání s USB tunery DVB-T jsem zvolil využít PCI sloty pro tunery DVB-S a tunery DVB-T připojit přes sběrnici USB. Jakmile bude služba v provozu, bude případné rozšiřování počtu PCI tunerů kvůli nutnému výpadku problematické, proto se zadavatel rozhodl využít rovnou všech 5 PCI slotů a získat tak do budoucna maximální možnou flexibilitu při výběru zdroje signálu. Celkem bude tedy server osazen 2 PCI tunery DVB-S2 pro příjem HD kanálů, 3 PCI tunery DVB-S a 3 USB tunery DVB-T:

• 2x TT-budget S2-3200 [18] • 3x GIGABYTE GT-PS700 [17] • 3x Genius TVGo DVB-T03 [19]

4.1.3

Antény

Signál pro všech 8 tunerů zajišťují 2 antény, které byly instalovány na střeše budovy. Jedna je běžná televizní anténa pro příjem signálu DVB-T z vysílače Praděd opatřená kanálovou propustí a rozbočovačem a druhá je satelitní parabola o průměru 80 cm s Inverto Black Pro Octo LNB pro až 8 satelitních přijímačů, která zajišťuje signál DVB-S z družice Astra 3A. Od antén jsou vedeny koaxiální kabely s impedancí 50 Ω až do racku s hlavním serverem, který se nachází v místnosti pod střechou. 2

Provozovatel satelitního vysílání spolu se změnami programové nabídky mění i rozložení programů na jednotlivých transpondérech. V tuto chvíli už by k pokrytí stejných programů stačily 3 DVB-S tunery.

4.2. RE-STREAMOVACÍ SERVER

4.1.4

21

Čtečka karet

Čtečka karet bude nutná pro dočasné dekódování programů základní nabídky před spuštěním vysílání DVB-T z Pradědu a v budoucnu pro dekódování programů v rozlišení HD. Výběr vhodné univerzální čtečky karet, kterou bude po vyřízení potřebných povolení od provozovatele satelitního vysílání možné použít v kombinaci s kartou systému Cryptoworks nebo Irdeto, jsem omezil na čtečky určené pro sběrnici USB. Ideálním řešením, které navíc nevyžaduje externí napájení, je čtečka SmarGo SmartReaderPlus.

4.2

Re-streamovací server

Návrh počítá s celkem 3 re-streamovacími servery umístěnými v centru každé z cílových lokalit. Požadavky na jejich hardware nejsou nijak specifické, proto bude ve 2 případech použit starší hardware s CPU Intel Celeron 2,4 GHz a v jednom případě nové PC na platformě Intel Atom D525 kvůli malým rozměrům a nízké spotřebě. Všechny budou vybaveny síťovou kartou s rychlostí 1 Gbps, aby se předešlo případným problémům s propustností spojů mezi nimi a centrálními switchi v příslušných lokalitách.

4.3

Set-top box

Set-top boxy s podporou IPTV se v maloobchodním prodeji téměř nevyskytují, protože služba IPTV není standardizovaná. Běžně se prodávají pouze velkoobchodně při uzavření smlouvy na odběr velkého množství kusů s tím, že výrobce poskytne SDK, aby si provozovatel mohl upravit software pro svoji IPTV službu. Tento obchodní model není pro službu MX-TV vhodný, protože není zaručen zájem o dostatečný počet kusů. Je tedy potřeba najít hardware pro set-top box, který bude dostupný maloobchodně a jeho software bude možné alespoň částečně upravit. Nejvhodnějším zařízením v cenové hladině do 1500,- Kč s DPH je multimediální přehrávač PBO Core[15] od společnosti Patriot.

22

KAPITOLA 4. NÁVRH HARDWARE

Kapitola 5

Výběr software 5.1


Server pro příjem signálu má plnit tyto základní funkce: • příjem signálu • dekódování • streamování (unicast i multicast) • IGMP querier

5.1.1

Operační systém

Vzhledem k tomu, že má být celá služba IPTV postavena na tzv. otevřeném software, je prakticky jedinou možnou volbou operační systém založený na jádru GNU/Linux[7]. Operačních systémů s otevřeným zdrojovým kódem existuje sice kromě Linuxu celá řada (např. různé varianty BSD), ale Linux z nich má jednoznačně nejrozšířenější podporu DVB hardwaru. Z velkého množství distribucí jsem zvolil Gentoo Linux[3], jednak proto, že už s ním mám zkušenosti, ale hlavně proto, že je celá distribuce kompilována ze zdrojových kódů až při instalování, takže se v ní snadněji provádějí případné úpravy.

23

24

KAPITOLA 5. VÝBĚR SOFTWARE

5.1.2

Příjem signálu a streamování

Programů, které umí ovládat DVB tunery a posílat přijímaný datový proud do sítě a které mají otevřený zdrojový kód, existuje několik. Já jsem vyzkoušel 4, které se v souvislosti se streamováním objevují nejčastěji, a všechny splňují základní předpoklady, tzn. podporují příjem signálu DVB-T i DVB-S a jsou schopné celý přijímaný multiplex nebo transpondér posílat do sítě: • VideoLAN Client (VLC)[23] • The Video Disk Recorder (VDR)[20] • Getstream 2 [5] • MuMuDVB[11] 5.1.2.1

VideoLAN Client

VideoLAN Client je aplikace určená původně především pro přehrávání videa, která se postupně rozrostla o podporu příjmu signálu z nejrůznějších zdrojů a o podporu vysílání videa přes síť. Sice velmi dobře zvládá streamování UDP multicastem i HTTP unicastem, ale pro použití na hlavním serveru trpí několika nedostatky. Prvním je vysoká náročnost na procesor a paměť ve srovnání s ostatními testovanými aplikacemi, i přestože jsem využil možností Gentoo Linuxu a zkompiloval jsem VLC bez podpory grafického rozhraní. Zásadním problémem pak je, že VLC nepodporuje dekódování satelitních programů bez hardwarového CI modulu. Ten není součástí návrhu hardware a navíc nedokáže dekódovat více kanálů současně. Na základě toho jsem musel aplikaci VLC z použití na headendu vyloučit. 5.1.2.2

The Video Disk Recorder

The Video Disk Recorder je modulární aplikace. Její jádro poskytuje jen základní funkce pro chytré ovládání DVB tunerů a přijímaný program pak buď nahrává, nebo předá výstupním modulům. V kombinaci s modulem streamdev[22], který přidává podporu pro multicastové (UDP) i unicastové (HTTP) streamování, lze tedy sestavit kompaktní řešení pro streamovací server. Z hlediska náročnosti na procesor a paměť je na tom VDR podstatně lépe než VLC, ale má jiné nedostatky. Podporu softwarového dekódování přidává modul vdr-sc, který není oficiálně podporován a nemá ani stálou domovskou stránku. Závažnější problém pak představuje způsob, jakým VDR spravuje DVB zařízení. Nelze nastavit, který tuner má přijímat

5.1. SERVER PRO PŘÍJEM SIGNÁLU

25

které programy, výběr vhodného zařízení se provádí dynamicky. To může značně komplikovat diagnostiku problémů se signálem konkrétního tuneru (rušení, poškozený kabel a pod.). Stejně tak je z hlediska údržby serveru problematická i nemožnost dočasně uvolnit jednotlivé tunery, aniž by bylo nutné způsobit výpadek celé služby. Ty je potřeba při občasném měření kvality signálu (například při podezření na vychýlení paraboly nárazy větru) nebo vyhledávání změněných programů zpřístupnit externím aplikacím, protože samotné VDR informace o signálu neposkytuje. 5.1.2.3

Getstream 2

Getstream 2 je minimalistická aplikace navržená pro streamovací server. Tomu odpovídají i minimální nároky na výkon procesoru a velikost paměti. Podporuje oba požadované způsoby streamování a netrpí ani problémem s flexibilitou správy jednotlivých tunerů jako VDR, protože se konfiguruje a provozuje vždy samostatná instance aplikace pro každé DVB zařízení. Problémem ale je, že nepodporuje softwarové dekódování, takže ji lze použít jen na streamování nekódovaných programů. 5.1.2.4

MuMuDVB

MuMuDVB je aplikace velmi podobná aplikaci Getstream 2. Má téměř totožné vlastnosti a z hlediska uživatele se liší jen drodnými rozdíly v syntaxi konfiguračního souboru. Sama o sobě také nepodporuje softwarové dekódování, ale nabízí možnost softwarového dekódování v kombinaci s externí aplikací Open-SASC-NG[13]. Tuto variantu jsem tedy zvolil.

5.1.3

Čtečka karet

Aplikace Open-SASC-NG, kterou jsem v předchozí části vybral pro softwarové dekódování, sice umí přistupovat ke čtečce karet přímo, ale nabízí i možnost připojení přes tzv. card server. Výhoda použití card serveru spočívá v lepším dohledu nad stavem karty a snadnější diagnóze případných problémů. Aplikací, které umožňují kartu spravovat a poskytují k ní přístup, je několik, ale v poslední době mají tendenci konvergovat do jednoho společného projektu s otevřeným kódem. Tento projekt se jmenuje OSCam[14] a nabízí všechny potřebné funkce.

26


5.2


Účelem re-streamovacích serverů je kompenzovat zátěž spojů mezi páteřní sítí a cílovými lokalitami způsobenou použitím směrování unicast na úkor směrování multicast, jak ukazuje obrázek 3.10. Aby toho bylo docíleno, musí re-streamovací servery splnit následující požadavky: 1. Zajistit, aby kritickým spojem žádný program nikdy neprocházel více než jednou. V případě, že chce program v dané lokalitě sledovat více uživatelů, je tedy třeba příchozí data duplikovat. 2. Přijímat příslušný program z hlavního serveru pouze tehdy, kdy ho někdo z uživatelů v dané lokalitě sleduje, aby bylo zajištěno optimální vytížení sítě. Základním požadavkem na aplikaci je, aby vůbec umožňovala příjem HTTP streamu a jeho vysílání zpět do sítě. Vzhledem k plánovanému postupnému přechodu na multicast by bylo výhodou, kdyby umožňovala i příjem a vysílání multicastem. To splňují následující 2 aplikace: • VideoLAN Client (VLC)[23] • The Video Disk Recorder (VDR)[20]

5.2.1

VideoLAN Client

VideoLAN Client umožňuje libovolnou kombinaci příjmu a vysílání streamů HTTP i UDP multicast, a to ve 2 režimech: • broadcast • vod (Video On Demand) V režimu broadcast se VLC připojí ke zdrojovému programu a podle potřeby ho přeposílá libovolnému počtu klientů, čímž splňuje požadavek na duplikování dat. Problém ale je, že je ke zdrojovému streamu připojeno i v době, kdy se na něj nikdo nedívá. Pro účely re-streameru by tedy VLC v režimu broadcast použít sice šlo, ale z hlediska vytížení kritického spoje by se systém choval stále jako v nejhorším případě, kdy je každý kanál sledován alespoň jedním divákem. V režimu vod se VLC chová obráceně. Pokud se nepřipojí žádný klient, nestahuje stream z hlavního serveru a nevytěžuje tak spoj s páteřní sítí, ale pokud se připojí několik klientů, vytvoří pro každého vlastní příchozí stream z hlavního serveru a re-streamer tak ztrácí smysl. V tomto režimu je tedy VLC jako re-streamer nepoužitelné.

5.3. KLIENT

5.2.2

27


The Video Disk Recorder umožňuje standardně příjem signálu pouze z DVB zařízení. Existuje ale rozšiřující modul vdr-iptv[21], který implementuje virtuální DVB zařízení schopné přijímat HTTP a UDP multicast stream. Teoreticky je tedy možné v kombinaci s modulem streamdev[22] získat aplikaci s požadovanými vlastnostmi.

5.3

Klient

Koncový uživatel si může samozřejmě zvolit libovolný software, ale je dobré mít alespoň jednu aplikaci otestovanou a poskytovat k ní případnou základní technickou podporu formou návodu na instalaci umístěném na webových stránkách. Ideální volbou je v tomto případě aplikace VideoLAN Client[23], která je dostupná na všech hlavních platformách, podporuje oba plánované typy vysílání a má přehledné uživatelské rozhraní s playlistem.

28


Kapitola 6

Realizace 6.1


Server pro příjem signálu je základem celého systému, proto se stavěl a uváděl do provozu jako první.

6.1.1

Operační systém

Instalace operačního systému Gentoo Linux proběhla standardním způsobem z tzv. live CD a dočasně připojené externí CD mechaniky. Postupoval jsem podle návodu z dokumnetace[4] s výjimkou tvorby swap oddílu. Tu jsem záměrně vynechal, protože instalovaný disk je SSD s omezeným počtem zápisů, a proto není pro swap oddíl vhodný. Jeho absence by ale neměla být problém, protože systém má dostatek operační paměti. Důležitá je konfigurace jádra. Vycházel jsem z univerzální konfigurace (tzv. genkernelu), který je automaticky nainstalován z live CD, ten jsem následně aktualizoval na verzi 2.6.31gentoo-r10 a optimalizoval pro konkrétní hardware (výsledný konfigurační soubor je k dispozici v příloze). Odstranil jsem všechny nepotřebné ovladače zařízení, z init-ramdisku jsem odebral všechny moduly kromě ahci, který je potřebný pro integrovaný SATA řadič, a zkontroloval jsem, že je zapnuta podpora pro V4L2 a DVB (v4l2_common a dvb_core). Následovalo zprovoznění sítě a základních služeb pro vzdálený přístup a dohled (sshd a snmpd), čímž byla instalace operačního systému dokončena. Výsledný minimalistický systém startuje za méně než 20 vteřin, čož je výhoda v případě nutného restartu.

29

30

KAPITOLA 6. REALIZACE

6.1.2 6.1.2.1

DVB tunery TT-budget S2-3200

Karta TT-budget S2-3200 je založena na čipu Philips SAA7146, což jsem si ověřil identifikací ve výpisu PCI zařízení.

tv-pio1 ~ # lspci | grep "SAA7146" 05:03.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 05:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) tv-pio1 ~ #

Ovladač pro karty s čipem Philips SAA7146 je součástí upstream jádra, takže zprovoznění spočívá pouze v povolení příslušných modulů (saa7146 a budget_core). Správnou inicializaci karet lze ověřit ve výpisu jádra (dmesg) nebo kontrolou, jestli se v adresáři /dev/dvb/ vytvořily odkazy na adapter0 a adapter1.

6.1.2.2

GIGABYTE GT-PS700

tv-pio1 ~ # lspci | grep "SAA7130" 05:00.0 Multimedia controller: Philips Semiconductors SAA7130 (rev 01) 05:01.0 Multimedia controller: Philips Semiconductors SAA7130 (rev 01) 05:02.0 Multimedia controller: Philips Semiconductors SAA7130 (rev 01) tv-pio1 ~ #

V případě GIGABYTE GT-PS700 je situace o něco složitější. Čip Philips SAA7130, na kterém je postavena, sice podporu v upstream kernelu má, ale karta postrádá eeprom paměť s identifikačními údaji, takže ovladač (saa7134 ) není po povolení v jádře schopen kartu správně rozpoznat. To se projeví tak, že nejsou vytvořeny odkazy v /dev/dvb/ a ve výpisu z jádra se objeví zpráva:

saa7134: Congratulations! Your TV card vendor saved a few saa7134: cents for a eeprom, thus your pci board has no saa7134: subsystem ID and I can’t identify it automatically. saa7134: I feel better now. Ok, here are the good news: saa7134: You can use the card= insmod option to specify saa7134: which board do you have. The list:


31

Následuje seznam s přibližně 180 podporovanými modely, ale GIGABYTE GT-PS700 v něm není. Lze dohledat, že karty LifeView FlyDVB-S a Acorp TV134DS, které jsou v seznamu uvedeny pod číslem 97, jsou s modelem GIGABYTE GT-PS700 kompatibilní, takže při ručním specifikování parametru card=97 při načítání modulu saa7134 se karta inicializuje správně. Parametr je potřeba zadat třikrát, aby se správně inicializovaly všechny nainstalované karty. To jsem následně zautomatizoval uložením do souboru /etc/modules.d/saa7130. tv-pio1 ~ # cat /etc/modules.d/saa7130 alias char-major-81-0 saa7134 options saa7134 card=97,97,97 tv-pio1 ~ # 6.1.2.3

Genius TVGo DVB-T03

Tuner Genius TVGo DVB-T03 je v prodeji již delší dobu a výrobce ho stále prodává pod stejným označením, ačkoliv se jedná již o 3. různé zařízení postavené na 3. různé čipové sadě[1]. Jako první je tedy potřeba zjistit, o kterou variantu se jedná. tv-pio1 ~ # lsusb | grep "KYE" Bus 005 Device 004: ID 0458:707f KYE Systems Corp. (Mouse Systems) Bus 005 Device 003: ID 0458:707f KYE Systems Corp. (Mouse Systems) Bus 005 Device 002: ID 0458:707f KYE Systems Corp. (Mouse Systems) tv-pio1 ~ # Podle ID 0458:707f lze určit, že se jedná o variantu postavenou na čipové sadě Realtek RTL2832. Ovladač není v jádře 2.6.31-gentoo-r10 k dispozici, takže je nutné stáhnout ho z externího zdroje[6]. Instalace proběhla standardním způsobem a po zavedení modulu (dvb_usb_rtl2832u) byly všechny 3 tunery úspěšně inicializovány. usb 5-2: new high speed USB device using ehci_hcd and address 2 usb 5-2: configuration #1 chosen from 1 choice dvb-usb: found a ’DVB-T TV Stick’ in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software... DVB: registering new adapter (DVB-T TV Stick) DVB: registering adapter 0 frontend 0 (Realtek DVB-T RTL2832)... dvb-usb: schedule remote query interval to 286 msecs. dvb-usb: DVB-T TV Stick successfully initialized and connected.

32


6.1.3

Open-SASC-NG

Open-SASC-NG je software, který implementuje tzv. CAM (conditional access module). Na rozdíl od ostatních podobných projektů se snaží být univerzální a transparentní. Princip je takový, že se Open-SASC-NG připojí ke skutečnému DVB zařízení, které přijímá zakódované programy, a vytvoří virtuální DVB zařízení, které poskytuje navíc simulovaný hardwarový CAM. Aplikace, která má data přijímat, se pak připojí k virtuálnímu DVB zařízení místo skutečného. Open-SASC-NG není součástí většiny distribucí, a proto se musí ručně přeložit ze stažených zdrojových kódů[13]. Postup instalace je běžný a nenarazil jsem při ní na žádný závažný problém. Výsledkem je modul jádra (dvbloopback), který vytváří virtuální DVB zařízení, a samotná aplikace sasc-ng. Při zavádění modulu je možné specifikovat požadovaný počet virtuálních zařízení. Aby bylo v případě potřeby možné dekódovat programy na všech skutečných satelitních tunerech, je potřeba stejný počet virtuálních. tv-pio1 ~ # modprobe dvbloopback num_adapters=5 tv-pio1 ~ # Konfigurace připojení k dekódovací kartě je standardně uložena v adresáři /etc/camfiles/. Zvolil jsem možnost připojení přes card server, jehož instalaci popíši v další části, a vytvořil jsem potřebný konfigurační soubor /etc/camfiles/cardclient.conf. tv-pio1 ~ # cat /etc/camfiles/cardclient.conf newcamd:127.0.0.1:15050:1/0d0f/0000:user:pass:0000000000000000000000002909 tv-pio1 ~ # Význam jednotlivých parametrů připojení: • newcamd - komunikační protokol • 127.0.0.1:15050 - IP adresa a port • 1/0d0f/0000 - identifikace karty a maska kanálů • user:pass - uživatelské jméno a heslo • 0000000000000000000000002909 - RSA klíč, který se použije pro šifrování spojení


33

Posledním krokem je přidání spuštění samotné aplikace sasc-ng do startovacího skriptu a definice propojení skutečných DVB zařízení s virtuálními. tv-pio1 ~ # sasc-ng -j 0:5 -j 1:6 -j 2:7 -j 3:8 -j 4:9 --daemon tv-pio1 ~ #

6.1.4

Čtečka karet

Čtečka karet SmarGo SmartReaderPlus je sériové zařízení kombinované s FTDI USB-Serial převodníkem. Její zprovoznění tedy spočívá v povolení příslušného modulu jádra (ftdi_sio). Po zavedení modulu se vytvoří odkaz na sériové zařízení /dev/ttyUSB0. Pro funkci card serveru jsem zvolil aplikaci OSCam[14], která také není součástí většiny distribucí a je nutné ji ručně přeložit ze stažených zdrojových kódů. Instalace se provádí běžným způsobem a nebyl s ní žádný problém. Důležitá je správná konfigurace čtečky karet v souboru /etc/oscam/oscam.server. tv-pio1 ~ # cat /etc/oscam/oscam.server [reader] label

= reader1

protocol

= smargo

device

= /dev/ttyUSB0

detect

= cd

mhz

= 356

cardmhz

= 356

group

= 1

tv-pio1 ~ # Zbývající část konfigurace (vytvoření uživatelského účtu, zpřístupnění newcamd serveru a nastavení stejného šifrovacího RSA klíče) je možné provést přes webové rozhraní, které ukazuje obrázek 6.1.

34


OSCAM 1.20 STATUS CONFIGURATION READERS USERS SERVICES FILES FAILBAN CACHEEX SCRIPT SHUTDOWN hide

Thread ID

Type ID

Label

AU

Crypted

Address

Port

Protocol

Login

Online

CAID:SRVID

Current Channel

LB Value/ Reader

Idle

Status

0x578160

s

0

root

127.0.0.1

0

server

08.05.12 00:02:02 14:19:31

0000:0000

00:00:00

OK

0x5f1130

h

1

root

127.0.0.1

0

http

08.05.12 00:02:02 14:19:31

0000:0000

00:00:04

OK

r

1

reader1

ON

OFF

127.0.0.1

0

smargo

08.05.12 00:02:02 14:19:31

0D0F/0000

CS Link: CT 2

c

1

sasc-ng ON

ON

127.0.0.1 15050

08.05.12 00:01:56 14:19:37

0D0F/0000

CS Link: CT 2

Readers 1/1 0x580f88

no data

00:00:01 CARDOK

Clients 1/1

2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08 2012/05/08

14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:07 14:46:08

by 00:00:09 reader1 (95ms)

OK

0 s services reloaded: 0 services freed, 2 services loaded, rejected 0 0 s userdb reloaded: 49 accounts loaded, 0 expired, 0 disabled 0 s signal handling initialized (type=sysv) 0 s 1406 service-id's loaded in 23ms 0 s 22 provid's loaded 0 s 0 lengths for caid guessing loaded 0 s Starting listener 0 0 s monitor: initialized (fd=8, port=988) 0 s Starting listener 0 0 s camd35: disabled 0 s Starting listener 0 0 s cs378x: disabled 0 s Starting listener 0 0 s newcamd: initialized (fd=9, port=15000, crypted) 0 s -> CAID: 0D0F PROVID: 000004, 000008, 00000C, 000010 0 s Starting listener 0 0 s pandora: disabled 0 s Starting listener 0 0 s csp: disabled 0 s Starting listener 0 0 s radegast: disabled 0 s starting thread http 0 s http thread started 0 s starting thread reader check 0 s reader check thread started 0 s starting thread check 0 s check thread started 5F1370 h HTTP Server listening on port 8888 580F60 r reader1 card detected Switch Debug from 0 to 0 1 2 4 8 16 32 64 128 255

OSCAM Webinterface developed by Streamboard Team - 08.05.12 14:21:33 | Access from 127.0.0.1 Start: 08.05.12 - 14:19:31 | UpTime: 00:02:02 | Process ID: 8529 WebIf Style by Eneen

Obrázek 6.1: Webové rozhraní aplikace OSCam

6.1.5

MuMuDVB

Aplikace MuMuDVB je základem celého systému. Jejím úkolem je řídit příjem programů a získaná data oběma způsoby (UDP multicastem i HTTP unicastem) streamovat do sítě. Stažení zdrojových kódů, jejich překlad a instalace aplikace proběhly bez problémů podle návodu[11]. Výsledkem je funkční aplikace ve verzi 1.6.1b.


35

MuMuDVB Version 1.6.1b_20101228 --- Build information --Built with CAM support. Built without transcoding support. Built with support for DVB API Version 5 (DVB-S2). --Konfigurace MuMuDVB vyžaduje znalost údajů o příslušných multiplexech a transpondérech (frequency, polarisation a symbol rate) a o vnitřní struktuře programů (program map table id a service id), které je nutné zjistit pomocí externí aplikace. K tomuto účelu jsem použil aplikaci dvbscan. tv-pio1 ~ # dvbscan -a 0 /usr/share/dvb/dvb-s/Astra-23.5E scanning /usr/share/dvb/dvb-s/Astra-23.5E using ’/dev/dvb/adapter0/frontend0’ and ’/dev/dvb/adapter0/demux0’ initial transponder 12525000 V 27500000 3 -->>> tune to: 12525:v:0:27500 DVB-S IF freq is 1925000 0x0000 0x1f41: pmt_pid 0x0400 Skylink -- CT 1 JM (running, scrambled) 0x0000 0x1f42: pmt_pid 0x0401 Skylink -- Prima family (running, scrambled) 0x0000 0x1f43: pmt_pid 0x0402 Skylink -- CT 1 (running, scrambled) 0x0000 0x1f44: pmt_pid 0x0403 Skylink -- CT 2 (running, scrambled) 0x0000 0x1f45: pmt_pid 0x0404 Skylink -- CT 1 SM (running, scrambled) 0x0000 0x1f46: pmt_pid 0x0405 Skylink -- CT 24 (running) 0x0000 0x1f47: pmt_pid 0x0406 Skylink -- CT 4 (running, scrambled) 0x0000 0x1f48: pmt_pid 0x0407 Skylink -- Noe TV (running) dumping lists (8 services) CT 1 JM:12525:v:0:27500:162:88:8001 Prima family:12525:v:0:27500:161:84:8002 CT 1:12525:v:0:27500:162:88:8003 CT 2:12525:v:0:27500:163:92:8004 CT 1 SM:12525:v:0:27500:162:88:8005 CT 24:12525:v:0:27500:165:100:8006 CT 4:12525:v:0:27500:166:102:8007 Noe TV:12525:v:0:27500:167:106:8008 Done. tv-pio1 ~ #

36


Informace o programu CT 1 SM : • frequency - 12525 MHz • polarisation - v (Vertical) • symbol rate - 27500 • program map table id - 1028 (převedeno z hexadecimálního tvaru 0x0404) • service id - 8005 (převedeno z hexadecimálního tvaru 0x1f45) Příklad konfigurace MuMuDVB pro program CT 1 SM : tv-pio1 ~ # cat iptv/mumudvb-a0.conf card=5 freq=12525 pol=v srate=27500 cam_support=1 unicast=1 port_http=8001 multicast=1 autoconfiguration=1 rewrite_sdt=1 rewrite_pat=1 sort_eit=1 dvr_buffer_size=40 ip=239.194.12.1 port=1234 name=CT 1 SM pids=1028 service_id=8005 --tv-pio1 ~ # Konfigurační soubor pokračuje nastavením ostatních kanálů, které jsou vysílány na stejném transpondéru.


37

Aplikace se spouští následujícím způsobem: tv-pio1 iptv # mumudvb -s -d -c mumudvb-a0.conf tv-pio1 iptv # Během testování se ukázalo, že za určitých okolností (pravděpodobně při přijetí poškozených dat z DVB zařízení) může v aplikaci MuMuDVB dojít k tzv. memory leaku, případně k chybě segmentation fault. Tyto chyby se vyskytují přibližně jednou za měsíc, což je vzhledem k povaze služby přijatelné, pokud bude aplikace v takových případech automaticky restartována. Vytvořil jsem tedy jednoduchý bash skript, který v těchto případech aplikaci automaticky restartuje a informaci o restartu zapíše spolu s aktuálním časem do logu. Navíc definuje limit paměti (ulimit), při jehož překročení jádro systému aplikaci ukončí. Tím je omezen vliv chybující aplikace na ostatní části systému. tv-pio1 iptv # cat iptv-a0 #!/bin/bash ulimit -v 65536 while [ 1 ]; do echo "‘date‘: starting MuMuDVB (adapter0)" >> iptv.log mumudvb -s -d -c mumudvb-a0.conf done tv-pio1 iptv # Aby bylo možné využívat informace o kvalitě signálu, které aplikace MuMuDVB vypisuje na terminál, je nutné udržet si k němu přístup. To jsem vyřešil následujícím způsobem pomocí virtuálního terminálu screen: tv-pio1 iptv # screen -dmS adapter0 ./iptv-a0 tv-pio1 iptv # Informace o signálu jednotlivých DVB zařízení lze tedy zobrazit připojením příslušného virtuálního terminálu: tv-pio1 iptv # screen -r adapter0 tv-pio1 iptv #

38


6.1.6

MRouteD

Po zahájení multicastového vysílání z aplikace MuMuDVB se podle očekávání projevila absence zařízení s funkcí IGMP querier v síti. Switch Cisco Catalyst WS-C2950T-24, do kterého je hlavní server připojen, začal i přesto, že na něm byla aktivní funkce IGMP snooping, celý multicastový provoz posílat na všechny porty, a tím způsobil přetížení některých bezdrátových spojů. To je standardní chování v případě, že funkce IGMP snooping nemůže určit adresu aktivního IGMP querieru a k ní asociovat tabulku IGMP klientů. Tuto skutečnost jsem ověřil výpisem IGMP querierů na switchi: sw-pio1br#show ip igmp snooping querier Vlan

IP Address

IGMP Version

Port

--------------------------------------------------sw-pio1br# Tabulka IGMP querierů byla prázdná. Nejlepším řešením, které minimalizuje možnost výpadku IGMP querieru a následného přetížení sítě multicastovým vysíláním, je vytvořit IGMP querier přímo z hlavního serveru, který je jeho zdrojem. K tomu lze použít například aplikaci MRouteD[10], která je součástí distribuce Gentoo Linux. Instalace se provádí příkazem emerge -vat mrouted. Po zprovoznění aplikace mrouted se IP adresa hlavního serveru objevila v tabulce IGMP querierů a síť se začala chovat požadovaným způsobem: sw-pio1br#show ip igmp snooping querier Vlan

IP Address

IGMP Version

Port

--------------------------------------------------1

212.158.155.14 v2

Gi0/1

sw-pio1br# IGMP querierů může být v sítí i více, v takovém případě se používá ten, který má nejnižší IP adresu.


6.2

39


Po dokončení hlavního serveru byla zahájena stavba re-streamovacích serverů.

6.2.1

Operační systém

Instalace operačního systému Gentoo Linux proběhla stejným způsobem jako v případě hlavního serveru.

6.2.2


6.2.2.1

Instalace

Pro instalaci modulu iptv-0.4.2 je potřeba vdr-1.7.15. Protože Portage Tree, výchozí zdroj Ebuild skriptů, které v distribuci Gentoo Linux slouží k instalaci nových aplikací, obsahuje pouze Ebuild skript pro vdr-1.6.0, je nutné ho rozšířit o tzv. Portage Overlay. Pomocí aplikace layman jsem tedy přidal Portage Overlay vdr-devel, které obsahuje potřebné Ebuild skripty. Aplikaci VDR a modul streamdev jsem následně nainstaloval standardním způsobem pomocí příkazu emerge. Pro modul iptv-0.4.2 není k dispozici Ebuild skript, takže je nutné ho zkompilovat a nainstalovat ručně ze stažených zdrojových kódů[21].

6.2.2.2

Konfigurace

Konfigurace se nachází v adresáři /etc/vdr/ a její nejdůležitější částí je definice kanálů v souboru /etc/vdr/channels.conf, která má pro účely IPTV upravenou syntaxi: Name:10:S=0|P=0|F=HTTP|U=127.0.0.1|A=3000:I:0:257:273:289:0:1:0:0:0 ^

^

^

^

^

^

^

|

|

|

|

|

|

|

|

|

|

|

|

|

IPTV

|

|

|

|

|

Port

|

|

|

|

Stream address

|

|

|

Protocol

|

|

Program ID scanner

|

Service ID scanner

Frequency

40


Poslední část obsahuje informace o vnitřní struktuře datového proudu (program map table id, service id a další). Parametr Frequency nemá u IPTV kanálů žádný význam, ale je nutné každému kanálu nastavit unikátní frekvenci, aby bylo zaručeno, že bude virtuální DVB zařízení při přepnutí programu přeladěno. Kompletní konfigurace je součástí přílohy. 6.2.2.3

Testování

Počáteční testování odhalilo, že se aplikace chová podle předpokladů, dokud se využívá pouze 1 virtuální DVB tuner, tedy dokud se přijímá pouze 1 kanál. Virtuálních DVB zařízení je instalováno tolik, kolik programů nabízí hlavní server, aby bylo možné vykrýt případ, kdy mají být všechny přijimány současně. Když se má ale začít přijímat 2. program, dojde k tomu, že místo využití DVB zařízení 2 se znovu přeladí DVB zařízení 1, které je v té době již využíváno 1. programem. Z pohledu 1. uživatele situace vypadá tak, že se mu sám přepne kanál na ten, který si zvolil 2. uživatel. Problém by bylo možné obejít tím, že by každý kanál obsluhovala samostatná instance VDR, ale takové řešení by bylo náročné na správu. Druhou možností je nalézt a opravit chybu v modulu iptv, která problém způsobuje. 6.2.2.4

Analýza problému

Příčinou problému je implementace metody cIptvDevice::ProvidesChannel(): bool cIptvDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers) const { bool result = false; bool needsDetachReceivers = false; debug("cIptvDevice::ProvidesChannel(%d)\n", deviceIndex); if(ProvidesTransponder(Channel)) result = true; if(NeedsDetachReceivers) *NeedsDetachReceivers = needsDetachReceivers; return result; } Voláním této metody VDR zjišťuje, jestli je DVB zařízení schopné přijímat požadovaný kanál. Nastavení parametru NeedsDetachReceivers přitom určuje, jestli příjem příslušného


41

kanálu vyžaduje odpojení od jiného kanálu. Protože metoda vždy nastaví parametr na false, algoritmus vyhodnotí zařízení za vhodné a zavolá metodu cIptvDevice::SetChannelDevice(). Ta přeladí zařízení na nový kanál, což vede k pozorovanému problému. 6.2.2.5

Návrh řešení

Parametr NeedsDetachReceivers je nutné nastavovat podle toho, jestli se požadovaný kanál shoduje s tím, který zařízení již přijímá. Problém je, že původní implementace třídy cIptvDevice si informaci o přijímaném kanálu neukládá. Je tedy potřeba přidat členskou proměnnou typu cChannel, upravit metodu cIptvDevice::SetChannelDevice() a nakonec přidat požadovanou podmínku do metody cIptvDevice::ProvidesChannel(). bool cIptvDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers) const { bool result = false; bool needsDetachReceivers = true; if(Receiving(true)) { dsyslog("IPTV device %d in use: Channel=%s", deviceIndex, pTunedChannel->Name()); if(Channel->GetChannelID() == pTunedChannel->GetChannelID()) needsDetachReceivers = false; } else { dsyslog("IPTV device %d free: Channel=%s", deviceIndex, pTunedChannel->Name()); needsDetachReceivers = false; } --Metodu cIptvDevice::SetChannelDevice() jsem navíc optimalizoval tak, aby se zařízení znovu nepřipojovalo ke streamu, který již přijímá, protože to způsobovalo krátké přerušení vysílání.

42


bool cIptvDevice::SetChannelDevice(const cChannel *Channel, bool LiveView) { cIptvProtocolIf *protocol; cIptvTransponderParameters itp(Channel->Parameters()); if(!(Receiving(true) && (Channel->GetChannelID() == pTunedChannel->GetChannelID()))) { *pTunedChannel = *Channel; dsyslog("IPTV device %d tuning to: %s", deviceIndex, Channel->Name()); debug("cIptvDevice::SetChannelDevice(%d)\n", deviceIndex); --Navržené úpravy byly po konzultaci s autory modulu (Rolf Ahrenberg a Antti Seppälä) zahrnuty do jeho dalších verzí[21].

6.3

Klient

Instalace aplikace VLC na straně klienta je triviální, ale je nutné splnit požadavek na automatickou aktualizaci programové nabídky, která je uložena jako playlist ve formátu M3U: #EXTM3U #EXTINF:-1,1 CT 1 SM http://tv-kve40.mx-net.cz:3000/TS/I-3-3014-8005 #EXTINF:-1,2 CT 2 http://tv-kve40.mx-net.cz:3000/TS/I-3-3014-8004 #EXTINF:-1,3 CT 24 http://tv-kve40.mx-net.cz:3000/TS/I-3-3014-8006 #EXTINF:-1,4 CT 4 http://tv-kve40.mx-net.cz:3000/TS/I-3-3014-8007 #EXTINF:-1,5 Nova http://tv-kve40.mx-net.cz:3000/TS/I-3-3219-13138 #EXTINF:-1,6 Nova Cinema http://tv-kve40.mx-net.cz:3000/TS/I-3-3219-13139 ---

6.4. SET-TOP BOX

43

Využil jsem možnost vnořování playlistů a původní playlist jsem umístil na webový server tak, aby na něj nový mohl odkazovat: #EXTM3U #EXTINF:0,MX-TV http://iptv.mx-net.cz/vlc/tv-kve40.m3u Tím je zajištěno, že si klient při každém spuštění služby MX-TV stáhne z webového serveru aktuální verzi playlistu.

6.4

Set-top box

Multimediální přehrávač PBO Core[15] je zařízení s operačním systémem Linux, které podporuje přehrávání HTTP streamů, ačkoliv není původně navrženo pro účely IPTV set-top boxu. Základem jeho uživatelského rozhraní je aplikace dvdplayer 1 , která načítá jednotlivé nabídky z externích souborů ve formátu RSS. To umožňuje vytvořit v hlavní nabídce novou položku a do ní umístit odkazy na kanály služby MX-TV. Main ./scripts/menu.rss <menu>main menu MX-TV Live http://iptv.mx-net.cz/stb/pbo/mx-tv_kve40.rss <media:thumbnail url="/usr/local/etc/dvdplayer/mx-tv_logo.png" width="256" height="144" /> <mediaDisplay name=threePartsView showNestedHeader=no fontSize=20 --Podobně jako u klientského playlistu jsem i v tomto případě zvolil variantu uložit RSS skript se seznamem kanálů na webový server a do nabídky v zařízení umístit pouze odkaz, aby byla zajištěna automatická aktualizace údajů. 1

Aplikaci dvdplayer nelze upravovat, protože není k dispozici její zdrojový kód.

44


Na straně webového serveru jsem implementoval jednoduchou aplikaci, která každou minutu seznam kanálů doplňuje aktuálními informacemi o právě vysílaných televizních pořadech.

#!/bin/bash source /etc/profile cd /web/www/mx-net.cz/iptv/stb/pbo/epg wget "http://iptv.mx-net.cz/stb/pbo/epg/mx-tv_vdr_template.php? link=iptv.mx-net.cz/stb/pbo/mx-tv_server.rss&server=tv-server.mx-net.cz" -O mx-tv_server.rss sed ’s/tv-server.mx-net.cz/tv-hor1/g’ mx-tv_server.rss > mx-tv_hor1.rss sed ’s/tv-server.mx-net.cz/tv-kve40/g’ mx-tv_server.rss > mx-tv_kve40.rss sed ’s/tv-server.mx-net.cz/tv-vp/g’ mx-tv_server.rss > mx-tv_vp.rss rm mx-tv_server.rss

Aplikace je kombinací několika shell skriptů a šablony v jazyce PHP. Televizní program ve formátu XMLTV se stahuje z Internetu jednou za den a vyhledává se v něm pomocí dotazu XPath[24].

="’ . $time . ’"]’; $elements = $xpath->query($query); foreach($elements as $element) { echo date("H:i", strtotime($element->getAttribute(’start’))) . " - "; $nodes = $element->childNodes; foreach($nodes as $node) { if($node->nodeName == "title") echo $node->nodeValue . " "; } echo "(" . round(((time() - strtotime($element->getAttribute(’start’))) / (strtotime($element->getAttribute(’stop’)) strtotime($element->getAttribute(’start’)))) * 100) . "%)"; } ?>

6.5. ZABEZPEČENÍ

6.5

45

Zabezpečení

Přístup ke službě MX-TV zabezpečují firewally, na kterých se povoluje přístup jednotlivým klientům.

46


Kapitola 7

Testování Základní testování systému se uskutečnilo v průběhu realizace jeho jednotlivých částí. Nefunkční části byly opraveny nebo nahrazeny, takže v tomto okamžiku je službu MX-TV možné považovat za plně funkční. Oficiálnímu zahájení provozu předcházelo zkušební období v délce asi 1 měsíce. Při dlouhodobém testování došlo k několika výpadkům služby, které byly ve většině případů způsobeny změnami parametrů jednotlivých přijímaných kanálů nebo povětrnostními podmínkami (vítr a sníh), které v extrémních případech dočasně znemožnily příjem signálu. V tuto chvíli využívá v síti společnosti MX-NET Telekomunikace s.r.o. službu aktivně přibližně 40 uživatelů. Zatížení re-streamovacích serverů v době večerní špičky ukazují grafy 7.1 a 7.2, přičemž rozdíl mezi velikostí přijatých a odeslaných dat představuje ušetřenou kapacitu kritických spojů. Zátěž procesorů je na všech serverech zanedbatelná. 80 Mbit/s

60 Mbit/s

40 Mbit/s

20 Mbit/s

0bit/s

20:30

21:00

21:30

22:00

GigabitEthernet0/1 (25) @ sw-kve40br tx

22:30

23:00

GigabitEthernet0/1 (25) @ sw-kve40br rx

Obrázek 7.1: Zatížení re-streamovacího serveru v cílové lokalitě 1

47

48

KAPITOLA 7. TESTOVÁNÍ

80 Mbit/s

60 Mbit/s

40 Mbit/s

20 Mbit/s

0bit/s

20:30

21:00

ether2_iptv (3) @ mtik-svm560vp tx

21:30

22:00

22:30

23:00

ether2_iptv (3) @ mtik-svm560vp rx

Obrázek 7.2: Zatížení re-streamovacího serveru v cílové lokalitě 3

Z grafů je patrné, že re-streamovací servery ušetří kritickým spojům ve večerní špičce v některých případech až 40Mbps, což představuje téměř polovinu jejich kapacity.

Kapitola 8

Závěr Cílem práce bylo analyzovat možnosti provozu služby IPTV v síti společnosti MX-NET Telekomunikace s.r.o. a následně službu navrhnout a implementovat se zaměřením na využití otevřeného software. Z úvodní analýzy vyplynulo, že požadovaných vlastností lze dosáhnout využitím vysílání HTTP unicast v kombinaci s tzv. re-streamovacími servery. Stanovené cíle byly splněny s výjimkou navrhované simulace, která se neuskutečnila, protože nebyla potřebná. Služba MX-TV byla implementována v požadovaném rozsahu a s použitím výhradně otevřeného software a v současné době je v plném provozu. V případě potřeby umožňuje flexibilní rozšiřování do dalších částí sítě, rozšiřování programové nabídky i přechod na vysílání UDP multicastem. Vysílání je možné prijímat jak přímo na počítačích, tak na televizních přijímačích prostřednictvím navrženého set-top boxu. Navíc byla v rámci implementace objevena a opravena chyba v open-source modulu vdr-iptv[21], z čehož mohou v budoucnu profitovat i jiné projekty. Za relativně dlouhou dobu vývoje projektu došlo i k vývoji otevřeného software. Je k dispozici celá řada nových aplikací, které by mohly být do některých částí systému vhodnější než současná řešení, ale možnosti jejich využití budou teprve předmětem analýzy. Je také nutné brát v úvahu skutečnost, že společnost Patriot, která vyrábí multimediální přehrávač PBO Core[15], oznámila ukončení jeho výroby. V nejbližší době bude tedy nutné navrhnout nový set-top box, postavený na jiném hardware. Zajímavou variantou se zdá být použití mini-počítače Raspberry Pi v kombinaci s multimediálním centrem XBMC.

49

50

KAPITOLA 8. ZÁVĚR

Literatura [1] DVB-T přijímače do USB [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [2] IP Multicasting: References [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [3] Gentoo Linux [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [4] Gentoo Linux x86 Handbook [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [5] Getstream 2 [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [6] GitHub - ambrosa [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [7] Linux and GNU [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [8] IPv4 Multicast Address Space Registry [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [9] MikroTik Routers and Wireless [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [10] MRouteD [online]. 2012. [cit. 24. 4. 2012].

Dostupné z:
projects/mrouted>. [11] MuMuDVB [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [12] MX-NET Telekomunikace s.r.o. [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: .

51

52

LITERATURA

[13] Install Open-SASC-NG [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [14] OSCam [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [15] PBO Core Media Player [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [16] Rada pro rozhlasové a televizní vysílání [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [17] GIGABYTE GT-PS700 [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [18] TT-budget S2-3200 [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [19] Genius TVGo DVB-T03 [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [20] The Video Disk Recorder [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [21] IPTV plugin for VDR [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [22] VDR Streamdev Plugin [online]. 2012. [cit. 24. 4. 2012].

Dostupné z:
projects.vdr-developer.org/projects/show/plg-streamdev>. [23] VideoLAN - VLC [online]. 2012. [cit. 24. 4. 2012].

Dostupné z:
videolan.org/>. [24] XML Path Language (XPath) [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: .

Příloha A

Seznam použitých zkratek ATX Advanced Technology Extended CAM Conditional Access Module CD Compact Disc CI Common Interface DVB Digital Video Broadcasting DVB-S Digital Video Broadcasting - Satellite DVB-T Digital Video Broadcasting - Terrestrial HD High-Definition HDMI High-Definition Multimedia Interface HTTP Hypertext Transfer Protocol IGMP Internet Group Management Protocol IP Internet Protocol IPTV Internet Protocol Television PC Personal Computer PCI Peripheral Component Interconnect RFC Request for Comments RRTV Rada pro rozhlasové a televizní vysílání

53

54

SD Standard-Definition SDK Software Development Kit STB Set-Top Box TCP Transmission Control Protocol UDP User Datagram Protocol USB Universal Serial Bus VoIP Voice over Internet Protocol

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Obsah přiloženého CD |-| |-| | |-| | |-|-| | ‘--

camfiles ‘-- cardclient.conf headend |-- iptv-a0 ‘-- mumudvb-a0.conf text |-- Dip.pdf ‘-- src vdr vdr-iptv |-- device.c.patch ‘-- device.h.patch web ‘-- vlc

- konfigurace Open-SASC-NG - spouštěcí skript MuMuDVB - konfigurace MuMuDVB -

text práce zdrojový kód konfigurace VDR kompletní oprava modulu vdr-iptv

- webová část služby vdr-iptv - playlisty pro VLC

Obrázek B.1: Obsah přiloženého CD

55

IPTV služba v síti malého poskytovatele internetu

Recommend Documents