Uitbreiding van het PISA-dramaproductiesysteem voor locatieshoots met behulp van PDAs

Uitbreiding van het PISA-dramaproductiesysteem voor locatieshoots met behulp van PDAs Bart Naessens

Promotor: prof. dr. ir. Rik Van de Walle Begeleiders: Dieter Van Rijsselbergen, Barbara Van De Keer Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

Uitbreiding van het PISA-dramaproductiesysteem voor locatieshoots met behulp van PDAs Bart Naessens

Promotor: prof. dr. ir. Rik Van de Walle Begeleiders: Dieter Van Rijsselbergen, Barbara Van De Keer Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2008-2009

Voorwoord Met het schrijven van dit voorwoord rond ik niet alleen deze masterproef af, maar een studie van 5 jaar. Met de keuze voor dit thesisonderwerp kon ik mijn interesse voor informatica combineren met mijn passie voor het maken van films en televisie. Ik heb me kunnen verdiepen in een materie die me sinds jaar en dag boeit. De realisatie van deze masterproef liep echter niet altijd van een leien dakje. Ik heb de verwezenlijking van deze masterproef dan ook te danken aan de hulp en steun van een aantal mensen. Eerst en vooral wil ik mijn promotor, prof. dr. ir. Rik Van de Walle bedanken om deze masterproef mogelijk te maken. Uiteraard hebben ook mijn begeleiders, Dieter Van Rijsselbergen en Barbara Van de Keer, een belangrijke rol gespeeld. Ik dank hen voor hun hulp en in het bijzonder voor hun begrip en antwoorden op mijn vele vragen. Ik bedank ook mijn mijn mama om onvoorwaardelijk in mij te geloven en altijd bereid te zijn om te helpen. Tenslotte bedank ik ook iedereen die, door hun steun, me geholpen heeft deze masterproef tot een goed einde te brengen.

Bart Naessens, augustus 2009

Toelating tot bruikleen “De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”

Bart Naessens, augustus 2009

Uitbreiding van het PISA-dramaproductiesysteem voor locatieshoots met behulp van PDAs door Bart NAESSENS Academiejaar 2008–2009 Promotor: prof. dr. ir. Rik VAN DE WALLE Begeleiders: Dieter VAN RIJSSELBERGEN, Barbara VAN DE KEER Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan VAN CAMPENHOUT

Samenvatting Bij het maken van films en televisieproducties gaan pen en papier nog steeds hand in hand. De opkomst van digitale opnametechnieken en de omschakeling van het tapegebaseerd naar bestandsgebaseerd opnemen opende vele nieuwe mogelijkheden om de huidige manier van werken te verbeteren. Daarom is aan de VRT, in samenwerking met het IBBT, het PISA-project gestart om een digitaal dramaproductieplatform te ontwikkelen met een volledig ge¨ıntegreerde workflow. Bij de huidige implementatie is het echter nog niet mogelijk dit systeem in te zetten bij opnames op locatie. In deze masterproef wordt een uitbreiding voor dit systeem ontwikkeld waarbij gebruik wordt gemaakt van PDA’s. Er wordt een architectuur voorgesteld en een proof of concept ontwikkeld. Tenslotte is die proof of concept grondig getest op een echt mobiel toestel, en worden er een aantal conclusies getrokken.

Trefwoorden PISA, dramaproductie, locatieshoots, PDA, Flash Lite.

Extension of the PISA-drama production system for location shoots using PDAs Bart Naessens Supervisor(s): prof. dr. ir. Rik Van de Walle Abstract— Up to this day, inefficient pen-and-paperwork are not far away when shooting films and television productions. The evolution from tape-based to file-based recording introduces many advantages to create a much more efficient workflow. In order to embrace all the advantages, the VRT started the PISA-project in cooperation with the IBBT to create a centralized drama production application. The current implementation is however not ready to be used on location. In this abstract, a solution is described to use the application from a handheld device as a PDA. An architecture was constructed and a proof of concept developed. Finally the proof of concept was tested and conclusions were drawn. Keywords—PISA, drama production, location shoots, PDA, Flash Lite.

I. I NTRODUCTION The switch from tape-based recording to file-based recording announced the computerization of the entire drama production process. The purpose of the PISA-project [1] is to fully benefit from those new possibilities by creating a centralized drama production system with an integrated (paperless) workflow. At this moment there are functions available to view and edit scenarios, integration with a 3D-previz application for shooting scripts and storyboards, an acquisition application to start and stop the recordings, enter the continuity reports, and more. The current implementation can be used in a controlled studio environment. The fact that it is not yet possible to use the application while on location, creates an inconsistent workflow: the integrated application in the studio, paperwork and log reports on location. II. S OLUTION

for the shot, starting and stopping the recording, and submitting the continuity report to the PISA-drama production server. The second function is a viewing application for scenarios. Many more functions are possible, but are based on the same principle - sending and displaying information - or require video functionality (e.g. to review recorded takes). The video functions were omitted because of insufficient support of the mobile frameworks. First we look closer at the architecture used to create this extension. From there on we see how a proof of concept was implemented and tested. To conclude this article, a few conclusions were drawn. III. A RCHITECTURE In order to relief the handheld device from too many processing actions, PDAservices were created as intermediary between the device and the PISA-drama production server and the ingest server. The ingest server captures the data and manages the connected cameras and microphones. The PDAservices are basically traditional webservices using HTTP and SOAP, who offer specific functions and data for the mobile application. They fetch, merge and process data from the PISA-drama production server so only the essential information can be sent to the mobile device. The PISA-drama production system uses REST-services as the interface to external applications. All information is exchanged in XML-format. The setup is given in Figure 2.

As solution, an extension is introduced to the current PISAdrama production system which allows the application to be used from a handheld device, such as a PDA or cellphone. This way the workflow stays consistent, and the users get more freedom to move around on set - which can also be useful in the studio. The mobile devices communicate with a PISA-drama production server available on set through WiFi. Once back in the studio, the PISA-drama production servers are synchronized. Figure 1 gives an overview.

Fig. 2. Setup for the PISA-drama production system for use with a PDA Fig. 1. Overview of the suggested solution

A proof of concept was developed which initially supports two main functions. The first function is the acquisition application, which allows selecting the cameras and microphones

The application on the mobile device was conceived as a stand alone application. Although the desired functionality can also be realised through a web application, a stand alone version offers more efficiency and advantages for later extensions. For

instance, a stand alone application can work offline as there is no continous network connection needed with the PISA-drama production server. To develop the stand alone application, many frameworks were considered. The Flash Lite [4] framework was eventually chosen over Java ME, because of the powerful graphics and animations. Also the integration with Adobe Device Central [5], an extensive test application for mobile content, was considered a plus.

% used memory Battery status

IV. I MPLEMENTATION The PDAservices are implemented in Java. They use the JDom-library [6] for handling XML documents and HttpClient [7] for the interaction with the PISA-drama production server through REST-services. The Flash Lite application is implemented according to a timeline based approach, which introduces a whole new style of developing. With a timeline based approach every important programme state has a KeyFrame labelled on the timeline. Actions, such as events or user input, cause the transitions between KeyFrames and thereby changing the programme state. A frame can contain code, which is then executed every time the frame is played. In this implementation there are KeyFrames labelled for when the episodes are loaded, when a recording has started, a scenario is ready to be rendered, and so on. The code had to be written in the previous version of ActionScript, version 2.0. This implied searching for some workarounds to overcome some bugs, and didn’t support some handy libraries such as E4X for easy XML handling. Eventually a solution was found for every problem, resulting in a fully functional portable application. Only the communication with the ingest server to start and stop the actual recordings is not yet implemented. A dummy implementation is used instead. During implementation, there was much attention paid to usability and stability. A user-friendly interface was created, and occasional errors are handled gracefully. Remaining battery time and memory usage are displayed so that users can anticipate possible failures. A screenshot is given in Figure 3. V. T ESTING Initially the portable application was tested in Adobe Device Central, a testsuite to emulate Flash content on a range of mobile devices. This gave a good first impression how the application behaves on a mobile device. Most bugs were discovered during this step. Afterwards, the application was also thoroughly tested on a real PDA. The usability was evaluated, performance and memory usage were measured, and some failures (e.g. loss of network connection) were simulated. The overall performance is good, only the steps where a DataGrid (to display a list) and ComboBoxes are displayed take a little too much time (and memory). VI. C ONCLUSIONS This article described the study that was undertaken to realise a portable extension to the current PISA-drama production system. During implementation, lots of problems were encountered

Navigation buttons Fig. 3. User interface of the portable PISA-drama application

regarding the implementation in Flash Lite. The new programming style, lack of decent information and numerous bugs had to be conquered. The resulting portable application is easy to use, has a polished interface, and shows the possibilities it can offer to the various people on set. With small improvements (e.g. the communication with the ingest server) the application can be used in a real production environment. Also later additions are possible with the current implementation in Flash Lite. R EFERENCES [1] Pisa. http://www.vrtmedialab.be/index.php/nederlands/ project/project_p_pisa/. [2] D. Van Rijsselbergen, M. Verwaest, B. Van de Keer and R. Van de Walle, Introducing the data model for a centralized drama production system, Multimedia and Expo, 2007 IEEE International Conference, pp. 615-618, Beijing, China, 2-5 Jul. 2007. [3] D. Van Rijsselbergen and B. Van de Keer, Drama Application Architecture PoC2. 2006. unpublished. [4] Adobe Flash Lite. http://www.adobe.com/products/flashlite/. [5] Adobe Device Central. http://www.adobe.com/nl/products/creativesuite/ devicecentral/. [6] JDom. http://www.jdom.org/. [7] HttpClient. http://hc.apache.org/httpclient-3.x/.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

2 Literatuurstudie

4

2.1

2.2

2.3

Televisie- en filmproductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

De preproductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

De opnames en postproductie . . . . . . . . . . . . . . . . . . . . . . . . .

6

Het PISA-project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Gelijkaardige projecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3.1

Improving workflow in practice for low-cost programme-making using MXF & AAF file formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3.2

Floorman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.3

EVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3 Probleemstelling

11

3.1

Beperking huidig PISA-project . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.2

Oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.2.1

Mobiele functies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.2.2

Functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.2.3

Kwalitatieve vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4 Architectuur 4.1

18

Architectuur van het huidige PISA-project . . . . . . . . . . . . . . . . . . . . . .

18

4.1.1

Het Episode Object Model . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1.2

REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.1.3

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

INHOUDSOPGAVE

4.1.4 4.2

4.3

4.4

Query’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

Ontwerpsbeslissingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2.1

Stand alone of webapplicatie . . . . . . . . . . . . . . . . . . . . . . . . .

25

Applicatieraamwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3.1

Microsoft Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.3.2

QT Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.3.3

Google Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.3.4

.NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.3.5

Java platform, Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.3.6

Adobe Flash Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.3.7

IPod Touch & IPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.3.8

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

Architectuur voor de mobiele uitbreiding . . . . . . . . . . . . . . . . . . . . . . .

33

4.4.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.4.2

PDAservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.4.3

Objectgeoriënteerd ontwerp voor de mobiele PISA-applicatie . . . . . . .

36

4.4.4

Dynamisch ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5 Implementatie 5.1

5.2

ii

48

PDAservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.1.1

Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

De mobiele PISA-applicatie in Flash Lite . . . . . . . . . . . . . . . . . . . . . .

52

5.2.1

Structureren van een Flash-applicatie . . . . . . . . . . . . . . . . . . . .

52

5.2.2

Ontwerp van de gebruikersinterface . . . . . . . . . . . . . . . . . . . . . .

54

5.2.3

Realisatie van de mobiele PISA-applicatie in Flash Lite . . . . . . . . . .

55

5.2.4

Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6 Installatie en uitvoering op een PDA

66

6.1

Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.2

Uitvoering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.2.1

Vaststellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.2.2

Mogelijke verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

INHOUDSOPGAVE

7 Overschouwingen

iii

73

7.1

Programmeren in Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

7.2

Programmeren voor mobiele toestellen . . . . . . . . . . . . . . . . . . . . . . . .

76

8 Besluit

77

Bibliografie

79

Lijst van figuren

85

Lijst van tabellen

87

INLEIDING

1

Hoofdstuk 1

Inleiding In de wereld van film en televisie gaan pen en papier nog steeds hand in hand. Scenario’s, opnamevoorbereidingen, draaiboek, logboek, call sheets, continu¨ıteitsrapporten, . . . alles wordt veelal manueel opgeschreven en talloze keren overgepend, met fouten tot gevolg. Films en televisie maken is dan ook een zeer veeleisende en complexe taak. Zo werd bijvoorbeeld tijdens de opnames van The Lord of the Rings-trilogie op bepaalde momenten gebruik gemaakt van niet minder dan zeven units 1 [36]. Die units produceren tientallen takes en tientallen minuten film per dag. We zien dit ook in de televisiewereld, waar soaps en telenovelles aan een hels tempo ingeblikt worden - tot meer dan 1 volledige aflevering per dag. Ter vergelijking: voor film rekent men doorgaans gemiddeld 1 draaidag voor 1 minuut effectieve film, voor televisie 1 dag voor 4 ` a 5 minuten televisie. Het hoeft geen betoog dat het in alle gevallen erg belangrijk is het overzicht te behouden over de opnames. Van elke opgenomen take moet bijgehouden worden op welke filmrol of filmcassette de opname is gemaakt. Er moet een continu¨ıteitsrapport voor gemaakt worden. Alle beelden moeten worden bekeken en beoordeeld door de regisseur. Ook worden vaak op het allerlaatste moment nog aanpassingen gemaakt aan het scenario of worden er dialogen herschreven. Al die informatie moet op een juiste en consistente manier worden bijgehouden. Op die manier kan ook het postproductieteam makkelijk werken en wordt er geen tijd verloren met zoeken naar het juiste beeldmateriaal en doorworstelen van allerhande paperassen. Een evolutie die een cruciale rol speelt om al deze informatie makkelijker te verwerken en te beheren is de opkomst van digitale opnametechnieken en het bestandsgebaseerd opnemen. De overschakeling van tapegebaseerd naar bestandsgebaseerd opnemen brengt immers heel wat 1

Een unit is een volwaardig opname-team dat aanvullende opnames maakt voor een film- of televisieproductie

INLEIDING

2

voordelen met zich mee. Allereerst kan het beeldmateriaal nu veel sneller dan real-time worden ingelezen. Met cassettes duurde het inladen van 1 uur beeldmateriaal in het montagestation ook 1 uur. Door bestandsgebaseerd te werken kan dit in slechts enkele minuten worden ingelezen. De opnames worden opgeslagen op een centraal digitaal platform, waardoor het onmiddellijk beschikbaar wordt gesteld voor alle medewerkers. Een ander voordeel is dat meerdere personen gelijktijdig met hetzelfde beeldmateriaal aan de slag kunnen. Zo kan een opgenomen interview gemonteerd worden voor een item in het journaal, en gelijktijdig bewerkt worden voor een documentaire. Het wordt eveneens makkelijker om alle informatie over de opnames (metadata) effectief te linken aan het eigenlijke beeldmateriaal. De opslag en bewaring van het materiaal wordt goedkoper en betrouwbaarder (door niet meer met tapes te werken is er geen probleem meer met tape rot), en met een goede netwerkinfrastructuur wordt al het mediamateriaal overal beschikbaar. Door op die manier een gecentraliseerd systeem te realiseren dat volledig afgestemd is op een optimale workflow, waarbij alle gegevens rechtstreeks in het systeem worden ingebracht, verkrijgen we een vermindering van de administratieve rompslomp. Dit zal er dus met andere woorden voor zorgen dat er sneller, overzichtelijker en efficiënter kan gewerkt worden. Om bijgevolg alle voordelen die computersystemen bieden uit te buiten in de broadcast-wereld, is aan de VRT het PISA-project opgestart in samenwerking met het IBBT [25]. PISA [81] staat voor Production, Indexing and Search of Audio-visual Material. In het PISA-project wordt in de eerste plaats onderzocht hoe het Product Engineering proces kan geoptimaliseerd worden, waarbij vertrokken wordt vanuit de notie van een virtueel model. Zo kunnen ambachtelijke methodes tijdens de eigenlijke productie worden vermeden, kan een hoger rendement gehaald worden en kan de kwaliteit van het product alleen maar beter worden. In het bijzonder wordt hierbij gedacht aan doorgedreven vormen van automatisering van het invoerproces, de opname en eventueel de montage. Onder de scope van het PISA-project valt ook het omgekeerde traject: het archiveren of de “Reverse Engineering” van audiovisueel materiaal. Hierbij wordt onderzocht in welke mate de klassieke beeldanalyse, meestal gebaseerd op zuivere signaalverwerking, kan verbeterd worden wanneer wordt uitgegaan van een modelmatige benadering. Hierbij wordt gebruik gemaakt van biometrische gezichtsherkenning, spraakherkenning, shotdetectie, enzovoort. Als laatste topic wordt onderzocht hoe er krachtige zoekmachines kunnen gebouwd worden wanneer beschikt wordt over een mediatheek waarvan de items objectief en intelligent geanalyseerd zijn. Wanneer de achtergronden, de tijd, de personages en de objecten reeds zijn ge¨ıdentificeerd, kunnen we

INLEIDING

3

in plaats van te werken op basis van een eenvoudig en eendimensionaal classificatiesysteem of thesaurus een gestructureerde databank creëren die genormaliseerd is in tijd en ruimte. Deze laatste zijn echter minder relevant voor het vervolg van deze masterproef, en worden daarom verder buiten beschouwing gelaten. De partners die in PISA samenwerkten zijn VRT-medialab [44], Eyetronics [19], KULAK [31], PSI-K.U.Leuven [30], ETRO-VUB [15], MMLab-UGent [32] en EDM-UHasselt [18]. In deze masterproef wordt een uitbreiding voor dit project voorgesteld. Op dit moment is het PISA-project reeds inzetbaar in een studio-omgeving, maar is het nog niet geschikt om ook op locatie te worden ingezet. Daarom zou het handiger zijn als het systeem ook bediend kon worden vanop een handheld toestel zoals een PDA, wat het platform een stuk mobieler maakt. Alvorens daar dieper op in te gaan wordt eerst bekeken hoe zo’n dramaproductie wordt gerealiseerd. Daarna volgt een overzicht van het huidige PISA-project, en wordt er een mogelijke mobiele uitbreiding van dit systeem voorgesteld. In de daarop volgende hoofdstukken wordt bekeken hoe die uitbreiding precies tot stand is gekomen aan de hand van de huidige implementatie. Tenslotte ronden een aantal overschouwingen en het besluit deze masterproef af.

LITERATUURSTUDIE

4

Hoofdstuk 2

Literatuurstudie In dit hoofdstuk wordt eerst meer uitleg gegeven over hoe televisie- en filmproducties worden gerealiseerd (sectie 2.1). In sectie 2.2 wordt het huidige PISA-project nader toegelicht. Tenslotte worden in sectie 2.3 een aantal gelijkaardige projecten besproken.

2.1

Televisie- en filmproductie

De productie van televisie en film, waar deze masterproef zich afspeelt, is een wereld op zich. Het is dan ook essentieel om een beeld te hebben hoe een fictieproductie tot stand komt. In de volgende paragrafen wordt daarom een beknopt overzicht gegeven. Voor meer informatie en duiding wordt verwezen naar [49] [53] [69].

2.1.1

De preproductie

Veel producers beschouwen de preproductie als de belangrijkste fase in het hele proces, omdat een goede voorbereiding later tijd en geld zal uitsparen. Het begint allemaal met een idee: de eerste aanzet tot het maken van een film of televisieserie. Dit idee wordt verder uitgewerkt tot een synopsis. Een synopsis is een gedetailleerde omschrijving van de inhoud en het dramatisch verloop van een scenario. Eens de structuur en opbouw van het verhaal goed zitten wordt, wordt het scenario uitgewerkt. In het scenario zijn alle dialogen, beeldovergangen en scènes uitgeschreven. Figuur 2.1 geeft een voorbeeld van een scenario. Eens het scenario al behoorlijk opgeschoten is, kan het verhaal verder visueel worden uitgewerkt, wat resulteert in het draaiboek of Shooting Script. Hierbij wordt elke scène omgezet in beeld

2.1 Televisie- en filmproductie

5

Figuur 2.1: Ingekorte scène uit het scenario van The Bourne Ultimatum

en geluid. Aan de hand van een plattegrond van de locatie worden de camerastandpunten en opnamehoeken bepaald, de plaatsing van de belichting en rekwisieten, enzovoort. De scènes worden opgesplitst in shots waarbij de beeldgrootte, camerabewegingen en perspectief worden bepaald. Eventueel wordt van bepaalde scènes ook een storyboard gemaakt: een serie tekeningen die de kadrage en fotografie van de verschillende shots illustreren (figuur 2.2). Tegenwoordig wordt er vaak nog een stapje verder gegaan en worden van meer en meer scènes 3D-previews gemaakt, die toelaten scènes tot in de kleinste details voor te bereiden. Vaak merkt men op die manier sneller mogelijke problemen op. 3D-previews vergemakkelijken ook de communicatie tussen de regisseur, acteurs en technici. Wanneer het draaiboek is afgewerkt, wordt de opnameplanning opgesteld. Hiervoor wordt het script overlopen en per scène opgelijst welke acteurs, rekwisieten, materiaal en technici er nodig zijn. Er wordt beslist welke scènes op locaties worden opgenomen en welke in de studio, en hoeveel draaidagen ervoor nodig zijn. Afhankelijk van het budget worden hier en daar nog aanpassingen gemaakt aan het scenario.

2.1 Televisie- en filmproductie

6

Figuur 2.2: Voorbeeld van een storyboard uit The Lord of the Rings

Om een efficiënte opnameplanning op te stellen wordt gebruik gemaakt van een planningsysteem. Zo’n planningssysteem probeert aan de hand van de beschikbare gegevens de draaidagen zo efficiënt mogelijk te organiseren. Daarbij wordt rekening gehouden met de beschikbaarheid van de acteurs, crew, materiaal, locaties, enzovoort. Per medewerker worden automatisch call sheets aangemaakt. Deze beschrijven wat er vereist is op elke opnamedag: personages, rekwisieten, kostuums, effecten, apparatuur, maar ook de essentiële telefoonnummers, adressen, wegbeschrijvingen, transportregelingen en - van vitaal belang - de call times of oproeptijden waarop men aanwezig moet zijn op de set of in de make-up.

2.1.2

De opnames en postproductie

Tijdens de opnames wordt een uitgebreid logboek bijgehouden met alle takes. Om de continu¨ıteit te garanderen worden de kostuums van de acteurs beschreven, de kwaliteit en richting van het licht, plaatsing van de rekwisieten, enzovoort. Deze informatie is belangrijk als verschillende delen van eenzelfde scène op andere tijdstippen worden opgenomen. Er wordt bijgehouden wat goed en fout was aan elke take, welke camera-instellingen er gebruikt zijn, op welke filmcassette of -rol de take is opgenomen en de tijdscodes waar de take begint en eindigt. Voor de monteur is

2.2 Het PISA-project

7

dit noodzakelijke informatie om te bepalen welke shots in de montage gebruikt kunnen worden, en waar die te vinden zijn. De monteur laadt aan de hand van de continu¨ıteitsrapporten de juiste beelden in voor de montage. Na de beeldmontage worden eventueel nog special effects en kleurcorrecties toegevoegd. De geluidsmontage en -mixage ronden het productieproces af.

2.2

Het PISA-project

Bij de productie van audiovisueel materiaal wordt op dit ogenblik nog weinig of geen gebruik gemaakt van virtuele (computer)modellen. Toch staat de techniek ver genoeg om instrumenten te ontwikkelen die mediabedrijven concreet helpen productiever en creatiever te produceren. Bij het IBBT PISA-project is het de bedoeling een groot deel van de productieworkflow te integreren door een volledig ge¨ıntegreerd digitaal productieplatform te creëren. Het schrijven en beheren van de scenario’s en draaiboeken, de continu¨ıteitsrapporten, het bekijken van 3Dpreviews van scènes, het beheer van opgenomen beeldmateriaal, . . . het wordt allemaal mogelijk met een ge¨ıntegreerd systeem. Het is in de eerste plaats de bedoeling om het huidige productieproces zo goed mogelijk te ondersteunen. In de toekomst kan het platform uitgebreid worden om complexere taken te automatiseren. Zo zou het bijvoorbeeld mogelijk worden om op basis van de op voorhand gecreëerde 3D-scènes automatisch een montage maken met de echte beelden. Figuur 2.3 geeft een schermafbeelding van deze 3D-previsualisatie applicatie Scoop, waarmee de scènes in detail worden voorbereid [72] [82]. Met de huidige manier van werken is dat onmogelijk, maar met de nieuwe aanpak is er een pak meer informatie over elke opname bekend: van welke scène en shot het een opname is, welke personages er in beeld zijn, wat er precies wordt gezegd, enzovoort. Daardoor wordt het in de toekomst mogelijk om met de bestaande spraak- en gezichtsherkenningstechnologieën automatisch een eerste (ruwe) montage te maken. Een tweede voorbeeld is het automatisch herschalen van de beelden. De beelden worden aan een zeer hoge resolutie opgenomen. Als men een aflevering wil bekijken op een draagbaar toestel (wat in de nabije toekomst alleen maar zal toenemen), met een veel lagere schermresolutie, volstaat het niet om het grote High Defenition beeld te verkleinen tot een (veel) kleinere resolutie. Het resultaat zou op die manier helemaal niet duidelijk zijn. Beter is een intelligente uitsnede te maken van het interessantste stuk van

2.2 Het PISA-project

8

Figuur 2.3: Schermafbeelding van de 3D-previsualisatie applicatie Scoop

het beeld, zodat aan duidelijkheid niet wordt ingeboet. Doordat alle informatie over de scènes en het beeldmateriaal aanwezig is in het systeem, kan dit proces sterk geautomatiseerd worden.

2.2.1

Functionaliteit

Het PISA-dramaproductiesysteem bevat reeds een hoop functies. Een korte opsomming van de belangrijkste functionaliteiten: • Bekijken, aanmaken en wijzigen van synopsissen • Bekijken, aanmaken en wijzigen van scenario’s • Zoekfuncties

2.3 Gelijkaardige projecten

9

• Integratie met de 3D-previsualisatie applicatie voor de draaiboeken en storyboards • Acquisitie-applicatie voor het starten en stoppen van opnames en het invoeren van continu¨ıteitsrapporten • EDL1 -beheer en integratie met AVID2 -systemen • Integratie met Ardome, het mediamanagementsysteem van de VRT

2.3

Gelijkaardige projecten

Niet alleen aan de VRT wordt er fors ingezet op bestandsgebaseerde mediaproductie. Ook bij andere omroepen, en met name de British Broadcasting Corporation (BBC), lopen daarover verschillende projecten.

2.3.1

Improving workflow in practice for low-cost programme-making using MXF & AAF file formats

Deze paper [77], gepubliceerd in 2006, beschrijft een zo goedkoop mogelijk multikanaals ingestsysteem. Waar mogelijk wordt open bron software gebruikt. Door gebruik te maken van gestandaardiseerde bestandsformaten is het succesvol ge¨ıntegreerd met bestaande montageapparatuur. Voor de videobestanden wordt het MXF3 -formaat gebruikt, voor metadata het AAF4 -formaat. Het systeem is succesvol ingezet bij de productie van BAMZOOKi, een kinderprogramma [48]. De beelden van de drie camera’s worden afzonderlijk opgenomen op de ingestserver in verschillende formaten. Naast de ongecomprimeerde versie wordt ook een versie voor DVD en het web gecreëerd. De montagebeslissingen die de regisseur al tijdens de opname nam worden vastgelegd in een ALE5 -bestand, enigszins vergelijkbaar met een EDL-bestand. Na elke take geeft de productieassistent in of de take goed of slecht was en waarom. Aan het einde van de opnames 1

Edit Decision List. Het is een manier om een gemonteerde film of video voor te stellen aan de hand van een

lijst met tijdscodes die aangeven waar elke shot begint en eindigt. 2 Avid is marktleider op het gebied van digitale niet-lineaire montagesystemen. De naam wordt hiervoor vaak veralgemenend gebruikt. 3 Material Exchange Format. Een container formaat gebruikt voor de opslag van professionele digitale video. 4 Advanced Authoring Format. Standaard bestandsformaat voor de uitwisseling van verschillende soorten metadata. 5 Avid Log Exchange. Formaat voor het uitwisselen van video logging data.

2.3 Gelijkaardige projecten

10

creëert de ingestserver automatisch een DVD met alle goede takes, en een quad-split van de drie camera’s en de eerste montage. Met die DVD kan de regisseur makkelijk de definitieve montage voorbereiden. De videobestanden kunnen snel (zonder tapes) worden ingeladen in de AVID voor de finale montage. De resultaten van het dit project toonden duidelijk aan dat een tapeless gebaseerde productie significante voordelen biedt voor zowel de kostprijs als de efficiëntie van de workflow. Gestimuleerd door deze resultaten is het systeem later verder uitgebreid met een mediaserver en ondersteuning voor verschillende montagesystemen en bestandsformaten [59].

2.3.2

Floorman

Floorman [55] is een project uit 2005 dat ervoor zorgt dat iedereen de beelden van alle camera’s kan bekijken op een draagbaar toestel, waar ze zich ook bevinden op de set. De beelden van de camera’s worden gecomprimeerd en gecombineerd tot een moza¨ıekbeeld. De gecomprimeerde beelden worden uitgezonden via DVB-T6 naar de draagbare toestellen. Dit concept is uitermate handig bij grote, complexe scènes. Het laat de regisseur toe vrij te bewegen op de set en makkelijker te regisseren terwijl hij steeds de camerabeelden in het oog kan houden. Dit concept is zowel toepasbaar in de studio als op locatie.

2.3.3

EVS

EVS [17] is wereldleider op vlak van digitale video productiesystemen. Hun XT[2] productie servers voor de opname, beheer, en het afspelen van professionele digitale video worden aanzien als dé standaard in de broadcast-wereld. Ze bieden alle apparatuur aan voor een tapeloze productieomgeving. Zo installeerden ze een volledige tapeless productieomgeving voor de productie van drama en entertainment bij TVB, de grootste commerciële zender in Hong Kong [56]. EVS heeft echter nog geen mobiele toepassingen van zijn producten voor een smartphone of PDA.

6

Digital Video Broadcasting - Terrestrial. Het is de open standaard voor uitzending van digitale video met

behulp van zendmasten.

PROBLEEMSTELLING

11

Hoofdstuk 3

Probleemstelling In het vorige hoofdstuk is uitgelegd hoe een dramaproductie wordt gerealiseerd en werd een overzicht gegeven van het huidige PISA-project. In dit hoofdstuk wordt de probleemstelling geschetst (sectie 3.1) en wordt de oplossing beschreven die in deze masterproef zal worden uitgewerkt (sectie 3.2).

3.1

Beperking huidig PISA-project

Een tekortkoming aan het huidige project is dat het moeilijk inzetbaar is op locatie. Men is op dit moment immers gebonden aan een computer/laptop met volwaardige browser en Javaomgeving. Het zou makkelijker zijn als de PISA-applicaties ook vanop een draagbaar toestel gebruikt konden worden - denk bijvoorbeeld aan de voordelen van BBC’s Floorman-project: als de regisseur rondloopt op de set, kan de regie-assistent(e) of de scriptgirl aan z’n zijde blijven voor het invoeren van de continu¨ıteitsrapporten, wijzigingen aan het scenario of andere opmerkingen. Ook andere productiemedewerkers kunnen hiervan gebruikmaken om scenario’s te lezen, informatie op te zoeken en opmerkingen toe te voegen. Doordat het PISA-project op dit moment nog niet inzetbaar is op locatie zorgt dit ook voor een inconsistente workflow: na de opnames op locatie zitten we terug met een stapel papier, die manueel moet worden verwerkt. Ook dit probleem wordt verholpen met een uitbreiding voor draagbare toestellen.

3.2 Oplossing

3.2

12

Oplossing

Wat wordt voorgesteld is een uitbreiding te maken die het toelaat het systeem te bedienen vanop een PDA. Er blijft wel ter plaatse een mobiele productieserver nodig waarmee de PDA’s draadloos communiceren. Die communicatie zal gebeuren via WiFi; het is de eenvoudigste oplossing, en bovendien is elke moderne PDA of smartphone uitgerust met een WiFi-ontvanger. Eenmaal terug in de studio worden de productieservers met elkaar gesynchroniseerd. Figuur 3.1 geeft dit schematisch weer.

Figuur 3.1: Overzicht van de voorgestelde oplossing

3.2.1

Mobiele functies

Er zijn heel wat nuttige functies denkbaar voor het gebruik op een PDA: • Bekijken en aanpassen van synopsis, scenario, draaiboek • Plattegrond of set-up van de scène bekijken (plaatsing van camera’s, micro’s, belichting) • 3D-preview van de scène bekijken • Toevoegen van continu¨ıteitsrapporten • Nota’s toevoegen m.b.t. camera-instellingen, montage, belichting, geluid, effecten, acteursregie, rekwisieten, . . . • Herbekijken van (pas)-opgenomen scènes • Bekijken van een lage resolutie versie van een opgenomen scène voor het aanduiden van interessante punten (cuepoints) voor de montage, effecten,...

3.2 Oplossing

13

De regisseur is verantwoordelijk voor het volledige creatieve proces, en neemt alle eindbeslissingen. Elke wijziging aan het scenario, storyboard, de camera-opstelling, montage, . . . moet door de regisseur worden goedgekeurd. Daarom zou bij veel van deze functies een status kunnen toegevoegd worden die aangeeft of de laatste wijzigingen al zijn goedgekeurd door de regisseur. Integratie met het planningsysteem (zie ook sectie 2.1.1) is in het PISA-project nog niet mogelijk. Functies zoals het opvragen van callsheets en het bekijken van de productieplanning (bijvoorbeeld kan de opname van een scène die vandaag niet gedraaid kon worden naar morgen verplaatst worden ?) zijn daardoor, ondanks hun meerwaarde, niet mogelijk.

3.2.2

Functionele vereisten

Niet alle opgesomde functies zullen worden uitgewerkt in deze scriptie. Het wordt beperkt tot een proof of concept waarbij twee belangrijke functies worden uitgewerkt: de opnamefunctionaliteit met het toevoegen van continu¨ıteitsrapporten, en het bekijken van scenario’s. De overige functies zijn eerder analoog (toevoegen/bekijken van informatie) of vereisen videofunctionaliteit op de PDA (herbekijken van shots, 3D-previews). De videofunctionaliteit werd op het moment dat de ontwerpsbeslissingen werden genomen (november 2008) nog niet voldoende ondersteund door de beschikbare mobiele ontwikkelingsplatformen1 . De applicatie wordt opgevat als volgt. Bij het starten krijgt men een beginscherm met daarin drie mogelijkheden: Acquisitie, Scenario en Settings. Onder settings kan men de URL opgeven waar het PISA-dramaproductiesysteem draait. Dit kan later nog uitgebreid worden met andere instellingen. De andere twee functies worden hieronder besproken.

Bekijken Scenario’s Het scenario voor het bekijken van scenario’s verloopt als volgt: 1. De gebruiker kiest voor de Scenario-optie in het hoofdmenu 2. Het laadscherm verschijnt terwijl gegevens worden opgehaald 3. Van elke aflevering wordt id, serie, titel en status weergegeven. De gebruiker selecteert de gewenste aflevering in de lijst en klikt op ‘Select Episode’. 1

zie ook hoofdstuk 4: Architectuur

3.2 Oplossing

14

4. Het laadscherm verschijnt terwijl gegevens worden opgehaald 5. Het scenario wordt opgemaakt weergegeven in een tekstveld. Bovenaan staat de titel met er naast het logo van de betreffende televisieserie.

Precondities

De applicatie is succesvol ge¨ınstalleerd en gestart op de PDA, er is een werkende

actieve WiFi-verbinding met de PDAservices, de PDAservices hebben toegang tot de PISAdramaproductieserver (de PDAservices worden beschreven in hoofdstuk 4).

Postcondities

Extensies

Geen

Bij stap 2,4 treedt er een fout op bij het laden van gegevens. Er wordt dan een

foutmelding weergegeven. Na een druk op de ok-knop wordt teruggegaan naar de vorige stap. Tijdens deze stappen is er een cancel-knop zichtbaar om het laden af te breken. Ook dan wordt teruggegaan naar de vorige stap. Figuur 3.2 geeft een voorbeeld van de weergave van een scenario in het PISA-project.

Figuur 3.2: Weergave van een scenario in het PISA-dramaproductiesysteem

Opnamefunctionaliteit en continu¨ıteitsrapporten Deze functie is iets complexer dan het weergeven van een scenario. Het opgenomen beeldmateriaal moet gematcht worden met de ingegeven continu¨ıteitsrapporten. De beste oplossing daarvoor

3.2 Oplossing

15

is dat de scriptgirl die de rapporten invoert, ook de opnames start en stopt op de camera’s. Dit zorgt ervoor dat het rapport al gelinkt is met de beelden die worden opgenomen. De camera’s zijn via FTP verbonden met de ingestserver waarop de beelden worden opgeslagen. Via die connectie zou ook het starten stopcommando kunnen worden gegeven. Dit zou dus ook kunnen gebeuren vanop een mobiel toestel. Echt noodzakelijk is dit echter niet - de beelden kunnen later aan de rapporten gelinkt worden met behulp van de tijdscodes waarop ze zijn aangemaakt, eventueel met een kleine manuele tussenkomst. Er is dus in ieder geval informatie nodig met welke camera’s en microfoons de opname is gemaakt. Het scenario verloopt als volgt. 1. De gebruiker kiest voor de Acquisitie-optie in het hoofdmenu 2. Het laadscherm verschijnt terwijl gegevens worden opgehaald 3. De gebruiker kiest de gewenste aflevering uit de lijst. Van elke aflevering wordt id, serie, titel en status weergegeven. 4. Het laadscherm verschijnt terwijl gegevens worden opgehaald 5. De gebruiker kiest de gewenste scène uit de lijst. Van elke scène wordt id, volgnummer en locatie weergegeven. 6. Het laadscherm verschijnt terwijl gegevens worden opgehaald 7. De gebruiker kiest de gewenste shot uit de lijst. Van elke shot wordt id, naam en beschrijving weergegeven. 8. De beschikbare camera’s en microfoons worden weergegeven waarmee de shot wordt gerealiseerd. De gebruiker kiest de gewenste devices in de daarvoor weergegeven ComboBoxen. 9. Op het volgende scherm wordt een chronometer weergegeven met een opname- en stopknop. De gebruiker klikt op de startknop. 10. Het laadscherm verschijnt terwijl het startopnameverzoek wordt verstuurd. 11. De chronometer loopt. De gebruiker klikt na verloop van tijd op de stopknop. 12. Het laadscherm verschijnt terwijl het stopopnameverzoek wordt verstuurd.

3.2 Oplossing

16

13. Vervolgens kan het continu¨ıteitsrapport worden ingevoerd. Er wordt een algemene logboodschap en ‘Good Shot Indicator’ (GSI) opgegeven. De GSI geeft met een classificatie aan hoe goed de opname was: Excellent, usable, interesting of bad material. • Per camera en per microfoon kan een specifieke logboodschap en GSI worden opgegeven. Gebeurt dit niet, dan wordt de algemene logboodschap en GSI hier ingevuld. 14. Het laadscherm verschijnt terwijl het continu¨ıteitsrapport wordt opgestuurd naar de PISAdramaproductieserver. 15. Er verschijnt een scherm met keuzemogelijkheden: een nieuwe take met dezelfde opstelling, wijzigen van de set-up, shot, scène of aflevering, of terug naar het beginscherm.

Precondities

De applicatie is succesvol ge¨ınstalleerd en gestart op de PDA, er is een werkende

actieve WiFi-verbinding met de PDAservices, de PDAservices hebben toegang tot de PISAdramaproductieserver.

Postcondities

Het continu¨ıteitsrapport is succesvol opgeslagen op de PISA-dramaproductie-

server.

Extensies

Bij stap 2,4,6,10,12,14 kan er een fout optreden bij het verzenden/ontvangen van

gegevens. Er wordt dan een foutmelding weergegeven. Na een druk op de ok-knop wordt teruggegaan naar de vorige stap. Tijdens deze stappen is er tevens een cancel-knop zichtbaar om het laden af te breken. Ook dan wordt teruggegaan naar de vorige stap. Na een fout bij stap 10 heeft de gebruiker de mogelijkheid het continu¨ıteitsrapport in te vullen zonder de opname succesvol te stoppen. Hij kan dan klikken op ‘Next’ om naar stap 13 te gaan.

3.2.3

Kwalitatieve vereisten

In dit deel worden de kwaliteitsattribibuten besproken die invloed hebben op de verdere uitwerking van de voorgestelde uitbreiding. Ze worden gegeven in volgorde van belangrijkheid.

Gebruiksvriendelijkheid De gebruiksvriendelijkheid is het belangrijkste kwaliteitsattribuut. Omdat de applicatie draait op een mobiel toestel moet veel aandacht besteed worden aan bedieningsgemak, een duidelijke

3.2 Oplossing

17

interface, en het opvangen van fouten. Iedereen op de set moet in staat zijn de applicatie zonder voorkennis te gebruiken.

Prestaties De prestaties hangen in dit project nauw samen met de gebruiksvriendelijkheid. Vertragingen op het mobiel toestel moeten zoveel als mogelijk vermeden worden om een aangename gebruikerservaring te waarborgen. Ook moet er rekening gehouden worden met de beperktere verwerkingscapaciteit op een mobiel toestel. De prestaties zijn dus een tweede belangrijk kwaliteitsattribuut.

Aanpasbaarheid De aanpasbaarheid van een systeem duidt aan hoe goed een systeem kan omgaan met veranderingen. Extra functies, zoals beschreven in sectie 3.2.1, moeten eenvoudig te integreren zijn met zo weinig mogelijk aanpassingen aan de bestaande broncode.

Schaalbaarheid De schaalbaarheid van een systeem is de mate waarin het kan omgaan met een verhoogde werklast. Schaalbaarheid staat in deze lijst op de een-na-laatste plaats omdat de mobiele PISAapplicatie op set nooit door honderden mensen tegelijk zal gebruikt worden - hooguit een tiental. Daardoor moeten in het ontwerp geen speciale maatregelen genomen worden betreffende schaalbaarheid.

Beveiliging Beveiliging van een systeem kan gedefinieerd worden als de mate waarin een syssteem beschermd is tegen (al dan niet opzettelijk) onbevoegd gebruik. Doordat dit systeem toegang biedt tot beschermde informatie waaronder onuitgegeven scenario’s en beeldmateriaal, is de beveiliging een niet te minimaliseren element. Er wordt echter aangenomen dat de beveiliging op een hoger niveau zal geregeld worden. Bij de verdere uitwerking is er geen rekening gehouden met beveiliging van de informatie. In het volgende hoofdstuk wordt de architectuur voor deze oplossing besproken die voldoet aan de beschreven functionele en kwalitatieve vereisten.

ARCHITECTUUR

18

Hoofdstuk 4

Architectuur In het vorige hoofdstuk is een uitbreiding beschreven voor het PISA-project zodat het gebruikt kan worden vanop een PDA. In dit hoofdstuk wordt eerst de architectuur van het huidige PISAproject van naderbij bekeken (sectie 4.1). Een aantal essentiële componenten van die architectuur, die nodig zijn om de uitbreiding te realiseren, worden hierbij uitgelicht. Vervolgens worden een aantal ontwerpsbeslissingen besproken (secties 4.2 en 4.3). Een uitgebreide bespreking van de architectuur voor de mobiele uitbreiding rondt dit hoofdstuk af (sectie 4.4).

4.1

Architectuur van het huidige PISA-project

Het huidige PISA-project is opgebouwd als een webapplicatie, ontwikkeld in Java, die draait in de Apache Tomcat server [8]. Gegevens worden met Hibernate [22] opgeslagen in een MySqldatabase [33]. Er wordt gebruik gemaakt van het JavaServer Faces Framework [28] als basis voor de gebruikersinterface. De architectuur wordt schematisch weergegeven in figuur 4.1. De belangrijkste componenten van het systeem die zeker nodig zullen zijn bij een uitbreiding zijn het Episode Object Model en de REST-services. In de volgende paragrafen worden deze componenten van naderbij bekeken.

4.1.1

Het Episode Object Model

Het Episode Object Model beschrijft hoe alle opgeslagen informatie gestructureerd is en hoe de informatie aan elkaar gerelateerd is [10]. Het is volledig compatibel met P/Meta [78], een datamodel dat ontwikkeld is met de focus op het uitwisselen van data tussen verschillende

4.1 Architectuur van het huidige PISA-project

19

Figuur 4.1: Architectuur van Proof Of Concept II

omroepen. Het is gestandaardiseerd door de European Broadcasting Union1 [16]. Het datamodel sluit nauw aan bij de workflow van een productie, en is daarom gebaseerd op vier verschillende business-processen, zoals te zien in figuur 4.2. Het eerste proces, de product planning, is waar het product ontstaat. Er wordt bijvoorbeeld een dramaserie gemaakt over een nukkige politieinspecteur in dertien afleveringen. Met die informatie wordt begonnen aan de engineeringfase. In die tweede fase wordt het project verder uitgewerkt: afleveringen (Episode) en scènes (Scène) worden gedefinieerd en uitgeschreven. In het datamodel worden deze gemodelleerd als Editorial Objects - zeg maar ‘eenheden van werk’. Figuur 4.3 toont het klassediagram voor Editorial Objects. De ProgrammeGroup bevat specifieke informatie voor een programmareeks (bijvoorbeeld ‘Thuis’ of ‘Witse’) en heeft links naar alle Editorial Objects van de serie. 1

De European Broadcasting Union is de grootste unie van nationale omroepen ter wereld. Ze bevorderen de

samenwerking tussend de omroepen en vergemakkelijken de onderlinge uitwisseling van audiovisueel materiaal.


20

Figuur 4.2: Het gelaagde dramaproductieproces

Figuur 4.3: Klassediagram van Editorial Objects

Een scène is een dramatische eenheid van tijd, plaats en handeling binnen een film- of televisiescenario. Een scène is bijgevolg de basiseenheid waarin een dramaproductie wordt voorbereid, opgenomen en gemonteerd. Meerdere scènes samen vormen een aflevering. Zoals te zien op figuur 4.3, bestaat er tussen de editorial objects een reflexieve many-to-many relatie. Op die manier kan elke scène dus gelinkt worden met eender welke aflevering. Er wordt per scène en aflevering steeds een lijst bijgehouden van alle (oudere) versies van het object: de Scèneen EpisodeDescription-objecten. De laatste (actuele) versie wordt opgeslagen als de active description. Figuur 4.4 verduidelijkt dit met een ingekorte XML-voorstelling van een Episode.

De derde fase in de workflow is het opstellen van het draaiboek, waarbij bepaald wordt hoe de scènes precies gerealiseerd moeten worden. Dit zien we in figuur 4.5. Een scène wordt opgesplitst in een aantal shots. Een shot is een ononderbroken opname van een camera en (eventueel) een microfoon. Hierbij heeft elke component vastgelegde parameters: plaats, hoek, eigenschappen


<mam:episode baseURI="/services/data/editorial_object" id="9" ...> <mam:programme_group baseURI="/services/data/programme_group" id="1"> <mam:title>Thuis <mam:status code="RFP"/> <mam:number>2002 <mam:active_description baseURI="/services/data/editorial_object_description" id="80" ...> <mam:creation_time>2008-03-19T14:42:14.000+01:00 <mam:author>barbara <mam:status code="DRAFT"/> <mam:log_message>schrijffouten verbeterd <mam:title>Kasper komt niet thuis <mam:original_title/> <mam:cast/> <mam:descriptions> <mam:editorial_object_description baseURI="..." id="80" ...> <mam:creation_time>2008-03-19T14:42:14.000+01:00 <mam:author>barbara <mam:status code="DRAFT"/> <mam:log_message>eerste versie <mam:title>Kasper komnt niet thuis <mam:original_title/> ... ...

Figuur 4.4: Ingekorte XML-representatie van een Episode

21


22

Figuur 4.5: Klassediagram van Components

voor microfoon, cameralens, camerabewegingen,. . . Al die gegevens over de camera’s, geluid, microfoons en mise-en-scène worden verwerkt in het draaiboek. Als we in het datamodel deze informatie aan de editorial objects toevoegen, spreken we van manufacturing objects. In de laatste (vierde) fase tenslotte, worden die manufacturing objects ook effectief gerealiseerd. Ze worden opgenomen in de vorm van audiovisueel materiaal: de Media Objects of MOB’s. Continu¨ıteitsrapporten en logginginformatie worden opgeslagen in Realisation-objecten. Deze

Figuur 4.6: Klassediagram van Components, Realizations en Media Objects

objecten bevatten hoe een bepaald Manufacturing Object precies werd gerealiseerd in een Media Object. Ze bevatten dus zeer belangrijke informatie voor het (post-)productieproces. Het klassediagram wordt gegeven in figuur 4.6.

4.1.2

REST

REST staat voor Representational State Transfer. Het is geen standaard, maar een architecturale stijl om bepaalde services aan te bieden. Bij REST gebeurt de communicatie tussen client en server stateless. In het PISA-dramaproductiesysteem wordt REST gebruikt om de


23

interface te verzorgen naar externe applicaties, die op die manier toegang krijgen tot alle opgeslagen informatie. Bij REST heeft elke resource een specifieke URL. Bijvoorbeeld http: //pisa.drama.be/drama/services/data/episode/9, voor de episode met ID 9. De URL wordt geparsed door een servlet, die vervolgens de database bevraagt om een representatie van het object weer te geven. In het PISA-dramaproductiesysteem wordt dit steeds weergegeven in XML-formaat. Op die manier kan alle informatie worden opgevraagd. Ook het wijzigen, toevoegen en verwijderen van informatie is mogelijk met REST, dat daarvoor gebruik maakt van de HTTP-methodes. Een voorbeeld maakt dit duidelijk: als we een nieuwe aflevering willen opslaan, sturen we een HTTP PUT-request met in de body de XML-representatie van die aflevering naar de juiste URL. In dit geval naar http://pisa.drama.be/drama/services/data/episodes. De HTTP responsecode geeft aan of de operatie al dan niet gelukt is. Tabel 4.1 geeft de verschillende HTTP methodes en hun functie bij REST-services. Tabel 4.1: HTTP-methodes en hun functie bij REST-services

4.1.3

HTTP-methode

Actie

POST

Aanmaken object

GET

Lezen object

PUT

Updaten of aanmaken object

DELETE

Verwijderen object

XML

Alle informatie wordt uitgewisseld in XML-formaat. Voor elk object (Scène, Episode, descriptions, . . . ) ligt vast hoe hun XML-representatie eruit ziet. Deze specificaties liggen vast met XML-schema’s in het bestand /schemas/mammal.xsd in de PISA-projectfolder.

4.1.4

Query’s

Om informatie op te zoeken in het PISA-dramaproductiesysteem kunnen query’s verstuurd worden. Er zijn op dit moment query’s ge¨ımplementeerd voor onder andere scènes, episodes, shots, en realisation-objecten. Een query wordt opgebouwd in XML. Ook die schema’s liggen ook vast in het /schemas/mammal.


24

xsd-bestand. De query wordt verstuurd in de body van een POST-request. Resultaat van de query’s is een lijst met onder andere de id’s van objecten die aan de query voldoen. Een voorbeeld. De onderstaande episode-query (figuur 4.7) vraagt de lijst op met afleveringen die ofwel status RFP, ofwel status SCRIPTEDIT hebben. Deze XML wordt in de body van een POST-request verstuurd naar /drama/services/data/episodes: Het resultaat is een XML <episode_query xmlns="mammal.drama.pisa.ibbt.be"> <status_code>RFP <status_code>SCRIPTEDIT

Figuur 4.7: XML-representatie van een episode-query bestand (figuur 4.8) met een lijst die bestaat uit alle Episode-objecten die aan de gegeven voorwaarden voldoen: <mam:editorial_object_list xmlns:mam="mammal.drama.pisa.ibbt.be"> <mam:editorial_object baseURI="/services/data/editorial_object" id="52" xsi:type="mam:episode_inline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <mam:number>818 <mam:editorial_object baseURI="/services/data/editorial_object" id="9" xsi:type="mam:episode_inline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <mam:number>2002 ... <mam:editorial_object baseURI="/services/data/editorial_object" id="23" xsi:type="mam:episode_inline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <mam:number>2003

Figuur 4.8: XML-response van een Episode-query

4.2 Ontwerpsbeslissingen

4.2 4.2.1

25

Ontwerpsbeslissingen Stand alone of webapplicatie

Een afweging die moet gemaakt worden is of de beschreven uitbreiding gerealiseerd zal worden als een webapplicatie, of als een stand alone applicatie. De uitbreiding die we voor ogen hebben kan perfect gerealiseerd worden als een webapplicatie. Het bekijken van scenario’s kan in HTML en CSS, het invoeren van continu¨ıteitsrapporten kan met gewone formulieren, en ook de weergave van video is geen probleem. Bovendien worden de mobiele browsers steeds sneller en intelligenter in het weergeven van webpagina’s op mobiele toestellen. Het beste voorbeeld is Opera Mobile [35], met onder andere intelligente pan- en zoomfuncties en volledige ondersteuning voor AJAX. Op die manier wordt ineens ook volledig platformonafhankelijk gewerkt: voor elk toestel met internetmogelijkheden is er een browser beschikbaar. Ondanks de vele voordelen van een webgebaseerde benadering, is er in deze toch geopteerd voor een stand alone aanpak. Een eerste reden voor een stand alone applicatie is dat het meer mogelijkheden biedt om de applicatie later uit te breiden. Het voorkomt dat er een steeds een actieve verbinding nodig is met de PISA-dramaproductieserver. Gegevens kunnen naar het toestel worden gedownload, zodat ook zonder verbinding scenario’s kunnen worden gelezen, geschreven en opmerkingen toegevoegd. Bij een latere verbinding met de PISA-dramaproductieserver kunnen deze wijzigingen worden gesynchroniseerd. Een tweede reden is efficiëntie. Het is nog steeds efficiënter rechtstreeks een applicatie te draaien op het toestel, dan een webapplicatie te draaien in een - relatief - zware browser. De derde reden tenslotte is een persoonlijke voorkeur. Of het nu voor de desktop of een mobiel toestel bedoeld is, het ontwikkelen van een webapplicatie verschilt daarin nauwelijks. Het was mijn bedoeling om specifiek voor mobiele toestellen te ontwikkelen, omdat het een discipline is die aan belang alleen maar zal toenemen. Webapplicaties werden in vorige projecten reeds behandeld, in tegenstelling tot ontwikkelen voor mobiele toestellen. Door te kiezen voor een stand alone applicatie kreeg ik de mogelijkheid me daarin te verdiepen.

4.3

Applicatieraamwerken

Nu er gekozen is om een mobiele stand alone applicatie te ontwikkelen, hebben we een degelijk ontwikkelingsraamwerk nodig dat aan een aantal eisen voldoet. Zo moet het raamwerk onder-

4.3 Applicatieraamwerken

26

steuning kunnen bieden voor REST-services of toch minstens voor ‘traditionele’ webservices die gebruikmaken van WSDL, HTTP en SOAP. Ook ondersteuning voor XML is een must. Het raamwerk moet liefst platformonafhanklijk zijn zodat er zoveel mogelijk toestellen ondersteund kunnen worden. Afspeelmogelijkheden voor video staan ook op het verlanglijstje. Tenslotte moet het onmiddellijk inzetbaar zijn voor live testen op een echt toestel. We bekijken een aantal raamwerken van naderbij: Microsoft Silverlight, QT Mobile, Google Android, .NET Compact Framework, JavaFX en Adobe Flash Lite passeren de revue.

4.3.1

Microsoft Silverlight

Microsoft Silverlight [39] [40] is een cross-browser, cross-platform, and cross-device webapplicatieraamwerk. Via een plug-in worden zowel in als buiten de browser Rich Internet Applications gedraaid. Silverlight ondersteunt naast webservices en XML allerhande multimediafuncties zoals animaties en effecten voor foto’s en video. Silverlight Mobile werd aangekondigd voor 2009. Op het moment dat de architectuur werd vastgelegd (november 2008), viel dit platform bijgevolg uit de boot als mogelijke kandidaat. Ook op het moment van schrijven is er nog maar weinig meer bekend over Silverlight Mobile. Alle Silverlight-applicaties zouden mits beperkte aanpassingen wel kunnen draaien op mobiele toestellen. Maar meer informatie over welke functies en toestellen ondersteund zullen worden is er nog steeds niet.

4.3.2

QT Mobile

QT [37] (uitgesproken als het Engelse ‘cute’) is een cross-platform applicatie- en UI raamwerk. QT is gebouwd volgens een ‘write once, deploy everywhere’-filosofie. De code wordt één keer geschreven (in C++), en kan daarna zonder aanpassingen gecompileerd en uitgevoerd worden op verschillende besturingssystemen. QT biedt een uitgebreide grafische API voor multimedia en graphics, alsook ondersteuning voor webservices en XML. Voor ontwikkeling kan de QTomgeving ge¨ıntegreerd worden in Visual Studio en Eclipse. De software van QT wordt onder andere gebruikt door Volvo, Google en Philips [37]. Helaas vallen onder de ondersteunde mobiele besturingssystemen enkel Windows Mobile en Linux embedded. Symbian OS, een veelvoorkomend mobiel besturingssysteem, wordt niet ondersteund.


4.3.3

27

Google Android

Android [6] is het mobiele besturingssysteem van Google. Het omvat een uitgebreide SDK om applicaties te schrijven voor dit nieuwe platform. Android biedt naast toestel-afhankelijke functies zoals Bluetooth, WiFi, GPS en kompas, ook ondersteuning voor 2D en 3D-graphics, audio en video (waaronder MPEG4 en H.264), enzovoort. Het is volledig op Java gebaseerd. Via een plug-in kunnen Android-applicaties ontwikkeld worden in Eclipse [13] met behulp van onder andere een emulator, tools voor geheugen- en prestatie-analyse, en een debugger. Een nadeel van Android is ondermeer dat Android-applicaties niet platformonafhankelijk zijn - ze gebruiken immers Android-specifieke bibliotheken. Ook was het in november 2008 nog helemaal niet duidelijk wanneer het eerste Android-toestel precies in de winkelrekken zou liggen. Intussen is in juni 2009 in België de allereerste Android smartphone gereleased, de HTC Magic [66].

4.3.4

.NET Compact Framework

Microsofts .NET Compact Framework [34] is een versie van het .NET Framework die ontworpen is om te draaien op Windows CE gebaseerde mobiele/ingebedde toestellen zoals PDA’s, GSM’s, settopboxen, enzovoort. Applicaties die gebruik maken van het .NET Compact Framework kunnen geschreven worden in Visual Studio (vanaf versie 2003), en dit zowel in C# als in Visual Basic.NET. Er is ook een emulator beschikbaar. Om de applicaties op de mobiele toestellen te draaien moet het .NET Compact Framework erop ge¨ınstalleerd zijn. Dit kan makkelijk zelf gedaan worden via een download van de Microsoft-site. Het is niet echt verrassend dat dit enkel beschikbaar is voor Windows CE en Windows Mobile. De laatste versie van het .NET Compact Framework is versie 3.5, met ondersteuning voor XML, webservices, en beperkte ondersteuning voor multimedia.

4.3.5

Java platform, Micro Edition

Java platform, Micro Edition (Java ME) [26] is een krachtig Java-platform voor mobiele toestellen en ingebedde systemen zoals mobiele telefoons, PDA’s, televisies en settopboxen. Naast de brede ondersteuning door de fabrikanten, biedt het platform ook andere voordelen. Er kan geprogrammeerd worden in Java, een volledig object-georienteerde en mature taal. De geoptimaliseerde virtuele machine biedt stevige prestaties, en er is een grote community en veel


28

documentatie beschikbaar. REST wordt niet standaard ondersteund, maar video behoort wel tot de mogelijkheden. Nadelen zijn dat Java ME werkt met profielen en configuratiebestanden, waardoor een applicatie geschreven in Java ME zeer verschillend kan reageren op verschillende toestellen. Ook worden schaalbare graphics niet ondersteund - waardoor er mogelijk heel wat aanpassingen nodig zijn om dezelfde applicatie op verschillende toestellen te draaien. De vraag is ook of Java ME nu, met de lancering van het ambitieuze JavaFX, een voorbijgestreefd platform is geworden.

JavaFX JavaFX [68] [70] is veel meer dan de opvolger van Java ME. Het is bedoeld om grafisch geavanceerde (internet)toepassingen te maken. JavaFX applicaties hebben de ambitie dat ze uitgevoerd kunnen worden op eender welk toestel met een scherm; gaande van computers en GSM’s tot televisies, settopboxen en Blu-ray Disc-spelers. Om de applicaties op al die toestellen uit te voeren zouden nauwelijks of geen wijzigingen nodig zijn aan de broncode. JavaFX biedt uitgebreide bibliotheken voor graphics, audio, (streaming) video en animaties. Het biedt op die manier de mogelijkheid eenvoudig een dymamische gebruikersinterface te creëeren. JavaFX is gebouwd bovenop Java, en laat dus toe reeds bestaande broncode te hergebruiken. Nog een voordeel van JavaFX is de beloofde platformonafhankelijkheid. Nu is er al ondersteuning voor Windows Mobile en Android, maar ook Sony Ericcson en LG Electronics hebben intussen aangekondigd JavaFX te zullen ondersteunen op hun toestellen [27]. Toestellen moeten JavaFX standaard ondersteunen, het is niet mogelijk zelf JavaFX erop te installeren. In november 2008 moest JavaFX helaas nog gelanceerd worden, en waren omtrent JavaFX Mobile weinig specifieke gegevens bekend.

4.3.6

Adobe Flash Lite

Adobe Flash Lite [1] is de mobiele variant Adobe Flash, en is geoptimaliserd voor mobiele telefoons, draagbare toestellen en andere elektronische apparaten die met internet kunnen verbonden worden (zoals settopboxen). Flash vindt zijn oorsprong in de animatie en is bijgevolg in staat om eenvoudig voor een mooie, geanimeerde interface te zorgen. ActionScript zorgt voor de interactiviteit, met ondersteuning voor XML, webservices en audio. In november 2008 was de laatste versie Flash Lite 2.1 - een versie die geen ondersteuning biedt voor video. Flash Lite


29

3.0 was wel al aangekondigd en beschikbaar voor ontwikkelaars, maar er waren nog geen spelers beschikbaar2 om Flash Lite 3.0 applicaties te draaien op mobiele toestellen. Flash Lite 3.0 biedt ondersteuning voor FLV en H.264-video, en een betere integratie met de device-API’s. Zowel Flash Lite 2.1 als 3.0 steunen op ActionScript 2.0 in plaats van versie 3.0 die gebruikt wordt in de gewone Flash spelers voor de desktop, maar daarover later meer. Nog een voordeel van Flash is de platformonafhankelijkheid. Er is ondersteuning voor Symbian, Windows Mobile, BREW, Sony PSP, en tientallen GSM-fabrikanten rusten hun toestellen standaard uit met een Flash Lite speler. Ook de uitgebreide testomgeving - Adobe Device Central - is een stevig pluspunt. Volgens onderzoeksbureau Strategy Analytics zullen in het eerste kwartaal van 2009 één miljard nieuwe toestellen met Flash Lite geproduceerd zijn [76].

Adobe Flex Adobe Flex 3 [3] is een open-source raamwerk waarmee grote, expressieve webtoepassingen kunnen gemaakt worden die gebaseerd zijn op Adobe Flash. De toepassingen draaien op de meest gangbare browsers, desktops en besturingssystemen. Adobe Flex is beschikbaar als plugin voor Eclipse. Adobe Flex maakt gebruik van ActionScript 3, en kan daardoor niet gebruikt worden om mobiele toepassingen te ontwikkelen. Dit wordt zelfs expliciet afgeraden door Adobe [4].

4.3.7

IPod Touch & IPhone

De IPhone en de IPod Touch zijn door hun intu¨ıtieve multitouchbediening een aantrekkelijke kandidaat voor het ontwikkelen van nieuwe mobiele applicaties. De ontwikkelingssoftware Cocoa geeft ondersteuning voor traditionele webservices, REST, video (mp4), en grafisch mooie gebruikersinterfaces. Cocoa is echter enkel beschikbaar voor Mac. Om een programma ook effectief op een IPhone of IPod Touch te krijgen, moet er eenmalig 99 dollar betaald worden voor het ADC3 -lidmaatschap. Apple zelf houdt immers nauwlettend toezicht op de gepubliceerde applicaties. 2 3

Intussen zijn er wel al Flash Lite 3.0 spelers beschikbaar [5]. Apple Developer Connection


30

Om die reden is het ook niet mogelijk andere applicaties of één van bovenstaande raamwerken te gebruiken om te programmeren voor de IPhone. Ook Flash wordt - zelfs in de browser - niet ondersteund.

4.3.8

Conclusie

In tabel 4.2 wordt een overzicht gegeven van de voor- en nadelen van de besproken raamwerken. Ondersteuning voor XML en webservices bleek geen probleem te zijn en wordt door elk modern raamwerk ondersteund. De rest van ons eisenpakket (platformonafhankelijkheid, videomogelijkheden, nu beschikbaar) bleek een zwaardere dobber. Vanwege de platformonafhankelijkheid vallen het .NET Compact Framework, Cocoa, Google Android en QT Mobile (vanwege geen ondersteuning voor Symbian OS) af. Over JavaFX en Microsoft Silverlight voor mobiele toestellen waren op het moment dat de keuze gemaakt moest worden nog veel te weinig definitieve specificaties bekend. Ook deze twee beloftevolle raamwerken vielen hierdoor uit de boot. Twee platformen blijven over: Adobe Flash Lite en Java ME. Beiden zijn platformonafhankelijk, zijn onmiddellijk inzetbaar, en ondersteunen video (Flash Lite weliswaar vanaf versie 3.0). Na een korte praktijktest is de keuze beslecht in het voordeel van Adobe Flash Lite. De snelheid waarmee een eenvoudige applicatie (één knop die tekst weergeeft in een tekstveld) in elkaar te boxen was, was indrukwekkend. Ook de testomgeving - Adobe Device Central - kon bekoren. De applicatie draaide ook onmiddellijk feilloos op een GSM. Bij Java ME bleek dit alles heel wat minder voor de hand liggend. Ook de beperktere mogelijkheden voor de gebruikersinterface bij Java ME gaven het voordeel aan Adobe Flash Lite. Op langere termijn is het uitkijken naar JavaFX. De belofte dat eenzelfde code kan gebruikt worden voor zowel een desktop-, browser-, en mobiele applicatie is een sterke troef.

JavaFX

IPod Touch en IPhone

Google Android

QT Mobile

Microsoft Silverlight

.NET Compact Framework

van Silverlight Mobile en ondersteunde toestellen Nog niet beschikbaar - aangekondigd voor 2009

Grafisch sterk Multimedia-ondersteuning

C++

Multimedia

Onduidelijkheid over lancering toestellen

H.264, MPEG4, 2D en 3D-graphics

Java

Enkel ontwikkelen op Mac, ADC Lidmaatschap

Grafisch sterk, multimedia

Vervolg op volgende pagina

Mobiele JavaFX platform: lente 2009

nodig om applicaties op echt toestel te draaien

Niet platform-onafhankelijk

Intu¨ıtieve multitouch bediening

Integratie Eclipse, Emulator, profiling

Volledig op Java gebaseerd

Niet platformonafhankelijk

Multimedia-ondersteuning:

Integratie met Visual Studio

Geen ondersteuning voor Symbian OS

Uitgebreide, grafische API

en mobiele applicatie

Weinig wijzigingen tussen desktop-

Nauwelijks informatie bekend over de specificaties

Enkel voor Windows Mobile

Nadelen

Cross-platform

Emulator

Integratie met Visual Studio

Voordelen

4.3 Applicatieraamwerken 31

Adobe Flash Lite

Java ME

maar nog geen spelers beschikbaar ActionScript 2.0

Veel ondersteunde toestellen uitgebreide testomgeving

Tabel 4.2: Voor- en nadelen van mobiele raamwerken

Versie 3.0: wel video-ondersteuning,

Mogelijkheden

Voorbijgestreefd door JavaFX ?

Video, prestaties

Huidige versie 2.1: Geen video-ondersteuning

op verschillende toestellen

platformonafhankelijk, community

Cross-platform

Kan zeer uiteenlopend reageren

Weinig specificaties vrijgegeven

Nadelen

Java, krachtig platform

Mogelijkheden

Cross-platform

en mobiele applicatie

´ enzelfde code voor desktop-, browser-, E´

Voordelen

4.3 Applicatieraamwerken 32

4.4 Architectuur voor de mobiele uitbreiding

4.4

33

Architectuur voor de mobiele uitbreiding

We weten nu hoe het huidige PISA-project is opgebouwd. Ook is de einddoelstelling duidelijk afgelijnd: er wordt een stand alone applicatie ontwikkeld in Flash Lite, met de functies die beschreven zijn in sectie 3.2.2. Hieronder wordt eerst een algemeen overzicht gegeven van de gecreëerde architectuur (sectie 4.4.1). In sectie 4.4.2 wordt het ontwerp van de PDAservices besproken. Sectie 4.4.3 gaat dieper in op het ontwerp van de mobiele toepassing. Tenlotte wordt in sectie 4.4.4 de dynamische interactie tussen de verschillende componenten van naderbij bekeken.

4.4.1

Overzicht

Samengevat hebben we in de architectuur te maken met 4 componenten: 1. Het draagbaar toestel waarop de mobiele PISA-applicatie draait 2. De PDAservices waarmee het draagbaar toestel communiceert 3. Het PISA-dramaproductiesysteem, de centrale component die alle data bevat en waar alle gegevens worden opgeslaan 4. De ingestserver die audio en video capteert van de aangesloten camera’s en microfoons Zowel de PDAservices, het PISA-dramaproductiesysteem als de ingestserver kunnen draaien op één en dezelfde machine, of verspreid worden over verschillende computers. Een vereiste is wel dat ze zich in hetzelfde netwerk bevinden. In figuur 4.9 wordt de opstelling schematisch weergegeven. Op de figuur wordt voor de duidelijkheid alles weergegeven op aparte machines.

4.4.2

PDAservices

REST-services worden niet ondersteund vanuit Flash. Er is een bibliotheek die dit wel mogelijk maakt, Flex UrlLoader [21], maar die maakt gebruik van ActionScript 3 en wordt bijgevolg niet ondersteund door Flash Lite. Ook E4X [12], een bibliotheek die toelaat om op een eenvoudige manier met XML te programmeren, is onderhevig aan hetzelfde lot. Om die redenen is er gekozen om alle communicatie tussen de mobiele PISA-applicatie en de ingestserver en PISA-dramaproductieserver uit te voeren via klassieke webservices (met HTTP


34

Figuur 4.9: Opstelling voor gebruik van het PISA-dramaproductiesysteem met een PDA

en SOAP), zoals tevens te zien is op figuur 4.9. We noemen deze webservices de PDAservices waarbij PDA ook staat voor Portable Drama Application. Deze configuratie heeft ook meer voordelen. De communicatie kan beperkt worden tot het strikte minimum: er worden enkel gegevens uitgewisseld die noodzakelijk zijn. Om bijvoorbeeld via REST een lijst te bekomen van alle afleveringen (titel en programme group4 ) met status RFP (Ready For Production), moet het volgende gebeuren: 1. Er wordt in XML een query opgesteld en via POST verstuurd naar het PISA-dramaproductiesysteem 2. De response moet geparsed worden in een XML-object door het mobiel toestel, en de id’s van iedere aflevering moeten eruit gehaald worden 3. per Episode ID moet ofwel: • de volledige XML-representatie van de aflevering worden opgehaald (één grote XML) 4

‘Serie’ waartoe de aflevering behoort. Bijvoorbeeld Thuis of Witse.


35

• ofwel moeten twee verzoeken verstuurd worden om de programme group en de active description van de episode op te halen (twee kleine XML’s). Voor een lijst van een tiental afleveringen lopen het aantal requests - en bijgevolg de verwerkingstijden en wachttijden - snel op. Door gebruik te maken van de specifieke PDAservices kunnen we dit als volgt aanpakken: 1. Vanop het mobiel toestel wordt de PDAservicemethode getRFPEpisodes() aangeroepen. Deze methode stuurt (analoog aan voorgaande) een query naar het PISA-dramaproductiesysteem, verwerkt de resultaten, en haalt de nodige gegevens van de afleveringen op. 2. De gegevens van die afleveringen (id, titel, programme group) worden in XML formaat terug naar het toestel gestuurd. Er wordt tussen het toestel en de server maar 1 verzoek gestuurd (geef me alle episodes met status RFP), en 1 response (een minimale XML met enkel de nodige gegevens). Door de PDAservices te gebruiken kan er zeer gericht gewerkt worden voor de mobiele toestellen, zonder dat deze uitbreiding de huidige implementatie van het PISA-dramaproductiesysteem be¨ınvloedt. Er wordt gebruik gemaakt van de reeds bestaande REST-services. De PDAservices nemen de toestellen een hoop werk uit handen, wat de responsiviteit en batterijduur zeker ten goede komt: in Flash Lite is de verwerking van XML data een bijzonder processorintensieve taak [67]. Alle informatie zal uitgewisseld worden in XML-formaat.

Klasseontwerp van de PDAservices Het klasseontwerp voor de PDAservices wordt gegeven in figuur 4.10. Alle methoden die als webservicemethode kunnen worden aangeroepen staan in de klasse DramaWebservice. De package datamodel, gegeven in figuur 4.11, bevat de klassen die worden uitgewisseld met de PDA. Deze objecten worden aangemaakt met de gegevens die uit het PISA-dramaproductiesysteem worden opgehaald. Elke klasse implementeert de interface PdaExchangeable die de methode toXmlElement() bevat. Deze methode geeft een org.jdom.Element-object terug, de bouwsteen van elk XML-document in JDom [29]. Van dit object kan dan later de stringrepresentatie worden verkregen die verstuurd wordt naar de PDA. Bij de implementatie zal de JDom bibliotheek


36

Figuur 4.10: Klassediagram van de PDAservices

gebruikt worden voor de verwerking van alle XML-documenten (zie ook sectie 5.1). De klassen van de package datamodel hebben dezelfde velden als de overeenkomstige klassen in de package datamodel bij het ontwerp van de mobiele PISA-applicatie: het is deze informatie die immers wordt uitgewisseld. Meer informatie daarover staat verderop in sectie 4.4.3. De package query bevat implementaties van de Episode- en Shotquery, zoals te zien in figuur 4.12. Die laten toe op eenvoudige wijze query’s op te bouwen die voldoen aan de vastgelegde specificaties. De abstracte klasse Query bundelt de gemeenschappelijke functionaliteit.

4.4.3

Objectgeori¨ enteerd ontwerp voor de mobiele PISA-applicatie

De mobiele PISA-applicatie wordt geschreven met behulp van ActionScript 2.0. Deze scripttaal uit 2003 is gebaseerd op ECMAScript en laat toe een objectgerichte syntax te gebruiken. Er kunnen onder meer klassen en interfaces gedefinieerd worden, en er kan gebruik worden gemaakt van overerving, maar overloading wordt bijvoorbeeld niet ondersteund. De volgende paragrafen geven een overzicht van het objectgeoriënteerd ontwerp.


37

Figuur 4.11: Klassediagram van de package datamodel

Package diagram Het packagediagram, weergegeven in figuur 4.13, bevat 5 packages. De package pisa.acquisition bevat de specifieke klassen voor deze applicatie, met name het model. De andere packages (externalcomm, ui, util en datamodel) kunnen hergebruikt worden in latere uitbreidingen of andere PISA-applicaties. De package flash op het diagram is geen eigenlijk package - het wordt weergegeven om aan te duiden wat entrypoint is van de Flash-applicatie. Flash heeft immers geen Main klasse of -methode van waaruit de applicatie zich ontvouwt.

Figuur 4.12: Klassediagram van de package query


38

Figuur 4.13: Packagediagram van de Flash-applicatie

De package externalcomm staat in voor alle communicatie naar de buitenwereld, terwijl de package ui (hulp)klassen bevat die gebruikt worden ter ondersteuning van bepaalde gebruikersinterface-elementen. De package datamodel bevat een eigen versie van het EOM5 -model en bevat zelf ook nog een package: pisa.datamodel.xmlparser. Zoals reeds vermeld zal alle informatie uitgewisseld worden in XML-formaat. Om makkelijk te werken worden deze resultaten geparsed naar hun overeenkomstige klasse uit de package datamodel. Vanwege deze nauwe relatie bevindt de package xmlparser zich in de package datamodel. De package util tenslotte bevat klassen voor het opslaan van data op het toestel, en het opvragen van andere toestelspecifieke informatie. Meer informatie hierover vindt u in de volgende paragrafen.

Klassediagram De uitwerking van het klassediagram, weergegeven in Figuren 4.14 tot 4.19, bevat geen grote verrassingen. Om het overzicht te bewaren zijn in de klassediagrammen geen constructors, getters of setters weergegeven. We overlopen het even kort per package. 5

Episode Object Model, zie sectie 4.1.1


39

acquisition Bevat één belangrijke klasse: het AcquisitionModel. Het bevat alle informatie over de draaiende applicatie: Welke episode, scène en shot er is gekozen, de laatst opgehaalde lijsten met afleveringen, scènes en shots, de lijst met beschikbare camera’s en microfoons, enzovoort.

Figuur 4.14: Klassediagram van de package acquisition

datamodel De klassen in deze package vormen een eigen, specifieke versie van het EOM-model met enkel de informatie die de mobiele PISA-applicatie nodig heeft. Zoals reeds vermeld hebben de klassen in deze package dezelfde velden als hun overeenkomstige klassen in de package datamodel van de PDAservices. Het toevoegen of verwijderen van een veld in de ene klasse impliceert dus een wijziging in de andere klasse. Dit ontwerp is echter niet blijvend. Als E4X beschikbaar wordt voor Flash Lite, is er bij de mobiele PISA-applicatie geen package datamodel meer nodig. De gegevens kunnen dan rechtstreeks op een overzichtelijke manier opgehaald worden uit de XML-bestanden die verstuurd worden door de PDAservices - de XML-bestanden moeten dus op het mobiele toestel niet meer geparsed worden tot een object van een klasse uit de package datamodel. Wijzigingen aan de originele klassen van het EOM-model op de PISA-dramaproductieserver hebben op de klassen in de datamodel packages geen invloed. De klassen in de datamodel packages moeten wel gewijzigd worden als in de mobiele PISA-applicatie meer informatie over


40

de objecten nodig is; bijvoorbeeld als bij elke aflevering ook de regisseur moet weergegeven worden. Een overzicht van de klassen in de package datamodel.

Figuur 4.15: Klassediagram van de package datamodel

• Episode Voorstelling van een aflevering, met velden als programmeGroup, titel, status, een array met scènes, en een id. • Scene


41

Stelt een scène voor, met velden als id, timeCode, location, volgnummer, en een lijst met shots. • Shot Stelt een shot voor, en heeft een naam, id, beschrijving, en numberOfCams en numberOfMics waarmee wordt aangegeven met hoeveel camera’s respectievelijk micro’s de shot wordt opgenomen. • Synopsis Beschrijft een synopsis met een header, en de tekst opgemaakt met HTML-codes. • Device, Camera en Microphone Device is de superklasse van Camera en Microphone. Bevat onder andere de velden id, type, name en supplier. • DeviceSet Een DeviceSet stelt een groep van devices voor. Zo zijn er voor de opnames van een bepaalde aflevering een aantal camera’s en micro’s beschikbaar, en wordt een shot ook opgenomen met één of meerdere camera’s of microfoons. Dit wordt gemodelleerd aan de hand van een DeviceSet. • ShotRealisation De verschillende takes bij de opnames van een bepaalde shot worden gemodelleerd als een ShotRealisation. Deze bevat de afgesproken ID, de episode, scène en shot die werd opgenomen, de deviceSet waarmee dit gebeurde, een counter, de duur van de take en de starten stopcodes. • GoodShotIndicator Bevat de verschillende Good Shot Indicators: Excellent, Usable, Interesting of Bad material. • Annotation Bevat de logboodschap en een bijhorende GoodShotIndicator.


42

datamodel.xmlparser De antwoorden van de PDAservices worden ontvangen in XML-formaat. Deze worden door reeds beschikbare Flash-methoden geparsed tot een XML-object dat standaard aanwezig is in ActionScript 2.0. Deze package creëert uit deze XML-objecten de overeenkomstige objecten uit de package datamodel.

Figuur 4.16: Klassediagram van de package datamodel.xmlparser

• Interface XMLParser Deze interface definieert de verschillende methodes die de XML’s parsen naar objecten van de respectieve klassen: parseEpisodes, parseScenes, parseDeviceSet, parseSynopsis, . . . • PisaXMLParser Specifieke implementatie van de XMLParser voor het Pisa-dramaproductiesysteem. Gebruikt een XPath-bibliotheek [46] om gegevens uit de XML-objecten te halen.

externalcomm Voor de communicatie met de buitenwereld zorgen volgende klassen: • Interface DataFacade


43

Figuur 4.17: Klassediagram van de package externalcomm

Definieert de methodes om de PDAservices te contacteren, zoals fetchRFPEpisodes(), fetchScenesForEpisode(episodeID), enzovoort. Alle methodes worden vermeld in figuur 4.17. • PisaDramaServer Implementatie van de DataFacade. Voor elke PDAservicemethode die we willen aanroepen hebben we hier twee methodes nodig: een fetch en een onLoad. De fetch-methodes zijn reeds gedefinieerd in de interface. Deze methoden sturen de requests naar de PDAservices, maar werken in Flash asynchroon. Als de resultaten ontvangen worden, wordt daarom de bijhorende onLoad-methode uitgevoerd. Daarnaast is er nog een hulpmethode voor het inladen van de WSDL (wsdlLoaded()), een die fouten afhandelt (errorOccurred(..)), en het annuleren van een request (cancelRequest()).


44

util Deze package bevat een aantal hulpklassen:

Figuur 4.18: Klassediagram van de package util

• SettingsManager Staat in voor het laden en opslaan van instellingen op het toestel (op dit moment enkel de URL van de PDAservices). Is een singleton, omdat we ten alle tijde maar één instantie nodig hebben om inconsistenties te vermijden. • DeviceManager Zorgt voor de implementatie van toestelspecifieke interacties, zoals opvragen van hoeveelheid vrij/beschikbaar geheugen en de resterende batterijduur. Is eveneens een singleton. • Profiler Eenvoudige klasse om de uitvoersnelheid van bepaalde stukken code te meten.

ui De hulpklassen voor de gebruikersinterface zijn ondermeer:


45

Figuur 4.19: Klassediagram van de package ui

• ChronoMeter Implementatie van de chronometer die loopt bij het starten van een opname. Methoden zijn onder andere startChrono, stopChrono en updateChrono. • ErrorMessage Wordt gebruikt voor het weergeven van een foutmelding • ContinuityReport Hulpklasse voor de gebruikersinterface bij het invoeren van een continu¨ıteitsrapport. Bouwt de interface op en verzorgt de animaties.

4.4.4

Dynamisch ontwerp

Het sequentiediagram voor het weergeven van een scenario is eenvoudig. Het mobiel toestel roept de juiste PDAservicemethode aan, waarna de PDAservices de nodige gegevens ophaalt uit het PISA-dramaproductiesysteem (onder andere de episode XML en verschillende scène XML’s). De gegevens worden verwerkt en het resultaat wordt teruggestuurd naar het toestel. Het schema wordt gegeven in figuur 4.20. Voor de continu¨ıteitsrapporten is dit minder voor de hand liggend. Niet alleen moet er veel meer data worden uitgewisseld (episodes, scènes, shots, devices, . . . ), ook moeten via de ingestserver


46

Figuur 4.20: Sequentiediagram voor het ophalen van een synopsis

de opnames gestart en gestopt worden, en moet het continu¨ıteitsrapport gelinkt blijven aan de opnames. Er moet ook steeds rekening mee gehouden worden dat op het draagbare toestel de netwerkverbinding kan uitvallen, vanwege te veel storing of buiten bereik, of een lege batterij. Hieronder wordt een overzicht gegeven van de verschillende berichten die worden uitgewisseld tot aan het starten van de opname. Alle antwoorden van de PDAservices zijn Strings in XMLformaat. De communicatie verloopt analoog aan figuur 4.20. 1. De PDAservicemethode getRFPEpisodes() wordt aangeroepen. De PDAservices voeren een query uit en stuurt voor elke resulterende aflevering de nodige informatie terug: id, titel, programmeGroup en statuscode. 2. De scènes voor de gekozen aflevering worden opgehaald met getScenesForEpisode(int episodeId). Het antwoord bevat voor elke scène de scène id’s, hun volgnummers, de locatie en tijdsaanduidingen. 3. Tenslotte wordt de lijst met shots opgevraagd. In deze stap wordt ook de lijst met beschikbare camera’s en micro’s meegestuurd. Voor de shots wordt id, naam en beschrijving teruggestuurd; voor de devices is dat de id, de naam en de supplier. Om het starten en stoppen van de opnames in goede banen te leiden wordt de volgende aanpak gevolgd. Bij het starten van een opname wordt een ID uitgewisseld. Als de PDA als response een ID ontvangt is dat de bevestiging dat de opname succesvol is gestart. In het andere geval is er kennelijk iets foutgelopen moet een nieuw startverzoek worden gestuurd.


47

Bij het stoppen van de opname wordt deze ID opnieuw meegestuurd. De ID garandeert dat de juiste opname kan worden gestopt. Stel dat de opname reeds manueel was gestopt en er reeds een nieuwe opname bezig is - het verzoek van de PDA komt dus te laat - dan mag de huidige opname zeker niet worden gestopt. Na de opname wordt zowel de realisatie als het continu¨ıteitsrapport naar het PISA-dramaproductiesysteem verstuurd, elk met dezelfde ID. Het PISA-dramaproductiesysteem gebruikt deze ID om het rapport en beeldmateriaal te matchen en samen te voegen. Figuur 4.21 geeft het sequentiediagram.

Figuur 4.21: Sequentiediagram voor het starten en stoppen van een opname

Stel dat een stopverzoek niet kon verstuurd worden vanop de PDA, en de opname manueel gestopt moet worden: op de PDA kan men het continu¨ıteitsrapport dan alsnog aanmaken en versturen. De ID was reeds afgesproken en kan dus gebruikt worden om de opname en het rapport aan elkaar te linken. In het volgende hoofdstuk wordt dieper ingegaan op de implementatie.

IMPLEMENTATIE

48

Hoofdstuk 5

Implementatie In dit hoofdstuk wordt de implementatie meer in detail besproken. Eerst wordt de implementatie van de PDAservices van naderbij bekeken (sectie 5.1). Daarna wordt een volledig overzicht gegeven van de gerealiseerde mobiele PISA-applicatie (sectie 5.2). Hierbij wordt onder andere de structuur van de Flash-applicatie toegelicht (sectie 5.2.1), het ontwerp van de gebruikersinterface wordt besproken (sectie 5.2.2), en er wordt een overzicht gegeven van de volledige implementatie (sectie 5.2.3). Om dit hoofdstuk af te ronden wordt ook het testen (sectie 5.2.4) en debuggen (sectie 5.2.4) kort toegelicht.

5.1

PDAservices

De PDAservices zijn ge¨ımplementeerd als een aparte webapplicatie in Java, die draait in een Apache Tomcat server. Dit kan dezelfde Apache Tomcat server zijn die ook het PISA-dramaproductiesysteem draait, maar ook een Apache Tomcat server op een aparte machine. Voor de implementatie werden de volgende grote bibliotheken gebruikt: • JDom [29] voor het ophalen, parsen, aanmaken en bewerken van alle XML-documenten. Ook stelt JDom de nodige XPath-functionaliteit ter beschikking. • HttpClient [24] voor de implementatie van alle HTTP-methodes, zoals PUT en POST, die gebruikt worden om query’s en andere gegevens naar het PISA-dramaproductiesysteem op te sturen. • Apache Axis [7] voor de implementatie van SOAP [41].

5.1 PDAservices

Ophalen van gegevens

49

De implementatie en werkwijze verschilt niet veel tussen de verschil-

lende methoden die de lijsten met afleveringen, scènes en shots ophalen. Als voorbeeld worden de verschillende stappen beschreven bij het ophalen van een lijst met afleveringen met de status RFP. 1. Er wordt een EpisodeQuery aangemaakt voor alle afleveringen met status RFP. De query wordt opgestuurd naar het PISA-dramaproductiesysteem. 2. De afleveringen uit de resulterende lijst worden één voor een één verwerkt: • Aan de hand van de ID van de aflevering wordt de XML-representatie opgehaald • JDom parsed dit resultaat tot een Document • Met behulp van XPath worden de nodige gegevens van de aflevering uit de XML gehaald (titel, productie) • er wordt een nieuw datamodel.Episode object met die gegevens aangemaakt • de XML-representatie van dat object wordt als node toegevoegd aan de uiteindelijke XML 3. de resulterende XML wordt teruggegeven

Starten en stoppen van opname Bij het startverzoek stuurt de PDA een XML-representatie mee van de shotRealisation. Hierin zitten alle gegevens over de huidige take (id’s van de episode, scène, shot, en welke camera’s en microfoons gebruikt worden). Het effectief starten en stoppen van de opnames, waarbij de camera’s worden aangestuurd, is nog niet ge¨ımplementeerd. In de plaats wordt alles uitgeschreven in een logbestand, met in de bestandsnaam de unieke afgesproken ID. Als een opname wordt gestopt, wordt aan de hand van de meegestuurde ID dit logbestand uitgelezen. In het logbestand staat de starttijd van de opname vermeld. Door die tijd te vergelijken met de huidige (stoptijd) kennen we de duur van deze opname. Dit wordt als geldige responsecode naar de PDA verstuurd. Hiervan wordt opnieuw een logbestand geschreven.

Tijdsaccuraatheid Op dit moment zijn nog geen maatregelen getroffen om de tijdsaccuraatheid te waarborgen zodat de chronometer op het mobiele toestel synchroon loopt met de eigenlijke opname. Omdat voor het starten en stoppen van de opnames een dummyimplementatie is gebruikt, was het

5.1 PDAservices

50

synchronisatieverschil slechts een tiental milliseconden. Bij een effectieve implementatie kan dit verschil echter oplopen tot een aantal seconden - afhankelijk hoe lang het duurt om de camera’s op te starten en in te stellen. Om een betere tijdsaccuraatheid te bekomen wordt hieronder een mogelijke oplossing geschetst. Deze oplossing gaat ervan uit dat de klokken van het mobiel toestel, de PDAservices en de ingestserver niet gesynchroniseerd zijn. Er kan bijgevolg geen rekening gehouden worden met de transmissievertraging. Als in sommige gevallen de transmissievertraging toch te hoog zou oplopen - bijvoorbeeld door een traag of overbelast netwerk - moeten de klokken eerst gesynchroniseerd worden om een nog betere tijdsaccuraatheid te verkrijgen. De fout in de voorgestelde oplossing bedraagt de transmissietijd van de PDA naar de PDAservices, vermeerderd met de tranmissietijd van de PDAservices naar de ingestserver (zie ook figuur 5.1): F out = tM P + tP I

Mobiel toestel

PDAservices TM

Ingestserver

t MP ∆1 = TP − TM

TP '

t PI ∆ 2 = TI − TP ' Start opname op tijdstip TI '

S = TI '−∆ 2 S

S1 = S − ∆1 S1

Figuur 5.1: Mogelijke opslossing voor verbetering van de tijdssynchronisatie

Beschrijving van de oplossing 1. Bij het startverzoek verstuurt de PDA naast de shotRealisation ook zijn tijdscode TM .

5.1 PDAservices

51

2. De PDAservicemethode bepaalt het verschil ∆1 tussen de ontvangen tijdscode TM en de eigen tijdscode TP . 3. Bij het startverzoek dat naar de ingestserver wordt verstuurd wordt de huidige tijdscode (inmiddels TP0 ) van de PDAservices meegegeven. 4. De ingestserver berekent het verschil ∆2 tussen de ontvangen tijdscode TP0 en de eigen tijdscode TI . 5. De ingestserver bepaalt het tijdstip TI0 waarop de opname effectief is gestart. Dit tijdstip wordt gecorrigeerd door het gekende tijdsverschil met de PDAservices ervan af te trekken: S = TI0 − ∆2 . Het resultaat wordt als antwoord teruggestuurd naar de PDAservices. 6. De PDAservicemethode corrigeert het ontvangen tijdstip met het gekende tijdsverschil met de klok van het mobiele toestel: S1 = S − ∆1 7. Door de huidige tijdscode van het mobiele toestel af te trekken van de ontvangen tijdscode is geweten hoe lang de opname al bezig is. De chronometer wordt hieraan overeenkomstig aangepast.

Continu¨ıteitsrapporten

Het opsturen van continu¨ıteitsrapporten naar het PISA-dramapro-

ductiesysteem wordt reeds deels ge¨ımplementeerd. Van de ontvangen shotRealisation wordt een acquisitionRealisation gemaakt. Dit is een voorstelling van een realisatie zoals die moet verstuurd worden naar het PISA-dramaproductiesysteem, met specificatie van de verschillende MOB’s, capturefuncties, enzovoort. Een aantal zaken in die XML worden nog niet correct ingevoerd, maar wel al voldoende om een weergave van de annotaties te zien in de opnamelogboeken.

Scenario Voor de weergave van het scenario op de PDA wordt de opmaak verwerkt door de PDAservicemethode. Voor de opbouw van een scenario zijn veel verschillende XML-representaties nodig: de episode, de uitgebreide active description (zie sectie 4.1.1) van de episode, en eveneens twee voor elke gedefinieerde scène (de scène en bijhorende active description). Om die reden is er besloten om af te stappen van het idee de transformatie uit te voeren met XSLT. Door de vele verschillende XML’s en bijhorende transformaties zou de eindoplossing veel complexer zijn dan nodig. De informatie wordt nu rechtstreeks uit de XML’s gehaald, en omgezet in HTML-tags en tekst die door Flash ge¨ınterpreteerd kunnen worden. Op dit moment zijn die HTML-tags hard gecodeerd in de broncode. Dit kan later nog aangepast worden door deze op

5.2 De mobiele PISA-applicatie in Flash Lite

52

te nemen in een propertiesbestand, of de transformatie op een andere manier uit te voeren. De code is wel zo geschreven dat de gewenste lettergrootte met één veld is aan te passen, of kan opgegeven worden als extra parameter bij het aanroepen van de methode. De opmaak van een scenario wijzigt echter niet vaak: de typische lay-out, zoals te zien in figuur 2.1, ligt al meer dan dertig jaar vast [57].

5.1.1

Testen

Voor het analyseren van de query’s en hun resultaten werd RestClient [38] gebruikt. Dit is een Java programma dat geschreven is om REST-services te testen, en biedt ondersteuning voor alle HTTP-methodes. Het bleek uitermate handig om te experimenteren met query’s, en fouten op te sporen bij de implementatie van de PDAservices. Om de PDAservices op zich te testen is soapUI [42] gebruikt. soapUI is een testtool die op een eenvoudige manier toelaat elke webservicemethode te testen via HTTP en SOAP. Vooral bij de methode die het opgemaakte scenario in HTML-codes verstuurt (als CDATA), bleek dit handig om te controleren of alles juist werd doorgestuurd.

5.2

De mobiele PISA-applicatie in Flash Lite

Flash ontstond in 1996 als FutureSplash, een tekenpakket om animaties in webpagina’s te verzorgen. In december 1996 werd FutureSplash overgekocht door Macromedia en was Flash 1.0 geboren. In de volgende versies werden steeds meer verbeteringen en functionaliteit toegevoegd. De belangrijkste is ongetwijfeld de toevoeging van scripting-mogelijkheden, waardoor Flash veel dynamischer werd en interactie met de gebruiker toeliet. Vandaag de dag is het toepassingsgebied van Flash (intussen overgenomen door Adobe) sterk verruimd. Het wordt niet alleen gebruikt voor animaties en websites, maar ook voor complexe Rich Internet Applications, video en desktoptoepassingen. Het is nuttig om de roots van Flash - het verzorgen van animaties - in het achterhoofd te houden bij het ontwikkelen van applicaties.

5.2.1

Structureren van een Flash-applicatie

Er zijn twee grote manieren om een Flash-applictatie te ontwikkelen. Aan de ene kant is er de tijdslijngebaseerde aanpak, en aan de andere kant de zuivere code aanpak.


53

Zuivere code Zoals de titel al doet vermoeden, wordt bij deze aanpak alles geregeld vanuit de code. Het voordeel hiervan is dat je de applicatie veel beter in de hand hebt, makkelijker fouten kan opsporen, en veel meer controle hebt over de flow en structuur van het programma. Het design wordt bovendien gescheiden gehouden van de implementatie, wat handig is als er geprogrammeerd wordt in team. Het grote nadeel van deze aanpak is dat er redelijk wat ervaring en kennis nodig is van Flash, en ActionScript in het bijzonder, om het gewenste resultaat te bekomen. De ontwikkeltijd zal langer zijn, ook omdat er meer code nodig is dan bij de tijdslijngebaseerde aanpak.

Tijdslijngebaseerd De tijdslijn in Flash is hét bewijs dat roots van Flash liggen bij animaties. De tijdslijn is opgebouwd uit Frames. Met elke status waar het programma zich in kan bevinden (voorbeeld menu, scèneselectie, startOpname) wordt een Keyframe gelabled. Die labels worden gebruikt om te navigeren binnen het programma. Aan frames kan ook code worden toegevoegd, die dan steeds wordt uitgevoerd als dat Frame wordt afgespeeld. Die code kan niet alleen het afspelen van de tijdslijn be¨ınvloeden maar ook objecten, variabelen en andere MovieClips manipuleren. Alles in Flash is een MovieClip. Elke MovieClip heeft z’n eigen tijdslijn, en kan alle combinaties van animaties, afbeeldingen, video’s, knoppen, tekst en code bevatten. Movieclips kunnen bovendien genest worden, zodat zeer ingewikkelde structuren mogelijk zijn - voor sommige projecten dreigt dit dan ook onoverzichtelijk te worden. Deze aanpak wordt vooral gebruikt voor kleinere applicaties en voor rapid prototyping, maar is minder geschikt voor grote, complexe opdrachten.

Keuze voor de mobiele PISA-applicatie De uitbreiding zal gerealiseerd worden volgens de tijdslijngerichte aanpak. De acquisitie-applicatie is van structuur niet echt complex, maar integendeel lineair - wat zich eenvoudig laat vertalen naar de tijdslijn: eerst wordt de aflevering gekozen, dan de scène, dan de shot, enzovoort. Bijkomend argument is dat er veel minder documentatie beschikbaar is voor een volledig codegebaseerde aanpak. De meeste voorbeelden en tutorials, zowel op het web als in boeken, gebruiken de tijdslijnbenadering. Ook de beperkte (lees: geen) ervaring met ActionScript spreekt in het voordeel van de tijdslijngerichte aanpak.


5.2.2

54

Ontwerp van de gebruikersinterface

De gebruikersinterface is eenvoudig gehouden voor een maximale duidelijkheid op een klein scherm. Bovenaan staat uiteraard de titel van het programma, met in de rechterbovenhoek informatie over het geheugengebruik en de batterijstatus van het toestel. De navigatieknoppen (vorige/volgende) bevinden zich in de onderste hoeken. De grote ruimte ertussen wordt gebruikt voor de eigenlijke informatie - lijst met beschikbare afleveringen, chronometer, scenario, invoervelden voor continu¨ıteitsrapport, enzovoort. Voor de knoppen, lijsten, en andere interface-elementen werden zoveel mogelijk standaard Flash-componenten gebruikt. Om de leesbaarheid te waarborgen bij verschillende lichtomstandigheden zijn er twee sterk contrasterende kleuren gekozen: wit en donkerblauw. Het donkerblauw is gebruikt als achtergrondkleur, tekst wordt in het wit weergegeven. Ook in een verduisterde omgeving blijft deze combinatie aangenaam - een hoofdzakelijk wit scherm kan vermoeiend zijn voor de ogen, en verbruikt bovendien meer energie. De gebruikersinterface wordt weergegeven in figuur 5.2.

% gebruikt geheugen Batterijstatus

Navigatieknoppen Figuur 5.2: De gebruikersinterface van de mobiele PISA-applicatie op een PDA


5.2.3

55

Realisatie van de mobiele PISA-applicatie in Flash Lite

Het project werd ontwikkeld in Adobe Flash CS3, een complete ontwikkelomgeving voor Flashprojecten. Alles zit vervat in één projectbestand, behalve externe afbeeldingen en de aparte ActionScript-klassen. De packages met die klassen staan in een folderstructuur - analoog aan Java. Onderstaande code geeft een voorbeeld van zo’n klasse in ActionScript-syntax. Waar code is weggelaten wordt ‘. . . ’ weergegeven. import pisa.datamodel.Episode; import pisa.datamodel.Scene; import pisa.datamodel.Shot; ... class pisa.datamodel.ShotRealisation {

private var episode:Episode; ... /** constructor */ public function ShotRealisation(theEpisode:Episode, ...) { episode = theEpisode; ... } /** getters */ public function setEpisode(newEpisode:Episode) { episode = newEpisode; } ... /** setters */ public function getEpisode():Episode { return episode; } ... }

Figuur 5.3: Voorbeeld van een klasse in ActionScript syntax

De tijdslijn, gegeven in figuur 5.4 geeft het algemeen overzicht van de applicatie. Ze bestaat uit verschillende lagen die toelaten om bepaalde componenten te groeperen en meer overzicht te krijgen. Zo zijn er aparte lagen aangemaakt voor de labels, ActionScript, en verschillende lagen voor de gebruikersinterface. Bij de implementatie is steeds rekening gehouden met zogeheten fail safes. Telkens er gegevens van de PDAservices worden opgehaald, heeft de gebruiker de mogelijkheid dit te annuleren -


56

Figuur 5.4: De tijdslijn van de Flash-applicatie

vanwege lange wachttijden door een slechte of weggevallen connectie. Ook andere fouten worden zoveel als mogelijk opgevangen. De batterijstatus wordt steeds weergegeven zodat de gebruiker kan anticiperen op een mogelijk uitvallende batterij. Bij een inkomend telefoongesprek wordt de applicatie door Flash gepauseerd, en nadien hervat. De implementatie zal hier niet in detail uit de doeken worden gedaan. Omdat de communicatie met de PDAservices asynchroon gebeurt, zal eerst die werkwijze toegelicht worden. Ook de manier waarop de chronometer en de interface voor de continu¨ıteitsrapporten werd gerealiseerd kan wat meer uitleg gebruiken. Daarna zal er per label op de tijdslijn kort uitgelegd worden wat er die stap gebeurt, en eventuele bijzonderheden worden aangestipt.

Communicatie met de PDAservices Alle interactie met de PDAservices wordt ge¨ımplementeerd in pisa.externalcomm.PisaDramaServer. Voor elke PDAservicemethode die we aanroepen, worden twee methodes ge¨ımplementeerd. De eerste methode contacteert de PDAservices - een oproep die asynchroon gebeurt - en zorgt dat het laadscherm wordt weergegeven. Een voorbeeld: public function fetchRFPEpisodes():Void { dramaResult = dramaService.getRFPEpisodes(); dramaResult.onResult = Delegate.create(this, onRFPEpisodesLoad); dramaResult.onFault = Delegate.create(this, errorOccurred); gotoAndPlay("Loading"); }

Figuur 5.5: Voorbeeld van een fetch-methode dramaResult is een leeg, nieuw object waarin de response van de PDAservices wordt opgeslagen. Er worden hier twee listeners geregistreerd: een methode die zal worden uitgevoerd


57

als het resulaat wordt ontvangen (onResult), en een methode in geval van een fout (onFault). Delegate.create() is een hulpmethode die de juiste methodes registreert voor die events. In dit geval wordt van het huidige object (this) de onRFPEpisodesLoad uitgevoerd als het resultaat wordt ontvangen. Na registratie van de errorOccurred -methode bij onFault wordt naar het label Loading gesprongen waardoor het laadscherm wordt weergegeven: gotoAndPlay("Loading"). Als het resultaat wordt ontvangen wordt de tweede methode uitgevoerd - in dit voorbeeld onRFPEpisodesLoad. Tijdens de uitvoering van deze methode wordt nog steeds het laadscherm weergegeven. Deze methode verwerkt de resultaten van de PDAservices, die worden doorgegeven aan de PisaXMLParser. Het resultaat wordt opgeslagen in het acquisitionModel. Tenslotte wordt naar het volgende label gesprongen waar de resulaten kunnen worden weergegeven.

Chronometer en continu¨ıteitsrapport Alles in Flash kan omgevormd worden tot een MovieClip. Om meer overzicht te krijgen werden deze twee componenten als aparte MovieClips geconcipieerd. De MovieClips zijn verbonden met hun ActionScript-klasse in pisa.ui. Dit is ingesteld bij de eigenschappen van de MovieClips zoals te zien is op figuur 5.6.

Figuur 5.6: Eigenschappen van de Movieclip ContinuityReport

Deze instelling zorgt ervoor dat als één van de MovieClips wordt aangemaakt, de constructor van die klasse wordt opgeroepen. De klassen erven over van de Flash-klasse MovieClip, en hebben daardoor toegang tot de objecten in die MovieClip.


58

Bij de chronometer bijvoorbeeld. Die is opgebouwd uit drie tekstvelden (een voor de minuten, seconden, en milliseconden) gescheiden door een dubbelpunt. De ChronoMeterklasse heeft volledige toegang tot die velden. Als er op start wordt geklikt, wordt de methode updateChrono() gekoppeld aan het onEnterFrame-event. Dit event wordt door flash steeds gegenereerd als er naar een nieuw Frame wordt overgegaan. Bemerk dat elke MovieClip zijn eigen tijdslijn heeft: het gaat hier over een nieuw frame binnen de tijdslijn van de chronometer MovieClip. De tijdslijn van de acquisitie-applicatie blijft hierbij ongewijzigd. MovieClips spelen standaard aan twaalf frames per seconde - de chronometer zal dus ook twaaf keer per seconde worden ge¨ updated. Een analoog verhaal bij de interface voor de continu¨ıteitsrapporten. Hier worden vanuit de code ook de radiobuttons voor de Good Shot Indicator en de checkbox toegevoegd. Er zijn methoden om logboodschap en GSI uit te lezen en in te stellen. Ook de animatie van deze MovieClip wordt hier ge¨ımplementeerd. De interface ‘vliegt’ namelijk het scherm binnen, om onmiddellijk te vertragen en te stoppen in het midden van het scherm - en vice versa: hij versnelt bij het buitenvliegen van het scherm. Deze bewegingen worden ook wel ease in/out genoemd. Hieronder volgt een overzicht van wat er precies gebeurt bij de verschillende labels op de tijdslijn. Het vormt zo ook een overzicht van de hele applicatie.

MainScreen Dit is de start van de applicatie. Er zijn drie knoppen: Acquisitie, Scenario en Settings. Figuur 5.7 geeft een schermafbeelding. De code bij deze frame programmeert de animatie van de drie knoppen (ze glijden het scherm binnen van links naar rechts en vertragen naar het einde) en de actie als er op de knoppen geklikt wordt (er wordt naar het juiste frame in de tijdslijn gesprongen: Settings of Init - zie verder).

Settings De GUI op deze frame is een eenvoudige titel en een input tekstveld waar de URL van de PDAservices kan worden ingegeven. De URL wordt opgeslagen in een zogeheten Mobile Shared Objects (MSO’s). In MSO’s kunnen zowel eenvoudige tekst als complexe objecten worden opgeslagen. De hoeveelheid data die in een MSO kan worden opgeslagen is afhankelijk van de vrije ruimte op het toestel. Na een druk op de save-knop springen we terug naar het beginscherm.


59

Figuur 5.7: Schermafbeelding van het startscherm van de mobiele PISA-applicatie

Init In deze stap wordt een AcquisitionModel en DataFacade aangemaakt. De aanmaak van deze laatste initieert het ophalen en parsen van het WSDL-bestand dat de PDAservices beschrijft. De implementatie hiervan bevindt zich in de pisa.externalcomm.PisaDramaServer-klasse. Die klasse zorgt ervoor dat tijdens het ophalen en verwerken van de WSDL het laadscherm wordt weergegeven door in de tijdslijn te verspringen naar het label Loading. Als het laden voltooid is wordt teruggegaan naar label webserviceLoaded.

webserviceLoaded De WSDL is ingeladen. Afhankelijk van de eerdere keuze van de gebruiker worden nu de afleveringen opgehaald. Koos de gebruiker voor Scenario, dan wordt een lijst met alle beschikbare afleveringen opgehaald. Als de gebruiker daarentegen koos voor Acquisitie wordt een lijst opgehaald met enkel afleveringen met status RFP. Eerst wordt de situatie verder bekeken waarbij de gebruiker koos voor het lezen van een scenario.

scenario De lijst met afleveringen wordt opgehaald uit het AcquisitionModel, en licht aangepast zodat deze goed wordt weergegeven in de GUI. De GUI bestaat uit een DataGrid-component voor


60

weergave van de lijst, een knop om de keuze te bevestigen en een knop om terug te keren naar het vorige scherm. Een klik op de eerste haalt de synopsis voor die aflevering op via de DataFacade.

synopsisLoaded Afhankelijk van de programme group waartoe de geslecteerde aflevering behoort wordt bovenaan het juiste logo weergegeven. Verder bestaat de GUI uit een tekstvak waar de titel van de aflevering in komt, en een groot tekstveld (TextArea) voor het scenario dat scrollbars weergeeft indien nodig. Figuur 5.8 geeft een schermafbeelding. De TextArea kan tekst weergeven die is opgemaakt met HTML-tags. De ondersteuning blijft beperkt tot onder andere
, , , ,
, en . Voor de volledige lijst van ondersteunde tags wordt verwezen naar [43].

Figuur 5.8: Schermafbeelding van de weergave van een scenario

episodesLoaded Volledig analoog aan het label scenario - behalve dat het nu enkel afleveringen zijn met als status RFP. Bij een klik op de ‘Select Episode’-knop wordt een lijst met beschikbare scènes voor die aflevering opgehaald. De geselecteerde aflevering wordt opgeslagen in het acquisitionModel.


61

scenesLoaded De lijst met beschikbare scènes wordt weergegeven. In een tekstveld bovenaan staat de titel van de geselecteerde aflevering. Na een druk op de knop ‘Select Scene’ worden de shots opgehaald én de gegevens over de beschikbare camera’s en microfoons. De scène wordt opgeslagen in het acquisitionModel.

shotsLoaded Analoog aan voorgaande label: de lijst met shots wordt weergegeven. De geselecteerde shot wordt opgeslagen in het acquisitionModel.

devicesSelect Deze stap bevat een pak meer code. Hier worden, afhankelijk van hoeveel camera’s en microfoons er nodig zijn om de shot op te nemen, de nodige ComboBoxen weergegeven. Bij een druk op ‘Select Devices’ wordt de selectie gecontroleerd: eenzelfde camera mag bijvoorbeeld niet twee keer geselecteerd zijn. Is dit toch het geval, dan wordt er een foutmelding weergegeven. Als alles goed is wordt er van de selectie een DeviceSet aangemaakt. Er wordt dan ook een ShotRealisationobject gecreëerd en opgeslagen in het acquisitionModel. Voor er naar een ander label wordt gesprongen worden de ComboBoxen opnieuw verwijderd.

recordStart Hier wordt de ChronoMeter aan de interface toegevoegd. ChronoMeter is een MovieClip die wordt bestuurd door de ChronoMeterklasse in de package ui. Als op de opnameknop wordt geklikt wordt een startRecordverzoek verstuurd naar de PDAservices. De chronometer wordt dus nog niet gestart.

startRecordRequestFinished De response van het start-request werd ontvangen. Als de response geldig is wordt de chronometer gestart (een schermafbeelding hiervan wordt gegeven in figuur 5.9). De opnameknop wordt uitgeschakeld zodat enkel nog op stop kan gedrukt worden. Als op de stopknop wordt gedrukt stopt de chronometer en wordt een stopRecordingRequest naar de PDAservices gestuurd.


62

Figuur 5.9: Schermafbeelding van de mobiele PISA-applicatie tijdens een opname

stopRecordRequestFinished Als de opname succesvol is gestopt wordt de chronometer verwijderd en naar het label continuityReport gesprongen. Kon de opname niet succesvol gestopt worden, dan kan opnieuw geprobeerd worden of alsnog worden verdergegaan naar de ingave van het continu¨ıteitsrapport.

continuityReport De interface voor het invoeren van een continuityReport is een aparte MovieClip die wordt toegevoegd. Erboven worden de algemene gegevens weergegeven: Naam van de aflevering, scène, shot, duur van de opname en nummer van de take. Figuur 5.10 geeft een schermafbeelding. Als op de knop ‘Continue’ wordt geklikt wordt er gekeken of het ‘Duplicate logmessage for cameras/micros’ is aangevinkt. Is dit niet het geval, dan wordt per camera/micro een nieuw logscherm weergegeven. Met de ‘Back’-knop kan steeds worden teruggekeerd naar een vorig scherm. Als alles is ingevuld wordt het rapport opgestuurd naar de PDAservices, waarna het opgeslagen wordt op de PISA-dramaproductieserver. De animaties en de interface worden ge¨ımplementeerd in de pisa.ui.ContinuityReport.

reportSubmitted In deze laatste stap worden een aantal knoppen weergegeven met verschillende keuzemogelijkheden. Er kan een nieuwe opname gemaakt worden, helemaal teruggaan naar het beginscherm, een


63

Figuur 5.10: Gebruikersinterface voor het invoeren van een continu¨ıteitsrapport

andere episode, scène of shot gekozen worden of andere camera/micro-setup. Als het rapport niet correct was verstuurd is er ook een knop om het opnieuw te proberen.

Loading Dit is het laadscherm. Een infotekstje wordt weergegeven in het tekstveld en als animatie wordt een draaiende ring getoond. Dit speelt in een lus van een tiental frames en blijft dus draaien tot er expliciet naar een ander label wordt gesprongen.

5.2.4

Testen

Flash Lite-applicaties worden getest in het uitstekende Adobe Device Central. Dit programma is speciaal ontwikkeld om Flash-content te testen voor mobiele toestellen. Er zijn tientallen profielen beschikbaar voor GSM’s, smartphones en PDA’s. De uitvoering en de bediening van de Flash Lite-applicaties worden zo getrouw mogelijk geëmuleerd. Figuur 5.11 geeft een schermafbeelding van een emulatie in Adobe Device Central op de Nokia E71. Tijdens de emulatie kunnen tientallen parameters bekeken en aangepast worden. Het geheugengebruik wordt gemonitord, de display-instellingen als helderheid, contrast, en reflectie kunnen aangepast worden, en ook de resterende batterijtijd, de eigenschappen voor de netwerkverbinding (netwerksterkte, netwerktype), enzovoort kunnen ingesteld worden.


64

Figuur 5.11: Emulatie van de mobiele PISA-applicatie op een Nokia E71 in Adobe Device Central

Het emuleren van de applicatie in Device Central, en het aanpassen van de verschillende parameters gaf al snel een goed beeld hoe de applicatie wordt weergegeven en reageert op een echt toestel. Andere testraamwerken of tools voor geheugen- en prestatie-analyse zijn niet beschikbaar voor Flash Lite. Naast de emulatie in Device Central, is uiteraard ook getest op een echt toestel. Meer over het uitvoeren en testen op een mobiel toestel wordt verder beschreven in hoofdstuk 6.

Debuggen Een nadeel is dat in Device Central niet gedebugged kan worden. De applicatie moet gecompileerd worden voor een gewone Flash Player-versie om gedebugged te kunnen worden met de Flash-debugger. Dit heeft dan weer als bijkomend nadeel dat specifieke Flash Lite-commando’s, zoals het opvragen van de hoeveelheid vrij geheugen op het toestel, niet worden ondersteund. Die regels code moeten bijgevolg manueel worden uitgecommentarieerd. De interface van de debugger is vrij beroerd en niet echt gebruiksvriendelijk - maar, zoals elke debugger, soms bij-


65

zonder handig. Tijdens het testen werden sommige PDAservicemethoden aangepast zodat ze geen geldig resultaat gaven, en werd de Apache Tomcat server tijdens een request manueel afgesloten om te verifiëren of de applicatie deze fouten naar behoren afhandelde.

INSTALLATIE EN UITVOERING OP EEN PDA

66

Hoofdstuk 6

Installatie en uitvoering op een PDA Dit hoofdstuk beschrijft de installatie (sectie 6.1) en uitvoering (sectie 6.2) op een echte PDA, waarna enkele vaststellingen worden gegeven en mogelijke verbeteringen worden voorgesteld. De tests op een echt toestel werden uitgevoerd op een HTC Touch Pro [23]. Dit toestel is tevens beschikbaar in Adobe Device Central voor emulatie. Het heeft een 2.8” groot aanraakscherm met een resolutie van 480 x 640 pixels, een 528 MHz processor, 288 MB ram-geheugen en een uitschuifbaar qwerty-toetsenbord.

6.1

Installatie

De hele applicatie (inclusief de gebruikte afbeeldingen) werd gecompileerd tot een *.swf-bestand van ongeveer 150 kB. Op een toestel met de Flash Lite 2.1 speler volstaat het dit swf-bestand naar het toestel te kopiëren en vervolgens op het toestel te openen. De applicatie wordt dan gestart. Op de HTC Touch Pro werd Flash Lite 3.1 speler ge¨ınstalleerd [5]. Bij de Flash Lite 3.1 speler is het niet meer mogelijk onmiddellijk een swf-bestand te openen. Met Adobe Mobile Packager [5], nog een ander programma, moet een uitvoerbaar installatiebestand gemaakt worden die de SWFapplicatie op het toestel installeert (vb. een CAB-bestand voor Windows Mobile). Tijdens de installatie wordt ook de versie van de Flash speler gecontroleerd, en wordt er een snelkoppeling met icoon toegevoegd aan het start-menu. Het installatiebestand bevat als metadata onder andere het versienummer van de applicatie, de auteur en een beschrijving.

6.2 Uitvoering

67

De applicatie wordt op deze manier op een gebruiksvriendelijke manier op het toestel ge¨ınstalleerd. Bij het installeren van een nieuwe versie wordt de oude automatisch verwijderd.

6.2

Uitvoering

In de testopstelling draaien zowel de PDAservices als de PISA-dramaproductieserver in eenzelfde Apache Tomcat server. Om de verbinding tussen de PDA en de Apache Tomcat server mogelijk te maken moet op de router port forwarding worden geconfigureerd (standaard poort 8080) en moet elke tussenliggende firewall juist ingesteld zijn.

6.2.1

Vaststellingen

De applicatie wordt weergegeven zoals verwacht. Als het toetsenbord wordt uitgeschoven draait het scherm zodat de applicatie schermvullend wordt weergegeven. Bij het starten gebruikt de applicatie 2237 Kb (of 36.5%) geheugen. Dit komt redelijk goed overeen met de 2077 Kb die werd aangegeven in de emulator. De Flash Player heeft bij de HTC Touch Pro maximaal 6142 Kb geheugen ter beschikking. Bij het testen op de HTC Touch Pro werd geëxperimenteerd met de netwerkverbinding: deze werd afwisselend aan- en uitgeschakeld om de gevolgen daarvan te bekijken voor de mobiele PISA-applicatie. Zoals reeds aangegeven is er enkel een actieve verbinding nodig als er gegevens moeten opgehaald of verstuurd worden - bijvoorbeeld na het selecteren van een aflevering of het starten van een opname. Bij terugkeren naar een vorige stap moeten geen gegevens opgehaald worden. Dit kan dus gebeuren zonder een actieve verbinding. Als er gegevens moeten worden opgehaald en de PDA geen WiFi-verbinding heeft, wordt een foutmelding weergegeven. Is er wel een WiFi-verbinding, maar zijn de PDAservices niet bereikbaar, dan blijft de loading-animatie zichtbaar tijdens herhaaldelijke pogingen om alsnog verbinding te krijgen. Zoals steeds is er de mogelijkheid het laden af te breken en terug te keren naar de vorige stap. Het ophalen en verwerken van gegevens van de PDAservices verloopt vlot: meestal onder de halve seconde. Wat het langst duurt is de weergave van die gegevens. Kennelijk vergt de weergave van de DataGrid (de interfacecomponent die de tabellen weergeeft) behoorlijk wat rekenkracht. Ook de stap waar de ComboBoxen worden gemaakt (voor selectie van camera’s en micro’s) duurt

6.2 Uitvoering

68

lang, en daar wordt helemaal niets opghaald of verwerkt van de PDAservices. De gemiddelde wachttijd per stap is vier seconden - althans in stappen waarbij een DataGrid of ComboBox wordt weergegeven. Het weergeven, starten en stoppen van de chronometer gebeurt onmiddellijk, en ook op de interface voor de continu¨ıteitsrapporten moet geen tiende van een seconde gewacht worden. Van elke stap in het programma (ophalen en weergeven van afleveringen, starten van een opname, versturen continu¨ıteitesrapport, enzovoort) is de wachttijd en de toename van het geheugengebruik gemeten. Tabel 6.1 geeft het gemiddelde van 5 metingen. De tijdsmetingen moesten manueel worden uitgevoerd. Eerst voert Flash alle code van een frame uit en pas daarna wordt er gerenderd. Wij willen het geheel meten, maar na het renderen kan geen commando meer worden uitgevoerd om de tijdsmeting te stoppen. Het geheugengebruik kon worden afgelezen van de gebruikersinterface. Bij de metingen werden geen noemenswaardige uitschieters vastgesteld.

Toename

Toename

Wachttijd (s)

geheugengebruik (%)

geheugengebruik (kB)

5,825

1,5

92,13

4,025

6,5

399,23

4,35

0,167

10,24

3,63

1,43

88,04

onmiddellijk

0

0

start opname

0,9

0

0

stop opname

0,96

0

0

onmiddellijk

0

0

1,1

0,6

12,28

Actie Ophalen en weergeven van afleveringen Ophalen en weergeven van scènes Ophalen en weergeven van shots weergeven ComboBoxen Camera’s en micro’s weergave chronometer

weergave interface continu¨ıteitsrapport versturen continu¨ıteitsrapport

Tabel 6.1: Gemiddelde wachttijd en geheugengebruik voor de mobiele PISA-applicatie

6.2 Uitvoering

69

Uit de tabel blijkt ook dat het geheugengebruik sterker stijgt bij de stappen die een DataGrid of ComboBoxen gebruiken - precies die stappen die langer duren. Voor de sterke stijging (6,5%) bij de weergave van de scènes heb ik geen verklaring. De code is daar volledig analoog aan die voor de weergave van afleveringen en shots. De chronometer en de interface voor de continu¨ıteitsrapporten vereisen nauwelijks extra geheugen. Nader onderzoek met de Profiler heeft uitgewezen dat het niet zozeer het uitvoeren van de code is die tijd kost, maar wel het renderen van de componenten voor weergave op het scherm. Tijdens dat renderen gebruikt Flash alle beschikbare verwerkingskracht en valt zelfs de Loading-animatie stil.

6.2.2

Mogelijke verbeteringen

De knelpunten zijn aangetoond: de stappen die gebruik maken van een DataGrid of ComboBox moeten eerst aangepakt worden. Ze gebruiken het meeste geheugen en laten de gebruiker gemiddeld vier seconden wachten. Bij de DataGrid blijkt dit een bekend issue te zijn. In het artikel ‘DataGrid performance strategies’ [11] worden een aantal te mijden werkwijzen gegeven. Zo moet de methode addColumn() zoveel mogelijk vermeden worden. Die methode wordt in de huidige implementatie gebruikt om de volgorde van de kolommen aan te passen. Het herschrijven van de code zodat deze methode niet meer gebruikt wordt, leverde echter niet de verhoopte prestatiewinst, en deed het geheugengebruik zelfs nog stijgen. Een alternatief is een andere interface ontwikkelen waardoor geen DataGrid en ComboBox gebruikt moet worden. Dit kan analoog gebeuren zoals de gebruikersinterface voor de continu¨ıteitsrapporten: een aparte MovieClip, met een sturende klasse in de package pisa.ui. Het geheugengebruik is een ander punt. Op dit moment zijn er nog geen inspanningen geleverd om het geheugengebruik te minimaliseren. Te veel objecten blijven aanwezig in het geheugen, waardoor bij langdurig gebruik van de applicatie het geheugen overvol zal geraken. Als oplossing kan daarvoor bij elke label een stuk code worden toegevoegd die objecten en variabelen die niet meer nodig zijn vernietigd of null toewijst. Flash werkt met een garbage collector, maar (sommige) objecten kunnen ook manueel vernietigd worden met de destroyObject()-methode. Voorlopig wordt er voor de bediening op dit moment uitsluitend uitgegaan van een aanraakscherm. Er zijn nog geen voorzieningen getroffen voor louter toetsenbediening. Nu er spelers voor Flash Lite 3 beschikbaar zijn kan ook videofunctionaliteit worden toegevoegd. Dit is zoals vermeld nog niet ge¨ıntegreerd in de huidige mobiele PISA-applicatie. Hieronder

6.2 Uitvoering

70

wordt beschreven hoe deze functionaliteit kan worden toegevoegd in het huidige Flash-project.

Toevoegen van videofunctionaliteit Flash Lite 3 heeft ondersteuning voor FLV, H.264, On2 VP6, en Sorenson videocodecs. Video’s kunnen afgespeeld worden van een webserver via HTTP, rechtstreeks van het toestel, of als streaming video via Flash Media Server [2]. In dit voorbeeld wordt een kleine testapplicatie ontwikkeld die een video afspeelt van een webserver via HTTP. De videospeler beschikt over de standaard bedieningsknoppen zoals play/pauze, opnieuw afspelen, volume, en een vooruitgangsbalk zodat vooruit en achteruit gesprongen kan worden. Ook wordt een knop en tekstveld toegevoegd voor het opvragen en weergeven van de huidige tijdscode van de video, wat kan gebruikt worden voor het toevoegen van interessante cuepoints (zie sectie 3.2.1). De hier gegeven implementatie kan naadloos worden ingepast in de huidige implementatie van de mobiele PISA-applicatie. Aan de tijdslijn voegen we een nieuw keyframe toe met label videoplayer. Aan de gebruikersinterface worden twee componenten toegevoegd: een MediaDisplay die de video zal weergeven, en een MediaController die knoppen en een voortgangsbalk voorziet voor de bediening van de video. Deze objecten krijgen respectievelijk de instantienamen movieDisplay en movieController. Ook wordt een tekstveld en een knop aan de interface toegevoegd. Figuur 6.1 geeft een verduidelijkende schermafbeelding. De code die toegevoegd moet worden om de componenten in te stellen en de video te laden wordt gegeven in figuur 6.2. Bij integratie met de mobiele PISA-applicatie zal er bij de PDAservices een methode toegevoegd moeten worden die indien nodig de gevraagde video herschaalt en de URL teruggeeft waar die video zich bevindt. In de pisa.externalcomm.DataFacade-klasse zullen methodes moeten toegevoegd worden om de nieuwe PDAservicemethode te kunnen oproepen (analoog aan de reeds bestaande methoden). Figuur 6.3 toont de draaiende testapplicatie in Adobe Device Central. Ter verificatie is deze applicatie ook met succes getest op de HTC Touch Pro.

6.2 Uitvoering

71

Figuur 6.1: Schermafbeelding van het Flash-project voor de videouitbreiding

stop(); //stop afspelen van de huidige tijdslijn //we linken de movieDisplay aan de movieController en omgekeerd movieDisplay.associateController(movieControls); movieControls.associateDisplay(movieDisplay); //We laden de film op de gegeven url movieDisplay.setMedia("http://192.168.2.3/alleskanbeter.flv"); movieControls.play(); //start afspelen zodra voldoende data geladen is movieControls.controllerPolicy = "on"; //geef uitgebreide bedieningsknoppen weer

//Instellen knop voor weergave tijdscode btn1.label = "TimeCode"; btn1.onRelease = function() { //Ophalen en weergeven van huidige tijdscode van de video textfield.text = movieDisplay.playheadTime; }

Figuur 6.2: Code voor weergeven van video

6.2 Uitvoering

Figuur 6.3: De draaiende testapplicatie voor video in Adobe Device Central

72

OVERSCHOUWINGEN

73

Hoofdstuk 7

Overschouwingen In dit hoofdstuk wordt teruggeblikt op de afgelegde weg om de mobiele PISA-applicatie te realiseren in Flash Lite (sectie 7.1). Ook wordt kort geschetst wat de voornaamste moeilijkheden en verschillen zijn bij het programmeren voor mobiele toestellen (sectie 7.2).

7.1

Programmeren in Flash

De realisatie van dit project liep niet van een leien dakje. Onderweg werd ik geconfronteerd met heel wat moeilijkheden, bugs en een gebrek aan gedegen informatie. Er is over Flash veel informatie te vinden, maar niet de informatie die hier nodig was om een applicatie te structureren en op een overzichtelijke en logische manier op te bouwen. De meeste voorbeelden zijn kleinere projecten, die geen gebruik maken van klassen, en hier en daar kleine losse stukjes code bevatten. Op fora en in tutorials was een vaak terugkerende zin iets als ‘Klik daar op dat en plak daar dan dit stukje code. . . ’. Niet echt een bevredigend antwoord. Hoe en waarom dat op die manier werkte werd nergens uitgelegd. Een tweede moeilijkheid was het verschil in de ActionScript-versie. ActionScript 3.0 werd gelanceerd in 2006, en bijna alle voorbeelden en tutorials die te vinden zijn op internet maken dan ook gebruik van deze versie. ActionScript 3.0 is fundamenteel anders opgebouwd dan versie 2.0 en gebruikt een volledig nieuwe virtuele machine - omschakelen tussen beide versies is dus niet vanzelfsprekend. Ook bibliotheken zoals E4X konden niet gebruikt worden. De doorbraak kwam er met het boek Flash Applications for Mobile Devices [67] waarin een aantal cruciale zaken worden uitgelegd over het ontwikkelen van Flash Lite-applicaties: hoe zo’n

7.1 Programmeren in Flash

74

applicatie best wordt gestructureerd, hoe MovieClips en klassen kunnen samenwerken, hoe en waarom de Delegate klasse gebruikt moet worden voor afhandelen van events, enzovoort. Doordat het boek volledig is toegespitst op mobiele toestellen staan er heel wat handige voorbeelden in en nuttige informatie over onder andere gebruikersinterfaces, opslaan en verwerken van data en interactie met het toestel. Toch kon dit niet beletten dat er heel wat bizarre bugs de kop op staken - die soms op een al even bizarre manier verdwenen. Een kort overzicht. • Bij de eerste testen werd een XML opgehaald van de PISA-dramaproductieserver. Dit verliep feilloos in de emulator, maar reageerde erg wisselend op een echt toestel. De allereerste keer dat de toepassing gestart werd lukte alles, maar bij elke volgende poging kwam er nooit een antwoord. Netwerkanalyse wees uit dat de PDA geen verzoek (HTTP GET) meer verstuurde. Alles werd geprobeerd om dit te verhelpen, maar uiteindelijk bleek een volledig nieuw project, met exact dezelfde code, ineens wel te werken. In het huidige project worden er geen gegevens meer rechtstreeks opgehaald van de productieserver, maar verloopt alle communicatie via de PDAservices. • Een ander probleem kwam voor bij het aanmaken van de ComboBoxen waarmee de camera’s en micro’s geselecteerd worden. Standaard werden die veel te klein weergegeven. In een lus worden die ComboBoxen aangemaakt en ingesteld. Alleen het vergroten van die boxen lukte niet: de setSize(length, width)-methode gaf geen effect. Ook het verplaatsen van die regel (dit was al eens succesvol gebleken) werkte nu niet. Uiteindelijk werd de regel anders geformuleerd. De gebruikelijke notatie cameraBox1.setSize(length, width) werd vervangen door eval("cameraBox"+i).setSize(length, width) met i een getal. De eval-funtie neemt een String als argument, en probeert die te matchen met een object. Hoewel beide notaties in essentie identiek zijn, werkte enkel de tweede. • Op een bepaald moment, toen de opname gestopt werd en de interface voor de continu¨ıteitsrapporten verschijnt, werd alles groen. Elke afbeelding, alle tekst, tekstvelden, knoppen, . . . alles was en bleef groen. Ook toen terug gegaan werd naar een vorige stap (die zopas wel correct werd weergegeven), bleef alles groen. De oplossing was het herschrijven van de code die de chronometer MovieClip verwijdert. De chronometer MovieClip wordt verwijderd met de methode removeMovieClip(), terwijl de MovieClip met de interface voor de continu¨ıteitsrapporten verwijderd moet worden met de destroyObject()-methode.

7.1 Programmeren in Flash

75

• In de pisa.ui.ContinuityReport-klasse werd de methode createClassObject() niet herkend, een methode die nochtans overgeërfd wordt van MovieClip. Een veld createClassObject:Function aanmaken (dat nergens ge¨ınitialiseerd wordt) loste het probleem op. • Bij de weergave van de ComboBoxen stak er nog een probleem de kop op. Sommige werden nu eens niet, dan weer wel weergegeven, soms verdween de lijst als die werd uitgeklapt of werd ze achter een andere ComboBox weergegeven. In Flash heeft elk object dat wordt weergegeven een unieke diepte. Afhankelijk van die diepte worden sommige objecten voor andere weergegeven in geval van overlapping. Om de dieptes niet manueel te moeten regelen is er de getNextHighestDepth()-methode, waarmee Flash automatisch de eerst volgende beschikbare diepte teruggeeft. Maar die methode is kennelijk niet altijd even betrouwbaar. Als oplossing werd manueel een tellertje bijgehouden om de dieptes in te stellen.

Er zitten dus heel wat bugs en onvolmaaktheden in ActionScript 2. Gelukkig werd voor elk probleem uiteindelijk een oplossing gevonden. Op een webpagina [51] waar ActionScript 3 uitvoerig bewierrookt wordt, geeft Adobe zelf de tekortkomingen toe: • ‘. . . ActionScript 2 isn’t as high-performance as it could be’ • ‘. . . the hacks needed to perform event handling’ • ‘. . . filled with so many bugs, hacks, and workarounds’ Tenslotte nog een woordje over excepties in Flash. Die worden niet gesmeten. Als er een regel niet kan uitgevoerd worden, wordt die overgeslagen en wordt verder gegaan met de rest van het programma. Maar kennelijk wordt bij het compileren de uitvoervolgorde van sommige instructies veranderd. Stel dat regel twee een fout geeft, is het mogelijk dat regel 1 ook niet wordt uitgevoerd - terwijl daar geen problemen zijn. Dit bemoeilijkt het debuggen ten zeerste. De Flash-compiler is ook al niet echt behulpzaam en geeft geen compileerfouten bij tikfouten. De boodschap is snel en veel testen: Na elke nieuwe blok code controleren of die naar wens wordt uitgevoerd, en bij twijfel grondig debuggen.

7.2 Programmeren voor mobiele toestellen

7.2

76

Programmeren voor mobiele toestellen

De huidige generatie smartphones en PDA’s zijn krachtig genoeg om meer geavanceerde, interactieve toepassingen aan te kunnen. Door de betere ondersteuning van de nieuwe technologieën - denk aan de aangekondigde releases van JavaFX, Silverlight for Mobile en Android - lijkt het erop dat het ontwikkelen de komende maanden pas echt op kruissnelheid zal komen. Het verschil tussen programmeren voor de desktop en een mobiel toestel zit vooral in de extra beperkingen: functies en bibliotheken die niet beschikbaar zijn, werken met oudere versies met meer bugs en minder documentatie, enzovoort. Ook het ontwerpen van de interface moet extra aandacht krijgen met oog op bedieningsgemak, leesbaarheid, en contrast. Er moet meer dan anders aandacht besteed worden aan zogenaamde fail safes: wat bij een uitvallende batterij of netwerkverbinding, een inkomend telefoongesprek of volrakend geheugen? Tot slot moet er ook uitgebreider gestest worden. Een emulator geeft al een goede eerste indruk, maar toestellen kunnen echter zeer verschillend reageren met betrekking tot bediening en weergave - waardoor er geen volledige garantie is dat een applicatie op elk toestel werkt. Aan het einde van de rit blijf ik achter de keuze voor Flash Lite staan, al hebben de nieuwe werkwijze en de vele bugs de nodige tijd gekost. Maar net daarom was het ook een meer leerrijke ervaring. Een identieke applicatie ontwikkelen met dezelfde gebruikerservaring (interface, animaties, etc.) met een ander raamwerk had volgens mij zeker evenveel tijd in beslag genomen. Waarschijnlijk was er dan minder moeite gekropen in het zoeken naar oplossingen voor bugs, maar des te meer in het creëren van de gebruikersinterface en de animaties. In Flash kun je snel animaties ontwerpen, die bovendien geoptimaliseerd zijn voor een zo efficiënt mogelijke uitvoering. Daarenboven zijn er sterke mogelijkheden tot parallellisme door gebruik te maken van verschillende actieve MovieClips. Ook het gemak waarmee de videofunctionaliteit kan worden toegevoegd is indrukwekkend (sectie 6.2.2). Het beschrijven hoe de videofunctionaliteit kan worden toegevoegd in sectie 6.2.2 duurde meer dan driedubbel zo lang als het volledig implementeren en testen (ook op de HTC Touch Pro) van de videotestapplicatie.

BESLUIT

77

Hoofdstuk 8

Besluit In deze masterproef is er een uitbreiding voorgesteld om het PISA-dramaproductiesysteem inzetbaar te maken op locatie. Een inconsistente workflow - het PISA-dramaproductiesysteem in de studio, papierwerk op locatie - wordt op die manier vermeden. Als uitbreiding is een stand alone applicatie ontwikkeld voor gebruik op een smartphone of PDA. In deze implementatie zijn twee belangrijke functies opgenomen: de acquisitiefunctie voor starten en stoppen van de opnames en het toevoegen van continu¨ıteitsrapporten, en het lezen van scenario’s. Er zijn nog vele andere nuttige functies voor de applicatie denkbaar, maar die werden nog niet ge¨ımplementeerd. Daarbij wordt bijvoorbeeld gedacht aan het bewerken van scenario’s, het toevoegen van opmerkingen of ideëen voor montage, regie of locaties, het herbekijken van opgenomen takes voor het aanduiden van interessante punten (‘cuepoints’) voor de post-productie, enzovoort. De ondersteuning van video door de applicatieraamwerken bleek te beperkt om nu al te integreren in de applicatie. De communicatie tussen de PISA-dramaproductieserver en het draagbaar toestel verloopt via de PDAservices. Deze webservices maken gebruik van WSDL, HTTP en SOAP. Op die manier kan enkel d´ıe informatie verstuurd worden die het programma nodig heeft, en wordt het aantal connecties en hoeveelheid verstuurde data geminimaliseerd. Elke denkbare functie kan ge¨ımplementeerd worden via webservices. Het toestel wordt daarbij zoveel mogelijk ontlast. De PDAservices communiceren via REST-services met de PISA-dramaproductieserver, en geven de informatie ook in XML-formaat terug. Bij het starten van de opnames op de ingestserver wordt een ID uitgewisseld. Als de verbinding met de PDA na het starten van de opnames zou wegvallen, kan de ID later alsnog gebruikt worden om de lograpporten en het opgenomen

BESLUIT

78

beeldmateriaal aan elkaar te linken. Als applicatieraamwerk voor de mobiele PISA-applicatie werd na een praktijktest gekozen voor Flash Lite boven Java ME. De uitgebreidere testomgeving (Adobe Device Central) en de vele mogelijkheden voor de gebruikersinterface gaven het voordeel aan Flash Lite. In de toekomst is het vooral uitkijken naar JavaFX. De keuze voor Flash Lite bracht een nieuwe manier van werken met zich mee door het werken met de tijdslijn. Het gros van de informatie en voorbeelden die op internet beschikbaar zijn, volstonden niet om inzicht te krijgen hoe de applicatie het best kon worden opgebouwd en gestructureerd. Veelal waren de voorbeelden geschreven in ActionScript 3, dat fundamenteel anders is opgebouwd dan de tweede versie die Flash Lite gebruikt. Uiteindelijk kwam de ontwikkeling in een stroomversnelling met een boek specifiek over het ontwikkelen van Flashapplicaties voor mobiele toestellen. Toch doken tijdens de ontwikkeling heel wat vervelende bugs en onvolmaaktheden op - gelukkig werd voor elk probleem een passende oplossing gevonden. De onwikkelde applicatie biedt in ieder geval een proof of concept van een mobiele uitbreiding, en kan mits nog een aantal kleine toevoegingen (onder andere het starten van de opnames op de ingestserver) effectief ingezet worden in een productie-omgeving. Ook latere uitbreidingen zijn zeker mogelijk met het huidig ontwerp in Flash Lite, al moet dan eerst gezorgd worden voor een beter geheugengebruik en betere prestaties bij de DataGrid en ComboBoxen. Met de nodige kennis is het in Flash in ieder geval mogelijk om in een snel tempo een degelijke mobiele toepassing te ontwikkelen, met de nodige toeters en bellen. De moeilijkheid in het ontwikkelen van applicaties voor mobiele toestellen zit in de beperkingen: oudere versies waardoor bepaalde bibliotheken niet gebruikt kunnen worden, minder degelijke informatie beschikbaar, meer bugs. De huidige prestaties van de toestellen laat in ieder geval complexere multimedia-applicaties toe. Het belang van mobiele applicaties zal in de toekomst zeker in sneltempo toenemen, geruggesteund door de nakende release van nieuwe applicatieraamwerken als Silverlight en JavaFX for mobile. Met deze masterproef zet het PISA-project alvast een stap in de richting van de mobiele toekomst.

BIBLIOGRAFIE

79

Bibliografie [1] Adobe Flash Lite. http://www.adobe.com/products/flashlite/. [2] Adobe Flash Media Server. http://www.adobe.com/products/flashmediaserver/. [3] Adobe Flex 3. http://www.adobe.com/nl/products/flex/. [4] Adobe Forums: Flash Lite and Flex. http://forums.adobe.com/thread/28126?tstart= 0. [5] Adobe Labs - Distributable Player Solution. http://labs.adobe.com/technologies/ distributableplayer/. [6] Android. http://www.android.com/. [7] Apache Axis. http://ws.apache.org/axis/. [8] Apache Tomcat. http://tomcat.apache.org/. [9] Avid. http://www.avid.com. [10] D. Van Rijsselbergen, M. Verwaest, B. Van de Keer and R. Van de Walle, Introducing the data model for a centralized drama production system, Multimedia and Expo, 2007 IEEE International Conference, pp. 615-618, Beijing, China, 2-5 Jul. 2007. [11] DataGrid

performance

strategies.

http://livedocs.adobe.com/flash/8/main/

00003253.html. [12] The E4X approach to XML processing. http://livedocs.adobe.com/flash/9.0/main/ 00000124.html. [13] Eclipse. http://www.eclipse.org/.

BIBLIOGRAFIE

80

[14] Edit decision list. http://nl.wikipedia.org/wiki/Edit_decision_list. [15] ETRO-VUB. http://www.etro.vub.ac.be/. [16] European Broadcasting Union. http://www.ebu.ch/. [17] Evs.tv Instant Tapeless Technology. http://www.evs.tv/. [18] Expertise centre for Digital Media. http://www.edm.uhasselt.be/. [19] Eyetronics. http://www.eyetronics.com/. [20] Flash CS3 Documentation.

http://livedocs.adobe.com/flash/9.0/main/wwhelp/

wwhimpl/js/html/wwhelp.htm. [21] Flex 3 - Working with external data. http://livedocs.adobe.com/flex/3/html/17_ Networking_and_communications_3.html. [22] Hibernate. http://www.hibernate.org/. [23] HTC

Touch

Pro

specifications.

http://www.htc.com/nl/product/touchpro/

specification.html. [24] HttpClient. http://hc.apache.org/httpclient-3.x/. [25] IBBT. http://www.ibbt.be/. [26] Java ME. http://java.sun.com/javame/index.jsp. [27] JavaFX Partners. http://javafx.com/partners/. [28] JavaServer Faces Technology. http://java.sun.com/javaee/javaserverfaces/. [29] JDOM. http://www.jdom.org/. [30] KU Leuven PSI. http://www.esat.kuleuven.ac.be/psi. [31] Kulak. http://www.kuleuven-kortrijk.be/nl/KULAK/indexF.htm. [32] Multimedia Lab. http://multimedialab.elis.ugent.be/. [33] MySQL. http://www.mysql.com/.

BIBLIOGRAFIE

81

[34] .NET Compact Framework.

http://msdn.microsoft.com/nl-nl/library/f44bbwa1%

28en-us%29.aspx. [35] Opera Mobile. http://www.opera.com/mobile/. [36] P. Jackson, The Fellowship of the Ring, Special extended edition, DVD, New Line Cinema, New York, 2002, 208 minutes. [37] Qt - A cross-platform application and UI framework. http://qt.nokia.com/. [38] RESTClient. http://code.google.com/p/rest-client/. [39] Silverlight faq. http://www.microsoft.com/silverlight/overview/faq.aspx. [40] Silverlight for mobile. http://silverlight.net/learn/mobile.aspx. [41] Soap Specifications. http://www.w3.org/TR/soap/. [42] Soap UI: the Web Services Testing tool. http://www.soapui.org/. [43] Supported HTML tags in Flash Lite. http://livedocs.adobe.com/flash/mx2004/main_ 7_2/00001040.html. [44] VRT-medialab. http://www.vrtmedialab.be/. [45] Wikimedia Commons. http://commons.wikimedia.org/wiki/Hoofdpagina. [46] XPath for ActionScript. http://www.xfactorstudio.com/. [47] David Austerberry. Digital Asset Management. Focal Press, 2004. [48] BBC. BBC R&D Production Automation Video. http://downloads.bbc.co.uk/rd/ pubs/whp/whp-pdf-files/whp133-downloads/BBC_RD_Production_Automation_2006. avi, 2006. video file. [49] S. Bernstein. Film production. Focal Press, second edition, 1994. [50] S. Bracke. Programmeren voor de IPhone. PC Magazine, 11(116):pp. 107–113, september 2008. [51] L. Brimelow.

Six reasons to use ActionScript 3.0.

actionscript/articles/six_reasons_as3.html.

http://www.adobe.com/devnet/

BIBLIOGRAFIE

82

[52] British Broadcasting Corporation. SMEF Data Model v1.10, 2004. [53] Eric Oosthoek en Ab Revoort. Basisboek televisie maken. Wolters-Noordhoff, 2003. [54] Lynda Hardman et al. Canonical Processes of Semantically Annotated Media Production, 2006. [55] R.H. Evans and R.R. Bills. FLOORMAN - freeing the director from the production gallery. http://www.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP121.pdf, 2005. [56] EVS.tv. Dramas and Entertainment Production. http://www.evs.tv/01/MyDocuments/ CS_TVB-HONG-KONG_0308_ASIA.pdf, march 2008. [57] Syd Field. Hoe schrijf ik een scenario? Het Wereldvenster, Amsterdam, 1988. [58] R.T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Master’s thesis, University of California, Irvine, 2000. http://www.ics.uci.edu/ ~fielding/pubs/dissertation/top.htm. [59] J. Fletcher, D.G. Kirby, and S.H. Cunningham.

Tapeless and paperless:

automa-

ting the workflow in tv studio production. http://www.bbc.co.uk/rd/pubs/whp/whp-pdffiles/WHP141.pdf, 2006. [60] M. De Geyter, B. Muylaert, N. Oorts, P. Soetens, B. Van De Keer, and D. Van Rijsselbergen. ASAP Research Program, 2008. [61] M. De Geyter, N. Oorts, and L. Overmeire. File-based broadcast workflows on MAM systems and their integration demands. SMPTE Motion Imaging Journal, pages 38–46, 2008. [62] T. Gilroy.

The Bourne Ultimatum.

http://awards.universalpictures.com/pdf/

bourne.pdf, 2007. [63] IBBT. FIPA Milestone Meetings, 2005-2006. unpublished presentations. [64] Peter Kassenaar. Handboek Flash CS3. Van Duuren Media, 2007. [65] Steven D. Katz. Film directing shot by shot. Michael Wiese, 1991. [66] P. Van Leemputten. Eerste Android-toestel voor België. http://www.zdnet.be/news/ 102343/eerste-android-toestel-voor-belgie/, 2009.

BIBLIOGRAFIE

83

[67] Richard Leggett, Weyert de Boer, and Scott Janousek. Flash Applications for Mobile Devices. friends of ED, 2006. [68] Sun Microsystems.

Sun Microsystems unveils JavaFX 1.0.

http://www.sun.com/

aboutsun/pr/2008-12/sunflash.20081204.1.xml. [69] Gerald Millerson. Video Production Handbook. Elsevier, third edition, 2001. [70] J. Van Oost. Sun toont nieuwe versie Javafx. http://www.zdnet.be/techzone/103338/ sun-toont-nieuwe-versie-javafx/, 2009. [71] P. Panigrahi. Memory management and optimizations in Flash Lite. http://www.adobe. com/devnet/devices/articles/memory_management.html. [72] D. Van Rijsselbergen. PISA Production, Indexing and Search of Audio-visual Material. http://www.vrtmedialab.be/media/pres_dvr_20080926_pisa.pdf, september 2008. [73] D. Van Rijsselbergen and B. Van de Keer. Drama Application Architecture PoC1, 2006. unpublished. [74] D. Van Rijsselbergen and B. Van de Keer. Drama Application Architecture PoC2, 2006. unpublished. [75] D. Van Rijsselbergen, B. Van de Keer, and R. Van de Walle. The canonical expression of the drama product manufacturing processes. Springer-Verlag, 2008. [76] S. Robinson. ments

in

Q1

Flash Lite-Enabled Handsets to Top 1 Billion Cumulative Ship2009.

http://www.strategyanalytics.com/default.aspx?mod=

ReportAbstractViewer&a0=4483, 2009. [77] P.N. Tudor and S.H. Cunningham. Improving workflow in practice for low-cost programmemaking using MXF & AAF file formats. http://www.bbc.co.uk/rd/pubs/whp/whp-pdffiles/WHP133.pdf, 2006. [78] European Broadcasting Union. P Meta 2.0 Metadata Library specification. http://www. ebu.ch/CMSimages/en/tec_doc_t3295v2-2007_tcm6-53551.pdf, 2007. [79] Bob van Duuren. Flash CS3 ActionScript. Van Duuren Media, 2008. [80] Vrtmedialab.

IBBT bestandsgebaseerde videoproductie.

watch?v=Wev9yuztc80. internet video.

http://www.youtube.com/

BIBLIOGRAFIE

[81] Vrtmedialab.

84

Pisa.

http://www.vrtmedialab.be/index.php/nederlands/project/

project_p_pisa/. [82] Vrtmedialab. Scoop. http://www.youtube.com/watch?v=cc_xQN7iyZo. internet video.

LIJST VAN FIGUREN

85

Lijst van figuren

2.1

Ingekorte scène uit het scenario van The Bourne Ultimatum . . . . . . . . . . . .

5

2.2

Voorbeeld van een storyboard uit The Lord of the Rings . . . . . . . . . . . . . .

6

2.3

Schermafbeelding van de 3D-previsualisatie applicatie Scoop . . . . . . . . . . . .

8

3.1

Overzicht van de voorgestelde oplossing . . . . . . . . . . . . . . . . . . . . . . .

12

3.2

Weergave van een scenario in het PISA-dramaproductiesysteem . . . . . . . . . .

14

4.1

Architectuur van Proof Of Concept II . . . . . . . . . . . . . . . . . . . . . . . .

19

4.2

Het gelaagde dramaproductieproces

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

20

4.3

Klassediagram van Editorial Objects . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.4

Ingekorte XML-representatie van een Episode . . . . . . . . . . . . . . . . . . . .

21

4.5

Klassediagram van Components . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.6

Klassediagram van Components, Realizations en Media Objects . . . . . . . . . .

22

4.7

XML-representatie van een episode-query . . . . . . . . . . . . . . . . . . . . . .

24

4.8

XML-response van een Episode-query . . . . . . . . . . . . . . . . . . . . . . . .

24

4.9

Opstelling voor gebruik van het PISA-dramaproductiesysteem met een PDA . . .

34

4.10 Klassediagram van de PDAservices . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.11 Klassediagram van de package datamodel . . . . . . . . . . . . . . . . . . . . . .

37

4.12 Klassediagram van de package query . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.13 Packagediagram van de Flash-applicatie . . . . . . . . . . . . . . . . . . . . . . .

38

4.14 Klassediagram van de package acquisition . . . . . . . . . . . . . . . . . . . . . .

39

LIJST VAN FIGUREN

86

4.15 Klassediagram van de package datamodel . . . . . . . . . . . . . . . . . . . . . .

40

4.16 Klassediagram van de package datamodel.xmlparser . . . . . . . . . . . . . . . .

42

4.17 Klassediagram van de package externalcomm . . . . . . . . . . . . . . . . . . . .

43

4.18 Klassediagram van de package util . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.19 Klassediagram van de package ui . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.20 Sequentiediagram voor het ophalen van een synopsis . . . . . . . . . . . . . . . .

46

4.21 Sequentiediagram voor het starten en stoppen van een opname . . . . . . . . . .

47

5.1

Mogelijke opslossing voor verbetering van de tijdssynchronisatie . . . . . . . . . .

50

5.2

De gebruikersinterface van de mobiele PISA-applicatie op een PDA . . . . . . . .

54

5.3

Voorbeeld van een klasse in ActionScript syntax . . . . . . . . . . . . . . . . . .

55

5.4

De tijdslijn van de Flash-applicatie . . . . . . . . . . . . . . . . . . . . . . . . . .

56

5.5

Voorbeeld van een fetch-methode . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

5.6

Eigenschappen van de Movieclip ContinuityReport . . . . . . . . . . . . . . . . .

57

5.7

Schermafbeelding van het startscherm van de mobiele PISA-applicatie . . . . . .

59

5.8

Schermafbeelding van de weergave van een scenario . . . . . . . . . . . . . . . . .

60

5.9

Schermafbeelding van de mobiele PISA-applicatie tijdens een opname . . . . . .

62

5.10 Gebruikersinterface voor het invoeren van een continu¨ıteitsrapport . . . . . . . .

63

5.11 Emulatie van de mobiele PISA-applicatie op een Nokia E71 in Adobe Device Central 64 6.1

Schermafbeelding van het Flash-project voor de videouitbreiding . . . . . . . . .

71

6.2

Code voor weergeven van video . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.3

De draaiende testapplicatie voor video in Adobe Device Central . . . . . . . . . .

72

LIJST VAN TABELLEN

87

Lijst van tabellen

4.1

HTTP-methodes en hun functie bij REST-services . . . . . . . . . . . . . . . . .

23

4.2

Voor- en nadelen van mobiele raamwerken . . . . . . . . . . . . . . . . . . . . . .

32

6.1

Gemiddelde wachttijd en geheugengebruik voor de mobiele PISA-applicatie . . .

68

Uitbreiding van het PISA-dramaproductiesysteem voor locatieshoots met behulp van PDAs

Recommend Documents