Extrakce multimediálních dat pro úložiště ModeShape Bakalářská práce
Robert Šiška
Brno, Podzim 2015
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Robert Šiška
Vedoucí práce: RNDr. Adam Rambousek, Ph.D. iii
Shrnutí Systém na správu repozitářů ModeShape umožňuje extrakci strukturovaných metadat z multimediálních souborů analýzou jejich obsahu. Tato práce se zabýva dokumentací této funkcionality a rozšiřuje podporu o vybrané multimediální a kancelářské formáty. Pro každý formát deĄnuji relevantní metadata a implementuji sekvencery pro extrakci dat ze souborů. Práce také demonstruje použití jednoho ze sekvencerů v systému na tvorbu webových prezentací Magnolia CMS.
iv
Klíčová slova modeshape, sequencing, metadata, multimedia, pdf, odf, epub, magnolia
v
Obsah 1 2 3 4 5 6 7 8 A
Standard JCR a jeho implementace . . . . 1.1 Úvod k JCR . . . . . . . . . . . . . . . . 1.2 Implementace a jejich uživatelé . . . . . . Sekvenace v systému ModeShape . . . . . 2.1 Popis architektury . . . . . . . . . . . . . 2.2 Tvorba nových sekvencerů . . . . . . . . Sekvenování formátu PDF . . . . . . . . . Sekvenování OpenDocument formátů . . Sekvenování formátu EPUB . . . . . . . . . Sekvenování zvukových formátů . . . . . Sekvenování video formátů . . . . . . . . . Demonstrace v systému Magnolia CMS . Přílohy . . . . . . . . . . . . . . . . . . . . . A.1 Přehled žádostí o začlenění do ModeShape A.2 Obsah digitální přílohy . . . . . . . . . . A.3 Příklad konĄgurace sekvenceru . . . . . . A.4 Příklad deĄnice nových typů uzlů . . . . A.5 Příklady JCR dotazů využívajích metadata
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
3 3 4 5 5 5 7 9 11 13 16 18 22 22 22 23 23 24
vi
Úvod Cílem práce je analyzovat a zdokumentovat sekvenaci metadat v systému na správu repozitářů ModeShape a doplnit podporu pro vybrané multimediální formáty. Pro jednotlivé formáty deĄnuji metadata, která považuji za relevantní, a implementuji moduly schopné tato metadata extrahovat. Výsledek práce bude začleněn do hlavní vývojové větve systému ModeShape. Sekvenování, neboli konstrukce strukturovaných metadat z binárních dat uložených v repozitáři, je funkce ModeShape, která není součástí standardu JCR. Apache Jackrabbit pouze podporuje extrakci obsahu populárních binárních formátů pro potřeby fulltextového vyhledávání. Strukturovaná metadata, která jsou výstupem této operace, mohou být kromě vyhledávání využita také k analýze dat nebo k dotazování na základě kritérií, jako třeba délka zvukové stopy nebo rozlišení obrázku. ModeShape již dokáže extrahovat metadata z graĄckých formátů, archivů ZIP, dokumentů produkovaných kancelářským balíkem Microsoft Oice, a z několika dalších nemultimediálních formátů. Protože časté využití systémů JCR je v tzv. systémech na správu obsahu (Adobe CQ5, Magnolia CMS, Hippo CMS, . . . ), zdá se být na místě zabývat se multimediálními formáty používanými na dnešním webu. V první kapitole se věnuji popisu nejdůležitějšich vlastností standardu JCR a přehledu jeho implementací. V druhé kapitole se podrobněji zabývam extrakcí metadat v systému ModeShape a stručně popisuji, jak vytvořit sekvencer nový. V následujících kapitolách popisuji metadata jednotlivých multimediálních formátů a postup při jejich extrakci. Postupně se zabývám kancelářskými formáty PDF, ODF a EPUB, a dále zvukovými a video formáty. Výsledek každé kapitoly je fungující a zdokumentovaný modul systému ModeShape, který je připraven pro používání a pro začlenění do hlavní vývojové větve zdrojového kódu. Ke každému modulu jsem kromě dokumentace ve formě JavaDoc napsal také článek do oĄciální dokumentace systému. Tyto články jsou před přijmutím ModeShape týmem dostupné prostřednictvím ticketu (neboli požadavku k začlenění změn do hlavního repozitáře zdrojového kódu) daného modulu. 1
Poslední kapitola demonstruje užitečnost této práce v praxi. Popisuje webovou aplikaci založenou na komunitní verzi systému Magnolia CMS, která pomocí ModeShape analyzuje a zobrazuje metadata video souborů. Stručně také zmiňuji problémy při přechodu aplikace Magnolia CMS z repozitáře Apache Jackabbit k ModeShape, na které jsem narazil.
2
1 Standard JCR a jeho implementace 1.1 Úvod k JCR ModeShape je implementace standardu Content Repository API for Java (dále JCR). Tento standard je deĄnovaný speciĄkací JSR-170 [1] a dodatečně rozšířen speciĄkací JSR-283 [2]. Cílem JCR je poskytnout jednotné rozhraní pro práci s repozitářem dat v programovacím jazyce Java. Z pohledu programátora jsou tato data uspořádána ve stromech s několika kořeny, podobně jako diskové jednotky v operačním systému Windows. Skutečný repozitář však může být souborový systém, relační databáze, úložiště typu cloud a další. Verze 2.0, deĄnovaná speciĄkací JSR-283, uvádí dodatečné funkce, jako dotazování, verzování obsahu, kontrolu přístupových práv a mnoho dalších. Standard JCR deĄnuje API pro práci s repozitáři obsahu. Repozitář se skládá z jedné či více oblastí (workspace), které mohou obsahovat stromy s uzly (nodes) a poduzly (properties) (tj. potomky uzlů, které jsou vždy listy). Samotná data jsou uložena v poduzlech a mohou být ve formě textového řetezce, čísla, pravdivostní hodnoty, časového údaje nebo binárních dat. Každý uzel nebo poduzel musí být jednoho či více typů, které určují nejen jaké poduzly může uzel obsahovat nebo jakého typu jeho poduzly jsou, ale také jeho vlastnosti, jako třeba schopnost být řazen nebo vyhledáván. Kromě tohoto datového modelu nabízí JCR možnost dotazování pomocí jazyka podobného SQL, verzování obsahu, kontrolu práv přístupu k uzlům, zamykání uzlů pro prevenci konkurentních změn, nebo třeba sledování a reakce na změny na zvolených cestách. Z pohledu uživatele tohoto API se nejprve naváže spojení s repozitářem a utvoří se sezení. Veškeré změny provedené v tomto sezení jsou uloženy jako transakce, které jsou provedeny, až když uživatel sezení uloží. Dodatečné funkce nejsou po implementacích vyžadovány. Uživatel se může pomocí API dotázat, zda chtěnou funkcionalitu daná implementace podporuje. Hlavní funkcí systémů JCR a tedy i ModeShape je ukládání souborů a následná práce s nimi. Zatímco v ostatních implementacích jsou soubory pouze uloženy jako binární poduzel a popřípadě některé formáty indexovány pro fulltextové vyhledávání, ModeShape umožňuje soubory analyzovat a vyvozovat z nich strukturovaná me3
1. Standard JCR a jeho implementace tadata. Ta mohou být následně využita pomocí JCR API k vyhledávání pomocí složitějších dotazů nebo například k analýze a statistice uložených dat. Pro příklady zajímavých dotazů využívajících metadata viz přílohu A.5.
1.2 Implementace a jejich uživatelé Kromě svobodného software ModeShape od společnosti Red Hat splňují tento standard také referenční implementace Apache Jackrabbit a Apache Jackrabbit Oak zaměřený na výkon a škálovatelnost. Systémy na správu obsahu, jako třeba Alfresco často nabízí JCR API jako jednu z možností, jak s daty pracovat. Mnoho těchto tzv. Enterprise Content Management (ECM) a jiných digitálních repozitářů tento standard podporují1 . Standard vyvinula švýcarská společnost Day Software, kterou v roce 2010 koupila Adobe Systems, a úspěšně prošel začleňovacím procesem JCP (Java Community Process). Výsledné API je tedy oĄciální součástí platformy Java a nachází se v balíku javax.jcr. Aplikací, které na standardu JCR staví, je bezpočet. Většinou se jedná systémy typu (Web) Content Management System (CMS/WCM), Digital Asset Management (DAM) nebo například Business process management (BPM). Velmi rozšířená je také podpora JCR ve vývojových knihovnách (Apache Sling, Apache Cocoon, Apache Tapestry, Spring Framework, a další). Zejména v oblasti podnikových Java systému je JCR bezpochyby jedno z nejrozšířenějších řešení práce s repozitáři obsahu. Kromě platformy Java vzniká také snaha o implementaci tohoto standardu v jiných jazycích. Vývojáři svobodného CMS TYPO3 zahájili projekt PHPCR (PHP Content Repository) Ű standard pro jazyk PHP vypracovaný dle speciĄkací JSR-170 a JSR-2802 . Zatím jediná aktivně vyvíjená implementace tohoto standardu se jmenuje Jackalope3 . Tento projekt je však teprve v počátku. V jiných jazycích zatím žádné pokusy o implementaci speciĄkací neexistují.
1 Day
CRX, Microsoft Sharepoint, IBM CM, eXo Platform a další.
2 http://phpcr.github.io/
3 http://jackalope.github.io/
4
2 Sekvenace v systému ModeShape 2.1 Popis architektury Sekvenace je speciální funkcionalita ModeShape, která není součástí standardu JCR. V rámci systému existují sekvencery ve formě modulů. To z důvodu, že ne všichni uživatelé tohoto systému potřebují pracovat se všemi typy datových souborů. Sekvencery také zpravidla využívají programové knihovny třetích stran, které nemusí být s každým řešením kompatibilní. Z technického pohledu je každý sekvencer deĄnován jediným JVM objektem implementujícím jednoduché rozhraní a jeho registrací v nastavení repozitáře. Sekvencer o sobě prohlašuje s jakými typy MIME (Multipurpose Internet Mail Extensions) zvládá pracovat, a jeho konĄgurace určuje, na kterých částech repozitáře operuje a kam ukládá extrahovaná metadata. ModeShape pak automaticky (pomocí funkce JCR sledování změn) při vytvoření nebo změně obsahu na těchto cestách analyzuje MIME typ datového souboru a provádí extrakci vhodnými sekvencery. Celá operace je spuštěna na pozadí ve vlastním vlákně1 , aby nebyl uživatel blokován. Od verze 3.6.0 je možné zpracování souboru vyvolat také manuálně skrze sezení přímo na zvoleném poduzlu nesoucím binární data. Tato funkce je pochopitelně deĄnována pouze v sezení systému ModeShape, a kód, který ji používá, se připravuje o možnost použít ostatní implementace standardu JCR. Metadata řady datových formátů již systém ModeShape konstruovat umí. Jsou to soubory XML, schémata XSD, archivy ZIP, soubory WDSL, zvukový formát MP3, dokumenty z kancelářského balíku Microsoft Oice a populární graĄcké formáty. Zbylé typy multimedií se snažím doplnit prostřednictvím této práce.
2.2 Tvorba nových sekvencerů DeĄnice nového sekvenceru je poměrně přímočará. Tvoří jej totiž jediná třída, která dědí po abstraktní třídě z API systému ModeShape. Tato abstraktní třída obsahuje dvě prázdné metody, které musí po1 Počet
vláken je možné nastavit v konĄguraci repozitáře. Viz příloha.
5
2. Sekvenace v systému ModeShape tomci implementovat. Pokud však chceme, aby nový modul fungoval automaticky, musíme jej nastavit v konĄguraci repozitáře. Toto nastavení obvykle obsahuje jméno třídy, deĄnici vstupní cesty (cesty, na jejíž změny sekvencer reaguje) a deĄnici výstupní cesty (cesty, kam jsou výsledná metadata uložena). Jazyk pro deĄnici cest umožňuje vytvářet vzory vyhovující více řetězcům, podobně jako jazyk regulárních výrazů. Ve výstupní cestě je možné použít zachycenou část vstupní cesty a pokud výstupní cesta chybí, metadata jsou uložena jako potomek vstupního uzlu. První abstraktní metoda initialize() slouží k inicializaci. Je volána výhradně systémem ModeShape a v argumentech poskytuje objekty potřebné k registraci nový typů uzlů a registraci MIME typů, které podporuje. Druhá metoda, kterou musí potomci této třídy obsahovat, je execute(). Tato metoda má jako argumenty poduzel, který vyhovuje vstupní cestě a jehož změna způsobila její vyvolání, a výstupní uzel, pod který mají být metadata uloženy. Tento uzel může již existovat, nebo být právě vytvořený. Je potřeba mít na paměti, že vstupní poduzel a výstupní uzel se mohou nacházet v různých oblastech repozitáře. Proto je nutné po dokončení práce uložit sezení spojené s výstupním uzlem. V nejjednodušším případě může být tedy celá funkcionalita dosažena za pomocí jediné třídy. V praxi však tvoří sekvencery samostatné podprojekty v systému Maven (deĄnované vlastním POM objektem), které se nachází ve skupině org.modeshape.sequencer. Tento podprojekt pak tvoří vlastní balík JAR (nebo více balíků JAR, pokud jsou použity knihovny třetích stran). Konvence doporučuje, aby modul obsahoval soubor formátu CND (Compact Node DeĄnition) s deĄnicí všech typů uzlů, které při konstrukci metadat vytvoří2 , a statickou Java třídu, která obsahuje konstanty všech jmen typů. Dobrou praxí je také oddělit veškerou práci s datovým souborem do zvláštní třídy a v hlavní třídě sekvenceru pouze sestavit JCR strom metadat. V neposlední řadě je vhodné všechen kód řádně otestovat pomocí jednotkových testů a zdokumentovat pomocí JavaDoc.
2 Všechna
metadata daného modulu by měla deĄnovat svůj vlastní jmenný prostor a jeho preĄx.
6
3 Sekvenování formátu PDF Formát PDF (Portable Document Format) od společnosti Adobe Systems je jeden z nejrozšířenějších formátů pro uchování dokumentů. Formát se výrazněji rozšířil v roce 1994 poté, co společnost změnila obchodní strategii produktu Acrobat Reader (dnes Adobe Reader) a produkt začala nabízet zdarma. Tím se formát stal de facto standardem pro uchovávání dokumentů v elektronické podobě. SpeciĄkace formátu byla volně dostupná již od jeho vzniku, formát byl ale stále chráněn vlastnickými právy Adobe Systems až do roku 2008, kdy byl jako verze 1.7 standardizován Mezinárodní organizací pro normalizaci ISO pod identiĄkátorem ISO 32000-1 [3]. Dnes je tedy PDF otevřený standard a je podporován většinou aplikací určených k práci s dokumenty. Některá rozšíření standardu, jako například archivační varianta PDF/A, jsou deĄnovány jako samostaté standardy. PDF dokument může obsahovat informace o názvu dokumentu, autorovi, datech vytvoření, poslední modiĄkace a podobně. Pro tato metadata byla původně vyhrazena oblast v patičce souboru zvaná Document Information Dictionary. Počínaje verzí 1.4 speciĄkace doporučuje používat ke kódování metadat ISO standard XMP (Extensible Metadata Platform.) Tento na formátu nezávislý standard popisuje datový model postavený na XML, serializaci binárních dat do XML a způsob vkládání do multimediálních formátů bez porušení jejich čitelnosti. Poprvé byl tento standard použit v balíku Adobe Acrobat, současně ale může být vložen do řady graĄckých, zvukových nebo video formátů. Používán je zejména u graĄckých formátů typu RAW, vytvářených v dnešních fotoaparátech. XMP také deĄnuje několik sad metadat určených k různým účelům. Každá sada má svůj jmenný prostor a jeden XMP soubor může obsahovat více sad. Mimo jiné je možné použít také známé schéma Dublin Core. V rámci PDF mohou být metadata přidružena nejenom k samotnému dokumentu, ale také k ostatním objektům uvnitř souboru, jako k jednotlivým stranám, k vloženým obrázkům nebo k přílohám. Navzdory jasným výhodám XMP metadat je však starší a jednodušší forma metadat stále rozšířenější. V neposlední řadě nabízí formát možnost šifrování dokumentu a digitální podepisování.
7
3. Sekvenování formátu PDF Sekvencer, který jsem navrhl, je schopný extrahovat všechna metadata uložena v Document Information Dictionary, a také všechna pole ze standardního jmenného prostoru XMP z metadat přiložených k dokumentu, stránkám a obrázkům. Metadata z DID jsou uložena jako poduzly uzlu pdf:metadata. Metadata ze jmenného prostoru XMP jsou uložena ve zvláštním uzlu pdf:xmp. Pro každou stranu dokumentu nebo přílohu, která obsahuje metadata, je vytvořen samostatný metadatový uzel typu pdf:xmp. Sekvencer také vytváří odvozená metadata, jako počet stran, rozměry a orientace papíru, verze formátu PDF a podobně. Pokud je dokument chráněn heslem, je možné extrahovat pouze odvozená metadata. Pro otestování kódu jsem vytvořil PDF soubor obsahující všechna metadata, jejichž extrakce je implementována, a heslem chráněný soubor. Pro práci se soubory PDF v jazyce Java se naskýtá několik možností. Nejdospělejší a zároveň aktivně vyvíjiné knihovny jsou vícejazyčný iText1 a Apache PDFBox.2 Obě podporují čtení, vytváření a manipulaci se standardem PDF po verzi 1.7 a obě mají otevřené zdrojové kódy. Vlastník knihovny iText však v roce 2009 změnil její licenci na AGPLv3, která zamezuje bezplatné použití knihovny v programech s uzavřeným kódem, což je právo, které licence ModeShape neupírá. Zvolil jsem tedy balík knihoven Apache PDFBox, který má licenci shodnou s ModeShape. V době psaní této práce vzniká novější verze této knihovny, která částečně mění API pro práci s XMP metadaty, zatím je však teprve ve stavu prvního kandidáta na Ąnální verzi.
1 http://itextpdf.com/
2 http://pdfbox.apache.org/
8
4 Sekvenování OpenDocument formátů Otevřený standard OpenDocument Format byl vyvinut standardizačním sdružením OASIS a vychází ze staršího formátu kancelářského balíku OpenOice.org od Sun Microsystems. Účel ODF je poskytnout formát pro všechny typy kancelářských dokumentů, jako prezentace, tabulky, grafy nebo textové dokumenty. Standard deĄnuje také formáty pro vektorovou graĄku, matematické formule a databáze, a také šablonové varianty všech formátů. Soubor v některém z formátů ODF je buď jediný soubor formátu XML, nebo balík JAR, obsahující několik XML souborů a přidružené datové soubory. Balík JAR je užíván téměř výhradně, protože může obsahovat binární data, která musí být do XML serializována, a protože má ve většině případů menší velikost (formát JAR je komprimační). Některé produkty, které o sobě prohlašují podporu formátů ODF, dokonce XML varianty formátů nepodporují (například kancelářský balík Microsoft Oice po verzi 2013). OpenDocument je od roku 2006 kromě OASIS standardu také standard organizace ISO. Rozšířený formát OpenDocument 1.2 byl touto organizací standardizován v červenci tohoto roku [4]. Formát OpenDocument podporuje několik typů metadat. Každý objekt uvnitř souboru může nést metadata ve formě RDF (rodina speciĄkací vypracovaných organizací W3C, jejímž zástupcem je i již dříve zmíněný formát XMP). Tento kontejner pro uchování metadat je velice Ćexibilní, ale v praxi vpodstatě nepoužívaný. V součastnosti neumožňuje žádný kancelářský balík tato metadata upravovat nebo číst. Druhý typ metadat je speciální element uvnitř hlavního XML souboru, který deĄnuje 20 polí pro uchování běžných metadat, jako titul, autor, klíčová slova, ale také dobu editace aj. Mezi těmito poli jsou také statistiky o dokumentu, které obsahují informace o počtu stran, tabulek, obrázků apod. Další metadata mohou být speciĄkována uživatelem (v LibreOice skrze dialog nazvaný Ďvlastní vlastnosti.Ş) Zatímco sekvencer pro dokumenty produkované kancelářským balíkem Microsoft Oice již ModeShape obsahuje, svobodný standard OpenDocument zatím zaměřen nebyl. Mnou navržený sekvencer extrahuje všechna předdeĄnovaná metadata, uživatelem speciĄkovaná metadata a statistiky o dokumentu. Všechna tato pole jsou uložena jako poduzly uzlu odf:metadata. Rozhodl jsem se neimple9
4. Sekvenování OpenDocument formátů mentovat extrakci RDF metadat především z důvodu jejich mizivé podpory v kancelářském softwaru. Pro práci s formátem OpenDocument jsem použil knihovnu Simple API z balíku ODF Toolkit1 . Tento projekt je od roku 2011 ve stádiu začlenění mezi projekty Apache Software Foundation. Od té doby byly vydány již tři verze, poslední v červenci minulého roku. Simple API vytváří abstraktní vrstvu využívající více podrobné ODFDOM API ze stejného balíku. Druhá volba pro práci s ODF v jazyce Java je knihovna jOpenDocument z dílny francouzské softwarové Ąrmy ILM Informatique2 . Tato knihovna má otevřené zdrojové kódy, nelze ji však bezplatně použít v komerčních projektech. Za zmínku však stojí, že jOpenDocument má srovnatelné vlastnosti s balíkem ODF Toolkit a je přitom mnohonásobně rychlejší. Ani jedna z těchto knihoven zatím neumí pracovat s jinými typy dokumentů než je text, tabulka, prezentace a vektorová graĄka. Matematické formule, databáze a ostatní typy deĄnované standardem tedy sekvencer neumí v současnosti zpracovat. Jednotkové testy ověřují správnost extrakce všech podporovaných metadat z dokumentů typu textový dokument, tabulka, prezentace a graĄka, a také jejich šablonové typy.
5 Sekvenování formátu EPUB V oblasti elektronických knih a dokumentů existuje již celá řada široce podoporovaných formátů. V minulosti byl pravděpodobně nejpoužívanějším formátem PDB pocházející z mobilního operačního systému Palm OS a PDF. Již v devadesátých letech se objevila snaha vytvořit otevřený formát, který by sloužil jako standard. Vznikající speciĄkace se nazývala Open eBook a její implementací je například formát MOBI. Dnes je však nejpopulárnější formát EPUB, zejména kvůli jeho propagaci významnými společnostmi, jako Adobe a distributory Amazon či Barney & Nobles a dalšími[6]. Formát EPUB je vytvořený dle standardu organizace IDPF (Internation Digital Publishing Forum) a slouží k reprezentaci a distribuci digitálních publikací. Rozšířenou verzi tohoto formátu, která hlavně umožňuje přesnější deĄnici rozložení textu, doporučuje také Book Industry Study Group jako standard, který by měl být preferovanou volbou pro digitální publikování. Také podpora ve čtecích zařízeních je velmi široká a to i přes relativně náročné zpracování. Z technického hlediska je totiž EPUB speciální adresářová struktura XML a jiných souborů komprimovaná algoritmem ZIP. Čtečka tedy musí být schopna s těmito technologiemi pracovat, což může být problematické, zejména v prostředí vestavěných systémů. Pro uchování metadat je použito schéma Dublin Core, jehož pole jsou uložena ve speciálním elementu hlavního (tzv. kořenového) XML souboru. Ačkoli je formát EPUB svobodný, jeho speciĄkace umožňuje použití digitální správy práv (DRM). Nicméně nevynucuje žádné konkrétní schéma DRM, což vede k jistému zmatku a nekompatibilitě formátů jednotlivých distributorů. Systém od Adobe Content Server of společnosti Adobe Systems je pravděpodobněji nejpoužívanější systém na správu a distribuci elektronických knih s DRM. Takto upravené soubory jsou pak čitelné pouze s použitím softwaru od společnosti Adobe Systems. DRM je implementováno jako zašifrování vybraných souborů, které pak mohou být dešifrovány pouze se znalostí klíče a algoritmu (který není veřejný.) Na extrakci metadat však DRM vliv nemá, neboť kořenový soubor být šifrován nemůže. Pro práci s formátem EPUB v jazyce Java příliš knihoven neexistuje, vzhledem k jednoduchosti formátu však není problém pracovat 11
5. Sekvenování formátu EPUB se soubory pomocí standardního API platformy Java. Mnou napsaný kód nejprve nalezne všechny kořenové soubory v kontejneru ZIP, dekomprimuje jejich obsah a pomocí dotazovacího jazyka XPath projde a uloží hodnoty všech XML elementů ze jmenného prostoru Dublin Core, jako titul, autor, datum vytvoření a podobně [7]. Pokud kontejner obsahuje speciální soubor určený na ukládání metadat, je použit přednostně. Pole značící název knihy, jazyk a identiĄkátor jsou povinná, zbylých dvanáct polí jsou volitelná. Všechny pole jsou uloženy jako poduzly uzlu epub:metadata. Pro potřeby testování jsem vytvořil soubory typu EPUB, EPUB 3 a EPUB obsahující metadata ve speciálním souboru.
12
6 Sekvenování zvukových formátů Systém ModeShape obsahuje sekvencer souborů MP3 již od první verze. Ten však dokáže extrahovat pouze několik polí z ID3 štítku (standard pro kódování metadat často přikládáný k MP3.) V rámci této práce jsem tento sekvencer rozšířil pro extrakci většího počtu metadat u více formátů. Konkrétně formátů MP4, 3GP, OGG Vorbis, FLAC, WMA a WAVE. Všechny tyto formáty umožňují nastavení alespoň některých metadat. Navíc je případné analyzovat vlastnosti souborů v těchto formátech, jako například délku, počet kanálů, vzorkování a podobně. Formát MP3 (MPEG-1/2 Audio Layer III) byl vyvinut v rámci standardu MPEG-1 (resp. MPEG-2) skupinou MPEG a standardizován jako norma ISO v roce 1993. Jedná se o ztrátový kompresní formát, který je schopný zmenšit velikost hudebních souborů přibližně na desetinu při zachování dostatečné kvality. To mu zajistilo obrovskou popularitu na tehdy rapidně rostoucím Internetu. Popularitě také výrazně přispěl přehrávač Winamp, dostupný zdarma. Standard MPEG deĄnuje MP3 jako sadu zvukových segmentů, které dohromady tvoří zvukový proud. V první a druhé audio vrstvě formátu MPEG jsou na sobě segmenty naprosto nezávislé. To pro třetí vrstvu již neplatí úplně, ale každý segment má stále svou vlastní hlavičku. Žádná souhrnná hlavička, která by charakterizovala celý proud tedy v souboru není. Tento nedostatek vyřešilo přidání tzv. štítku ID3 na konec souboru, což je jednoduše datový blok s pevnou délkou, umožňující popsat soubor metadaty předdeĄnovaného typu. Tento formát metadat není popsán žádnou speciĄkací, stal se ale de facto standardem. Přestože byl štítek ID3 elegantním řešením problému, brzy přestalo toto řešení dostačovat zejména kvůli nedostatečné maximální velikosti hodnot. Pro metadata typu řetězec je ve štítku vyhrazeno pouze 30 bytů. Jako nástupce vznikl metadatový štítek ID3v2, který má jinou strukturu. Tento štítek se umisťuje na začátek souboru, výrazně rozšiřuje maximální velikost štítku až na 256 megabytů (oproti 128 bytů štítku první verze) a umožňuje ukládání více typů metadat, včetně graĄckých dat. Štítek ID3v2 je narozdíl od ID3 deĄnován speciĄkací, která však zatím nebyla standardizována žádnou normalizační organizací. Přesto je jeho podpora velmi rozšířená. Sekvencer je schopný 13
6. Sekvenování zvukových formátů extrahovat všechna metadata z obou typů štítků, přičemž preferuje hodnoty nastavené ve vyšší verzi. Další dva zvukové formáty vychází z otevřeného standardu vydadného společností Xiph.Org. Jsou to bezztrátový kompresní formát FLAC (Free Lossless Audio Codec) a ztrátový formát Vorbis známý spíše pod názvem Ogg, kvůli jeho obvyklé příponě. Formát MP3 vzhledem k zmiňované absenci jakékoliv hlavičky v podstatě kontejner nemá, to je však v oblasti audio a video formátů spíše výjimkou. U těchto formátů často rozlišujeme jednak samotný formát kódování (nazýván v tomto kontextu kodek1 ) a kontejner, což si můžeme představit jako obálku, která může obsahovat více zvukových, video nebo jiných datových proudů. Kontejner Ogg může obsahovat proudy Vorbis, FLAC, ale i video proudy Theora a mnohé další formáty organizace Xiph.Org. Metadata, která má každý proud vlastní, jsou ve formátu Vorbis Comment. Navzdory svému jménu může být toto metadatové schéma použito i v jiných proudech než Vorbis. Názvy polí se schéma podobá štítku ID3v2, umožňuje však nastavit každé pole vícekrát. Formát WMA (Windows Media Audio) a jeho bezztrátová varianta WMA Lossless byly vyvinuty společností Microsoft. Jako kontejner jim slouží Advanced Systems Format, který nese metadata. Formát deĄnuje vlastní formát metadat s mnoha poli a podporuje i metadata formátu XMP. Kontejner má také volitelnou funkci digitální správy práv (DRM). Metadata jsou však i při použití DRM stále dostupná. MP4 (MPEG-4 Part 14) je multimediální kontejner, který kromě videa může obsahovat také zvukové kodeky AAC a Apple Lossless. Formát může obsahovat DRM schéma omezující přehrávání jen na produkty společnosti Microsoft. Metadata jsou uložena v kontejneru a jsou čitelná, i když je soubor chráněn systémem DRM. Formát AAC bývá často ukládán také v kontejneru 3GP, který má opět vlastní sadu metadat. Posledním formátem, se kterým je sekvencer schopen pracovat, je WAVE (Waveform Audio File Format), který vznikl již v roce 1991 ve spolupráci společností Microsoft a IBM. Formát má vlastní sadu me-
1 Jméno
kodek je původně určeno programu schopnému kódovat a dekódovat data, je však používán i jako označení samotného formátu kódování.
14
6. Sekvenování zvukových formátů tadat (deĄnovanou v obecném formátu RIFF) a podporuje také štítky ID3 a metadata formátu XMP. Zvukový sekvencer deĄnuje nový typ uzlu audio:metadata, který obsahuje informace o míře vzorkování, počtu kanálů, délce a bitrate. Tento uzel může obsahovat potomka typu audio:tag, který zahrnuje obecná metadata, obsažena ve štítcích zvukových formátů, jako autor, název, album, a podobně. Všechna graĄcká metadata jsou uložena jako binární uzly JCR. Sekvencer v současnosti nepodporuje metadatový kontejner XMP, z důvodu jeho mizivého výskytu. Pro práci se zvukovými soubory jsem použil svobodnou knihovnu jAudioTagger2 , která vytváří abstrakci nad metadatovými štítky všech formátů a navíc umožňuje zjišťovat informace vyvozené z hlaviček formátů nebo jinak. Jediný problém, na který jsem narazil, byl fakt, že jAudioTagger neumí automaticky rozlišovat formáty. Uživatel této knihovny musí zjistit formát souboru a použít odpovídající třídu. ModeShape API však nabízí vlastní rozšíření binárního poduzlu, který MIME typ určuje pomocí softwaru Apache Tika. Pro potřeby testování jsem sestavil soubory ve všech šesti podporovaných formátech s vyplňenými všemi metadatovými poli, která je můj kód schopen extrahovat.
2 http://www.jthink.net/jaudiotagger/
15
7 Sekvenování video formátů Oblast video formátů je velmi dynamická. Existují desítky formátů, které mohou být obsaženy v různých kontejnerech, a většina nejpoužívanějších formátů je poměrně mladá (například Flash Video, H.264 a WebM vznikly po roce 2000). Zatímco v popularitě dlouhodobě vedly kontejnery AVI od společnosti Microsoft Windows, obsahující kodeky vycházející ze standardu MPEG-4, jako DivX a XviD, a kontejnery MPEG-1 a MPEG-2. Tyto formáty jsou však již v dnešní době považovány spíše za zastaralé. V dnešní době jsou nejpopulárnější kontejnery Matroska, WebM, MP4 a FLV, kodeky H.264 a rodina kodeků TrueMotion. Z důvodu nestálosti formátů je proto problematické udržovat API pro obecnou práci s videem. Oracle, vývojář platformy Java, nabízí knihovnu Java Media Framework1 , která je zaměřena na kódování proudů za učelem přehrávání a nahrávání. Informace o samotných formátech toho však přiliš zjistit nedokáže. Navíc, podpora kodeků je mizivá; o to více těch v současnosti používaných. Dále existuje několik knihoven zaměřených na konkrétní formáty nebo kontejnery. Vzhledem k potřebám této práce mě však nejvíce zaujal velmi mladý projekt Humble Video2 , dříve nazýván Xuggler. Tato knihovna využívá nativní kód mocné knihovny z projektu FFmpeg3 (který mimochodem používá pro práci s videi i portál YouTube) a vytváří nad ním API pro jazyky platformy Java. Nevýhoda tohoto řešení je, že tato knihovna není multiplatformní. Pomocí centrálního repozitáře systému Maven je dostupná verze, která obsahuje nativní kód pro všech šest nejrozšířenějších platforem Ű Microsoft Windows, OS X a Linux v 32 a 64 bitových verzích. Jakékoliv narušení multiplatformnosti je však samozřejmě v rozporu s ĄlosoĄí platformy Java. Na druhou stranu, zmíněné platformy pokrývají drtivou většinu uživatelů systému ModeShape a použití této knihovny umožní sekvenaci desítek zvukových a video kodeků. 1 http://www.oracle.com/technetwork/java/javase/tech/
7. Sekvenování video formátů V současnosti tento modul rozpoznává formáty kontejnery Matroska, Apple Quicktime, AVI, WMV, FLV, 3GP, WebM, MP4 a OGG. Přidání podpory ostatních formátů je však dosažitelné pouze rozšířením typů MIME, jež pro sebe sekvencer registruje. Tento modul zavádí nový typ uzlu video:metadata, který může nést informace, jako titul, komentář, bitrate, délku videa či program použitý při kódování videa. Tento uzel také může obsahovat uzly typu video:stream popisující multimediální proudy obsažené v kontejneru. Proudy mohou být buď typu audio resp. video a podle toho tento uzel nese informace o vzorkování, počtu kanálů, rozlišení, počtu snímků za sekundu a podobně. Pro testování kódu jsem vytvořil pět video souborů různých formátů obsahující všechna metadata, která je sekvencer schopen extrahovat. Mnoho formátů podporuje schémata DRM; tyto formáty neumí software FFmpeg číst, a tudíž ani nový sekvencer neextrahuje data takto upravených souborů.
17
8 Demonstrace v systému Magnolia CMS Mezi software, který systémy JCR používá, nepochybně patří systémy na správu obsahu. Tím je i Magnolia CMS (Content Management System), který sice vznikl na systému Apache Jackrabbit, ale je možné jej použít i se systémem ModeShape za použití modulu, na jehož vývoji se dlouhodobě podílím. Magnolia je svobodný software, který byl jedním z prvních uživatelů Apache Jackrabbit. Účelem tohoto systému je deĄnice a údržba webových prezentací s náročnějšími požadavky při zachování jednoduchosti a použitelnosti. Dodnes je tato společnost velmi aktivní a v posledních letech se výrazněji zaměřuje na integraci s dalším svobodným i komerčním softwarem v oblasti podnikové verze platformy Java. Ačkoliv Jackrabbit i ModeShape podporují všechny funkce standardu JCR 2.0, přechod není zcela bez obtíží. Především jsem objevil několik chyb, jak na straně ModeShape1,2 , tak na straně Magnolia CMS. Nejen chyby v samotném softwaru, ale také rozdílné výklady speciĄkace ztěžují kompatibilitu. Například registrace nových typů uzlů, zejména jejich dědičnosti, je v Jackrabbit poněkud volnější, oproti ModeShape, který provádí důkladnější validaci dle pravidel uvedených ve speciĄkaci. Všechny typy deĄnované v Magnolii a jejich modulech neprochází validací, což je chyba poměrně triviální na opravu, nicméně je to natolik dalekosáhlá změna, že musí být přesunuta až do další hlavní verze softwaru3 . Zajímavá je také neshoda systémů Jackrabbit a ModeShape ohledně serializace. Standard JCR 2.0 deĄnuje povinnou funkci ukládání celého stromu nebo podstromu do formátu XML. Načítání zpět do repozitáře zpět je volitelná funkce a oba systémy postupují jinak při načítání výstupu XML, který obsahuje kořenový uzel. I tato funkce je v Magnolii hojně využívána. Magnolia tedy zatím nefunguje s ModeShape stoprocentně bez jistých ĎzáplatŞ4 . Integrací těchto systémů se budu určitě zabývat i v budoucnu. 1 http://issues.jboss.org/projects/MODE/issues/MODE-2504 2 http://issues.jboss.org/projects/MODE/issues/MODE-2511 3 http://jira.magnolia-cms.com/browse/MAGNOLIA-6394 4 http://jira.magnolia-cms.com/browse/MGNLMSHAPE-22
18
8. Demonstrace v systému Magnolia CMS Pro demonstraci sekvenace jsem vytvořil webovou aplikaci postavenou na svobodné verzi systému Magnolia CMS, používající ModeShape jako repozitář obsahu. Aplikace obsahuje jediný dodatečný modul, který ke komponentě k zobrazování videa přidá všechna nalezená metadata. KonĄgurace repozitáře ModeShape obsahuje také sekvencer, který sleduje oblast vymezenou k ukládání multimédií. Každý soubor s vyhovujícím typem MIME, který uživatel nahraje, je tak automaticky předán sekvenceru, který extrahuje všechna metadata a uloží je pod datový uzel. Nová šablona video kompomenty pak vypíše všechny poduzly uzlu video:metadata. Zdrojové aplikace jsou obsaženy v příloze. K jejímu úspěšnému přeložení do mezikódu Java je zapotřebí záplatovat (viz třetí poznámka pod čarou na předchozí straně) modul magnolia-core softwaru Magnolia CMS a přeložit větev, která obsahuje video sekvencer. Pro usnadnění jsem do přílohy zahrnul i přeloženou aplikaci ve standardním formátu WAR obsaženém ve webovém kontejneru Apache Tomcat. Stačí tedy spustit dávkový soubor bin/startup.bat v operačních systémech Microsoft Windows, nebo skript bin/startup.sh na platformátch typu UNIX. Jméno i heslo pro vstup do aplikace jsou superuser. V sekci Pages se na adrese demo-project → multimedia → video-player nachází webová stránka obsahující video komponentu. Pomocí tlačítka v pravém horním rohu kompomenty můžeme nahrát nové video. Po uložení kompomenta ihned zobrazuje extrahovaná metadata.
19
Závěr Projekt dle mého názoru dostál zadaných kritérií. Zdokumentoval jsem sekvenování v systému ModeShape a přispěl jsem do oĄciální dokumentace oddílem o tvorbě nových sekvencerů. Dále jsem vytvořil pět nových sekvencerů schopných extrahovat relevantní metadata z multimediálních souborů nejrůznějších formátů. V oblasti multimédií umí tedy v současnosti ModeShape navíc k obrázkům, dokumentům Microsoft Oice a MP3 souborům sekvenovat také dokumenty formátů PDF, OpenDocument a EPUB, zvukové formáty MP4, 3GP, Ogg, FLAC, WMA, a WAVE. Sekvencer video formátů, který využívá projekt FFmpeg, rozpozná desítky formátů a kontejnerů, má však limitovanou podporu platforem. Pro práci s jednotlivými formáty jsem převážně použil již existujících knihoven, dostupných pod svobodnými licencemi, které umožňují začlenění do systému ModeShape. Veškerý kód je v době psaní práce ve formě požadavku na začlenění do hlavní vývojové větve. Příloha obsahuje odkazy na tyto požadavky. Pro demonstraci užitečnosti kódu v praxi jsem také vytvořil webovou aplikaci založenou na systému Magnolia CMS, která ve video komponentě zobrazuje všechna extrahovaná metadata. Aplikace používá modul modeshape-support, na jehož vývoji se dlouhodobě podílim5 .
Literatura [1] JSR-170 Content Repository for Java Technoogy API. Červen 2005. Java Community Process. Dostupné na: . [2] JSR-283 Content Repository for Java Technology API Version 2.0. Září 2009. Java Community Process. Dostupné na: http://jcp.org/ en/jsr/detail?id=283. [3] ISO 32000-1:2008 Document management Ű Portable document format Ű Part 1: PDF 1.7. ICS: 35.240.30; 37.100.99. Ed. 1. Červenec 2008. International Organization for Standardization. [4] ISO/IEC 26300:2006 Information technology Ű Open Document Format for Oice Applications (OpenDocument) v1.0. ICS: 35.240.30. Ed. 1. Prosinec 2006. International Organization for Standarization. [5] EPUB SpeciĄcation. International Digital Publishing Forum. Dostupné na: http://idpf.org/epub. [6] GARRISH, Matt. What is EPUB 3?. O’Reilly Media, Inc., c2011. ISBN 978-1-449-31454-5. [7] Dublin Core Element Set, Version 1.1. Dublin Core Community. 1999. Dostupné na: http://www.dublincore.org/documents/ dces/.
21
A Přílohy A.1 Přehled žádostí o začlenění do ModeShape •
http://issues.jboss.org/browse/MODE-2549 PDF sequencer