hledat:

9   Multimediální přenosy a kolaborativní prostředí

Aktivita Multimediální přenosy a kolaborativní prostředí se zabývá vývojem a diseminací znalostí o kolaborativních prostředích, pro jejichž implementaci lze efektivně využít vysokorychlostní síťovou infrastrukturu, jak je realizována například sítí CESNET2. V roce 2008 došlo k další integraci původních aktivit Virtuální prostředí pro spolupráci a IP telefonie. Původní skupiny komunikují a jejich členové spolupracují jak při výzkumu, tak při formulování výzkumných cílů do budoucna. Aktivita zahrnuje velmi širokou paletu činností od produkčních služeb nad sítí CESNET2, jako jsou například provoz IP telefonie či audio a video streamovací služby, přes aktivity hraniční, kam lze zařadit například indexaci a vyhledávání v multimediálních datech a kolaborativní platformu založenou na nekomprimovaném HD videu, až po čistě výzkumné úkoly, mezi něž patří například virtualizovaná synchronní komunikační infrastruktura, analytický model rozptylu zpoždění pro obsluhu RTP toků či psychologická studie, která připravuje půdu pro vývoj nové generace vícebodových kolaborativních prostředí. I v letošním roce se aktivita podílela na řadě demonstrací technologií, u kterých se podílí na vývoji i takových, které sice nevyvíjíme, ale jsou to pokročilé technologie založené na využití vysokorychlostních sítí.

9.1   DiProNN

V první polovině roku 2008 jsme se v rámci integrace systému pro správu a řízení zdrojů prvku DiProNN zaměřili na testování vhodných plánovacích algoritmů dostupných v jeho aktuální prototypové implementaci, využívající virtualizační systém XEN 3.1. Analyzovali jsme zejména algoritmy přidělování procesorového času (SEDF - Simple Earliest Deadline First, Credit Scheduler) a jejich vliv na obsluhu síťových toků procházejících prvkem. Do prototypové implementace prvku DiProNN jsme rovněž začlenili možnosti limitace procházejících síťových toků, pro které jsme využili standardní nástroj Linuxových systémů Traffic Control (tc).

Ve druhé polovině roku jsme pro vyvíjený prvek navrhli a detailně popsali kompletní systém správy jeho zdrojů, a to jak softwarových (aktivní programy, virtuální stroje, speciální funkce), tak hardwarových (CPU, paměť, síťový a diskový subsystém). Navržený systém sestává ze tří podčástí - procesu zjišťování dostupných zdrojů na všech jednotkách prvku DiProNN, procesu specifikace uživatelem požadovaných zdrojů a procesu vlastní alokace požadovaných zdrojů:

• Pro proces zjišťování dostupných zdrojů jsme využili monitorovací systém Ganglia - pro monitorování HW zdrojů jsme využili moduly (tzv. "agenty") v Ganglii přímo obsažené, pro monitorování SW zdrojů jsme monitorovacího démona (gmond) obohatili o dynamicky zaveditelného agenta (VMAPmon_module), který na každé výpočetní jednotce periodicky komunikuje se zde běžícími virtuálními stroji a sbírá informace o dostupných softwarových zdrojích.
• Pro specifikaci uživatelem požadovaných zdrojů jsme navrhli jednoduché rozšíření programu DiProNN detailně popsané v [Reb08], díky kterému si může uživatel precizně zvolit zdroje požadované jeho aplikací.
• Vlastní alokace požadovaných zdrojů je provedena s využitím nástrojů dostupných ve standardních Linuxových systémech a systému XEN 3.1 - pro alokaci procesorového času jsme využili plánovač Credit Scheduler pracující v tzv. work consuming režimu, pro alokaci dostupné operační paměti a diskového prostoru jsme využili relevantní parametry konfiguračních souborů jednotlivých virtuálních strojů, a pro alokaci síťových toků jsme využili již zmíněný nástroj Traffic Control (tc).

Navržený systém správy a řízení zdrojů jsme (včetně analýzy algoritmů přidělování procesorového času a jejich vlivu na obsluhu síťových toků) prezentovali v článku nazvaném DiProNN Resource Management System, publikovaném na konferenci MEMICS'08.

9.2   Rozvoj platformy UltraGrid

V oblasti nízkolatenčních HD přenosů jsme se soustředili na rozvoj platformy UltraGrid a podporu jejího nasazení pro různé aplikace. Byla dokončena portace na operační systém MacOS X, kde je nyní plně podporován nejen záznam videa (jakožto kritická komponta implementováno v loňském roce, kvůli dostupnosti grabovacích karet), ale nyní také příjem a zobrazování. Zobrazování je možné jak softwarově obdobně jako v Linuxu, tak i hardwarově pomocí HD-SDI karet s podporou přehrávání (testováno s kartami AJA Kona3 a BlackMagic Design Multibridge). Hardwarové zobrazování po HD-SDI umožňuje využít UltraGrid v aplikacích náročných na přesnost zobrazování barevného prostoru, neboť lze zobrazovat kompletních 10 bitů barevné informace přenášené rozhraním HD-SDI.

UltraGrid byl také rozšířen o zobrazování pomocí SAGE [SAGE06], škálovatelného middleware pro zobrazování na dělených displejích. UltraGrid v tomto režimu předává zobrazovaná data knihovně libSAIL, která rozesílá obrazovou informaci na uzly zobrazovacího clusteru na základě informace o pozici oken od ovládací komponenty fsManager. Systém pak může fungovat v jednom ze dvou režimů:

• síťový přenos zajišťuje UltraGrid, přičemž přijímač typicky běží přímo na vizualizačním clusteru SAGE, nebo
• odesílací strana UltraGridu funguje současně i jako zobrazovač, takže data jsou po síti přenášena přímo pomocí knihovny libSAIL.

Zatímco první režim je vhodný zejména pro malé zobrazovací systémy obsluhované jedním počítačem (typicky 4K displej, kterému data dodává jediný počítač se dvěma grafickými kartami o dvou výstupech), druhý režim je vhodný pro zobrazování na velkých stěnách dělených displejů, jejichž řízení zajišťují clustery vizualizačních počítačů. SAGE podpora v UltraGridu byla doplněna také o jednoduchý přenos audia s využitím knihovny libSAIL. UltraGrid s podporou SAGE byl mimo jiné využit při demonstraci na prestižní konferenci SuperComputing 08, kde jsme se v rámci týmu vedeného Electronic Visualization Lab z UIC účastnili Bandwidth Challenge a dostali se až do jejího finále (obrázek).

Do vývojové větve platformy UltraGrid jsme také integrovali podporu kompatibility se systémem iHDTV, která byla implementována v roce 2008 v rámci studentského projektu na Fakultě informatiky Masarykovy univerzity. Vzhledem k tomu, že tento režim kompatibility nyní podporuje i iVisto, plně hardwarový systém pro přenos HD-SDI po IP sítích od NTT, všechny tři konkurenční systémy pro přenos HD-SDI (UltraGrid, iHDTV, iVisto) mohou nyní spolupracovat na úrovni formátu síťového přenosu.

V jarním semestru 2008 byla platforma UltraGrid opět produkčně nasazena pro výuku distribuovaného kurzu Introduction to High-Performace Computing vyučovaného prof. Thomasem Sterlingem z Louisiana State University.

9.2.1   Podpora 2K videa v UltraGridu

V rámci spolupráce s filmovým průmyslem, konkrétně s postprodukční společností CinePost, jsme implementovali do platformy UltraGrid podporu přenosu 2K videa v režimu 24 fps 4.2:2 v barevné hloubce 10 bitů. Výsledný datový tok v síti je 1,2 Gb/s. Vzhledem k použití v oblasti barevných korekcí bylo kritické dodržení 10bitové barevné hloubky od snímání videa až po jeho zobrazování. Proto bylo využito hardwarové zobrazování přes HD-SDI rozhraní karty AJA Kona3, jak je patrné ze schematu na obrázku.

Implementovaný systém byl v praxi úspěšně nasazen pro provádění barevných korekcí v reálném čase a umožňuje oddělení samotného systému pro barevné korekce BaseLight od kontrolního náhledu, čehož lze využít například pro schvalování postprodukčních úprav producenty filmu. Výsledek byl prezentován mimo jiné také na specializovaném workshopu CineGrid [Hol08] v La Jolla, CA, věnovanému spolupráci mezi filmovým průmyslem, výzkumnými institucemi a vysokorychlostními sítěmi.

9.2.2   Demonstrace použití platformy UltraGrid s okruhy Internet2 DCN a AutoBAHN

V rámci spolupráce s partnerskými organizacemi Internet2 a LSU byla dohodnuta demonstrace na Internet2 Fall Member Meeting 2008, v jejímž rámci byl UltraGrid využit nad řiditelnými okruhy Internet2 DCN a AutoBAHN pro propojení LSU v Baton Rouge, Masarykovy univerzity v Brně a New Orleans, kde se meeting konal. Vzhledem k omezením okruhů do hotelu v New Orleans na Gigabitový Ethernet bylo využito komprimovaného přenosu videa ve formátu DXT. Síťové zapojení demonstrace je patrné z obrázku.

V rámci ukázky pak byly ručně vyvolány alokace a vytvoření potřebných okruhů, což trvalo cca 1 minutu, a následně bezprostředně začaly vysílat apliakce UltraGrid a RAT ze všech zúčastněných míst. Auditorium mělo možnost vidět ustavování okruhů díky vizualizaci sítě v reálném čase. V rámci samotné prezentace pak prof. Sterling přednesl přednášku o kurzu Introduction to High-Performance Computing a studenti z Laboratoře pokročilých síťových technologií (SITOLA), kteří kurzem prošli, prezentovali své zkušenosti s tímto kurzem.

O demonstraci, jež zaznamenala široký mezinárodní ohlas, vydalo sdružení Internet2 obsáhlou tiskovou zprávu. V průběhu roku 2009 plánujeme na tyto aktivity navázat implementací Internet2 DCN API do systému CoUniverse pro řízení kolaborativních aplikací jako je UltraGrid tak, aby bylo možné okruhy vytvářet programově na základě požadavku koncového uživatele v okamžiku, kdy je aplikace bezprostředně využijí. Systém řízení okruhů Internet2 DCN spolu s linkou CESNETu do StarLightu bude využit v produkčním nasazení během jarního semestru 2009 k přenosu dalšího ročníku kurzu prof. Sterlinga.

9.2.3   Obslužný model RTP toků se dvěma prioritními frontami

V minulém roce jsme vytvořili model rozptylu zpoždění pro obsluhu RTP paketů ve směrovači. V letošním roce jsme tuto práci rozšířili a navrhli jsme obslužný model M/D/2 (dle Kendallova značení) umožňující dosáhnout snížení střední doby obsluhy u obslužné fronty s vyšší prioritou. V nižší prioritní frontě je střední doba obsluhy naopak zvýšena.

Na obrázku je klasický příklad klasifikace datagramů na vstupním rozhraní směrovače a jejich řazení do font, které jsou obsluhovány s rozdílnou prioritou. U nově navrženého modelu jsme analyticky stanovili střední dobu obsluhy, a to jak střední dobu setrvání požadavku ve frontě s vyšší prioritou, tak i s nižší prioritou. Použitý matematický aparát a vyjádření parametrů našeho modelu jsou uvedeny v technické zprávě [HrV08]. Podmínky platnosti modelu byly opět založeny na předpokladu, že pravděpodobnost vzniku volání má Poissonovo rozložení. Oproti původním podmínkám, které jsme publikovali v minulém roce, jsme definovali pro M/D/2 další dvě podmínky: nedochází k přerušení obsluhy datagramů, pokud bylo započato jejich odesílání ze směrovače (model tedy neplatí při použití techniky LFI - Link Fragmentation and Interleaving), datagramy ve vyšší prioritní frontě jsou obsluhovány přednostně před datagramy v nižší prioritní frontě. Vztah mezi střední dobou obsluhy ve vyšší a nižší prioritní frontě a počtem hovorů je uveden na obrázku.

Získané matematické modely pro stanovení end-to-end zpoždění jsme experimentálně ověřili a popsali v technické zprávě [HrV08]. V experimentu jsme generovali celkově sto spojení s různou hodnotou ToS, RTP toky jednotlivých hovorů přicházely na rozhraní směrovače postaveného na platformě PC s OS Linux a pomocí nástroje Traffic Control jsme docílili rozdílnou obsluhu toků. Měřili jsme end-to-end zpoždění a získané výsledky jsme porovnali s hodnotami vypočtenými vytvořeným modelem. V experimentu jsme využívali produkty IxLoad a IXChariot, pomocí kterých jsme generovali RTP toky a měřili end-to-end zpoždění, přičemž jsme pozorovali evidentně rozdílné chování v obou frontách. Do 75 % změřeného síťového zatížení byla maximální odchylka modelu od reálně změřených hodnot do 3 %, pro vyšší zatížení se značně zhoršovala reprodukovatelnost testů a rovněž jsme pozorovali závislost na zatížení procesoru směrovače, proto jsme další výsledky nepublikovali. Při experimentálních ověřeních jsme zjistili, že do modelu vstupuje další typ zpoždění závislý na vytížení procesoru směrovače, který jsme nezahrnuli do výpočtů, má značnou variabilitu a jeho exaktní vyjádření je problematické. Praktickým přínosem navrženého obslužného modelu je optimalizace rozložení rozptylu zpoždění při obsluze RTP datagramů ve směrovači s frontami s různou prioritou. Vytvořený matematický model umožňuje teoreticky stanovit dobu obsluhy u sledovaného obslužného prvku v závislosti na parametrech sítě a síťového provozu, což je potřebný krok ke zdokonalení predikce kvality VoIP hovoru.

9.2.4   Vliv zabezpečení síťové infrastruktury na kvalitu hovoru

Dosud jsme se věnovali zabezpečení IP telefonie z hlediska efektivity a robustnosti, popisovali jsme autentizaci v protokolu SIP, šifrování médií s použitím SRTP nebo vlastní signalizace protokolem SIPS. V letošním roce jsme se zaměřili na výzkum vlivu síťového zabezpečení na kvalitu hovoru. Většina připojení vysunutých pracovišť a VoIP klientů je realizována prostřednictvím zabezpečených spojů - IPsec nebo TLS. Již v předešlém roce byla publikována práce [NBR07] prokazující, že může dojít k ovlivnění celkové kvality hovoru vyjádřené pomocí MOS (Mean Opinion Score) nebo R-faktoru. Jelikož byl výzkum v oblasti přenosu hlasu po IPsec již proveden na univerzitě v Miláně [BBR02], zaměřili jsme se na TLS.

Společně s kolegy z Milána jsme provedli řadu experimentů, ve kterých jsme přinesli nejen praktické výsledky popisující, jak může použití TLS ovlivnit celkovou kvalitu hovoru, ale i matematický aparát pro výpočet odhadované kvality hovoru v zabezpečeném prostředí. Využili jsme open-source řešení OpenVPN. Po provedení simulace spojení v NS-2 a emulace pomocí nástroje SIPp ve VPN tunelu sestaveném mezi univerzitami VŠB-TU v Ostravě a UNIMI v Miláně jsme konstatovali, že vliv na kvalitu hovoru se projevuje pouze při přiblížení mezním limitům kapacity šifrovaného tunelu.

Jedním z důvodů ovlivnění je využití blokového schématu šifrování CBC, kde šifrovaný výstup z jednoho bloku je vstupem na další blok. Velikost bloků závisí na použitém typu šifry, v našem případě jsme srovnávali AES, DES, 3DES a BlowFish. Výsledky měření s výpočtem odhadované kvality hovoru jsme publikovali [VRN08].

V další části výzkumu jsme se zaměřili na výpočet nároků VoIP spojení na pásmo v prostředí TLS. Odvodili jsme rovnice pro výpočet pásma, které je vyžadováno pro vybraný počet současných spojení za předpokladu použití stejných kodeků. Průběh závislosti využitého pásma na počtu hovorů a velikosti zátěže je zobrazen v grafu. Protokol TLS nelze exaktně umístit do aplikační ani do transportní vrstvy, leží totiž mezi nimi. Pro přenos využívá transportní protokol TCP a je závislý na aplikační vrstvě. Existuje sice už i varianta TLS nad UDP označovaná jako DTLS, ale v praxi se téměř výhradně používá TLS nad TCP a v OpenVPN dosud varianta DTLS není implementována. Do výpočtu jsme zahrnuli velikost bloku šifry, která je závislá na použitém algoritmu šifrování. Platnost našich výpočtů jsme úspěšně ověřili a metodu publikovali v [Voz08a]. Graf obsahuje porovnání nároků na pásmo pro tři různé situace: v síti bez zabezpečení, se zabezpečením TLS a v OpenVPN.

Další část naší práce byla zaměřena na výpočet R-faktoru, který je výstupem E-modelu definovaného v doporučení ITU-T G.107. E-model slouží k výpočtu odhadované kvality hovoru. Jelikož s použitím TLS narůstají nároky na pásmo, dochází pochopitelně k saturaci dostupného přenosového kanálu dříve než bez TLS, což je provázeno ztrátami paketů. Ztrátovost se může modelovat například pomocí Markovovských procesů [Cla01].

Teorie v této oblasti jsou založeny na pravděpodobnostních modelech, a jelikož se jedná o téma dosti náročné, rozhodli jsme se aplikovat doporučení ITU-T G.113, ve kterém je popsán výpočet ztrátovosti jako parametru Ie-ef a počítá i s odolností konkrétního kodeku vůči ztrátám. Faktor Ie-ef byl zahrnut do E-modelu v revizi doporučení ITU-T G.107 z roku 2005, což byl jasný důvod, proč jsme se vydali touto cestou. Dále jsme využili zjednodušení v E-modelu a použili implicitní hodnoty pro parametry, u nichž to bylo možné. Popis způsobu výpočtu R-faktoru a jednotlivých parametrů včetně zmíněného faktoru Ie-ef jsme publikovali v technické zprávě [Voz08b].

Pro ilustraci několik údajů: Pokud použijeme kodek G.711 s paketizací 20 ms, pak bez TLS potřebujeme na jeden hovor 90,4 kbit/s, zatímco OpenVPN s TLS a šifrováním AES vyžaduje 130 kbit/s. Pro G.729 je rozdíl ještě markantnější, přenos bez TLS pro G.729 s paketizací 20 ms potřebuje 34,4 kbit/s, v OpenVPN s TLS a AES jeden hovor vyžaduje 72,4 kbit/s. Pomocí vztahů, které jsme publikovali, lze vypočíst nejen nároky na pásmo, ale i odhadovanou kvalitu hovoru.

Na závěr je nutné zdůraznit, že vliv zabezpečení sítě na kvalitu hovoru se může uplatnit tehdy, pokud síťové prostředky nemohou uspokojit požadavky na přenos datagramů generovaných zdroji RTP a dochází ke ztrátám. Kodeky jsou proti ztrátám různě odolné - zatímco ztrátovost 3 % má pro G.711 bez PLC (Packet Loss Concealment) fatální následky na srozumitelnost, u iLBC je v hovoru stěží postřehnutelná. Zlepšení by se dalo dosáhnout optimalizací časování paketizace, aby blok šifry byl násobkem velikosti protokolové datové jednotky, což skýtá další potenciál výzkumu v této oblasti.

9.2.5   Signalizační infrastruktury na H.323 a SIP a jejich služby

Základem pro služby poskytované výzkumné a vzdělávací komunitě i náš vlastní výzkum v oblasti IP telefonie a videokonferencí je signalizační infrastruktura. Pokračovali jsme v rozvoji služeb poskytovaných nejen sestavou gatekeeperů, řídících prvků H.323 infrastruktury, jakými je například zapojení do GDS infrastruktury. GDS umožňuje propojení pro spolupráci nad výzkumnými a vzdělávacími projekty napříč celým světem.

Naše účast se neomezuje na pouhé propojovací služby, ale poskytujeme i prostředky pro vícebodové konference - MCU. Pro zjednodušení práce s MCU jsme nasadili rezervační portál pro SD videokonference na MCU Polycom vyvinutý kolegy ze švýcarské NREN. Dále jsme otestovali fungování HD MCU Codian na několika akcích. Po dobrých výsledcích z provozních akcí (Live Surgery, FUSENET meeting) jsme přistoupili k povýšení systému, aby kapacitně pokrýval nároky uživatelů sítě. HD MCU Codian je schopno obsloužit nejen HD videokonferenční jednotky, využívající přenos obrazu v rozlišení prozatím 1280×720, ale také znatelně povýšit kvalitu obrazu posílaného z SD videokonferenčních jednotek, tedy celkově zlepšit kvalitu předávaného obrazu i při použití starších zařízení u některých účastníků. Multidoménový SIP server, fungující jako předváděcí a testovací prostředí, nadále poskytuje služby několika doménám a vyjednáváme s dalšími zájemci a snažíme se jim doporučit nejvhodnější postup. Poskytujeme individuální pomoc i dalším institucím, které nás osloví, například v otázkách renovace jejich telefonního systému a možnosti připojení do IP telefonie (JAMU, FTVS UK, ústavy AV ČR).

Pokrok v modelových nasazeních a rozvoj aplikací jsme prezentovali na semináři aktivity. Jendou z nich je například autokonfigurační systém pro hardwarové IP telefony popsaný v technické zprávě [Pet08]. Plánovaný přechod na SIP na páteř jsme se rozhodli provádět systémem postupných kroků kvůli nutnosti nepřerušeného fungování služeb a distribuovanému řešení problémů. Příchozí a odchozí hovory jsou funkční na SIPu na ZČU, JČU a OSU. Všechny instituce jsou schopny SIP hovory přijímat. Ani po ukončení přechodu však H.323 infrastruktura nezanikne, protože je hojně používána ve videokonferencích.

Mezinárodní spolupráce

Řešitelé aktivity jsou aktivní i v zahraničních projektech a odborných skupinách. Jednou z těchto skupin byla TERENA TF-ECS, která oficiálně letos na podzim ukončila svou činnost a její práce byla kladně hodnocena. V současnosti diskutujeme o možnosti vzniku nové skupiny či pokračování některých oblastí v rámci dalších skupin (TF-EMC2, TF-Mobility). Dokument a obraz systému (VMware) vznikající v rámci této skupiny bude ke stažení po editorské kontrole (TERENA). Systém je především zaměřen na testování a seznámení se s aplikacemi na institucích a jako první krok pro jejich následné nasazení do provozu. V rámci projektu GN2 SA6 spolupracujeme na systému monitoringu a informačních služeb především pro GDS infrastrukturu (H.323 videokonference). V CESNETu je nainstalována monitorovací sonda realizující aktivní testy mezi (zatím) šesti evropskými partnery.

Bezpečnost

Nedílnou součástí našeho výzkumu je i zájem o bezpečnostní aspekty. Kromě již zmíněného výzkumu vlivu zabezpečení na kvalitu pokračujeme v testech s TLS v signalizačním serveru, které jsou zohledněny v doporučení - kuchařce vytvořené v rámci TERENA TF-ECS. Dále jsme se zabývali různými útoky na IP telefonní infrastrukturu a nástinem možných řešení. Jde například o útoky typu DoS na několika úrovních od jednoduchých záplav až po cílené vyčerpávání omezených prostředků. Věnovali jsme se i praktické simulaci útoků pomocí nástroje Scapy. Specifikem útoku na IP telefonii je omezená možnost odložit požadavky do front k následné analýze a náročnost analýzy hlasových dat. Jedním z nejsilnějších obranných prvků proto bude v budoucnosti silná důvěryhodná identita. Poznatky jsme publikovali na konferencích.

Podpora a akce

Poskytujeme individuální konzultace pro členy sdružení v oblasti videokonferenčních a prezentačních technologií (projekty Fondu rozvoje, AVU, AVČR, NTK, ČVUT, MU) a napomáháme při testech a zprovozňování realizovaných pracovišť. Předáváme tak své poznatky a zkušenosti dále do praxe. Kromě klasických videokonferenčních řešení jsme se věnovali návrhu a realizaci dvou DVTS pracovišť pro trvalou plně duplexní nízkolatenční AV komunikaci mezi pracovišti v ÚVN a MNUL. Tyto sady jsou vhodné pro přenos například obrazu z operace mezi pracovišti s vyšší kvalitou než poskytují klasické videokonference při využití výrazně většího datového pásma. Dostatek přenosové kapacity je však jednou ze základních výhod sítě CESNET2. Tyto sady jsou omezeny na přenos SD signálu, který zatím převládá v přístrojové technice, jíž jsou vybaveny spolupracující nemocnice. HD rozlišení se však rozšiřuje i do této oblasti, proto jsme připravili realizaci mobilních teleprezenčních pracovišť s podporou přenosu nízkolatenčního HD videa na platformě MAKO-HD.

V uplynulém roce jsme realizovali či podpořili například následující akce:

• Ve spolupráci s CNC jsme zajišťovali HD videokonferenční přenos Live Surgery 2008 (spojení sálů FN Ostrava, FN Hradec Králové, FN Brno Bohunice, ÚVN a auly ÚVN).
• ÚVN Instrumentaria 23G - HD videokonference a streaming vybraných oftalmologických operací mezi KU Leuven a UVN Praha.
• Příprava a realizace demonstrace vícebodové videkonference pomocí technologie DVTS na konferenci CESNET 2008 - DVTS Videoconferencing with Quatre. Akce se zúčastnilo sedm pracovišť z celého světa, z toho tři v České republice v naší režii.
• Podpora konference CESNET 2008, streaming, podpora vícebodových videokonferenčních akcí pro konference a semináře (FUSENET, D0 Collaboration Workshop 2008, atd.)

Závěrem roku jsme uspořádali úspěšný celodenní seminář s účastí téměř sedmdesáti posluchačů.

9.3   Bod přítomnosti CineGrid

V uplynulém roce jsme vybudovali distribuovaný bod přítomnosti sítě CineGrid. Tento bod přítomnosti se skládá z kombinace několika pevných a mobilních zařízení. Do infrastruktury jsme integrovali vybraná zařízení našeho průmyslového partnera, společnosti CINEPOST (je možné tato zařízení použít pro CineGrid projekty po dohodě) v lokalitě filmových studií Barrandov.

Zařízení tvořící infrastrukturu bodu sítě CineGrid jsou:

• 4K monitor Astro Systems,
• dělený displej se čtyřmi monitory,
• 4K kodek JPEG2000 výrobce NTT Labs,
• PC systém na bázi SAGE (Scalable Adaptive Graphics Environment),
• proudovací server pro JPEG2000 4K video (ve spolupráci s KEIO University),
• 4K monitor SONY SRX (ve vlastnictví společnosti CINEPOST),
• zařízení pro barevné korekce FilmLight BaseLight FOUR (ve vlastnictví společnosti CINEPOST),
• systémy pro přenos nekomprimovaného videosignálu v HD rozlišení na bázi prostředí UltraGrid a iHDTV.

Prostory, kde je možné mobilní systémy plnohodnotně používat, jsou vymezeny schopností přijímat a zobrazovat video nejméně o rozlišení 4K + odpovídající audio. Zároveň musí disponovat dostatečně kvalitní přípojkou k infrastruktuře CineGrid (respektive k infrastruktuře GLIF, kterou CineGrid používá). Připravené a ověřené jsou následující lokality:

• prostory sdružení CESNET (s omezením vzhledem k akustice),
• prostory laboratoře Siťola v Brně (MU Brno),
• digitální kino v budově Varšava v prostorách ateliérů Barrandov (CINEPOST),
• prostory Institutu intermédií v halových laboratořích v Technické ulici (ČVUT).

Prakticky lze realizovat připojení v ČR prakticky na jakékoliv VŠ, která je k síti CESNET2 připojena rychlostí 10 Gb/s.

Díky vybudovanému bodu přítomnosti CineGrid a jeho koncepci a konfiguraci disponuje sdružení prvním místem na světě, které umožňuje distanční práci v oblasti postprodukce digitálního intermediátu.

9.3.1   Spolupráce s kinematografickým průmyslem

Podařilo se nám vytvořit prototyp metodiky aplikace 4K workflow při přenosu denních prací (dailies). Systém jsme ověřili v praxi v případě nutnosti přenosu dat mezi Prahou (CINEPOST - studia Barrandov Praha) a Los Angeles, respektive San Diego. Tento přenos jsme ověřili ve spolupráci s UCSD/Calit2 a UIC/EVL/StarLight.

Výsledky jsme prezentovali na konferencích ABEX society (ČR), ChinaCom 2008 (Čína), 8th Annual Global LambdaGrid Workshop (Seattle, USA) a CineGrid Workshop 2008 (San Diego, USA).

Naše řešení pro vzdálené barevné korekce vyvinuté ve spolupráci s CineGrid a CINEPOST jsme prezentovali na konferenci NAB 2008 (Las Vegas, USA).

9.3.2   Demonstrace

V spolupráci s aktivitou 601, Masarykovou Univerzitou, UCSD/Calit2, UIC/EVL/StarLight a UW/Research Channel/PWNGigapop jsme v rámci 8th Annual Global LambdaGrid Workshop prezentovali aplikaci fotonického multicastu pro účely vysílání vysoce kvalitního videa. Vysílali jsme nekomprimovaný HD videosignál o datovém toku 1,1 Gb/s z Brna přes Prahu do Chicaga, kde byl signál opticky replikován a posílán zpět do Brna, dále do Seattle a do San Diega. Uvedené řešení pracuje až do limitů rozhraní (v našem případě 10GE).

9.4   Vyhledávač

Ve spolupráci s naší partnerskou společností Jyxo se nám podařilo rozšířit vyhledávač audiovizuálních dat na Internetu tak, že pokrývá všechny země rozšířené EU.

9.5   Statistiky

Vzhledem k potřebám uživatelů našeho systému pro vysílání audia a videa jsme v součinnosti s aktivitou Sledování infrastruktury a provozu sítě uvedli do provozu systém sledování využití jednotlivých vysílacích bodů. Systém je koncipován jako nezávislý na vysílací platformě nebo počtu serverů. Předávací rozhraní je tvořeno protokoly HTTP/XML.

předchozí

obsah

následující