012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Návrh a implementace systému pro video podporu rozhodování rozhodˇcích v hokeji D IPLOMOVÁ PRÁCE

Bc. Pavel Kohoutek

Brno, podzim 2013

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: RNDr. Petr Holub, Ph. D. ii

Podˇekování Chci podˇekovat pˇredevším RNDr. Petru Holubovi, Ph.D. za vedení této práce, za podnˇetné pˇripomínky a za cˇ as, který mi byl ochoten vˇenovat. Dˇekuji také kolegum ˚ z laboratoˇre SITOLA, kteˇrí byli ochotni konzultovat technické potíže zejména v zaˇcátku vývoje systému. Mé díky patˇrí také mojí ženˇe Veronice, pˇrátelum ˚ a blízkým za podporu a trpˇelivost.

iii

Shrnutí Cílem této práce je navrhnout a implementovat video systém pro podporu rozhodování sporných situací v ledním hokeji. Systém zaznamenává video z více kamer souˇcasnˇe a umožnuje ˇ rychlé opakování nahraných záznamu. ˚ Nabízí zpomalené pˇrehrávání tak, aby bylo rozhodˇcímu umožnˇeno správnˇe posoudit spornou situaci pˇri hˇre. Souˇcástí práce je analýza dostupných technologií a výkonnostních požadavku˚ pro zpracování videa v poˇcítaˇci. K systému je vytvoˇreno pˇrehledné uživatelské rozhraní s dotykovým ovládáním. Oproti zadání byl systém rozšíˇren o výstup na další zobrazovací systémy. Systém je nasazen v reálném provozu.

iv

Abstract Goal of this thesis is to design and implement a video system to support decisions of disputable situations in ice hockey. The system records videos concurrently from multiple cameras and it allows quick replay of the recordings. To correctly decide about disputable situations during the game, the system features slow-motion functionality. Another part of this thesis is analysis of available technologies and performance requirements for video processing in a computer. A well-arranged touch enabled user interface is created as a part of the system. The system has been deployed on one stadium successfully as of finalizing this thesis.

v

Klíˇcová slova Lední hokej, HD video, záznam videa, komprese, GPU, JPEG

vi

Obsah 1

2

3

Požadavky pro rozhodování . . . . . . . 1.1 Rozmˇery hˇrištˇe . . . . . . . . . . . . 1.2 Brankové kamery . . . . . . . . . . . 1.2.1 Poˇcet a umístˇení kamer . . . 1.2.2 Rozlišení . . . . . . . . . . . . 1.2.3 Snímkovací frekvence . . . . Dostupné technologie . . . . . . . . . . . 2.1 Video rozhraní . . . . . . . . . . . . . 2.1.1 HDMI . . . . . . . . . . . . . 2.1.2 SDI . . . . . . . . . . . . . . . 2.1.3 CoaXPress . . . . . . . . . . . 2.1.4 Výbˇer video rozhraní . . . . . 2.2 Komprese . . . . . . . . . . . . . . . 2.2.1 Požadavky . . . . . . . . . . . 2.2.2 Dostupné nástroje . . . . . . 2.2.3 Výbˇer komprese . . . . . . . 2.3 Použité technologie . . . . . . . . . . Architektura systému . . . . . . . . . . . 3.1 Analýza požadavku˚ na propustnost 3.1.1 Vstupní video . . . . . . . . . 3.1.2 Ukládání . . . . . . . . . . . . 3.1.3 Pˇrehrávání . . . . . . . . . . . 3.1.4 Zobrazení a SDI výstup . . . 3.1.5 Vyhodnocení propustnosti . . 3.2 Grafické uživatelské rozhraní . . . . 3.2.1 Rozložení ovládacích prvku˚ . 3.3 Schéma systému . . . . . . . . . . . . 3.3.1 Záznam . . . . . . . . . . . . 3.3.2 Pˇrehrávání . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 5 6 6 7 9 11 11 12 12 14 15 16 17 17 18 20 21 21 21 22 24 26 26 29 31 32 32 33 1

3.3.3 Výstup . . . . . . . . . . . 3.4 Minimální požadavky . . . . . . 4 Implementace vybraných cˇ ástí . . . . 4.1 OpenGL display . . . . . . . . . . 4.1.1 Pˇríprava scény . . . . . . 4.1.2 Nahrávání textur . . . . . 4.1.3 Zobrazení YUV dat . . . . 4.2 Pˇrehrávaˇc . . . . . . . . . . . . . 4.2.1 Výbˇer snímku˚ k pˇrehrání 4.2.2 Režimy pˇrehrávání . . . . 4.3 SDI výstup . . . . . . . . . . . . . 4.3.1 Klíˇcování pˇres video . . . 4.4 Dotykové ovládání . . . . . . . . Literatura . . . . . . . . . . . . . . . . . A Obsah CD . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34 35 37 37 37 38 39 41 41 42 43 44 45 48 52

2

Úvod Lední hokej velice rychlá týmová hra, ve které jsou kladeny stále vˇetší nároky na pˇresnost posuzování pravidel a pˇrestupku˚ vuˇ ˚ ci nim. Ve hˇre je povoleno, a v nˇekterých soutˇežích dokonce vyžadováno, použití video záznamu˚ k posuzování sporných herních situací. V souˇcasné dobˇe jsou na video zaznamenávány pouze situace v blízkosti brány, do budoucna se ale pravdˇepodobnˇe záznam rozšíˇrí na celé hˇrištˇe. Existuje dnes celá rˇ ada systému, ˚ které dnešní požadavky splnují ˇ a na stadionech se používají. Jsou to ale cˇ asto velice komplexní, na ovládání složité a nákladné systémy, které si menší hokejové kluby nemužou ˚ dovolit. Ve spolupráci s firmou Daite s.r.o. proto vznikla tato práce, která si klade za cíl navrhnout a vytvoˇrit ucelený systém pro zpracování videa z hokejových zápasu˚ pro potˇreby posuzování sporných herních situací videorozhodˇcími. Systém má umožnovat ˇ záznam zajímavých momentu˚ zápasu z více kamer souˇcasnˇe a rychle nabízet pˇrístup k tˇemto záznamum ˚ k pˇrehrání, pˇri kterém je možné mˇenit rychlost a smˇer pˇrehrávání. Pˇritom má být systém postaven na bˇežnˇe dostupném hardware, aby jeho poˇrizovací cena byla pˇrijatelná i pro menší hokejové kluby. V menších klubech bývá zvykem, že obsluha na stadionu není složena z profesionálu˚ v oblasti video produkce, ale cˇ asto z dobrovolníku. ˚ V tomto systému je proto kladen duraz ˚ na jednoduché a intuitivní ovládání, aby jej byli schopni ovládat i jen krátce proškolení uživatelé. Z tohoto duvodu ˚ má být systém ovladatelný i dotykovým rozhraním a zobrazovat v uživatelském rozhraní náhledy všech vstupních videí. V prubˇ ˚ ehu rˇ ešení byly do projektu zaˇrazeny další dodateˇcné požadavky firmy Daite. Do systému byl pˇridán jeden video výstup pro zobrazování živého i opakovaného video záznamu na velkoplošných obrazovkách na stadionu. Požadována byla také možnost zobrazovat pˇres video další pruhledný ˚ obsah jako jsou textové informace pro diváky, stˇrihové efekty videa, gólové animace a další uživatelsky definovaný obsah. Systém pro videorozhodˇcí tím byl rozšíˇren i pro použití jako video režie pro promítání na obrazovkách v rámci stadionu v menších hokejových klubech. Systém byl také v prubˇ ˚ ehu rozšíˇren o možnost exportu uživatelem vybraných video klipu˚ do zvoleného externího úložištˇe pro použití hokejovým klubem k postprodukci. 3

V první kapitole práce rozebírám, jaké jsou požadavky rozhodˇcích na zamýšlený systém, co od systému oˇcekávají. Rozebírám také, jaké základní parametry videa má smysl pro tento úˇcel uvažovat pˇri daných rozmˇerech hˇrištˇe a puku a pˇri rychlostech, s jakými se puk muže ˚ pohybovat. V následující kapitole nabízím pˇrehled dostupných technologií pro pˇrenos a kompresi videa a vybírám, která se do prostˇredí hokejových stadionu˚ pro daný úˇcel nejlépe hodí. Tˇretí kapitolu vˇenuji rozboru datové nároˇcnosti zpracování videa a stanovení maximálního poˇctu vstupu˚ a jejich parametru˚ tak, aby bylo možné systém postavit na jednom poˇcítaˇci sestaveném z komoditních komponent. Na základˇe toho dále navrhuji schéma systému, popisuji principy a propojení jeho jednotlivých zamýšlených souˇcástí. Implementace vybraných problému˚ je podrobnˇeji popsána ve cˇ tvrté kapitole. Pˇredpokládá se komerˇcní nasazení celého systému, proto není souˇcástí práce kompletní popis implementace a zdrojový kód systému jako celku, ale jsou zahrnuty jen vybrané problémy, které jsou z pohledu této práce zajímavé. Poslední kapitolu vˇenuji mˇerˇ ení výkonu implementovaného systému.

4

Kapitola 1

Požadavky pro rozhodování Lední hokej je velice rychlá týmová hra, která se rˇ ídí pˇresnými pravidly. S tím, jak se lední hokej od svého vzniku stále zrychluje, rostou také požadavky na pˇresnost posuzování pravidel. V urˇcitých pˇrípadech se již dostáváme za hranici možností lidského vnímání, napˇríklad když již nelze pouhým okem pˇresnˇe posoudit dráhu rychle letícího puku. Z tohoto duvodu ˚ byl do pravidel hokeje zaveden takzvaný videorozhodˇcí, který s pomocí videotechniky posuzuje sporné situace zpomaleným pˇrehráváním záznamu. ˇ Videorozhodˇcí patˇrí podle v souˇcasné dobˇe platných pravidel Ceského svazu ledˇ ního hokeje (CSLH) [1] do skupiny pomocných rozhodˇcích, tedy takových, kteˇrí nejsou bˇehem hry na ledové ploše. Kompetence videorozhodˇcího spoˇcívá v posouzení herní situace z dostupných videozáznamu, ˚ pokud je hlavním rozhodˇcím požádán o pˇrezkoumání dané situace. V souˇcasné dobˇe se takto zkoumají sporné situace pouze pˇred bránou, do budoucna se však uvažuje o sledování celého hˇrištˇe. ˇ V Ceské republice je používání systému videorozhodˇcího vyžadováno pouze v nejvyšší hokejové soutˇeži, v Tipsport Extralize, jejím herním rˇ ádem. Uvažuje se ale o zaˇrazení videorozhodˇcích i do nižších soutˇeží, napˇríklad do 1. ligy ledního hokeje. Herní rˇ ád Tipsport Extraligy ledního hokeje (TELH) uvádí že kluby hrající danou soutˇež "zajistí technické zabezpeˇcení nezbytné k urˇcení branek a asistencí videorozhodˇcím (tj. záznamové zaˇrízení s možností opakování zábˇeru z prubˇ ˚ ehu utkání) "[2]. Nemusí být tedy nutnˇe zaznamenáváno celé utkání, ale pouze cˇ ásti zápasu, které jsou pro urˇcení branek a asistencí nezbytné. Nevyžaduje se také záznam v herních pˇrestávkách a pˇri pˇrerušení hry.

1.1 Rozmˇery hˇrištˇe Hˇrištˇe pro lední hokej je ledová plocha tvaru obdélníku se zakˇrivenými rohy s polomˇerem zakˇrivení 7 až 8,5 metru˚ a je obehnaná ze všech stran mantinely. Rozmˇery hˇrištˇe jsou stanoveny pravidly ledního hokeje [1] v rozmezí 26 až 30 metru˚ na šíˇrku, 56 až 61 5

1. P OŽADAVKY PRO ROZHODOVÁNÍ

Brankovišt

Branková ára, ervená, 5 cmširoká

ára vymezující brankovišt, ervená, 5 cmširoká, polomr 180 cm

Obrázek 1.1: Pudorys ˚ brankovištˇe. Všechny míry jsou v cm. Pˇrevzato z [1]. metru˚ na délku. Na obou koncích delší strany hˇrištˇe jsou osazeny brány a vyznaˇcené brankovištˇe. Brankovištˇe má tvar pulkruhu ˚ o polomˇeru 180 cm smˇerˇ ující od brankové cˇ áry do stˇredu hˇrištˇe. Pudorys ˚ brankovištˇe a brány je znázornˇen na obrázku 1.1. Cílem hry je vstˇrelit puk do brány soupeˇre. Puk je válcovitý pˇredmˇet vyrobený z vulkanizované gumy cˇ erné barvy o rozmˇerech 3 palce v prumˇ ˚ eru (pˇribližnˇe 7,62 cm), 1 palec na výšku (pˇribližnˇe 2,54 cm). Rychlost puku pˇri stˇrelách muže ˚ dosahovat až 160 km/h [3].

1.2 Brankové kamery Správná volba parametru˚ kamer, jejich poˇcet a umístˇení na hˇrišti jsou pˇredpoklady pro dobrou použitelnost systému pro podporu videorozhodˇcích. 1.2.1 Poˇcet a umístˇení kamer ˇ Pro správné posouzení herních situací pˇred bránou CSLH vyžaduje alesponˇ dvˇe kamery u každé z branek na hˇrišti. Jedna nabízí pohled na bránu a brankovištˇe shora pod úhlem pˇribližnˇe 2◦ od kolmice k ledu tak, aby kostrukce branky nezakrývala brankovou cˇ áru. Druhá kamera zabírá bránu šikmo z boku. Tento poˇcet kamer však nemusí být dostaˇcující pro posouzení všech možných situací. V okolí brány bývá zejména pˇri šancích a sporných momentech vˇetší poˇcet hráˇcu, ˚ 6

1. P OŽADAVKY PRO ROZHODOVÁNÍ kteˇrí zakrývají pohled kamery na puk. V tomto pˇrípadˇe by bylo vhodné umístit další boˇcní kameru na opaˇcnou stranu hˇrištˇe, cˇ ímž zvýšíme pravdˇepodobnost, že bude puk alesponˇ z jedné strany viditelný. Setkáváme se dnes i s instalacemi kamer dovnitˇr brány. Výhoda takového pohledu je v tom, že puk v pˇrípadˇe pˇrechodu pˇres brankovou cˇ áru již nikdo nezakryje, nanejvýš brankáˇr. Je však tˇreba poˇcítat s vyšší fyzickou odolností kamery, protože muže ˚ být zasažena pukem. Alternativnˇe lze instalovat kameru za bránu za hranici hˇrištˇe, je však nutno poˇcítat s tím, že ideální výhled na puk je pˇrekryt sítí a konstrukcí brány, pˇrípadnˇe i hráˇci stojícími za bránou. Celkem by tedy pro ideální pokrytí prostoru pˇred bránami bylo nutné používat systém s osmi až deseti kamerami, pro každou bránu horní pohled, šikmé boˇcní pohledy z obou stran, pohled zevnitˇr brány a pˇrípadnˇe i zadní pohled. Tento poˇcet kamer by dle ˇ mého názoru již dostateˇcnˇe pokrýval prostor v okolí branek. CSLH pro tyto systémy však v souˇcasné dobˇe používá bˇežnˇe cˇ tyˇri kamery, avšak rozšíˇrení jejich poˇctu je možné v budoucnu oˇcekávat.

1.2.2 Rozlišení Hokejový puk je pomˇernˇe malý pˇredmˇet. Jak uvádím výše, jeho rozmˇery jsou 7,62 cm v prumˇ ˚ eru a 2,54 cm na výšku. V této cˇ ásti se zabývám tím, jaké nejnižší rozlišení kamer už je v systému použitelné, aby bylo možné puk dostateˇcnˇe pˇresnˇe v obraze najít. Tabulka 1.1 vyjadˇruje, kolika obrazovými body (pixely) je pˇri daném rozlišení puk v obraze reprezentován. Pˇri výpoˇctu vycházím z velikosti zábˇeru horní kamery, jehož rozmˇery lze nejlépe odvodit z rozmˇeru˚ brankovištˇe. Zbylé kamery pokrývají svým zábˇerem pˇribližnˇe stejnou plochu, pˇrípadnˇe menší, tedy s vˇetším detailem. Uvedené hodnoty jsou tedy nejhorším odhadem velikosti puku v obraze. Zábˇer horní kamery je schematicky zachycen na obrázku 1.2. Zábˇer byl umístˇen tak, aby se do nˇej vešla celá konstrukce brány, brankovištˇe a prostor pˇred brankovištˇem alesponˇ stejné délky jako samotné brankovištˇe. Hráˇci, vyjma brankáˇre, nemohou do brankovištˇe vstupovat. Nejvíce hráˇcu˚ se tak soustˇredí v okolí brankovištˇe, proto není v zábˇeru jen brankovištˇe, ale i prostor v jeho okolí, avšak se stále dostateˇcnˇe detailním pohledem na bránu. V souˇctu má tedy zábˇer výšku 4,8 metru a šíˇrku 6,4 metru v pˇrípadˇe videa s pomˇerem stran 4:3, respektive 8,5 metru v pˇrípadˇe použití kamer s pomˇerem stran 16:9. V tabulce 1.1 také uvádím velikost bodové reprezentace puku v obraze pˇri zábˇeru celé hrací plochy. Uvažuji zábˇer jedné kamery s pomˇerem stran 16:9, nebot’ pomˇer stran hˇrištˇe je pˇribližnˇe 2:1, což jsou pomˇernˇe blízké hodnoty a kamera takto zabere témˇerˇ 7

480


640 850

Obrázek 1.2: Pozice a velikost zábˇeru horní kamery nad bránou. Všechny míry v cm. PAL 576 1

HD 720

Full HD 1080

4K 2160

zábˇer na brankovištˇe

ležící puk puk na hranˇe

9,1 x 9,1 3 x 9,1

11,4 x 11,4 3,8 x 11,4

17,1 x 17,1 5,7 x 17,1

34,3 x 34,3 11,4 x 34,3

zábˇer na celé hˇrištˇe

ležící puk puk na hranˇe

1,2 x 1,2 0,4 x 1,2

1,8 x 1,8 0,6 x 1,8

2,7 x 2,7 0,9 x 2,7

5,4 x 5,4 1,8 x 5,4

Tabulka 1.1: Velikost puku v obraze (v pixelech) pˇri daných standardech videa (v závorce uvedeno vertikální rozlišení pro daný standard). výluˇcnˇe jen plochu hˇrištˇe. Horní pohled by byl pˇri hˇre využíván zejména pro kontrolu ofsajdových pozic hˇráˇcu˚ (situace, kdy útoˇcící hráˇc vjede do útoˇcného pásma dˇríve než puk [1]) a podobných, kdy pohled shora nabízí nejlepší pˇrehled. Pˇrípadné doplnˇení o celkový pohled z boku tak v tomto pˇrípadˇe není pro posuzování pravidel hokeje zajímavé. Výsledky z tabulky 1.1 ukazují, že v pˇrípadˇe detailního pohledu na brankovištˇe jsou z pohledu rozlišení obrazu dostaˇcující standardy Full HD i HD. Pˇri celkovém pohledu na hˇrištˇe je nejnižší použitelné rozlišení 4K (pˇri pomˇeru stran 16:9 je rozlišení obrazu 3840 × 2160). V pˇrípadˇe všech uvedených menších rozlišení se dostáváme pˇri pohledu na puk stojící na hranˇe pod hranici jednoho pixelu. Pˇri 4K rozlišení je puk v obraze

1. Pomˇer stran PAL videa je 4:3.

8

1. P OŽADAVKY PRO ROZHODOVÁNÍ reprezentován pˇribližnˇe 2x5 pixely, což je úplné minimum. Má smysl uvažovat využití nadcházejícího standardu 8K se cˇ tyˇrikrát vyšším rozlišením oproti 4K [4]. 1.2.3 Snímkovací frekvence Jak bylo zmínˇeno v zaˇcátku kapitoly, hokej je velice rychlá hra. Hráˇci na bruslích dosahují vysokých rychlostí a vystˇrelený puk se muže ˚ pohybovat rychlostí až 160 km/h. V této cˇ ásti práce se zabývám požadavky hokejových rozhodˇcích na temporální rozlišení kamerového záznamu. Na modelové situaci demonstruji minimální snímkovací frekvenci, kterou má smysl v systému používat. Videorozhodˇcí potˇrebuje ke správnému rozhodnutí o posouzení situace vidˇet na videu puk v pozici, která je pro posouzení situace rozhodující, napˇríklad puk za brankovou cˇ árou, puk odrážející se od zadní konstrukce brány apod. Urˇcovat, zda puk byl v inkriminovaném místˇe na základˇe snímku, kdy puk v daném místˇe ještˇe není a na následujícím snímku v daném místˇe už není, je znaˇcnˇe problematické, zejména když není zˇrejmé, od jakého pˇredmˇetu se mohl puk mezi snímky odrazit. Uvažujme tedy modelovou situaci, kdy stˇrela smˇerˇ uje do brány pod horní tyˇc, projde pˇres brankovou cˇ áru, odrazí se od zadní konstrukce brány a vrátí se opˇet pˇres brankovou cˇ áru ven. Takový gól je platný. Budeme nyní zkoumat jaká je nejnižší hodnota snímkové frekvence (angl. frames per second – FPS), abychom puk uvnitˇr brány zaznamenali alesponˇ jedenkrát. Z obrázku 1.1 víme, že horní cˇ ást zadní konstrukce brány je umístˇena 60 cm za úrovní brankové cˇ áry. Puk tedy urazí uvnitˇr brány celkovˇe dráhu nejménˇe 120 cm. Snížení rychlosti puku vlivem odrazu v tomto pˇrípadˇe zanedbávám. Nejnižší snímkovací frekvenci v tomto pˇrípadˇe snadno urˇcíme vztahem FPS =

160 ∗ 1000 1 v 1 3600 = s = = = ˙ 37 t s 1,2 v

kde v je rychlost puku km/h, s je dráha, kterou má urazit a t je doba mezi jednotlivými snímky videa. Snímkovací frekvence se rovná pˇrevrácené hodnotˇe cˇ asu mezi snímky. Vypoˇctenou hodnotu 37 FPS je tˇreba brát jako minimální hodnotu pouze pro uvedenou modelovou situaci. Mohou pˇri hˇre pochopitelnˇe nastat situace, kdy je rozhodující mnohem kratší vzdálenost, kterou puk urazí, než zminovaných ˇ 120 cm. Tabulka 1.2 uvádí potˇrebnou rychlost snímkování pokud chceme puk zaznamenat alesponˇ každých n metru˚ pˇri ruzných ˚ rychlostech puku.

9


80 km/h 120 km/h 160 km/h 180 km/h

2m

1,2 m

60 cm

30 cm

11,1 16,7 22,2 25

18,5 27,8 37 41,7

37 55,6 74,1 83,2

74,1 111,1 148,1 166,7

Tabulka 1.2: Potˇrebná snímkovací frekvence (v jednotkách FPS ) pro zachycení puku alesponˇ po n metrech pˇri ruzných ˚ rychlostech.

10

Kapitola 2

Dostupné technologie Existuje dnes rˇ ada technologií urˇcených pro pˇrenos videa ruzných ˚ standardu˚ a parametru. ˚ Nˇekteré se pro využití v systému pro hokejové videorozhodˇcí hodí více a nˇekteré ménˇe. Cílem této kapitoly je vytvoˇrit pˇrehled souˇcasných technologií a zvolit takové, které budou pro daný systém nejvhodnˇejší. Zamˇerˇ ovat se budu pˇredevším na podporovaná rozlišení obrazu a podporované snímkovací frekvence. Duležitými ˚ aspekty jsou ale také maximální délky kabelu, ˚ dostupnost a cena kamer a pˇrídavného hardware pro zachytávání videa v poˇcítaˇci. V druhé cˇ ásti kapitoly se vˇenuji volbˇe vhodné metody komprese. Urˇcujícími faktory jsou pˇritom zejména zpoždˇení (latence) komprese, závislost jednotlivých snímku˚ videa, podpora ruzných ˚ rozlišení, snadná integrovatelnost do systému, licence, pod jakou je daný kompresní nástroj šíˇren a pˇrípadné patentové poplatky spojené s využíváním komprese do daného formátu.

2.1 Video rozhraní Rozlišení video formátu˚ se bˇežnˇe oznaˇcuje poˇctem rˇ ádku˚ obrazu, tedy oznaˇcuje vertikální rozlišení obrazu. Šíˇrka obrazu se muže ˚ mˇenit v závislosti na použitém pomˇeru ˇ stran videa. Císlo, udávající poˇcet rˇ ádku˚ obrazu, bývá doplnˇeno písmenem p nebo i. Písmeno p znamená progressive a oznaˇcuje, že každý snímek videa nese všechny informace. Naproti tomu písmeno i znamená interlaced, tedy že snímky jsou prokládané. Každý snímek videa nese polovinu obrazových dat. Využívá se rˇ ádkový proklad, kdy jeden snímek obsahuje liché rˇ ádky a následující sudé rˇ ádky výsledného obrazu. Tímto zpusobem ˚ mužeme ˚ pˇrenést obraz poˇrízený s dvojnásobnou snímkovací frekvencí pˇri stejném datovém toku a opticky tak vytvoˇrit dojem vyšší snímkovací frekvence pˇri sledování videa. Jak již bylo zmínˇeno, každý takový snímek má poloviˇcní vertikální rozlišení, v pˇrípadˇe formátu 1080i je rozlišení snímku pouze 540 rˇ ádku. ˚ K získání celého snímku na neprokládaných zobrazovacích zaˇrízeních je potˇreba jej složit ze dvou po 11

2. D OSTUPNÉ TECHNOLOGIE sobˇe jdoucích snímku˚ poˇrízených v ruzných ˚ cˇ asových okamžicích. Pˇri skládání snímku˚ navíc v obraze vznikají problémy s výskytem artefaktu˚ a jejich odstranováním. ˇ 2.1.1 HDMI HDMI (High-Definition Multimedia interface) je digitální rozhraní urˇcené k pˇrenosu nekomprimovaného multimediálního obsahu, obrazu i zvuku. Aktuálnˇe nejrozšíˇrenˇejší je rozhraní ve verzi 1.4 [5]. V této verzi umožnuje ˇ pˇrenášet video s rozlišením 720p až s 60 snímky za vteˇrinu, 1080p až s 30 FPS nebo 1080i s dvojnásobmou frekvencí, tedy 60 FPS. Podporuje také pˇrenos videa formátu 4K 2160. V záˇrí 2013 vyšla nová verze tohoto rozhraní oznaˇcená HDMI 2.0 [6]. Propustnost rozhraní byla zvýšena až na 18 Gbps a jsou nyní podporovány i formáty 1080p se snímkovací frekvencí až 60 FPS a 4K 2160p, taktéž pˇri 50 i 60 FPS. Rozhraní zachovává zpˇetnou kompatibilitu se staršími verzemi, nezmˇenily se ani používané konektory. Podle soukromé komunikace s výrobci se oˇcekávají první karty pro zachytávání videa s rozhraním HDMI 2.0 na jaˇre 2014. Specifikace rozhraní neurˇcuje maximální povolenou délku kabelu. Standardizující instituce na svých stránkách uvádí že s bˇežnými certifikovanými kabely lze dosáhnout pˇrenosu na 30 metru˚ [7]. Existují však i možnosti pˇrenosu po jiných médiích. Výrobce uvádí HDMI pˇres Cat5/Cat6 kabeláž s dosahem až 50 metru, ˚ HDMI pˇres koaxiální kabel s dosahem až 300 stop (pˇribližnˇe 91 metru) ˚ nebo HDMI pˇrenášené optickým kabelem, kde uvádí dosah až 100 metru˚ nebo více. [7] Kamer s rozhraním HDMI je na trhu velký výbˇer, cˇ asto se jedná spíše o komerˇcní než prumyslové ˚ kamery. Aktuálnˇe dostupné karty pro záchyt videa (neboli ménˇe formálnˇe „grabovací karty“) podporují zatím pouze HDMI 1.4. Na trhu je rˇ ada výrobcu˚ tˇechto karet, napˇríklad zde zmíním Intensity Pro karty spoleˇcnosti Blackmagic Design, ke kterým výrobce dodává i SDK pro Windows, Mac i Linux. Karta podporuje videoformáty standardu HDMI 1.4 kromˇe 4K rozlišení. 2.1.2 SDI SDI (Serial Digital Interface) je skupina rozhraní k pˇrenosu digitálního obrazu a zvuku. Obsažené standardy jsou vydávány a spravovány asociací Society of Motion Picture and Television Engineers (SMPTE). Tato rozhraní jsou využívána zejména v profesionálním televizním prumyslu. ˚ Pro úˇcely zpracování videa pro hokej jsou zajímavá rozhraní HD-SDI, dual link HDSDI a 3G-SDI. První jmenované rozhraní HD-SDI (high-definition serial digital inter12

2. D OSTUPNÉ TECHNOLOGIE face), rˇ ídící se standardem SMPTE 292 [8], umožnuje ˇ pˇri propustnosti 1,5 Gbit/s pˇrenášet video s rozlišením 720p, 1080p a 1080i. Snímkovací frekvence podporované pˇri tˇechto rozlišeních jsou uvedeny v tabulce 2.1. Rozhraní Dual Link HD-SDI je rozšíˇrením pˇredchozího uvedeného rozhraní, rˇ ídí se standardem SMPTE 372 [9]. Používá pro jeden video signál dvojici kabelu˚ pˇredchozího zmínˇeného standardu SMPTE 292, cˇ ímž dosahuje dvojité pˇrenosové rychlosti oproti HD-SDI, umožní tak pˇrenést i rozlišení 1080p pˇri 60 FPS, pˇrípadnˇe videosignál s plným vzorkováním 4:4:4 pˇri 30 FPS. Dalším uvedeným rozhraním je 3G-SDI, které pˇredepisuje standard SMPTE 424 [10]. Má stejnou propustnost jako dual link SDI, avšak s použitím jen jednoho kabelu pro pˇrenos. Pˇrehled uvádí tabulka 2.1. Posledním rozhraním je 6G-SDI, které má umožnovat ˇ pˇrenos jedním kabelem, dvojicí i cˇ tveˇricí kabelu˚ k dosažení pˇrenosových rychlostí 6 GB/s, 12 GB/s a 24 GB/s. Bude tím možné dosáhnout pˇrenosu napˇríklad i 4K videa pˇri snímkovací frekvenci 120 FPS. Toto rozhraní však zatím nebylo standardizováno, organizace SMPTE uvádí odhadovaný termín dokonˇcení standardu v cˇ ervnu 2015 [11]. Pˇresto jsou už na trhu dostupné karty pro zachytávání videa s podporou 6G-SDI rozhraní, napˇríklad Blackmagic Decklink 4K Extreme s podporou dual link 6G-SDI.

HD-SDI dual link HD-SDI 3G-SDI

720p

1080i

1080p

4K

50, 59.94, 60 -

50, 59.94, 60 -

24, 25, 29.97, 30 50, 59.94, 60 50, 59.94, 60

24, 25, 29.97, 30

Tabulka 2.1: Pˇrehled video formátu˚ rozhraní SDI, poˇcet snímku˚ za vteˇrinu pˇri daném rozlišení Rozhraní SDI využívá k pˇrenosu signálu standardnˇe koaxiální kabel. Nˇekteré zdroje uvádí možnou délku kabelu pro pˇrenos HD-SDI signálu až 300 metru, ˚ není to ale garantovaná hodnota a je tˇreba otestovat pˇrenos v daném prostˇredí, protože muže ˚ v místˇe vznikat rˇ ada jevu˚ zpusobujících ˚ rušení. Vˇetších vzdáleností lze dosáhnout pˇri pˇrenosu optickým kabelem použitím konvertoru. ˚ Výrobce konvertoru Blackmagic Mini Converter Optical Fiber na svých stránkách uvádí dosah pˇresahující deset kilometru˚ 1 . S použitím opakovaˇcu˚ na optických kabelech je vzdálenost prakticky nelimitovaná. Pˇrídavné karty pro záchyt videa z HD-SDI rozhraní jsou dobˇre dostupné v ruzných ˚ modelech od rˇ ady výrobcu, ˚ napˇríklad karty rodiny Decklink od spoleˇcnosti Blackma1. http://www.blackmagicdesign.com/products/miniconverters [2013-12-30]

13

2. D OSTUPNÉ TECHNOLOGIE gic, karty Osprey od ViewCastu, karty výrobce Matrox a dalších. Ve vˇetšinˇe pˇrípadu˚ výrobce dodává ovladaˇce a SDK (Software Development Kit) pro použití hardware v programu, cˇ asto ale jen pro vybrané operaˇcní systémy. Napˇríklad karty Blackmagic Decklink jsou však podporovány na všech nejbˇežnˇejších platformách, na Windows, Mac i Linux. V Pˇrípadˇe 3G-SDI karet je výbˇer užší, jmenujme napˇríklad kartu BlackMagic Decklink 4K Extreme, Deltacast DELTA-3G-elp nebo NVIDIA Quadro SDI Capture. 2.1.3 CoaXPress CoaXPress (CPX) je standard pro asymetrickou vysokorychlostní komunikaci pro pˇrenos obrázku˚ a videa, rozšiˇritelný pˇres jeden nebo více koaxiálních kabelu˚ [12]. Nabízí vysokorychlostní downlink pro pˇrenos videa, obrázku˚ a dat s rychlostí až 6,25 Gb/s na jednom kabelu (až 25 Gb/s s využizím cˇ tyˇr koaxiálních kabelu) ˚ a pomalejší 20 Mb/s uplink pro komunikaci se zaˇrízeními a jejich ovládání. Napájení zaˇrízení je možné datovým koaxiálním kabelem (technologie Power-over-Coax). Výrobce uvádí možnou délku kabelu˚ delší než 100 metru. ˚ [12] Kamery s tímto rozhraním se podstatnˇe liší od kamer s rozhraním HDMI cˇ i SDI. Jejich rozlišení a snímkovací frekvence se vymykají standardum ˚ známým z oblasti digitální televize. Umožnují ˇ snímat obraz s vysokým rozlišením i pˇri snímkovacích frekvencích nˇekolikanásobnˇe vyšších než u bˇežných televizních kamer. I proto nacházejí uplatnˇení zejména v prumyslu ˚ v oblasti strojového vidˇení, robotiky apod. Uvádím zde základní parametry vybraných kamer: •

•

•

Adimec QUARTZ-series Q-4A180 –

rozlišení 4MPix

–

snímkovací frekvence 180 FPS

Optronis CP80-4-C-500 –

rozlišení 2.304 x 1.720 bodu˚ pˇri 500 FPS

–

až 10.000 FPS pˇri sníženém rozlišení a cˇ ernobílém snímání

Mikrotron EoSens 4CXP –

rozlišení 2.336 x 1.728 pˇri 560 FPS

–

témˇerˇ 10.000 FPS pˇri horizontálním rozlišení 100 pixelu˚ 14

2. D OSTUPNÉ TECHNOLOGIE Pˇri výbˇeru hardware pro zachytávání videa v tomto rozhraní mužeme ˚ vybírat mezi pˇrídavnými kartami firem Active Silicon, BitFlow, Matrox, Silicon Software a nˇekolika málo dalších. Karty se liší zejména podporou vstupních datových toku˚ (6,25 - 25 Gb/s) a podporou dalších funkcí CPX rozhraní jako je ovládání kamer a odesílání dat pˇres stejný kabel, pˇrípadnˇe i napájení kamer tímto kabelem.

2.1.4 Výbˇer video rozhraní Jako kritéria pro volbu vhodného rozhraní pro pˇrenos videa v zamýšleném systém jsem zvolil maximální podporovanou délku kabelu, ˚ podporované snímkovací frekvence a rozlišení, dostupnost a cena kamer a zachytávacího hardware pro dané rozhraní. V prostˇredí hokejových stadionu˚ je tˇreba uvažovat pomˇernˇe velké vzdálenosti od kamer k uvažovanému systému. V závislosti na umístˇení tohoto systému a velikosti stadionu dosahují vzdálenosti nejménˇe 100 metru, ˚ ale i nˇekolikanásobnˇe více v pˇrípadˇe rozlehlých sportovních hal. Rozhraní HDMI je v tomto ohledu nedostaˇcující, s použitím bˇežné kabeláže je udávaný dosah 30 metru. ˚ Je sice možné využít technologie pro pˇrenos HDMI po optickém kabelu k dosažení vˇetších vzdáleností, ale takové rˇ ešení by bylo v pˇrípadˇe HDMI rozhraní pomˇernˇe komplikované a drahé. CoaXPress nabízí standardnˇe dosah nejménˇe 100 metru˚ po bˇežném koaxiálním kabelu, SDI na stejném typu kabelu až 300 metru. ˚ V pˇrípadˇe potˇreby lze s SDI navíc dosáhnout mnohem vˇetších vzdáleností pˇrenosem po optické kabeláži. Data jsou pˇres SDI rozhraní pˇrenášena sériovˇe, díky tomu mohou být konvertory na optickou kabeláž pomˇernˇe jednoduchá a tedy i levná zaˇrízení, protože nemusí data v konvertoru serializovat. Uvažujeme tedy dále rozhraní skupiny SDI a rozhraní CoaXPress. Po SDI rozhraní lze pˇrenášet standardní formáty videa používané v televizním prumyslu, ˚ jejich pˇrehled je v tabulce 2.1 na stranˇe 13. Naproti tomu CoaXPress umožnuje ˇ pˇrenášet témˇerˇ libovolný formát videa, zejména pak formáty s vyšší snímkovací frekvencí než 60 FPS, což je nejvyšší hodnota, kterou souˇcasná rozhraní SDI podporují. Tato univerzálnost a orientace na prumyslové ˚ využití se však odráží v cenˇe a dostupnosti kamer, karet pro zachytávání videa a dalšího vybavení pro rozhraní CoaXPress. Zvýšila by se tím podstatnˇe nejen poˇrizovací cena systému jako celku, ale také údržba a pˇrípadné rozšíˇrení cˇ i upgrade video vybavení. V kapitole 1.2.3 na stranˇe 9 jsem stanovil na základˇe reálné situace v ledním hokeji minimální snímkovací frekvenci 37 FPS. Maximální snímkovací frekvenci SDI rozhraní 60 FPS je tak možné považovat za dostateˇcnou. Má samozˇrejmˇe smysl použít v sys15

2. D OSTUPNÉ TECHNOLOGIE tému vyšší snímkovací frekvenci, která by umožnila ještˇe pˇresnˇejší posouzení situace. V souˇcasné dobˇe by to nˇekolikanásobnˇe zvýšilo náklady systému, což je s ohledem na cílovou skupinu zákazníku, ˚ jimiž jsou menší hokejové kluby, nepˇrijatelné. Souˇcasnˇe je však vhodné ve zbytku systému poˇcítat s možným budoucím rozšíˇrením tímto smˇerem. V kapitole 1.2.2 na stranˇe 7 uvádím požadovaná rozlišení brankových kamer vzhledem k velikosti puku. Dostateˇcná rozlišení jsou Full HD i HD formáty, tedy vertikální rozlišení 1080 i 720. Pˇri snímkové frekvenci 60 FPS a formátu 720p potˇrebujeme vybavení podporující rozhraní HD-SDI. Pro vyšší rozlišení v HD-SDI pˇri stejné snímkové frekvenci bychom museli použít prokládaný formát 1080i. V úvodu této podkapitoly uvádím duvody ˚ proˇc není prokládaný formát pˇríliš vhodný pro zamýšlený systém. Pro použití formátu 1080p pˇri 60 snímcích za vteˇrinu už bychom museli pˇrejít na novˇejší rozhraní 3G-SDI. Karty k zachytávání HD-SDI videa jsou dostupné v modelech s vysokou hustotou vstupních konektoru˚ na jedné kartˇe a v pˇrijatelné cenové hladinˇe. Napˇríklad karta Blackmagic Decklink Quad se cˇ tyˇrmi vstupy/výstupy HD-SDI za necelý tisíc amerických dolaru, ˚ pˇrípadnˇe model Deltacast DELTA-hd-elp-d s osmi HD-SDI vstupy, jehož cena však není výrobcem zveˇrejnˇena. K zachytávání videa z 3G-SDI rozhraní jsou dostupné karty zpravidla s poloviˇcní hustotou vstupu˚ na jedné kartˇe, obvykle se dvˇema vstupy (napˇríklad model Blackmagic Decklink 4K Extreme), pˇrípadnˇe cˇ tyˇrmi vstupy (model Deltacast DELTA-3G-elp 40 ). Pˇrepoˇctená cena jednoho 3G-SDI vystupu v pˇrípadˇe Blackmagic Decklink karet je pˇresnˇe dvojnásobkem ceny jednoho vstupu HD-SDI. Z výše uvedených skuteˇcností jsem tedy pro uvažovaný systém zvolil vstupní rozhraní HD-SDI s použitím zachytávacích karet Blackmagic Decklink Quad a vstupní video ve formátu 720p pˇri 60 snímcích za vteˇrinu.

2.2 Komprese Video v nekomprimovaném formátu pˇredstavuje pomˇernˇe velké množství dat v závislosti na použitém video standardu. Napˇríklad video ve formátu HD 720p pˇri 60 snímcích za vteˇrinu má datový tok pˇribližnˇe 106 MB/s, hodina záznamu zabere pˇribližnˇe 370 GB místa na disku. To by v zamýšleném systému s více vstupy videa znamenalo velmi velké nároky na propustnost a kapacitu úložištˇe. Bude tedy zˇrejmˇe nutné zvolit vhodný zpusob ˚ komprese. V této podkapitole uvádím pˇrehled dostupných nástroju˚ ke kompresi videa. 16

2. D OSTUPNÉ TECHNOLOGIE 2.2.1 Požadavky Pˇri výbˇeru nástroju˚ se zamˇerˇ uji zejména na zpoždˇení pˇri kompresi, aby bylo možné video komprimovat v reálném cˇ ase. Použití pomalejšího kompresního nástroje by znamenalo nutnost ukládat video nekomprimované a komprimovat jej v prubˇ ˚ ehu nahrávání nebo až po dokonˇcení nahrávání. Vzhledem k povaze uvažovaného systému, který má umožnovat ˇ rychlé opakování pˇredchozích zábˇeru˚ v prubˇ ˚ ehu nahrávání, by taková komprese videa mˇela smysl zˇrejmˇe jen pro archivaˇcní úˇcely, internˇe by ale systém musel pracovat s nekomprimovaným videem, tedy s velkými objemy dat jak je zminováno ˇ výše. Dalším z požadavku˚ na kompresní algoritmus je nezávislost jednotlivých snímku˚ videa. Významné množství kompresních nástroju˚ pro zpracování videa využívá princip rozdílových snímku, ˚ kdy je uložen vždy jeden klíˇcový snímek (key-frame nebo také I-frame, intra-coded) a nˇekolik dalších snímku˚ obsahuje jen zmˇeny vuˇ ˚ ci pˇredchozímu snímku (P-frames, predicted) nebo vuˇ ˚ ci pˇredchozímu i následujícímu snímku (B-frames, bi-directional). Je to obecný princip, pro který existuje rˇ ada modifikací. Lze tímto dosáhnout lepšího kompresního pomˇeru, avšak pˇri pˇrehrávání je potˇreba napˇred najít a dekódovat klíˇcový snímek, dekódovat rozdílový snímek a z nich vytvoˇrit složením výsledný snímek videa. Je zˇrejmé, že uvedený postup dekomprese není pˇríliš vhodný pro náhodný pˇrístup doprostˇred video streamu. Obdobný postup se využívá i pˇri kompresi, což bývá cˇ asto pˇríˇcinou vyšší latence kodéru, zejména pˇri použití B-snímku. ˚ V úvodu zminuji, ˇ že systém bude firmou Daite nabízen komerˇcnˇe. Použité kompresní nástroje tedy musí být šíˇreny pod licencí, která umožnuje ˇ jejich použití v komerˇcním software bez nutnosti zveˇrejnit zdrojové kódy, jako jsou BSD licence, MIT licence, LGPL a další. Nˇekteré formáty videa mohou být navíc zatíženy patentovými poplatky pˇri jejich používání. I toto hledisko budu pˇri výbˇeru zohlednovat. ˇ Neménˇe duležitými ˚ vlastnostmi kompresních nástroju˚ je jednoduchost jejich použití a snadná integrovatelnost do zbytku systému. Výhodné je také zvolit kompresní formát s širokou škálou podporovaných rozlišení, a to i ruzných ˚ nestandardních, pro pˇrípad rozšíˇrení systému o nestandardní vstupní video formáty napˇríklad použitím vysokofrekvenˇcních kamer s rozhraním CoaXPress a další. 2.2.2 Dostupné nástroje Typickými pˇredstaviteli mezi–snímkových (inter-frame) kompresních formátu˚ jsou MPEG-4 a H.263, dále jejich nástupce, dnes hojnˇe využívaný formát H.264 nebo no17

2. D OSTUPNÉ TECHNOLOGIE vˇejší H.265 standardizovaný v roce 2013. Formát MPEG-4 (MPEG-4 Part 1 a MPEG-4 Part 14) byl navržen primárnˇe pro distribuci audio–video (AV) dat televizním vysíláním, uložení dat na DVD a podobnˇe. Byl tedy kladen duraz ˚ více na kvalitu komprese než na nízkou latenci. Zaˇcala tak vznikat rˇ ada rozšíˇrení standardu H.263 právˇe pro využití v systémech s nízkou latencí. Jejich nástupcem se stal formát H.264 (MPEG-4 Part 10). Formát H.264 nabízí profily optimalizované na kvalitu výsledného videa i na nízkou latenci kodéru. Je tedy možné použít jej i v aplikacích pro záznam videa v reálném cˇ ase. Profily s nízkou latencí nevyužívají všechny možnosti formátu, nízké latence a konstantního datového toku výstupního videa dosahují ruznými ˚ pokroˇcilými technikami jako napˇríklad rozložení klíˇcového snímku po sloupcích pˇres více snímku˚ (Periodic Intra Refresh) [13]. Toto platí pro volnˇe dostupnou implementaci (de)kodéru H.264 s názvem x264 [15]. Je šíˇrena pod licencí GNU GPL a komerˇcní licencí spravovanou x264 LLC a CoreCodec. Na použití komprese do formátu H.264 se také vztahují patentové poplatky za každou instalovanou realizaci [14]. Další skupinou video formátu˚ jsou takzvané intra-frame formáty. Pro porovnání s pˇredchozí skupinou formátu˚ mužeme ˚ oznaˇcit všechny snímky tˇechto formátu˚ za klícˇ ové, jinými slovy každý snímek videa je uložen jako kompletní statický obrázek. Jednotlivé snímky videa jsou na sobˇe plnˇe nezávislé, což maximálnˇe zjednodušuje a zrychluje náhodný pˇrístup ke snímku uprostˇred video streamu k pˇrehrání. Formáty využívající tento pˇrístup jsou napˇríklad Motion JPEG a Motion JPEG2000. Ke kompresi snímku˚ využívají kompresi JPEG v baseline formátu, respektive formát JPEG2000-Part 1. Na použití tˇechto formátu˚ se nevztahují žádné patentové poplatky. Existují implementace (de)kodéru˚ tˇechto formátu, ˚ které využívají akceleraci na grafických procesorech (GPU). V pˇrípadˇe JPEG formátu je to volnˇe dostupná knihovna GPUJPEG distribuovaná pod BSD licencí. Tato knihovna nabízí nízko–latenˇcní JPEG kompresi. Nízká latence komprese je v tomto pˇrípadˇe dosažena omezenou nároˇcností výpoˇctu, kdy není nutné vypoˇcítávat rozdílové snímky, a naproti tomu vysokou výpocˇ etní kapacitou na GPU. Implementace využívá technologii CUDA, je tedy nutné použít grafický cˇ ip výrobce NVIDIA.

2.2.3 Výbˇer komprese Pˇri výbˇeru komprese pro použití v uvažovaném systému byl kladen nejvˇetší duraz ˚ na nezávislost snímku˚ daného video formátu. Možnost pracovat se snímky uvnitˇr systému nezávisle vnáší do systému jednoduchost a také minimalizuje latenci pˇri práci 18

2. D OSTUPNÉ TECHNOLOGIE s již zkomprimovanými snímky, zejména umožnuje ˇ snadno a rychle pˇristoupit ke kompletnímu snímku videa v urˇceném místˇe záznamu, což je pro zamýšlený systém, ve kterém bude ve videu cˇ asto vyhledáváno a pˇreskakováno, dle mého názoru klíˇcovou vlastností. Z uvedených formátu˚ toto splnují ˇ formáty Motion JPEG a Motion JPEG2000. Rozhodl jsem se použít první jmenovaný formát Motion JPEG a jako kompresní nástroj použít GPUJPEG. Oproti JPEG2000 má JPEG nižší výpoˇcetní nároky a je šíˇren volnˇe pod BSD licencí, díky cˇ emuž je nástroj možné použít i v projektu s nezveˇrejnˇeným zdrojovým kódem. Oproti ostatním zmínˇených formátum, ˚ jako jsou MPEG-4, H.264 a další, nabízí Motion JPEG kromˇe nezávislých snímku˚ a z principu nižší latence ještˇe další výhody. Na formát JPEG baseline se nevztahují žádná patentová omezení a poplatky, což zjednodušuje distribuci systému jako celku a také pochopitelnˇe snižuje jeho cenu. Tento formát podporuje všechna rozlišení obrazu, i ty, které jsou v oblasti zpracování videa nestandardní a nebrání tak pˇrípadnému budoucímu rozšíˇrení systému o video vstupy s nestandardním nebo velmi vysokým rozlišením (4K, 5K, 6K, 8K). Nevýhodou formátu Motion JPEG muže ˚ být jeho horší kompresní pomˇer v porovnání s H.264 a tedy vˇetší potˇrebná kapacita pro uložení zkomprimovaných video dat. Vzhledem k tomu, že systém využívá video záznam pouze internˇe, vˇetší velikost záznamu nepˇredstavuje velký problém a spíše upˇrednostníme nezávislost snímku˚ a latenci. Naopak formát H.264 mužeme ˚ s výhodou použít pro funkci exportu uživatelem vybraných klipu˚ k postprodukci. Možnost exportu byla do systému pˇridána v prubˇ ˚ ehu jeho rˇ ešení jako rozšíˇrení, které uživateli umožní ze systému po skonˇcení zápasu získat vybrané klipy na zvolené externí úložištˇe. Zde již má smysl použít formát s obecnˇe vyšším kompresním pomˇerem, jakým je napˇríklad formát H.264. Pˇri exportu již zaznamenaného videa není nutné zkomprimovat záznam v urˇcitém cˇ ase, muže ˚ být tedy použit profil kodéru, který je optimalizován na kvalitu a velikost výstupního videa místo použití nízko–latenˇcního profilu, kde musí být rˇ ada optimalizací kodéru vypnutá. Samozˇrejmˇe je potom nutné poˇcítat s patentovými a licenˇcními poplatky za používání H.264 formátu pˇri exportu záznamu˚ ze systému.

19

2. D OSTUPNÉ TECHNOLOGIE

2.3 Použité technologie V této cˇ ásti nabízím struˇcný pˇrehled technologií a nástroju, ˚ které budou v systému použity. Vstupní video bude zachytáváno na kartách Blackmagic Decklink. Výrobce k ovládání tˇechto karet dodává Decklink SDK pro programovací jazyk C++ a ovladaˇce pro operaˇcní systémy Windows, Mac OS i Linux [17]. Zejména podpora na Linuxu založených operaˇcních systému˚ nebývá všemi výrobci karet pro zachytávání videa nabízena. Karty Blackmagic Decklink jsou však na Linuxu podporovány v plném rozsahu. Kromˇe zachytávání videa umožnují ˇ používané karty také pˇrehrávání na SDI výstup s možností klíˇcování pruhlednosti, ˚ tzv. alfa kanálu. Pro video výstup ze systému na velkoplošné obrazovky lze tedy využít stejnou technologii jako pro zachytávání snímku. ˚ Jako interní kompresní formát videa jsem zvolil Motion JPEG. Ke kompresi a dekompresi bude systém využívat knihovnu GPUJPEG [18]. Tato knihovna je napsána v jazyce C s využitím technologie CUDA pro akceleraci výpoˇctu na grafické kartˇe. V systému je tedy nutné mít nainstalovánu grafickou kartu, která podporuje technologii CUDA. S ohledem na výše uvedené nástroje jsem pro implementaci systému zvolil programovací jazyk C/C++. Upˇrednostnovaný ˇ operaˇcní systém pro zamýšlenou aplikaci je Linux. Jelikož jsou Decklink karty, CUDA i GPUJPEG dobˇre podporované na Linuxu, byl tento systém zvolen pro implementaci i následné nasazení. Pro tvorbu grafického uživatelského rozhraní (GUI) jsem zvolil knihovnu Qt [22] ve verzi 5.0, která používá programovací jazyk C++ a nabízí platformnˇe nezávislý pˇrístup nejen k tvorbˇe GUI, ale i k dalším funkcím jako je správa vláken, zámku, ˚ pˇrístup k souborum ˚ a podobnˇe. Použití této multi platformní knihovny usnadní pˇrípadné budoucí rozšíˇrení systému další operaˇcní systémy.

20

Kapitola 3

Architektura systému Pˇri návrhu architektury systému, který zpracovává velké množství dat, což bezesporu systém pro ukládání a pˇrehrávání videa z více kamer souˇcasnˇe je, je nutné provést analýzu propustnosti jednotlivých klíˇcových cˇ ástí systému. Jako klíˇcové cˇ ásti jsem stanovil pˇríjem a kompresi videa, dále pak ukládání na disk a koneˇcnˇe pˇrehrávání videa ze záznamu. Protože má výsledný systém zvládnout všechny jmenované úkoly, v dalším kroku zhodnotím propustnost systému jako celku a stanovím maximální objem vstupních dat. Potom bude možné vytvoˇrit schéma systému a stanovit jeho minimální požadavky.

3.1 Analýza požadavku˚ na propustnost Pˇri cestˇe zpracování dat mohou vznikat úzká místa limitující výkon systému jako celku. Cílem této podkapitoly je tato úzká místa najít, navrhnout, jak je eliminovat nebo stanovit limit systému, pokud už je více eliminovat nelze. 3.1.1 Vstupní video Nekomprimované snímky z karty pro zachytávání videa je nutné pˇrenést po systémové sbˇernici PCI Express (PCIe) do operaˇcní pamˇeti a následnˇe po téže sbˇernici do pamˇeti grafické karty ke kompresi. Po dokonˇcení komprese ještˇe musíme pˇrenést zkomprimovaná data zpˇet do operaˇcní pamˇeti po PCIe sbˇernici. Maximální pˇrenosová rychlost po PCIe sbˇernici je 250 MB/s pro jeden lane v jednom smˇeru v pˇrípadˇe PCIe v.1, dvojnásobná v pˇrípadˇe PCIe v.2. Tˇretí generace PCIe sbˇernice nabízí oproti pˇredchozí generaci opˇet zdvojnásobení rychlosti pˇrenosu až na pˇribližnˇe 1 GB/s [23]. Pˇri použitém video formátu HD 720p@60 FPS a kódování obrazových dat YUV s podvzorkováním 4:2:2 s barevnou hloubkou 8 bitu˚ dosahuje datový tok ze zachytávací karty pˇribližnˇe 106 MB/s obrazových dat. Formát pixelu˚ YUV 4:2:2 kóduje 2 pixely na 4byty, tedy 2B na každý obrazový bod pˇri barevné hloubce 8 bitu. ˚ Pˇri 21

3. A RCHITEKTURA SYSTÉMU použití dalšího formátu pixelu, ˚ který karta pro zachytávání videa nabízí, formát pixelu˚ RGBA bez podvzorkování (RGBA 4:4:4), je pˇri osmibitové barevné hloubce datový tok dvojnásobný, tedy pˇribližnˇe 211 MB/s na jeden vstup. Pˇri 10 bitové barevné hloubce zustává ˚ datový tok stejný stejný jako v pˇrípadˇe RGBA 4:4:4, není ale pˇrenášen kanál alfa [17]. V následujícím kroku dochází k pˇrenosu nekomprimovaného snímku na grafickou kartu ke kompresi. Potˇrebná šíˇrka pásma sbˇernice je stejná jako v pˇredchozím pˇrípadˇe pˇri pˇrenosu ze zachytávací karty, tedy pˇribližnˇe 106 MB/s pro jeden video vstup YUV 4:2:2, respektive 211 MB/s pro vstup RGBA 4:4:4. Výstupní datový tok zkomprimovaných dat z grafické karty pˇri použití kompresního nástroje GPUJPEG literatura uvádí v rozmezí 3,4 MB/s až 62 MB/s v závislosti na nastavení kvality komprese [19]. Rozdíl velikosti zkomprimovaného snímku pˇri kvalitˇe Q = 90 a nejvyšší kvalitˇe Q = 100 je dle dostupných mˇerˇ ení [18][19] více než dvojnásobný. Pˇri kvalitˇe Q = 90 mužeme ˚ tedy poˇcítat s datovým tokem pˇribližnˇe 31 MB/s. Uvedené hodnoty platí pro podvzorkované video s rozlišením 1080p pˇri 30 FPS. Množství zpracovaných obrazových bodu˚ takového videa je prakticky stejné jako v pˇrípadˇe videa s rozlišením 720p pˇri 60 FPS, je tedy možné uvažovat pˇribližnˇe stejné hodnoty. Dále v práci uvažuji datový tok videa v plné kvalitˇe 62 MB/s jako nejhorší pˇrípad. Doba potˇrebná pro kompresi 1080p snímku akcelerovaná na GPU s použitím knihovny GPUJPEG se udává 2,91 ms až 4,45 ms v závislosti na nastavené kvalitˇe komprese, formátu pixelu˚ vstupních dat a modelu grafického cˇ ipu, testováno na NVIDIA GTX 580 [19]. Uvedené hodnoty zahrnují dobu kopírování dat do pamˇeti GPU, samotný výpoˇcet a kopírování dat zpˇet do operaˇcní pamˇeti. Pro snímky s rozlišením 720p je možné poˇcítat s kratší dobou komprese, pˇresné hodnoty však nelze urˇcit pˇrímou úmˇerou k velikosti obrazu. Poˇcítám tedy s pesimistickým odhadem trvání komprese pˇribližnˇe 4 ms na snímek RGB 4:4:4, 3,6 ms na snímek YUV 4:2:2. Hodnoty jsou odeˇcteny z grafu˚ mˇerˇ ení výkonu GPUJPEG komprese [19]. Celkovˇe tedy dosahuje datový tok pˇres PCIe sbˇernici pˇri pˇríjmu a kompresi jednoho video vstupu s formátem pixelu˚ YUV 4:2:2 hodnotu pˇribližnˇe 274 MB/s. Datový tok je rozdˇelen do tˇrí pˇrenosu, ˚ z karty pro záchyt videa (106 MB/s), na grafickou kartu (106 MB/s) a z grafické karty (62 MB/s).

3.1.2 Ukládání Pro ukládání zkomprimovaného videa v nejvyšší kvalitˇe je tˇreba uvažovat rychlost zápisu na disk alesponˇ velikosti 62 MB/s, což je nejvyšší uvažovaný datový tok z grafické 22

3. A RCHITEKTURA SYSTÉMU karty provádˇející kompresi snímku˚ pˇri nejvyšší kvalitˇe komprese. Vysokorychlostní pevné disky (napˇríklad Seagate Cheetah 15K.7 s 15.000 otáˇckami) dosahují rychlosti zápisu až 204 MB/s. Už pro cˇ tyˇri video vstupy by ale tato rychlost nedostaˇcovala ani pro samotné ukládání záznamu. U rotaˇcních disku˚ je navíc nutné uvažovat jisté zpoždˇení zpusobení ˚ cˇ ekáním na vystavení hlaviˇcek disku a otoˇcení ploten pˇri soubˇežném ukládání více video streamu. ˚ Je také nutné rezervovat stejnˇe velkou šíˇrku pásma pro naˇcítání videa k pˇrehrání jako pˇri ukládání záznamu, uvažujeme-li soubˇežné ukládání a naˇcítání video záznamu, ˚ protože rotaˇcní disky neumožnují ˇ zapisovat a cˇ íst z ruzných ˚ míst na disku souˇcasnˇe a obˇe operace musí být provádˇeny postupnˇe. Pˇri soubˇežném záznamu na disk a pˇrehrávání z jiné cˇ ásti disku bychom mohli spolehlivˇe pracovat jen s jedním video vstupem. Použitím SSD disku (napˇríklad Intel SSD 530 series) mužeme ˚ poˇcítat s rychlostí zápisu až 490 MB/s a cˇ tením až 540 MB/s. Odpadá také cˇ ekání na vystavování hlaviˇcek disku a je možné soubˇežné cˇ tení a zápis. Teoreticky by tak bylo možné dosáhnout zápisu a souˇcasného cˇ tení až sedmi video streamu˚ na jeden disk v maximální kvalitˇe. Kapacita 480 GB na disku by pˇri sedmi vstupech staˇcila na záznam pˇribližnˇe 19 minut videa v plné kvalitˇe. Hokejový zápas bˇežnˇe trvá dvˇe až tˇri hodiny, ani takto bychom se tedy nevyhnuli stavbˇe jistˇe velice nákladného diskového pole s vysokou propustností a kapacitou. Jak uvádím v první kapitole, není nutné ukládat záznam celého zápasu. Postaˇcující je záznam tˇech situací, které jsou z pohledu rozhodˇcích zajímavé a rozhodující pro posouzení gólu˚ a asistencí. Takových situací bývá jednotky až desítky za zápas. Navrhl jsem tedy proto kruhový buffer v operaˇcní pamˇeti, který ukládá jen urˇcitý potˇrebný poˇcet vteˇrin záznamu, nejnovˇejší snímky pˇrepisují nejstarší snímky v bufferu. Uživatel, videorozhodˇcí, potom muže ˚ pˇri významné události pˇri hˇre uložit aktuální obsah bufferu na disk a získat tak dlouhodobý záznam události, která se právˇe stala. Tímto je možné ušetˇrit místo na disku uložením pouze zajímavých úseku˚ zápasu. Požadavky na rychlost disku zustávají ˚ stejné jako v pˇrípadˇe ukládání celého záznamu. Obsah kruhového bufferu totiž musí být uložen alesponˇ tak rychle, jako je jeho délka. Pokud by byl zápis na disk pomalejší než záznam všech video vstupu, ˚ muselo by se pˇri záznamu nových snímku˚ cˇ ekat na dokonˇcení zápisu na disk a systém by musel zaˇcít zahazovat snímky. Možným rˇ ešením pˇri nedostateˇcné rychlosti zápisu na disk by mohl být postup, kdy pˇri požadavku na uložení obsahu bufferu je jeho obsah napˇred zkopírován na jiné místo v operaˇcní pamˇeti a odtud potom ukládán na pomalé diskové úložištˇe aniž by tím byl ovlivnˇen zápis nových snímku˚ do kruhového bufferu. Datový tok novˇe pˇrícho23

3. A RCHITEKTURA SYSTÉMU zích snímku, ˚ respektive poˇcet vstupu˚ systému, by potom byl omezen rychlostí kopie dat uvnitˇr operaˇcní pamˇeti. Napˇríklad v souˇcasné dobˇe nejrychlejší pamˇet’ové moduly DDR3-1600 dosahují propustnosti 12,5 GB/s [25], což je dostateˇcnˇe vysoká hodnota. Ukládání na disk by potom mohlo trvat obecnˇe libovolnˇe dlouho. Toto rˇ ešení by však také nebylo ideální. Pˇri každém dalším požadavku na uložení obsahu bufferu v pru˚ bˇehu probíhajícího dlouhého zápisu na disk pˇredchozího klipu by musela být vytvorˇ ena další kopie obsahu bufferu v operaˇcní pamˇeti. Nabízí se v tomto pˇrípadˇe také rˇ ešení alokovat nový kruhový buffer, do kterého by se novˇe pˇríchozí snímky zapisovaly a puvodní ˚ buffer po dokonˇcení zápisu na disk uvolnit z pamˇeti. V obou pˇrípadech by však mohlo dojít k vyˇcerpání volné operaˇcní pamˇeti a systém by již nemohl novˇe pˇríchozí snímky ukládat. Je tedy nutné uvažovat i s použitím bufferu dostateˇcnou propustnost disku pro ukládání všech vstupu˚ jako v pˇrípadˇe ukládání celého video záznamu. Požadavky na uložení obsahu bufferu, které pˇrijdou za kratší dobu než je délka videa v bufferu, znamenají zbyteˇcné redundantní uložení cˇ ásti videa. Pˇríchozí požadavky v prubˇ ˚ ehu ukládání pˇredchozího klipu tedy mužeme ˚ vykonat až po dokonˇcení pˇredchozí operace, cˇ ímž tuto redundanci snížíme. Uložení video klipu o chvíli pozdˇeji tolik nevadí, pokud je pˇredchozí video klip uložen za kratší dobu než je délka jeho video záznamu. V tabulce 3.1 uvádím, jaký nejvyšší poˇcet vstupu˚ videa je vzhledem k propustnosti daného úložištˇe možný a jak dlouhý záznam kapacita daného úložištˇe umožnuje. ˇ Uvažuji soubˇežné nahrávání i pˇrehrávání video klipu. ˚ V pˇrípadˇe zápisu do kruhového bufferu v operaˇcní pamˇeti zohlednuji ˇ všechny pˇrenosy z a do operaˇcní pamˇeti, které musí systém vykonávat. 3.1.3 Pˇrehrávání Systém musí mít dostateˇcný výkon na pˇrehrávání záznamu˚ ze všech kamer na monitoru poˇcítaˇce souˇcasnˇe a pˇrehrávání jednoho z tˇechto záznamu˚ také na výstupním SDI rozhraní. Pˇri pˇrehrávání videa ze záznamu musí být zkomprimované JPEG snímky videa naˇcteny z disku, nahrány na grafickou kartu k dekompresi a již jako nekomprimované snímky nahrány zpˇet do operaˇcní pamˇeti k dalšímu zpracování, tedy k zobrazení na monitoru poˇcítaˇce v OpenGL a pˇrípadnˇe i k odeslání na výstupní SDI kartu. Nahrávání záznamu z disku není cˇ asovˇe kritickou operací pro správnou funkci systému. S rostoucím poˇctem vstupu˚ videa roste pouze cˇ as potˇrebný k naˇctení záznamu˚ 1. V závorce jsou uvedeny maximální hodnoty pˇri použití kruhového bufferu a ukládáním na uvedený SSD disk v tabulce.

24

3. A RCHITEKTURA SYSTÉMU HDD Seagate Cheetah 15K.7 204 MB/s, 600 GB

SSD Intel SSD 530 490 MB/s, 480 GB

RAM-kruh. buffer DDR3-1600 12,5 GB/s, 32 GB

1

7

19 (71 )

záznam pˇri max. poˇctu vstupu˚

55 min

19 min

27 sec (75 sec1 )

délka záznamu jednoho vstupu

166 min

133 min

8,8 min

maximální vstupu˚

poˇcet

Tabulka 3.1: Maximální poˇcet video vstupu˚ pˇri souˇcasném nahrávání a pˇrehrávání a délka záznamu pro vybrané typy úložišt’.

a jejich celková velikost. Ovlivní se tím pouze rychlost odezvy systému pˇri naˇcítání klipu, ˚ záznam novˇe pˇríchozího videa tím ale není ovlivnˇen, protože pˇri nahrávání záznamu uvažuji zápis do kruhového bufferu v operaˇcní pamˇeti a disk tedy není využíván. Pro nahrávání komprimovaných snímku˚ na grafickou kartu k dekompresi platí obdobné požadavky jako pro kopírování zkomprimovaných dat z karty v cˇ ásti 3.1.1. Rozdílná je doba potˇrebná k dekompresi, která více závisí na nastavené kvalitˇe dekomprese. Pˇri kvalitˇe Q ≤ 90 je doba dekomprese pˇribližnˇe stejná jako doba komprese, zaˇcíná na hodnotˇe 2,78 ms pˇri Q = 10, pˇribližnˇe 4 ms pˇri Q = 90. Pˇri nastavení vyšší kvality dojde k výraznému prodloužení doby dekomprese, pro 1080p snímky až na 5,78 ms [19]. Pro snímky 720p je opˇet možné poˇcítat menšími hodnotami, které však nelze pˇresnˇe urˇcit z mˇerˇ ení uvedeného na 1080p snímcích a poˇcítám tak opˇet s nejhorším pˇrípadem trvání dekomprese pˇri maximální kvalitˇe 5,78 ms. Pˇrenos dekomprimovaných dat z grafické karty vyžaduje opˇet stejný datový tok jako již zmínˇené nahrávání dat na grafickou kartu pˇri kompresi v cˇ ásti 3.1.1. Pro pˇrehrávání tedy uvažujeme datové toky 62 MB/s pˇri nahrávání dat z disku do operaˇcní pamˇeti, 62 MB/s pˇri nahrávání k dekompresi na grafickou kartu a 106 MB/s pˇri pˇrenosu dekomprimovaných dat. Celkovˇe tedy na jedno pˇrehrávané video potˇrebujeme pˇrenést pˇribližnˇe 230 MB/s dat pˇres PCIe sbˇernici. Doba dekomprese jednoho snímku je až 5,78 ms. 25

3. A RCHITEKTURA SYSTÉMU 3.1.4 Zobrazení a SDI výstup Systém má zobrazovat náhledy videa jak novˇe pˇríchozího živého videa, tak i pˇrehrávaného ze záznamu. Pˇri pˇrehrávání záznamu není nutné zobrazovat i aktuální živé video, vždy jsou tedy zobrazovány bud’ živé snímky videa nebo snímky ze záznamu. K zobrazení na monitoru potˇrebujeme snímek nahrát na grafickou kartu jako texturu. Do textury nahráváme již nekomprimovaná data. Je tedy tˇreba pˇrenést na grafickou kartu pˇribližnˇe 158 MB/s obrazových dat formátu RGB 4:4:4, respektive 106 MB/s dat v pˇrípadˇe použití formátu YUV 4:2:2 pro každé zobrazované video. V pˇrípadˇe, že je pro vykreslování použita stejná grafická karta jako pro CUDA kompresi cˇ i dekompresi, je tˇreba poˇcítat se znatelným snížením rychlosti komprese, protože karty zpravidla neumožnují ˇ souˇcasné vykreslování grafické scény a soubˇežný výpoˇcet CUDA kernelu [24]. Na SDI výstup ze systému se vždy posílá právˇe jeden video stream. Datový tok pro upload na odesílací SDI kartu je tedy konstantní nezávisle na poˇctu video vstupu˚ do systému. Po PCIe sbˇernici je nutno pˇrenést 106 MB/s dat formátu YUV 4:2:2. Pruhledný ˚ obsah pˇres výstupní video je na odesílací kartu nahráván v rozlišení pro formát PAL (720 x 576 bodu) ˚ s formátem pixelu˚ RGBA. Toto rozlišení je vzhledem k parametrum ˚ velkoplošných LED obrazovek, pro které je výstup urˇcen, plnˇe dostaˇcující. Datový tok pˇres sbˇernici potˇrebný pro klíˇcování výstupu dosahuje hodnoty pˇribližnˇe 40 MB/s. 3.1.5 Vyhodnocení propustnosti V tabulce 3.3 uvádím pˇrehled požadavku˚ jednotlivých komponent systému pro ruzné ˚ kombinace poˇctu a formátu vstupu˚ videa. Uvádím vždy propustnost vyžadovanou danou cˇ ástí systému, pˇrípadnˇe i cˇ as, který je souˇctem doby komprese cˇ i dekomprese snímku všech video vstupu. ˚ V pravém sloupci je uvedena celková nutná propustnost pˇres sbˇernici pokud by mˇel systém obsluhovat všechny zamýšlené funkce a nejmenší poˇcet grafických karet, které by bylo v dané konfiguraci tˇreba použít. Možnosti rozšíˇrení na více vstupu˚ budou diskutovány dále. ˇ potˇrebný pro kompresi a dekompresi snímku, Cas ˚ ze kterého vycházím pˇri urˇcování potˇrebného poˇctu grafických karet, vychází z mˇerˇ ení na kartˇe s grafickým cˇ ipem NVIDIA GTX 580. Dnes dostupný hardware nabízí vyšší výkon, tabulka 3.2 srovnává parametry zmínˇeného modelu grafického cˇ ipu s modelem NVIDIA GTX TITAN. U novˇejšího modelu GTX TITAN si mužeme ˚ všimnout více než pˇetinásobného zvýšení poˇctu CUDA výpoˇcetních jader, o polovinu vyšší propustnosti pamˇeti a použití rychlejší PCIE sbˇernice oproti modelu, na kterém bylo provádˇeno mˇerˇ ení. Mužeme ˚ tak poˇcítat s urˇcitým snížením celkové doby komprese a dekomprese, pˇribližnˇe dvojnásobnˇe vzhledem 26

3. A RCHITEKTURA SYSTÉMU k tomu, že lze použitím výkonnˇejší grafické karty urychlit jen ty cˇ ásti kompresoru, které jsou provádˇeny na GPU a pˇrenosy mezi pamˇetí GPU a CPU. Pˇri hodnocení systému v tabulce 3.3 ale vycházím z pˇresnˇejších hodnot mˇerˇ ení na GTX 580, možné konfigurace systému s GTX TITAN diskutuji pouze v dalším textu.

poˇcet CUDA jader velikost pamˇeti propustnost pamˇeti sbˇernice

NVIDIA GTX 580 [20] 512 1536 MB 192,4 GB/s PCI-E 2.0 x16

NVIDIA GTX TITAN [21] 2688 6144 MB 288,4 GB/s PCI-E 3.0

Tabulka 3.2: Srovnání parametru˚ grafických karet NVIDIA GTX 580 a NVIDIA TITAN. Z tabulky 3.3 je zˇrejmé, že už systém se cˇ tyˇrmi vstupy videa vyžaduje alesponˇ tˇri grafické karty. Není to dáno nedostateˇcnou propustností sbˇernic, ale délkou trvání výpoˇctu pˇri kompresi na tˇechto kartách. Pˇri snímkovací frekvenci 60 FPS je teoreticky nejdelší možná doba komprese snímku˚ ze všech kamer 16,67 ms. V pˇrípadˇe komprese nevzniká žádný problém a výpoˇcetní kapacita jedné grafické karty dostaˇcuje. Doba dekomprese je však 23,12 ms, tedy ji nelze provádˇet na jedné grafické kartˇe, ale je nutné do systému pˇridat další grafickou kartu. Pokud bychom chtˇeli i dekompresi provádˇet na jedné GPU kartˇe nabízí se nˇekolik možností. Uvedená doba dekomprese platí pˇri nastavené nejvyšší kvalitˇe. Jak uvádím v kapitole 3.1.3, už pˇri kvalitˇe Q = 90 je možné poˇcítat s podstatnˇe kratší dobou dekomprese než pˇri plné kvalitˇe, 4 ms. První možností je tedy mírné snížení kvality dekomprese. Pro zobrazení náhledu˚ videa v uživatelském rozhraní však potˇrebujeme stále jednu grafickou kartu navíc, protože obˇe (kompresní i dekompresní) jsou již plnˇe využívány. Druhá možnost spoˇcívá ve snížení zobrazovací frekvence pˇri pˇrehrávání. Napˇríklad pˇri zobrazování záznamu s frekvencí 25 snímku˚ za vteˇrinu získáváme cˇ asové kvantum pro dekompresi 40 ms. Pˇri této frekvenci snímku˚ se obraz videa jeví dostateˇcnˇe plynulý. Pˇri zpomaleném pˇrehrání bychom mˇeli stále možnost vidˇet všechny snímky videa porˇ ízeného s 60 FPS. Grafická karta pro dekompresi by potom mohla být využita na ménˇe než 50% výkonu a mohla by být využita i pro zobrazování OpenGL scény. Tato konfigurace je však spíše nouzovým rˇ ešením pokud chceme z urˇcitého duvodu ˚ používat jen dvˇe grafické karty v celém systému. Lépe by bylo osadit systém jednou 27

3. A RCHITEKTURA SYSTÉMU poˇcet formát vstupu˚ pixelu˚ 4 YUV 4:2:2 4 RGBA 4:4:4 8 YUV 4:2:2 8 RGBA 4:4:4 12 YUV 4:2:2 12 RGBA 4:4:4

pˇríjem a komprese 1096 MB/s 14,4 ms 1936 MB/s 16 ms 2192 MB/s 28,8 ms 3872 MB/s 32 ms 3288 MB/s 43,2 ms 5808 MB/s 48 ms

zobrazení a výstup 570 MB/s

ukládání na disk 248 MB/s

1095 MB/s

248 MB/s

994 MB/s

496 MB/s

1939 MB/s

496 MB/s

1418 MB/s

744 MB/s

2783 MB/s

744 MB/s

pˇrehrávání

celkem

920 MB/s 23,12 ms 1340 MB/s 23,12 ms 1840 MB/s 46,3 ms 2680 MB/s 46,3 ms 2760 MB/s 69,4 ms 4020 MB/s 69,4 ms

2,77 GB/s 3xGPU 4,51 GB/s 3xGPU 5,39 GB/s 6xGPU 8,78 GB/s 6xGPU 8,02 GB/s (8xGPU) 13,04 GB/s (8xGPU)

Tabulka 3.3: Pˇrehled odhadovaných propustností jednotlivých komponent

grafickou kartou dedikovanou pro OpenGL vykreslování navíc a komprimovat i dekomprimovat s plnou snímkovací frekvencí na dvou dalších grafických kartách. Další, byt’ jeden, vstup videa navíc by znamenal nutnost rozložit i kompresi na dvˇe grafické karty. Ve skuteˇcnosti by se však musely pˇridat dva vstupy – ke každé ze dvou hokejových branek jedna kamera navíc, aby byly u obou branek stejné podmínky. Výsledných 6 vstupu˚ by bylo možné na dvou grafických kartách komprimovat, dekomprese by však i pˇri 25 FPS vytížila celou grafickou kartu a systém by bylo nutné rozšíˇrit o další grafický cˇ ip pro zobrazování videa. Celkovˇe by v systému musely být instalovány cˇ tyˇri grafické karty. Pˇri použití výkonnˇejších karet GTX TITAN by nemˇel být problém komprimovat všech šest vstupu˚ na jedné kartˇe, stejnˇe tak v pˇrípadˇe dekomprese. Ukládání záznamu videa s datovým tokem 372 MB/s je ještˇe možné na jeden SSD disk. Na jednom poˇcítaˇci je teoreticky možné dosáhnout nahrávání a pˇrehrávání i osmi video vstupu. ˚ Systém už ale musí být osazen celkem šesti grafickými kartami, dvˇema pro kompresi, tˇremi pro dekompresi a jednou pro vykreslování videa v OpenGL. V konfiguraci s grafickými kartami GTX TITAN by mˇela být komprese i dekomprese teoreticky možná na dvou grafických kartách, tuto konfiguraci by však bylo nutné pˇredem otestovat vzhledem k absenci výkonnostních mˇerˇ ení GPUJPEG na tˇechto kartách. Dále je tˇreba zapoˇcítat karty pro zachytávání vstupního videa a jednu výstupní SDI kartu. 28

3. A RCHITEKTURA SYSTÉMU V této konfiguraci by již bylo zˇrejmˇe nutné použít systém s více fyzickými procesory. K jednomu procesoru je PCIe sbˇernice pˇripojena nejvýše 40 linkami (lanes) [26]. Grafické karty bˇežnˇe komunikují na šestnácti nebo osmi linkách, takže by musel být systém postaven alesponˇ na dvouprocesorové platformˇe. Pˇrestává zde staˇcit už i rychlost zápisu na SSD disk a bylo by tak tˇreba sestavit diskové pole kvuli ˚ zvýšení rychlosti zápisu, což je pˇri požadované propustnosti 496 MB/s pomˇernˇe snadno rˇ ešitelné. Nahrávání a pˇrehrávání dvanácti vstupu˚ videa souˇcasnˇe je teoreticky možné na poˇcítaˇci s osmi grafickými kartami (ˇctyˇrmi v pˇrípadˇe použití GTX TITAN) a alesponˇ dvˇema fyzickými procesory, aby byl zajištˇen dostateˇcný poˇcet linek PCIe sbˇernice pro všechny grafické karty a karty pro zachytávání videa. Celkový objem pˇrenášených dat uvnitˇr systému dosahuje až 13 GB/s, což už je za hranicí propustnosti dnešních operaˇcních pamˇetí na jednoprocesorových systémech (DDR3-1600 s propustností 12,5 GB/s ve špiˇcce [25]) a i z tohoto duvodu ˚ je nutné pˇrejít na platformu s dvˇema fyzickými procesory. Pro rozšíˇrení na více vstupu˚ je již dál vhodné jít cestou distribuovaného zpracování na více strojích. Vznikají tím další netriviální problémy k rˇ ešení, napˇríklad distribuce zkomprimovaného videa mezi jednotlivými stroji nebo rˇ ešení sdíleného centrálního úložištˇe s dostateˇcnou propustností a kapacitou. V dalším textu tedy budeme uvažovat systém se cˇ tyˇrmi video vstupy z kamer pˇres rozhraní SDI ve formátu HD 720p se snímkovací frekvencí nastavitelnou v rozsahu 50 až 60 FPS. Tento systém bude umožnovat ˇ nahrávání, pˇrehrávání i zobrazování videa. Internˇe bude pracovat se snímky ve formátu YUV 4:2:2, tedy s podvzorkovanou barevnou složkou obrazu, což pro zamýšlený systém plnˇe dostaˇcuje a snížíme tím objem pˇrenášených dat po systémové sbˇernici. Snímání cˇ tyˇrmi kamerami v souˇcasné dobˇe vyˇ hovuje požadavkum ˚ ze strany CSLH a zárovenˇ umožnuje ˇ sestavit systém z komoditních komponent.

3.2 Grafické uživatelské rozhraní Jedním z požadavku˚ na systém bylo jednoduché ovládání vhodné i pro uživatele, kteˇrí nejsou profesionálové v oblasti zpracování videa. K naplnˇení tohoto požadavku je možno použít nˇekolik prostˇredku, ˚ které nyní postupnˇe popíšu. Prvním z nich je požití dotykového ovládání. Uživatelé jsou v dnešní dobˇe na tento typ interakce s programy zvyklí pˇredevším z mobilních zaˇrízení. Kromˇe toho, že je dotykové ovládání pro uživatele obecnˇe intuitivnˇejší než používání myši cˇ i klávesových 29

3. A RCHITEKTURA SYSTÉMU zkratek, je také velmi rychlé. Bude také možné používat nˇekterá intuitivní dotyková gesta, napˇríklad pˇribližování videa roztažením dvˇema prsty (gesto známé pod názvem pinch-to-zoom). Dalším prostˇredkem ke zjednodušení ovládání jsou náhledy všech video vstupu˚ pˇrímo v grafickém rozhraní aplikace. Uživatel tak muže ˚ sledovat hru na všech cˇ tyˇrech zábˇerech kamer aniž by musel zamˇerˇ ovat svoji pozornost jinam než na samotnou aplikaci. Všechny ovládací nástroje aplikace má neustále v zorném poli na monitoru. Stˇrih jednotlivých vstupu˚ videa prostým klepnutím pˇrímo na video z kamery, kterou chci pˇrepnout na výstup, je také velmi pˇrímoˇcaré. K dosažení vyšší pˇrehlednosti rozhraní byly jednotlivé ovládací prvky rozmístˇeny tak, aby byly viditelné po celou dobu bˇehu aplikace a aby nemusela být využita žádná dialogová okna, menu, rozbalovací seznamy a podobnˇe. Rozmístˇení ovládacích prvku˚ je vidˇet na obrázku 3.1.

Obrázek 3.1: Snímek obrazovky výsledné aplikace (zde v režimu Replay bˇehem pˇrípravy playlistu pro pˇrehrání na výstupním rozhraní, na obrázku pˇridány dvˇe videa v playlistu).

30

3. A RCHITEKTURA SYSTÉMU 3.2.1 Rozložení ovládacích prvku˚

Aplikaci jsem navrhl tak, aby oddˇelovala dva režimy, režim Live a režim Replay, tedy režim živého videa, respektive pˇrehrávací režim. Základní rozložení ovládacích prvku˚ je v obou režimech stejné. V režimu Live je na náhledech videa zobrazeno živé video z kamer. Výbˇerem jednoho ze vstupních videí dojde k vysílání tohoto živého vstupu na výstupní rozhraní. Zvolené video pro výstup je potom oznaˇceno zeleným rámeˇckem po celou dobu jeho vysílání. Režim Replay slouží k pˇrehrávání uložených klipu. ˚ Všechna videa jsou pˇrehrávána souˇcasnˇe stejnou rychlostí. Z dostupných videí muže ˚ být sestaven doˇcasný playlist, který je potom možné pˇrehrát na výstupním rozhraní. Nejvíce prostoru na monitoru zabírají náhledy všech cˇ tyˇr vstupních videí. Pˇres každé video jsou zobrazovány polopruhledné ˚ textové stavové informace a další ovládací prvky, které se vztahují k danému videu. Zobrazená videa mohou být v závislosti na rozlišení použitého monitoru vykreslena zmenšená, aby se vešla celá na monitor. Dotykovým gestem pinch-to-zoom nad videem je možné toto video pˇriblížit, aby mˇel uživatel možnost vidˇet maximální možný detail pˇri posuzování sporných momentu. ˚ Pˇribližovat lze libovolnˇe i na více než 100% originálního rozlišení videa. Každé video lze pˇribližovat nezávisle na ostatních. Na snímku obrazovky je vpravo hlavní ovládací panel. Umístˇení panelu lze pˇrepnout na levou stranu, aby si uživatel levák nezakrýval pˇri práci se systémem na dotykovém monitoru vlastní rukou zobrazená videa. V panelu jsou nahoˇre umístˇena cˇ tyˇri tlaˇcítka pro ukládání video klipu˚ a zárovenˇ jejich rychlé rozˇrazení. Rozlišují se góly a šance domácího a hostujícího týmu. Všechna tato tlaˇcítka uloží obsah bufferu do video klipu. Pod nimi jsou umístˇena tlaˇcítka pro pˇrepínání režimu˚ aplikace a rˇ ízení pˇrehrávání video klipu˚ na výstupní rozhraní. Dále se v hlavním panelu nachází seznam uložených klipu˚ se tˇremi záložkami. V první záložce zleva jsou v seznamu všechny uložené klipy. Výbˇerem klipu ze seznamu se daný klip naˇcte, aplikace se pˇrepne do pˇrehrávacího režimu a je možné jej ihned pˇrehrávat. Prostˇrední záložka obsahuje seznam klipu˚ oznaˇcené hvˇezdiˇckou. Uživatel si takto oznaˇcuje zajímavé klipy, které bude po zápase chtít exportovat. Poslední záložka je nazvána Edit. Nabízí taktéž seznam všech uložených klipu˚ jako na první záložce. Výbˇerem klipu v tomto seznamu se uživateli ihned nabídne úprava popisu klipu. Toto rˇ ešení bylo zvoleno, aby nedocházelo k nechtˇeným editacím dvojitým klepnutím pˇri výbˇeru klipu˚ ze seznamu na první záložce, která je pˇri práci se systémem nejvíce využívána. 31

3. A RCHITEKTURA SYSTÉMU Pod náhledy videa je umístˇen posuvník k ovládání rychlosti a smˇeru pˇrehrávání. Ve výchozí pozici je posuvník uprostˇred. Stisknutím a tažením posuvníku doprava se pˇrehrává video vpˇred, pˇresunutím posuvníku doleva od výchozí pozice se pˇrehrává pozpátku. Vzdálenost posuvníku od výchozí pozice urˇcuje rychlost pˇrehrávání, cˇ ím dál posuvník je, tím rychleji se video pˇrehrává. Pˇri uvolnˇení prstu nad posuvníkem se tento pˇresune ihned do výchozí pozice a video se v daném místˇe zastaví. Tímto zpusobem ˚ je snadné video zastavit pˇresnˇe v potˇrebném místˇe tím, že pouze pustím prst. Plynulé pˇrehrávání bez nutnosti držet prst na posuvníku je možné jednoduchým klepnutím na posuvník. Video se zaˇcne pˇrehrávat od daného místa normální rychlostí. Posledním ovládacím prvkem je textový rˇ ádek na horním okraji okna aplikace. Do nˇej lze vepsat libovolnou textovou informaci, kterou je potom pˇríslušným tlaˇcítkem možné zobrazit polopruhlednˇ ˚ e pˇres výstupní video ze systému na velkoplošné obrazovce na stadionu. Pokud je zadaný text delší než šíˇrka obrazovky, zobrazí se animovanˇe jako bˇežící text. Návrh grafických prvku˚ uživatelského rozhraní, volba barev, logo aplikace a další podrobnosti spojené se vzhledem rozhraní jsou dílem firmy Daite.

3.3 Schéma systému Schéma systému je zobrazeno na obrázku 3.2. Smˇer šipek propojujících komponenty znázornuje ˇ smˇer toku dat. Popisky u tˇechto propojení oznaˇcují typ a objem pˇrenášených dat. Dvojice cˇ árkovaných propojení vedoucích do komponent Náhled videa, respektive SDI výstupní karta, znamená, že je vždy pouze jedno propojení z této dvojice v cˇ ase aktivní, tedy že jsou zobrazovány, respektive odesílány na SDI výstup, bud’ snímky živého videa nebo videa ze záznamu, nikdy však oba zároven. ˇ

3.3.1 Záznam Pˇrijaté snímky z karty pro zachytávání videa jsou dále zaˇrazeny do fronty ke kompresi. Komprese se provádí bez pˇrerušení po celou dobu bˇehu aplikace nezávisle na ostatní práci se systémem, aby bylo zajištˇeno nepˇrerušené nahrávání záznamu. Ke kompresi využívám knihovnu GPUJPEG [18], která pro kompresi snímku˚ do formátu JPEG využívá akcelerovaný výpoˇcet na grafických procesorech (GPU), používá k tomu technologii CUDA. V této konfiguraci systému s cˇ tyˇrmi video vstupy je pro kompresi dedikovaná jedna grafická karta. 32

3. A RCHITEKTURA SYSTÉMU

Obrázek 3.2: Schéma propojení hlavních komponent systému. Zkomprimované snímky jsou ponechány v operaˇcní pamˇeti v kruhovém bufferu. Koncept kruhového bufferu videa byl pˇredstaven v podkapitole 3.1.2. Uživatel muže ˚ kdykoli pˇri bˇehu aplikace oznaˇcit pˇríslušným tlaˇcítkem aktuální situaci na ledˇe za zajímavou a spustit tak uložení obsahu kruhového bufferu videa na pevný disk. Zárovenˇ je tímto pˇridána položka do seznamu uložených klipu. ˚ Každá položka nese referenci na uložené video klipy z jednotlivých kamer pro pozdˇejší pˇrehrání.

3.3.2 Pˇrehrávání Pˇrehrávání klipu˚ je možné v režimu Replay. Do Replay režimu je možné se pˇrepnout výbˇerem položky ze seznamu akcí. Dojde k naˇctení jednotlivých video klipu˚ do vyrovnávací pamˇeti pˇrehrávaˇce. V tomto režimu muže ˚ uživatel pˇrehrávat záznamy ze všech kamer z daného okamžiku na monitoru. Na SDI výstup se pˇritom posílá živé vi33

3. A RCHITEKTURA SYSTÉMU deo z kamery, která byla pro výstup vybrána jako poslední pˇred pˇrepnutím do Replay režimu. Systém má umožnovat ˇ i pˇrehrávání záznamu˚ na velkoplošné obrazovce. Proto systém nabízí vytvoˇrení doˇcasného playlistu k pˇrehrání na výstup. Uživatel muže ˚ oznacˇ ením jednotlivých videí definovat poˇradí, v jakém se jednotlivá videa budou postupnˇe pˇrehrávat na výstupním rozhraní. Toto rˇ ešení odpovídá tomu, jak videorozhodˇcí se záznamy pracuje, napˇred posoudí sám danou situaci a po rozhodnutí muže ˚ pˇrehrát vybrané relevantní záznamy na velkoplošné obrazovce. V obou pˇrípadech muže ˚ v pru˚ bˇehu pˇrehrávání mˇenit rychlost a smˇer pˇrehrávání videa. Video ze záznamu je pˇrehráváno s nastavitelnou snímkovací frekvencí spoleˇcnou pro všechny záznamy. Pevnou snímkovací frekvenci pˇrehrávání jsem zvolil proto, že systém podporuje obecnˇe libovolné snímkovací frekvence pˇri zaznamenávání videa, s tím, že chceme pˇrehrávat záznamy synchronnˇe a to i v pˇrípadˇe, že mají jednotlivé vstupy ruznou ˚ snímkovací frekvenci. Algoritmus pˇrehrávaˇce potom vybírá snímek k pˇrehrání z každého videa tak, aby si cˇ as poˇrízení snímku co nejvíce odpovídal s ostatními snímky. Použitý postup bude popsán v cˇ ásti 4.2. S využitím zpomaleného pˇrehrávání videa tak využijeme všechny snímky i když je pˇrehrávací frekvence nastavena na nižší hodnotu než je snímkovací frekvence zaznamenaného videa a neztrácíme tak žádnou informaci. Snímky zaznamenaného videa vybrané pˇrehrávaˇcem jsou pˇredány do fronty k dekompresi. Využívám k ní taktéž knihovnu GPUJPEG jako pro kompresi. Nekomprimované snímky jsou následnˇe zobrazovány v OpenGL jako textury. Dekompresi a zobrazování OpenGL scény v této konfiguraci provádí stejná grafická karta. Jak uvádím v kapitole 3.1.5 není to ideální konfigurace, ale pˇri nastavení pˇrehrávání s frekvencí 25 FPS je proložení OpenGL renderování a CUDA výpoˇctu z hlediska výkonu dostaˇcující a v systému tak mohly být použity celkem dvˇe grafické karty namísto tˇrí pˇri soucˇ asném dodržení kvality obrazu Q ≥ 90, což je nezbytné pro detailní analýzu obrazu videorozhodˇcím.

3.3.3 Výstup Systém nabízí jako rozšíˇrení jeden SDI video výstup. Tento výstup je napojen do velkoplošných LED obrazovek na hokejových stadionech. Vertikální rozlišení tˇechto obrazovek dosahuje nejvýše hodnot 520–576 pixelu, ˚ cˇ asto ale i ménˇe. Pˇritom výška obrazovek dosahuje bˇežnˇe až 3 metry. Tyto LED obrazovky bývají zpravidla zavˇešeny nad ledovou hrací plochou, takže pozorovací vzdálenost diváku˚ od obrazovky je pˇribližnˇe 30 až 80 metru˚ v závislosti na velikosti stadionu. Použití vyššího rozlišení zde proto ani 34

3. A RCHITEKTURA SYSTÉMU nedává pˇríliš smysl s ohledem na rozlišovací schopnost lidského oka, která je pˇribližnˇe 60 arcsec [28]. Pˇri pozorování obrazovky z nejkratší možné vzdálenosti (pˇribližnˇe 30 metru) ˚ má nejmenší rozlišitelný bod velikost pˇribližnˇe 8,7 mm. Pˇritom velikost bodu˚ LED obrazovek se pohybuje v rozmezí 6 až 8 mm, tudíž pod rozlišovací schopností lidského oka na tuto vzdálenost. Pˇres výstupní video má systém umožnovat ˇ zobrazení pruhledného ˚ obsahu. Toho je možné nejsnadnˇeji dosáhnout využitím hardware odesílací SDI karty Blackmagic Decklink, která podporuje interní alfa–klíˇcování výstupu. Podporováno je však jen klíˇcování do videa v SD kvalitˇe, tedy ve formátech PAL nebo NTSC. Klíˇcování v HD kvalitˇe podporují až karty vyšší rˇ ady Blackmagic Decklink Extreme, které jsou však dvojnásobnˇe drahé. Vzhledem k rozlišení obrazovek, pro které je výstup urˇcen, nám ale SD kvalita plnˇe dostaˇcuje, jelikož jejich rozlišení je stejné nebo menší než formát PAL umožnuje. ˇ Dalším úkolem je tedy pˇrevést HD video, které se v systému zpracovává, na SD formát PAL. Opˇet je nejjednodušší využít hardware odesílací karty, který umožnuje ˇ provádˇet konverzi HD videa na SD v reálném cˇ ase v hardware karty. V koneˇcné konfiguraci tedy potˇrebujeme pro výstup s klíˇcováním dvˇe odesílací karty. Mužeme ˚ využít kartu Blackmagic Decklink Duo, která na jedné fyzické kartˇe do PCIe slotu integruje dvˇe plnohodnotné nezávislé karty pro pˇríjem i odesílání na SDI rozhraní. Jedna z nich je využita pro konverzi HD videa na SD (formát PAL), které je pˇrivedeno na vstup druhé karty. Ta vkládá do videa na svém vstupním portu pruhledný ˚ obsah a na jejím výstupním portu je již složený obraz.

3.4 Minimální požadavky Pˇripravil jsem pˇrehled minimálních požadavku, ˚ které systém v dané konfiguraci vyžaduje. •

Zachytávací karta SDI – Blackmagic Decklink Quad, karta pro pˇríjem cˇ tyˇr video vstupu˚ s rozhraním PCI Express x4. Lze použít i další typy karet z rˇ ady Blackmagic Decklink, souˇcet vstupu˚ všech karet musí být alesponˇ cˇ tyˇri.

•

Odesílací karta SDI – Blackmagic Decklink Mini Monitor, karta s jedním SDI výstupem. Pˇri použití alfa–klíˇcování výstupu v SD kvalitˇe (PAL, NTSC) je vyžadována alesponˇ karta Blackmagic Decklink Duo, pro klíˇcování v HD kvalitˇe alesponˇ Blackmagic Decklink 4K Extreme. 35

3. A RCHITEKTURA SYSTÉMU •

Grafická karta – dvˇe karty s podporou technologie CUDA, šíˇrka sbˇernice PCI Express x8 nebo vyšší. Doporuˇcený model grafického cˇ ipu GeForce GTX 580 nebo novˇejší.

•

Operaˇcní pamˇet’ – alesponˇ 8 GB pˇri nastavení délky ukládaného klipu 30 sec. Navýšení této doby o vteˇrinu zvýší nároky na pamˇet’ pˇribližnˇe o 248 MB.

•

Pevný disk – SSD Solid-state drive, rychlost zápisu alesponˇ 248 MB/s, kapacita 480 GB vystaˇcí nejménˇe na 66 situací pˇri délce klipu 30 sec, což je pro videorozhodˇcí více než dostaˇcující. Každá situace obsahuje cˇ tyˇri klipy v maximální kvalitˇe.

36

Kapitola 4

Implementace vybraných cˇ ástí Tato práce vznikla ve spolupráci s firmou Daite s.r.o., která bude výsledný systém nabízet jako komerˇcní produkt. K práci z tohoto duvodu ˚ není pˇriložen kompletní zdrojový kód, který by bylo možné pˇreložit a spustit. V elektronických pˇrílohách k práci jsou zveˇrejnˇeny úseky kódu, které jsou pro problematiku této práce zajímavé. Zdrojové kódy jsou napsány v programovacím jazyce C/C++ s využitím frameworku Qt pro práci s grafickým uživatelským rozhraním. Využívám v kódu také další možnosti tohoto nástroje, zejména pro platformnˇe nezávislou práci s vlákny, zámky, semafory a podobnˇe. Aplikace byla vyvíjena primárnˇe pro operaˇcní systém Linux s durazem ˚ na použití multi–platformních implementací Qt frameworku pro snadnˇejší pˇrenos kódu na jiné platformy.

4.1 OpenGL display O zobrazení video snímku˚ na monitoru se stará tˇrída GLVideoWidget. Tato tˇrída dˇedí vlastnosti tˇrídy QGLWidget z Qt frameworku, která zprostˇredkovává OpenGL kontext a umožnuje ˇ jej vložit na formuláˇr do grafického rozhraní jako jakýkoli jiný widget. Widget je v Qt frameworku grafický objekt, který muže ˚ být umístˇen na formuláˇr aplikace. Chování objektu, který dˇedí vlastnosti tˇrídy QGLWidget, lze mˇenit implementací jejích virtuálních metod. Podkladem pro implementaci OpenGL vykreslování mi byly materiály k pˇredmˇetu Poˇcítaˇcová grafika vyuˇcovanému na Fakultˇe Informaˇcních technologií VUT v Brnˇe [29] a další dostupná literatura [30]. 4.1.1 Pˇríprava scény Virtuální metoda initializeGL tˇrídy QGLWidget je zavolána jednou a je zajištˇeno, že je to pˇred prvním voláním paintGL nebo resizeGL metod. V implementaci této metody tedy vytváˇrím scénu, do které budu vykreslovat video jako textury, probíhá 37

ˇ 4. I MPLEMENTACE VYBRANÝCH CÁSTÍ

zde inicializace potˇrebných bufferu˚ na grafické kartˇe, kompilace a linkování shaderu˚ a další nezbytné inicializace. Scéna sestává ze cˇ tyˇr obdélníku, ˚ každý pro zobrazení jednoho videa. K jejich vytvoˇrení volám pomocnou funkci createVBOs, ve které vytváˇrím pro každé vstupní video pole vrcholu˚ a pole texturových souˇradnic obdélníku. ˚ Tato pole využiji k naplnˇení zásobníku˚ typu GL_ARRAY_BUFFER v pamˇeti grafické karty. Pˇri pˇrekreslení scény se potom odkazuji na pˇripravené zásobníky a není nutné nahrávat vždy znovu vrcholy obdélníku˚ a jejich texturové souˇradnice. V této fázi také vytváˇrím a alokuji zásobníky na grafické kartˇe pro obrazová data (Pixel Buffer Object - PBO) a pro textury. Kód, který provádí alokaci lze nalézt v pomocné metodˇe allocPBOandTex. Alokaci pamˇeti na kartˇe provádím voláním bˇežných funkcí knihovny OpenGL pro nahrávání textur, respektive Pixel Buffer Objektu, ˚ s ukazatelem na data s hodnotou NULL. Ovladaˇc tímto pouze alokuje pamˇet’ na grafické kartˇe. Její velikost stanoví podle zadaných parametru˚ funkcím glTexImage2D v pˇrípadˇe textur, respektive glBufferData v pˇrípadˇe PBO. Pro každou texturu alokuji dva PBO, pro dosažení vyšší efektivity pˇri nahrávání dat pro textury. Podrobnˇeji v následující podkapitole. V neposlední rˇ adˇe je tˇreba pˇreložit a pˇripojit shader programy vertex shader a fragment shader, který pˇrevádí barvu bodu˚ z formátu YUV na RGB pro zobrazení. K tomuto úkolu jsem vytvoˇril opˇet vlastní pomocné funkce využívající nativní volání knihovních funkcí OpenGL glCreateShader, glCompileShader, glAttachShader a další.

4.1.2 Nahrávání textur Jednotlivé snímky videa jsou zobrazovány jako textury na vytvoˇrených obdélnících ve scénˇe. Je tedy zˇrejmé, že pro každý snímek videa je tˇreba nahrát novou texturu. V této práci uvažuji maximálnˇe cˇ tyˇri vstupní videa s frekvencí snímku˚ nejvýše 60 FPS. Znamená to, že nahrání nové textury na grafickou kartu muže ˚ být voláno až 240-krát za vteˇrinu v závislosti na parametrech vstupního videa a jejich poˇctu. Má tedy smysl zabývat se možnostmi zvýšení efektivity nahrávání tˇechto textur. Pˇri implementaci jsem zvolil pˇrístup k vytváˇrení textur z dvojice PBO. Zvolené rˇ ešení umožnuje ˇ asynchronní pˇrenosy dat na grafickou kartu s využitím Direct Memory Access (DMA), tedy pˇrenos dat bez pozornosti procesoru, pokud použitá grafická karta a její ovladaˇc tuto funkci podporují. Toho je dosaženo použitím funkce OpenGL 38


glMapBuffer, která vrací ukazatel na interní pamˇet’ ovladaˇce grafické karty. Tato pamˇet’ je ve vˇetšinˇe pˇrípadu˚ nestránkovatelná a je spravována grafickým ovladaˇcem [31]. Dokonˇcení asynchronního kopírování dat na kartu nelze pˇredem stanovit. K vytvorˇ ení textury z PBO je však ještˇe nutné zavolat OpenGL funkci glTexImage2D s pˇripojeným PBO, ze kterého se budou cˇ íst data pro texturu. Pokud bychom tuto funkci volali dˇrív než by byl dokonˇcen asynchronní pˇrenos do zvoleného PBO, ovladaˇc by cˇ ekal na dokonˇcení operace a výhody asynchronního pˇrenosu by se ztratily. Používám proto pro každou texturu dva PBO. Pˇri pˇríchodu nového snímku videa spustím pˇrenos dat nového snímku do prvního PBO, z druhého PBO vytvoˇrím texturu. Pˇri nahrávání pˇríštího snímku videa se poˇradí PBO pˇrevrátí. Vytváˇrení textury se tedy vždy volá nad pˇredchozím snímkem videa. Pˇredpokládám, že pˇred pˇríchodem nového snímku bude asynchronní pˇrenos pˇredchozího již dokonˇcen. Pokud ne, je tímto zpu˚ sobem alesponˇ minimalizováno cˇ ekání na dokonˇcení operace pˇrenosu. Vytváˇrení textury z PBO už je velmi rychlá operace, nebot’ potˇrebná data už jsou nahrána v pamˇeti grafické karty. Literatura uvádí pˇrenosovou rychlost z PBO do textury až 52,79 GB/s (testováno na kartˇe NVIDIA GeForce GTX 470 )[31].

4.1.3 Zobrazení YUV dat OpenGL nepodporuje pˇrímé vytváˇrení textur z YUV obrazových dat. Pro jejich zobrazení jsem implementoval vlastní fragment shader, jeho kód je souˇcástí elektronických pˇríloh práce. Fragment shader (též pixel shader) je jeden ze shader programu, ˚ které se uplatní v programovatelném vykreslovacím rˇ etˇezci OpenGL. Kód fragment shaderu je spuštˇen nad každým bodem rasterizované scény. K programování shaderu˚ v OpenGL se používá programovací jazyk GLSL, jehož syntaxe je podobná jazyku C. Kód shader programu˚ bˇeží celý na grafickém procesoru (GPU). V první rˇ adˇe je tˇreba nahrát obrazová data ve formátu YUV do textury. OpenGL formát YUV nezná, pˇri nahrávání textury specifikuji formát dat RGBA s poloviˇcní šíˇrkou obrazových dat než ve skuteˇcnosti je. Proˇc jsem zvolil právˇe tento postup demonstruje obrázek 4.1. Dokumentace ke kartám Blackmagic Decklink [17] uvádí ve formátu YUV (s podvzorkováním 4:2:2) poˇradí bytu˚ U-Y1-V-Y2, kde Y1 je hodnota jasové složky prvního bodu a Y2 hodnota jasové složky druhého bodu. U a V jsou barevné hodnoty spoleˇcné pro oba pixely, barevná informace je podvzorkovaná. Takto jsou zakódované hodnoty dvou sousedních pixelu˚ na cˇ tyˇrech bytech. OpenGL formát RGBA popisuje cˇ tyˇrmi byty jeden pixel obrazu. Z toho plyne, že je nutné specifikovat textuˇre v YUV formátu po39


Obrázek 4.1: Mapování bytu˚ formátu YUV 4:2:2 a RGBA.

loviˇcní šíˇrku, protože barevná informace je spoleˇcná pro dvojici bodu˚ vedle sebe na rˇ ádku. Textura je pˇri vykreslení na obdélník ve scénˇe roztažena na puvodní ˚ šíˇrku obrazu, takže každý bod textury je roztažen pˇres dva body v rˇ ádku. V kódu fragment shaderu se pro každý bod obrazu na základˇe své texturové souˇradnice rozhodnu, o který z dvojice bodu˚ se jedná a naˇctu hodnotu jeho jasové složky (Y ) z patˇriˇcné barevné složky bodu textury (texelu), G, respektive A. Pro složky U a V nemusím provádˇet rozhodování, jsou pro oba sousední vykreslované body stejné. Mám pˇripravené správné hodnoty YUV, mohu tedy provést samotný výpoˇcet RGB barvy a vrátit jej jako výstupní hodnotu shaderu FragColor. Vztah pro pˇrevod YUV 4:2:2 formátu (též YCbCr) na RGB je pˇresnˇe pˇredepsán v dokumentaci k Decklink API [17] následovnˇe:

R = 1,164(Y − 16) + 1,793(Cr − 128) G = 1,164(Y − 16) − 0,534(Cr − 128) − 0,213(Cb − 128) B = 1,164(Y − 16) + 2,115(Cb − 128)

V uvedených rovnicích se pˇredpokládají hodnoty jednotlivých složek v rozsahu 0–255. V kódu shaderu jsou hodnoty barev normalizované v rozsahu 0–1, proto jsou v kódu zadány jako už pˇrepoˇcítané konstanty. 40


4.2 Pˇrehrávaˇc K pˇrehrávání video klipu˚ slouží tˇrída Player. Umožnuje ˇ pˇrehrávání klipu˚ ve dvou režimech. První z nich je v kódu oznaˇcován jako režim preview. V tomto režimu jsou pˇrehrávány všechny klipy souˇcasnˇe a pouze na monitoru poˇcítaˇce. Tento režim je vhodný pro posuzování situace videorozhodˇcím. Druhým režimem je pˇrehrávání playlistu na výstupní SDI rozhraní, v kódu oznaˇcován jako režim output. Pˇrehrává postupnˇe všechny klipy pˇridané do playlistu a zobrazuje je jak na monitoru, tak na výstupním SDI rozhraní. V obou režimech je možné libovolnˇe mˇenit rychlost a smˇer pˇrehrávání.

4.2.1 Výbˇer snímku˚ k pˇrehrání Jednotlivá vstupní videa do systému mohou mít obecnˇe ruzné ˚ snímkovací frekvence. Pˇritom je pro správné posuzování situací na hˇrišti klíˇcové vidˇet danou situaci z ruzných ˚ pohledu˚ ve stejnou chvíli, tedy pˇrehrávat všechny klipy synchronnˇe. K dosažené této vlastnosti si objekt Player pˇri pˇrehrávání uchovává aktuální pozici v pˇrehrávaných klipech jako cˇ as klipu od zaˇcátku jeho pˇrehrávání v promˇenné currentReplayTime. Tuto hodnotu je možné použít pro všechny pˇrehrávané klipy. Metoda emitActualFrame na základˇe této cˇ asové hodnoty vypoˇcte cˇ íslo snímku, které je cˇ asovˇe nejblíže aktuální pozici pˇrehrávaˇce. Snímek s tímto cˇ íslem je odeslán k zobrazení. Každý video klip má svoji snímkovací frekvenci pevnˇe danou, je tedy snadné urcˇ it cˇ íslo aktuálního snímku prostým vynásobením aktuálního cˇ asu pˇrehrávání poˇctem snímku˚ za vteˇrinu pˇrehrávaného videa a tuto hodnotu zaokrouhlit na nejbližší celé cˇ íslo. Získáme tak index snímku ve video klipu. Je zajištˇeno, že klipy jsou pˇred spuštˇením pˇrehrávání nahrány do vyrovnávací pamˇeti jako pole snímku. ˚ Je tedy možné pˇristoupit pˇrímo ke snímku na daném indexu bez nutnosti prohledávání dat. Aktualizaci pozice pˇrehrávaˇce zajišt’uje metoda renderFrames. Tato metoda je volána periodicky po uplynutí stanoveného intervalu cˇ asovaˇce. Pro cˇ asovaˇc používám objekt typu QTimer. Je garantováno, že cˇ asovaˇc nevyprší dˇríve než za stanovenou dobu, není již však garantováno, že nevyprší pozdˇeji. Nelze tedy aktualizovat pozici pˇrehrávaˇce prostým pˇriˇctením intervalu cˇ asovaˇce, má-li být pˇrehrávání plynulé a pˇresné. Pˇresnˇeji lze pozici pˇrehrávaˇce aktualizovat mˇerˇ ením uplynulé doby od pˇrehrání snímku˚ pˇri minulém vypršení cˇ asovaˇce. Používám k tomu objekt QElapsedTimer a jeho metodu nsecsElapsed, která vrací poˇcet nanosekund od spuštˇení tohoto cˇ asovaˇce. Bezprostˇrednˇe potom restartuji cˇ asovaˇc pro použití v následující periodˇe pˇrehrá41


vání. Získanou hodnotu násobím aktuální rychlostí pˇrehrávání, cˇ ímž efektivnˇe dochází ke zmˇenˇe rychlosti cˇ i smˇeru všech pˇrehrávaných videí. Rychlost pˇrehrávání udává desetinné cˇ íslo vyjadˇrující násobek normální rychlosti pˇrehrávání. Záporná rychlost pˇrehrávání zpusobí ˚ pˇrehrávání pozpátku. Krokování videa po snímcích je docíleno nastavením rychlosti na nulovou hodnotu a pˇriˇctením doby trvání snímku videa s nejvyšší hodnotou FPS k pozici pˇrehrávaˇce pokaždé, když uživatel použije pˇríslušné tlaˇcítko pro krokování videa.

4.2.2 Režimy pˇrehrávání Jak zminuji ˇ v úvodu této podkapitoly o pˇrehrávaˇci, pˇrehrávání klipu˚ je možné ve dvou režimech. V režimu preview se pˇrehrávají všechny klipy souˇcasnˇe. Video je zobrazováno pouze na monitoru poˇcítaˇce. V tomto režimu se pˇrehrává s pevnˇe danou snímkovací frekvencí. Tuto je možné nastavit jako parametr konstruktoru pˇri vytváˇrení objektu Player nebo je použita výchozí hodnota 25 FPS. Tato hodnota je také doporuˇcenou hodnotou pro pˇrehrávání cˇ tyˇr videí v HD kvalitˇe souˇcasnˇe jak uvádím v cˇ ásti 3.3.2. Snímkovací frekvenci pˇrehrávání lze ale nastavit libovolnˇe, na míru ruznˇ ˚ e výkonných konfigurací systému. Ovlivnuje ˇ se tím pouze interval cˇ asovaˇce a tedy frekvence volání výše zmínˇené metody pˇrehrávaˇce renderFrames. V režimu preview je také možné vkládat videa do playlistu k následnému pˇrehrání na výstupní SDI rozhraní. Playlist je seznam cˇ ísel typu QList. Tato cˇ ísla pˇredstavují cˇ ísla video vstupu. ˚ Obsah playlistu urˇcuje, v jakém poˇradí a zda vubec ˚ bude klip s daným cˇ íslem vstupu pˇrehrán na výstup. QList je v Qt frameworku výchozí doporuˇcený generický datový typ pro seznamy. Pˇrepnutím do režimu output dojde k nastavení snímkovací frekvence pˇrehrávaˇce na stejnou hodnotu jako je snímkovací frekvence pˇrehrávaného video klipu. V tomto režimu je totiž pˇrehráváno vždy pouze jedno video. Z toho duvodu ˚ nepˇredstavuje pˇrehrávání s nativní snímkovací frekvencí výkonnostní hrozbu pˇri dekompresi a zobrazení jako by tomu bylo pˇri pˇrehrávání všech videí souˇcasnˇe. Na výstupním SDI rozhraní tak také dostáváme video se všemi snímky, se kterými bylo poˇrízeno. To pochopitelnˇe platí za pˇredpokladu pˇrehrávání rychlostí 1,0. Pˇri zmˇenˇe rychlosti se snímková frekvence pˇrehrávaˇce nemˇení, pˇri zrychleném pˇrehrávání jsou tedy urˇcité snímky pˇreskoˇceny. 42


4.3 SDI výstup Implementace výstupu videa na SDI rozhraní je k nalezení ve tˇrídách OutputSDI a PlaybackDelegate v pˇrílohách práce. V implementaci využívám rozhraní k ovládání pˇrídavných karet poskytované výrobcem v rámci Decklink API [17], zejména rozhraní IDeckLinkOutput. Po vytvoˇrení objektu typu OutputSDI je tˇreba provést inicializaci zavoláním jeho metody init. Metoda má dva povinné parametry. Prvním je cˇ íslo SDI karty, která se má pro výstup použít. Druhý parametr je typu bool a urˇcuje, zda se má provádˇet konverze HD formátu videa na SD, tedy na nižší kvalitu. Proˇc provádˇet konverzi na SD formát bylo diskutováno v cˇ ásti 3.3.3. Inicializace SDI výstupu spoˇcívá v nalezení požadované karty pomocí iterátoru IDeckLinkIterator, který umožnuje ˇ procházet pˇres všechny Decklink karty v systému. Na zvolené kartˇe je tˇreba nastavit výstupní formát, v našem pˇrípadˇe HD 720p60, a povolit video výstup voláním metody EnableVideoOutput z rozhraní IDeckLinkOutput. Rozhraní IDeckLinkOutput umožnuje ˇ výstup snímku˚ videa dvˇema zpusoby. ˚ Prvním z nich je voláním metody DisplayVideoFrameSync s ukazatelem na snímek k zobrazení. Tímto je snímek na výstupu zobrazen až do dalšího volání této metody nebo do doby, kdy je spuštˇeno pˇrehrávání druhým zpusobem. ˚ Druhý zpusob ˚ se více hodí k pˇrehrávání videa, ale jeho použití je složitˇejší. Snímky videa jsou nahrávány do vyrovnávací pamˇeti na odesílací kartˇe a každému z nich je naplánován cˇ as a doba zobrazení. Po spuštˇení pˇrehrávání metodou StartScheduledPlayback je odesílání snímku˚ na SDI rozhraní rˇ ízeno hardwarem odesílací karty v pˇresnˇe stanovený cˇ as. Výstupní video je tak vždy plynulé. V prubˇ ˚ ehu pˇrehrávání z této naplánované fronty je duležité ˚ udržovat frontu pˇrimˇerˇ enˇe plnou. Pokud se vyprázdní, pˇrehrávání se zastaví a je nutné spustit pˇrehrávání znovu a video je trhané. Pokud se naopak fronta naplní pˇríliš, Decklink API odmítne další snímek naplánovat k pˇrehrání. Takový snímek je potom nutno odložit a pokusit se jej naplánovat až se fronta uvolní. Abychom se tˇechto situací vyvarovali, navrhl jsem rˇ ešení s vlastní frontou, která není omezená velikostí. Snímky k zobrazení na výstupu jsou vkládány do této fronty. Spuštˇení pˇrehrávání metodou startScheduled tˇrídy OutputSDI je dovoleno, až fronta obsahuje alesponˇ urˇcitý poˇcet snímku, ˚ v souˇcasném nastavení je to pˇet snímku. ˚ Tyto snímky jsou naplánovány k pˇrehrání na kartˇe a následnˇe je spuštˇeno pˇrehrávání. Decklink API informuje aplikaci o dokonˇcení pˇrehrání každého snímku zavoláním callback funkce ScheduledFrameCompleted. V tˇele této funkce vyjmu jeden další sní43


mek z fronty a naplánuji ho k pˇrehrání. Udržuji tak velikost fronty na zaˇrízení ve stanovené velikosti a mám pˇritom možnost pˇredat k pˇrehrání na výstup i vˇetší množství snímku˚ najednou. Zmínˇená metoda ScheduledFrameCompleted je virtuální metodou rozhraní IDeckLinkVideoOutputCallback, jejíž implementace se nachází ve tˇrídˇe PlaybackDelegate, která vlastnosti uvedeného rozhraní dˇedí. Objektu PlaybackDelegate je v konstruktoru pˇredán ukazatel na rodiˇcovský objekt typu OutputSDI. Delegát tak muže ˚ volat metodu svého rodiˇce pro naplánování dalšího snímku z fronty scheduleFromQueue. Pˇrístup k frontˇe snímku˚ je tˇreba ošetˇrit zámkem, protože callback metoda je vyvolána v samostatném vláknˇe a mohlo by tak dojít k soubˇežnému cˇ tení a zápisu ze sdílené fronty, neboli race condition.

4.3.1 Klíˇcování pˇres video Karty Blackmagic Decklink obsahují dva SDI konektory, jeden vstupní a jeden výstupní. Pˇri inicializaci karty je tˇreba zvolit, zda bude karta použita pro pˇríjem nebo pˇrehrávání videa na SDI, tedy se vždy používá jen jeden z konektoru. ˚ Výjimkou je režim karty pro alfa–klíˇcování pruhledného ˚ obsahu pˇres video, kdy jsou používány oba konektory. Vstupní konektor je použit jako zdroj pokladového videa, na výstupním konektoru je k dispozici video s naklíˇcovaným obsahem. Implementace klíˇcování se nachází ve tˇrídˇe KeyerSDI v pˇríloze práce. Pˇri inicializaci karty pro klíˇcování je postup obdobný jako v pˇrípadˇe bˇežného výstupu na SDI, je uveden v metodˇe init. Nalezení urˇcené karty, volba výstupního formátu a povolení výstupu videa je doplnˇeno o získání rozhraní IDeckLinkKeyer a zavolání jeho metody Enable pro povolení klíˇcování v hardware karty. Nahrávání snímku, ˚ které mají být zobrazeny pˇres video, se provádí stejným zpu˚ sobem jako nahrávání snímku˚ pro bˇežný výstup, tedy pomocí již známé metody DisplayVideoFrameSync rozhraní IDecklinkOutput. Pro správnou funkcionalitu je však pochopitelnˇe potˇreba nahrávat snímky s pruhlednými ˚ oblastmi a ve formátu RGBA. Míchání videa a nahraného obrazu se rˇ ídí hodnotami kanálu alfa daného obrazu. Rozhraní IDecklinkKeyer umožnuje ˇ za bˇehu mˇenit celkovou úrovenˇ pruhled˚ nosti obrazu klíˇcovaného pˇres video. Použít k tomu lze metodu SetLevel s jedním parametrem v rozsahu 0–255, která nastaví pruhlednost ˚ trvale na stanovenou hodnotu, pˇrípadnˇe metody RampUp a RampDown, které zpusobí ˚ postupné plynulé zobrazování, 44


respektive skrývání klíˇcovaného obsahu s rychlostí urˇcenou parametrem tˇechto metod v poˇctu snímku˚ videa.

4.4 Dotykové ovládání Knihovna Qt nabízí podporu pro dotykové ovládání od verze 4.6 z roku 2009. V této podkapitole popisuji, jaké principy knihovna Qt používá pro práci s dotykovým rozhraním a jakým zpusobem ˚ je lze využít v kódu aplikace pro implementaci vlastních dotykových gest. Pˇri implementaci grafických aplikacích se pro interakci uživatele s programem obvykle používají události events zasílané jednotlivým objektum. ˚ V pˇrípadˇe dotykové interakce v Qt využijeme zejména události typu QTouchEvent. Informace k používání tˇechto událostí jsou dostupné v obsáhlé dokumentaci tˇrídy QTouchEvent [27]. V Qt se pro jednotlivé grafické prvky v oknˇe aplikace používá oznaˇcení widget. Ve výchozím nastavení jsou dotykové události danému widgetu doruˇceny jako odpovídající bˇežné události myši. Tím je zaruˇcena zpˇetná kompatibilita s widgety, které dotyky pˇrímo nepodporují. Je zˇrejmé, že tímto zpusobem ˚ však nelze využít všechny možnosti dotykového ovládání, zejména podporu více dotykových bodu˚ souˇcasnˇe, známou pod oznaˇcením multi-touch. Chceme-li pˇrijímat dotykové události v daném widgetu, musíme mu nastavit atribut WA_AcceptTouchEvents. Tímto efektivnˇe vypneme doruˇcování dotykových událostí jako událostí myši a budou dále widgetu doruˇcovány události typu QTouchEvent. Tyto mohou být následnˇe zachytávány widgetem bˇežným zpusobem ˚ jako jakékoli jiné události. Dotykové události jsou typu TouchBegin, TouchUpdate, TouchEnd nebo TouchCancel. Pˇri prvním dotyku je widgetu, nad kterým k dotyku došlo, zaslána událost typu TouchBegin. Pˇri každém pohybu prstu po obrazovce je zaslána událost typu TouchUpdate tomu widgetu, kterému byla zaslána událost TouchBegin a to i v pˇrípadˇe, že se již prst nad daným widgetem nenachází. Událost TouchEnd je widgetu zaslána pˇri uvolnˇení dotykového bodu. Pro podporu více dotykových bodu˚ a správné urˇcení pˇríjemce dotykových událostí využívá knihovna Qt takzvané shlukování dotykových bodu. ˚ Novˇe pˇridané dotykové body jsou pˇridány do skupiny již aktivní dotykové události. Ta potom obsahuje seznam všech dotykových bodu. ˚ Události TouchUpdate jsou pak doruˇcovány vždy widgetu, který pˇrijal první dotykovou událost. 45


Jednotlivé dotykové body jsou uvnitˇr události QTouchEvent uloženy jako seznam objektu˚ typu TouchPoint. Každý bod má nastaven svuj ˚ stav (bod právˇe stisknut, posunut, neposunut nebo uvolnˇen) a pozici. Objekt TouchPoint také výraznˇe usnadnuje ˇ práci s programováním gest poskytováním souˇradnic relativnˇe vuˇ ˚ ci monitoru, oknu aplikace nebo widgetu, poskytováním pˇredchozí a poˇcáteˇcní souˇradnice bodu, cˇ i získáním vektoru pohybu bodu. Nové události TouchUpdate jsou generovány vždy, když se zmˇení stav nebo pozice jednoho nebo více dotykových bodu. ˚ Událost TouchEnd je widgetu zaslána až když je uvolnován ˇ poslední dotykový bod, pˇrípadnˇe když je uvolnováno ˇ více bodu˚ souˇcasnˇe. Událost TouchCancel je widgetu zaslána na žádost operaˇcního systému, napˇríklad když dojde k rozpoznání systémového dotykového gesta, které má obsloužit operaˇcní systém a ne daná aplikace. Aplikace by na tuto událost mˇela reagovat ukonˇcením dotykové akce, podobnˇe jako pˇri události TouchEnd, ignorovat akce bˇehem trvání tohoto dotyku a obnovit svuj ˚ stav do doby pˇred pˇrijetím události TouchBegin.

46

Závˇer V práci jsem se zabýval vytvoˇrením systému pro hokejové videorozhodˇcí. Navrhl a vytvoˇril jsem systém, který umožnuje ˇ snímat až cˇ tyˇri video signály ve vysokém rozlišení, ukládat video klipy z rozhodˇcím oznaˇcených zajímavých momentu˚ pˇri hˇre a nabízet jejich rychlé pˇrehrání s možností pˇribližování videa a regulace rychlosti a smˇeru pˇrehrávání. Aplikací dodateˇcných rozšíˇrení lze nyní systém souˇcasnˇe použít i pro režii vysílání na velkoplošné obrazovky uvnitˇr stadionu. Systém tak slouží také ke stˇrihu mezi jednotlivými živými vstupy videa a opakovanými záznamy s použitím pruhledných ˚ uživatelsky definovatelných pˇrechodových efektu. ˚ Od cˇ ervna 2013 je systém nasazen v reálném provozu na hokejovém stadionu klubu SK Horácká Slavia Tˇrebíˇc a jsou už tedy k dispozici i první provozní zkušenosti. Uživatelé ocenují ˇ zejména jednoduchost ovládání systému pˇres grafické rozhraní s dotykovým ovládáním, rychlost systému a dostatek nabízených funkcí. Další vývoj systému se bude jistˇe ubírat smˇerem ke zvyšování poˇctu vstupu˚ videa. Souˇcasný poˇcet vstupu˚ nebude pravdˇepodobnˇe do budoucna vˇetším klubum ˚ dostaˇcovat. Systém, využívající principy popsané v této práci, postavený na výkonnˇejším hardware, by mohl zpracovávat i 8 vstupu˚ videa. Pro rozšíˇrení na více video vstupu˚ bude již potˇreba navrhnout urˇcitý distribuovaný systém pro nahrávání a pˇrístup k video záznamum. ˚ Ve spolupráci s firmou Daite již také pˇripravujeme další aplikace, které budou využívat nasbírané video záznamy napˇríklad pro potˇreby trenéru˚ k rozborum ˚ zápasu˚ pˇrímo v šatnˇe s hráˇci a podobnˇe. Ve své práci jsem využil výsledku˚ pˇredchozích prací v laboratoˇri SITOLA (spoleˇcné pracovištˇe FI MU, ÚVT MU a sdružení CESNET), zejména použitím knihovny GPUJPEG pro akceleraci komprese obrazových dat na grafických kartách. V zaˇcátku práce mi také výraznˇe pomohly konzultace v laboratoˇri SITOLA ohlednˇe specifické práce s hardware pro nabírání video dat z SDI rozhraní. V prubˇ ˚ ehu vytváˇrení aplikace jsem si prohloubil své teoretické znalosti i praktické zkušenosti s programováním paralelních aplikací ve více vláknech.

47

Literatura ˇ [1] CESKÝ SVAZ LEDNÍHO HOKEJE. Pravidla ledního hokeje 2010 - 2014 [online]. 2010 [cit. 2013-11-25]. Dostupné z: http://www.cslh.cz/text/119-pravidla-ledniho-hokeje.html ˇ [2] CESKÝ SVAZ LEDNÍHO HOKEJE. Herní rˇ ád Tipsport Extraligy ledního hokeje [[online]]. 2013, 80 s. [cit. 2013-12-05]. Dostupné z: http://www.cslh.cz/dokument/1287-herni-rad-tipsportextraligy-ledniho-hokeje-201314.html [3] NORMANI, Franco. The Physics Of Hockey. REAL WORLD PHYSICS PROBLEMS [online]. 2009-2013 [cit. 2013-11-25]. Dostupné z: http: //www.real-world-physics-problems.com/physics-of-hockey.html [4] Ultra High Definition Television: Threshold of a new age. International Telecommunication Union [online]. Geneva, 24 May 2012 [cit. 2013-12-10]. Dostupné z: http://www.itu.int/net/pressoffice/press_releases/ 2012/31.aspx#.UrLC-ueGHld [5] Introducing HDMI Specification Version 1.4a. HDMI.org [online]. 2009 [cit. 2013-12-19]. Dostupné z: http://www.hdmi.org/manufacturer/hdmi_1_4/index.aspx [6] Introducing HDMI 2.0. HDMI.org [online]. 2013 [cit. 2013-12-19]. Dostupné z: http://www.hdmi.org/manufacturer/hdmi_2_0/index.aspx [7] Running Long Cable Lengths. HDMI.org [online]. 2009 [cit. 2013-12-19]. Dostupné z: http://www.hdmi.org/installers/longcablelengths.aspx [8] THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS. 1.5 Gb/s Signal/Data Serial Interface [online]. 2012 [cit. 2013-12-10]. ISBN 978-1-61482-676-7. Dostupné z: http://standards.smpte.org/content/978-1-61482-676-7/st292-1-2012/SEC1.body.pdf+html 48


[9] THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS. Dual Link 1.5 Gb/s Digital Interface for 1920 x 1080 and 2048 x 1080 Picture Formats [online]. 2011 [cit. 2013-12-10]. ISBN 978-1-61482-513-5. Dostupné z: http://standards.smpte.org/content/978-1-61482-513-5/st372-2011/SEC1.body.pdf+html [10] THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS. 3 Gb/s Signal/Data Serial Interface [online]. 2012 [cit. 2013-12-10]. ISBN 978-1-61482-714-6. Dostupné z: http://standards.smpte.org/content/978-1-61482-714-6/st424-2012/SEC1.body.pdf+html [11] 32NF-70 WG Ultra HD SDI Interfaces. THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS. [online]. 2013, 2013-09-25 [cit. 2013-12-15]. Dostupné z: https://kws.smpte.org/kws/public/projects/project/ details?project_id=180 [12] What is CoaXPress. CoaXPress: The next generation digital interface [online]. 2011 [cit. 2013-12-21]. Dostupné z: http://www.coaxpress.com/coaxpress.php [13] GARRETT-GLASER, Jason. X264: the best low-latency video streaming platform in the world. Diary Of An x264 Developer [online]. 2010 [cit. 2013-12-15]. Dostupné z: http://x264dev.multimedia.cx/archives/249 [14] MPEG LA. SUMMARY OF AVC/H.264 LICENSE TERMS [online]. 2010 [cit. 2013-12-16]. Dostupné z: http://www.mpegla.com/main/programs/AVC/ Documents/AVC_TermsSummary.pdf [15] X264, the best H.264/AVC encoder. VIDEOLAN. VideoLAN organization [online]. 2013 [cit. 2013-12-15]. Dostupné z: http://www.videolan.org/developers/x264.html [16] MERRITT, Loren et al. X264: A HIGH PERFORMANCE H.264/AVC ENCODER. [online]. [cit. 2013-12-15]. DOI: 10.1.1.96.8042. Dostupné z: http://citeseerx.ist.psu.edu/viewdoc/download?rep=rep1&type= pdf&doi=10.1.1.96.8042 [17] BLACKMAGIC DESIGN. SDK-DeckLink: Software developers kit. July 2013, 317 s. Dostupné z: http://www.blackmagicdesign.com/support/sdks 49


[18] GPUJPEG: JPEG compression and decompression accelerated on GPU. HOLUB, Petr, Martin JIRMAN, Jiˇrí MATELA, Martin PULEC, Jan BROTHÁNEK a Lukáš ˇ RUCKA. SourceForge [online]. 2011, 2013-12-20 [cit. 2013-12-27]. Dostupné z: http://sourceforge.net/projects/gpujpeg/ [19] HOLUB, Petr, Martin ŠROM, Martin PULEC, Jiˇrí MATELA a Martin JIRMAN. GPU-accelerated DXT and JPEG compression schemes for low-latency network transmissions of HD, 2K, and 4K video. Future Generation Computer Systems [online]. 2013, vol. 29, issue 8, s. 1991-2006 [cit. 2013-12-10]. DOI: 10.1016/j.future.2013.06.006. Dostupné z: http: //linkinghub.elsevier.com/retrieve/pii/S0167739X13001209 [20] GeForce GTX 580 Specification. GEFORCE [online]. [cit. 2013-12-15]. Dostupné z: http://www.geforce.com/hardware/desktop-gpus/geforce-gtx580/specifications [21] GeForce GTX TITAN Specification. GEFORCE [online]. [cit. 2013-12-15]. Dostupné z: http://www.geforce.com/hardware/desktopgpus/geforce-gtx-titan/specifications [22] DIGIA. Qt Project [online]. 2013 [cit. 2012-12-06]. Dostupné z: http://qt-project.org/ [23] PCI Express 3.0 Frequently Asked Questions. PCI-SIG [online]. 2010 [cit. 2013-12-15]. Dostupné z: http://www.pcisig.com/news_room/faqs/pcie3.0_faq/#EQ3 [24] CUDA / OpenGL / GLSL Pixel Shader running within the same application. In: NVIDIA Developer Zone [online]. 2010 [cit. 2013-12-10]. Dostupné z: https://devtalk.nvidia.com/default/topic/471763/cuda-openglglsl-pixel-shader-running-within-the-same-application-/ [25] Memory speeds and compatibility. MICRON TECHNOLOGY, Inc. Crucial.com [online]. 2013 [cit. 2013-12-11]. Dostupné z: http://www.crucial.com/support/memory_speeds.aspx [26] Intel? Xeon? Processor E5-2687W. INTEL CORPORATION. [online]. 2012 [cit. 2013-12-28]. Dostupné z: http://ark.intel.com/products/64582/Intel-Xeon-Processor-E52687W-20M-Cache-3_10-GHz-8_00-GTs-Intel-QPI 50


[27] QtGui 5.0: QTouchEvent Class. QT DIGIA. Qt Project Documentation [online]. 2012 [cit. 2013-12-30]. Dostupné z: http://qt-project.org/doc/qt-5.0/qtgui/qtouchevent.html [28] Optická prostˇredí oka. 2009, Brno. Bakaláˇrská práce. Masarykova Univerzita, Lékaˇrská fakuuta. ˚ Vedoucí práce Mgr. Sylvie Petrová. [29] HEROUT, Adam. Poˇcítaˇcová grafika: Studijní opora. Verze: 12.2008. Brno, 2008. [30] Žára J., Beneš B., Sochor J., Felkel P. Moderní poˇcítaˇcová grafika. Vyd 2. Brno: Computer Press, 2005, 609 s. ISBN 80-251-0454-0. [31] Asynchronous Buffer Transfers. COZZI, Patrick a Christophe RICCIO. OpenGL Insights [online]. Boca Raton, FL: CRC Press, 2012, s. 391-414 [cit. 2013-11-15]. ISBN 9781439893760. [32] RYDBERG, Henrik. Multi-touch (MT) Protocol. Kernel.org [online]. 2009-2010 [cit. 2013-12-30]. Dostupné z: https://www.kernel.org/doc/Documentation/input/multi-touchprotocol.txt

51

Pˇríloha A

Obsah CD •

Text práce

•

Vybrané cˇ ásti zdrojového kódu

52

012345

Recommend Documents