Technologieverkenning

Transcriptie

1 Technologieverkenning MediaMosa Matterhorn Koppeling Matterhorn en MediaMosa

2 Versie: 1.0 Datum: 5 januari 2011 Auteurs: Herman van Dompseler Wladimir Mufty Frans Ward SURFnet/Kennisnet Innovatieprogramma Het SURFnet/ Kennisnet Innovatieprogramma wordt financieel mogelijk gemaakt door het Ministerie van Onderwijs, Cultuur en Wetenschap. Voor deze publicatie geldt de Creative Commons Licentie Attribution 3.0 Unported. Meer informatie over deze licentie is te vinden op 2

3 Inhoudsopgave Management Samenvatting Inleiding Achtergrond Doel Beschrijving The big picture Mogelijke koppelingen Nut/meerwaarde voor onderwijs Leeswijzer Hard- en software configuratie Opstelling Gebruikte hard- en software Capture Agent Matterhorn server Installatie en configuratie van Matterhorn Introductie Trunk vs. final release Capture Agent Matterhorn server Matterhorn delivery methoden Delivery workflow Workflow aanmelding YouTube delivery code Configuratie opties De test De conclusie Search API Request Response Atom request en response

4 4.2.4 De conclusie MediaMosa ontvangst methoden REST FTP bulk VUF AtomPub Proof of Concept Eerste versie Tweede versie Uitgebreide AtomPub specificatie CMIS Open Social oauth Conclusie

5 Management Samenvatting Deze technologieverkenning geeft antwoord op de volgende vragen: Is het mogelijk om Matterhorn in te zetten voor het opnemen van colleges op een zodanige wijze dat deze weblecture recordings automatisch in MediaMosa opgeslagen kunnen worden om via een eindgebruiker applicatie als SURFmedia ontsloten te kunnen worden? En Welke aanpassingen zouden er aan MediaMosa gedaan moeten worden zodat Matterhorn op deze manier op MediaMosa aangesloten kan worden? Het rapport en de Proof of Concept (POC) omgeving van deze verkenning vormen de basis voor besluitvorming over volgende releases van MediaMosa. Meerwaarde voor het onderwijs MediaMosa is open source software waarmee een op webservices gebaseerd media management en distributie platform gemaakt kan worden. MediaMosa faciliteert aan eindgebruikerdiensten (zoals SURFmedia) toegang tot en gebruik van video s en biedt onder andere opslag-, transcoding- en streamingdiensten. Zie ook: De kracht van MediaMosa is het media management systeem, het toekennen van metadata en afscherming aan de video en het geschikt maken voor streaming, inclusief transcoding naar de gewenste videoformaten. MediaMosa heeft echter geen functionaliteit aan boord om weblecture recordings te kunnen maken en daarom kan het Opencast Matterhorn project een belangrijke aanvulling op het gebruik van MediaMosa zijn. Het Opencast Matterhorn project heeft veel aandacht binnen de doelgroep. Er worden regelmatig vragen gesteld of Matterhorn en MediaMosa met elkaar vergeleken kunnen worden en hoe beiden ingezet zouden kunnen worden. Door te laten zien dat beide producten samen gebruikt kunnen worden en hierbij aanvullend op elkaar kunnen werken kan op deze vragen antwoord gegeven worden. Proof of Concept De Proof of concept is opgebouwd uit 3 fasen, waarbij de eerste fase bestond uit het installeren van een volledig werkende Matterhorn Capture cliënt en Matterhorn server. In de fasen daarna werd bekeken hoe content uit Matterhorn in MediaMosa geplaatst zou kunnen worden. Het onderzoek laat zien dat er diverse methoden zijn om dit voor elkaar te krijgen. Deze zijn verder uitgewerkt en hieruit is het gebruik van de AtomPub API met ondersteuning van de Open Social standaard als favoriete oplossing gekomen. 5

6 Conclusie Om Matterhorn met MediaMosa op de gewenste manier samen te laten werken, waarbij Matterhorn gebruik maakt van de delivery workflow en MediaMosa gebruik maakt van de AtomPub API, is er een aantal werkzaamheden te verrichten. De werkzaamheden voor Matterhorn zijn: 1. In Java een delivery workflow programmeren 2. De upload in MediaMosa middels de uitgebreide AtomPub specificatie doen. a. POST 3. Gebruikers van Matterhorn authentiseren met oauth. Voor MediaMosa zijn dit de werkzaamheden: 1. Een REST interface voor de AtomPub specificatie maken 2. Gebruikers authentiseren met oauth mogelijk maken Aan de ontwikkelpartij Madcap is opdracht gegeven om de REST interface van MediaMosa aan te passen zodat deze voldoet aan de standaarden Atom 1, RSS 2 en JSON 3. Ook is opdracht gegeven om de Open API, zoals deze in de Proof of Concept is gebruikt, op te nemen in de MediaMosa code en zal support voor de Open Social standaard 4 worden ontwikkeld. De aanpassingen aan Matterhorn zullen in een later stadium gedaan kunnen worden, wanneer de code van Matterhorn verder ontwikkeld is. Hoewel de resultaten van deze Technologieverkenning, na vertaling in het Engels, ook met de Opencast community gedeeld zullen worden, valt niet te verwachten dat alle gewenste aanpassingen door de Opencast community opgepakt zullen worden. Met name de ontwikkeling van een specifieke MediaMosa workflow zal door de MediaMosa community geïnitieerd moeten worden. Op basis van de resultaten van deze verkenning wordt in de loop van 2011 een pilot met instellingen uitgevoerd waarbij onderzocht wordt of Matterhorn in combinatie met MediaMosa een goed alternatief is voor de commerciële systemen voor het opnemen en afspelen van weblectures. 1 Atom: 2 RSS: 3 JSON:

7 1 Inleiding 1.1 Achtergrond Het Opencast initiatief is een samenwerking tussen onderwijsinstellingen uit de VS, Canada en Europa met als doel het ontwikkelen van een open source systeem om opnames van colleges zo goed mogelijk in te kunnen zetten in het onderwijs. Specifiek richt de Opencast community zich op de ontwikkeling van Matterhorn voor het ontsluiten van weblecture recordings. The Opencast community is a collaboration of individuals, higher education institutions and organizations working together to explore, develop, define and document best practices and technologies for management of audiovisual content in academia. Through the mailing list, website and collaboration among its members, the community will strive to offer guidance and information to help others choose the best approach for the delivery and usage of rich media online. The Opencast community also supports community-driven projects to solve common issues in management of academic audiovisual content. These projects will include open source software development, such as Matterhorn, and research focused projects. The Opencast Community will support these projects through feedback and participation in project-related activities. Bron: Matterhorn is vergelijkbaar met MediaMosa 5 : een open source video platform voor gebruik in het onderwijs veld waarmee (rich) media ontsloten kan worden. Maar er zijn ook grote verschillen. Matterhorn is vooral gefocust op het opnemen van weblecture recordings aan het begin van de keten waarbij processen als scheduling, video capture, workflow en ingest een grote rol spelen. Maar ook aan de eindgebruikerskant biedt Matterhorn mooie functionaliteiten waaronder een mediaplayer met ondersteuning voor zaken als OCR, captioning en branding. MediaMosa biedt deze functionaliteiten niet en focust met name op de rol als centrale media repository met specifieke taken voor metadata, transcoding en het kunnen afschermen van media. Het ligt voor de hand om de sterke punten van Matterhorn te combineren met de sterke punten van MediaMosa. Matterhorn en MediaMosa vullen elkaar aan zou je kunnen zeggen. Eerder is al bekeken of MediaMosa niet als basis voor het Opencast Matterhorn initiatief zou kunnen dienen. Vanwege de incompatibele open source licenties 5 MediaMosa: 7

8 (Matterhorn: Apache ECL, MediaMosa: GPLv2) bleek dit echter niet eenvoudig mogelijk en heeft Opencast er voor gekozen MediaMosa niet als basis te gebruiken. 1.2 Doel Deze technologieverkenning (TV) geeft antwoord op de volgende vragen: En Is het mogelijk om Matterhorn in te zetten voor het opnemen van colleges op een zodanige wijze dat deze weblecture recordings automatisch in MediaMosa opgeslagen kunnen worden om via een eindgebruiker applicatie als SURFmedia ontsloten te kunnen worden? Welke aanpassingen zouden er aan MediaMosa gedaan moeten worden zodat Matterhorn op deze manier op MediaMosa aangesloten kan worden? 6 Het rapport en de Proof of Concept (POC) omgeving van deze TV vormen de basis voor besluitvorming over volgende releases van MediaMosa. Het onderzoek versterkt de samenwerking tussen de Opencast en MediaMosa communities en zal het gebruik van weblectures in het onderwijs beter toepasbaar maken. 1.3 Beschrijving Deze TV is onder te verdelen in een drietal fases: (zie figuur 1) Fase 1: Onderzoek naar Matterhorn en definiëren van use cases. Installatie van een Matterhorn platform bestaande uit een Capture Agent (onderdeel: Matterhorn Lecture Capture and Administration) en een Matterhorn Server (Onderdelen: Matterhorn Ingest and Processing, Matterhorn Distribution Management en Matterhorn Engage Tools). In deze fase is de werking van Matterhorn onderzocht. Er zijn test opnames gemaakt en deze fase vormt de basis voor de volgende fasen. In deze fase staat Matterhorn op zichzelf en is niet gekoppeld aan MediaMosa. 6 En vice versa: Mocht blijken dat het zinvoller of efficiënter is om aan de Matterhorn zijde aanpassingen te maken dan kan hierover in overleg getreden worden met de Opencast community. 8

9 Fase 2: Koppelen van Matterhorn aan MediaMosa (deel functionaliteit). In deze fase is onderzocht in hoeverre de Matterhorn Workflows kunnen worden aangepast om de opnames in MediaMosa te krijgen. Hierbij zijn twee MediaMosa ingangen onderzocht: de FTP-bulk upload en de directe REST-interface. Uitgangspunt bij deze opstelling is geweest dat er gebruik wordt gemaakt van bestaande Matterhorn functionaliteit en dat voor deze koppeling geen aanpassingen hoeven te worden gemaakt (op de aangepaste workflows na). Voor MediaMosa werden wel noodzakelijke aanpassingen verwacht. Dit heeft te maken met het authenticatie proces tussen een EGA en de MediaMosa backend. Momenteel is er een zgn. trust relatie op basis van het DBUS protocol nodig, maar voor open en niet afgeschermde content is dat niet nodig. Een andere aanpassing werd verwacht bij het mechanisme rondom de play-tickets bij het opvragen (of afspelen) van content. Het gebruiken van open en niet afgeschermde content zou eenvoudiger kunnen wanneer hier statische URL s voor worden gebruikt i.p.v. het gebruik van een play-proxy en tijdelijke URL s. Figuur 1: de 3 fases in deze TV Fase 3: Koppelen van Matterhorn aan MediaMosa (volledige functionaliteit). In aanvulling op fase 2 is het in deze fase mogelijk om alle functionaliteit van Matterhorn in te zetten in combinatie met MediaMosa. In feite wordt hier de backend van Matterhorn vervangen door MediaMosa. Voordeel hiervan is een grote flexibiliteit en geen afhankelijkheid met SURFmedia om de content af te kunnen spelen. Om dit te 9

10 realiseren zijn er aanpassingen aan MediaMosa nodig. Authenticatie vind nu immers plaats via een DBUS trust relatie met een EGA die een ticket mechanisme gebruikt om te bepalen of een gebruiker gerechtigd is om media te kunnen bekijken. In deze opstelling met Matterhorn is er geen sprake van een trust relatie met MediaMosa en zal de authenticatie zich geheel op webservice niveau moeten afspelen. Authentiseren op webservice niveau kan met een technologie genaamd oauth. Met oauth wordt data gedeeld tussen twee applicaties. Hierdoor kan een cliënt applicatie gebruik maken van de afgeschermde data in een bron, zoals MediaMosa. Zie voor uitleg hierover de oauth specificaties: Er zal daarom ondersteuning voor oauth in MediaMosa toegevoegd moeten worden The big picture Om Opencast op MediaMosa aan te sluiten biedt Opencast twee delivery methoden: 1. Delivery workflow 2. Search API MediaMosa heeft drie ontvangst methoden: 1. REST interface met DBUS authenticatie 2. FTP bulk upload 3. AtomPub API Een video die opgenomen wordt in Opencast, dit is het capture proces, wordt in MediaMosa opgeslagen en beheerd, dit is het management proces. De video wordt in een eindgebruiker applicatie of een mashup (via de Open API) aangeboden aan de kijker, dit is het presentation proces. Zie het volgende figuur: 10

11 Figuur 2: The big picture: Opencast levert video aan MediaMosa Mogelijke koppelingen De koppeling tussen Opencast en MediaMosa komt bij voorkeur tot stand tussen de delivery workflow van Opencast en de AtomPub API van MediaMosa. Dit zijn de oranje componenten in bovenstaand figuur. Het alternatief is lezen uit de search API van Opencast en ingesten via FTP bulk in MediaMosa. Dit is het rode component. Deze TV kan in sterke mate gezien worden als het vervolg op de TV Open Webservices 7 welke is uitgevoerd door Herman van Dompseler. In deze TV is onderzocht hoe content op een open manier aangeboden kan worden en hoe MediaMosa gebruik kan maken van data die via andere open webservices beschikbaar wordt gemaakt. Het in MediaMosa opslaan van content die door Matterhorn is opgenomen (de weblecture recordings) past precies in de laatste categorie. 1.4 Nut/meerwaarde voor onderwijs De kracht van MediaMosa is het media management systeem, het toekennen van metadata en afscherming aan de video en het geschikt maken voor streaming, inclusief transcoding naar de gewenste videoformaten. MediaMosa kan gezien worden als de 7 Rapport beschikbaar op: 11

12 motor voor het werken met video in het onderwijs. Maar aan enkel een motor heb je niet genoeg. Om MediaMosa te kunnen gebruiken heb je ook een carrosserie nodig, de eindgebruikers applicatie en brandstof, de mediafiles. Een toenemende belangrijke bron vormen de opnames van de colleges: de weblecture recordings. MediaMosa heeft echter geen functionaliteit aan boord om weblecture recordings te kunnen maken en daarom kan het Opencast Matterhorn project een belangrijke aanvulling op het gebruik van MediaMosa zijn. Het Opencast Matterhorn project heeft veel aandacht binnen de doelgroep. Er worden regelmatig vragen gesteld of Matterhorn en MediaMosa met elkaar vergeleken kunnen worden en hoe beiden ingezet zouden kunnen worden. Door te laten zien dat beide producten samen gebruikt kunnen worden en hierbij aanvullend op elkaar kunnen werken kan op deze vragen antwoord gegeven worden. Tot slot is er een meerwaarde voor de MediaMosa Community vorming. Deze TV zal aandacht trekken van de Opencast community, een veel grotere community dan de MediaMosa community op dit moment. Deze aandacht voor MediaMosa zal een positieve uitwerking kunnen hebben op de community vorming van MediaMosa. 1.5 Leeswijzer Na een inleidend hoofdstuk over deze technologieverkenning zal in hoofdstuk 2 en 3 de installatie en configuratie van de hardware en van Matterhorn worden beschreven. In de hoofdstukken 4 en 5 wordt de koppeling tussen Matterhorn en MediaMosa onderzocht aan zowel de Matterhorn kant (de verzend of delivery methoden) als aan de MediaMosa kant (de ontvangst methoden). Hoofdstuk 6 bespreekt de opzet van de Proof of Concept omgeving en in hoofdstuk 7 wordt het gebruik van de voorgestelde AtomPub specificatie verder uitgewerkt. Tenslotte zijn in hoofdstuk 8 de conclusies van dit onderzoek opgenomen. 12

13 2 Hard- en software configuratie De Matterhorn client-server opstelling is opgebouwd uit meerdere hardware componenten waarmee je een registratie kan maken door middel van video en audio. Er is getracht om bestaande, soms wat verouderde, componenten te gebruiken en niet gebruik te maken van de meest recente (high-end) oplossingen. Door bewust te kiezen voor gangbare en betaalbare hardware kan een opstelling worden samengesteld welke mogelijkerwijs ook terug te vinden is in de collegezalen binnen het hoger onderwijs. Dit hoofdstuk geeft een overzicht van de SURFnet gebruikte opstelling, specificatie en configuratie van de Capture Agent en de Matterhorn server die tijdens deze TV zijn gebruikt. 2.1 Opstelling Matterhorn kent een client-server architectuur, de cliënt wordt aangeduid met de term Capture Agent. Deze Capture Agents staan in de collegezalen en verzorgen de daadwerkelijke opname van video, audio en de video-opname van het computerscherm Capture Agent Capture Agent (screen capture). Binnen de TV is dan ook gekozen voor een reguliere opstelling waarbij Server de Capture Agent fysiek in een andere ruimte staat ten opzichte van de server. De server in het (enkelvoudige) centrale punt waarin de opname-agenda wordt bijgehouden en waarin de opnames definitief worden opgeslagen en waarvandaan deze later kunnen worden Capture Agent Capture Agent afgespeeld door de eindgebruiker (Zie figuur Figuur 2. Client-server architecture. 2). Er is gebruik gemaakt van één Capture Agent, de huidige opzet leent zich echter uitstekend voor het verder opschalen van het aantal Capture Agents over meerdere locaties. Het is daarnaast mogelijk om de server ook als Capture Agent te gebruiken. Dit kan in bepaalde (uitzonderlijke) gevallen wenselijk zijn. Er dienen hiervoor wel enkele aanpassingen aan software en configuratie gemaakt te worden. 2.2 Gebruikte hard- en software Eén van de doelen die wordt nagestreefd door de ontwikkelaars van Matterhorn is het mogelijk maken van opnames doormiddel van gangbare en betaalbare hardware. Zij willen hiermee voorkomen dat gebruikers naast de eenmalige aanschaf kosten ook vastzitten aan onderhouds- of licentiekosten. Er is een hardware-referentie 8 lijst

14 aanwezig op de website van het Opencast Matterhorn project waar de mogelijk te gebruiken componenten staan vermeld. Deze hardware componenten zijn getest en worden ondersteund door de te gebruiken software. In de volgende twee paragrafen wordt er een overzicht gegeven van de door SURFnet gebruikte hard- en software, ook wordt er een toelichting gegeven over het gebruik en de opgedane ervaring Capture Agent Matterhorn behaalde in augustus 2010 een mijlpaal door het uitbrengen van haar 1.0 release versie. Deze 1.0 versie is dan ook gebruikt binnen deze TV als de te gebruiken software. Het succesvol installeren en configureren van de hardware componenten binnen de Capture Agent verliep vrij moeizaam en heeft relatief veel tijd gekost. De oorzaak hiervan ligt deels in het feit dat er gebruik wordt gemaakt van nieuwe software met daarin nog onopgemerkte fouten, de afwezigheid van volledige documentatie en de beperkte ondersteuning van hardware componenten. De installatie en gebruik van de video capture card vergde veel aandacht. De beperkte set ondersteunde capture cards zorgde in eerste instantie al voor problemen bij het verkrijgen van een geschikt exemplaar. De capture cards van het merk Hauppauge zijn in Nederland zeer gangbaar en beschikbaar voor de consumentenmarkt, de door Matterhorn ondersteunde versies zijn echter al wat ouder en zijn om die reden niet meer verkrijgbaar. De capture cards moeten dus nog wel tot de beschikking zijn om hiervan gebruik te kunnen maken. Het was binnen deze TV dan ook nodig om o.a. (oude) machines te onderzoeken op de aanwezigheid van zo n kaart en er is gezocht op particuliere verkoopsites zoals Marktplaats.nl en ebay. Ook is er een beroep gedaan op (privé) eigendommen van collega s. Voor het gebruik van screen capture hardware, om het VGA beeldsignaal op te kunnen nemen, is er een zeer beperkte keuzemogelijkheid. Het aantal fabrikanten van dit hardware type is beperkt en kennen naast de producten van Epiphan ook geen ondersteuning binnen Matterhorn. De reeds aanwezige Epiphan producten bij SURFnet maakte de aanschaf hiervan onnodig, de kosten van dit type hardware lopen echter uiteen beginnende bij 250 tot zelfs 1500 euro, afhankelijk van de geleverde prestaties (geheugen, resolutie, frames per seconde e.d.). Een ander obstakel bij het toepassen van geschikte hardware was het gebruik van een video camera met ondersteuning van S-video. De ondersteuning van deze verouderde norm voor het transporteren van videosignalen hangt weer samen met de ondersteunde video capture cards. Er zal net een beroep moeten worden gedaan op reeds beschikbare video camera s met een S-video uitgang of er dient gezocht te worden bij particulieren (2 e hands) of een video speciaalzaak. Er is gebruik gemaakt van de standaard geluidskaart voor het opnemen van de audio. De geluidskaart zit op het moederbord en maakt een geluidsopname doormiddel van een eenvoudige microfoon welke gericht staat op de spreker/presentator. Er waren enkele problemen met het geluid die betrekking hadden op het gebruikte 14

15 besturingssysteem en de geluidskaart. Het probleem en de oplossing hiervoor staan goed gedocumenteerd in de installatie handleiding van Matterhorn. De hardware systeem componenten zoals processor, intern geheugen, geluidskaart of harde-schijf kennen daarentegen een reguliere (gangbare) ondersteuning. Deze is niet direct afhankelijk van de Matterhorn software maar houdt meer verband met de ondersteuning binnen het besturingssysteem. Er is in deze TV gekozen om gebruik te maken van Ubuntu Het gebruik hiervan in combinatie met Matterhorn wordt ondersteund en is gedocumenteerd. De volledige configuratie van gebruikte hard en software onderdelen van de Capture Agent zijn opgenomen in Tabel 1. Tabel 1. Configuration Capture Agent Operating System Name: Kernel: Ubuntu 9.10 Desktop (karmic) generic #48-Ubuntu i686 GNU/Linux Matterhorn GNOME: Version: Maven: Apache Maven (rdebian-1) Hardware Java version: 1.6.0_20 Memory: Processor0: Processor1: Disk space: 2.0 GiB Intel Pentium 4 CPU 3.4GHz Intel Pentium 4 CPU 3.4GHz GiB Capture card Card: Hauppauge WinTV PVR-250 Capabilities: VIDEO_CAPTURE, VBI_CAPTURE,?,TUNER, AUDIO, REDWRITE Driver: ivtv Audio 15

16 Name: Intel ICH7 (default on motherboard) Microphone: Labtec AM-22 (600 ohm) Screen capture Name: Model: Type: Max width: Max height: Epiphan VGA2USB Pro CAPTURE 1280 px 1024 px Camera (2) Name & model: Docking: Name & model: Panasonic NV-DX110 Panasonic VSK 0499 (required for S-Video) Sony DCR-TRV30E Matterhorn server De benodigde hardware componenten voor de Matterhorn server kende geen issues zoals deze naar voren zijn gekomen bij de Capture Agent. De server maakt zelf geen opnames en bevat daarom geen randapparatuur of de benodigde ondersteuning daarvoor. Er is niet duidelijk gedocumenteerd wat de exacte, noch de gewenste, requirements zijn. De binnen deze TV gebruikte hardware blijkt in de praktijk naar behoren te werken, het is echter wel aan te raden om bij gebruik binnen een productie omgeving na te gaan wat de exacte requirements zijn. Dit ter voorkoming van problemen met onvoldoende capaciteit bij de installatie maar ook ter indicatie bij beheer en gebruik van o.a. schijfruimte, geheugen en processorkracht. Bij het draaien van de server is er gebruik gemaakt van een Virtual Machine, dit maakt het eenvoudig om backups te maken, te experimenteren, en updates te draaien met niet-stabiele (productiewaardige) software versies. De gekozen opzet is dan ook specifiek voor de gekozen situatie en zeker niet een voorwaarde voor de implementatie van de server van Matterhorn. De volledige configuratie van gebruikte hard- en software onderdelen van de Matterhorn server zijn opgenomen in Tabel 2 16

17 Tabel 2. Configuration server Host Operating System Name: Windows 7 Enterprise, 32-bit (Build 7600) CPU: RAM: Type: Disk: Intel Xeon CPU E5440 2,83GHz (2 processors) 4.00 GB (3.25 USABLE) 32-bit OS 195 GB Virtual Machine Operating System Name: Kernel: Ubuntu 9.10 Desktop (karmic) generic #54-Ubuntu i686 GNU/Linux Matterhorn GNOME: Version: Maven: Apache Maven (rdebian-1) Java version: 1.6.0_15 MAVEN_OPTS: -Xms512m -Xmx1024m -XX:PermSize=128m - XX:MaxPermSize=256m' Felix: org.apache.felix.main.distribution tar.gz Virtual Machine Software: Memory: VMware Player build MB Processors: 4 Hard disk: Network: USB: Sound: Display: 20 GB bridged none none autodetect 17

18 18

19 3 Installatie en configuratie van Matterhorn 3.1 Introductie De installatie van Matterhorn kent meerdere stappen en is grofweg in te delen in 4 fases: Het bemachtigen van de laatste Matterhorn versie. Het installeren van benodigde componenten zoals Java, Maven en Felix. Het installeren van 3rd party software voor het bewerken van multimedia bestanden. (alleen nodig op de server). Het builden van de Matterhorn source code naar werkende software. Naast deze manuele vorm van installatie zijn er ook twee alternatieven beschikbaar waarbij de software voor-geïnstalleerd is in de vorm van een virtuele machine 9 (0.5 versie) of als binary-bestand 10 beschikbaar is. Binnen deze TV is gekozen om geen gebruik te maken van deze voor-geïnstalleerde versie i.v.m. de nadelen bij het up-todate houden van de software en de mogelijkheid om gebruik te maken van zelf gedefinieerde instellingen. Het installeren, configureren en beheren van de Matterhorn software vereist enige systeem(beheer) kennis. Bij het volledig aanhouden van de requirements en andere systeem randvoorwaarden is het mogelijk om een installatie en configuratie uit te voeren met eenvoudige systeembeheer vaardigheden. Hoe gebruikers kunnen controleren of zij volledig aan alle randvoorwaarden en requirements voldoen is niet gedocumenteerd. 3.2 Trunk vs. final release Een trunk -versie van software binnen het software ontwikkeldomein is in actieve ontwikkeling en bevat de nieuwste maar ook potentieel onstabiele functionaliteiten. Het is bedoeld voor de meer gevorderde gebruikers die voornemens zijn gebruik te maken van de meest recente versies zonder dat hier volledige ondersteuning voor is of de garantie dat deze volledig correct werkt. Ook binnen het Matterhorn ontwikkeltraject is er de beschikking over een trunk versie, hier is binnen deze TV meerdere malen mee gewerkt. Hoewel in veel gevallen de trunk versie problemen oplost uit een voorgaande versie of nieuwe functionaliteiten toevoegt, is er tijdens de finale opzet van het systeem gekozen om hier geen gebruik van te maken. Er is gekozen voor de stabiele 1.0 versie, deze versie wordt niet meer

20 aangepast en de werking ervan is bekend en gedocumenteerd. De 1.0 versie wordt gebruikt op zowel de Capture Agent als op de server. Het combineren van de 1.0 versie met een trunk versie kan om de eerder beschreven problematiek tot onoverkomelijke problemen leiden. Versie 1.0 source: Trunk source: Capture Agent De installatie van de software op de Capture Agent is gedaan aan de hand van de handleiding op Hier staan de stappen omschreven bij het gebruik van een op Linux gebaseerd systeem zoals Ubuntu. De handleiding is duidelijk, maar verondersteld enige kennis van systeembeheer op dit type platform. Voor de door SURFnet uitgevoerde TV is ook gebruik gemaakt van de handleiding 11 geschreven door Anastassia Loujanina en Brian Bolt (Boise State University) ter uitbreiding op de eerder genoemde handleiding. Een van de belangrijkste bevindingen die uit de installatie naar voren kwamen waren de specifieke randvoorwaarden waaraan moest worden voldaan om succesvol een installatie af te kunnen ronden. Daarnaast is gebleken dat de documentatie niet op alle vlakken is bijgewerkt, aanwezig is of duidelijk genoeg is. Door gebruik te maken van een Wiki voor het bijwerken van de documentatie bleek al tijdens de TV dat hier aan werd gesleuteld en dat de documentatie gedurende de uitvoer van de TV beter en completer werd. Overige issues die specifiek bij de installatie van de Capture Agent parten speelde waren: Drivers voor de Epiphan VGA2USB frame grabbers. Er zijn hier alleen pre-compiled drivers beschikbaar voor Linux (i386 and x86_64). Het grote nadeel hiervan is dat als de benodigde drivers niet beschikbaar 12 zijn deze bij de fabrikant moeten worden aangevraagd. Een alternatief voor het vermijden van deze afhankelijkheid van de fabrikant is het specifiek selecteren van een besturingssysteem en bijbehorende kernel waarvoor reeds een driver beschikbaar is. Het updaten van de kernel kan echter weer tot problemen leiden. Deze situatie is dan ook onwenselijk

21 S-Video instellingen video capture card. De video capture cards van Hauppauge kennen vaak meerdere input kanalen. Voordat het mogelijk wordt om de videosignalen correct te ontvangen op de Capture Agent is het noodzakelijk om deze input kanalen te configureren. Hier is geen documentatie over binnen de handleiding en zal ook per type kaart verschillen. Binnen de installatie van deze TV was het nodig om naar het juiste S-video kanaal te verwijzen op systeemniveau en aan te geven dat de PALstandaard gebruikt dient te worden. Dit kan worden bewerkstelligd door het automatisch uitvoeren van de volgende video4linux -commando s bij het opstarten van het systeem: Set video input to 1 (S-Video 1): v4l2-ctl -i 1 Set video standard to PAL: v4l2-ctl -s 5 Aangesloten hardware tijdens installatie. Het is noodzakelijk dat tijdens de installatie alle benodigde hardware is aangesloten. Als dit niet het geval is zal Matterhorn het niet aangesloten onderdeel tijdens de installatie overslaan. Dit zorgt weer voor een incompleet systeem. Naast de fysieke aansluiting is het van belang dat de drivers ook overeenkomen en correct zijn geladen en aangesloten apparatuur niet op standby staat of opnames maakt van een apparaat (bijvoorbeeld een systeem) dat op stand-by staat. Herinstallatie of updaten van de Capture Agent. Het her-installeren van de Capture Agent heeft in veel gevallen voor problemen gezorgd waarvan de bron moeilijk te herleiden is. Het volledig opnieuw installeren van de software op een schoon systeem gaf dan ook de beste resultaten en was het meest efficiënt. Als er geavanceerde systeembeheer vaardigheden 13 aanwezig zijn moet het mogelijk zijn om de Capture Agent opnieuw te installeren op een systeem waarop deze al actief is. Verwijderen van de software. Het is niet gelukt om de software succesvol weer te verwijderen. Het verwijderen van de software verloopt via het uitvoeren van een verwijder - script, deze geeft echter een syntax-foutmelding waardoor het verwijderen vroegtijdig wordt afgebroken en er niet met zekerheid kan worden vastgesteld welke onderdelen volledig, deels of geheel niet zijn verwijderd. Dit kan mede de oorzaak zijn van problemen bij de herinstallatie. Overige problemen. Er zijn aan het begin van de TV, waarin werd gewerkt met de 0.8 versie en later 13 Uitsluiten van cache problematiek, g-streamer kennis, SVN updates uitvoeren en handmatig processen en pipelines beëindigen of opstarten. 21

22 met trunk versies, verscheidende problemen ontstaan waarvan de oorzaak praktisch gezien niet te achterhalen is. Daarbij is opgemerkt dat de logging minimaal is en niet altijd even helder is. Er zijn er tal van installaties geweest waarbij om onduidelijke redenen een onsuccesvolle build hebben opgeleverd en daarmee een onbruikbaar systeem. Of dit bijvoorbeeld lag aan een tekort aan intern geheugen, een hapering in het netwerkverkeer of een missende library tijdens een automatisch uitgevoerde installatie is onduidelijk. De gebruikte configuratie settings die tijdens de installatie zijn gebruikt of later handmatig zijn aangepast zijn opgenomen in Tabel 3 Tabel 3. Overzicht Capture Agent configuratie instellingen. capture.device.video.src /dev/video0 capture.device.epiphan_vga2usb.buffer.bytes capture.device.audiomicro.flavor capture.device.epiphan_vga2usb.flavor capture.device.audiomicro.outputfile capture.device.video.flavor = presenter/source presentation/source audiomicro.mp2 presenter/source capture.device.audiomicro.buffer.bytes capture.device.video.outputfile camera_out.mpg capture.device.video.buffer.bytes capture.device.audiomicro.src hw: capture.device.timezone.offset 120 capture.device.epiphan_vga2usb.outputfile capture.device.epiphan_vga2usb.src Epiphan_VGA2USB.mpg /dev/epiphan_vga2usb 3.4 Matterhorn server Met de installatie van de Matterhorn server zijn er aan het begin van de TV ook problemen geweest welke moeilijk identificeerbaar waren. Er werd gewerkt met de nietstabiele 0.8 versie en diverse trunk versies om gebruik te kunnen maken van de nieuwste functionaliteiten of verholpen issues. Ook hierbij geldt dat de minimale logging 22

23 opties en duidelijke foutmeldingen ontbraken om dit proces inzichtelijker te maken of hier een oplossing voor te bieden. De 1.0 versie is echter stabiel en kan zonder problemen worden geïnstalleerd als men de benodigde randvoorwaarden en requirements vervult op systeem- en software niveau. Dit betekent dus het juiste besturingssysteem, kernel versie, werkende drivers, netwerkconnectiviteit etc. De installatie van de 1.0 versie kende echter ook enkele kanttekeningen die binnen de TV van SURFnet van belang waren, zoals het ontbreken van een werkende distributie services voor externe publicatie. Het zou mogelijk moeten zijn om gebruik te maken van distributie services waardoor je standaard al gebruik zou kunnen maken van het publiceren van video s naar bijvoorbeeld Youtube en itunes. Dit werkt helaas (nog) niet in versie 1.0. Er is getracht om dit op ons verzoek te verwerken met een patch, dit heeft nog niet geresulteerd in werkende functionaliteit. Dit was geen vereiste voor het succesvol kunnen uitvoeren van de TV, maar dit zou wel een mooie basis zijn geweest om naast de opties voor Youtube en itunes ook een publicatie-optie naar MediaMosa aan te bieden op een modulaire manier binnen Matterhorn. Zo n aparte module zou dan gebouwd en toegevoegd moeten worden aan de code van Matterhorn. Omdat het mechanisme an sich niet werkt is gekozen om daar nu geen module voor te bouwen. Er is binnen deze TV dan ook gekozen om een alternatief hiervoor te zoeken, door in eerste instantie gebruik te maken van de lokale data opslag op de Matterhorn server en vervolgens deze met behulp van een ATOM-feed over te zetten naar MediaMosa. Een schematisch overzicht van de werking en opstelling is te vinden in Figure 1. In hoofdstuk 4 wordt deze oplossing verder uiteengezet en toegelicht. 23

24 itunes U Matterhorn Opencast Server Classroom lecture Camera Audio Matterhorn Capture Agent Screen capture Figure 1. Opstelling en overzicht Matterhorn werking binnen TV na installatie van versie 1.0. De 1.0 versie bevat daarnaast o.a. issues op het gebied van de grafische interface en compatibiliteitsproblemen. Deze zijn vaak klein van aard en hebben geen grote impact op de overall werking van het systeem binnen deze TV. Ook zijn er verbeteringen mogelijk als het gaat om de robuustheid van de installatie en de configuratie. Iets wat bij een verdere uitrol onder eindgebruikers wenselijk is en de kans op een succesvolle installatie zal verhogen. De volledige lijst met issues en mogelijke oplossingen is te vinden op: 24

25 4 Matterhorn delivery methoden In dit hoofdstuk worden de verschillende delivery methoden van Matterhorn beschreven. 4.1 Delivery workflow Als eerste is onderzoek gedaan naar de delivery workflow van Matterhorn. Hiervoor is een testinstallatie van Matterhorn gedaan en daar is gekeken naar de werking van de delivery workflow van YouTube. Deze workflow is standaard onderdeel van de Matterhorn code en dient als een goed voorbeeld voor MediaMosa Workflow aanmelding Dit is de workflow directory: /opt/matterhorn/felix/conf/workflows Hier staan de diverse workflows vermeld, zoals die van YouTube: <operation id="distribute-youtube" fail-on-error="true" exception-handler-workflow="error" description="distributing media to Youtube please..."> </operation> YouTube delivery code De code die de koppeling met YouTube verzorgt staat in de file: /opt/matterhorn/matterhorn_trunk/modules/matterhorn-distribution-serviceyoutube/src/main/java/org/opencastproject/distribution/youtube/youtubedistributionservice.java In deze code wordt een soort van job gescheduled, die in principe de video zou moeten afleveren. De code is nog niet af getuige bijvoorbeeld de metadata velden: YouTubeDeliveryAction act = new YouTubeDeliveryAction(); act.setname(name); act.settitle(sourcefile.getname()); // CHNAGE ME: set metadata elements here act.settags(new String[] { "whatever" }); act.setabstract("opencast Distribution Service - Youtube"); act.setmediapath(sourcefile.getabsolutepath()); Configuratie opties Om een YouTube filmpje te plaatsen zijn er configuratie opties in: /opt/matterhorn/felix/conf/config.properties 25

26 De default opties zijn: youtube.username=utubedelivery youtube.password=utubedelivery youtube.playlist=b8b47104c2c1663b youtube.clientid=abcde youtube.developerkey=ai39si7bx2abnom6rm8j7mdrljfzczisyzdkqviqejv3zjbqqir6- u_bg3r0mlavvxlqkjssxu4reytwfn7ylildk6oc7pdxpq youtube.task=${org.opencastproject.storage.dir}/distribution/youtube De test Via de interface van Matterhorn is een opname gemaakt en als delivery optie YouTube gekozen. Helaas heeft dit niet geresulteerd in een opname in YouTube. Voorheen heeft de methode wel gewerkt, want er staat een filmpje op YouTube bij het betreffende account: De conclusie Omdat de YouTube voorbeeld delivery methode niet werkt, is het niet mogelijk gebleken een delivery methode voor MediaMosa te maken. Deze manier van workflow maken zal wel de aangewezen manier zijn om in de toekomst een koppeling tussen Matterhorn en MediaMosa te kunnen maken. Hiervoor is het noodzakelijk om een Java expert/programmeur in de arm te nemen die de MediaMosa delivery methode kan ontwikkelen in Matterhorn. Delivery methodes zijn op dit moment niet eenvoudig configureerbaar, maar moeten geprogrammeerd worden. 4.2 Search API Een alternatief op de specifieke delivery workflow voor MediaMosa is om via de zoekoptie toegang te krijgen tot de data in Matterhorn. De opname wordt dan eerst lokaal in Matterhorn opgeslagen met de local delivery optie. De Matterhorn server heeft vervolgens een zoekinterface om de opgeslagen files te bekijken: Request Van de zoekinterface is ook een overeenkomstige REST interface gemaakt, waar het resultaat in een XML formaat opgehaald kan worden. De URL hiervan is: 26

27 4.2.2 Response Het antwoord van Matterhorn op het REST verzoek is in een eigen formaat XML. Een voorbeeld hiervan is: Atom request en response Matterhorn biedt ook een Atom response XML formaat. In de eerste test die was gedaan werkte deze niet. In een latere versie van Matterhorn wel. De Atom URL is: De bijbehorende response is: 27

28 In dit voorbeeld is duidelijk te zien wat Matterhorn aan metadata biedt (gaat bieden). Op dit moment zijn de entries nog vrij summier beschreven. Qualified Dublin Core wordt als extensie op het Atom formaat gebruikt om meer metadata mee te geven. De elementen die gebruikt kunnen worden zijn: asset info: entry:id entry:link (alle enclosures) entry:title metadata: entry:dc:title entry:dc:date entry:dc:identifier De conclusie Zowel de XML response als de Atom response kunnen gebruikt worden als input voor verdere verwerking in MediaMosa. De voorkeur gaat uit naar het Atom formaat, omdat dat een open standaard is die gemakkelijker is te verwerken. 28

29 5 MediaMosa ontvangst methoden In dit hoofdstuk worden twee bestaande en één nieuwe ontvangst methode voor MediaMosa besproken. 5.1 REST De standaard manier om vanuit een (eindgebruiker)applicatie data in MediaMosa te krijgen is via de REST interface van MediaMosa. Om toegang te krijgen is DBUS authenticatie en een trust relatie nodig tussen de applicatie en MediaMosa. In deze verkenning is niet gekozen om het ingesten vanuit Matterhorn naar MediaMosa mogelijk te maken met een applicatie, omdat dit niet het doel is van deze verkenning. Het uiteindelijke doel is om Matterhorn met MediaMosa te koppelen via de delivery workflow van Matterhorn, direct naar MediaMosa toe; daar zit geen applicatie tussen. Voor de proof of concept opstelling is daarom gekozen om de hieronder beschreven methode te gebruiken. 5.2 FTP bulk Met de FTP bulk tool kan video in MediaMosa geplaatst worden. Hiervoor dient video in een speciaal formaat aangeboden te worden. MediaMosa heeft daarvoor een eigen file formaat gemaakt, een Video Upload File (VUF, extentie.vuf). Uitleg van dit formaat staat op: De proof of concept die is gemaakt is een vertaling van het Atom XML formaat naar het VUF formaat VUF Dit is een template van de vertaling van de gegevens van het Atom formaat in het VUF formaat. Het entry:id wordt gebruikt als <referenceid> van de video. In onderstaand voorbeeld wordt de link naar de video, entry:link:href, opgeslagen als een <external> link in MediaMosa. entry:id.vuf <FTPupload> <videos> <video> <action>save</action> <referenceid>[entry:id]</referenceid> <metadatafile>[entry:id].qdc</metadatafile> <formats> <format> 29

30 <action>save</action> <external>[entry:link:href]</external> <!-- <mediafile>[filename]</mediafile> --> </format> </formats> </video> </videos> </FTPupload> De Metadata wordt als Qualified Dublin Core opgeslagen in MediaMosa. Dit is een mooie match tussen Matterhorn en MediaMosa. Beiden maken gebruiken van de Dublin Core Standaard! Alle velden kunnen daardoor één op één gekopieerd worden. entry:id.qdc <aoi_qdc> <dc:title>entry:dc:title</dc:title> <dc:date>entry:dc:date</dc:date> <dc:identifier>entry:dc:identifier</dc:identifier> </oai_qdc> Met het aanbieden van deze VUF aan MediaMosa is de eerste koppeling tussen Matterhorn en MediaMosa tot stand gekomen! 5.3 AtomPub Bij de vorige methode wordt een vertaling gemaakt van het Atom formaat in het VUF formaat. Deze actie wordt echter geïnitieerd door het vertaal proces. In de uiteindelijke versie moet de actie geïnitieerd worden door de Matterhorn delivery workflow. Op het moment dat een video met Matterhorn is opgenomen moet deze direct afgeleverd worden bij MediaMosa. Op zich zijn de bestaande REST methodes en FTP bulk tool daar ook voor geschikt, maar het zou mooier zijn als MediaMosa kan aansluiten bij een standaard manier van video uploaden. Deze standaard kan worden gevonden in AtomPub. In AtomPub wordt gebruik gemaakt van REST principes om web resources te publiceren en te editen. De bijbehorende metadata wordt gespecificeerd in het Atom formaat. Uitleg van het AtomPub formaat is her te vinden: Hieronder staat een voorbeeld van het AtomPub formaat zoals deze gebruikt wordt voor het uploaden van een video in YouTube. Voor het opslaan van een nieuwe video wordt de POST methode gebruikt. YouTube specificeert als URL: POST /feed/api/users/default/uploads De titel van de video staat in de Slug header: 30

31 Slug: summer_vacation.mp4 In de body van deze POST staat de metadata in het Atom formaat gespecificeerd, met als voorbeeld de category: Travel. Daarnaast staat de video zelf ook in deze body. Voorbeeld gebruik AtomPub door YouTube 31

32 6 Proof of Concept De Proof of Concept omgeving is in twee delen opgebouwd. 6.1 Eerste versie In de eerste test is een vertaling gemaakt van het Matterhorn Atom formaat naar het MediaMosa VUF formaat. Door de volgende URL aan te roepen worden de VUF files dynamisch gegenereerd, vanuit de Atom feed: Voor het Atom response voorbeeld is het resultaat twee files: VUF: MatterhornUpload vuf <FTPupload> <videos> <video> <action>save</action> <referenceid>f0ccd101-ac7f-4315-b173-59d8d87c2577</referenceid> <metadatafile>f0ccd101-ac7f-4315-b173-59d8d87c2577.qdc</metadatafile> <formats> </formats> </video> </videos> </FTPupload> METADATA: f0ccd101-ac7f-4315-b173-59d8d87c2577.qdc <oai_qdc> <dc:title>test_nu_echt_empty</dc:title> <dc:date> t10:49:00z</dc:date> <dc:identifier>f0ccd101-ac7f-4315-b173-59d8d87c2577</dc:identifier> </oai_qdc> Zoals de titel aangeeft: test nu echt empty, is aan deze video geen mediafile verbonden. Daarom is het <format> veld leeg. Een voorbeeld van een video met 4 tracks/mediafiles is: <video> <action>save</action> <referenceid>8bef822f-7fbf b-f f830</referenceid> <metadatafile>8bef822f-7fbf b-f f830.qdc</metadatafile> <formats> <format> <action>save</action> <external> </format> <format> 32

33 <action>save</action> <external> </format> <format> <action>save</action> <external> </format> <format> <action>save</action> <external> </format> </formats> </video> De actie die daarop volgt is het handmatig aanbieden van de getoonde files aan de FTP bulk tool. 6.2 Tweede versie Na verder onderzoek is gebleken dat Matterhorn bij het opnemen van een video ook een ZIP file creëert met daarin alle noodzakelijke bestanden, zoals mediafiles en metadata. Deze bestanden kunnen met de gecreëerde VUF direct doorgestuurd worden naar de FTP bulk tool. De Proof of Concept omgeving zou vervolgens geschikt gemaakt kunnen worden om deze ZIP bestanden automatisch uit te pakken en vervolgens de inhoud ervan op te slaan in MediaMosa. Hierbij kan gebruik worden gemaakt van de Rich Media EGA 14 die door One Shoe 15 ontwikkeld is

34 7 Uitgebreide AtomPub specificatie Om video uit te wisselen moeten er tussen Matterhorn en MediaMosa een aantal afspraken gemaakt worden. De meest voor de hand liggende kapstok waaraan deze afspraken opgehangen kunnen worden is de AtomPub specificatie. Dit betekent dat: Communicatie tussen Matterhorn en MediaMosa op een REST full manier is: o De request is een URL o De response is Atom XML In de REST URL s verschillende methoden worden gebruikt voor verschillende functies: o GET [URL], haalt de gegevens van de betreffende video op o POST [URL], maakt een nieuwe video aan o PUT [URL], bewerk de gegevens van een video o DELETE [URL], verwijdert een video De metadata wordt gespecificeerd in het Atom formaat, o Een belangrijke toevoeging aan het standaard Atom formaat is de Dublin Core specificatie Het AtomPub formaat voorziet niet in de naamgeving van de REST URL s en request. Hiervoor moeten we aansluiting zoeken bij een ander initiatief, zoals CMIS of Open Social. Beiden worden in de volgende paragrafen beschreven. Ook voorziet AtomPub niet in een methode voor authenticatie van de uploader. De methode die daar het meest geschikt voor is, is oauth en dat wordt in paragraaf 8.3 beschreven. 7.1 CMIS In het kader van standaarden voor uitwisselen van gegevens is gekeken naar CMIS. Deze standaard is gemaakt voor het uitwisselen van data tussen enterprise level content management systemen. De CMIS standaard heeft een AtomPub variant waarmee CMIS gegevens uitgewisseld kunnen worden en waar op aangesloten kan worden. De CMIS standaard wordt in het volgende document uitgebreid (229 pagina s) beschreven: CMIS is echter te uitgebreid voor het uitwisselen van gegevens tussen Matterhorn en MediaMosa. De naamgeving die in CMIS gehanteerd wordt voor een resource is overigens obj, afgeleid van object. 34

35 7.2 Open Social Een andere standaard voor uitwisselen van gegevens is Open Social. Open Social is een verzameling API s die gemaakt is voor uitwisseling van persoonsgegevens tussen applicaties. Een uitbreiding op persoonsgegevens in Open Social zijn mediaitems en dat is de verzamelnaam voor afbeeldingen, geluid en video. De mediaitems worden verzameld in Albums, de Open Social variant op een collectie. De API voor mediaitems wordt hier beschreven: Server.xml#MediaItems-Service Voor ophalen van een mediaitem is de volgende URL gespecificeerd: GET /mediaitems/[user-id]/[group-id]/[album-id]/[mediaitem-id] Specificatie GET mediaitems Voor het opslaan van een nieuw item wordt de volgende URL gespecificeerd: POST /mediaitems/[user-id]/@self/[album-id] Specificatie Post mediaitems 35

36 Het dient aanbeveling om bij deze Open Social standaard aan te sluiten voor het ingesten van een video vanuit Matterhorn in MediaMosa. De REST URL wordt dan: POST (als er niet in collectie wordt opgeslagen) Waarbij de USER-ID de identifier van de gebruiker is betekent dat de video van deze gebruiker zelf is. 7.3 oauth Voordat de upload plaats kan vinden moet de gebruiker die de upload doet geauthentiseerd worden in MediaMosa. Authentiseren op webservice niveau kan met de technologie genaamd oauth. Met oauth wordt afgeschermde data gedeeld tussen twee applicaties, zonder dat daarbij user credentials worden uitgewisseld. De eigenaar authentiseert zichzelf op de bron en de cliënt wordt hiervan op de hoogte gebracht. Hierdoor kan een cliënt applicatie gebruik maken van de afgeschermde data in een bron, zoals MediaMosa. Zie voor uitleg hierover de oauth specificaties: 36