Masarykova univerzita Fakulta informatiky
Akcelerace dekódování videa pro nástroj UltraGrid
Bakalárska práca
Martin Piatka
Brno, jar 2018
Masarykova univerzita Fakulta informatiky
Akcelerace dekódování videa pro nástroj UltraGrid
Bakalárska práca
Martin Piatka
Brno, jar 2018
Na tomto mieste sa v tlačenej práci nachádza oficiálne podpísané zadanie práce a vyhlásenie autora školského diela.
Vyhlásenie
Vyhlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.
Martin Piatka
Vedúci práce: RNDr. Miloš Liška Ph.D.
i
Poďakovanie
Chcel by som poďakovať RNDr. Milošovi Liškovi, Ph.D. za trpezli- vosť a pomoc počas vedenia tejto práce. Ďalej chcem poďakovať Mgr. Martinovi Pulcovi za rady a odbornú pomoc. Na záver ďakujem svo- jej rodine, priateľom a kolegom z Laboratória pokročilých sieťových technológií za podporu.
iii Zhrnutie
Bakalárska práca sa zaoberá implementáciou hardvérovej akcelerácie dekódovania videa pre nástroj UltraGrid. Výsledná implementácia umožňuje hardvérovú akceleráciu dekódovania videa pomocou gra- fických kariet firem NVIDIA a Intel. Súčasťou práce je aj meranie výkonu a oneskorenia výsledenj implementácie a jej porovnanie so softvérovým dekódovaním.
iv Kľúčové slová
Ultragrid, akcelerácia, video, NVIDIA, Intel, VDPAU, VA API, ffmpeg, OpenGL, libavcodec
v
Obsah
1 Úvod 1
2 Ultragrid 5 2.1 Modulárna architektúra programu UltraGrid ...... 5 2.2 Práca s videom v programe UltraGrid ...... 6 2.3 Dekódovanie videa v programe UltraGrid ...... 7 2.3.1 FFmpeg ...... 7 2.3.2 Dekódovanie videa pomocou knižnice libavcodec 7 2.3.3 Štruktúra AVCodecContext ...... 8 2.3.4 Konverzia AVFrame na video_frame ...... 8 2.3.5 Funkcia get_format ...... 9 2.4 Zhrnutie ...... 9
3 Hardvérová akcelerácia 11 3.1 Priebeh hardvérovej akcelerácie ...... 11 3.2 Formáty videa ...... 11 3.2.1 Bitová hĺbka ...... 11 3.2.2 Podvzorkovanie farebných zložiek ...... 12 3.2.3 Formát pixelu ...... 12 3.2.4 Kompresia ...... 13 3.2.5 Podpora formátov hardvérom ...... 14 3.3 Prehľad aplikačných rozhraní hardvérovej akcelerácie .... 14 3.3.1 VDPAU ...... 14 3.3.2 NVDEC ...... 15 3.3.3 VA API ...... 15 3.3.4 libmfx ...... 15 3.4 Zhrnutie ...... 16
4 Implementácia akcelerácie dekódovania 17 4.1 Návrh implementácie hardvérovej akcelerácie v programe Ul- traGrid ...... 18 4.1.1 Štruktúra hw_accel_state ...... 18 4.2 Hardvérová akcelerácia s knižnicou libavcodec ...... 19 4.2.1 AVHWDeviceContext ...... 19 4.2.2 AVHWFramesContext ...... 20
vii 4.3 Výber formátu dekódovania ...... 20 4.4 Inicializácia akcelerácie VDPAU ...... 21 4.5 Inicializácia akcelerácie VA API ...... 21 4.5.1 Inicializácia kontextu vaapi_context ...... 21 4.6 Kopírovanie snímkov z akcelerátora ...... 21 4.7 Zhrnutie ...... 22
5 Implementácia akcelerácie s priamym zobrazovaním 23 5.1 Hardvérové snímky AVFrame ...... 23 5.1.1 Počítanie referencií na obrazové dáta ...... 24 5.2 Formát HW_VDPAU ...... 24 5.2.1 Vytváranie, kopírovanie a uvoľňovanie hardvé- rových snímkov ...... 25 5.3 Prúdenie dát medzi dekodérom a displejom ...... 26 5.3.1 Konfigurácia dekodéru a displeja ...... 26 5.3.2 Rekonfigurácia pri chybe ...... 26 5.4 Zobrazovanie HW_VDPAU snímkov ...... 27 5.4.1 VdpVideoSurface a VdpOutputSurface ...... 28 5.4.2 Inicializácia zobrazovania snímkov vdpau . . . 28 5.4.3 Zobrazovanie VdpOutputSurface snímkov . . . 29 5.4.4 Typová chyba v špecifikácii GL_NV_vdpau_interop 29 5.5 Záver ...... 30
6 Meranie výkonu 31 6.1 Použité počítače ...... 31 6.2 Meranie oneskorenia ...... 32 6.3 Meranie výkonu s využitím inštrumentácie ...... 34 6.4 Meranie záťaže procesora ...... 35 6.5 Zhrnutie ...... 37
7 Záver 39
Bibliografia 41
A Elektronická príloha 43
viii 1 Úvod
Kvalita videa sa neustále zdokonaľuje, rastie jeho rozlíšenie, počet snímkov za sekundu ako aj farebná hĺbka. K zlepšeniu dochádza aj pri komprimačných algoritmoch, ktoré dokážu zachovať detaily obrazu aj pri nižších dátových tokoch. Následkom tohto zdokonaľovania je však zvýšená výpočtová ná- ročnosť dekódovania a zobrazovania videa, čo nie je žiadúce z pohľadu narastajúcej popularity prenosných zariadení napájaných batériou, ktoré často obetujú výpočtový výkon na úkor menšej veľkosti a menšej spotreby elektrickej energie. V prípade videa vo vysokom rozlíšení sú tieto zariadenia často príliš málo výkonné na dekódovanie v reálnom čase. Výrobcovia hardvéru preto začali do svojich čipov umiestňovať ASIC (Application-Specific Integrated Circuit) bloky, ktoré umožňujú dekódovanie videa priamo v hardvéri. Tento prístup je často energe- ticky efektívnejší, a preto má priaznivý vplyv aj na výdrž batérie. Na používanie týchto obvodov bohužiaľ neexistuje jednotné rozhranie a takmer každý výrobca navrhol svoje vlastné. Na grafických kartách spoločnosti NVIDIA sa používa rozhranie VDPAU (Video Decode and Presentation API for Unix) a na kartách spoločnosti Intel sa pou- žíva rozhranie VA API (Video Acceleration Application Programming Interface). UltraGrid1 je aplikácia vyvíjaná v Laboratóriu pokročilých sieťo- vých technológií Fakulty informatiky Masarykovej univerzity v spolu- práci so združením CESNET. UltraGrid sa používa na prenosy zvuku a videa vo vysokej kvalite a pri nízkom oneskorení. Vie pracovať s ne- komprimovaným ako aj s komprimovaným videom. V kvalite videa nasleduje najnovšie trendy, ako je podpora videa v rozlíšení až 8K (7680 x 4320 bodov) [1]. V súčasnej dobe UltraGrid komprimované video dekóduje softvé- rovými dekódermi pomocou knižnice ffmpeg. Pri vyšších rozlíšeniach videa vyžaduje softvérové dekódovanie niekedy viac výpočtového výkonu, ako je k dispozícii na prenosných počítačoch. Tieto počítače často obsahujú hardvér podporujúci akceleráciu videa, ale v súčasnom stave ostáva nevyužitý.
1. http://www.ultragrid.cz/
1 1. Úvod
Cieľom mojej bakalárskej práce je pridať podporu hardvérovo ak- celerovaného dekódovania pomocou rozhraní VA API a VDPAU, s vy- užitím knižnice ffmpeg, ktorá tieto rozhrania podporuje [2]. Súčasťou práce je aj meranie výkonu tejto implementácie a jeho porovnanie s výkonom softvérového dekódovania. Prvým krokom bolo zoznámenie sa s nástrojmi, ktoré som na vy- pracovanie práce používal. Prečítal som dokumentáciu nástroja Ul- traGrid, kde som naštudoval možné spôsoby použitia a dostupné prepínače na príkazovom riadku. Bolo potrebné prečítať zdrojový kód a zorientovať sa v častiach týkajúcich sa dekódovania a zobrazovania videa. Ďalej som preštudoval dokumentáciu knižnice ffmpeg, ktorá sa v nástroji UltraGrid používa na dekódovanie videa, ako aj doku- mentácie knižníc libvaapi a libvdpau. Následujúcim krokom bola sa- motná implementácia akcelerácie dekódovania, ktorá bola vykonaná pomocou programovacích jazykov C a C++. Pri tejto implementá- cii sa snímky videa po dekódovaní akcelerátorom kopírovali naspäť do pamäte počítača, čo bolo v prípade akcelerácie grafickými kartami NVIDIA príliš pomalé. Na NVIDIA grafických kartách je k dispozícii OpenGL rozšírenie [3], ktoré dovoľuje dekódované snímky priamo zobrazovať bez ich kopírovania. Toto rozšírenie bolo štandardizované skupinou The Khronos Group, ktorá vydala dokument, ktorý ho po- pisuje2. Ďalším krokom bolo teda preštudovanie tohto dokumentu a implementovanie priameho zobrazovania dekódovaných snímkov obrazu bez ich kopírovania do pamäti počítača. Finálnym krokom bolo zmeranie výkonu a oneskorenia hardvérového dekódovania. Meranie oneskorenia spočíva v meraní času, ktorý prebehne medzi prijatím komprimovaného videa a jeho zobrazením. Toto meranie bolo vy- konané pomocou vysokorýchlostných kamier a referenčného zdroja signálu. Za účelom zistenia vplyvu hardvérovej akcelerácie na onesko- renie videa som meranie vykonal s využitím hardvérovej akcelerácie dekódovania, ako aj softvérového dekódovania a výsledky som po- rovnal. V prvej časti tejto práce popisujem nástroj UltraGrid, princíp hard- vérovej akcelerácie a nástroje, ktoré som na implementáciu využil. V následujúcej časti popisujem implementáciu akcelerácie s využitím
2. https://www.khronos.org/registry/OpenGL/extensions/NV/NV_vdpau_ interop.txt
2 1. Úvod
kopírovania, ako aj akcelerácie s priamym zobrazovaním. Ďalšia časť popisuje priebeh a výsledky merania vplyvu hardvérovej akcelerácie na oneskorenie videa.
3
2 Ultragrid
Ultragrid1 je program, ktorý sa používa na živé prenosy videa a zvuku vo vysokej kvalite a pri nízkom oneskorení s použitím bežne dostup- ného hardvéru. V súčastnosti je vyvíjaný pod slobodnou licenciou BSD v Laboratóriu pokročilých sieťových technológií2 Fakulty informatiky Masarykovej univerzity v spolupráci so združením CESNET3. Jedná sa o fork pôvodného UltraGridu4, ktorý bol vyvíjaný v University of Glasgow a University of Southern California ako výskumný projekt na demonštráciu výkonu 10Gbps sietí.
2.1 Modulárna architektúra programu UltraGrid
Program UltraGrid obsahuje podporu pre špecializovaný hardvér a množstvo funkcií, ktoré pre svoju činnosť vyžadujú knižnice tretích strán. Tieto závislosti môžu byť v niektorých prípadoch nežiadúce, napríklad v prípade ak je potrebné UltraGrid preložiť pre platformu, ktorá pre danú knižnicu nemá podporu, alebo ak funkcie daného mo- dulu nie sú potrebné. Z tohto dôvodu je program UltraGrid založený na modulárnej architektúre, čo znamená, že sa skladá z množstva modulov, ktoré je možné individuálne pri preklade zapínať, alebo vypínať. Moduly v programe UltraGrid sú rozdelené do niekoľkých kategórií. Nasleduje krátky popis modulov, ktoré sú pre túto prácu relevantné.
Dekodéry Moduly, ktoré slúžia na dekódovanie videa sa nazývajú dekodéry. Ich zdrojové súbory sú umiestnené v priečinku src/video_decoders. Program UltraGrid obsahuje dekodéry pre formáty JPEG, DXT. Taktiež obsahuje dekodér libavcodec, ktorý využíva dekodéry dostupné v knižnici libavcodec pro- jektu ffmpeg.
1. http://www.ultragrid.cz/ 2. https://www.sitola.cz/wordpress/ 3. https://www.cesnet.cz/ 4. http://csperkins.org/research/ultragrid/index.html
5 2. Ultragrid
Displeje Moduly, ktoré slúžia na zobrazovanie videa sa nazývajú displeje a ich zdrojové súbory sa nachádzajú v src/video_display. Na zobrazovanie videa v okne sa používajú displeje gl a sdl. Prog- ram UltraGrid taktiež podporuje zobrazovanie videa pomocou množstva hardvérových prehrávacích kariet.
Post-process filtre Post-process filtre sú moduly používané na úpravu snímkov videa po ich dekódovaní a pred ich zobrazením. Program Ul- traGrid v súčastnosti obsahuje filtre napríklad na vkladanie textu, alebo farebného okraja. Zdrojové súbory filtrov sa nachá- dzajú v priečinku src/vo_postprocess.
2.2 Práca s videom v programe UltraGrid
Program UltraGrid potrebuje pri svojom behu uchovávať obrazové dáta videa a metadáta, ktoré tieto používa pre svoje fungovanie nie- koľko dátových typov. Spomínané typy sú zadefinované v súbore src/types.h. Nasleduje krátky prehľad typov, ktoré sú využívané pre dekódovanie a zobrazovanie videa: codec_t codec_t je výčtový typ, ktorý reprezentuje použitý formát vi- dea. Medzi jeho hodnoty patrí napríklad RGBA, alebo aj H264. video_frame Štruktúra video_frame sa v programe UltraGrid používa na uchovávanie obrazových dát video snímku ako aj metadát ob- sahujúcich informácie o dekódovanom videu, ako je napríklad použitý formát pixelu, alebo počet snímkov za sekundu. Samotné obrazové dáta sú ukladané do „dlaždíc“ (tiles), ktoré sa niekedy používajú na rozdelenie videa vo veľkom rozlíšení na menšie časti. video_desc Štruktúra video_desc obsahuje súhrnné informácie o formáte videa, vrátane počtu „dlaždíc“ z ktorých je video zložené.
6 2. Ultragrid 2.3 Dekódovanie videa v programe UltraGrid
Dekódovanie väčšiny podporovaných formátov videa je v programe UltraGrid realizované dekodérom libavcodec, ktorý sprístupňuje dekodéry knižnice s rovnakým názvom - libavcodec. Táto knižnica je súčasťou projektu FFmpeg.
2.3.1 FFmpeg FFmpeg5 je projekt ktorý obsahuje nástroje a knižnice na prácu s mul- timédiami. Podporuje dekódovanie, kódovanie, prehrávanie, rozpoz- návanie, škálovanie a filtrovanie médií. Keďže sa jedná o rozsiahly projekt, je rozdelený do niekoľkých častí – knižnice libavcodec, libavu- til, libavformat, libavfilter, libavdevice, libswscale, libswresample a nástroje príkazovej riadky ffmpeg, ffplay a ffprobe, ktoré tieto kniž- nice používajú. V svojej práci som využíval funkcionalitu poskytnutú knižnicou libavcodec.
2.3.2 Dekódovanie videa pomocou knižnice libavcodec Knižnica libavcodec poskytuje na dekódovanie videa rozhranie v ja- zyku C. Priebeh dekódovania je možné zhrnúť do následujúcich kro- kov: 1. Inicializácia knižnice libavcodec: Pred požitím tejto knižnice je nutné ju najskôr inicializovať. Toto je vykonané funkciou avcodec_register_all() 2. Zvolenie a „otvorenie“ dekodéru: Dostupné dekodéry je možné zistiť volaním avcodec_find_decoder. Po vybraní vhodného dekodéru je potrebné tento dekodér „otvoriť“. Táto operácia inicializuje štruktúru AVCodecContext na použitie s týmto de- kodérom a vykoná sa zavolaním funkcie avcodec_open2(). 3. Dekódovanie snímkov: Dekódovanie videa prebieha pomo- cou funkcie avcodec_decode_video2, do ktorej sú dáta vkla- dané pomocou štruktúry AVPacket, ktorá obsahuje ukazovateľ na dáta a ich dĺžku. Pretože dopredu nevieme určiť hranicu
5. https://ffmpeg.org/
7 2. Ultragrid
jednotlivých snímkov v poli nedekódovaných obrazových dát, nemusí vždy dôjsť k dekódovaniu celého obrazového snímku. Funkcia avcodec_decode_video2 preto postupne číta dáta kým dôjde k dekódovaniu celého snímku, pričom nastaví príznak got_frame, alebo po koniec dát v štruktúre AVPacket. Výsledné obrazové dáta sú zapísané do štruktúry AVFrame.
4. Uvoľnenie prostriedkov: Po dokončení dekódovania je potrebné uvoľniť prostriedky alokované knižnicou libavcodec. Použitím funkcie avcodec_close sa AVCodecContext „uzavrie“ a napo- kon sa pomocou funkcie avcodec_free_context uvoľní.
2.3.3 Štruktúra AVCodecContext
Štruktúra AVCodecContext6 je používaná knižnicou libavcodec na ukladanie dát, ktoré táto knižnica potrebuje pre svoju činnosť. Okrem toho táto štruktúra slúži aj ako rozhranie na komunikáciu medzi kniž- nicou libavcodec a ostatným kódom. Z tejto štruktúry sa dajú čítať informácie o dekódovanom videu ako je jeho rozmer, počet snímkov za sekundu, formát pixelu. Zároveň je v tejto štruktúre možné nastaviť niektoré nastavenia a príznaky.
2.3.4 Konverzia AVFrame na video_frame
Knižnica libavcodec používa na reprezentáciu video snímkov štruk- túru AVFrame7, zatiaľ čo UltraGrid používa štruktúru video_frame. Aby bola zaistená funkčná interoperabilita medzi knižnicou libavcodec a programom UltraGrid sú snímky po dekódovaní prevádzané na snímky typu video_frame. K tomuto účelu slúžia statické funkcie defi- nované v súbore src/video_decompress/libavcodec.c. Tento súbor taktiež obsahuje pole convert_funcs, v ktorom sú uložené ukazateľe na tieto funkcie, spolu s informáciou o formátoch videa, s ktorými pracujú.
6. https://ffmpeg.org/doxygen/3.4/structAVCodecContext.html 7. https://ffmpeg.org/doxygen/3.4/structAVFrame.html
8 2. Ultragrid
2.3.5 Funkcia get_format Knižnica libavcodec umožňuje dekódovanie videa do rôznych for- mátov. Voľba formátu pre dekódovanie je sprístupnená pomocou funkcie položky get_format v štruktúre AVCodecContext. Jedná sa o funkčný ukazovateľ na užívateľom definovanú funkciu. Argumen- tom tejto funkcie je zoznam pixel formátov, do ktorých je možné video dekódovať. Zvolený formát potom funkcia vráti. Ak bol v štruktúre AVCodecContext nastavený ukazateľ na funkciu get_format dôjde k jej zavolaniu pred dekódovaním prvého snímku. V programe UltraGrid je na voľbu formátu dekódovaných snímkov používaná funkcia get_format_callback. Táto funkcia iteruje zozna- mom dostupných formátov a vyberie prvý z nich, ktorý je možné pomocou funkcie z poľa convert_funcs konvertovať.
2.4 Zhrnutie
Pre pochopenie návrhu a implementácie mojej práce je potrebné po- chopenie spôsobu akým nástroj UltraGrid pracuje s videom. Táto kapitola preto obsahuje opis nástroja UltraGrid a jeho štruktúry. Ďalej obsahuje popis dekodéra libavcodec, ktorý sa v nástroji UltraGrid využíva na dekódovanie väčšiny podporovaných formátov, a princíp používania knižnice libavcodec, ktorú tento dekodér využíva pre svoje fungovanie. Tento dekodér som v svojej práci modifikoval za účelom podpory harvérovej akcelerácie.
9
3 Hardvérová akcelerácia
Hardvérová akcelerácia je pojem, ktorým sa označuje presunutie vy- konávania nejakého výpočtu z procesora na špecializovaný hardvér, ktorý bol navrhnutý špeciálne pre tento typ výpočtu. Takýto typ hard- véru sa označuje ako ASIC1 (aplikačne špecifický integrovaný obvod). V súčastnosti sú obvody na dekódovanie videa zahrňované výrobcami grafických kárt do svojich čipov.
3.1 Priebeh hardvérovej akcelerácie
Moderné grafické karty obsahujú svoju vlastnú operačnú pamäť pre svoje výpočty. V prípade ak grafická karta obsahuje modul na akcele- ráciu dekódovania videa, je na dekódovanie použitá práve táto pamäť. To znamená, že pred dekódovaním, musia byť vstupné dáta z ope- račnej pamäte počítača najprv prenesené do grafickej pamäti a po dekódovaní je výsledok prenesený naspäť. Tento prenos prebieha cez DMA2 (Direct Memory Access) kanál a je riadený ovládačom grafickej karty.
3.2 Formáty videa
Existuje veľké množstvo spôsobov ako uložiť digitálne video v pa- mäti počítača. Rôzne videá sa môžu navzájom líšiť napríklad svojim rozlíšením, bitovou hĺbkou, snímkovou frekvenciou, alebo aj použi- tým algoritmom kompresie. Keďže hardvérové dekodéry videa sú aplikačne špecifické integrované obvody dokážu dekódovať len for- máty videa pre ktoré boli navrhnuté. Nasleduje teda krátky prehľad jednotlivých vlastností formátu videa.
3.2.1 Bitová hĺbka Bitová hĺbka udáva počet bitov použitých na vyjadrenie jednej vzorky videa. Vyššie bitové hĺbky umožňujú presnejšie vyjadrenie farby a
1. https://sk.wikipedia.org/wiki/ASIC 2. https://sk.wikipedia.org/wiki/Priamy_pr%C3%ADstup_do_pam%C3%A4te
11 3. Hardvérová akcelerácia intenzity. V súčastnosti sa pre video zväčša používajú bitové hĺbky 8 a 10 bitov na vzorku.
3.2.2 Podvzorkovanie farebných zložiek Pri farebnom videu je nutné pre každý bod uložiť okrem intenzity aj farebnú informáciu. Ako je informácia zapísaná v pamäti je dané spôsobom vzorkovania a podvzorkovania farebných zložiek. Pri kó- dovaní videa sa používajú schémy typu YCbCr. Namiesto uchovávania samostatných zložiek pre kanály červenej, zelenej a modrej intenzity ako u známejšej RGB schémy sa ukladá zložka svetlosti označovaná ako Y alebo „luma“ a farebné zložky Cb a Cr. Keďže ľudské oko je citli- vejšie na zmeny jasu ako zmeny zafarbenia [4], je možné šetriť úložné miesto ukladaním menšieho množstva informácií o zafarbení. Toho je možné docieliť ukladaním spoločnej farebnej zložky pre susedné obrazové body. Následkom tejto úspory je však strata na kvalite, ktorá je pozorovateľná hlavne v situácii keď dôjde k ostrej farebnej zmene vo vnútri spoločného farebného bloku. Na vyjadrenie konkrétneho pomeru počtu bitov pre jednotlivé zložky sa používa zápis v tvare j:a:b
∙ j vyjadruje šírku konceptuálneho regiónu (vždy je rovné 4)
∙ a vyjadruje počet vzoriek farebných zložiek v prvom riadku širokého j bodov
∙ b udáva počet zmien farebných zložiek medzi prvým a druhým riadkom
Na obrázku 3.1 je znázornené uloženie snímky pomocou schémy 4:2:0, ktorá patrí medzi najpoužívanejšie. Táto schéma umožňuje uložiť pri bitovej hĺbke 8 bitov jeden pixel na 12 bitov, čo je polovica miesta, ktoré by bolo potrebné pri ukladaní pomocou formátu RGB.
3.2.3 Formát pixelu Formát pixelu popisuje bitovú hĺbku, spôsob vzorkovania ako aj spô- sob uloženia jednotlivých zložiek v pamäti. Formáty pixelov je možné rozdeliť na planárne a prekladané formáty. Pri planárnom uložení sú
12 3. Hardvérová akcelerácia
Cr Cr
Cr Cr Cb Cb
YYY CbY Cb YYYY YYYY YYYY
Obr. 3.1: schéma 4:2:0 s planárnym uložením vzorky jednotlivých typov uložené od seba oddelene v jednotlivých rovinách (plane). Pri prekladanom uložení sú jednotlivé zložky ulo- žené striedavo v jednej rovine. Mimo to existujú ešte semiplanárne formáty – napríklad formát NV12, pri ktorom je zložka svetlosti Y ulo- žená oddelená a dve farebné zložky sú uložené prekladane v spoločnej rovine.
3.2.4 Kompresia Jednoduché ukladanie informácií o každom obrazovom bode v kaž- dom snímku by bolo z pohľadu pamäťovej náročnosti veľmi neprak- tické. Je teda žiadúce redukovať množstvo obrazových dát použitím kompresie. Stratová kompresia spočíva v odstránení malých detailov takým spôsobom, aby pre človeka nastal čo najmenší rozdiel. Väčšina súčasne používaných kompresných algoritmov využíva fakt, že bez- prostredne následujúce snímky sú obvykle veľmi podobné. Konkrétna implementácia kompresného algoritmu v softvéri alebo v hardvéri sa nazýva kodek. Súčasne dostupné grafické karty bežne podporujú štandardy kom- presie videa vyvinuté skupinou MPEG (Moving Picture Experts Group), medzi ktoré patria štandardy MPEG2, MPEG4, H.264 a H.265. V sú- častnosti patrí medzi najpoužívanejšie štandardy H.264 [5].
Profily a levely Kodeky rodiny MPEG je možné používať v rôznych konfiguráciách, ktoré využívajú rôzne funkcie kodeku. Na vyjadrenie kompatibility
13 3. Hardvérová akcelerácia daného hardvéru alebo softvéru s rôznymi funkciami sú štandardom zadefinované profily a levely [6]. Profily popisujú, aké funkcie jemožné pri danom profile využívať. Levely zas udávajú požadovaný výkon dekódovania.
3.2.5 Podpora formátov hardvérom Podpora najnovších štandardov v hardvéri, s ktorým sa bežne stret- neme v osobných počítačoch väčšinou zaostáva, pretože výrobcovia do svojich grafických kariet často integrujú dekodéry až potom akosa daný štandard kódovania videa stane rozšíreným. V súčastnosti najrozšírenejší štandard H.264 je podporovaný väčši- nou hardvérových akcelerátorov dekódovania videa, ale obvykle je dekódovanie obmedzené na formáty s bitovou hĺbkou 8 a so schémou podvzorkovania farebných zložiek 4:2:0. Podpora H.265 zatiaľ nieje veľmi rozšírená, ale pomaly sa situácia zlepšuje a najnovšie modely grafických kariet od firiem NVIDIA a Intel podporu už obsahujú.
3.3 Prehľad aplikačných rozhraní hardvérovej akcelerácie
3.3.1 VDPAU VDPAU (Video Decode and Presentation API for Unix)3 je aplikačné rozhranie na dekódovanie a prezentovanie videa pre operačné sys- témy podobné Unixu. Toto rozhranie bolo navrhnuté firmou NVIDIA a poskytnuté bez licenčných poplatkov. Na zobrazovanie dekódovaných snímkov pomocou rozhrania OpenGL bolo štandardizované OpenGL rozšírenie GL_NV_vdpau_interop4, ktoré dovoľuje mapovanie dekódo- vaných snímkov na OpenGL textúry. Knižnica, ktorá toto rozhranie implementuje je distribuovaná pod voľnou licenciou MIT. Dôsledok toho je, že rozhranie VDPAU je možné použiť v spojení s otvoreným ovládačom nouveau, alebo aj s grafickými kartami tretích strán ako napríklad AMD.
3. https://www.freedesktop.org/wiki/Software/VDPAU/ 4. https://www.khronos.org/registry/OpenGL/extensions/NV/NV_vdpau_ interop.txt 14 3. Hardvérová akcelerácia
3.3.2 NVDEC
NVDEC5 (niekedy tiež označované ako cuvid) je novšie API od firmy NVIDIA, ktorého iniciálna verzia bol vydaná v júni 2016. Toto API na- väzuje na rozhranie CUDA, ktoré využíva na prístup k dekódovaným snímkam a ich následnému spracovaniu. Na zobrazenie snímkov sú k dispozícii rozhrania, ktoré poskytujú interoperabilitu s OpenGL a DirectX vo verziách 9 a 11 [7]. V porovnaní s VDPAU je toto API však uzavreté, čo spôsobuje, že sa dá používať len hardvéri od spoločnosti NVIDIA a s použitím uzavretých ovládačov.
3.3.3 VA API
VA API (Video Acceleration API)6 je aplikačné rozhranie na dekódova- nie, kódovanie a prezentovanie videa. Aj keď je nezávislé na konkrétnej platforme, používa sa prevažne na operačných systémoch podobných Unixu. Toto rozhranie bolo pôvodne vyvinuté firmou Intel na použitie s grafickými jednotkami série GMA (Graphics Media Accelerator), ale podobne ako rozhranie VDPAU je toto rozhranie možné používať bez licenčných poplatkov a doprevádzajúca implementácia v knižnici libVA7 je licencovaná pod permisívnou licenciou MIT. Toto dovolilo mnohým ďalším firmám toto rozhranie použiť v svojich produktoch.
3.3.4 libmfx
Libmfx je proprietárna knižnica, ktorú vydala firma Intel ako súčasť balíku Intel Media SDK8. Oproti VA API môže v niektorých prípadoch poskytnúť vyšší výkon. Nevýhodou je však užšia podpora kodekov a hardvéru. Inštalácia tohto balíku je komplikovanejšia. Vývojári kniž- nice ffmpeg silne odporúčajú namiesto libmfx použiť VA API[8].
5. https://developer.nvidia.com/nvidia-video-codec-sdk 6. https://01.org/vaapi 7. https://github.com/intel/libva 8. https://software.intel.com/en-us/media-sdk
15 3. Hardvérová akcelerácia 3.4 Zhrnutie
V tejto kapitole bol popísaný princíp hardvérovej akcelerácie dekódo- vania videa. Táto kapitola obsahuje aj krátky prehľad formátov videa, aby bolo ďalej možno popísať podporu týchto formátov hardvérovými akcelerátormi. V svojej práci som zvolil rozhrania VDPAU a VA API, pretože sa vďaka svojim voľným licenciám stali najrozšírenejšími rozhraniami pre hardvérové dekódovanie videa. To znamená, že okrem zadaním vyžadovaných grafických kariet spoločností Intel a NVIDIA, bymalo byť možné použiť moju implementáciu aj s hardvérom iných výrobcov, ako napríklad S3 Graphics a AMD. Toto je však mimo rozsah tejto práce a teda nebolo testované.
16 4 Implementácia akcelerácie dekódovania
V tejto kapitole je popísaná implementácia hardvérovej akcelerácie dekódovania videa v programe UltraGrid. Táto implementácia pod- poruje akceleráciu na akcelerátoroch vyrábanými firmami Intel a NVI- DIA pomocou aplikačných rozhraní VDPAU a VA API. Akcelerácia dekódovania v mojej implementácii môže pracovať v dvoch režimoch. Dôvodom je, že po dekódovaní snímku hardvéro- vým akcelerátorom je tento snímok obvykle v pamäti hardvérového dekodéra a nie je možné k nemu pristupovať klasickým spôsobom. Na prácu s takýmto snímkom je nutné využiť funkcie poskytnuté aplikač- ným rozhraním daného akcelerátora. Najjednoduchší spôsob práce s takýmito snímkami je ich kopírovanie z akcelerátora do operačnej pamäti počítača, po ktorom je možné so snímkami pracovať rovnakým spôsobom ako so softvérovo dekódovanými snímkami. Toto kopí- rovanie však môže byť v niektorých prípadoch neefektívne, hlavne v tom prípade ak je použitý akcelerátor súčasťou grafickej karty, ktorú chceme zároveň použiť aj na zobrazovanie týchto snímkov. V tejto práci som preto implementoval hardvérovú akceleráciu dekódovania videa, ktorá môže pracovať v dvoch režimoch – s kopí- rovaním a bez kopírovania. Rozdiel medzi týmito prístupmi je možné pozorovať na obrázkoch 4.1 a 5.1.
CPU 0 1 GPU 0 1
dekódovanie
Obr. 4.1: Priebeh akcelerácie s kopírovaním
Implementácia samotného dekódovania je pre oba režimy rovnaká. Tieto režimy sa líšia len spôsobom práce so snímkami v pamäti hard-
17 4. Implementácia akcelerácie dekódovania vérového akcelerátora po ich dekódovaní. Väčšinu tejto kapitoly tvorí opis implementácie hardvérovej akcelerácie dekódovania ktorá je spo- ločná pre oba režimy. V závere tejto kapitoly je popísaný mechanizmus režimu kopírovania. Režim zobrazovania dekódovaných snímkov bez ich kopírovania je značne zložitejší, a je opísaný v kapitole 5.
4.1 Návrh implementácie hardvérovej akcelerácie v programe UltraGrid
Na implementáciu hardvérovej akcelerácie dekódovania videa v prog- rame UltraGrid som využil knižnicu libavcodec, ktorá sa v tomto programe už využíva na softvérové dekódovanie. Vo svojej implementácii som kód rozdelil do viacerých súborov. Kód ktorý je spoločný pre viac akcelerácií vytvoril zdrojový súbor src/hwaccel_libav_common.c a pre kód, ktorý je špecifický pre danú akceleráciu súbory src/hwaccel_
4.1.1 Štruktúra hw_accel_state Na uloženie aktuálneho stavu harvérovej akcelerácie som vytvoril štruktúru hw_accel_state v ktorej sú uložené informácie o použitej hardvérovej akcelerácii a pomocné dáta: type výčtový typ, ktorého hodnota hovorí o aktuálne použitej hard- vérovej akcelerácii. V prípade, že sa žiadna nepoužíva je jeho hodnota HWACCEL_NONE. copy pravdivostný typ, v prípade využitia akcelerácie s kopírovaním je jeho hodnota logická pravda. tmp_frame ukazovateľ na pomocný snímok typu AVFrame, ktorý sa používa pri kopírovaní.
18 4. Implementácia akcelerácie dekódovania
uninit voliteľný ukazovateľ na funkciu, ktorá sa volá po dokončení dekódovania.
ctx ukazovateľ, ktorý môže byť aktuálnou akceleráciou využitý na odkladanie pomocných dát.
4.2 Hardvérová akcelerácia s knižnicou libavcodec
Hardvérová akcelerácia videa s použitím knižnice libavcodec vy- žaduje vytvorenie a pripojenie hardvérových kontextov k štruktúre AVCodecContext a zvoleniu príslušného hardvérového formátu vo fun- kcii get_format. Hardvérové kontexty slúžia na ukladanie dát potrebných na ko- munikáciu a korektné pracovanie s hardvérovým akcelerátorom. Me- dzi tieto kontexty patria AVHWDeviceContext1 a AVHWFramesContext2. Tieto štruktúry sú vytvárané pre rôzne akcelerácie rovnakým spôso- bom.
4.2.1 AVHWDeviceContext
Táto štruktúra slúži na ukladanie hardvérovo špecifického stavu za- riadenia používaného na hardvérovú akceleráciu dekódovania videa. Na vytvorenie a inicializáciu tejto štruktúry sa používa funkcia av_hwdevice_ctx_create, ktorej sa predá typ zariadenia pomocou vý- čtového typu AVHWDeviceType a ukazovateľ na štruktúru AVBufferRef3, do ktorej je výsledný kontext uložený. Štruktúra AVBufferRef slúži na spravovanie pamäte počítaním referencií. Toto je bližšie popísané v kapitole 5.1.1.
1. https://ffmpeg.org/doxygen/3.4/structAVHWDeviceContext.html 2. https://ffmpeg.org/doxygen/3.4/structAVHWFramesContext.html 3. https://ffmpeg.org/doxygen/3.4/structAVBufferRef.html
19 4. Implementácia akcelerácie dekódovania
4.2.2 AVHWFramesContext
Táto štruktúra reprezentuje pool4 hardvérových snímkov videa, ktorý slúži na ukladanie dekódovaných snímkov. Táto štruktúra je alokovaná funkciou av_hwframe_ctx_alloc. Ná- sledne je v nej potrebné nastaviť parametre ako rozmer videa, formát pixelu a iniciálnu veľkosť fondu. Po nastavení všetkých potrebných pa- rametrov sa inicializuje pomocou funkcie av_hwframe_ctx_init. Toto je v mojej implementácii vykonané funkciou create_hw_frame_ctx.
4.3 Výber formátu dekódovania
Keďže hardvérová akcelerácia dekódovania videa môže v niektorých prípadoch spôsobovať problémy, je žiadúce, aby mohol užívateľ povo- liť, alebo zakázať jej využitie. V programe UltraGrid som toto imple- mentoval pomocou parametru use-hw-accel na príkazovom riadku. Tento parameter je definovaný pomocou makra ADD_TO_PARAM, ktoré umožňuje pridať aj krátky popis, ktorý sa zobrazí v nápovede vyvola- nej príkazom uv --param help. V programe UltraGrid je ukazovateľ get_format nastavený na funkciu get_format_callback. V tejto funkcii som pri implementácii definoval pole accels, v ktorom sú k formátom pixelov uložených pomocou výčtového typu AVPixelFormat uložené ukazovatele na ini- cializačné funkcie jednotlivých akcelerácií. Pri výbere formátu sa najskôr skontroluje, či užívateľ nastavil para- meter use-hw-accel pomocou funkcie get_commandline_param. Ak je tento parameter nastavený, je pre každú akceleráciu definovanú v poli accels skontrolované, či je video pomocou nej možné dekódovať. Ak to možné je, akcelerácia sa príslušnou inicializačnou funkciou inicia- lizuje a funkcia get_format_callback následne vráti formát patriaci k tejto akcelerácii. Ak použitie akcelerácie nie je povolené, alebo nebolo možné pre daný formát videa nájsť a úspešne inicializovať žiadnu akceleráciu, je následne pomocou pôvodného kódu zvolený softvérový dekodér.
4. https://en.wikipedia.org/wiki/Pool_(computer_science)
20 4. Implementácia akcelerácie dekódovania 4.4 Inicializácia akcelerácie VDPAU
Inicializácia VDPAU akcelerácie prebieha vo funkcii vdpau_init, ktorú som implementoval v súbore src/hwaccel_vdpau.c. Táto funkcia inicializuje potrebné kontexty zariadenia, alokuje pamäť pre pomocný snímok tmp_frame a nastaví potrebné položky v štruktúre hw_accel_state. Vytvorené kontexty potom prepojí s kontextom AVCodecContext pomocou funkcie av_vdpau_bind_context.
4.5 Inicializácia akcelerácie VA API
Inicializácia akcelerácie VAAPI prebieha vo funkcii vaapi_init, ktorú som implementoval v súbore src/hwaccel_vaapi.c. Pri použití novšej verzie knižnice libavcodec prebieha inicializá- cia akcelerácie VA API veľmi podobne ako inicializácia akcelerácie VDPAU. Vytvorený AVHWFramesContext je priradený do premennej hw_frames_ctx v štruktúre AVCodecContext. V prípade použitia knižnice libavcodec vo verzii staršej ako verzia 57.74.100 je potrebné naviac vytvoriť kontext vaapi_context [9].
4.5.1 Inicializácia kontextu vaapi_context Tento kontext obsahuje konfiguráciu hardvérového dekodéru. Vytvára sa pomocou funkcií knižnice libva a jeho vytvorenie spočíva vo vý- bere vhodného dekódovacieho profilu. Vytvorenie tohto kontextu je pri verziách knižnice libavcodec vyš- ších ako 57.74.100 plne automatické a štruktúra vaapi_context sa vôbec nepoužíva. Vytváranie tohto kontextu je preto v mojej imple- mentácii prekladané podmienene len v prípade potreby.
4.6 Kopírovanie snímkov z akcelerátora
Po vytvorení a pripojení hardvérových kontextov ku kontextu deko- déra AVCodecContext je možné začať video dekódovať. Dekódované snímky budú však uložené v pamäti dekodéra a štruktúra AVFrame bude obsahovať len identifikačné číslo daného dekódovaného snímku.
21 4. Implementácia akcelerácie dekódovania
Pred ďalším spracovaním je teda potrebné dekódované snímky kopírovať z pamäte akcelerátora do operačnej pamäti. V mojej im- plementácii na to slúži funkcia tranfer_frame, ktorá najskôr pomo- cou funkcie av_hwframe_transfer_data skopíruje dáta do priprave- ného pomocného snímku tmp_frame a následne pomocou funkcie av_frame_move_ref prenesené dáta presunie do pôvodného snímku. Po zavolaní tejto funkcie už snímok obsahuje obrazové dáta a môže byť ďalej spracovávaný rovnakým spôsobom ako po softvérovom de- kódovaní.
4.7 Zhrnutie
Táto kapitola popisuje návrh a implementáciu hardvérovej akcelerácie dekódovania videa v programe UltraGrid. Takisto sú popísané režimy akcelerácie s kopírovaním a bez kopírovania. Implementácia popísaná v tejto kapitole podporuje režim kopíro- vania na akcelerátoroch firiem NVIDIA a Intel a zároveň tvorí spoločný základ pre režim bez kopírovania, ktorý je popísaný v následujúcej kapitole.
22 5 Implementácia akcelerácie s priamym zobra- zovaním
V prípade ak je zariadenie obsahujúce hardvérový akcelerátor dekó- dovania videa používané aj na zobrazovanie dekódovaných snímkov je akcelerácia s využitím kopírovania neefektívna, pretože vyžaduje kopírovanie snímkov dva krát – po dekódovaní smerom z dekodéra do operačnej pamäte a pri zobrazovaní zas naopak. Z tohto dôvodu je umožnené z dekódovaných snímkov vytvá- rať OpenGL1 textúry, bez ich zbytočného kopírovania. Toto je zobra- zené na obrázku 5.1. Túto funkcionalitu ponúka OpenGL rozšírenie GL_NV_vdpau_interop2. V svojej implementácii som toto rozšírenie využil pri modifikácii UltraGrid displeja gl.
CPU 0 1 GPU 0 1
dekódovanie
Obr. 5.1: Priebeh akcelerácie s kopírovaním
5.1 Hardvérové snímky AVFrame
Knižnica libavcodec používa na uchovávanie hardvérových sním- kov štruktúru AVFrame rovnako ako u bežných snímkov. Rozdiel spo- číva v tom, že pole ukazovateľov data neobsahuje ukazovatele na
1. https://www.opengl.org/ 2. https://www.khronos.org/registry/OpenGL/extensions/NV/NV_vdpau_ interop.txt
23 5. Implementácia akcelerácie s priamym zobrazovaním obrazové dáta. Namiesto nich je v tomto poli uložená [10] premenná typu VdpVideoSurface3, ktorá obsahuje číslo hardvérového snímku. Hardvérové snímky majú oproti softvérovým snímkom naviac pripo- jený harvérový kontext AVHWFramesContext s ktorým sú dekódované snímky zviazané.
5.1.1 Počítanie referencií na obrazové dáta Snímky AVFrame sú vo veľa prípadoch používané viacerými časťami programu súčasne. Dekódované snímky si môže napríklad dekodér vnútorne uchovávať, zatiaľ čo ich predáva ďalej displeju. Správa pa- mäti môže byť u takýchto dát problematická, pretože nie je vždy možné jasne určiť, ktorá časť programu je vlastníkom týchto dát a zodpovedá za ich uvoľnenie. Medzi takéto dáta patria aj hardvérové kontexty za- riadení, ktoré sú potrebné zároveň pri dekódovaní aj pri zobrazovaní snímkov. V knižnici libavcodec sa na ukladanie týchto dát používa tech- nika počítania referencií4. Tento prístup má tú výhodu, že dáta takto uložené nemajú „vlastníka“, ktorý zodpovedá za ich uvoľnenie po tom, ako prestanú byť potrebné. Namiesto toho sa drží počet referencií a po uvoľnení poslednej z nich prebehne automatické uvoľnenie dát. V knižnici libavcodec je toto realizované pomocou dvojice štruk- túr AVBuffer5 a AVBufferRef6. Nové referencie sa dajú vytvárať pomo- cou funkcie av_buffer_ref a uvoľňovať pomocou av_buffer_unref.
5.2 Formát HW_VDPAU
Za účelom predávania hardvérových vdpau snímkov medzi dekodé- rom a displejom som v svojej implementácii vytvoril formát HW_VDPAU. Z dôvodu prehľadnosti som vytvoril aj štruktúru hw_vdpau_frame. Táto štruktúra sa používa na reprezentáciu hardvérových vdpau snímkov. Takisto obsahuje aj príslušný hardvérový kontext, na repre- zentáciu ktorého som vytvoril štruktúru hw_vdpau_ctx. Pre korektnú
3. http://download.nvidia.com/XFree86/vdpau/doxygen/html/group___ vdp_video_surface.html 4. https://en.wikipedia.org/wiki/Reference_counting 5. https://ffmpeg.org/doxygen/3.4/structAVBuffer.html 6. https://ffmpeg.org/doxygen/3.4/structAVBufferRef.html 24 5. Implementácia akcelerácie s priamym zobrazovaním
správu pamäti obsahuje aj AVBufferRef referencie na dáta alokované knižnicou libavcodec.
5.2.1 Vytváranie, kopírovanie a uvoľňovanie hardvérových snímkov
V programe UltraGrid sú operácie ako vytváranie, kopírovanie a uvoľňovanie realizované funkciami, ktoré sú definované v súbore src/video_frame.c Vytváranie nového snímku je realizované rodinou funkcií vf_alloc. Tieto funkcie potrebujú informácie o použitom formáte, aby mohli alokovať pamäťové miesto so správnou veľkosťou. Tieto informácie sú obsiahnuté v štruktúre codec_info_t, ktorá sa nachádza v súbore src/video_codec.c. Zásadný rozdiel medzi hardvérovými a bežnými snímkami spo- číva v tom, že ich veľkosť s premenlivým rozlíšením zostáva kon- štantná. Toto je spôsobené faktom, že neobsahujú samotné obrazové dáta, ale len identifikačné číslo snímku uloženého v pamäti akcelerá- tora. Z tohto dôvodu som do štruktúry codec_info_t zaviedol nový príznak const_size, ktorý signalizuje, že daný formát používa kon- štantnú veľkosť. Ak je tento príznak nastavený, tak veľkosť snímku určuje hodnota block_size zo štruktúry codec_info_t. Pre korektné kopírovanie hardvérových snímkov nestačí jednodu- ché kopírovanie dát štruktúry hw_vdpau_frame, ale je potrebné záro- veň vytvoriť nové AVBufferRef referencie. Za týmto účelom som vy- tvoril funkciu hw_vdpau_frame_data_cpy, pre ktorú som v štruktúre codec_info_t vytvoril položku copy_data a nakoniec som upravil funkciu vf_get_copy aby túto funkciu používala. Pri uvoľňovaní hardvérových snímkov je zas potrebné uvoľniť AVBufferRef referencie. Toto v mojej implementácii vykonáva funkcia hw_vdpau_free_extra_data, pre ktorú je v štruktúre codec_info_t položká free_extra_data. Nakoniec som upravil funkciu vf_free, aby bola táto funkcia zavolaná pred uvoľnením pamäte snímky.
25 5. Implementácia akcelerácie s priamym zobrazovaním 5.3 Prúdenie dát medzi dekodérom a displejom
Ako už bolo spomínané v sekcii 2.1, program UltraGrid je založený na modulárnej architektúre. Za účelom zobrazovania dekódovaných snímkov musí dochádzať ku presunu obrazových dát z dekodéra do displeja. Na predávanie dát medzi dekodérom a displejom slúži štruktúra video_frame. Za alokáciu tejto štruktúry je zodpovedný displej. Po za- písaní obrazových dát dekodérom je táto štruktúra predaná naspäť do displeja, ktorý je zodpovedný aj za jej korektné uvoľnenie. Táto výmena dát je riadená vláknom vykonávajúcim funkciu decompress_thread v súbore src/rtp/video_decoders.cpp a je znázornená na obrázku 5.2.
5.3.1 Konfigurácia dekodéru a displeja Pre korektné fungovanie musia dekodér a displej na výmenu dát me- dzi sebou používať dopredu dohodnutý formát. Po ustanovení spoloč- ného formátu sú dekodér a displej nastavené na použitie tohto formátu pomocou funkcií display_reconfigure a decompress_reconfigure. Tento proces sa nazýva konfigurácia. Toto má na starosti kód v súbore src/rtp/video_decoders.cpp, ktorý na základe formátov ktoré pod- poruje displej vyberie vhodný dekodér a následne ich nakonfiguruje na použitie spoločného formátu.
5.3.2 Rekonfigurácia pri chybe Problém pri použití tohto riešenia môže nastať v situácii, ak hard- vérové dekódovanie z nejakého dôvodu zlyhá. V takomto prípade je žiadúce snímky dekódovať aspoň softvérovým dekodérom. Deko- dér a displej boli však nakonfigurované používať formát HW_VDPAU s ktorým sú softvérovo dekódované snímky nekompatibilné. Riešením tohto problému je implementovať mechanizmus, pomocou ktorého je možné vyvolať rekonfiguráciu dekodéru a displeja na používanie nehardvérového formátu. V svojej implementácii som preto za účelom signalizácie potreby rekonfigurácie zaviedol výčtový typ decompress_status, ktorým som nahradil pôvodný typ návratovej hodnoty funkcie decompress_frame.
26 5. Implementácia akcelerácie s priamym zobrazovaním
src/video_decoders/libavcodec.c src/rtp/video_decoders.cpp
decompress_frame
return
src/video_display/gl.cpp display_get_frame
return
display_put_frame
Obr. 5.2: Predávanie obrazových dát medzi dekodérom a displejom
Pôvodne táto funkcia vracala logickú hodnotu informujúcu o dekódo- vaní ďalšieho snímku. Tomuto odpovedajú hodnoty výčtového typu DECODER_GOT_FRAME a DECODER_NO_FRAME. Na signalizáciu potreby re- konfigurácie je použitá hodnota DECODER_CANT_DECODE. Ak počas dekódovania dôjde k vráteniu tejto hodnoty je aktuálne použitý formát zaradený do „čiernej listiny“ a pri ďalšej rekonfigurácii už nebude zvolený. Následne je táto rekonfigurácia vyvolaná.
5.4 Zobrazovanie HW_VDPAU snímkov
Na zobrazovanie HW_VDPAU snímkov som v mojej práci upravil v prog- rame UltraGrid displej gl. Zobrazovanie hardvérových vdpau sním- kov spočíva v ich konverzii na OpenGL textúry, ktoré sa potom už zobrazujú bežným spôsobom.
27 5. Implementácia akcelerácie s priamym zobrazovaním
5.4.1 VdpVideoSurface a VdpOutputSurface Dekódované snímky z dekodéra sú snímky typu VdpVideoSurface7. Tieto snímky obsahujú dáta interne uložené ako YCbCr a nie sú určené na zobrazovanie [11], a je ich najprv nutné konvertovať na snímky typu VdpOutputSurface8. Na túto konverziu je možné využiť video mixér VdpVideoMixer9, ktorý je súčasťou knižnice libvdpau10.
5.4.2 Inicializácia zobrazovania snímkov vdpau Pre korektné zobrazovanie snímkov vdpau je najprv potrebné získať funkčné ukazovatele na funkcie knižnice libvdpau a OpenGL rozšíre- nia GL_NV_vdpau_interop. Toto rozšírenie je potrebné pred použitím inicializovať pomocou funkcie glVDPAUInitNV. Keďže knižnica libvdpau definuje len samotné aplikačné rozhra- nie a samotná implementácia je prenechaná na grafický ovládač, je nutné získať ukazovatele na jednotlivé funkcie za behu programu [12]. Na získanie ukazovateĺov na jednotlivé funkcie knižnice slúži fun- kcia VdpGetProcAddress. Táto funkcia je sprostredkovaná ako funkčný ukazovateľ, ktorý je vrátený pri vytváraní hardvérového kontextu. Vo svojej implementácii som na ukladanie týchto ukazovateľov vytvoril štruktúru vdp_funcs a funkciu vdp_funcs_load, ktorá do tejto štruk- túry získané ukazovatele zapíše. Podobný spôsobom je potrebné získať aj ukazovatele na OpenGL funkcie rozšírenia GL_NV_vdpau_interop. Pred samotným načítaním ukazovateľov je však potrebné zistiť, či je toto rozšírenie na danom počítači dostupné. Reťazec obsahujúci názvy všetkých dostupných roz- šírení je možné získať volaním funkcie glGetString(GL_EXTENSIONS). Samotné získavanie funkčných ukazovateľov prebieha pomocou fun- kcie glXGetProcAddressARB, ktorá ako argument berie reťazec obsa- hujúci názov danej funkcie.
7. http://download.nvidia.com/XFree86/vdpau/doxygen/html/group___ vdp_video_surface.html 8. http://download.nvidia.com/XFree86/vdpau/doxygen/html/group___ vdp_output_surface.html 9. http://download.nvidia.com/XFree86/vdpau/doxygen/html/group___ vdp_video_mixer.html 10. https://cgit.freedesktop.org/vdpau/libvdpau/
28 5. Implementácia akcelerácie s priamym zobrazovaním
Inicializácia video mixéru spomínaného v sekcii 5.4.1 prebieha v mojej implementácii vo funkcii initMixer po prijatí prvého snímku. Pri inicializácii VdpVideoMixer je možné vyžiadať voliteľné funkcie, alebo nastavovať rôzne parametre. Medzi povinné parametre patrí roz- mer vstupných snímkov typu VdpVideoSurface. Vo svojej implemen- tácii nastavujem aj formát pixelu. Tieto informácie sa zo snímku dajú zistiť pomocou funkcie VdpVideoSurfaceGetParameters. Parametre sa dajú nastaviť len pri inicializácii a musia byť dodržané. Vo funkcii initMixer inicializujem aj pomocný snímok VdpOutputSurface, do ktorého sú zapisované výsledné snímky z video mixéru.
5.4.3 Zobrazovanie VdpOutputSurface snímkov Spracovanie a zobrazovanie dekódovaných snímkov prebieha vo fun- kcii gl_render_vdpau. Táto funckia využíva video mixér na konverziu vstupných snímkov na výstupné, z ktorých napokon vytvára OpenGL textúry. Konvertovať vstupné snímky na Výstupné je možné pomocou fun- kcie VdpVideoMixerRender. Táto funkcia sa volá s celkom 14 vstup- nými parametrami. Väčšina týchto parametrov sa používa na pokroči- lejšie funkcie ako rôzne orezávania snímkov, alebo kompozícia viace- rých vrstiev. Moja implementácia tieto funkcie nevyužíva a väčšina vstupných parametrov je potom nastavená na hodnotu NULL. Rozšírenie GL_NV_vdpau_interop umožňuje pracovať s vdpau sním- kami ako s OpenGL textúrami. Snímky je nutné najprv pomocou funkcie glVDPAURegisterOutputSurfaceNV registrovať. Registrované snímky je potom možné prepojiť s OpenGL textúrou pomocou fun- kcie glVDPAUMapSurfaceNV. Napokon je potrebné snímok odpojiť a odregistrovať. Jednotlivé stavy a prechody medzi nimi sú popísané na obrázku 5.3 Výsledná textúra sa zvolí pomocou volania glBindTexture a je následne zobrazená pôvodným kódom displeja gl.
5.4.4 Typová chyba v špecifikácii GL_NV_vdpau_interop V špecifikácii OpenGL rozšírenia GL_NV_vdpau_interop sú chybne uvedené typy parametrov VdpDevice a VdpOutputSurface. V špecifi- kácii a aj v hlavičkových súboroch je typ týchto parametrov uvedený
29 5. Implementácia akcelerácie s priamym zobrazovaním
VDPAUUnregiserSurfaceNV / VDPAUFiniNV
VDPAURegisterSurfaceNV Unknown/Unregistered Registered
VDPAUUnmapSurfaceNV VDPAUMapSurfaceNV
Mapped VDPAUFiniNV
Obr. 5.3: Možné stavy vdpau snímkov a prechody medzi nimi. Prekres- lené z https://www.khronos.org/registry/OpenGL/extensions/ NV/NV_vdpau_interop.txt ako const void *, no implementácia v skutočnosti neočakáva ukazo- vateľ, ale hodnotu typu VdpDevice, alebo VdpOutputSurface. Z tohto dôvodu je potrebné tieto parametre pri volaní funkcií pretypovať. V svojej implementácii som pre tento účel vytvoril makro NV_CAST.
5.5 Záver
V tejto kapitole je opísaná implementácia hardvérovej akcelerácie de- kódovania videa pracujúca v režime bez kopírovania. Tento režim je dostupný na grafických kartách vyrábaných firmou NVIDIA. Tento režim ponúka oproti režimu akcelerácie s kopírovaním vyššiu efekti- vitu.
30 6 Meranie výkonu
Po dokončení implementácie som vykonal merania oneskorenia a výkonu tejto implementácie. Účelom týchto meraní bolo zistiť, či vý- sledná implementácia hardvérovej akcelerácie dekódovania má pozi- tívny vplyv na výkon a oneskorenie, alebo prípadné zistenie výkon- nostných problémov. Merania boli vykonané sledovaním časového sklzu medzi vstupným a výstupným videom, ako aj pomocou merania času, ktorý program trávi dekódovaním jednotlivých snímkov. Pri me- raní boli použité vstupné videá s rozlíšeniami 1920x1080 a 3840x2160 obrazových bodov, snímkovou frekvenciou 30 snímkov za sekundu a kódované pomocou štandardov H.264 a H.265. Do každého snímku bolo vypálené jeho poradové číslo.
6.1 Použité počítače
Na merania boli použíté počítače HD12, HD13 a HD14. Pre tieto me- rania sú relevantné parametre počítača HD13 na ktorom prebiehalo dekódovanie. V menšej miere mohli byť merania ovpyvnené aj počí- tačom HD12 na ktorom prebiehalo zobrazovanie a kódovanie videa. Toto kódovanie však prebiehalo pre rôzne metódy dekódovania rov- nako, takže na relatívne rozdiely medzi metódami dekódovania by nemali byť týmto počítačom ovplyvnené. Počítač HD14 slúžil len ako zdroj videa a preto tento počítač ne- mohol ovplyvniť výsledky merania. Jeho parametre preto nie sú pre túto prácu relevantné.
HD13
Operačný systém: Ubuntu 16.04.1 + CentOS 7
CPU: Intel○R CoreTM i7-6700K
Operačná pamäť: 32 GB 2133 MHz DDR4
GPU: NVIDIA GeForce GTX 960
31 6. Meranie výkonu
HD12
Operačný systém: Ubuntu 16.04
CPU: Intel○R CoreTM i7-4960X Operačná pamäť: 64 GB 1866 MHz DDR3 Playback/capture karta: DeckLink Extreme 4K Merania s použitím grafickej karty NVIDIA boli vykonané spo- mocou operačného systému Ubuntu a merania s použitím grafickej karty Intel boli vykonané s pomocou operačného systému CentOS.
6.2 Meranie oneskorenia
Pri meraní oneskorenia prebiehalo formou end-to-end. To znamená, že sa meralo oneskorenie od zaznamenania snímku, až po jeho zobra- zenie. Nameraná hodnota teda obsahuje oneskorenia, ktoré vznikli pri zaznamenaní snímku, jeho kódovaní, jeho prenose sieťou, dekódovaní a zobrazovaní. Meranie oneskorenia prebiehalo porovnávaním poradových čísel vstupných a výstupných snímkov. Na zobrazovanie týchto snímkov boli použité dva monitory rovnakého modelu, aby sa predišlo nepres- nostiam meranie spôsobené líšiacou sa odozvou pri zobrazovaní. Ako zdroj obrazu bol použitý počítač HD14, ktorý odosielal obraz po sieti počítaču HD12. Počítač HD12 tento obraz zobrazoval na prvom moni- tore pomocou video karty DeckLink Extreme 4K1. Obrazový výstup tejto karty bol touto kartou súčasne aj zaznamenávaný. Zaznamenaný obraz bol počítačom HD12 kódovaný pomocou práve testovaného štandardu a po sieti ďalej posielaný na počítač HD13. Na tomto počí- tači prebiehalo dekódovanie videa a jeho následné zobrazovanie. Toto zapojenie je znázornené na obrázku 6.1. Video zobrazované na dvoch použitých monitoroch bolo fotené zrkadlovkou s použitím času uzávierky 1/125 sekundy. Zo zazna- menanej fotografie bolo potom vďaka vypáleným poradovým číslam v obraze zistiť oneskorenie medzi týmito obrazmi v počte snímkov.
1. https://www.blackmagicdesign.com/products/decklink
32 6. Meranie výkonu
HD14 HD12 HD13 dekódovanie kódovanie
Decklink GPU
58 54
Obr. 6.1: Testovacia konfigurácia
Pri testovaní videa kódovaného štandardom H.265 sa vyskytlo niekoľko problémov. Na grafických kartách spoločnosti NVIDIA je akcelerácia dekódovania tohto štandardu v knižnici ffmpeg zakázaná, kôli chybám v NVIDIA ovládačoch2. Akcelerácia dekódovania H.265 na grafických kartách NVIDIA preto netestovala. Ďalším problémom je, že kódovanie videa týmto štandardom je príliš výpočtovo náročné a počítač HD12 nebol dostatočne výkonný na kódovanie videa v reálnom čase a to ani v rozlíšení 1920x1080. Dôsledkom tohto bol na kódovanie videa použitý hardvérový akce- lerátor grafickej karty NVIDIA. Video kódované týmto spôsobom nie je možné dekódovať paralelne, čo spôsobilo, že počítač HD13 ne- bol schopný takto kódované video v rozlíšení 3840x2160 obrazových bodov v reálnom čase dekódovať a preto nebolo možné zmerať one- skorenie softvérového dekódovania videa v tomto formáte. Pre každý testovaný formát videa a spôsob dekódovania bolo vy- fotených 10 až 15 snímkov. Z nameraných hodnôt bol vypočítaný priemer a smerodatná odchýlka. Namerané dáta sú v tabuľke 6.1. Z nameraných výsledkov je možné vidieť, že grafická karta NVIDIA ponúka oproti grafickej karte Intel rýchlejšiu odozvu. Ďalej sa dá všim-
2. https://patchwork.ffmpeg.org/patch/4172/
33 6. Meranie výkonu Tabuľka 6.1: Namerané hodnoty oneskorenia
Priemerné Smerodatná Formát videa Dekodér GPU oneskorenie odchýlka v snímkoch v snímkoch 1920x1080 30p H.264 SW NVIDIA 4.8 0.5 1920x1080 30p H.264 VDPAU NVIDIA 3.6 0.4 3840x2160 30p H.264 SW NVIDIA 6 0.5 3840x2160 30p H.264 VDPAU NVIDIA 4.7 0.4 1920x1080 30p H.264 SW Intel 6.9 0.2 1920x1080 30p H.264 VA API Intel 6.7 0.4 3840x2160 30p H.264 SW Intel 7 0 3840x2160 30p H.264 VA API Intel 7.9 0.3 1920x1080 30p H.265 SW Intel 7.0 0.1 1920x1080 30p H.265 VA API Intel 7.4 0.4 3840x2160 30p H.265 VA API Intel 8.2 0.5
núť, že akcelerácia bez kopírovania má na oneskorenie pozitívny vplyv. Akcelerácia na grafických kartách Intel má na oneskorenie mierne ne- gatívny dopad, čo môže byť spôsobené kopírovaním dekódovaných snímkov.
6.3 Meranie výkonu s využitím inštrumentácie
Meranie výkonu s využitím inštrumentácie spočíva v meraní času vykonávania určitých častí programu. Pre účely tohto merania som do kódu vložil volania funkcií clock_gettime3, s využitím hodín CLOCK_MONOTONIC_RAW, ktoré ponúkajú vyššiu presnosť a nie sú ovplyv- nené NTP synchronizáciou času. Touto funkciou som zaznamenal čas pred dekódovaním a po dekódovaní jednotlivých snímkov. Rozdiel
3. https://linux.die.net/man/3/clock_gettime
34 6. Meranie výkonu
týchto hodnôt je čas potrebný na dekódovanie jedného snímku. Toto meranie obsahuje aj čas strávený prenosom snímku z pamäte akcele- rátora do pamäte počítača v prípade využitia Intel akcelerátora. Na zmeranie výkonu dekódovania videa v rozlíšení 3840x2160 a štandarde H.265 som využil video, ktoré bolo do tohto formátu v predstihu predkonvertované. Z nameraných výsledkov som vypočí- tal priemer a smerodatnú odchýlku. Výsledky sú k dispozícii v tabuľke 6.2. Z nameraných výsledkov je možné vidieť, že dekódovanie sním- kov pomocou NVIDIA akcelerátora je značne rýchlejšie a v čase na dekódovanie sa vyskytujú len veľmi malé odchýlky. Pri využití Intel akcelerátora trvá dekódovanie snímkou dlhšie ako pri softvérovom dekódovaní s výnimkou videa kódovaného štandardom H.265 v rozlí- šení 3840x2160 obrazových bodov. Na druhú stranu sa však v čase na dekódovanie vyskytujú menšie odchýlky. Prekvapivým výsledkom je rozdiel v čase dekódovania snímkov videa v rozlíšení 3840x2160 obrazových bodov s použitím softvérového dekódovania medzi mera- niami s použitím NVIDIA a Intel grafických kárt. Tento rozdiel mohol vzniknúť kôli použitiu rozdielnych operačných systémov.
6.4 Meranie záťaže procesora
Na meranie záťaže procesora som využil nástroj time4. Výstupom tohto nástroja je trojica časov:
real reálny čas, ktorý ubehol počas behu procesu
user čas strávený vykonávaním inštrukcií tohto procesu
system čas strávený jedným jadrom procesoru vykonávaním inštrukcií systémových funkcií vyvolaných týmto procesom.
4. https://linux.die.net/man/1/time
35 6. Meranie výkonu Tabuľka 6.2: Namerané hodnoty výkonu s využitím inštrumentácie
Priemerný Smerodatná Formát videa Dekodér GPU čas odchýlka dekódovania [ms] snímku [ms] 1920x1080 30p H.264 SW NVIDIA 4.4 0.6 1920x1080 30p H.264 VDPAU NVIDIA 0.2 0.04 3840x2160 30p H.264 SW NVIDIA 12.5 5.4 3840x2160 30p H.264 VDPAU NVIDIA 0.6 0.3 1920x1080 30p H.264 SW Intel 4.6 0.9 1920x1080 30p H.264 VA API Intel 10.5 0.2 3840x2160 30p H.264 SW Intel 9.6 4.5 3840x2160 30p H.264 VA API Intel 17.0 1.8 1920x1080 30p H.265 SW Intel 14.5 3.2 1920x1080 30p H.265 VA API Intel 11.2 0.7 3840x2160 30p H.265 SW Intel 25.6 11.2 3840x2160 30p H.265 VA API Intel 14.7 1.4
Tieto časy sú súčtom pre všetky jadrá procesoru. To znamená, že ak dve jadrá súčasne pracujú na plný výkon po dobu jednej mi- núty, bude výsledkom hodnota 2 minúty. Percentuálne zaťaženie procesoru meraným procesom je možné vypočítať pomocou vzorca (user + system)/real * 100. Výsledok je percentuálne zaťaženie jed- ného jadra procesoru – to znamená, že pre 2 plne zaťažené jadrá je výsledok 200%. Dekódovanie bolo merané po dobu približne 2 minúty. Výsledkom je priemerné zaťaženie procesoru počas celej doby merania. Name- rané výsledky je možné vidieť v tabuľke 6.3. Na zmeranie výkonu dekódovania videa v rozlíšení 3840x2160 a štandarde H.265 bolo opäť využité predkonvertované video. Z nameraných výsledkov je možné vidieť, že na záťaž procesoru má najpriazniveˇȷší vplyv akcelerácia bez
36 6. Meranie výkonu
kopírovania na akcelerátoroch firmy NVIDIA. Použitie akcelerátorov firmy Intel má na záťaž procesoru tiež pozitývny vplyv. Pri týchto akcelerátoroch je záťaž procesoru závislá najmä na rozlíšení videa a teda veľkosti dekódovaných snímkov. Táto záťaž je pravdepodobne spôsobená kopírovaním týchto snímkov.
Tabuľka 6.3: Namerané hodnoty záťaže procesoru
Priemerná Formát videa Dekodér GPU záťaž procesoru 1920x1080 30p H.264 SW NVIDIA 70.3% 1920x1080 30p H.264 VDPAU NVIDIA 9.3% 3840x2160 30p H.264 SW NVIDIA 195.7% 3840x2160 30p H.264 VDPAU NVIDIA 19.8% 1920x1080 30p H.264 SW Intel 75.3% 1920x1080 30p H.264 VA API Intel 40.1% 3840x2160 30p H.264 SW Intel 161.0% 3840x2160 30p H.264 VA API Intel 62.0% 1920x1080 30p H.265 SW Intel 57.1% 1920x1080 30p H.265 VA API Intel 41.2% 3840x2160 30p H.265 SW Intel 410.0% 3840x2160 30p H.265 VA API Intel 53.9%
6.5 Zhrnutie
Táto kapitola obsahuje popis a výsledky merania oneskorenia a vý- konu výslednej implementácie hardvérovej akcelerácie dekódovania videa. Výsledky meraní oneskorenia ukázali, že použitie hardvérovej ak- celerácie v režime kopírovania môže v niektorých prípadoch spôsobiť
37 6. Meranie výkonu mierne oneskorenie. Použitie akcelerácie bez kopírovania malo na oneskorenie priaznivý efekt. Z hľadiska výkonu je hardvérová akcelerácia priaznivá hlavne pri dekódovaní videa kódovaného štandardom H.265, ktorého dekódo- vanie je výpočtovo náročné. Počas testovania sa podarilo pomocou hardvérovej akcelerácie dekódovať aj video, ktoré na použitom hard- véri nebolo možné dekódovať softvérovo v reálnom čase. Z hľadiska záťaže procesoru bola hardvérová akcelerácia priaznivá vo všetkých testovaných prípadoch, najmä však pri použití akcelerácie bez kopíro- vania na grafických kartách NVIDIA.
38 7 Záver
Cieľom tejto práce bola implementácia hardvérového dekódovania videa pre nástroj UltraGrid. Táto implementácia bola zameraná na hardvérové akcelerátory vyrábané firmami Intel a NVIDIA. Vzhľadom k využitiu aplikačných rozhraní VA API a VDPAU je pravdepodobné, že výsledná implementácia pracuje aj s akcelerátormi iných výrobcov, ktorí tieto rozhrania implementujú. Toto je už však mimo rozsah tejto práce a nebolo testované. Výsledná implementácia môže pracovať v dvoch režimoch. Režim využívajúci kopírovanie dekódovaných snímkov je dostupný na všet- kých podporovaných akcelerátoroch. Na akcelerátoroch firmy NVIDIA je naviac podporovaný režim, v ktorom ku kopírovaniu nedochádza a výsledné snímky sa zobrazujú priamo z pamäte hardvérového akce- lerátora. Po dokončení implementácia prebehli merania jej výkonu ako aj oneskorenia, ktoré je touto akceleráciou vnesené do nástroja UltraGrid. Meranie výkonu a oneskorenia ukázalo, že pomocou hardvérovej akcelerácie je možné dekódovať na mnohých prenosných počítačoch video vo vyššom rozlíšení a vo vyššom počte snímkov za sekundu, ako by bolo možné s využitím softvérového dekódovania, a to bez značného nárastu oneskorenia. Výsledná implementácia ponúka priestor pre ďalšie rozšírenie. V režime zobrazovania dekódovaných snímkov bez ich kopírovania na akcelerátoroch firmy NVIDIA nie je možné použiť existujúce post- process filtre a pre prácu v tomto režime by museli byť reimplemen- tované. Ďalším možným pokračovaním tejto práce by mohla byť im- plementácia režimu zobrazovania bez kopírovania pre akcelerátory firmy Intel.
39
Bibliografia
1. LIŠKA, Miloš. Přenos obrazu v kvalitě 8K pomocí PC [on- line]. CESNET, 2016 [cit. 2017-11-18]. Dostupné z: https : //www.cesnet.cz/2016/07/prenos-obrazu-v-kvalite-8k- pomoci-pc/. 2. HWAccelIntro [online]. FFmpeg Bug Tracker and Wiki, 2017 [cit. 2017-11-18]. Dostupné z: https : / / trac . ffmpeg . org / wiki / HWAccelIntro. 3. NV_vdpau_interop [online]. The Khronos Group, 2014 [cit. 2017- 12-17]. Dostupné z: https : / / www . khronos . org / registry / OpenGL/extensions/NV/NV_vdpau_interop.txt. 4. LIVINGSTONE, Margaret. Vision and art : the biology of seeing. New York, N.Y: Harry N. Abrams, 2002. ISBN 0810904063. 5. Global Media Format Report 2018 [online]. 2018 [cit. 2018-04-28]. Dostupné z: https://www.encoding.com/files/2018-Global- Media-Formats-Report.pdf. 6. GARY J. SULLIVAN Pankaj Topiwala, Ajay Luthra. The H.264/AVC Advanced Video Coding Standard: Overview and Intro- duction to the Fidelity Range Extensions [online]. 2004 [cit. 2018- 04-28]. Dostupné z: http://www.fastvdo.com/spie04/spie04- h264OverviewPaper.pdf. 7. NVIDIA VIDEO DECODER (NVDEC) INTERFACE [on- line]. NVIDIA, 2016 [cit. 2018-04-28]. Dostupné z: https : //developer.nvidia.com/nvdec-programming-guide. 8. Hardware/QuickSync [online]. FFmpeg Bug Tracker and Wiki, 2017 [cit. 2018-04-20]. Dostupné z: https://trac.ffmpeg.org/ wiki/HWAccelIntro. 9. THOMPSON, Mark. [FFmpeg-user] VAAPI Decoding/Encoding with C code. 2016. Dostupné tiež z: https : / / ffmpeg . org / pipermail/ffmpeg-user/2016-December/034534.html. 10. FFmpeg Documentation [online]. 2017 [cit. 2018-11-18]. Dostupné z: https://ffmpeg.org/doxygen/3.4/pixfmt_8h.html.
41 BIBLIOGRAFIA
11. VdpVideoSurface; Video Surface object. 2015. Dostupné tiež z: http: / / download . nvidia . com / XFree86 / vdpau / doxygen / html / group___vdp_video_surface.html. 12. Video Decode and Presentation API for Unix. 2015. Dostupné tiež z: http://download.nvidia.com/XFree86/vdpau/doxygen/html/ index.html.
42 A Elektronická príloha
Súčasťou práce je aj elektronická príloha dostupná v elektronickom ar- chíve práce. Tento archív obsahuje zdrojový kód programu UltraGrid a dokument obsahujúci hodnoty namerané v kapitole 6.
43