Praktische Studie en Analyse van het QuickTime Raamwerk

Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter : Prof. dr. ir. J. Van Campenhout

Praktische Studie en Analyse van het QuickTime Raamwerk door Wesley De Neve

Promotor : Prof. dr. ir. R. Van de Walle Thesisbegeleider : lic. B. Rogge Afstudeerwerk ingediend tot het behalen van de academische graad van LICENCIAAT IN DE INFORMATICA Academiejaar 2001-2002

“De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te copi¨eren 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 dit afstudeerwerk.”

Wesley De Neve, 27 mei 2002

i

Dankwoord

Het zijn tal van mensen die er, rechtstreeks of onrechtstreeks, voor gezorgd hebben dat dit afstudeerwerk hier voor u ligt. Mijn dankbaarheid gaat dan ook uit naar alle personen die mij onderweg met tal van woorden, idee¨en en daden hebben gesteund en begeleid. Toch zijn er enkele mensen die onrecht zou worden aangedaan indien ze niet vernoemd werden. Hierbij denk ik in de eerste plaats aan mijn ouders, die een ideale omgeving cre¨eerden om deze studies te volbrengen. Ook de begeleiders van dit afstudeerwerk, Lic. B. Rogge en Prof. dr. ir. R. Van de Walle, mogen zeker niet ontbreken. Zij waren steeds bereid om samen met mij te zoeken naar een antwoord op ´e´en van mijn talloze vragen en hebben mij ook de mogelijkheden geboden om heel wat bij te leren. Tot slot wil ik ook nog alle mensen bedanken die mij met raad en daad hebben bijgestaan via verschillende QuickTime mailinglijsten, in het bijzonder vermeld ik hier Greg Chapman, Kevin Marks, Tom Dowdy, Chris LeCroy, Mike Dodd, John Anderson, Dean Perry, Steve Nicolai, Roy Lovejoy, Mark Fleming, George Birbilis, Robert G. Palmer Jr., Joel Hedden, Kuniyoshi Murata, Scott Thompson en Bruce Wheaton.

”Although Windows and Macintosh programmers used to live on different planets, with respect to QuickTime they belong to one family.”(George Towner)

ii

Praktische Studie en Analyse van het QuickTime Raamwerk door Wesley De Neve

Afstudeerwerk ingediend tot het behalen van de academische graad van LICENCIAAT IN DE INFORMATICA Academiejaar 2001-2002 Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter : Prof. dr. ir. J. Van Campenhout Promotor : Prof. dr. ir. R. Van de Walle Thesisbeleider : lic. B. Rogge Samenvatting Deze thesis beschrijft QuickTime, een krachtige multimediatechnologie die gebruikt wordt voor het manipuleren van video, geluid, animatie, afbeeldingen, tekst, muziek, en zelfs 360-graden virtuele realiteit. Ook het stromen van beeld en geluid maakt deel uit van het dienstenpakket van QuickTime. Als technologie die aanwezig is op meerdere platformen laat het toe multimediapresentaties te vertonen aan een zeer groot aantal gebruikers. Deze voorstellingen worden afgeleverd aan de hand van ´e´en enkele structuur, een movie. Een groot deel van de scriptie zal handelen over de idee¨en die schuil gaan achter de QuickTime movie architectuur, waaronder de manier waarop tijd door movies gemeten wordt. Verder zal er ook stilgestaan worden bij de modulaire opbouw van QuickTime en de wijze waarop data door QuickTime in een bestand gestructureerd wordt. In een volgend deel wordt de integratie van netwerkdiensten in Apple’s multimediatechnologie besproken. Bijzondere aandacht zal geschonken worden aan het stromen van data. Er zal eveneens gekeken worden naar de mogelijkheden die QuickTime biedt op het vlak van interactie tussen gebruikers en movies. De theorie werd aan de praktijk getoetst door het schrijven van een API bovenop de functiebibliotheek van QuickTime. Deze interface werd vervolgens getest met een zelfontwikkelde applicatie, Atomic Player. De precieze werking van de API en de testapplicatie worden in het laatste deel besproken. Trefwoorden : QuickTime, bestandsformaat, streaming, XML, multimedia

iii

Inhoudsopgave 1 Inleiding 1.1 De wereld van QuickTime 1.2 Doelstellingen . . . . . . . 1.3 Verantwoording . . . . . . 1.4 Onderzochte aspecten . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 De 2.1 2.2 2.3 2.4

QuickTime Architectuur De QuickTime API . . . . . . . . . . . . . . Enkele definities . . . . . . . . . . . . . . . . QuickTime als vijflagige architectuur . . . . Transformaties, layering en grafische modes . 2.4.1 Clipping . . . . . . . . . . . . . . . . 2.4.2 Bewerkingen met matrices . . . . . . 2.4.3 Actieve en passieve tracks . . . . . . 2.4.4 Track layering . . . . . . . . . . . . . 2.4.5 Grafische modi . . . . . . . . . . . . 2.5 Grafische bibliotheken en datastructuren . . 2.6 Compressie . . . . . . . . . . . . . . . . . . 2.6.1 Situering . . . . . . . . . . . . . . . . 2.6.2 Afwegingen . . . . . . . . . . . . . . 2.6.3 Enkele algemene technieken . . . . . 2.7 Moviebestanden op meerdere platformen . . 2.7.1 Het vlak maken van movies . . . . . 2.7.2 Endian conversies . . . . . . . . . . .

3 Movies in Tijd en Ruimte 3.1 Situering . . . . . . . . . . . . . . . . 3.2 De relativiteit van tijd. . . . . . . . . 3.3 Movietijd, mediatijd en tijdsbasissen. 3.3.1 Movietijd . . . . . . . . . . . 3.3.2 Mediatijd . . . . . . . . . . . 3.3.3 Tijdsbasissen . . . . . . . . . 3.3.4 Voorbeeld . . . . . . . . . . .

iv

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

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

. . . . . . .

. . . .

1 1 2 2 3

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

5 5 7 10 11 12 14 14 15 15 17 22 22 23 24 25 26 28

. . . . . . .

30 30 31 32 33 34 34 35

3.4 3.5 3.6 3.7

De relativiteit van beelden en beeldsnelheden . Interessante tijden . . . . . . . . . . . . . . . Tijd en beeld in de praktijk. . . . . . . . . . . De creatie van een movie . . . . . . . . . . . .

4 QuickTime Componenten 4.1 Inleiding . . . . . . . . . . . . . . . . . . . 4.2 Het beheer van componenten . . . . . . . . 4.3 Enkele belangrijke componenten . . . . . . 4.3.1 De Movie Toolbox . . . . . . . . . 4.3.2 Movie Controllers . . . . . . . . . . 4.3.3 Movie Data Exchange componenten 4.3.4 Media Handlers . . . . . . . . . . . 4.3.5 Video-effecten . . . . . . . . . . . . 4.4 Praktisch voorbeeld . . . . . . . . . . . . . 5 Het QuickTime Bestandsformaat 5.1 Atomen . . . . . . . . . . . . . . . . . . . 5.1.1 Klassieke atomen . . . . . . . . . . 5.1.2 QT atomen . . . . . . . . . . . . . 5.1.3 QT atoomcontainers . . . . . . . . 5.2 De structuur van een QuickTime bestand . 5.3 Beveiliging . . . . . . . . . . . . . . . . . . 5.3.1 Gebruikersdata . . . . . . . . . . . 5.3.2 Gebruikte technieken . . . . . . . . 5.4 Referentie movies en clientnegotiatie . . . 5.5 Enkele nuttige voorbeelden en scenario’s . 5.5.1 Werken met samples . . . . . . . . 5.5.2 Spelen met atomen . . . . . . . . . 5.5.3 De creatie van movies. . . . . . . . 5.5.4 Werken met edit lists . . . . . . . . 5.5.5 Data interleaving . . . . . . . . . . 5.5.6 Meerdere databestanden gebruiken 5.5.7 XMLT-componenten . . . . . . . . 6 Netwerkdiensten 6.1 Movies aanbieden via een webpagina . . 6.1.1 Linking . . . . . . . . . . . . . . 6.1.2 Embedding . . . . . . . . . . . . 6.2 Enkele netwerktechnieken . . . . . . . . 6.3 Ware-tijdsstroming . . . . . . . . . . . . 6.3.1 Situering . . . . . . . . . . . . . . 6.3.2 Het real-time streaming protocol

v

. . . . . . .

. . . . . . . . .

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

. . . . . . .

. . . . . . . . .

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

. . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

36 39 40 43

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

48 48 50 52 52 53 54 55 56 58

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

63 63 64 65 66 67 71 71 72 73 75 75 81 82 83 86 87 89

. . . . . . .

92 92 92 93 93 94 94 95

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

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

. . . . . . .

6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8 6.3.9

Het real-time transport protocol . . . . . . . . Unicast, multicast en relaying . . . . . . . . . Ware-tijdsstroming of progressief downloaden Openen van streaming movies . . . . . . . . . Een movie klaarmaken voor stroming . . . . . Media packetizers en reassemblers . . . . . . . Het formaat van een hintspoor . . . . . . . . .

7 Interactiviteit 7.1 Virtuele Realiteit . . . . . . . 7.1.1 Objectknopen . . . . . 7.1.2 Panoramische knopen . 7.2 Sprites en wired movies . . . . 7.3 AppleScript . . . . . . . . . . 7.4 SMIL . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

8 Praktische Aspecten 8.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . 8.2 QuickTime gebruiken in een applicatie . . . . . . . . . 8.3 CQuickTime: functies en aanverwante datastructuren . 8.3.1 Member variabelen van een CQuickTime object 8.3.2 Member functies van een CQuickTime object . 8.3.3 De XMLT-componentfuncties . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . . .

95 98 99 101 104 106 107

. . . . . .

110 . 110 . 111 . 112 . 113 . 114 . 115

. . . . . .

118 . 118 . 118 . 120 . 120 . 120 . 128

9 Besluit

130

A Afkortingen

131

B Volledige opbouw van een movie

133

vi

Hoofdstuk 1 Inleiding In dit hoofdstuk zal ik een algemeen beeld trachten te schetsen van de filosofie die schuil gaat achter QuickTime. Verder zal ik ook wat uitleg geven bij een aantal doelstellingen die ik via het maken van deze thesis heb proberen te realiseren.

1.1

De wereld van QuickTime

Velen hebben waarschijnlijk reeds gebruik gemaakt van de QuickTime mediaspeler of van de QuickTime browser plug-in voor het beluisteren of bekijken van een multimediavoorstelling. Wat weinigen echter weten is dat dit slechts het topje vormt van een gigantische ijsberg. QuickTime staat immers voor meer dan zomaar een mediaspeler. Een aanzet tot de formulering van een antwoord op de vraag naar wat QuickTime nu eigenlijk is, kan misschien gevonden worden in een overlevering uit de geschiedenis van de Hindu’s. Deze verhaalt over vier blinde mannen die als opdracht hadden op de tast een olifant te beschrijven. Uiteraard kwam ieder van hen op de proppen met een totaal andere beschrijving, en uiteindelijk kon niemand uitmaken met welk dier ze te maken hadden. QuickTime is zoals deze olifant. Voor sommigen is het een universele multimediaspeler, voor anderen is het een animatiesysteem, en nog voor anderen is het een gereedschapskist die kan gebruikt worden om een multimediatoepassing te cre¨eren. Het volledig begrijpen van alle componenten en alle API oproepen die QuickTime defini¨eren, is echter een moeilijke en tijdrovende taak. Het modulair softwaremodel dat door QuickTime gehanteerd wordt laat gelukkig toe gebruik te maken van de functionaliteit van QuickTime zonder dat daartoe alles moet begrepen worden. Op die manier is het mogelijk om vanuit een applicatie QuickTime aan te spreken met slechts een beperkt aantal lijnen code. Dankzij QuickTime kan men dus de mogelijkheden van een toepassing op het gebied van multimedia zeer sterk uitbreiden. Hierbij kan er gedacht worden aan de creatie, bewerking en presentatie van al dan niet gecomprimeerde mediabestanden van bijna eender welk type. Men kan eveneens denken aan het toevoegen van professionele video- en

1

audio-effecten en het op een eenvoudige manier omspringen met virtuele realiteit. Het grote voordeel hierbij is dat QuickTime de applicatieprogrammeur zoveel mogelijk zal afschermen van implementatie- en compatibiliteitsproblemen. De programmeur beschrijft met een gelimiteerd aantal lijnen code wat er moet gerealiseerd worden, en QuickTime zal zelf uitzoeken hoe dit het best kan gedaan worden.

1.2

Doelstellingen

Na bovenstaande inleiding doorgenomen te hebben, is het duidelijk geworden dat QuickTime heel wat in zijn mars heeft betreffende het werken met multimedia. Bovendien zal QuickTime deze diensten op een zo eenvoudig mogelijke manier ter beschikking stellen van een gebruiker. Toch is er nog ruimte over voor verbetering en een eerste doelstelling is dan ook een zekere abstractie te maken van de QuickTime Application Programming Interface (API). Concreet betekent dit dat het de bedoeling is om bovenop de QuickTime API een eigen interface te ontwikkelen, zodanig dat iemand die gebruik maakt van de zelfgeschreven API slechts een minimale kennis nodig heeft van QuickTime en multimedia. Zo hoeft een potenti¨ele gebruiker van de nieuwe (Windows) API helemaal niet te weten dat het Macintosh besturingssysteem onder andere opgebouwd is aan de hand van een dubbelgevorkt bestandssysteem en dat QuickTime omwille van zijn Macintosh origine standaard gebruik maakt van QuickDraw om naar het scherm te tekenen. Een andere doelstelling is het verwerven van een zeker inzicht in het QuickTime raamwerk, en dit zowel vanuit theoretisch als empirisch perpectief. Op theoretisch vlak zijn het door QuickTime gebruikte tijdsmechanisme en bestandsformaat heel belangrijk. Vanuit praktisch opzicht is vooral het werk rond het ontwikkelen van een aantal eigen componenten voor het uitwisselen van XML-data met een QuickTime movie interessant.

1.3

Verantwoording

Naast Apple zijn er nog tal van andere bedrijven intensief bezig met het ontwerpen en commercialiseren van nieuwe multimediatechnologie¨en. Hierbij kan men onder meer denken aan Microsoft en RealNetworks, in dit domein respectievelijk bekend voor o.a. de Windows Media Player en RealPlayer. Een logische vraag die zich nu opdringt is waarom er niet voor ´e´en van deze alternatieven gekozen werd. Een eerste verklaring is heel eenvoudig: het stond namelijk zo in de opgave. Toch zijn er nog een aantal andere factoren die eveneens hun gewicht in de schaal werpen, namelijk: • QuickTime is een vrij open technologie die op meerdere platformen beschikbaar is en gekenmerkt wordt door een zeer grote verspreiding. Een typisch voorbeeld hiervan

2

is de Darwin Streaming Server waarvan de broncode volledig vrijgegeven werd door Apple, op de code van een aantal testprogramma’s na. Dit maakt het mogelijk de betreffende server te installeren onder besturingssystemen zoals Windows, Solaris, Free BSD en talloze anderen. Bovendien houdt Apple zich meestal heel strikt aan de standaarden waardoor het bijvoorbeeld mogelijk is om een MP3-broadcast, verzorgd door de Darwin Streaming Server, te beluisteren via een speler zoals Winamp. • QuickTime is in staat om de meest gangbare dataformaten en mediatypes te herkennen en te interpreteren. • Door de modulaire architectuur is het relatief eenvoudig om QuickTime uit te breiden met een eigen dataformaat of extra functionaliteit. Hierdoor is het in principe mogelijk om eender welke mediatype en dataformaat, waarvan de specificaties vrijgegeven zijn, toe te voegen aan QuickTime. Uiteraard kan dit ook onder een gesloten vorm. • Het QuickTime bestandsformaat en een aantal andere concepten zoals hinttracks vormen de basis voor MPEG-4, een nieuwe multimediastandaard die op het punt staat door te breken maar die op het moment van schrijven geteisterd wordt door een aantal licentieperikelen.

1.4

Onderzochte aspecten

Algemeen bekeken bestaat dit werk uit twee grote delen, zijnde enerzijds een studie van de fundamenten van QuickTime, en anderzijds een praktische evaluatie van het multimediaraamwerk a.d.h. van een eigen API en een bijhorende testapplicatie. In hoofdstuk 2 wordt aandacht besteed aan de QuickTime architectuur. Er zal een overzicht gepresenteerd worden van een aantal belangrijke concepten en er zal ook wat meer informatie verstrekt worden over de omgeving waarin QuickTime ontstaan is. Vervolgens zal er in hoofstuk 3 dieper ingegaan worden op het gebruik van tijd door een movie. Er zal eveneens onderzoek gevoerd worden naar de precieze opbouw van deze uiterst belangrijke structuur. Hoofdstuk 4 behandelt de modulaire opbouw van QuickTime, dewelke van QuickTime een toekomstgerichte technologie maakt. Er zal dieper ingegaan worden op de werking van enkele belangrijke componenten, waaronder enkele zelfgeschreven componenten die het mogelijk maken XML-data uit te wisselen met een QuickTime movie. In hoofdstuk 5 wordt er uitvoerig ingegaan op het QuickTime bestandsformaat. Via enkele praktische voorbeelden en scenario’s wordt getracht om de ge¨ıntroduceerde begrippen te verduidelijken.

3

Verder wordt in hoofdstuk 6 de integratie aangekaart van QuickTime in de hedendaagse netwerktechnologie¨en. Er zal vooral aandacht geschonken worden aan de mogelijkheden van QuickTime op het gebied van stroming. Hoofdstuk 7 richt zich op de interactie tussen een gebruiker en QuickTime movies. Virtuele realiteit, sprites en wired movies, AppleScript en SMIL zijn de onderwerpen die in dit hoofdstuk aan bod komen. Tot slot zal hoofdstuk 8 zich uitsluitend concentreren op de praktische kant van mijn werk. Concreet zal er een blik geworpen op de zelfontworpen interface en de bijhorende testapplicatie, zijnde Atomic Player.

4

Hoofdstuk 2 De QuickTime Architectuur Dit hoofdstuk heeft als bedoeling de lezer wat meer vertrouwd te maken met de QuickTime architectuur. Er zullen een aantal belangrijke concepten toegelicht worden en er zal ook meer informatie verstrekt worden over de omgeving waarin QuickTime ontstaan is, zijnde het Macintosh besturingssysteem. Ik zal mijn uiteenzetting starten met een situering van de QuickTime API.

2.1

De QuickTime API

De QuickTime API ([Inc01b]) is een bibliotheek van functies en datastructuren die kan aangesproken worden vanuit een hogere programmeertaal, zoals Java of C++, en dit om aan controle te doen van tijdsgebaseerde mediadata. Dit is data die in de loop der tijd verandert of interageert met een gebruiker. Men heeft het in deze context ook wel eens over dynamische media. Met controle van tijdsgebaseerde data wordt bedoeld dat het via de API mogelijk is om bijvoorbeeld vanuit een zelfgeschreven applicatie een beeld- of een geluidsfragment te editeren en af te spelen. In feite hebben toepassingen toegang tot zo’n 1200 functies en aanverwante datastructuren. Daarnaast kan QuickTime data importeren en exporteren in meer dan 70 formaten, waaronder de meest gebruikte transport- en compressieformaten. De ontwikkeling van de QuickTime bibliotheek werd gestart in het begin van de jaren ’90 door Apple Computer Inc. en is nog steeds niet be¨eindigd. Gezien het tijdstip waarop met de ontwikkeling begonnen werd, is het niet verwonderlijk dat ´e´en van de eerste belangrijke evoluties bestond uit de overschakeling van zwart-wit beelden naar beelden met kleur. Tegenwoordig werkt men aan een geleidelijke introductie van 64-bits datatypes en is men eveneens druk bezig met de introductie van XML en de uitbouw van functionaliteiten voor stroming. Het invoeren van 64-bits datatypes is noodzakelijk omwille van de steeds groter wordende multimediabestanden. Deze kunnen in sommige gevallen de grens van 232 bytes (4

5

Gigabyte) overschrijden. Denk hierbij bijvoorbeeld aan de situatie waarin een QuickTime bestand gebruikt wordt als databank voor de opslag van stilstaande beelden. Dit was aanvankelijk problematisch voor QuickTime aangezien groottes intern uitgedrukt worden in bytes en deze initieel enkel bijgehouden werden in 32-bits datavelden. Door te werken met 64-bits waarden worden dergelijke problemen opgelost. Wat stroming betreft is men eigenlijk bezig met de creatie van een eigen API binnen de QuickTime API. Stroming wordt als communicatiemedium immers met de dag populairder en dit omwille van de steeds sneller wordende netwerkverbindingen. Vandaar dat Apple heel wat aandacht schenkt aan deze technologie. Ook op het vlak van interactiveit worden er heel grote inspanningen geleverd. De QuickTime bibliotheek is ook beschikbaar op meerdere platformen. Men spreekt wel eens van een cross-platform technologie. In eerste instantie moet hierbij gedacht worden aan het Macintosh platform maar de bibliotheek is eveneens volwaardig overgebracht naar het Windows besturingssysteem. Ondanks het feit dat MacOS en Windows toepassingen verschillend gestructureerd zijn, is hun interface naar de QuickTime API bijna volledig identiek. Hierdoor is het perfect mogelijk om, mits enige zelfdiscipline, applicaties te schrijven die zonder veel problemen op beide besturingssystemen draaien. Voor *nix platformen is de QuickTime interface niet beschikbaar, zelfs niet via de Javaversie van de QuickTime API aangezien de Java-interface slechts een omhulsel is voor C- en Pascal-datastructuren. De QuickTime mediaspeler is eveneens bruikbaar onder de twee reeds eerder vermelde besturingssystemen. Via een commerci¨ele plug-in is het ook mogelijk om recente QuickTime multimediabestanden, die vaak gebruik maken van Sorensen Video 3 compressie, te openen onder *nixgebaseerde besturingssystemen. Het gebrek aan ondersteuning voor deze platformen is hoogstwaarschijnlijk te wijten aan het feit dat Apple dit (gefragmenteerd) marktsegment nog te klein acht en zich liever op andere ontwikkelingen wil concentreren zoals het toenemend gebruik van handheld toestellen.1 Op computers die draaien onder Windows, is QuickTime ge¨ımplementeerd via een dynamic link library of DLL (bibliotheken met een dynamische koppeling). Op Macintosh computers wordt de functionaliteit van QuickTime ter beschikking gesteld via een aantal systeemuitbreidingen die normaal gezien reeds aanwezig zijn bij de installatie van het besturingssysteem. Applicaties en andere software krijgen toegang tot de diensten van QuickTime via een omvangrijke collectie functies en datastructuren. Deze API elementen zijn ondergebracht in verschillende functionele groepen. Op die manier is het mogelijk om QuickTime een aantal specifieke taken uit te laten voeren zonder dat men daartoe als programmeur alles moet begrijpen. Ongeveer een honderdtal extra Macintosh functies - voor beheer van 1

Nochtans doen er geruchten de ronde dat er bij Apple zelf een *nix versie zou circuleren van de QuickTime mediaspeler. Dit zou geen verrassing zijn aangezien heel wat programmeurs die bij Apple werken, ervaring hebben met *nixgebaseerde systemen. Bovendien is het zo dat Darwin, de open source kernel van MacOS, gedeeltelijk gebaseerd is op BSD Unix.

6

geheugen en bestanden, voor controle van grafische omgevingen, enzoverder - zijn eveneens beschikbaar via de Windows DLL. Het resultaat is ´e´en enkele API die QuickTime’s functionaliteit nagenoeg volledig ondersteunt op zowel het Windows als het Macintosh platform. QuickTime is ook synoniem voor een gereedschapskist die ter beschikking gesteld wordt voor een applicatieprogrammeur. Het is de taak van deze laatste om creatief om te springen met de aangeboden mogelijkheden. QuickTime is dus opgebouwd uit verschillende componenten. Alhoewel deze componenten de meeste standaard multimediataken uitvoeren, is het perfect mogelijk om de functionaliteit van QuickTime uit te breiden met zelfgeschreven componenten.

2.2

Enkele definities

QuickTime had oorspronkelijk als bedoeling om beweging te brengen in computerafbeeldingen en om multimediabestanden te kunnen afspelen op de computer van een gebruiker. Naarmate QuickTime evolueerde, stelde men echter vast dat het realiseren van deze doelstellingen niet zo eenvoudig was. Men had nood aan een raamwerk dat in staat was om elementen, die oorspronkelijk ontworpen waren om deel uit te maken van een statische presentatie, te organiseren langsheen een gemeenschappelijke tijdslijn, en dit als veranderende informatie. Zodoende ontstond het begrip veranderings- of tijdsgebaseerde media en het ontwikkelde raamwerk kreeg de benaming ’movie’. Op die manier werd het via QuickTime mogelijk om tijdsassen te defini¨eren en informatie te organiseren langsheen deze tijdslijnen. Het concept ’movie’ liet toe om een sequentie van mediadata te specificeren, te presenteren en te controleren. Gebruik makend van QuickTime is het dus mogelijk om een collectie van veranderingsgebaseerde data (auditief, visueel of beiden) te organiseren in de tijd. Hoe dit precies gebeurt, is vrij complex en zou gedurende het lezen van deze thesis duidelijk moeten worden. Een aantal heel belangrijke basisconcepten zijn echter vrij eenvoudig uit te leggen: • Movies2 zijn boekhoudkundige structuren. Ze bevatten alle informatie om data te organiseren in de tijd, maar ze bevatten deze data zelf niet. Movies zijn als het ware containers voor de opslag van metadata. Een movie is ook op te vatten als een stroom van instructies die aan QuickTime vertellen waar het bepaalde data kan vinden, en hoe en wanneer deze data moet voorgesteld worden aan een gebruiker. Tenslotte wil ik ook nog opmerken dat een movie een private datastructuur is. Dit betekent dat er doorgaans gebruik gemaakt wordt van functionaliteit uit de QuickTime API om de metadata in de movie te kunnen manipuleren. Omwille van 2

Merk op dat ik de benaming movie niet vertaald heb naar film en dit om te beklemtonen dat een QuickTime movie meer is dan zomaar een film. Het kan evengoed een tekstbestand zijn of een file die een beschrijving bevat van een driedimensioneel object.

7

het open bestandsformaat is dit echter niet vereist waardoor het mogelijk is om zelf functies te schrijven die in staat zijn om de gegevens in de movie te verwerken. Figuur 2.1 geeft een overzicht van de metadata die specifiek van toepassing is op een movie. Merk op dat dit slechts deel uitmaakt van een groter geheel. Dit zal in de loop van deze scriptie verder uitgewerkt worden. Movie

Creation time Modification time Time scale Duration

Movie time information

Selection time Selection duration Current time Preview time Preview duration Poster and preview time

Preview and poster data

Matrix Movie clip

Spatial characteristics

Preferred rate Preferred volume

Playback settings

Tracks

Track information

User data

User data

Figuur 2.1: Karakteristieken van een movie. • Tracks of sporen vormen de bouwstenen van movies. Iedere track bevat referenties naar data van hetzelfde type - video, geluid, tekst of wat dan ook - en zal deze referenties in de loop der tijd organiseren. Tracks kunnen in een movie op twee manieren ge¨ıdentificeerd worden. Ten eerste heeft iedere track in een movie een unieke ID. Deze ID blijft onveranderd gedurende het bestaan van een movie en er kan geen track aan de movie toegevoegd worden met dezelfde ID. Ten tweede kan een track in een movie ook opgespoord worden via zijn index, een waarde die wel gewijzigd kan worden gedurende het bestaan van de track. Indexwaarden vari¨eren steeds tussen 1 en het aantal tracks in de movie, een restant van de oorspronkelijke QuickTime API die op de programmeertaal Pascal gebaseerd was. Indices zijn vooral handig wanneer alle tracks in een movie moeten overlopen worden. Bij het verwijderen van een track zal QuickTime er voor zorgen dat de indexwaarden van de resterende sporen automatisch aangepast worden. Figuur 2.2 geeft een overzicht van de eigenschappen die eigen zijn aan een spoor.

8












Track

Creation time Modification time Duration

Track time information

Track ID

Track ID Alternate group

Track relationship

Track width Track height Track clipping region Track matte Matrix

Spatial characteristics

Volume

Sound information

Edit list

Edit data

Media

Media information User data

User data

Figuur 2.2: Karakteristieken van een track. De edit list bevat de eigenlijke referenties naar de mediadata.

• Mediadata of moviedata is de eigenlijke data waarnaar verwezen wordt vanuit de verschillende sporen waaruit een movie doorgaans is opgebouwd. Merk op dat mediadata niet atomair is; ze is opgebouwd uit verschillende elementen die samples genoemd worden. Een sample wordt door QuickTime gedefinieerd als zijnde ´e´en enkel element in een sequentie van tijdsgeordende data. Bij een sample kan men bijvoorbeeld denken aan een videobeeld of een audiosample. Figuur 2.3 toont de karakteristieken die van toepassing zijn op mediadata. • Een moviebestand bevat steeds de movie of metadata maar hoeft niet noodzakelijke de eigenlijke data te bevatten. De mediadata kan bijvoorbeeld opgeslagen zijn in een ander bestand in het lokaal bestandssysteem of in een bestand dat zich op een webserver bevindt. QuickTime maakt dus een duidelijk onderscheid tussen metadata en eigenlijke data. Indirect heeft dit ook te maken met het Macintosh bestandssysteem. De basisrelaties tussen movies, tracks, en media worden verduidelijkt aan de hand van figuur 2.4. QuickTime movies zijn dus verantwoordelijk voor het organiseren van mediadata langsheen de tijdsdimensie. Om deze dimensie te kunnen beheren, zal QuickTime een aantal

9

Media

Creation time Modification time

Media time information

Time scale Duration Media handler

Media handler Language Playback quality

Media characteristics

Media type-specific information

Media information

User data

User data

Figuur 2.3: Karakteristieken van mediadata. tijdsco¨ ordinatensystemen defini¨eren die een movie en bijhorende mediadata zullen vastankeren aan een gemeenschappelijke realiteit, de seconde. Ieder tijdsco¨ordinatensysteem omvat een tijdschaal die verantwoordelijk zal zijn voor de vertaling van re¨ele tijd naar movietijd of mediatijd. Tijdschalen worden uitgedrukt in tijdseenheden - zoveel per seconde. Het tijdsco¨ordinatensysteem definieert ook een duur. Dit laat dan toe om de lengte van een movie, track of mediastructuur uit te drukken in tijdseenheden. Verder legt een tijdsco¨ordinatensysteem eveneens een offset vast. Een offset bepaalt bijvoorbeeld wanneer een track begint te spelen. Tot slot is het ook zo dat iedere mediastructuur een eigen tijdschaal zal toegewezen krijgen. Deze zal bepalen hoeveel tijdseenheden er toegekend worden aan de samples waaruit de betreffende media is opgebouwd. Hierop zal ik uitgebreid terugkomen in het hoofdstuk over het QuickTime tijdsmechanisme.

2.3

QuickTime als vijflagige architectuur

In figuur 2.5 wordt een vereenvoudigd architecturaal model getoond van QuickTime. De vijf lagen waaruit dit model is opgebouwd geven weer welke stappen er moeten ondernomen worden vooraleer een movie aan een gebruiker kan gepresenteerd worden. In eerste instantie biedt QuickTime functionaliteit aan om ruwe mediadata te cre¨eren. Dit kan bijvoorbeeld gebeuren met behulp van een microfoon of een camera. QuickTime zal eveneens diensten ter beschikking stellen om deze ruwe data verder te bewerken. Hierbij kan men denken aan het toepassen van compressie- en transformatietechnieken. In een volgende stap kunnen de aldus ontstane mediastromen via QuickTime gestructureerd worden tot een presentatie die dan opgeslagen wordt in een moviebestand. Via een CD-ROM of een

10

V1

Video Track Audio Track XML Track

A1

A2

V2 A3

A4

X1

Xj

XML Samples

Vj

Video Samples

A5 X2

Aj

V1 A6

A7

A8

A9

X1

Audio Samples

Figuur 2.4: De movie die hier wordt voorgesteld bestaat uit 3 sporen: video, audio, en XML. Merk op dat elke track slechts verwijzigingen bevat naar mediadata van hetzelfde type en dat de XML samples gealigneerd zijn met de videobeelden. Deze XML samples kunnen bijvoorbeeld informatie bevatten over de corresponderende videofragmenten, zoals het tijdstip waarop een beeld begint, de duur van een beeld, enzoverder. Het hier besproken XML-spoor kan aangemaakt worden met behulp van Atomic Player, een applicatie die in het kader van deze thesis geschreven werd, aangezien QuickTime op zich geen expliciete ondersteuning biedt voor het werken met XML-tracks.

netwerk kan het resulterende bestand afgeleverd worden aan een gebruiker. Deze laatste kan dan gebruik maken van de QuickTime mediaspeler om de movie af te spelen. In de komende paragrafen zal ik wat meer uitleg verstrekken bij een aantal technieken die toegepast worden tijdens het proces van mediacreatie tot mediapresentatie. Ook zal er bijzondere aandacht besteed worden aan enkele problemen die kunnen opduiken wanneer QuickTime aangewend wordt om movies te cre¨eren die op meerdere platformen ter beschikking worden gesteld. Dit laatste staat ook bekend onder de benaming interoperability.

2.4

Transformaties, layering en grafische modes

Zoals reeds eerder gezegd is een movie te vergelijken met een stroom van instructies die aan QuickTime vertelt waar het data kan vinden, en hoe en wanneer deze data moet voorgesteld worden aan een gebruiker. Vaak krijgt QuickTime hierbij te maken met visuele data die op de ´e´en of andere manier moet gepresenteerd worden aan een gebruiker. In sommige gevallen is het nodig om deze grafische data nog aan te passen via technieken zoals clipping en rotaties.

11

User Experience Video

Video and sound

Video, sound, and text

Movie Delivery Disk File

CD-ROM/DVD

Streaming

Movie Composition

Media Handling Compression

Referencing

Transformation

Media Source Camcorder

CD-ROM/DVD

Microphone

And more!

Figuur 2.5: Het architecturaal model van QuickTime heeft een gelaagde gedaante. Dit komt omdat QuickTime het proces van datacreatie en datapresentatie opdeelt in vijf fasen. De beelden en geluiden die een gebruiker kan waarnemen, worden georganiseerd en afgeleverd door middel van een movie. Deze structuur bevat verwijzingen naar bewerkte mediadata, afkomstig van bestanden of externe randapparaten.

2.4.1

Clipping

Clipping is het proces waarbij de ruimtelijke begrenzingen van een beeld gelimiteerd worden vooraleer het voorgesteld wordt aan een gebruiker. QuickTime biedt de mogelijkheid aan om clipping toe te passen op iedere track afzonderlijk. Uiteraard is dit enkel zinvol indien de betreffende track verwijzingen bevat naar visuele informatie. Het beeld in een visuele track wordt eerst conceptueel opgebouwd in een trackrechthoek. Deze wordt vervolgens voorgesteld in een eigen co¨ordinatensysteem, het trackco¨ordinatenstelsel, waarvan de oorsprong klassiek in de linkerbovenhoek van het beeld

12

gelegd wordt. Na bepaald te hebben welke pixels van de afbeelding mogen vertoond worden aan een gebruiker, wordt er een speciaal gebied gedefinieerd, het track clipping gebied. De doorsnede van dit gebied met de rechthoek waarin het beeld opgebouwd werd, levert uiteindelijk het gewenste begrensde gebied op. De precieze werking van clipping wordt verduidelijkt aan de hand van figuur 2.6.

(0,0)

(0,0)

x

(track width, track height)

x

(0,0)

x

+ y

(0,0)

x

=

+ (track width, track height)

y

Track boundary region

Track clipping region

Track matte

Track rectangle

y

y

Figuur 2.6: Clipping op het niveau van een track met visuele informatie. Op een analoge manier kan clipping toegepast worden op een ganse movie. Dit wordt getoond in figuur 2.7. Oorspronkelijk is het gebied dat door de movie in beslag genomen wordt gelijk aan de unie van de begrensde gebieden horende bij de sporen waaruit de movie is opgebouwd. Op deze unie wordt dan clipping toegepast. Merk op dat hier niet langer gewerkt wordt in het trackco¨ordinatenstelsel maar wel in het ruimtelijk movieco¨ordinatensysteem. Movie coordinate system (0,0)

(0,0)

x

+ Track 1 y

(0,0)

x

x

= y

Clipped track movie boundary regions

y

Track movie boundary regions Track 2 Movie boundary region

Movie clipping region

Clipped movie boundary region

Figuur 2.7: Clipping op het niveau van een movie.

13

2.4.2

Bewerkingen met matrices

In de vorige sectie zou het moeten duidelijk geworden zijn dat iedere track in een movie zijn eigen co¨ordinatensysteem heeft, en dat al deze systemen samen het co¨ordinatenstelsel vormen van een movie. Er is echter ook nog een displayco¨ordinatensysteem, wat hetzelfde is als dat van de Graphics World waarin de movie wordt afgespeeld. Een Graphics World, of kortweg GWorld, is de benaming die QuickTime gebruikt voor een framebuffer, het gebied in het werk- of videogeheugen waarin de beelden opgebouwd worden en waarin meerdere movies kunnen geconstrueerd worden. Het betreffende GWorld- of displayco¨ordinatensysteem is echter op z’n beurt relatief t.o.v. het schermco¨ordinatenstelsel. In veel gevallen is het mogelijk om te werken met een overlapping tussen meerdere co¨ordinatensystemen waardoor de overgang van het ene systeem naar het andere op een impliciete manier kan gerealiseerd worden. Toch zijn er soms expliciete vertalingen nodig. Track coordinate system (0,0)

x

(0,0)

x y

Movie coordinate system

Track matrix

Track boundary region

a

b

u

c

d

v

x

y

w

x

= y

Track movie boundary region

Figuur 2.8: Een tracktransformatiematrix vertaalt zijn co¨ordinaten naar co¨ordinaten in een bijhorend movieco¨ordinatensysteem. Dergelijke transformaties zijn nuttig wanneer een movie samengesteld wordt.

QuickTime maakt gebruik van matrices die opgebouwd zijn uit 9 elementen om over te schakelen van het ene co¨ordinatenstelsel naar het andere. Zo definieert een tracktransformatiematrix een overgang van een gegeven trackco¨ordinatensysteem naar een movieco¨ordinatensysteem (zie figuur 2.8) en maakt een movietransformatiematrix een transitie mogelijk tussen een movie- en een displayco¨ordinatensysteem. In [Inc93b] kan men hierover meer informatie vinden. Matrixbewerkingen zullen het eveneens mogelijk maken om beelden te verschuiven, te verkleinen, en te roteren en dat op talloze manieren. Samen met clipping vormt dit al een heel krachtig mechanisme voor de bewerking van integrale videobeelden.

2.4.3

Actieve en passieve tracks

Op het eerste zicht zou men kunnen denken dat een typische QuickTime movie opgebouwd is uit ´e´en videotrack en uit ´e´en audiotrack. Vaak is dit echter niet het geval en zal een

14

movie meerdere sporen bevatten. In een groep van alternatieve tracks kan er bijvoorbeeld slechts ´e´en track op actief (enabled) staan. In dat geval zal QuickTime enkel dit spoor presenteren aan een gebruiker. De andere passieve (disabled) tracks worden genegeeerd. Door slechts ´e´en track te activeren in een groep van alternatieve tracks, is het mogelijk om een gebruiker verschillende kwaliteitservaringen aan te bieden. Welk spoor er precies geactiveerd wordt, kan afhangen van een aantal factoren. Veronderstel ter illustratie een movie die o.a. twee audiotracks bevat. De ene audiotrack bevat bijvoorbeeld verwijzingen naar 8-bit audiosamples terwijl het andere spoor referenties bevat naar 16-bit audiosamples. Naargelang de rekenkracht van het systeem van de gebruiker kan een applicatie er al dan niet voor kiezen de beste geluidskwaliteit aan te bieden. Een andere toepassing is een movie die voorzien is van een aantal tekstsporen, waarbij ieder spoor tekstsamples bevat die opgesteld zijn in een specifieke taal. Afhankelijk van de taalinstelling op het systeem van de gebruiker kan QuickTime de gepaste teksttrack activeren.

2.4.4

Track layering

In de context van QuickTime movies kan de ervaring van een gebruiker gedefinieerd worden als de som van de bijdragen van alle sporen die op een gegeven moment actief zijn. De verschillende tracks waaruit een movie is opgebouwd, kunnen echter ook bekeken worden als een aantal lagen, meer bepaald als een aantal lagen verf. Hierbij is het mogelijk om te spelen met de volgorde en de manier waarop de lagen als het ware door QuickTime geschilderd worden. Track layers worden genummerd van -32768 tot 32767, en lagen met een kleiner nummer worden vertoond boven lagen met een groter nummer. Indien een movie meer dan ´e´en track bevat met hetzelfde laagnummer, worden de sporen door QuickTime geordend op basis van hun indexnummer met als regel dat tracks met een kleinere index vertoond worden bovenop tracks met een grotere index. Het kunnen ordenen van tracks is vooral van belang wanneer meerdere videotracks met elkaar gecombineerd worden via grafische modi.3

2.4.5

Grafische modi

Wanneer een beeld bedekt wordt door een ander beeld moet QuickTime voor ieder paar pixels (´e´en pixel in het onderste beeld en ´e´en in het bovenste) beslissen welke pixelwaarde de gebruiker te zien krijgt. QuickTime baseert zijn beslissing op de grafische modus die door de maker van de movie gekozen wordt. Een aantal van die modi worden hieronder besproken: 3

Alhoewel layering nu vooral besproken wordt vanuit een grafisch standpunt, zijn analoge technieken toepasbaar op tracks die verwijzingen bevatten naar geluidsfragmenten.

15

• In copy modus, de standaardmodus voor stilstaand en bewegend beeld, vertoont QuickTime enkel de toplaag en negeert het onderliggende lagen, tenzij de onderliggende lagen meer plaats in beslag nemen dan de toplaag. Trackdimensies kunnen immers van elkaar verschillen. • In blend modus neemt QuickTime het gemiddelde van de numerieke waarde van iedere kleur voor elk corresponderend pixel in de twee overlappende beelden. Dit gemiddelde kan verschoven worden naar ´e´en bepaalde laag door gewichtsfactoren te introduceren.

1.0 (Bron)

0.8

0.6

0.4

0.2

0.0 (Bestemming)

Figuur 2.9: Het beeld van een wolk wordt vermengd met het beeld van de letter A door gebruik te maken van verschillende gewichtsfactoren.

• In dither modus worden twee beelden met elkaar gecombineerd door hun pixels te alterneren zonder dat hierbij de kleurwaarden van de betreffende pixels gewijzigd worden. Indien we de twee beeldlagen A en B noemen, dan vertoont het resultaat de pixels van de beelden in de volgorde ABAB. . . Dithering kan gebruikt worden voor het produceren van kleuren die niet voorkomen in de originele beelden. Indien in het kleurenpalet van een beeld bijvoorbeeld geen paars voorkomt, dan kan via dithering van de kleur rood in het origineel beeld met de kleur blauw uit een ander beeld, toch nog de illusie van een paarse kleur gecre¨eerd worden. • In transparante modus wordt een pixel uit een onderliggende laag vervangen door een pixel uit de bovenliggende laag, maar enkel wanneer de kleur van het bovenliggende pixel niet gelijk is aan een gespecificeerde achtergrondkleur. Dus, wanneer de bovenliggende laag bestaat uit een figuur, getekend tegen de opgegeven achtergrondkleur, dan zal het uiteindelijke resultaat de betreffende figuur tonen waarbij deze nu getekend is over de onderliggende laag, m.a.w. de achtergrond uit de bovenste laag is transparant geworden. Deze modus wordt ondermeer gebruikt bij blue screen technieken. • Een alfawaarde in de kleurbeschrijving van een beeld definieert de helderheid van het beeld, zijnde de mate waarin beelden in onderliggende lagen verborgen worden. Soms spreekt men ook van een alfakanaal, omdat het als het ware een extra kanaal is dat toegevoegd wordt aan de reeds drie bestaande kanalen indien men werkt met het RGB-kleurensysteem. Een alfawaarde 1 betekent dat het bovenste beeld

16

onderliggende beelden volledig bedekt. Een waarde 0 betekent dat het bovenste beeld onzichtbaar is en dat onderliggende beelden wel zichtbaar zijn, net alsof het bovenliggende beeld er helemaal niet was. Door de alfawaarde tussen 0 en 1 te laten vari¨eren, kan men fade in en fade out effecten cre¨eren. Bij alfa blending bepaalt de alfawaarde van het eerste beeld in welke mate het voorkomt in het resultaat, en het complement van deze alfawaarde bepaalt dan de mate waarin het tweede beeld opduikt in het resulterende beeld.

2.5

Grafische bibliotheken en datastructuren

Omwille van zijn Macintosh roots, maakt QuickTime standaard gebruik van QuickDraw om op het scherm te tekenen. QuickDraw is het Macintosh alternatief voor de Graphics Device Interface (GDI) die gebruikt wordt binnen Windows besturingssystemen. Net zoals de GDI op het Windows platform verantwoordelijk is voor het beeldbeheer op het niveau van monitoren en printers, is QuickDraw dit voor het Macintosh platform. Zelfs wanneer QuickTime onder Windows gebruikt wordt, kan het een beroep doen op QuickDraw voor het uitvoeren van tekenoperaties. QuickTime voor Windows bevat immers een gedeeltelijke port van de QuickDraw bibliotheek. Op het Windows platform ondersteunt QuickTime echter eveneens DirectDraw en DirectSound (standaard gebruikt op het Windows platform door de QuickTime mediaspeler omwille van performantieredenen), de Display Control Interface (DCI) en GDI. QuickDraw, DirectDraw, DCI en GDI zijn voorbeelden van grafische bibliotheken die kunnen gebruikt worden voor het manipuleren van tweedimensionale beelden. Direct3D, OpenGL en QuickDraw3D laten dit toe voor driedimensionale beelden. Omdat Atomic Player voor de eenvoud gebruik maakt van QuickDraw is het belangrijk enig inzicht te hebben in de werking van deze bibliotheek, alhoewel natuurlijk veel principes terug te vinden zijn in andere grafische API’s. Een andere reden voor het gebruik van QuickDraw onder Windows ligt in het feit dat het dan eenvoudiger is om code over te brengen naar het Macintosh platform. De fundamentele datastructuur die door QuickDraw gebruikt wordt is de graphics port. Onder Windows zou men praten over een device context. Een graphics port vormt een complete tekenomgeving die alle parameters bevat voor het controleren van de tekenoperaties van QuickDraw. Deze datastructuur bevat informatie over de grootte en de locatie van de lijntekenende pen, de te gebruiken achter- en voorgrondkleur, het huidige lettertype,. . . Al deze informatie wordt bijgehouden in een datastructuur van het type CGrafPort (Color Graphics Port4 ), waarnaar verwezen wordt door een pointer van het type CGrafPtr. In tegenstelling tot de Windows GDI routines, die een device context altijd als een expliciete parameter beschouwen, werken de QuickDraw routines impliciet met een huidige 4

Hier ziet u een voorbeeld van een datastructuur die Apple heeft moeten aanpassen bij de overgang van zwart-wit beelden naar beelden met kleur.

17

graphics port. Dus, op eender welk moment kan er maar ´e´en graphics port de huidige zijn en die zal bijgehouden worden door het systeem. Daardoor moet men deze niet meer vermelden als een extra parameter in een functieoproep. De QuickTime routine GetPort() levert een pointer op naar de huidige graphics port terwijl de routine MacSetPort() deze verandert. De originele Macintosh benaming van deze routine, SetPort(), conflicteerde met een reeds bestaande naam in de Windows API. Dergelijke probleemfuncties hebben van Apple op het Windows platform het prefix Mac meegekregen. Op die manier worden naamconflicten vermeden. Om QuickDraw de mogelijkheid te geven in een applicatievenster te tekenen moet dit venster bij QuickTime geregistreerd worden door een oproep te doen naar de functie CreatePortAssociation(). Deze functie legt het verband tussen een applicatievenster (gekarakteriseerd aan de hand van een handle HWND) en een graphics port. Via DestroyPortAssociation() kan men een vensterregistratie bij QuickTime ongedaan maken en deze functie zal er ook voor zorgen dat de graphics port-datastructuur verwijderd wordt. De manier waarop QuickTime beelden op het scherm vertoont, hangt in zeer sterke mate af van de karakteristieken van het grafisch randapparaat. Eigenschappen zoals pixelresolutie, kleurdiepte, en de capaciteit van de kleurentabel of CLUT (Color Lookup Table) zijn bepalend. Dergelijke informatie, naast andere, wordt bijgehouden in een gespecialiseerde datastructuur, zijnde een graphics device record. Merk op dat movies op een apparaatonafhankelijke manier geconstrueerd worden, m.a.w. met een eigen dimensie, een eigen pixeldiepte, eigen kleuren,. . . QuickTime zal automatisch de grafische karakteristieken van een movie zo optimaal mogelijk proberen aanpassen aan het apparaat dat gebruikt wordt voor het genereren van visuele output. Een graphics device record vormt samen met een graphics port een apparaatonafhankelijke Graphics World. Een GWorld is een private datastructuur die door QuickTime beheerd wordt en is volledig bepalend voor de grafische omgeving waarin QuickTime tekenwerk verricht. Een GWorld zal dus ook informatie bevatten over een framebuffer of tweedimensionale array van pixels waarin de beelden uiteindelijk opgebouwd zullen worden. Datgene wat op het scherm te zien is, is immers de visuele weergave van de inhoud van een stuk geheugen dat voor de videohardware gereserveerd is. Wanneer nu de waarde van een bepaalde geheugenlocatie veranderd wordt, dan zal daardoor eveneens een corresponderende locatie op het scherm gewijzigd worden. Dit is wat men on-screen drawing noemt. Omdat het opbouwen van een beeld in een geheugensegment gebeurt, is het eveneens mogelijk om aan QuickDraw de opdracht te geven beelden te tekenen in geheugen dat helemaal niet voor de videohardware gereserveerd werd, bijvoorbeeld in een stuk geheugen dat deel uitmaakt uitmaakt van de heap van een applicatie. In dat geval zullen wijzigingen die aangebracht worden in een dergelijke geheugenbuffer, niet te zien zijn op het scherm. Men spreekt van off-screen drawing en dit wordt door Atomic Player gebruikt om snel beelden te kunnen dumpen naar de harde schijf. Het is immers weinig zinvol om dit proces te visualiseren voor een gebruiker. Off-screen drawing wordt ook vaak gebruikt

18

voor de opbouw van complexe beelden, m.a.w. beelden waarvan de creatie veel tijd in beslag neemt. Aangezien het scherm tegen een hoge snelheid geactualiseerd wordt, kan on-screen drawing in deze situatie aanleiding geven tot een onstabiel beeld. Een dergelijk probleem kan opgelost worden door gebruik te maken van een off-screen GWorld en een CopyBits() operatie. Deze laatste bewerking is in staat om zeer vlug de inhoud van een framebuffer naar een andere te kopi¨eren, in dit geval de inhoud van een off-screen buffer naar een on-screen geheugenbuffer. Een GWorld zal eventueel ook nog informatie bevatten over een CLUT, naargelang de eigenschappen van het device waarvoor het beeld bestemd is. Zoals reeds aangegeven gebeurt het cre¨eren van beelden in een GWorld zoveel mogelijk apparaatonafhankelijk. Daarmee wordt in deze context bedoeld dat, op het niveau van een applicatie, een kleurwaarde voor een pixel vastgelegd wordt aan de hand van een RGBColor-record. Dit is een datastructuur die opgebouwd is uit drie datavelden en waarbij elk van deze velden een 16-bits kleurwaarde (rood, groen, blauw) definieert, m.a.w. in het geheugen wordt elke pixel voorgesteld door middel van een 48-bits waarde. QuickDraw zal deze theoretische waarde at run-time vergelijken met de mogelijkheden van het video device en zal hierbij ook op zoek gaan naar de kleurwaarde in de kleurenomgeving die het best bij de opgegeven 48-bits RGB-specificatie past. Hieronder ziet u een opsomming van een aantal mogelijke werkwijzen: • Video devices die direct-color modus ondersteunen, elimineren opzoekingen in een kleurentabel met een gelimiteerde capaciteit waardoor fotorealisme mogelijk gemaakt wordt. Bij het opgeven van een 48-bits RGBColor record, zal Color QuickDraw de hoogst beduidende bits van de rode, groene en blauwe component trunceren tot 16 bits (5 bits voor voor rood, groen en blauw met ´e´en bit ongebruikt) of tot 32 bits (8 bits voor iedere component, met 8 bits ongebruikt), waarbij het device dan respectievelijk gebruik maakt van 32 000 en 16 miljoen kleuren. • Sommige devices maken gebruik van indexed-color modus om een maximum van 256 kleuren per keer te ondersteunen. Dit is geheugenbesparend en vermijdt dat talloze megabytes aan videodata moeten verplaatst worden, maar zorgt wel voor een apparaatafhankelijkheid aangezien er in het geheugen niet langer gewerkt wordt met RGB-waarden. Een ge¨ındexeerd video device dat 1 byte per pixel ondersteunt, laat toe om 256 kleuren te gebruiken aangezien met 8 bits 256 kleuren kunnen ge¨ındexeerd worden. Dit stemt overeen met bijna-fotografische kwaliteit. Voor veel afbeeldingen is dit voldoende. Wanneer men echter op het scherm een Monet wil tonen, dan kan dat in dit geval wel problemen opleveren indien er een algemene CLUT gebruikt wordt, aangezien je dan een tekort hebt aan blauwschakeringen. Een oplossing hiervoor is toelaten dat de CLUT softwarematig aangepast wordt naargelang de situatie. • Bij inverse-color modus of anti-color modus, een modus die de voordelen van de de vorige twee methodes met elkaar probeert te combineren, wordt er wederom

19

Rood =$1234 Groen RGBColor-Record

=$5678 Blauw

=$9ABC

=$0159

Inverse-Table Index

Figuur 2.10: Conversie van een RGBColor-record naar een Inverse-Table index. gebruik gemaakt van een 48-bits RGB-record maar deze wordt door QuickDraw omgezet tot een index in een tabel. Dit levert dan opnieuw een waarde op die als index kan gebruikt worden in een CLUT, resulterend in een kleurwaarde die heel dicht bij de opgegeven theoretische waarde zal liggen. De conversie van een 48-bits waarde naar een index bestaat typisch uit het extraheren van de 4 hoogst beduidende bits (de zogenaamde resolutie van de inverse tabel) van iedere RGBkleurcomponent. Merk op dat de pixels in het geheugen soms ook over een eigen CLUT kunnen beschikken en dit om ruimte te besparen. Deze CLUT zal dan verantwoordelijk zijn voor het omzetten van een pixelwaarde naar een 48-bits RGB-waarde die dan op zijn beurt terug kan gebruikt worden als input bij direct-color modus of als input bij inverse-color modus. Het is duidelijk dat er heel wat mogelijkheden zijn om pixels met kleuren te associ¨eren en dat veel zal afhangen van de technische kenmerken van het computersysteem. In figuur 2.11 wordt de werking van QuickDraw wat nader toegelicht. We kunnen de volgende stappen onderscheiden: 1. De gebruiker van een applicatie selecteert een kleur voor een bepaald object, hierbij gebruik makend van een ge¨ındexeerd kleurensysteem. 2. De applicatie doet een oproep naar Color QuickDraw om het object in de gevraagde kleur te tekenen. Deze kleur wordt gedefinieerd aan de hand van een 48-bits RGBColor-Record. 3. Color QuickDraw vraagt aan de Color Manager welke kleur uit de CLUT van het video device het best overeenkomt met de opgegeven theoretische waarde. 4. De Color Manager onderzoekt de informatie in het GDevice-record. Op die manier weet de software welke kleuren er beschikbaar zijn en is het in staat het kleur te bepalen dat het dichtst bij de gevraagde kleur ligt. Merk op dat de informatie die opgeslagen ligt in het GDevice-record verzameld werd tijdens het opstarten van het

20

Video card Video RAM

CLUT 7

User

R G B

9

6

Application 1

8

Color table

2

3 Color Manager

Color QuickDraw

4

GDevice record

5 Color table

Figuur 2.11: De werking van QuickDraw: van bits naar pixels via een ge¨ındexeerd pixelpad. syteem. Toen werden de nodige gegevens ingelezen uit het ROM-geheugen dat bij het video device hoort. 5. De Color Manager bepaalt de index die de beste overeenkomst oplevert en levert deze waarde af aan Color QuickDraw. Dit kan bijvoorbeeld gebeuren via inversecolor modus. 6. Color QuickDraw plaatst de bekomen indexwaarde op die plaatsen in het video RAM die het betreffende object beschrijven. 7. Het video device leest continue data in van het video RAM. De bekomen indexwaarden worden via de device CLUT omgezet naar kleurwaarden. 8. De aldus bekomen kleuren worden naar schakelingen gestuurd die in staat zijn om het digitaal signaal om te zetten naar een analoog signaal (D/A-convertoren). 9. De analoge signalen zorgen er uiteindelijk voor dat het gewenste beeld op het scherm verschijnt. Voor meer informatie over het tekenen met QuickDraw verwijs ik naar [Inc94].

21

2.6 2.6.1

Compressie Situering

Ongecomprimeerde beelden kunnen grote hoeveelheden opslagcapaciteit in beslag nemen. Voor het opslaan van ´e´en enkel beeld met een grootte van 640 bij 480 pixels (picture elements) en dit in 32-bits kleuren, kan algauw 1.2 megabyte aan schijfruimte nodig zijn. Wanneer men dit nu ook nog combineert met de tijdsdimensie, waarbij dan gevraagd wordt om een sequentie van dergelijke beelden persistent te bewaren, dan kan de vereiste opslagcapaciteit zeer groot worden. Zo slorpt de hoeveelheid ongecomprimeerde data, horende bij een 1-minuut durende film die full-screen afgespeeld wordt tegen een snelheid van 30 beelden per seconde, algauw 2 gigabyte aan schijfruimte op. De oplossing bestaat eruit om de hoeveelheid ruwe data te verkleinen of te comprimeren. Hierbij kunnen er compressieverhoudingen bereikt worden van 50 op 1, waardoor het moviebestand, horende bij de zojuist besproken film, nog maar 40 megabyte in beslag neemt. Een nadeel van deze techniek is echter dat de data moet gedecomprimeerd worden vooraleer deze terug kan afgespeeld worden. Vaak vereist dit veel rekenwerk waardoor het voldaan zijn aan een aantal randvoorwaarden, zoals het vlot weergeven van de mediadata, in het gedrang kan komen. Een complicerende factor is ook het feit dat er tegenwoordig talloze manieren bestaan om data te comprimeren. Bestanden die afkomstig zijn van externe bronnen, zoals het Internet, zijn bijna altijd gecomprimeerd. Zodoende moet de programmatuur die verantwoordelijk is voor het weergeven van deze data ook voorzien zijn van de nodige faciliteiten om deze data te kunnen decomprimeren. Hiermee werd reeds van in het begin rekening gehouden in de QuickTime architectuur. Deze is dan ook uitgerust met de nodige gespecialiseerde componenten en functies zoals onder meer codecs en transcoders. Codecs zijn componenten die het eigenlijke compressie- en decompressiewerk zullen verzorgen. Veel codecs werken op een asymmetrische manier, d.w.z. dat ze veel meer rekentijd nodig hebben tijdens het encoderingsproces dan tijdens de decoderingsfase. Transcoders zijn componenten die in staat zijn om data om te zetten van het ene compressieformaat naar het andere, zonder dat deze data tussendoor volledig moet gedecomprimeerd worden. Dergelijke formaten zijn doorgaans aan elkaar gerelateerd; bijvoorbeeld, de videocompressieformaten MJPEG-A en MJPEG-B. Transcoderen heeft twee belangrijke voordelen ten aanzien van decompressie en opnieuw comprimeren: • De bewerking wordt doorgaans veel sneller uitgevoerd omdat vaak een groot gedeelte van de data rechtstreeks kan gekopieerd worden van bron- naar doelformaat. • Transcoderen is doorgaans ook veel accurater omdat het decomprimeren en dan terug comprimeren van de data twee mogelijkheden vormen voor het introduceren van afrondingsfouten.

22

Verder zal QuickTime ook heel wat mogelijkheden aanbieden om een groot aantal beeld- en geluidsformaten te importeren naar het eigen movieformaat. Data opgeslagen in het eigen movieformaat kan op z’n beurt ge¨exporteerd worden naar andere formaten. Hierbij kan men bijvoorbeeld denken aan het importeren van een datastroom, afkomstig van een audio-CD, in een QuickTime movie. Dergelijke functionaliteit wordt gerealiseerd met behulp van daartoe geschikte import- en exportcomponenten. Deze zullen in meer detail aan bod komen in hoofdstuk 4.

2.6.2

Afwegingen

Wanneer men datacompressie gebruikt moet men steeds een aantal belangrijke afwegingen maken. In de komende paragrafen zal ik wat meer toelichtingen geven bij een aantal tradeoffs die opduiken in het geval van beeldcompressie. In hoofdzaak zijn er drie manieren om te oordelen over beeldcompressietechnieken; er kan gekeken worden naar de bereikte compressieverhouding, naar de snelheid waaraan er gewerkt wordt en naar de resulterende beeldkwaliteit. Deze drie karakteristieken staan in conflict met elkaar waardoor er naar een compromis moet gezocht worden. • De compressieverhouding - zijnde de grootte van het origineel beeld, gedeeld door de grootte van het gecomprimeerde beeld - zegt iets over de hoeveelheid opslagruimte die een particuliere compressietechniek kan uitsparen. De compressieverhouding staat doorgaans in zeer nauw verband met de beeldkwaliteit; hoe groter de compressieverhouding, hoe slechter de kwaliteit van het resulterende beeld. Verder is het ook zo dat de compressieverhouding van sommige technieken ook in sterke mate afhangt van de inhoud van de afbeelding. Dit aspect noemt men ook wel eens een data-afhankelijkheid. Dergelijke algoritmen hebben typisch de volgende karakteristiek: een lage compressieverhouding bij een beeld met veel detail (bv. een menigte mensen) en een hoge compressieverhouding bij beelden met weinig detail (bv. het beeld van een blauwe lucht, gekenmerkt door een beperkt aantal constante kleuren). • De compressiesnelheid kan gemeten worden aan de hand van het aantal bytes dat per seconde kan verwerkt worden. Dit hangt meestal af van de volgende factoren: - de complexiteit van het compressiealgoritme - de effici¨entie van de hardware waarop het algoritme uitgevoerd wordt Algemeen gesproken geldt hierbij het volgende: hoe sneller, hoe beter. Spijtig genoeg is het vaak zo dat grote snelheden slechts bereikt worden door het opofferen van een goede compressieverhouding of beeldkwaliteit. De beste regel is om een aantal minimale eisen op te leggen aan deze laatste parameters en om dan op zoek te gaan naar een optimale snelheid.

23

• De beeldkwaliteit beschrijft de betrouwbaarheid waarmee een bepaalde compressietechniek het origineel beeld weergeeft. Een afbeelding kan bijvoorbeeld weergegeven worden met behulp van een pixelmap, die voor ieder pixel de corresponderende kleurwaarde bijhoudt. Voor de meeste afbeeldingen is dit echter vrij ineffeci¨ent; een afbeelding die een grote zwarte figuur bevat, zal eenzelfde kleurwaarde immers vele malen opslaan. Het is duidelijk dat dit beter kan via compressie. Deze zal normaal gezien in staat zijn om een groot deel van de redundante informatie te elimineren waardoor het uiteindelijke resultaat veel minder schijfruimte in beslag zal nemen.

2.6.3

Enkele algemene technieken

Compressietechnieken kunnen beschouwd worden als zijnde verlieslatend (lossy) of verliesloos (lossless). Verliesloze compressie behoudt de oorspronkelijke data volledig. Verlieslatende compressie wordt gekenmerkt door het feit dat bepaalde informatie verloren gaat; informatieverlies dat niet meer kan hersteld worden. De meeste verlieslatende technieken proberen data zoveel mogelijk te comprimeren zonder dat hierbij teveel informatie verloren gaat. Een dergelijke techniek kan er bijvoorbeeld voor kiezen om data op een zodanige manier te elimineren, dat het menselijk visueel systeem het verlies compenseert. Hierbij wordt de gebruiker als het ware bedrogen. Merk op dat sommige technieken zowel verlieslatend als verliesloos kunnen zijn, en dit afhankelijk van een kwaliteitsniveau dat door de gebruiker gekozen wordt. Compressie kan bovendien toegepast worden op enkele beelden ofwel op ganse sequenties van beelden. Wanneer er een sequentie van beelden verwerkt wordt, spreekt men van temporele compressie (temporal compression). Dit betekent dat informatie ge¨elimineerd wordt die redundant is van het ene beeld tot het andere. Temporele compressie verschilt van ruimtelijke compressie (spatial compression) in die zin dat de laatste techniek toegepast wordt op de individuele beelden waaruit de sequentie bestaat. Beide methoden kunnen toegepast worden op een opeenvolging van beelden. QuickTime past temporele compressie toe door het huidige beeld in een bepaalde sequentie te vergelijken met een vorige beeld, hierbij enkel informatie behoudend over die pixels die aanzienlijk veranderen tussen twee beelden. Wanneer de visuele informatie, aanwezig in adjacente beelden, een zeer grote overeenkomst vertoont, wat vaak het geval is, dan kan temporele compressie aanzienlijke winsten boeken op het vlak van dataopslag. Ruimtelijke compressie zal door QuickTime eveneens toegepast worden. Beide technieken worden doorgaans gestuurd door een aantal parameters die bepalend zijn voor de compressiegraad en waarvan de waarden meestal gekozen werden in functie van de gewenste beeldkwaliteit. Temporele compressie is zeer effectief wanneer het toegepast wordt op een sequentie van beelden die een grote gelijkenis vertonen. Op die manier kan immers een aanzienlijke hoeveelheid overbodige informatie weggegooid worden. Dit werkt zeer goed indien een applicatie een movie altijd begint af te spelen vanaf het begin. Indien het echter wenselijk is

24

om een movie te kunnen afspelen vanaf een willekeurig punt - of indien het zelfs wenselijk is om een movie achterwaarts te kunnen afspelen - dan heeft de betreffende compressiecomponent in het geval van temporele compressie doorgaans onvoldoende informatie om beelden op een effici¨ente manier te kunnen decomprimeren. Om dergelijke problemen te kunnen oplossen, worden er op geregelde tijdstippen key frames of sync samples toegevoegd aan beeldsequenties waarop temporele compressie wordt toegepast. Een key frame is het startpunt om een bepaald deel van de sequentie te kunnen decomprimeren, en andere beelden (delta frames, difference samples) zullen voor hun decompressie afhankelijk zijn van dit key frame. Key frames, ook wel eens random access points genoemd, zullen het mogelijk maken dat een gebruiker op een vlotte manier kan overgaan naar eender welk punt in een movie, indien deze movie visuele informatie bevat die bewerkt werd met temporele compressietechnieken. Ook het achteruit spelen van een movie zal op die manier mogelijk gemaakt worden, alhoewel dit CPU-intensiever zal zijn dan het gewoon afspelen van een movie. Wanneer QuickTime movies bijvoorbeeld verstuurd worden door middel van waretijdsstroming, dan zijn key frames de enige beelden die in hun geheel verstuurd worden.

2.7

Moviebestanden op meerdere platformen

Zoals reeds aangehaald maakt QuickTime interoperability mogelijk. Hiermee wordt bedoeld dat het o.a. mogelijk is om multimediabestanden uit te wisselen tussen verschillende besturingssystemen. Dit is niet zo vanzelfsprekend omdat MacOS gebruik maakt van een gesegmenteerd bestandssysteem. In feite is het zelfs zo dat, qua werkwijze van het systeem, het verschil tussen Mac en Windows veel groter is dan het verschil tussen Windows en Linux. Op het Macintosh platform bestaat een klassiek bestand uit 2 delen: een data fork en een resource fork. De datavork is in feite niets anders dan een sequentie van bytes, m.a.w. het equivalent van een traditioneel Windows bestand. De bronvork bevat ´e´en of meerdere Macintosh resources of bronnen - datavelden die gekarakteriseerd worden door een type (een vierkaraktercode) en een numerieke ID. Een tabel aan het begin van de bronvork helpt het Macintosh bestandssysteem de verschillende bronnen te lokaliseren en in te laden. Een voorbeeld kan waarschijnlijk veel verduidelijken. Laat ons hiertoe kijken naar de manier waarop een tekstbestand bewaard wordt op het Macintosh platform. Alle woorden die in de tekstverwerker worden ingetikt, komen terecht in de datavork. In de bronvork worden dan gegevens opgeslagen i.v.m. de tekstverwerker die met het betreffende bestand geassocieerd is, waar het venster moet geplaatst worden op het bureaublad bij het openen van het tekstdocument en allerlei andere nuttige zaken. In het geval van een moviebestand wordt de movie of de metadata onder Mac OS standaard opgeslagen als een bron in de bronvork en wordt de mediadata opgeslagen in

25

Single-fork

Double-fork

Resource map Code en data

Resource Data Resource Resource

Figuur 2.12: In een bestand dat slechts uit ´e´en vork bestaat, gebruikt onder zowel Windows als Mac OS, worden code en data opgeslagen in ´e´en enkel gebied. In een dubbelgevorkt bestand, enkel gebruikt op het Macintosh platform, worden code en GUI-beschrijvingen (Graphical User Interface) opgeslagen als bronnen en dit gescheiden van de eigenlijke data. Hierdoor is het bijvoorbeeld mogelijk de GUI van een applicatie te veranderen zonder dat aan de code van de toepassing moet geraakt worden.

de datavork. Bovendien wordt er meestal aan de bronvork eveneens een bron toegevoegd die zal aangeven dat de movie dient geopend te worden met de QuickTime mediaspeler. Deze bron wordt getypeerd aan de hand van de 4-karaktercode ’TVOD’.

2.7.1

Het vlak maken van movies

Een dubbelgevorkte bestandsarchitectuur heeft zowel voor- als nadelen. Een voordeel is dat ieder bestand z’n eigen bronvork heeft. Indien een gebruiker of een applicatie een bronvork verknoeit, dan is er slechts ´e´en bestand aangetast. Een gevolg hiervan is bijvoorbeeld dat het icoon dat met het bestand overeenstemt, verdwenen is, of dat het systeem niet meer weet welke toepassing het moet aanspreken om het betreffende bestand te openen. Op een Windows PC wordt al deze informatie echter opgeslagen in ´e´en enkel bestand, het register, en dit voor iedere toepassing. Dit register vormt een zogenaamd single point of failure. En applicatie kan op die manier gemakkelijk het ganse systeem ru¨ıneren. Een belangrijk nadeel van het gebruik van dubbelgevorkte bestanden is het feit dat, wanneer een bestand over een netwerk moet getransporteerd worden, er nu twee delen moeten verstuurd worden. Ook de overdraagbaarheid van een multimediabestand naar het populaire Windows platform komt op die manier in het gedrang.

26

Om deze problemen te verhelpen kan men een speciale techniek toepassen die flattening wordt genoemd. Dit komt in essentie neer op het volgende. Veronderstel dat er in het werkgeheugen een movie gecre¨eerd werd die verwijzingen bevat naar bepaalde mediasamples. Indien je het resultaat in een Macintosh bestand opslaat, dan wordt de mediadata dus ondergebracht in de datavork terwijl de movie of metadata ondergebracht wordt als een Macintosh bron in de bronvork. Het is echter niet noodzakelijk zo dat de mediadata, waarnaar verwezen wordt door de sporen in de movie, expliciet hoeft opgenomen te zijn in de datavork van het bestand. Deze data kan immers, omwille van plaatsbesparingen, evengoed gedeeltelijk of volledig bewaard worden op een andere computer in het netwerk. Het is zelfs mogelijk dat andere movies eveneens verwijzingen bevatten naar die data. Het vlak maken van de movie komt er dan op neer dat dergelijke referenties opgelost worden waardoor alle data waarnaar verwezen wordt, effectief in de datavork terecht komt. Men spreekt dan van een zelfstandige movie (self-referencing movie, self-containing movie). Bovendien, en dat was hetgeen waartoe we dienden te komen, is het ook mogelijk om via deze techniek de datavork en de bronvork te laten versmelten tot een bestand dat nog maar uit ´e´en vork bestaat. In dat geval worden de betreffende bronnen volgens een door QuickTime gekende procedure opgeslagen in de corresponderende datavork. Met het vlak maken van een movie is het dus mogelijk meerdere doelstellingen te realiseren: • Men kan ervoor zorgen dat een movie zelfstandig wordt door de data, waarnaar verwezen wordt door de tracks in de movie, samen met de metadata onder te brengen in ´e´en bestand. Zo wordt het uitwisselen van een moviebestand over meerdere platformen heen, mogelijk gemaakt. Het zal eveneens het transport van een multimediapresentatie over een netwerk vereenvoudigen. Merk op dat het flattening proces doorgaans ook automatisch mediasamples uit een bestand zal verwijderen indien deze door geen enkele track meer gerefereerd worden. Dergelijke fantomen kunnen ontstaan door het uitvoeren van editeerbewerkingen. • Het is ook mogelijk om de flattening procedure zo te configureren dat deze de moviestructuur aan het begin van het bestand plaatst. Dit is een nodige voorwaarde om progressief downloaden mogelijk te maken. Progressief downloaden is een techniek waarbij de gebruiker een multimediapresentatie reeds kan afspelen terwijl deze nog aan het downloaden is. Merk op dat dit onmogelijk is indien de metadata achter de eigenlijke data wordt opgeslagen. Dan weet QuickTime pas helemaal op het einde wat er precies gedownload werd. In het andere geval heeft QuickTime reeds van in het begin (na de movie binnengehaald te hebben) kennis over de structuur van de mediadata; het zal weten uit hoeveel tracks de movie is opgebouwd, welke compressietechnieken er gebruikt werden,. . . Alternatieve benamingen voor progressief downloaden zijn HTTP Fast Start en HTTP streaming. • Flattening kan er ook voor zorgen dat mediadata, die simultaan moet voorgesteld worden (zoals video en geluid), alternerend opgeslagen wordt. Dit is eveneens een

27

nodige voorwaarde om HTTP-stroming mogelijk te maken. Bovendien wordt zo het aantal schijftoegangen beperkt doordat data, die heel dicht bij elkaar gelegen is in de tijd, ook heel dicht bij elkaar gelegen is op schijf. Een gereduceerd aantal schijftoegangen, in combinatie met geavanceerde bufferingstechnieken, zal het voor QuickTime gemakkelijker maken om verschillende mediastromen met elkaar te synchroniseren. • Men kan het proces, dat verantwoordelijk is voor het vlak maken van de movie, eveneens opdracht geven om de movie resource te comprimeren. Dit zal er doorgaans voor zorgen dat in de beste omstandigheden de latency of vertraging bij het progressief downloaden van een movie met een factor twee daalt. Wanneer QuickTime een movie opbouwt door gebruik te maken van referenties naar data die opgeslagen zijn in andere bestanden, dan noemt ment dit importing in place. In dat geval moet er geen data verplaatst of gekopieerd worden. Dit is zelfs mogelijk voor data die opgeslagen zijn in bestandsformaten zoals AIFF (Audio Interchange File Format) en MPEG (Moving Picture Experts Group). Indien nodig kunnen deze referenties opgelost worden via flattenening. Merk op dat de QuickTime bibliotheek op het Windows platform intern nog steeds werkt volgens het Mac OS bestandssysteem wat inhoudt dat iedere Windows bestandsspecificatie door de programmeur expliciet moet omgezet worden naar een corresponderende Macintoshversie. Dit kan door een oproep te doen naar de gepaste conversiefuncties.

2.7.2

Endian conversies

Een klassiek probleem, dat bijna altijd opduikt wanneer computerdata tussen verschillende systemen moet uitgewisseld worden, is het feit dat datavelden die uit meer dan ´e´en byte bestaan, op twee manieren kunnen geadresseerd worden. Big-endian adressering, waarbij het adres voor een veld wijst naar de meest beduidende byte van het veld, en little-endian adressering, waarbij het adres voor een veld verwijst naar de minst beduidende byte van het betreffende veld. QuickTime code zal steeds gebruik maken van big-endian adressering (omwille van z’n Macintosh roots). Op het Windows platform daarentegen, wordt data door andere software meestal benaderd op de little-endian manier: • Big Endian (ook wel eens Motorola bytevolgorde of netwerkbytevolgorde genoemd) – Mac OS – Motorola en IBM PowerPC processoren – Motorola 680x0 processoren – Veel RISC werkstations (kunnen vaak overschakelen tussen big/little endian)

28

Big-endian MSB

Lager geheugen adres

LSB

MSB

LSB

Pointer naar veld B

Pointer naar veld A

LSB

MSB

LSB

Hoger geheugen adres

MSB

Little-endian

Figuur 2.13: MSB en LSB stellen respectievelijk de meest en minst beduidende byte voor. Merk op dat de pointers wijzen naar verschillende bytes in de 2 schema’s, alhoewel ze naar dezelfde velden refereren.

• Little Endian (ook wel eens Intel bytevolgorde genoemd) – Windows OS – Intel x86, Pentium, Celeron, en andere gerelateerde processoren – DEC Alpha processor In de meeste gevallen zal QuickTime automatisch de nodige endian conversies uitvoeren. Soms is dit echter niet mogelijk en voor die gevallen stelt QuickTime een aantal conversiehulpmiddelen ter beschikking. Hierbij verwijs ik onder meer naar de functie EndianU32 NtoB() die in staat is om een native unsigned 32-bits integer te converteren naar het big-endian formaat. Werd er reeds een big-endian voorstelling gebruikt voor het geheel getal, dan doet deze functie niets. EndianU32 NtoB() wordt bijvoorbeeld aangewend voor de conversie van gehele variabelen waarvan de waarden worden opgeslagen in parameteratomen die een video-effect beschrijven. Ook bij een applicatie die zelf instaat voor de interpretatie van z’n data moet er rekening gehouden worden met endian conversies aangezien er dan niet langer exclusief gebruik gemaakt wordt van QuickTime functies. Deze toepassing zou bijvoorbeeld eigen data voor de eenvoud kunnen opslaan in little-endian volgorde. Terloops wil ik hier ook nog vermelden dat er in de QuickTime bibliotheek ook veel gebruik gemaakt wordt van Pascal-strings. Bij dergelijke strings wordt de lengte van de karaktersequentie opgeslagen in de eerste byte, wat ervoor zorgt dat de lengte van Pascalstrings beperkt wordt tot 255 karakters. Zij verschillen dus grondig van C-strings. Deze laatste worden immers be¨eindigd door middel van een speciaal karakter en hebben in principe geen beperking qua lengte. De QuickTime API zal wederom een aantal functies ter beschikking stellen zodat een vlotte overgang tussen beide types strings mogelijk is.

29

Hoofdstuk 3 Movies in Tijd en Ruimte QuickTime is een algemene technologie voor het werken met tijdsgebaseerde media. In feite is dit al in grote mate af te leiden uit de naam, die duidelijk aangeeft dat de klemtoon van QuickTime ligt op het manipuleren van computerdata die gekoppeld kan worden aan een tijdsdimensie. In het vorige hoofdstuk werd reeds een kleine inleiding gegeven tot het gebruik van tijd door QuickTime. In dit hoofdstuk zal dieper ingegaan worden op de verschillende manieren waarop tijd door een movie gemeten wordt. Verder zullen de idee¨en die schuil gaan achter een movie in meer detail besproken worden en zal er eveneens stilgestaan worden bij de eigenlijke creatie van een movie.

3.1

Situering

Toen het QuickTime team in het begin van de jaren ’90 met de ontwikkeling van code startte, was het de bedoeling een nieuwe multimediatechnologie in het leven te roepen die veelzijdig en krachtig was, die gemakkelijk te gebruiken was voor een gewone computerliefhebber, en die eenvoudig in omgang was voor programmeurs. Een resultaat van deze ontwerpfilosofie was de idee van een movie als centrale datastructuur in QuickTime. Naarmate QuickTime evolueerde, verwierf een movie de volgende basiseigenschappen: • Er is maar ´e´en moviestructuur, met ´e´en collectie van hulpprogramma’s voor de creatie, het editeren, en afspelen van movies. • Een movie bevat geen mediadata; in plaats daarvan bevat het referenties naar mediadata. Deze referenties zullen aan QuickTime vertellen waar het de mediadata kan vinden en hoe deze moet voorgesteld worden aan de gebruiker. Het werken met referenties heeft een aantal belangrijke voordelen: – Het is mogelijk data eender waar op te slaan.

30

– Een movie kan hetzelfde stuk mediadata meerdere malen refereren, zonder dat deze data telkens moet gedupliceerd worden. – Verschillende movies kunnen refereren naar dezelfde data. – Het maakt editeerbewerkingen sneller en geheugenbesparend: in veel gevallen volstaat een manipulatie van referenties, zonder dat hierbij aan de eigenlijke data moet geraakt worden. • Een moviestructuur kan als het ware vergeleken worden met een directory in een klassiek bestandssysteem: het bevat belangrijke informatie maar behelst hoofdzakelijk wijzers naar externe data. • Een movie organiseert z’n referenties langsheen een gemeenschappelijke tijdslijn waardoor het een manier wordt om media in de tijd weer te geven. • Een movie kan uit meerdere sporen bestaan. Ieder spoor is verantwoordelijk voor de organisatie van zijn referenties en kan slechts verwijzingen bevatten naar data van hetzelfde mediatype. • Een movie bevat algemene informatie over hoe de mediadata moet verwerkt worden (zoals decompressieparameters). Op basis van deze informatie zal QuickTime in staat zijn om de meest effici¨entie verwerkingstechnieken te selecteren. Een movie presenteert dus een collectie mediadata langsheen ´e´en enkele tijdslijn. Nochtans is het vaak zo dat de verschillende mediastromen waarnaar een movie verwijst, een eigen notie van tijd hebben. Videodata wordt gekarakteriseerd door een bepaalde beeldsnelheid terwijl digitale audio getypeerd wordt door een zekere sample rate. Tekst en stilstaande beelden worden dan weer gekenmerkt door het ontbreken van een intrinsieke tijdsdimensie. Een gevolg hiervan is dat QuickTime gebruik maakt van een aantal gesofistikeerde technieken om mediadata in de loop der tijd te organiseren tot een coherente presentatie. De idee¨en die schuil gaan achter deze geavanceerde methoden voor het beheer van tijd zijn heel belangrijk en duiken in tal van situaties op.

3.2

De relativiteit van tijd.

QuickTime kent twee tijdsrelaties: enerzijds is er de relatie re¨ele tijd - movietijd en anderzijds is er de relatie movietijd - mediatijd. Re¨ele tijd wordt gemeten in seconden terwijl movietijd uitgedrukt wordt in tijdseenheden (TE). Hierbij is een TE een transcendentie van het meer concrete begrip seconde. Daarmee bedoel ik dat een TE, naargelang de omstandigheden, eender wat kan voorstellen in re¨ele tijd; het kan een seconde zijn, maar evengoed 10 nanoseconden of 66 milliseconden. De twee tijdsrelaties worden ge¨ıllustreerd aan de hand van figuur 3.1.

31

Applicatie (Atomic Player) Reële tijd – Movietijd

Movie Controller

Tick Count

Movie Toolbox

Klok Component

Media Handler(s)

Presentatie

Movietijd – Mediatijd

Figuur 3.1: QuickTime wordt gekenmerkt door twee tijdsrelaties: enerzijds de relatie re¨ele tijd - movietijd en anderzijds de relatie movietijd - mediatijd.

Op deze afbeelding ziet u een beknopt overzicht van de interactie tussen Atomic Player en QuickTime, met als doel een multimediapresentatie weer te geven. Dit is alleen maar mogelijk door een samenwerking van verschillende componenten. Een component is een software entiteit die in staat is om een aantal welgedefinieerde diensten te leveren. Zo is een klokcomponent in staat om QuickTime te voorzien van informatie over het verstrijken van de re¨ele tijd. Dit zal gebeuren op basis van gegevens die de klokcomponent verwerft via een externe bron, bijvoorbeeld via de interne klok van het computersysteem van de gebruiker. Op die manier zal QuickTime in staat zijn om de link te leggen tussen movietijd en re¨ele tijd. Een klokcomponent kan ook verantwoordelijk zijn voor de scheduling van tijdsgebaseerde callback events. Een tijdsgebaseerde callback event is een onderbreking die op geregelde tijdstippen optreedt en die doorgaans aanleiding geeft tot het oproepen van een callback functie. Die kan dan bijvoorbeeld een boodschap op het scherm uitschrijven.

3.3

Movietijd, mediatijd en tijdsbasissen.

De relatie re¨ele tijd - movietijd zal ik niet in detail behandelen. Het is wel belangrijk te weten dat deze relatie bestaat en dat de vertaling van movietijd naar ware tijd, en omgekeerd, meestal aan QuickTime wordt overgelaten. Het is pas in zeer gespecialiseerde gevallen dat het vereist is om een eigen klokcomponent te schrijven. Verder is het misschien ook nog interessant om te weten dat QuickTime mogelijkheden heeft om externe tijdsinformatie, zoals SMPTE-tijdscodes, op te slaan in een daartoe gespecialiseerd spoor, zijnde een tijdscodetrack. SMPTE is de afkorting voor Society of Motion Picture and Television Engineers, en laat toe om naast uren, minuten, en secon-

32

den ook te selecteren op basis van frames en subframes (1 honderdste van een frame). QuickTime zal gebruik maken van een aantal geavanceerde technieken om tijdscodes te synchroniseren met frames, wat meestal zeer goed lukt omdat veel analoge videostandaarden werken met gehele beeldsnelheden. Hierbij kan er gedacht worden aan SECAM en PAL die beiden werken tegen een beeldsnelheid van exact 25 fps (eigenlijk 50 halve beelden; de opbouw van een beeld gebeurt echter om de andere lijn - interlaced video - en dit 25 maal per seconde, zodat men gemakshalve spreekt over 25 fps). Niet alle videostandaarden zijn echter even rationeel. NTSC color speelt bijvoorbeeld beelden af aan een snelheid van 30/1.001 fps. De bijhorende NTSC-tijdscodes veronderstellen echter dat er exact 30 fps afgespeeld worden, naar analogie met NTSC black-and-white, waardoor er na een zekere tijd een afwijking zal ontstaan tussen de NTSC-tijdscodes en de eigenlijke videobeelden, en waarbij de mediaspeler als taak heeft deze anomalie te corrigeren. Om een dergelijke drift te vermijden zal QuickTime een techniek toepassen die dropframe timecode heet, wat inhoudt dat er op geregelde tijdstippen frames zullen weggegooid worden. Indien tijdscodewaarden uitgedrukt worden als uren:minuten:seconden:beelden dan zal er iedere minuut een overgang te zien zijn van 00:00:59:29 naar 00:01:00:02, waarbij de frames 00:01:00:00 en 00:01:00:01 worden overgeslagen. Dit leidt tot een beter benaderende afspeelsnelheid van 29.97 fps1 . Waar ik wel dieper op zal ingaan, is de wisselwerking movietijd - mediatijd. Beide tijdsmechanismen worden gedefinieerd aan de hand van een eigen tijdsco¨ordinatenstelsel waarin telkens drie fundamentele concepten zullen opduiken, namelijk de begrippen tijdschaal, duur en offset. Verder zal er ook nog sprake zijn van een overkoepelende definitie, zijnde een tijdsbasis.

3.3.1

Movietijd

Het movietijdsco¨ ordinatenstelsel (afgekort tot movietijd) omvat in eerste instantie een tijdschaal. Een movietijdschaal is d´e tijdslijn waarlangs alle gebeurtenissen in een movie gemeten en gelokaliseerd worden en definieert het aantal TE dat per seconde verstrijkt. Het legt dus de lengte van een TE vast in de re¨ele tijdsdimensie. Bijvoorbeeld, stel dat de tijdschaal gelijk gekozen wordt aan 1000 TE/s. Dit betekent dat iedere TE correspondeert met ´e´en milliseconde2 . Verder wordt er in het co¨ordinatenstelsel een duur ingevoerd. De duur van een movieelement wordt gedefinieerd als het aantal TE dat dit element in beslag neemt en zal 1

Ik vermeld dit hier enkel om duidelijk te maken dat de QuickTime API ook heel wat mogelijkheden heeft op het gebied van digitalisatie en dat QuickTime ook in staat is om te werken met gestandaardiseerde formaten zoals NTSC, PAL, SECAM, YUV, en SMPTE. Dit is echter, net zoals de werking van klokcomponenten, niet in detail aan bod gekomen in deze scriptie. Mijn thesis situeert zich in feite enkel in de 4 bovenste lagen van het QuickTime referentiemodel. 2 Aangezien een tijdschaal wordt voorgesteld door middel van een unsigned 32-bits integer is het in theorie zelfs mogelijk te werken op het niveau van nanoseconden.

33

bijvoorbeeld toelaten om een uitspraak te doen over de lengte van een track, een sample, enzoverder. Naast een duur heeft ieder movie-element in de movie ook een offset, wederom uitgedrukt in TE. Deze stelt dan het beginpunt voor van het movie-element. Een track die bijvoorbeeld begint wanneer de movie start, heeft een offset 0. Merk op dat iedere movie een tijdsco¨ordinatensysteem heeft en dat deze systemen kunnen vari¨eren van movie tot movie. De duur van een movie in movietijd is trouwens het totaal aantal TE van het begin tot het einde van de movie. Een track in een movie kan een kleinere duur hebben dan de movie wanneer de track bijvoorbeeld niet tot het einde van de movie duurt, en de mediasamples waarnaar verwezen wordt vanuit een track hebben doorgaans nog veel kleinere lengtes.

3.3.2

Mediatijd

Iedere mediastroom waaruit een movie is opgebouwd, beschikt, net zoals de movie zelf, over een eigen mediatijdsco¨ ordinatenstelsel. Dit systeem bevat - in analogie met een movie - een tijdschaal, een duur en een offset. Een mediatijdschaal zal gedefinieerd zijn in termen van de karakteristieken van de onderliggende mediastroom. Concreet betekent dit dat de mediatijdschaal bijvoorbeeld zal corresponderen met de beeldsnelheid in het geval van videodata en met de sample rate in het geval van audiodata. Eenzelfde redenering gaat op voor het begrip duur. Dankzij dit begrip zal het mogelijk zijn te praten over een videotrack met een duur van n frames of over een audiotrack met een duur van n audiosamples. Tot slot zal het begrip offset toelaten uitspraken te doen over bijvoorbeeld het nde frame of over het nde audiosample. Merk op dat QuickTime automatisch zal instaan voor de vertaling3 tussen de tijdschaal van een movie en de tijdschalen van de verschillende mediastromen waaruit een movie is opgebouwd. Op het niveau van de API wordt er bijna uitsluitend gewerkt in het movietijdsco¨ordinatenstelsel.

3.3.3

Tijdsbasissen

Een tijdsbasis is een overkoepeling van de vorige definities. Het zal deze zelfs nog uitbreiden, meer bepaald met het concept afspeelsnelheid of rate en het concept huidige tijd. Tevens zal er aan een tijdsbasis een referentie naar een klokcomponent toegevoegd worden. Wanneer een movie aan een gebruiker gepresenteerd wordt, bepaalt de afspeelsnelheid hoeveel tijdseenheden er per seconde in werkelijkheid verstrijken. De afspeelsnelheid 3

Dit zal gebeuren via een aantal gespecialiseerde componenten, meer bepaald via de media handlers. Deze zullen uitgebreid aan bod komen in het hoofdstuk over QuickTime componenten.

34

bepaalt ook de manier waarop de movie afgespeeld wordt. Indien de waarde van de afspeelsnelheid positief is, dan wordt de movie voorwaarts afgespeeld. Is ze negatief, dan wordt de movie achterwaarts afgespeeld. Neem bijvoorbeeld aan dat de movietijdschaal 600 TE/s bedraagt en dat de afspeelsnelheid de waarde 1.0 heeft4 . Dit betekent dat QuickTime iedere seconde 600 TE van de movie in voorwaartse richting zal verwerken; de movie zal normaal afgespeeld worden. Een afspeelsnelheid met de waarde 0.5 zal er daarentegen voor zorgen dat QuickTime iedere seconde nog maar 300 TE van de movie zal verwerken; de movie zal in slow motion afgespeeld worden. Een rate van -1.0 betekent dat de movie achterwaarts afgespeeld wordt en dat tegen een normale snelheid. De huidige tijd van een movie is het punt, uitgedrukt in movietijd, dat aan QuickTime vertelt welke mediadata het momenteel moet ophalen en presenteren. De waarde van de huidige tijd kan vari¨eren tussen 0 en de duur van de movie, uitgedrukt in movietijd. De huidige tijd zal QuickTime dus informeren over welk gedeelte van de movie er momenteel gepresenteerd wordt. Naarmate de movie afgespeeld wordt, zal de waarde van de huidige tijd veranderen. De afspeelsnelheid of rate zal, samen met de movietijdschaal, in staat zijn om de movietijd in verband te brengen met de re¨ele tijd door te zeggen hoe snel en in welke richting de movie moet verwerkt worden door QuickTime.

3.3.4

Voorbeeld

Beschouw ter illustratie van het QuickTime tijdsmechanisme het volgende voorbeeld. Zij gegeven een movie met een tijdsduur van 2 seconden, een tijdschaal van 600 TE/s, en een afspeelsnelheid met een waarde 1. Neem aan dat een videotrack begint te spelen van zodra de movie gestart wordt en dat deze videotrack net zolang duurt als de movie zelf, m.a.w. dat het videospoor wordt gekenmerkt door een offset 0 en een duur van 1200 TE (in movietijd). Er mag eveneens verondersteld worden dat de videotrack opgenomen is aan een snelheid van 30 frames per seconde (een mediatijdschaal van 30 fps). De hier besproken movie beschikt ook nog over een audiotrack die eveneens begint te spelen van zodra de movie gestart wordt en dit aan een snelheid van 44100 samples per seconde. Bovendien correspondeert de duur van de audiotrack met die van de movie. Bijgevolg wordt het audiospoor getypeerd door een offset 0, een duur van 1200 TE in movietijd, en een mediatijdschaal van 44100 audiosamples per seconde. Tot slot heeft de movie ook nog een teksttrack die uit ´e´en sample bestaat, zijnde de titel van de movie. De tekst wordt 0.25 seconden na de start van de movie gedurende 1 seconde op het scherm vertoont. Dit resulteert in de volgende karakteristieken voor het tekstspoor: een offset van 150 TE in 4

De waarde van de afspeelsnelheid wordt intern voorgesteld door middel van het datatype Fixed. Dit is een 32-bits integer waarvan de 16 hoogst beduidende bits gereserveerd zijn voor het geheel deel, terwijl de 16 laagst beduidende bits gereserveerd zijn voor het fractioneel deel. Naast een Fixed wordt er door QuickTime ook nog gebruik gemaakt van het datatype Fract. Dit is wederom een 32-bits integer maar waarbij er nu 30 bits gebruikt worden voor de voorstelling van het fractioneel gedeelte. Op die manier kan het gedeelte na de decimale punt met een grotere nauwkeurigheid voorgesteld worden. Het datatype Fract wordt vaak gebruikt voor de voorstelling van getallen die behoren tot [-1,1].

35

movietijd, een duur van 600 TE in movietijd, en een mediatijdschaal van 1 tekstsample per seconde. Indien er nu een kopieerbewerking aangevraagd wordt met een duur van 0.5 seconden in ware tijd (300 in de tijdschaal van de movie), en dit vanaf het midden van de movie, dan zal QuickTime ervoor zorgen dat iedere track correct gekopieerd wordt, en dit overeenkomstig de verschillende mediatijdschalen. In deze context betekent dit dat QuickTime 15 videobeelden, 22050 audiosamples en 1 tekstsample zal moeten kopi¨eren. Movie tijd (TE):

0

Media tijd (fps):

Reële tijd (sec):

300

600

V1

0

900

…

1

0.5

1200

V60

1.5

2

Figuur 3.2: Het verband mediatijd, movietijd en re¨ele tijd. Figuur 3.2 toont een meer concrete voorstelling van de in het vorig voorbeeld besproken movie, zij het dat deze nu enkel nog maar bestaat uit een videotrack. Ook de verschillende tijdsrelaties worden in deze figuur weergegeven. Merk op dat indien de afspeelsnelheid gehalveerd wordt naar 300 TE/s, dat dan de duur van de movie met een factor 2 toeneemt.

3.4

De relativiteit van beelden en beeldsnelheden

Het zou moeten duidelijk geworden zijn dat het door QuickTime ingevoerde tijdsmechanisme vrij geavanceerd is. Het is echter ook een heel soepel systeem aangezien het immers mogelijk is te werken in eender welke re¨ele tijdseenheid door een specifieke keuze te maken voor de movietijdschaal. Door deze gelijk te stellen aan 1, wordt er gewerkt op het niveau van een seconde. Stelt men de movietijdschaal gelijk aan 1000, dan wordt er gewerkt op op het niveau van milliseconden. Dergelijke flexibiliteit zal het mogelijk maken te werken in de natuurlijke eenheden van een bepaald mediatype. Een goed voorbeeld hiervan is het editeren van een audiospoor dat gesampled is aan een frequentie van 44.1 kHz. Wanneer in dit geval de tijdschaal gelijk gekozen wordt aan 44100 dan is het heel eenvoudig om via de QuickTime API te specificeren dat bijvoorbeeld samples 29346 t.e.m. 36547 moeten verwijderd worden. Het zou al heel wat moeilijker worden indien hetzelfde resultaat moet bereikt worden door te werken met de milliseconde als eenheid. In het voorgaande geval laat men QuickTime de nodige omzettingen uitvoeren, terwijl men in het laatste geval zelf verantwoordelijk is voor een groot deel van het rekenwerk. Bovendien laat het flexibel karakter van een tijdschaal ook toe om de discussie te vermijden over het kiezen van ´e´en bepaalde tijdseenheid die overal en altijd moet gebruikt

36

worden. Wordt er bijvoorbeeld gekozen voor de milliseconde, dan is dat vrij interessant voor het werken met frames. Deze eenheid is echter minder bruikbaar indien er moet gewerkt worden met audiosamples die tegen een veel grotere snelheid afgespeeld worden. In dat geval is het beter te kiezen voor een kleinere eenheid. Dergelijke transities zijn in QuickTime heel gemakkelijk uit te voeren door het spelen met de waarde van een tijdschaal. Het is trouwens ook zo dat de volgende basisregel geldt wat betreft het werken met tijdschalen: hoe groter de tijdschaal, hoe groter de nauwkeurigheid waarmee editeerbewerkingen kunnen uitgevoerd worden. Dat is in feite de reden waarom de mediatijdschaal van videotracks zelden gelijk gesteld gesteld wordt aan de corresponderende beeldsnelheid5 , iets wat doorgaans wel het geval is voor audiotracks. En heel belangrijk, dit is ook de fundamentele reden waarom QuickTime een tijdsgebaseerde, en dus geen framegebaseerde technologie is. Op dit laatste kom ik onmiddellijk terug maar eerst zal ik de zonet vermelde basisregel in meer detail uitwerken. Dat een betere nauwkeurigheid kan bereikt worden door de tijdschaal groter te kiezen, is in principe vrij logisch. Immers, de granulariteit van een tijdseenheid wordt fijner. Of anders gezegd, een abstracte tijdseenheid correspondeert met een kleiner segment in de ware tijd. Dit kan misschien het best verduidelijkt worden aan de hand van een voorbeeld. Veronderstel een videotrack die beelden afspeelt aan een snelheid van 4 fps. In theorie zou de mediatijdschaal dan eveneens gelijkgesteld worden aan 4, maar in de praktijk is dit niet zo’n goede keuze. Er bestaan betere opties die meer editeermogelijkheden zullen bieden. Door de mediatijdschaal immers gelijk te stellen aan 4, stemt ieder frame overeen met 1 tijdseenheid of met 250 milliseconden in ware tijd. We kunnen de duur van een frame wel verhogen, bijvoorbeeld door aan het frame 2 tijdseenheden toe te kennen, maar we verkeren niet in de mogelijkheid om de duur van een frame kleiner te maken dan 250 milliseconden (1 tijdseenheid in mediatijd) aangezien het in de QuickTime API enkel mogelijk is te werken met gehele tijdswaarden6 . Dus, aan QuickTime zeggen dat een frame maar 0.5 tijdseenheden mag duren, kan niet. Dit zal echter wel mogelijk zijn door de tijdschaal te verhogen. Neem aan dat we voor de mediatijdschaal de waarde 40 kiezen i.p.v. de waarde 4. Dan is de lengte van een tijdseenheid gedaalt van 250 msec naar 25 mscec, en een frame zal in mediatijd nu 10 tijdseenheden duren i.p.v. 1 tijdseenheid zoals dat oorspronkelijk het geval was. Het is nu wel relatief eenvoudig geworden om de duur van ´e´en specifiek frame aan te passen zodat het bijvoorbeeld nog maar 125 msec duurt. Echter, met de gekozen tijdschaal van 40 zullen we niet nauwkeuriger kunnen gaan dan 25 msec. Is een grotere nauwkeurigheid gewenst, dan kan die eenvoudig bereikt worden door een nog grotere mediatijdschaal te introduceren. Merk op dat de tijdschaal ook niet te groot gekozen mag worden omwille van over5

Bijna altijd wordt de mediatijdschaal van een videospoor gelijkgesteld aan de movietijdschaal om op die manier eenvoudige conversies mogelijk te maken. 6 Een tijdswaarde is een aantal tijdseenheden.

37

flowproblemen. Een mediatijdschaal van 30 en media samples met een duur 1, in combinatie met een movietijdschaal van 30, levert 2 jaar tijd op in een 32-bits voorstelling (2-complement signed integer). Dit werkt vrij goed in het geval van movies die enkel videotracks bevatten. Indien een movie voorzien is van een audiotrack met een tijdschaal 44100 zal de resulterende lengte kleiner zijn (minder dan een dag). Dit is iets dat typisch optreedt bij media die gekenmerkt worden door hoge sample snelheden, zoals digitaal geluid, en soms zal men dan kiezen voor een tijdschaal waarbij men spreekt in termen van n samples per TE i.p.v. n TE per sample7 . Het voorbeeld dat gebruikt werd om te verduidelijken dat een grotere tijdschaal een grotere nauwkeurigheid inhoudt, toont ook al min of meer aan dat in QuickTime een frame eender welke duur kan hebben en dat een frame, en zeker een vaste frame rate, een heel relatief begrip is. Trouwens, in de QuickTime API zijn er nergens functies terug te vinden waarmee het bijvoorbeeld mogelijk is om naar een bepaald frame te gaan, of waarmee het mogelijk is om een bepaald frame te elimineren. Alle functies werken aan de hand van tijdseenheden en tijdswaarden. Dit was dan ook ´e´en van de uitdagingen van deze thesis: namelijk, er voor zorgen dat in de mate van het mogelijke deze functies toch beschikbaar zijn, zij het via een eigen API. De eerlijkheid gebiedt mij wel te vermelden dat er ´e´en functie bestaat waarmee de frame rate kan opgevraagd worden tijdens het afspelen van videodata. Het is wel zo dat de QuickTime documentie aanraadt deze functie enkel te gebruiken voor debug doeleinden en dat de output van deze functie best ook niet vertoond wordt aan gewone gebruikers, omdat deze de resultaten wel eens verkeerd zouden kunnen interpreteren. In de praktijk is het kunnen werken met een vaste frame rate handig, en een vaste frame rate zal ook vrij frequent voorkomen, maar voor QuickTime is het geen vereiste. In het geval van een vaste frame rate raadt QuickTime wel aan de movietijdschaal voor de eenvoud zo te kiezen dat de lengte van een frame overeenkomt met een geheel aantal tijdseenheden in movietijd, en dus ook in mediatijd. Vaak worden de movie- en mediatijdschaal gelijk gekozen aan 600. Dit getal is immers deelbaar door 24, 25, 30, 50, en 60, wat veel voorkomende vaste beeldsnelheden zijn. Door een dergelijke keuze te maken kan men, bij het samenstellen van een movie, het rekenwerk sterk vereenvoudigen. In het geval van tweening kan men eveneens moeilijk spreken van een beeldsnelheid. Tweening houdt in dat er een algoritme wordt toegepast dat in staat is om bepaalde data te interpolleren zodat een overgang tussen twee totaal verschillende beelden vloeiend wordt weergegeven. Op die manier wordt een discrete transitie omgezet naar een continue 7

Ter illustratie, zoals we weten speelt NTSC exact 30/1.001 frames per seconde af. Een mediatijdschaal van 30000 en een duur voor de samples van 1001 TE, samen met een movietijdschaal van 30000, levert 19.9 uren correcte afspeeltijd op met een 32-bits voorstelling van de bepalende parameters. Sommige bestaande movies maken echter gebruik van een mediatijdschaal 2997 en een duur voor de samples van 100 TE, samen met een movietijdschaal van 2997. Dit levert 8.2 dagen tijd op voor een 32-bits overflow optreedt. Echter, na 4.6 uren, is er reeds sprake van een afwijking van het videobeeld t.o.v. het echte videosignaal ter grootte van een halve frame.

38

overgang met als gevolg dat men niet langer kan spreken over twee beelden. Het zijn er in feite zoveel als men zelf wil. Voor movies die zowel audiotracks als videotracks bevatten, is het soms wenselijk om editeerbewerkingen uit te voeren op een audiotrack met een granulariteit die fijner is dan een videobeeld. Aangezien bijna alle editeerbewerkingen in de QuickTime API uitgedrukt worden in movietijd, zou er in principe een tijdschaal moeten gekozen worden die voldoet aan zowel de noden van editeerbewerkingen op audiosporen als aan de noden van editeerbewerkingen op videosporen. Normaliter zou er dan moeten gekozen worden voor een tijdschaal die het kleinste gemeenschappelijke veelvoud is van de verschillende video- en audiotijdschalen. Terwijl videotracks typisch gekenmerkt worden door een tijdschaal gelijk aan 600, hebben audiosporen doorgaans een tijdschaal die gelijkgesteld is aan de sample rate (bv. 22050, 44100, 48000). Voor sommige combinaties van audio- en videotijdschalen kan dit resulteren in een 32-bits overflow. Er is dus min of meer sprake van een tradeoff. Welke beslissing er precies genomen wordt, is doorgaans applicatie-afhankelijk. Vaak zal de movietijdschaal gelijk gekozen worden aan 600, waarbij dan de voorkeur uitgaat naar het videospoor.

3.5

Interessante tijden

Zoals reeds gezegd is een sample en een vaste sample rate een betrekkelijk begrip voor QuickTime. Een vaste sample rate is mooi meegenomen omdat het veel zaken zoals editeerbewerkingen vergemakkelijkt, maar het is geen absolute vereiste. Ieder sample kan in QuickTime immers een eigen duur hebben. Omwille van deze variabele sample rate stelt QuickTime via de API een aantal functies ter beschikking die in staat zijn om samples terug te vinden in movies, tracks, en mediastructuren8 . Deze functies zijn allemaal gebaseerd op het concept interessante tijden (times of interest). Een interessante tijd refereert naar een bepaald punt in een movie, in een track, of in een mediastructuur dat aan zekere (zoek)criteria voldoet. Deze criteria worden opgegeven aan de Movie Toolbox, een centrale component in QuickTime die de primaire code bevat voor het werken met movies en moviebestanden. De Movie Toolbox zal dan de movie, track, of mediastructuur overlopen en op zoek gaan naar die tijdswaarden die voldoen aan de opgegeven zoekcriteria. Deze functies kunnen o.a. gebruikt worden om beeldsequenties te analyseren, bijvoorbeeld om op zoek te gaan naar alle beelden in een videospoor. Of ze kunnen bijvoorbeeld gebruikt worden om key frames te localiseren. Informatie over key frames is heel belangrijk bij het optimaliseren van de manier waarop beelden gepresenteerd worden. Hoe meer key frames, hoe minder rekenkracht er nodig is 8

Met mediastructuur bedoel ik de collectie van samples zoals die op schijf is opgeslagen, m.a.w. hiermee bedoel ik mediadata die nog niet georganiseerd is tot een presentatie via tracks. Wanneer een track de gedaante S 2 S 1 S 3 S 2 S 1 heeft, dan is de corresponderende mediastructuur van de vorm S 1 S 2 S 3 , met S i een sample.

39

en hoe vloeiender beelden kunnen weergegeven worden. Een nadeel van het gebruik van veel key frames is dat het volume van de moviedata op schijf toeneemt. Via deze functies is het ook gemakkelijk na te gaan of een movie bewerkt of ge¨editeerd werd. Ze kunnen immers ook gebruikt worden om het aantal elementen te tellen in een edit list. De Movie Toolbox identificeert een interessante tijd door het teruggeven van een starttijd en een duur. De starttijd geeft het tijdstip aan in de movie, track of mediastructuur, waarop aan de opgegeven zoekcriteria voldaan werd. De teruggegeven duur levert informatie op over hoe lang aan het opgegeven criteria gedaan werd. Bijvoorbeeld, indien men op zoek is naar samples in de mediastructuur, dan geeft de starttijd het begintijdstip aan van het sample in de mediastructuur, en de duur geeft dan de lengte aan van het sample. In dit geval kan het begintijdstip van het volgende sample reeds gevonden worden door de duur van het sample op te stellen bij het begintijdstip van het sample. De waarde van de duur is steeds positief; merk bovendien op dat het mogelijk is om een movie, track of mediastructuur zowel voorwaarts als achterwaarts te doorzoeken.

3.6

Tijd en beeld in de praktijk.

Wanneer er gezocht wordt naar interessante tijden op het niveau van een movie, dan eindigt een interessante tijd wanneer een andere interessante tijd start in eender welke track van de movie. Bijvoorbeeld, wanneer men zoekt naar key frames in een movie, dan geeft de waarde van de duur van een interessante tijd het tijdstip aan wanneer een volgend key frame start. Het is echter perfect mogelijk dat dit key frame behoort tot een andere track van de movie. Dit zorgt ervoor dat de duur van een interessante tijd niet noodzakelijk correspondeert met de duur van het key frame. Het zorgt er eveneens voor dat het niet zo eenvoudig is om het aantal frames te bepalen in een QuickTime movie. Denk hierbij maar aan het geval van een movie waarbij er twee videotracks simultaan afgespeeld worden, bijvoorbeeld een combinatie van een normaal videospoor met een videospoor met daarin reclame, en dit elk tegen een eigen beeldsnelheid. In dat geval kan er alleen maar zinvol gepraat worden over een beeldsnelheid op het niveau van een track en niet op het niveau van een movie. Merk op dat een beeldsnelheid op het niveau van een spoor zelfs voor discussie vatbaar is indien dit spoor gaps of gaten bevat. In de zelfontwikkelde testapplicatie wordt er geen rekening gehouden met dergelijke speciale gevallen en gebruik ik de functie GetMovieNextInterestingTime() om het aantal interessante punten te bepalen in een movie. Wanneer het een normale movie betreft, zijnde een movie opgebouwd uit ´e´en videotrack en ´e´en audiotrack, dan vallen de interessante punten samen met beeldgrenzen bij het opgeven van de vlaggen nextTimeMediaSample, nextTimeEdgeOK, nextTimeStep, en VisualMediaCharacteristic. Een bijzonder woordje uitleg verdient de vlag nextTimeStep. Deze zorgt ervoor dat er in onze context van videodata binnen een sample op zoek kan gegaan worden naar frames. Dit is nodig wanneer een movie een track bevat die verwijst naar videodata

40

die gecomprimeerd werd via MPEG-1 ([Chi96]) of MPEG-29 ([Chi00]) omdat QuickTime MPEG-data opslaat onder de vorm van ´e´en sample waarin zowel de video- als audiodata worden gestockeerd10 . De vlag nextTimeStep wordt in de praktijk echter niet vaak gebruikt in combinatie met MPEG omdat ze veel te traag is. Dit heeft in zekere zin ook wel te maken met het feit dat MPEG-1 en MPEG-2 geen formaten zijn die zich gemakkelijk lenen tot manipulatie, zoals editeren. Het zijn eerder passieve “zit-en-kijk” formaten, wanneer MPEG-1 en MPEG-2 bekeken worden vanuit het standpunt van QuickTime. Dit wordt niet negatief bedoeld, aangezien MPEG-1 en MPEG-2 gericht zijn op compressie van computerdata terwijl de klemtoon bij QuickTime eerder ligt op het organiseren van data in de tijd. Men kan dit trouwens ook afleiden uit het gebruik van Sorenson Video 3 en QDesign Music 2. Respectievelijk zijn dit de populairste video- en audiocompressor die in combinatie met QuickTime toegepast worden en waarbij deze niet door door Apple zelf ontwikkeld werden. Omdat het analyseren van alle frames in een movie op zich al niet zo snel is, en omdat dit in mijn applicatie toch vaak moet gebeuren, bijvoorbeeld voor het dumpen van frames, wordt er door Atomic Player bij het inladen van een movie een tabel opgebouwd met daarin informatie over de framegrenzen. Met andere woorden, het is een tabel die ge¨ındexeerd wordt op framenummer en die als resultaat het begintijdstip oplevert van het frame in movietijd. Op die manier is het eenvoudig om een functie toe te voegen aan de QuickTime API die toelaat om zeer snel naar een bepaald frame te springen. Deze functie wordt gebruikt om andere framegebaseerde functies te cre¨eren. Bovendien is het geheugengebruik van de tabel vrij klein in vergelijking met de grootte van de moviedata aangezien de entries in de tabel slechts 32 bits groot zijn (tijdswaarden zijn 32-bits). Het opbouwen van de tabel gebeurt m.b.v. de functie GetMovieNextInterestingTime() die, zoals reeds besproken, het mogelijk maakt om het exact aantal beelden te bepalen in een normale movie. Deze functie uit de QuickTime API laat dus toe te manoeuvreren van het ene beeld naar het andere waarbij we het begintijdstip van ieder beeld in movietijd bijhouden in een tabel. Voor het inschatten van de door de tabel vereiste hoeveelheid geheugen wordt er gebruik gemaakt van een zelfgeschreven heuristische functie GetEstimatedNumberOfFramesViaRand(). Op die manier kunnen we het (de)alloceren van geheugen tijdens het opbouwen van de tabel tot een minimum beperken. Immers, bij het inladen van de movie weten we niet hoeveel beelden er in de movie aanwezig zijn zodat we ook de exacte grootte van onze tabel niet kennen. GetEstimatedNumberOfFramesViaRand() selecteert bij willekeur NR CHOICES verschillende meetpunten in de movie en berekent dan de corresponderende beeldlengtes. Deze worden uitgemiddeld en nadien gedeeld door de duur van de movie om zo een schatting van het aantal frames te bekomen. Dit levert meestal 9

MPEG-1 en MPEG-4 ([Koe02]) worden door QuickTime rechtstreeks ondersteund. MPEG-2 is echter alleen beschikbaar door gebruik te maken van codecs die geschreven werden door anderen (licentieproblemen). 10 Analoog voor Flashdata.

41

een heel goede benadering op. In tabel 3.1 ziet u een overzicht van enkele resultaten die bekomen werden door gebruik te maken van verschillende heuristische functies voor het bepalen van het aantal frames in een normale movie. De parameter NR CHOICES had de waarde 64 bij GetEstimatedNumberOfFramesViaRand(). Movie

#Frames

Duur (msec)

Functie

120

GetMovieNextInterestingTime()

2550

10

Ad Random

6376

0

First Frame

2550

0

Aging

250

GetMovieNextInterestingTime()

5101

10

Ad Random

12752

0

First Frame

5100

0

Aging

370

GetMovieNextInterestingTime()

7651

10

Ad Random

19128

0

First Frame

7651

0

Aging

501

GetMovieNextInterestingTime()

10202

10

Ad Random

25504

0

First Frame

10201

0

Aging

621

GetMovieNextInterestingTime()

12752

10

Ad Random

31880

0

First Frame

12752

0

Aging

Monsters Inc. 1 2551

Monsters Inc. 2 5102

Monsters Inc. 3 7653

Monsters Inc. 4 10204

Monsters Inc. 5 12755

Tabel 3.1: Een overzicht van de resultaten die bekomen werden door het aantal frames in vijf movies te tellen via verschillende technieken. De tweede kolom toont het aantal frames dat met een welbepaalde methode bekomen werd terwijl de derde kolom de tijdsduur aangeeft die nodig was om tot dat resultaat te komen. Movie 2 werd bekomen door de beelden van movie 1 nog eens achter zichzelf te plaatsen. Op een analoge manier werden de overige movies gecre¨eerd. De videodata in de movies was gecodeerd m.b.v. Sorenson Video 3 en de audiodata m.b.v. QDesign Music 2. Tot slot wil ik ook nog vermelden dat de test werd uitgevoerd onder Windows 2000 met behulp van Atomic Player en dit op een Pentium III 1GHz met 384 MB RAM.

GetEstimatedNumberOfFramesViaFirstVideoFrame() berekent het aantal frames door de lengte te beschouwen van het eerste frame, en dit dan te gebruiken als deler voor de

42

totale duur van de movie. Deze functie zal bijvoorbeeld slecht presteren indien het eerste frame kort is en alle andere frames vrij lang, wat toevallig van toepassing was op de testmovie. Alle beelden hadden immers een duur van 25 TE, behalve het eerste beeld. Dit werd gekenmerkt door een duur van 10 TE en deze afwijking vormt dan ook de verklaring voor de grote waarden die afgeleverd werden door GetEstimatedNumberOfFramesViaFirstVideoFrame(). De functie GetEstimatedNumberOfFramesViaAging() berekent eveneens een schatting van het aantal frames en dit door gebruik te maken van aging ([Tan01]). Dit is een techniek waarbij een schatting wordt gemaakt van de volgende waarde in een reeks van waarden door het gewogen gemiddelde te berekenen van de huidig gemeten waarde met de vorige schatting. Aging wordt bijvoorbeeld gebruikt door sommige schedulingsalgoritmen in besturingssystemen en dit voor het bepalen van het volgende uit te voeren (kortste) proces. Neem aan dat T 1 de duur is van het eerste frame en zij T 2 de duur van het tweede frame. Als schatting voor de duur van het derde frame kunnen we de volgende formule aanwenden: aT 1 + (1 - a)T 2 . Via de parameter a is het mogelijk te bepalen hoe snel het schattingsproces informatie uit het verleden vergeet. Voor a = 1/2 bekomen we de volgende opeenvolgende schattingen: T 1 als schatting voor de duur van het tweede frame, T 1 /2 + T 2 /2 als schatting voor de duur van het derde frame, 1/2(T 1 /2 + T 2 /2) + T 3 /2 = T 1 /4 + T 2 /4 + T 3 /2 als schatting voor de duur van het vierde frame,. . . Belangrijke parameters voor dit algoritme zijn AGING PARAM en AGING MAX, die respectievelijk bepalen hoe snel informatie over het verleden verloren gaat en hoe lang dit verleden is, m.a.w. hoeveel frames er moeten onderzocht worden. In het experiment hadden ze (respectievelijk) de waarde 0.5 en 128. Aging zal vrij goed functioneren indien een movie gekenmerkt wordt door een grillig begin maar nadien in een regimetoestand terechtkomt. Voorwaarde is wel dat die evenwichtstoestand door het algoritme kan gedetecteerd worden en dit is alleen maar mogelijk door een gepaste waarde te kiezen voor de parameter AGING MAX. Tabel 3.1 maakt ook duidelijk dat er een lineair verband bestaat tussen het aantal frames en de tijd nodig om het aantal frames te berekenen bij gebruik van de functie GetMovieNextInterestingTime(). Wanneer het aantal beelden verdubbelt, verdubbelt eveneens de rekentijd die nodig is om dit aantal beelden exact te bepalen.

3.7

De creatie van een movie

In hoofdstuk 2 werd er reeds aangehaald dat tracks de bouwstenen zijn van een movie. Tracks zijn een familiair concept uit de audiotechnologie, waar ze gebruikt worden om verschillende geluidssequenties met elkaar te mixen en met elkaar te laten overlappen, resulterend in ´e´en enkele output. Op net dezelfde manier gebruikt QuickTime sporen in een movie om data van verschillende types met elkaar te combineren tot ´e´en enkele gebruikerservaring.

43

Een movie kan verschillende tracks bevatten, waarbij ieder spoor mediadata van ´e´en welbepaald type in de tijd organiseert. Het type media bepaalt het type van de track, welk kan vari¨eren over alle mogelijke datatypes die QuickTime kan interpreteren: • gedigitaliseerde videodata (MPEG, DV, AVI,. . . ) • gedigitaliseerde audiodata (AIFF, ULAW, WAVE, MP3,. . . ) • stilstaande beelden (JPEG, GIF, BMP, PNG,. . . ) • animatie (Animated GIF, FLC, PICS,. . . ) • virtuele realiteit, MIDI, tekst, real-time streaming types,. . . Ieder mediatype wordt verwerkt door een eigen media handler component. Dergelijke componenten, welke later nog uitgebreid aan bod zullen komen, zijn soms in staat om verschillende types te interpreteren. Alle tracks in een movie gebruiken het movietijdsco¨ordinatensysteem, maar de media waartoe ze toegang hebben gebruiken een eigen notie van tijd. Bijvoorbeeld, een videotrack kan beelden afspelen tegen een snelheid van 30 frames per seconde, terwijl een audiotrack samples kan afspelen tegen een snelheid van 22050 audiosamples per seconde. QuickTime is verantwoordelijk voor de conversie tussen de verschillende tijdssystemen. Iedere track begint bij de start van de movie, maar de data in de track kan bijvoorbeeld maar voor het eerst aangesproken worden vanaf een tijdstip verschillend van nul. Dit tijdstip wordt de track offset genoemd. Het initieel lege gedeelte wordt bij een audiotrack voorgesteld door stilte, en bij een videotrack door het ontbreken van beeld. Iedere track heeft ook een bepaalde duur, die korter kan zijn dan de duur van een movie. De duur van een movie is steeds gelijk aan de duur van z’n langste track. Zoals reeds vermeld bevat een track een lijst van referenties die de verschillende mediasamples identificeren waarvan het gebruik maakt. Deze verzameling referenties noemt men de edit list. Het is een uiterst belangrijke datastructuur die een zeer flexibele relatie mogelijk zal maken tussen een track en de verschillende mediasamples die het moet afspelen; de mediasamples, opgeborgen in een mediacontainer, kunnen in eender welke volgorde afgespeeld worden en elk mediasample kan een onbeperkt aantal maal opgenomen worden in de edit list. Door in de edit list dezelfde sequentie van mediasamples meerdere malen op te nemen, is het bijvoorbeeld mogelijk een lus te cre¨eren in de movie. Net zoals een movie bevat een track gegevens over de datum en tijd van creatie en wijziging, een transformatiematrix, gebruikersdata,. . . Gebruikersdata is extra data die kan bewaard worden bij een movie of een track en die o.a. toelaat informatie op te slaan i.v.m. auteursrechten, voorkeursinstellingen, enzoverder. Zoals aangegeven in [Tow99] gebeurt de uiteindelijke creatie van een nieuwe movie door het uitvoeren van een aantal opeenvolgende stappen. Hieronder volgt een chronologische en vereenvoudigde opsomming van de verschillende stappen die moeten uitgevoerd worden om een niewe movie aan te maken. Deze nieuwe movie zal bestaan uit ´e´en videotrack:

44

0

Movietijdschaal

Track Duur Track Offset

Mediatijdschaal

0

Dit stuk is niet opgenomen in de track

Media TE

Mediaduur

Figuur 3.3: Een track met bijhorende media. 1. Cre¨eer en open een moviebestand voor de nieuwe movie. 2. Cre¨eer een lege movie in het geheugen. 3. Voeg een track toe aan de lege movie. 4. Vertel QuickTime wat het type is van de track. In dit geval is de track van het type VideoMediaType (’vide’). Op die manier kan QuickTime de gepaste mediacontainer aanmaken en kan het in de metadata van de track informatie opslaan over de media handler die verantwoordelijk zal zijn voor de interpretatie van de toegevoegde mediadata. 5. Begin een media-editeersessie. Dit laat toe dat de mediadata in de mediacontainer gewijzigd wordt. 6. Voeg datasamples toe aan de mediacontainer. Mediasamples worden steeds achteraan de mediacontainer toegevoegd. Bovendien moet ieder sample voorzien worden van een beschrijving. In het geval van videosamples zal de beschrijving bijvoorbeeld informatie bevatten over het algoritme dat gebruikt werd voor de compressie van de videodata. Op die manier zal de video media handler in staat zijn om de video data correct te interpreteren. Merk op dat veel samples doorgaans dezelfde beschrijving zullen delen waardoor deze dan ook maar ´e´en maal moet opgeslagen worden. 7. Be¨eindig de media-editeersessie.

45

8. Voeg aan de track referenties toe naar de mediasamples, m.a.w. start het eigenlijke editeerwerk. Hierbij moet er opgegeven worden waar een bepaalde mediareferentie in de track moet terecht komen. Dit zal gebeuren door een punt op te geven in movietijd (het punt trackStart, zie ook figuur 3.4). Een mediareferentie zal eveneens gekenmerkt worden door een bepaald begin in de mediacontainer, zijnde een punt in de mediatijd (het punt mediaTijd). Verder zal er ook sprake zijn van een zekere duur (mediaDuur). De duur zal iets zeggen over het aantal opeenvolgende samples dat uit de mediacontainer, vanaf het opgegeven begintijdstip in mediatijd, moet toegevoegd worden aan de track. Tot slot zal het ook nog mogelijk zijn om QuickTime iets te vertellen over de snelheid waarmee de betreffende samples in de mediareferentie moeten afgespeeld worden (de mediaRate). Merk op dat het triplet <mediaDuur uitgedrukt in movietijd, mediaTijd uitgedrukt in mediatijd, mediaRate> een entry vormt in de edit list. Dit zal eveneens aan bod komen in het hoofdstuk over het QuickTime bestandsformaat, meer bepaald in paragraaf 5.5. 9. Voeg de movie toe aan het moviebestand. 10. Sluit het moviebestand. We kunnen dus vaststellen dat er editeerbewerkingen plaatsvinden op twee niveaus. Enerzijds op het niveau van de media (toevoegen, verwijderen of aanpassen van samples) en anderzijds op het niveau van een track (toevoegen, verwijderen of aanpassen van mediareferenties). Hierbij kan men het volgende opmerken: • De mediaTijd van nieuwe samples neemt toe naarmate samples worden toegevoegd aan de mediacontainer die bij een bepaalde track hoort. • Er kunnen gaten zitten tussen de locaties van samples in een track en geen twee samples hebben dezelfde trackStart tijd. Figuur 3.4 toont een typische track waarbij er aan de edit list van de track verschillende mediasamples werden toegevoegd. Zoals u kan zien, bevat de mediastructuur of mediacontainer de verschillende stukken media die door de movie gebruikt worden; de track bepaalt hoe en wanneer deze stukken mediadata worden afgespeeld. Een mediacontainer zou je als het ware ook kunnen vergelijken met een stapel van mediasamples, waarbij de duur van de media gelijk is aan de som van de verschillende lengtes van de samples in de container. Wanneer een movie afgespeeld wordt en de tijd bereikt die opgegeven is via trackStart voor ´e´en van z’n tracks, dan zal QuickTime beginnen met het ophalen van datasamples vanaf het begintijdstip mediaTijd, hierbij gebruik makend van de volgende stappen: • Het lokaliseert de samples in een mediacontainer.

46

trackStart1

trackStart2

trackStart3

trackStart4

Track

Media Container

mediaTijd1

mediaTijd2

mediaDuur1

mediaTijd3 mediaDuur2

mediaTijd4

mediaDuur3

Figuur 3.4: Media samples in een mediacontainer worden toegevoegd aan een track. De samples worden gekenmerkt door een starttijd en een duur, uitgedrukt in mediatijdseenheden, terwijl de positie van ieder sample in de track wordt gespecificeerd door een starttijd, uitgedrukt in movietijdseenheden. Merk op dat mediaTijd1 < mediaTijd2 < mediaTijd3 < mediaTijd4.

• Het interpreteert ieder sample op basis van z’n sample beschrijving, decompressie uitvoerend indien nodig. • Het speelt ieder datasample af tegen een snelheid van mediaRate maal de huidige movie afspeelsnelheid. • Het speelt samples af totdat mediaDuur tijd verstreken is. Dit is de manier waarop QuickTime moviedata vertoont aan een gebruiker. Terwijl een movie gepresenteerd wordt, worden er meerdere tracks al dan niet simultaan afgespeeld, waarbij iedere track gekenmerk wordt door data van een welbepaald type (video, geluid, tekst,. . . ). Vanuit het standpunt van de gebruiker is het resultaat een volledige multimedia-ervaring.

47

Hoofdstuk 4 QuickTime Componenten QuickTime is niet alleen ontworpen om op een triviale manier multimediadiensten ter beschikking te stellen van een gebruiker, het is er eveneens op gericht om zo eenvoudig mogelijk functionaliteit te kunnen aanbieden aan de ontwerpers van applicaties. Dit hoofdstuk beschrijft de modulaire opbouw van QuickTime die ervoor zorgt dat het eveneens garant staat voor een krachtige en flexibele programmeeromgeving. Verder zal er dieper ingegaan worden op de werking van enkele belangrijke componenten, waaronder enkele zelfgeschreven componenten die het mogelijk maken om XML-data uit te wisselen met een QuickTime movie.

4.1

Inleiding

Een component is een stuk QuickTime code dat in staat is om een welomschreven set van diensten aan te bieden aan ´e´en of meerdere clients, m.a.w. het zijn kleine (geparametriseerde) programmaonderdelen die bepaalde functionaliteiten voor hun rekening nemen en die onder ideale omstandigheden herbruikbaar zijn. Applicaties die gebruik maken van de door QuickTime aangeboden functionaliteit voeren in feite voortdurend oproepen uit naar componenten. Daarenboven roepen QuickTime componenten elkaar eveneens continu op. De QuickTime bibliotheek bevat ongeveer 600 componenten, waarbij iedere component verantwoordelijk is voor het uitvoeren van een specifieke taak. Bovendien zal elke component eveneens voldoen aan een duidelijk gedefinieerde interface. Zo is het bijvoorbeeld mogelijk dat een component compressiediensten aanbiedt. Wanneer een applicatie een beroep wil doen op deze compressiefaciliteiten, dan zal het een beeld ter verwerking moeten afleveren. Na de gewenste bewerking uitgevoerd te hebben, zal de component het gecomprimeerde beeld teruggeven aan de applicatie. Een interface is als het ware te vergelijken met een contract waarin staat welke diensten er aangeboden worden, welke parameters er aanvaard worden en welke gegevens er moeten weergegeven worden.

48

Een aantal componenten kunnen dezelfde diensten aanbieden, maar verschillen dan onderling van elkaar door het niveau van de dienstverlening. Denk hierbij bijvoorbeeld aan twee componenten die allebei in staat zijn om beelden te comprimeren; de ene component doet dit met een factor 2, terwijl de andere component dit doet met een factor 3 door een geringere beeldkwaliteit toe te laten. Ondanks dit verschil moeten beide componenten wel dezelfde basisinterface ondersteunen. Dit laat toe dat code kan gebruik maken van een aantal gestandaardiseerde oproepen in het geval van een bepaald type componenten, terwijl terzelfdertijd toch een verschil in dienstverlening kan afgedwongen worden. Componenten werken ook volgens het black box principe: enkel de interface naar de component is gekend, maar hoe de functionaliteit ge¨ımplementeerd werd, wordt verborgen gehouden voor de client. Dit heeft voornamelijk voordelen, zoals het feit dat er op die manier aan complexiteitsbeheersing van een probleem kan gedaan worden. Nochtans zijn er ook een aantal minpunten. Het is niet zo eenvoudig om enig inzicht te verwerven in het functioneren van een bepaald concept indien de precieze werking ervan verborgen gehouden wordt. Ook wanneer er iets fout loopt, is het vaak moeilijker te kunnen interpreteren wat er juist mis is gegaan, tenzij er gewerkt wordt met een gestructureerd foutafhandelingsmechanisme, wat bij QuickTime componenten gelukkig het geval is. Dit laatste kan zelfs veralgemeend worden tot de volledige QuickTime Software Development Kit (SDK). Verder is het ook belangrijk te weten dat QuickTime over een ganse waaier aan mogelijkheden beschikt om de functionaliteit van bestaande componenten uit te breiden of om zelf nieuwe componenten toe te voegen. Dit zorgt ervoor dat de architectuur van QuickTime zeer sterk toekomstgericht is. Immers, dankzij het feit dat er zelfgeschreven componenten aan QuickTime kunnen toegevoegd worden, is het mogelijk QuickTime met nieuwe diensten of dataformaten uit te breiden. Vaak kan dit gerealiseerd worden zonder dat daartoe reeds bestaande applicaties moeten weggegooid worden. In veel gevallen zullen deze oude toepassingen zelfs toegang verkrijgen tot nieuwe multimediamogelijkheden zonder dat ze moeten herschreven worden. Voor ontwikkelaars van nieuwe componenten heeft Apple een heel interessante infrastructuur in het leven geroepen, namelijk het QuickTime Component Download programma. Dankzij dit initiatief is het vrij eenvoudig om een zelfgeschreven component voor de ganse wereld ter beschikking te stellen. Immers, dit project geeft ontwikkelaars de mogelijkheid om hun nieuwe component op de servers van Apple te plaatsen, mits er aan bepaalde voorwaarden voldaan is (veiligheid,. . . ). Bijvoorbeeld, een applicatie die gebruik maakt van QuickTime en die na analyse een onbekend dataformaat aantreft in een multimediabestand, zal automatisch de servers van Apple contacteren om na te gaan of er een component beschikbaar is die het onbekende formaat kan interpreteren. Merk op dat de analyse van een multimediabestand vrij grondig uitgevoerd wordt. Indien het bestandstype door QuickTime niet kan bepaald worden door in eerste instantie te kijken naar de extensie in de bestandsnaam, dan zal het de hoofding van het bestand en eventueel andere interne datastructuren onderzoeken.

49

Vooraleer dieper in te gaan op de manier waarop componenten door QuickTime beheerd worden, is het ook nog interessant te vermelden dat een component beschreven wordt aan de hand van een structuur die opgebouwd is uit vijf datavelden. • Het dataveld componentType bevat een vierkaraktercode die het type van de component vastlegt. Bijvoorbeeld, het type van een component die in staat is om aan beelddecompressie te doen, is ’imdc’. Alle componenten van hetzelfde type moeten dezelfde interface ondersteunen. De door een component ondersteunde interface zal dus volledig afhangen van het type van de component. • Het dataveld componentSubType bevat een vierkaraktercode die het subtype van de component vastlegt. Verschillende subtypes van hetzelfde componenttype zullen een ander niveau van dienstverlening verzorgen. Bijvoorbeeld, het subtype van een component die JPEG-decompressie ondersteunt, is ’jpeg’. • Het dataveld componentManufacturer bevat een vierkaraktercode die de ontwikkelaar van de component identificeert. Componenten die bijvoorbeeld ontwikkeld werden door Apple hebben voor dit veld de waarde ’appl’. • Het dataveld componentFlags is een 32-bits veld dat extra informatie aanbiedt over een bepaalde component. Dit kan bijvoorbeeld gebruikt worden om aan te geven welke de mogelijkheden zijn van een component, bijvoorbeeld enkel inlezen van data uit een geheugenbuffer en niet vanuit een bestand. • Het dataveld componentFlagsMask is een 32-bits veld dat kan gebruikt worden om te weten welke vlaggen er relevant zijn voor een bepaald componenttype. Dit is handig wanneer er gezocht wordt naar een component die een specifieke dienst kan uitvoeren. Op die manier zullen er tijdens een zoekproces volledige componentklassen kunnen genegeerd worden.

4.2

Het beheer van componenten

De Component Manager (CM) zal instaan voor het centraal beheer van componenten en zal eveneens mogelijkheden aanbieden voor het verwerven van toegang tot hun functionaliteiten. Op die manier kunnen verschillende applicaties gebruik maken van dezelfde componenten en moeten deze ook maar ´e´en maal opgeslagen worden. De CM classificeert componenten op basis van drie criteria: het type dienstverlening, het niveau van de dienstverlening, en de ontwikkelaar van de component. Gegeven een bepaald componenttype, is de CM in staat om alle componenten van dat type te lokaliseren en te bevragen. Zo is het mogelijk om uit te vinden hoeveel componenten er van een bepaald type op het systeem aanwezig zijn en is het eveneens mogelijk om uit te zoeken wat de mogelijkheden van een component zijn zonder dat er eerst een connectie naar de betreffende component

50

moet geopend worden. Voor iedere component die opgenomen is in de lijst die door de CM beheerd wordt, is er eveneens informatie opgenomen over de naam, het icoon en de informatiestring die bij een bepaalde component hoort. Atomic Player

Component Manager

Beeld decompressie component (type ‘imdc’ Subtype ‘jpeg’)

Teken component (type ‘draw’ Subtype ‘oval’)

Teken component (type ‘draw’ Subtype ‘rect’)

Klok component (type ‘clok’ Subtype ‘micr’)

Figuur 4.1: De relatie tussen Atomic Player, de Component Manager, en enkele componenten. Figuur 4.1 toont de relatie tussen een applicatie, de CM, en enkele componenten. Applicaties en andere componenten moeten dus gebruik maken van de CM om toegang te bekomen tot componenten. In de figuur zien we dat er voor de applicatie vier componenten aanwezig zijn: een beelddecompressiecomponent (van het type ’idmc’), twee tekencomponenten (van het type ’draw’), en een klokcomponent (van het type ’clok’). Bemerk dat de twee tekencomponenten elk verschillende subtypes hebben: ’oval’ en ’rect’. De tekencomponent met het subtype ’oval’ tekent ovalen, en de tekencomponent met het subtype ’rect’ tekent rechthoeken. De tekencomponenten ondersteunen dezelfde interface maar verlenen elk een eigen type dienstverlening. De CM laat toe dat ´e´en enkele component meerdere clients terzelfdertijd bedient. Iedere client zal hiertoe een uniek toegangspad toegewezen krijgen naar de component. Deze toegangspaden worden componentverbindingen genoemd. Een componentverbinding wordt ge¨ıdentificeerd door middel van een componentinstantie. De CM levert deze componentinstantie af aan de client wanneer deze een verbinding opent naar de component. Voor iedere verbinding die opgezet wordt, zal de CM statusinformatie bijhouden, zoals informatie over het globaal geheugen dat met die verbinding geassocieerd is. Meerdere applicaties, zoals de QuickTime mediaspeler en Atomic Player, kunnen dus een verbinding openen naar dezelfde beelddecompressiecomponent. De CM zal verantwoordelijk zijn voor het beheer van die verbindingen en zal ervoor zorgen dat boodschappen over de correcte connectie verstuurd worden, zodanig dat verschillende toepassingen niet op een ongewenste manier met elkaar kunnen interfereren. Applicaties moeten dus gebruik maken van de diensten van de CM om componenten te vinden die aan hun noden voldoen. Vooraleer een applicatie een specifieke component kan lokaliseren, moet deze geregistreerd zijn bij de CM. Wanneer een component geregistreerd wordt, zal de Component Manager deze toevoegen aan een lijst van beschikbare

51

componenten. Dit is heel belangrijk. Bijvoorbeeld, in Atomic Player wordt er gebruik gemaakt van componenten om te werken met het eigen mediatype ’XMLT’. Wanneer deze componenten echter niet geregistreerd zijn, en QuickTime detecteert een track van het type ’XMLT’ waarvoor het geen gepaste component kan vinden, dan zal het contact leggen met de servers van Apple om daar op zoek te gaan naar een geschikte component. Deze zullen echter niets afweten van XMLT-componenten waardoor QuickTime genoodzaakt is om z’n zoektocht te staken en om een foutboodschap op het scherm uit te schrijven. Er zijn twee mechanismen om componenten te registreren bij de CM. Bij de eerste manier wordt tijdens het opstarten van het systeem een speciale directory doorzocht, de zogenaamde Extensions Folder. Bij Windows 2000 is dit doorgaans de directory c:\winnt\system32\quicktime en wordt er gezocht naar bestanden met als extensie qtx. Indien een dergelijk bestand voldoende informatie bevat voor een succesvolle registratie, dan zal de component, die zich in deze file bevindt, automatisch bij de CM geregistreerd worden. Een dergelijk bestand kan ook meerdere componenten bevatten. Bij de tweede manier is het een applicatie die verantwoordelijk is voor de registratie. Hierbij is het mogelijk om aan te geven of de component globaal (voor alle applicaties) of lokaal (enkel voor de registrerende applicatie) moet geregistreerd worden. Atomic Player maakt gebruik van de laatste optie. Via Atomic Player is het ook mogelijk om een lijst op te vragen van alle componenten die geregistreerd zijn bij de CM. Merk op dat er ook nog andere managers aanwezig zijn in QuickTime. Zo is er ook nog de Gestalt Manager die kan gebruikt worden om systeeminformatie op te vragen, zoals de huidige versie van QuickTime, het gebruikte OS,. . .

4.3

Enkele belangrijke componenten

In de komende paragrafen zal de werking van een aantal componenten toegelicht worden. Meer bepaald zal er stilgestaan worden bij het gebruik van de Movie Toolbox, Movie Controllers, Movie Data Exchange componenten, en Derived Media Handlers. Tot slot zal er ook gekeken worden naar het werken met video-effecten aangezien elk video-effect ge¨ımplementeerd wordt aan de hand van een component. Voor een volledig bespreking van bijna alle beschikbare QuickTime componenten verwijs ik naar [Inc93c].

4.3.1

De Movie Toolbox

De Movie Toolbox bevat de primaire code voor de creatie en aanmaak van movies en moviebestanden. Tevens zal er functionaliteit ter beschikking gesteld worden voor het afspelen van movies. Het betreft hier dus code die zeer veel zal aangesproken worden door toepassingen en andere QuickTime code. Het is een component die vooral thuishoort in de derde en vijfde laag van het QuickTime referentiemodel en die zowat het centraal brein

52

vormt van QuickTime. Het is niet mogelijk om de Movie Toolbox aan te passen of om zelf een Movie Toolbox te schrijven omwille van zijn fundamentele rol voor de goede werking van QuickTime. Atomic Player

Movie Controller

Movie Toolbox

Klok Component

Video Media Handler

Alias Data Handler

ICM decompressie

SV3 decoder

Tick Count

MonstersInc.mov

Gebruikerservaring

Figuur 4.2: Interactie tussen Atomic Player en QuickTime.

4.3.2

Movie Controllers

Een movie controller is een component die verantwoordelijk is voor het aanbieden van een visuele interface aan de gebruiker, zodat deze op een eenvoudige manier controle kan uitoefenen over het verloop van een multimediapresentatie. Tevens zal deze component het mogelijk maken om een aantal eenvoudige editeerbewerkingen uit te voeren. Een movie controller component is gebouwd bovenop de interface van de Movie Toolbox en vormt een intermediaire laag tussen een applicatie en de Movie Toolbox. Dit zal het voor de betreffende applicatie vaak eenvoudiger maken om met de Movie Toolbox te communiceren. Simpele kopieer-, plak-, en knipbewerkingen kunnen via een movie controller vrij snel ge¨ımplementeerd worden. Zoals u kan zien op figuur 4.3 is een movie controller opgebouwd uit verschillende elementen. Merk op dat de movie controller zichzelf configureert naargelang de situatie. Verandert de gebruiker bijvoorbeeld de grootte van de movie op een zodanige manier dat er niet genoeg plaats is om alle individuele elementen van de movie controller te tonen, dan zal deze laatste een aantal elementen elimineren. In het geval dat er bijvoorbeeld een movie zonder geluidsspoor geopend wordt, zal de movie controller automatisch de elementen die verantwoordelijk zijn voor de controle van het geluidsvolume verwijderen. Op figuur 4.3 ziet u eveneens een movie controller die voorzien is van een lijst van hoofdstukken (een

53

MovieBox

Afspeelknop

Tijdsindicator

Chapter List Stapknoppen

Knop voor wijzigen grootte

Tijdsbalk

Figuur 4.3: De standaard movie controller horende bij Atomic Player. chapter list). Dit geeft een gebruiker de mogelijkheid om snel doorheen een movie te bladeren. De movie controller zal aan een gebruiker eveneens toelaten de presentatie van een movie te stoppen of te starten door op het moviebeeld te klikken. Dit is een belangrijke eigenschap, omdat een gebruiker een movie nog steeds kan controleren in het geval dat de movie controller niet zichtbaar is. Movie controllers horen thuis in de vijfde laag van het QuickTime referentiemodel en het is mogelijk om een eigen controller te schrijven.

4.3.3

Movie Data Exchange componenten

Movie data exchange componenten geven aan applicaties de mogelijkheid om verschillende types data uit te wisselen met een QuickTime movie. Deze componenten worden gesitueerd in de derde laag van het QuickTime referentiemodel en worden normaal gezien enkel door de Movie Toolbox rechtstreeks aangesproken. Importcomponenten laten toe om vreemde dataformaten onder te brengen in een QuickTime movie. Bijvoorbeeld, een importcomponent zou afbeeldingen afkomstig van een tekenprogramma kunnen converteren naar frames in een QuickTime movie. Exportcomponenten bieden daarentegen faciliteiten aan om data die opgeslagen is in een QuickTime movie, te converteren naar een ander dataformaat, zodat deze gegevens ook door andere applicaties kunnen gebruikt worden. Bijvoorbeeld, een exportcomponent zou in staat kunnen zijn om een geluidsspoor van een QuickTime movie om te zetten naar het AIFF-formaat. De ge¨extraheerde geluidstrack zou dan kunnen gemanipuleerd worden door andere applicaties die helemaal niets van QuickTime afweten.

54

4.3.4

Media Handlers

Media handler componenten laten de Movie Toolbox toe om data, die opgeslagen liggen in een mediacontainer, af te spelen. De Movie Toolbox zelf kan geen moviedata lezen of schrijven. Deze input- en outputdiensten moeten door de Movie Toolbox aangevraagd worden bij media handlers. Deze componenten zullen de Movie Toolbox isoleren van de details over hoe en waar specifieke mediadata bewaard wordt, waardoor het mogelijk is om QuickTime uit te breiden met nieuwe dataformaten. De Movie Toolbox zal toegang verkrijgen tot een gepaste media handler voor een welbepaalde track in een movie door de metadata in de track te doorzoeken. Deze metadata zal informatie bevatten over welke media handler component er door QuickTime moet aangesproken worden om de mediadata in de track te interpreteren. Meer bepaald zal de gewenste media handler component in de metadata ge¨ıdentificeerd worden via een componenttype en een componentsubtype. Iedere media handler zal verantwoordelijk zijn voor het begrijpen van het formaat en de inhoud van het mediatype dat door de betreffende component ondersteund wordt. Een media handler zal zeer vertrouwd zijn met de gebruikte samplestructuur in de mediacontainer, de aangewende compressietechnieken, en de performantiekarakteristieken van het randapparaat dat gebruikt wordt om mediadata op te slaan. Bij het afspelen van een movie die bestaat uit een videotrack en een audiotrack zal de video media handler verantwoordelijk zijn voor het vertonen van de frames en zal de sound media handler instaan voor het afspelen van de audiosamples. Wanneer een applicatie een movie aanmaakt, zullen de media handlers eveneens zorgen voor het wegschrijven van de moviedata. Merk op dat het eigenlijke lezen, schrijven en cachen van data uitgevoerd wordt door een andere component, zijnde de data handler. Deze zal werken in dienst van een media handler en zal verantwoordelijk zijn voor het lezen of schrijven van een stroom bytes. Waar bytes moeten gelezen of geschreven worden door de data handler, en hoeveel, wordt berekend door de media handler. De data handler ziet dus enkel een stroom bytes. Het is de media handler die deze stroom bytes moet interpreteren. Dit zorgt ervoor dat een data handler door verschillende types media handlers kan gebruikt worden. Applicaties maken nooit op een directe manier gebruik van de diensten van media handlers. De Movie Toolbox controleert alle opslag en datahergebruik in functie van QuickTime toepassingen. Door de Movie Toolbox en QuickTime applicaties te isoleren van de details van toegang tot mediadata, wil Apple drie doelstellingen realiseren. Ten eerste, het afschermen laat ontwikkelaars toe zich te focussen op hun specifieke problemen. Ten tweede, deze architectuur maakt het ook mogelijk om QuickTime te laten werken met nieuwe randapparaten en dataformaten. Ten derde, door de media handler interface te documenteren kunnen ontwikkelaars hun eigen gespecialiseerde media handlers schrijven die met QuickTime werken.

55

Veel taken die door een media handler moeten uitgevoerd worden zijn gemeenschappelijk voor alle media handler componenten. Het onderhouden van de connectie met de data handler, moviedata ophalen en opslaan,. . . vormen een aanzienlijk onderdeel van het takenpakket van een media handler. Vaak zullen media handlers enkel van elkaar verschillen door de manier waarop ze mediadata verwerken. Daarom kunnen ontwerpers van nieuwe media handler componenten indien gewenst gebruik maken van een basis media handler. Deze basis media handler zal zorgen voor de interactie tussen de Movie Toolbox en de gepaste data handler, zodat de eigen media handler zich volledig kan concentreren op de verwerking van de media samples. Wanneer een zelfgeschreven media handler gebouwd wordt bovenop de basis media handler, noemt men dit een afgeleide media handler. De tekst media handler van Apple is gebouwd bovenop een basis media handler, dit in tegenstelling tot de video en audio media handler. Laat ons ter illustratie kijken naar de werking van een video media handler. Deze zal verantwoordelijk zijn voor het interpreteren van videodata. Concreet betekent dit dat de video media handler op geregelde tijdstippen processortijd zal krijgen van de Movie Toolbox voor het verwerken van video samples. Indien er bijvoorbeeld 24 frames per seconde moeten afgespeeld worden, dan zal de Movie Toolbox de video media handler 24 maal per seconde oproepen zodat deze de nodige samples kan ophalen, decomprimeren en naar het scherm kan wegschrijven. Hierbij zal er typisch gebruik gemaakt worden van de functionaliteit van een data handler, de Image Compression Manager en QuickDraw. De Image Compression Manager (ICM) zal verantwoordelijk zijn voor het bepalen of de videodata al dan niet gecomprimeerd werd. Indien de ICM na analyse van de metadata, opgeslagen bij de mediadata, vaststelt dat er sprake is van compressie, zal deze de gepaste decompressiecomponent aanspreken. Merk op dat de video media handler slechts een beperkte hoeveelheid rekentijd toegewezen krijgt. Indien deze limiet overschreden wordt, zal dit resulteren in een kleiner aantal oproepen waardoor bepaalde frames niet meer zullen getekend worden.

4.3.5

Video-effecten

QuickTime bevat ondersteuning voor de 133 video-effecten zoals die gedefinieerd werden door de Society of Motion Picture and Television Engineers. Daarenboven voegt QuickTime hieraan nog 24 extra effecten aan toe. Video-effecten worden ge¨ımplementeerd als componenten, het standaardmechanisme dat gebruikt wordt om QuickTime uit te breiden. Hierbij biedt QuickTime ondersteuning aan voor drie types video-effecten: • Genererende effecten, ook wel eens zero-source effecten genoemd, werken onafhankelijk van videobeelden. Daarmee wordt bedoeld dat voor de berekening van het effect geen input nodig is van een videobeeld. Het betreffende effect wordt gewoon over het videobeeld geprojecteerd. Voorbeelden van genererende effecten zijn vlammen of rimpelend water.

56

• Filtereffecten, ook wel eens one-source effecten genoemd, nemen als input een videobeeld en veranderen dan de manier waarop dit beeld aan de gebruiker vertoond wordt. Een voorbeeld van een dergelijk effect is het filmruiseffect. Dit is een effect dat door Apple zelf ontwikkeld werd en dat ook kan gebruikt worden via Atomic Player. • Transitie-effecten, ook wel eens two-source effecten genoemd, nemen als input twee videobeelden en zorgen ervoor dat er een vloeiende overgang mogelijk gemaakt wordt tussen deze twee beelden. Om een video-effect component te kunnen gebruiken in QuickTime, moet er een effectspoor aan de movie toegevoegd worden. De grootte en de duur van deze track bepalen het gebied van de movie dat door de track gemanipuleerd wordt en eveneens hoe lang het effect duurt. Het effectspoor heeft twee belangrijke attributen: een beschrijving van het effect en de input map. De beschrijving van het effect is een sample dat toegevoegd wordt aan de mediacontainer van het effectspoor en dat toelaat om het gewenste effect te selecteren uit een lijst van gegeven effecten. Verder zal de beschrijving ook bestaan uit een aantal waarden voor de parameters die het effect beschrijven. Zo wordt het filmruiseffect gedefinieerd aan de hand van acht parameters, zoals het aantal krassen dat per seconde moet getoond worden, de grootte van de krassen, enzoverder. Het tweede attribuut, zijnde de input map, beschrijft de tracks die als input dienen voor het effectspoor, meer bepaald bevat de input map het type van de bronsporen (video, tekst,. . . ), en een middel om deze tracks op een unieke manier te kunnen identificeren. Dit gebeurt door voor ieder bronspoor een trackreferentie toe te voegen aan het effectspoor. Deze trackreferentie bevat de ID van het bronspoor en het is naar deze trackreferentie dat er op z’n beurt een verwijzing is opgenomen in de input map. Via de input map zal het effectspoor dus weten van welke sporen het visuele data moet onderscheppen. Men spreekt van een pull operatie. Trackreferenties laten toe een relatie te defini¨eren tussen de verschillende sporen van een movie. Het QuickTime trackreferentiemechanisme ondersteunt veel-naar-veel relaties. Dit is, eender welke movietrack kan ´e´en of meerdere trackreferenties bezitten, en een track kan op zijn beurt gerelateerd zijn met meerdere tracks in de movie. Trackreferenties worden bijvoorbeeld ook gebruikt bij chapter lists om een passief tekstspoor te associ¨eren met een videospoor. Effectcomponenten gebruiken volledige sporen als input. Indien dit niet gewenst is, kan het soms nodig zijn om nog bijkomende tracks te cre¨eren. Merk op dat de bronsporen die door een effectspoor gebruikt worden ook wel eens modifier tracks genoemd worden omdat de media handlers van deze tracks verplicht worden hun data door te sturen naar de media handler van een andere track. Dus, een modifier track zal niet zelf instaan voor het presenteren van z’n data.

57

Originele movie Track A

Track B

Verkorte movie met transitie-effect Track A

Nieuwe offset voor track B Track B

Figuur 4.4: Een transitie-effect kan een movie verkorten. Het uitvoeren van een effect gebeurt tijdens het afspelen van een movie. QuickTime zal hierbij proberen zoveel mogelijk frames per seconde te genereren, zodat het effect zo vloeiend mogelijk wordt uitgevoerd, naargelang de kracht van de CPU en het vermogen van de schermkaart van de doelmachine. Het is ook mogelijk om effecten als het ware op te stapelen, door een effectspoor als input op te geven voor een ander effectspoor. Het opstapelen van effecten zal echter zware eisen opleggen aan de rekenkracht van het computersysteem van de gebruiker. Het feit dat effecten vaak veel rekenkracht vergen, is ook de reden waarom QuickTime maar in heel beperkte mate ondersteuning biedt voor geluidseffecten. Bij video-effecten is het niet zo erg wanneer bepaalde frames wegvallen om op die manier de synchronisatie te kunnen behouden. Meestal is dit zelfs niet zichtbaar voor het menselijk oog. Het weglaten van audiosamples heeft echter wel een ingrijpende invloed op de gebruikerservaring. Het menselijk waarnemingsvermogen is immers gevoeliger voor storingen op auditief vlak dan op visueel vlak. Merk ook op dat bij het aanwenden van een effect dat gebruik maakt van twee bronnen, enige voorzichtigheid geboden is. Het is namelijk mogelijk dat dit de duur van de presentatie van de visuele data kan verkorten of vergroten, naargelang er al dan niet sprake is van overlap. Dit kan er voor zorgen dat er problemen optreden bij het synchroniseren van visuele data met (continue) audiodata. Bij het editeren van een movie moet hiermee rekening gehouden worden. Dergelijke problemen kunnen bijvoorbeeld opgelost worden door te spelen met de duur van de frames die betrokken zijn bij de overgang van de ene bron naar de andere.

4.4

Praktisch voorbeeld

Bij het maken van deze thesis heb ik o.a. een import- en exportcomponent geschreven. Deze componenten laten toe om XML-data ([Bra00]) uit te wisselen met een QuickTime movie. De XML-data stelt in feite metadata voor die bepaalde frames uit een QuickTime movie beschrijft. Dit kan heel nuttig zijn om geavanceerde zoekbewerkingen mogelijk te maken in het kader van MPEG-7 ([Mar02]) en MPEG-21 ([Bor01]). Omdat het in mijn scriptie niet de bedoeling was dieper in te gaan op dergelijke geavanceerde technieken,

58

werd de beschrijving van een frame heel eenvoudig gehouden en zal deze bijvoorbeeld bestaan uit het begintijdstip van het frame, de duur van het frame,. . . Het schrijven van eigen componenten voor het importeren en exporteren van XMLdata vergde veel werk maar het leverde wel een goed inzicht op in de werking van QuickTime. De zelfontwikkelde data exchange componenten bieden trouwens ook een veel grotere flexibiliteit aan dan de andere mogelijkheden waarover QuickTime beschikt voor het werken met XML-data. De metadata kon immers ook via een teksttrack of via de gebruikersdata toegevoegd worden aan een QuickTime movie. Deze mogelijkheden werden echter niet benut en dit omwille van de hieronder opgesomde redenen. Het grote nadeel van een teksttrack is dat deze een restrictie oplegt aan de waarden van de bytes die karakters voorstellen. Het is namelijk zo dat deze waarden in een bepaald bereik moeten liggen waardoor XML-data enkel onder de vorm van klare tekst aan een QuickTime movie kan toegevoegd worden. Hierdoor is compressie van de data in een later stadium al uitgesloten. Door het opsplitsen van een byte in twee nibbles, en door deze laatste terug uit te breiden tot 2 bytes waarvan de waarde behoort tot het vereiste interval, is dit probleem wel op te lossen maar het is vrij omslachtig. Het toevoegen van XML-data aan de gebruikersdata zal weliswaar geen problemen opleveren qua bytewaarden, maar toch is het ook niet ideaal voor het opslaan van grote hoeveelheden XML-data. Immers, men is dan als ontwerper zelf verantwoordelijk voor de structuring van de data wat bij het gebruik van eigen import- en exportcomponenten kan overgelaten worden aan QuickTime. Bovendien zorgt dit ook voor een meer orthogonale aanpak aangezien er via de zelfgeschreven data exchange componenten expliciet gebruik gemaakt wordt van de mogelijkheden die QuickTime op dit vlak aanbiedt. Ook de ontwikkeling van code voor het stromen van deze XML-data, samen met het ontwerpen van de bijhorende controlemiddelen, zou via deze aanpak vlotter moeten verlopen. Concreet kan mijn importer de volgende zaken. De component is in staat om de inhoud van een XML-document in te lezen en als een sample toe te voegen aan een QuickTime movie. In dat geval zal de importcomponent ook automatisch op zoek gaan naar een bijhorend XSL-document ([W3Ca]) en indien dit aanwezig is, zal de inhoud daarvan als een tweede sample aan de betreffende track toegevoegd worden. De importcomponent kan echter eveneens data vanuit een handle of geheugenbuffer importeren in een QuickTime movie. Het is deze laatste techniek die gebruikt wordt om de beschrijvende XML samples toe te voegen aan een spoor, en dit op een zodanige manier dat deze samples in de tijd gealigneerd zijn met de videosamples die ze beschrijven (cfr. figuur 2.4). De exportcomponent voert de duale handelingen uit. Via de eigen import- en exportcomponenten laten we QuickTime dus kennis maken met een vreemd dataformaat, of beter gezegd, we voegen een eigen mediatype aan QuickTime toe. Om dit mediatype, dat ik de vierkaraktercode ’XMLT’1 heb toegekend, te kunnen registreren bij QuickTime, moeten we echter een bijkomende component schrijven. Deze 1

Vierkaraktercodes die enkel bestaan uit kleine letters zijn door Apple gereserveerd.

59

zal eveneens verantwoordelijk zijn voor de verwerking en interpretatie van XMLT-data. Merk op dat ’XMLT’ ook het type is van de track waarin de verwijzingen bewaard worden naar de verschillende XML samples. Wat betreft de verwerking en interpretatie van de XML samples zijn we aangekomen op het domein van media handlers. Hierbij heb ik gebruik gemaakt van de basis media handler, zodat mijn media handler een afgeleide media handler is. In feite heb ik het inlezen, wegschrijven en cachen van XML samples volledig kunnen overlaten aan de basis media handler, die in functie van mijn component zal onderhandelen met de data handler. Blijft dus nog over de verwerking of het afspelen van de XML-data. Atomic Player

Movie Toolbox

Video Media Handler

Basis Media Handler

Afgeleide XMLT Media Handler

Data Handler

Figuur 4.5: Logische relatie tussen de Movie Toolbox en verschillende media handlers. Zoals reeds gezegd zijn de XML samples gealigneerd met de videoframes die ze beschrijven. Voor de eenvoud, en ook ter controle, is er voor elk videosample een corresponderend XML sample toegevoegd aan een XMLT-track. Dit is echter geen vereiste; het resultaat zou hetzelfde zijn moesten XML samples ad random aan de track toegevoegd worden via de XMLT import component. Nu, het gealigneerd zijn houdt in dat, wanneer er 24 frames per seconde afgespeeld worden, de XMLT media handler eveneens 24 maal per seconde opgeroepen wordt door de Movie Toolbox om werk uit te voeren, volledig in analogie met de video media handler. Met andere woorden, de XML samples worden synchroon verwerkt met video samples. Omdat ik geen programma schrijf in het kader van MPEG-7 of MPEG-21, heb ik de analyse van de XML mediasamples vrij eenvoudig kunnen houden. Er wordt geen compressie of decompressie uitgevoerd, net zomin als dat de XML samples op hun geldigheid worden gecontroleerd. Hetgeen wat er gebeurt is in feite vrij verwant met hetgeen

60

wat door de eigen exportcomponent uitgevoerd wordt. Daar waar de exportcomponent in ´e´en vloeiende lus de XML samples kan inlezen uit een QuickTime movie en vervolgens kan wegschrijven naar een XML-document, gebeurt dit bij de XMLT media handler op een geleidelijke manier, namelijk aan een snelheid gelijk aan de beeldsnelheid van de corresponderende videotrack. Hieronder ziet u de output die door de XMLT media handler gegenereerd wordt in het geval van een movie met 5 frames. Bemerk dat de media handler aan de opgehaalde XML samples nog een tijdsindicatie toevoegt. Dit tijdstip is het moment waarop het sample wordt weggeschreven naar het bestand. Tussen de beschrijving van het eerste en het tweede frame zit een vertraging van ongeveer 2 seconden. Dit heeft te maken met het volgende. Bij het openen van een moviebestand wordt de movie of de metadata eerst in het geheugen geladen. Vervolgens zal QuickTime deze metadata doorzoeken zodat het zo snel mogelijk connecties kan openen naar de gepaste componenten, waarbij uiteraard ook nog ander werk verricht wordt. In het geval van een videotrack zal er bijvoorbeeld een verbinding opgezet worden naar een gepaste video media handler zodat deze reeds een eerste beeld aan de gebruiker kan tonen, zonder dat daarom de movie reeds moet afgespeeld worden. Hetzelfde wordt uitgevoerd met de XMLT media handler. QuickTime detecteert een XMLT-track en vraagt vervolgens aan de CM om een connectie te openen naar een XMLT media handler, wat zonder problemen kan indien deze component bij de CM geregistreerd werd. Eenmaal de verbinding opgezet geeft QuickTime de opdracht tot het afspelen van een eerste XML sample, wat betekent dat een eerste XML-fragment naar een bestand wordt weggeschreven. Alle andere samples worden pas aan het bestand toegevoegd nadat de gebruiker op de afspeelknop heeft gedrukt. Wat deze samples betreft, kunnen we vaststellen dat deze ongeveer om de 40 milliseconden worden weggeschreven, wat min of meer correspondeert met het gebruikte tijdsinterval bij een snelheid van 24 fps. <XMLDOC> Generated by Atomic Player Tue Apr 09 16:50:10.717 2002 0 25 Tue Apr 09 16:50:12.850 2002 25 25

61

Tue Apr 09 16:50:12.890 2002 50 25 Tue Apr 09 16:50:12.940 2002 75 25 Tue Apr 09 16:50:12.980 2002 100 25 Tot slot wil ik nog vermelden dat ik in mijn uitleg over de XMLT-componenten nergens gesproken heb over het gebruik van movie- en mediatijd. Nochtans zal dit ook zeer belangrijk zijn want het is op basis van de organisatie van de samples in movietijd dat de Movie Toolbox bepaalt wanneer een media handler opgeroepen wordt, en het is op basis van de organisatie van de samples in mediatijd dat de media handler in staat zal zijn om samples te lokaliseren in een mediacontainer2 . De introductie van movie- en mediatijd in mijn componenten hangt echter nauw samen met de precieze werking van een basis media handler en een data handler. Die komen echter pas aan bod in het volgende hoofdstuk over het QuickTime bestandsformaat. Vandaar dat ik pas op het einde van dat hoofdstuk (zie paragraaf 5.5) de uitleg over de zelfontwikkelde componenten zal verderzetten. Meer bepaald zal ik dan hun precieze werking beschrijven aan de hand van pseudocode.

2

Hierbij laat ik voor de eenvoud de edit list buiten beschouwing. Deze regelt o.a. het hergebruik van mediasamples en dit hergebruik impliceert dat het voor de mediahandler moeilijker zal zijn om samples te lokaliseren in een mediacontainer.

62

Hoofdstuk 5 Het QuickTime Bestandsformaat Dit hoofdstuk beschrijft hoe een movie en bijhorende moviedata, zoals bijvoorbeeld key frames en delta frames die na digitalisatie en compressie van analoge videodata ontstaan zijn, door QuickTime op schijf bewaard worden. Het QuickTime bestandsformaat kan gebruikt worden om bijna eender welke mediastructuur te beschrijven waardoor het een effici¨ent formaat is om digitale media uit te wisselen tussen applicaties, en dit onafhankelijk van het platform waarop deze toepassingen werkzaam zijn. Het QuickTime bestandsformaat is in feite een logische voortzetting van de idee¨en die schuil gaan achter het Macintosh bestandssysteem.

5.1

Atomen

Een QuickTime bestand slaat de beschrijving van de media gescheiden op van de eigenlijke mediadata. Zoals we reeds gezien hebben, wordt de beschrijving of metadata de movie genoemd en bevat deze informatie over het aantal tracks, het videocompressieformaat,. . . De movie beschikt eveneens over een index die aangeeft waar alle mediadata is opgeslagen. Deze data kan bewaard worden in hetzelfde bestand als de movie, in een apart bestand, of zelfs in verschillende bestanden. Vooraleer uit te leggen hoe een QuickTime movie op schijf wordt opgeslagen, is het belangrijk om eerst te begijpen wat de basiseenheden zijn die gebruikt worden om QuickTime bestanden te construeren. QuickTime maakt gebruik van twee basisstructuren voor het opslaan van informatie: klassieke atomen en QT atomen. Zowel klassieke atomen, ook wel eens eenvoudige atomen genoemd, als QT atomen laten toe om willeurig complexe, hi¨erarchische datastructuren op te bouwen. Beide types atomen geven aan applicaties eveneens de mogelijkheid om data te negeren die ze niet verstaan.

63

5.1.1

Klassieke atomen

De basiseenheid voor het opslaan van informatie in een QuickTime bestand is dus het atoom, een objectge¨ori¨enteerde datastructuur. Een klassiek atoom bevat, naast data, ook twee velden die het type en de grootte van het atoom aangeven. Deze velden vormen samen de hoofding van het atoom. De grootte van een atoom wordt uitgedrukt in bytes, en wordt opgeslagen als een 32-bits integer in de header. De grootte omvat zowel de data als de hoofding van het atoom. Het typeveld specificeert het type van de data die in het atoom opgeslagen wordt, en dus eveneens het dataformaat. Atoomtypes worden net zoals atoomgroottes opgeslagen als 32-bits integers. Deze gehele getallen worden normaal gezien ge¨ınterpreteerd als vierkaraktercodes. Tenzij anders afgesproken, wordt alle data in een QuickTime atoom opgeslagen in big-endian bytevolgorde. Atomen hebben een sterk hi¨erarchische natuur. Dit betekent dat atomen ´e´en of meerdere andere atomen kunnen bevatten, al dan niet van hetzelfde type. Bijvoorbeeld, een movie-atoom bevat een trackatoom voor iedere track die in de movie voorkomt. De trackatomen bevatten op hun beurt een aantal andere atomen. Een atoom dat andere atomen bevat, noemt men een containeratoom. Indien dit niet het geval is, spreekt men van een bladatoom. Bladatomen bevatten enkel data, vaak onder de vorm van tabellen. In de meeste gevallen speelt de volgorde waarin atomen voorkomen in een atoomcontainer geen rol. Merk ook op dat het correct interpreteren van de data die opgeslagen is in een atoom, niet alleen afhangt van het typeveld van dat atoom. Het gebruik van een atoom wordt ook bepaald door z’n context. Een gegeven atoomtype kan voor verschillende doeleinden gebruikt worden, en dit naargelang het type van het atoom waarin het opgeslagen werd (cfr. de media handler reference atomen en de gebruikersdata-atomen). Atoomcontainer Atoomgrootte [4] Atoomtype [4] Atoomcontainer Atoomgrootte Atoomtype Bladatoom Atoomgrootte Atoomtype Atoomdata

…

Figuur 5.1: Een voorbeeld van een hi¨erarchie van klassieke atomen.

64

5.1.2

QT atomen

Klassieke atomen hebben een aantal limieten, zoals het feit dat men gebruik moet maken van offsets om doorheen een boom van atomen te navigeren. Daarom cre¨eerde Apple QT atomen. Deze atomen zijn een verbetering van klassieke atomen en zullen een aantal dubbelzinnigheden elimineren. Zo is het met eenvoudige atomen niet mogelijk om te weten of een bepaald atoom andere atomen bevat of enkel data, zonder specifieke kennis over het betreffende atoom. Bij QT atomen is dit zeer eenvoudig te bepalen via het headerveld Child Count. Verder zullen QT atomen ook toelaten om op een meer intelligente manier doorheen een hi¨erarchie van atomen te bewegen. Zo bestaan er in de QuickTime API voorzieningen die het mogelijk maken om bijvoorbeeld van alle kinderen van een ouderatoom het tweede kindatoom op te vragen van een gegeven type. Het feit dat QT atomen krachtiger datastructuren zijn, vergt wel een grotere overhead; de hoofding van een QT atoom is 20 bytes groot terwijl deze van een klassiek atoom maar 8 bytes in beslag neemt. QT Atom Container Header Reserved [10] Lock count [2] QT Atom Header Size [4] Type [4] Atom ID [4] Reserved [2] Child Count [2] Reserved [4] Leaf Atom Size Type Atom Data Leaf Atom Size Type Atom Data

Figuur 5.2: Een voorbeeld van een QT atoom dat twee klassieke atomen bevat. Het QT atoom maakt op zijn beurt deel uit van een QT atoomcontainer. Het veld Lock Count dient om de container in het geheugen te vergrendelen. Op die manier is het mogelijk om rechtstreeks op de data in te werken, en niet op een kopie.

Het QuickTime bestandsformaat maakt zowel gebruik van klassieke atomen als QT atomen. Apple raadt wel aan om QT atomen te gebruiken indien een applicatie nieuwe datastructuren definieert.

65

5.1.3

QT atoomcontainers

Een QT atoomcontainer is een boomvormige hi¨erarchie van QT atomen, waarbij een nieuwe QT atoomcontainer te vergelijken is met de wortel van een boomstructuur die geen kinderen bevat. Een QT atoomcontainer bevat QT atomen, zoals getoond in figuur 5.2. Ieder QT atoom bevat ofwel data, ofwel andere atomen. Indien een QT atoom andere atomen bevat, is het een ouderatoom en de atomen die het bevat zijn de kindatomen. Ieder kind van een ouder wordt op een unieke manier ge¨ıdentificeerd door middel van het atoomtype en een atoom ID. Een QT atoom dat enkel data bevat, noemt men een bladatoom. Bemerk dat een QT atoomcontainer, naast een eigen hoofding met 2 datavelden, ook steeds een root QT atoom bevat (zie figuur 5.2). Dit root QT atoom heeft het type ’sean’ en heeft geen siblings (broers of zussen). Ieder QT atoom heeft een offset die de positie van het atoom beschrijft binnen de atoomcontainer. Bovendien heeft elk atoom een type en een ID. Het atoomtype specificeert het type van de data die in het atoom opgeslagen ligt. Het atoom ID wordt gebruikt om een onderscheid te kunnen maken tussen kinderen van hetzelfe type met dezelfde ouder; een atoom ID is dus uniek voor een gegeven ouder en een gegeven type. Bovendien heeft ieder atoom ook nog een index die de relatieve volgorde beschrijft van het atoom t.o.v. de andere kindatomen van dezelfde ouder met hetzelfde atoomtype. Indexwaarden starten vanaf ´e´en en vormen in feite een rangnummer1 . Zo is het mogelijk om een QT atoom op een unieke wijze te identificeren via ´e´en van de volgende manieren: • door de offset binnen de QT atoomcontainer • door het ouderatoom, type, en index • door het ouderatoom, type, en ID Het is dus mogelijk om atomen, binnen een atoomcontainer, op te slaan of in te lezen via index, ID, of beide. Bijvoorbeeld, om een QT atoomcontainer als een dynamische array of als een boomstructuur aan te wenden, kan er gebruik gemaakt worden van indices. Om een QT atoomcontainer als een databank te gebruiken, kan er gesteund worden op de ID waarden. Het is ook mogelijk om zowel gebruik te maken van indices en ID waarden om een willekeurig complexe datastructuur te construeren. Merk op dat het niet nodig is om zelf QT atomen te parsen, in tegenstelling tot klassieke atomen. Daartoe kan er gebruik gemaakt worden van functies uit de QuickTime API. Vaak worden willekeurig diep geneste structuren van QT atomen gebruikt om informatie uit te wisselen tussen verschillende processen. Men kan hierbij denken aan parameters die ingelezen worden via een dialoogvenster en die vervolgens opgeslagen worden in een atoomcontainer. De betreffende container kan dan doorgegeven worden aan een functie die instaat voor de verwerking van de ingelezen gegevens (cfr. het inlezen van de parameters van een videoeffect via een dialoogvenster). 1

Bemerk de gelijkenis met een trackindex en een track ID.

66

QT atom container Index= 2 Offset= 20

Index= 1 Offset= 10

’abcd’

’abcd’

900

1000 Data

Index= 1 Offset= 30

Index= 1 Offset= 40

Index= 2 Offset= 50

’abcd’

’word’

’abcd’

100

100

1000

"Hello"

Figuur 5.3: Een uitgewerkt voorbeeld van een QT atoomcontainer met twee kindatomen. Bemerk dat de container offsets niet corresponderen met re¨ele waarden. Zo zou het eerste kind offset 32 - hoofding atoomcontainer (12) + hoofding root QT atoom (20) - moeten hebben i.p.v. offset 10. Let eveneens op de uitgesproken boomstructuur.

Figuur 5.3 toont een atoomcontainer die twee kindatomen bevat. Het eerste kind (offset = 10) is een bladatoom en heeft als atoomtype ’abcd’, een ID met waarde 1000, en een index 1. Het tweede kindatoom (offset = 20) heeft ook als atoomtype ’abcd’, een ID 900, en een index 2. Omdat de twee kindatomen beiden hetzelfde type hebben, moeten ze verschillende IDs hebben. Het tweede kindatoom is ouder van 3 atomen. Het eerste kindatoom (offset = 30) heeft een atoomtype ’abcd’, een ID 100, en een indexwaarde 1. Het heeft geen kinderen, net zomin als het data heeft. Het tweede kindatoom (offset = 40) heeft een atoomtype ’word’, een ID 100, en een index 1. Het atoom bevat data, dus is het een bladatoom. Het tweede atoom (offset = 40) heeft dezelfde ID als het eerste atoom (offset = 30), maar een verschillend atoomtype. Het derde kindatoom (offset = 50) heeft als atoomtype ’abcd’, een ID met waarde 1000, en een index 2. Het atoomtype en ID zijn dezelfde als van het atoom met offset 10 maar ze hebben verschillende ouders.

5.2

De structuur van een QuickTime bestand

Een QuickTime bestand kan dus beschouwd worden als een collectie atomen. QuickTime legt hierbij vaak geen restricties op aan de volgorde waarin bepaalde atomen voorkomen. Onderstaande lijst toont schematisch de atoomstructuur van een typisch QuickTime bestand. Hieruit kunnen we een duidelijk hi¨erarchische structuur afleiden met zes niveaus, van links naar rechts. Merk ook op dat men er voor de eenvoud mag van uitgaan dat alle hier opgesomde atomen, klassieke atomen zijn. Het grootste deel van deze atomen

67

was immers al gedefinieerd vooraleer QT atomen op de proppen kwamen. Deze laatste worden bijvoorbeeld wel gebruikt bij de beschrijving van een video-effect omdat effecten pas veel later aan de QuickTime bibliotheek werden toegevoegd. Een insprong onder een element in de lijst betekent dat het betreffende atoom een containeratoom is. ’moov’

Movie Atom

’mvhd’

Movie Header Atom (cfr. figuur 2.1)

’trak’

Track Atom ’tkhd’

Track Header Atom (cfr. figuur 2.2)

’edts’

Edit Atom ’elst’

Edit List Atom

’mdia’

Media Atom

’mdhd’

Media Header Atom (cfr. figuur 2.3)

’hdlr’

Media Handler Reference Atom

’minf’

Media Information Atom

’vmhd’

Video Media Info Atom

’hdlr’

Media Handler Reference Atom

’dinf’

Data Info Atom ’dref’

Data Reference Atom

’stbl’

Sample Table Atom ’stsd’

Sample Description Atom

’stts’

Time-to-sample Atom

’stss’

Sync Sample Atom

’stsc’

Sample-to-chunk Atom

’stsz’

Sample Size Atom

’stco’

Chunk Offset Atom

’udta’

User Data Atom

’trak’

Track Atom

’udta’

User Data Atom

’name’ c ’ inf’

Name

c ’ cpy’ c ’ cmt’

Copyright statement

’WLOC’

Default Window Location

Information about the movie Comment

’free’

Free Atom

’wide’

Wide Atom

68

’mdat’

Media Data Atom

Op het hoogste niveau zien we het movie-atoom, dat de metadata bevat, en het mediadata-atoom, dat als payload de mediasamples bevat. De metadata wordt heel duidelijk gestructureerd aan de hand van atomen. Het movie-atoom is een containeratoom terwijl het mediadata-atoom een bladatoom is. Alhoewel QuickTime geen stricte atoomvolgorde oplegt, is het soms toch interessant om het movie-atoom vooraan het bestand te plaatsen. Dit zal namelijk aan een applicatie de mogelijkheid geven een movie reeds af te spelen naarmate deze over het netwerk gedownload wordt. Het vooraan plaatsen van de movie kan echter ook nadelig zijn. Stel dat er een aantal editeerbewerkingen worden uitgevoerd waardoor de movie in omvang toeneemt. Dan moet alle mediadata in het bestand verplaatst worden, wat vaak veel tijd in beslag neemt. Wanneer de movie achteraan geplaatst wordt, zullen dergelijke problemen niet optreden maar progressief downloaden is in dat geval uit den boze. Om deze problemen op te lossen, heeft QuickTime het ’free’ atoom ge¨ıntroduceerd. Dit atoom maakt het mogelijk om een movie-atoom vooraan het bestand te plaatsen zonder dat bij editeerbewerkingen telkens alle mediadata moet verplaatst worden en alle interne tabellen moeten aangepast worden. Het enige wat dit atoom doet is een zekere hoeveelheid plaats reserveren voor het movie-atoom in het QuickTime bestand. Op die manier mag de grootte van de movie toch nog in enige mate vari¨eren. Grootte

Grootte

Grootte

Grootte

Grootte = 1

Grootte = 0

Type

Type

Type

Uitgebreide grootte (indien grootte = 1)

Einde bestand

Figuur 5.4: Berekenen van atoomgroottes. Het ’wide’ atoom heeft een analoge taak als het ’free’ atoom, zij het dat dit atoom 8 bytes reserveert voor het mediadata-atoom. Dit is nuttig wanneer de grootte van de mediadata de grens van 4 gigabyte overschrijdt. In dat geval wordt het ’wide’ atoom overschreven met de oude hoofding van het mediadata-atoom en wordt van deze oude hoofding een 64-bits dataveld gemaakt dat de nieuwe lengte van het ’mdat’ atoom zal bevatten. Het 32-bits grootteveld in het vroegere ’wide’ atoom krijgt de waarde 1. Op die manier weet QuickTime dat er een 64-bits dataveld aanwezig is dat de eigenlijke grootte

69

bevat. Wanneer het grootteveld trouwens de waarde 0 heeft, betekent dit dat de grootte van het atoom gelijk is aan het resterende aantal bytes in het QuickTime moviebestand. Dit wordt verduidelijkt aan de hand van figuur 5.4. Het movie header atoom is een bladatoom dat algemene informatie over een movie bevat, zoals de movietijdschaal, de duur, de voorkeurinstellingen voor het geluidsvolume en de afspeelsnelheid, de tijd en datum van creatie en laatste wijziging,. . . Op hetzelfde niveau zien we ook nog de eigenlijke bouwstenen van een movie, zijnde de trackatomen. E´en van deze containeratomen werd in de lijst uitgevouwd en toont informatie over een videospoor. Het andere trackatoom bevat gegevens over een audiotrack. Het trackatoom bestaat o.a. uit een track header atoom dat in analogie met het movie header atoom algemene informatie bevat over een spoor, zoals de afmetingen van de track, de track ID, de duur, het layer nummer, de datum en tijd van creatie en wijziging,. . . Eenzelfde taak is ook weggelegd voor het media header atoom. In dit bladatoom kan men informatie terugvinden over de mediatijdschaal, de mediaduur, de taal en kwaliteit van de mediasamples,. . . Verder zien we ook nog twee media handler reference atomen. Het media handler reference atoom dat als ouder het media atoom heeft, bevat een beschrijving van de video media handler die door QuickTime moet gebruikt worden voor de interpretatie van de videosamples in het mediadata-atoom. Figuur 5.5 toont de structuur van dit media handler reference atoom in het geval van een XMLT-spoor. Het andere media handler reference atoom, met als ouder het media information atoom, heeft als payload de beschrijving van een data handler.

B

4

Type: ‘hdlr’

4

Grootte: 59 bytes

1

Version: 0

3

Flags: 0

Y

4

Component Type: ‘mhlr’

T

4

Component Subtype: ‘XMLT’

4

Component Manufacturer: ‘WMDN’

4

Component Flags: $00 00 00 01

4

Component Flags Mask: $00 01 02 77

27

Component Name: “XMLT Handler Component”

E S

Header

Data

Figuur 5.5: Een media handler reference atoom. Alle atomen die nog niet besproken werden, behalve het video media info atoom, zullen toegelicht worden in de resterende paragrafen van dit hoofdstuk. Het video media info atoom bevat een beperkte hoeveelheid technische informatie voor QuickDraw en is niet zo belangrijk in het kader van deze thesis. Aanvullende informatie over het gebruik en de

70

betekenis van de verschillende atomen is eveneens terug te vinden in [Inc00]. Om deze paragraaf te besluiten, wil ik ook nog iets vermelden over de relatie tussen het MPEG-4 en QuickTime bestandsformaat, zonder MPEG-4 in detail bestudeerd te hebben. Het is namelijk zo dat de betreffende bestandsformaten dezelfde syntax hebben: (klassieke) atomen die (klassieke) atomen bevatten, enzoverder. De atomen die men terugvindt in het QuickTime bestandsformaat komen ook voor in het MPEG-4 bestandsformaat (’mdat’, ’moov’, ’mvhd’, ’trak’,. . . ), maar niet allemaal. Omgekeerd is het ook zo dat MPEG-4 een aantal atomen definieert die niet voorkomen in een QuickTime movie, zoals het Initial Object Descriptor atoom (’iods’) en het Elementary Stream Descriptor atoom (’esds’). MPEG-4 maakt eveneens gebruik van een aantal sporen (voor het beschrijven van objecten, scenes,. . . ) die niet door QuickTime gekend zijn. In feite kan men besluiten dat een MPEG-4 bestand geen QuickTime bestand is, en omgekeerd, ook al worden dezelfde codecs gebruikt. En, om even vooruit te lopen op het hoofdstuk over netwerkdiensten, het concept hinttrack is eveneens een begrip dat terug te vinden is in MPEG-4. Een hinttrack zal aan een streaming server vertellen hoe data moet gestroomd worden. Dit zal ervoor zorgen dat de te stromen data niet in een speciaal stromingsformaat moet opgeslagen worden in het bestand (alhoewel dit te bediscussi¨eren valt, cfr. het optimaliseren van een hintspoor). Omwille van de grote overeenkomsten tussen het MPEG-4 en QuickTime bestandsformaat moest men aan Apple’s streaming server vrij weinig veranderen om er eveneens een MPEG-4 streaming server van te maken.

5.3 5.3.1

Beveiliging Gebruikersdata

Gebruikersdata-atomen laten een ontwerper toe om data te associ¨eren met een bepaald QuickTime object, zoals een movie of een track. Dit omvat zowel informatie die door QuickTime gebruikt wordt, zoals gegevens over auteursrechten of indien een movie al dan niet in een lus moet afgespeeld worden, als informatie die door QuickTime genegeerd wordt. In het laatste geval kunnen we denken aan informatie die door een eigen applicatie gebruikt wordt. Merk op dat gebruikersdata zowel binair als tekstueel kan zijn. Een gebruikersdata-atoom dat als onmiddellijke ouder een movie-atoom heeft, bevat data die relevant is voor de movie in z’n geheel. Een gebruikersdata-atoom wiens ouder een trackatoom voorstelt, bevat data die enkel relevant is voor een specifiek spoor. Er is slechts ´e´en gebruikersdata-atoom toegestaan als rechtstreeks kind van een gegeven movieatoom of een gegeven trackatoom. Een gebruikersdata-atoom kan wel een onbeperkt aantal andere atomen bevatten, waarvan het type al dan niet door QuickTime gekend is. Het gebruikersdata-atoom, dat een voorbeeld is van een containeratoom, heeft een atoomtype ’udta’. In een gebruikersdata-atoom bevindt zich een lijst van atomen die

71

verschillende stukken gebruikersdata beschrijven. De atomen die tot deze lijst behoren, noemt men ook wel eens items. Gebruikersdata laat toe om op een eenvoudige manier extra informatie toe te voegen aan een QuickTime movie. Wanneer het type van een atoom, dat zich in een gebruikersdatalijst bevindt, begint met een copyright-symbool, dan betekent dit dat het betreffende atoom tekstuele data bevat.

5.3.2

Gebruikte technieken

Ontwikkelaars zullen het vaak noodzakelijk achten om data, die opgeslagen werd in moviebestanden, te beveiligen. Een dergelijke beveiliging kan gerealiseerd worden met behulp van paswoordprotectie of met behulp van een aantal andere schema’s. Dergelijke systemen kunnen een gebruiker de toegang ontzeggen tot de data die opgeslagen is in een movie of kunnen deze verhinderen om ongewenste wijzigingen aan te brengen in een movie. Wanneer er een no save user data item (type ’nsav’) toevoegd wordt aan de gebruikersdata van een movie, dan is het onmogelijk om wijzigingen, die aangebracht werden aan een movie in het geheugen, persistent te maken. Aan een dergelijke movie kan men bijvoorbeeld wel een filtereffect toevoegen, maar de Movie Toolbox zal helemaal niet toelaten om het bekomen resultaat te bewaren. Dit is al een interessante manier om aan dataprotectie te doen. Nochtans kan ze vrij eenvoudig omzeild worden met een tool als Atomic Browser (zie ook [Moj]), en dit in combinatie met een hexeditor. Met deze programma’s is het mogelijk om het ’nsav’ atoom op te sporen in het QuickTime moviebestand en het ’nsav’ type te veranderen in ’free’. Daarom zou deze beveiliging enkel moeten beschouwd worden als een soort van intentieverklaring aan de gebruiker. Merk op dat het omzeilen van het ’nsav’ atoom bemoeilijkt kan worden door de movie te comprimeren, en uiteraard ook door de movie en bijhorende mediadata te encrypteren maar daarover later meer. We hebben reeds gezien dat de meeste QuickTime movies bestaan uit metadata en mediadata. Mediadata kan gecomprimeerd worden met een ganse waaier aan video- en audiocompressietechnieken. Het is echter ook mogelijk om de movie resource te comprimeren. Hierbij mag men geen gebruik maken van verlieshebbende compressiemethodes, aangezien de movie kritische informatie bevat die niet verloren mag gaan. Een gecomprimeerde movie resource is, net zoals een gewone movie resource, opgebouwd uit een aantal QuickTime atomen, hi¨erarchisch geordend. Het buitenste atoom is een movie-atoom (’moov’). Dit movie-atoom bestaat uit ´e´en kindatoom (’cmov’), het gecomprimeerde movie-atoom, dat op zijn beurt terug 2 kindatomen heeft: het atoom dat alle gecomprimeerde metadata bevat (’cmvd’), en een atoom dat een 32-bits integer als payload heeft (’dcom’). Dit geheel getal zal het algoritme identificeren dat voor decompressie moet gebruikt worden (de Apple data compressor of de zlib data compressor). Merk op dat de gecomprimeerde metadata in het ’cmvd’ atoom voorafgegaan wordt door een 32-bits integer die de grootte in bytes zal aangeven van de ongecomprimeerde movie resource. Wanneer een zeer goede beveiliging vereist is van een moviebestand, kan er in QuickTime gebruik gemaakt worden van toegangssleutels (access keys). Deze zullen aan een

72

applicatie de mogelijkheid bieden om een paswoord te registreren bij QuickTime. Dit paswoord moet door een gebruiker ingegeven worden wanneer deze toegang wil krijgen tot de data. Bijvoorbeeld, een codec (Intel Indeo, Sorenson Video 3) kan data, die het moet comprimeren, encrypteren met behulp van een paswoord. Op die manier is de data enkel beschikbaar voor personen die kennis hebben van het betreffende paswoord. Wanneer een gebruiker een movie wil bekijken, moet deze het correcte paswoord opgeven opdat de decryptie juist zou uitgevoerd worden.

5.4

Referentie movies en clientnegotiatie

Een QuickTime movie kan dienst doen als een container voor een verzameling van alternatieve movies die slechts mogen vertoond worden wanneer aan bepaalde voorwaarden voldaan is. E´en van deze movies zal soms opgeslagen worden als een standaardmovie in hetzelfde bestand; de andere movies worden dan ge¨ıdentificeerd m.b.v. een referentie. Bijvoorbeeld, een QuickTime movie kan een lijst van referenties bevatten naar movies die elk gekenmerkt worden door een verschillende datasnelheid. Dit maakt het voor een applicatie mogelijk er die movie uit te halen die het best kan afgespeeld wanneer deze progressief gedownload wordt over het Internet. Hierbij zal de toepassing zich bij het maken van een keuze laten inspireren door de snelheid van de netwerkverbinding van de gebruiker. Een movie die referenties bevat naar alternatieve movies, noemt men een reference movie. Een referentie movie bevat steeds een reference movie atoom (’rmra’). Dit atoom is een kind van het movie-atoom. Dit movie-atoom kan o.a. ook nog een movie header atoom bevatten, horende bij de standaardmovie; dit is echter geen vereiste. Het reference movieatoom bevat ´e´en of meerdere movie descriptor atomen (’rmda’). Elk van deze atomen zal een alternatieve movie beschrijven en zal ook een data reference atoom bevatten. Dit laatste zal informatie leveren over de locatie van een movie. Movie locaties worden gespecificeerd door gebruik te maken van QuickTime datareferenties. QuickTime ondersteunt meerdere types datareferenties, maar alternatieve movies worden meestal ge¨ıdentificeerd door middel van een URL (’url ’) of door middel van een bestandsalias (’alis’). Een bestandsalias is de naam die onder MacOS gebruikt wordt om bestandsobjecten te typeren (een volume, een directory, een bestand). Dit verschilt van een bestandsspecificatie zoals die onder Windows gebruikt wordt. QuickTime zal waar mogelijk zelf de nodige conversies uitvoeren. Soms moet dit ook manueel gebeuren en in dat geval kan men gebruik maken van functies uit de QuickTime API. Merk op dat naargelang het type datareferentie er een andere data handler zal gebruikt worden. Zo is er sprake van een URL data handler - die http://, ftp://, rtsp://, file:// en icy:// kent en een alias data handler. Merk op dat een URL zowel relatief als absoluut kan zijn en dat deze opgeslagen wordt als een C-string, dus niet als een Pascal-string.

73

Movie Atoom Atoomgrootte Atoomtype (‘moov’) Reference Movie Atoom Atoomgrootte Atoomtype (‘rmra’) Reference Movie Descriptor Atoom Atoomgrootte Atoomtype (‘rmda’) Data Reference Atoom (‘rdrf’) Data Rate Atoom (‘rmdr’) CPU Speed Atoom (‘rmcs’) Version Check Atoom (‘rmvc’) Component Detect Atoom (‘rmcd’) Quality Atoom (‘rmqu’)

Figuur 5.6: Het reference movie atoom. Een reference movie descriptor atom zal doorgaans ook atomen bevatten die de systeemvereisten en de kwaliteit zullen beschrijven van een movie. Indien dit het geval is, zal er voor iedere vereiste een atoom van het gepaste type aanwezig zijn, en eventueel ook nog een quality atoom. Applicaties moeten altijd die movie afspelen die de hoogste kwaliteit biedt en die aan de gestelde eisen voldoet. Indien de datareferentie voor de geselecteerde movie niet kan opgelost worden - omdat het bestand bijvoorbeeld niet kan gevonden worden - dan moet de volgende movie afgespeeld worden die het best aan de gestelde criteria voldoet. Dit proces wordt herhaald totdat er geen alternatieve movies meer in de lijst aanwezig zijn. In dat geval wordt de movie afgespeeld die beschreven wordt met het movie header atoom, op voorwaarde dat dit atoom aanwezig is. Het is zelfs perfect mogelijk dat ´e´en van de alternatieve movies een referentie bevat naar de movie die gelinkt is met het movie header atoom. Een standaardmovie wordt vaak gebruikt om compatibiliteit te verzekeren met oudere applicaties die het concept referentie movie nog niet kennen. Zij zullen deze atomen negeren en automatisch de standaardmovie afspelen indien deze aanwezig is. Het data rate atoom (’rmdr’) specificeert de minimale datasnelheid die vereist is om de movie af te spelen. Deze wordt vergeleken met de instellingen in het QuickTime controlepaneel. Applicaties moeten de movie afspelen met de hoogste datasnelheid, kleiner dan of gelijk aan de betreffende instelling. De movie met de hoogste datasnelheid wordt verondersteld de movie met de hoogste kwaliteit te zijn. Indien de door de gebruiker

74

ingestelde snelheid trager is dan eender welke datasnelheid, dan moet een applicatie de movie afspelen met de kleinste datasnelheid. Het CPU speed atoom (’rmcs’) specificeert de minimale rekenkracht die nodig is om een movie te presenteren. QuickTime voert hiertoe een interne test uit waarbij o.a. gekeken wordt naar de kloksnelheid. Deze waarde wordt dan vergeleken met hetgeen gespecificeerd werd in het betreffende atoom. Verder zijn er ook nog twee atomen waarmee het mogelijk is om de versie van QuickTime te controleren (’rmvc’) en om te kijken of een bepaalde component wel aanwezig is (’rmcd’). Het quality atoom beschrijft de relatieve kwaliteit van een movie. In geval van twijfel, wanneer bijvoorbeeld meerdere movies voldoen aan de gestelde vereisten, zal dit gebruikt worden om de knoop door te hakken. Er kan slechts ´e´en quality atoom aanwezig zijn in een movie. Van atomen van het type ’rmcd’ kunnen er wel meerdere instanties voorkomen.

5.5 5.5.1

Enkele nuttige voorbeelden en scenario’s Werken met samples

QuickTime gebruikt het ’mdat’ atoom voor het bewaren van mediadata. Hierbij wordt mediadata opgeslagen onder de vorm van samples, waarbij het mogelijk is dat elk sample een eigen duur heeft. Zoals reeds gezien is een sample ´e´en enkel element in een sequentie van tijdsgeordende data. Samples worden op hun beurt opgeslagen in een aantal chunks of brokken. Chunks vormen een collectie van bij elkaar horende datasamples zodat QuickTime, meer bepaald de data handler, op die manier de toegang tot data kan optimaliseren. Een chunk kan ´e´en of meerdere samples bevatten. Zoals getoond wordt in figuur 5.7 kunnen chunks verschillende groottes hebben, weliswaar steeds kleiner dan een in te stellen limiet. De individuele samples in een chunk kunnen eveneens in grootte vari¨eren. Om de samples in een mediadata-atoom te beschrijven maakt QuickTime gebruik van het sample table atoom (’stbl’). Dit is een containeratoom dat dienst doet als een opslagplaats voor informatie over de samples en dat heel wat andere atomen zal bevatten. Deze verschillende atomen zullen toelaten dat de (basis) media handler in staat is om de samples in de correcte volgorde te parsen. Merk op dat hierbij gebruik gemaakt wordt van een ordening van de samples die verschillend kan zijn van de volgorde waarin ze voorkomen in movietijd. Het sample table atoom bevat dus informatie die het mogelijk maakt een conversie uit te voeren van movietijd naar mediatijd, van mediatijd naar samplenummer, en van samplenummer naar een samplelocatie. Dit atoom zal ook over gegevens beschikken die aangeven hoe een sample moet ge¨ınterpreteerd worden, bijvoorbeeld of een videosample al dan niet gedecomprimeerd moet worden en, indien dit het geval is, hoe dit moet uitgevoerd worden. Het sample table atoom kan het sample description atoom, het time-to-sample atoom, het sync sample atoom, het sample-to-chunk atoom, het sample size atoom, het chunk

75

Datastroom Sample 1 Sample 2

Chunk 1

Sample 3

Sample 4 Chunk 2 Sample 5 Sample 6 Chunk 3

Sample 7

Chunk 4

Sample 8

Chunk 5

Sample 9

Figuur 5.7: Samples in mediadata. offset atoom, en het shadow sync2 atoom bevatten. Het sample table atoom beschikt dus over voldoende informatie om samples in de tijd te kunnen lokaliseren, om het type van samples te kunnen bepalen, alsook hun grootte, container, en offset in de container of het chunk. Het sample description atoom moet tenminste ´e´en item bevatten. Dit atoom moet steeds voorkomen omdat het een index bevat die zal gebruikt worden in een tabel die opgeslagen ligt in het data reference atoom (’ref’). Data reference atomen bevatten tabulaire data die de data handler component informatie zal geven over hoe het toegang kan krijgen tot de data, bijvoorbeeld via een alias of via een URL. De zojuist beschreven index zal een entry identificeren in de betreffende tabel. Deze entry heeft terug de vorm van een atoom. Het is dus mogelijk dat de betreffende tabel meerdere entries heeft, wat betekent dat niet alle samples in een track noodzakelijkerwijze in hetzelfde bestand opgeslagen liggen. Sommige van deze samples kunnen zelfs bewaard worden in een bestand dat zich op een webserver bevindt. Zonder het sample description atoom is het dus voor QuickTime onmogelijk om te bepalen waar de mediasamples opgeslagen werden. Het sync sample atoom is optioneel. Indien het sync sample atoom niet aanwezig is, veronderstelt QuickTime impliciet dat alle samples sync samples zijn. Dit is bijvoorbeeld het geval voor 2

Shadow sync samples zijn key samples die door QuickTime onder bepaalde omstandigheden aan een datastroom kunnen toegevoegd worden om zo de performantie te verbeteren. Men kan hierbij denken aan het toevoegen van key frames aan een stroom van videoframes.

76

XMLT samples. Het sample description atoom slaat ook informatie op over hoe samples moeten gedecodeerd worden, m.a.w. het zal informatie bevatten over de eventueel toegepaste compressietechnieken, zoals het algoritme dat gebruikt werd met eventueel bijhorende inputparameters, of er al dan niet sprake is van temporele of ruimtelijke compressie,. . . Het is duidelijk dat de datastructuur die gebruikt wordt voor de beschrijving van samples zal vari¨eren naargelang het mediatype. Zo zal een beschrijving van videodata geen informatie bevatten over het aantal kanalen (mono, stereo) dat gebruikt wordt door de corresponderende audiodata. Via Atomic Player is het mogelijk dergelijke informatie op te vragen. Wanneer QuickTime een movie vertoont aan een gebruiker, moeten de geactiveerde media handlers voortdurend samples lokaliseren in de tijd en deze vanaf schijf ophalen. Het is waarschijnlijk duidelijk geworden dat de (basis) media handler hiertoe verschillende tabellen moet raadplegen. Ik zal via een voorbeeld de werking van dit proces proberen te verduidelijken. Sample 1 (4 kB - 10 TE) Chunk 1 Sample 2 (4 kB - 10 TE) Sample 3 (4 kB - 10 TE) Chunk 2 Sample 4 (4 kB - 10 TE) Sample 5 (4 kB - 10 TE) Chunk 3 Sample 6 (4 kB - 10 TE)

Figuur 5.8: De payload van een mediadata-atoom. Veronderstel een zelfstandige movie die bestaat uit ´e´en track, zijnde een videospoor, en waarbij de movie 2 seconden duurt. Hierbij worden de videobeelden afgespeeld aan een snelheid van 3 fps. De movietijdschaal heeft een waarde van 600 TE/s, terwijl de mediatijdschaal een waarde heeft van 30 TE/s. Neem ook aan dat de edit list specificeert dat de videosamples mogen afgespeeld worden in de volgorde waarin ze opgeslagen zijn in de mediacontainer. Veronderstel bovendien ook dat alle samples dezelfde grootte en duur hebben. In figuur 5.8 ziet u de voorstelling van de payload van het mediadata-atoom. Neem nu aan dat we op zoek zijn naar de file offset van het videosample dat start op tijdstip 800 in het movietijdsco¨ordinatensysteem. Daartoe moet de (basis) media handler de volgende stappen uitvoeren: 1. Converteer de opgegeven tijd van het movietijdsco¨ordinatensysteem naar het mediatijdsco¨ordinatensysteem.

77

0

600

800

1200 Movie tijd

0

30

60

40

Media tijd

Figuur 5.9: Conversie movietijd - mediatijd. Count

Duration

6

10

Figuur 5.10: Een voorbeeld van een time-to-sample tabel met een gecomprimeerde entry. Concreet betekent dit dat tijdstip 800 in movietijd moet omgezet worden naar mediatijd. Via figuur 5.9 stellen we vast dat dit kan gebeuren door de regel van drie toe te passen. Door 800 te delen door 20 bekomen we hetzelfde punt in mediatijd. Immers, 20 is ook het getal waarmee de movietijdschaal moet gedeeld worden om de mediatijdschaal te bekomen aangezien iedere tijdseenheid in mediatijd 20 maal langer duurt dan een tijdseenheid in movietijd. 2. Gebruik het time-to-sample atoom om het samplenummer te kennen dat data bevat voor het berekende tijdstip in mediatijd. Time-to-sample atomen (’stts’) slaan informatie op over de duur van mediasamples, waardoor ze op die manier een link defini¨eren tussen een tijdstip in mediatijd en het corresponderende datasample. Iedere entry in de tabel levert het aantal opeenvolgende samples op met dezelfde duur, samen met de betreffende duur van deze samples. Door de verschillende duurwaarden op te tellen, kan een volledige time-to-sample functie opgebouwd worden. Neem aan dat ST T S(n) de duur is van sample n in mediatijd en dat DT (n) het begintijdstip is waarop sample n begint in mediatijd (de display time). Men noemt ST T S(n) ook wel eens de ongecomprimeerde entry in de tabel. Dan stelt DT (n+1) = DT (n) + ST T S(n) het begintijdstip voor van het n + 1de sample in mediatijd. Merk op dat de sample entries geordend zijn in de (media)tijd en dat de hierPbesproken waarden niet-negatief zijn. De DT -as heeft als oorsprong 0; DT (i) = i−1 j=0 ST T S(j), en de som van alle ST T S-waarden levert de lengte op van de media in de track (niet omgezet naar movietijd en ook geen rekening houdend met de edit list). Het edit list atoom levert de initi¨ele DT -waarde. Dit is belangrijk wanneer de edit list aangeeft dat mediasamples hergebruikt worden of dat mediasamples in een andere volgorde moeten afgespeeld worden dan ze voorkomen in de mediacontainer. Anders zou dit leiden tot een verkeerde afbeelding van movietijd naar mediatijd. Men kan in dat geval niet zomaar de regel van drie toepassen.

78

Figuur 5.10 toont de tabel zoals die opgeslagen ligt in het time-to-sample atoom dat bij ons hypothetisch voorbeeld hoort. Hieruit leiden we af dat alle samples dezelfde duur hebben in mediatijd, namelijk 10 TE. Zodoende weten we ook dat tijdstip 40 het begin aangeeft van het 4de sample. De tabel maakt ook duidelijk dat, indien alle opeenvolgende samples dezelfde duur hebben, er maar ´e´en entry gebruikt wordt in de tabel: men spreekt dan van een gecomprimeerde entry. Het sample count veld geeft dan het aantal opeenvolgende samples aan dat dezelfde duur heeft. Bijvoorbeeld, in het geval van videomedia die opgenomen is aan een vaste beeldsnelheid bevat deze tabel ´e´en entry en is de waarde van het count veld gelijk aan het totaal aantal samples. Indien er echter sprake is van een variabele beeldsnelheid, dan zal de tabel meerdere entries bevatten en zal de totale duur van de media een gewogen som voorstellen. Ons voorbeeld is daarvan een speciaal geval. 3. Onderzoek het sample-to-chunk atoom om het chunk te bepalen dat het sample in kwestie bevat. De sample-to-chunk atomen (’stsc’) bevatten een tabel die sample nummers afbeeldt op chunk nummers. Iedere entry in de tabel geeft het aantal opeenvolgende chunks aan dat hetzelfde aantal samples bevat. Bovendien moet alle samples in hetzelfde chunk ook nog eens gekenmerkt worden door dezelfde sample beschrijving. Wanneer het aantal samples per chunk verandert of wanneer een sample beschrijving wijzigt, moet er een nieuwe entry in de betreffende tabel aangemaakt worden. Indien alle chunks hetzelfde aantal samples bevatten en indien alle samples dezelfde sample beschrijving delen, dan heeft de tabel ´e´en entry. Figuur 5.11 toont aan dat dit het geval is voor ons voorbeeld. Hieruit halen we gemakkelijk dat het vierde sample tot het tweede chunk behoort. First Chunk

Samples / Chunk

Sample Description ID

1

2

1

Figuur 5.11: Een voorbeeld van een sample-to-chunk tabel. 4. Extraheer de file offset van het betreffende chunk via het chunk offset atoom. Chunk offset atomen (’stco’) identificeren de locatie van ieder chunk in de mediadatastroom. Merk op dat de betreffende offsets offsets zijn in bestanden; het zijn dus geen offsets in atomen binnen het bestand. Hierdoor is het mogelijk om naar mediadata te refereren zonder gebruik te maken van enige atoomstructuur. Met dit gegeven moet men wel voorzichtig omspringen wanneer de metadata vooraan het bestand wordt geplaatst aangezien de grootte van het movie-atoom de waarden be¨ınvloedt van de chunk offsets. We hebben gezien dat dit probleem min of meer

79

werd opgelost door gebruik te maken van een ’free’ atoom. Verder bestaan er van de bestandsoffsets twee varianten: 32-bits of 64-bits. 0

Chunk 1

8192

Chunk 2

16384

Chunk 3

Figuur 5.12: Een voorbeeld van een chunk offset tabel. Figuur 5.12 toont de tabel voor ons voorbeeld. Hieruit halen we dat chunk 2 start vanaf byte 8192 aangezien de tabel ge¨ındexeerd wordt op chunknummer. De tabel bevat steeds een entry voor ieder chunk. 5. Vind de offset van het sample in het chunk door gebruik te maken van het sample size atoom. Sample size atomen (’stsz’) specificeren de grootte van ieder sample in de mediadata. Dit atoom bevat niet noodzakelijk een tabel. Indien alle samples dezelfde grootte hebben, dan zullen er twee gereserveerde velden in het atoom aangesproken worden. Het ene veld zal ingevuld worden met de grootte van het sample, uitgedrukt in bytes, en het andere veld met het aantal samples. Wanneer er echter samples voorkomen met een verschillende grootte, dan zal hiervan niet gebruikt worden en wordt er een tabel opgebouwd met een entry voor ieder sample. Deze tabel zal ge¨ındexeerd worden op samplenummer. Terugkerend naar ons voorbeeld weten we dat we op zoek moeten gaan naar de bestandsoffset van het tweede sample in het tweede chunk. Dit kunnen we berekenen door bij de bestandsoffset van het tweede chunk de grootte op te tellen van het derde sample. Via het sample size atoom, dat geen tabel bevat aangezien al onze samples dezelfde grootte hebben, kennen we eveneens de grootte van het derde sample. Zodoende wordt de bestandsoffset van het sample dat op tijdstip 800 in movietijd moet afgespeeld worden, gegeven door 8192 + 4096 = 12228. De mediahandler zal deze informatie doorgeven aan de data handler, samen met de grootte van het sample, zodat die de betreffende sampledata kan inlezen. Aangezien de eenheid voor het inlezen van data een chunk is, en rekening houdend met het feit dat een data handler ook aan buffering doet, zal het vierde datasample zich waarschijnlijk reeds in het geheugen bevinden en zal de data handler vrijwel onmiddellijk een handle kunnen teruggeven aan de media handler zodat die de data verder kan interpreteren. Dit betekent echter nog niet dat de media handler reeds onmiddellijk de opgehaalde data kan vertonen. Het zou evengoed kunnen gebeuren dat er nog bijkomende leesopdrachten nodig zijn in het geval dat het betreffende sample bijvoorbeeld geen key sample is.

80

5.5.2

Spelen met atomen

Men kan gebruik maken van de functie QTInsertChild() om nieuwe atomen te cre¨eren en deze onder te brengen in een QT atoomcontainer. De QTInsertChild() functie cre¨eert een nieuw kindatoom voor een ouderatoom. De oproeper specificeert een atoomtype en een atoom ID voor het nieuwe atoom. Indien er voor de atoom ID de waarde 0 opgegeven wordt, kent QuickTime zelf een unieke waarde toe aan het atoom. QTInsertChild() voegt het atoom toe aan de lijst van kinderen waarover een ouderatoom beschikt, en dit volgens de index die gespecificeerd werd m.b.v. de indexparameter; alle reeds bestaande atomen met dezelfde index of groter worden naar het einde van de lijst verschoven. Indien er voor de indexparameter een waarde 0 opgegeven wordt, voegt QuickTime het atoom toe aan het einde van de lijst. De voorbeeldcode maakt een nieuwe QT atoomcontainer aan en roept QTInsertChild() op om een nieuw atoom aan de container toe te voegen. Het bekomen resultaat wordt getoond in figuur 5.13. In de firstAtom parameter wordt de offsetwaarde 32 teruggegeven. QTAtom firstAtom; QTAtomContainer container; OSErr myErr = noErr; myErr = QTNewAtomContainer (&container); if ( !myErr ) myErr = QTInsertChild(container, kParentAtomIsContainer, ’abcd’, 1000, 1, 0, nil, &firstAtom);

QT atoom container

Index = 1 Offset = 32

‘abcd’ 1000

Figuur 5.13: De QT atoomcontainer na het toevoegen van een atoom. Het volgende codefragment doet een oproep naar QTInsertChild() om een tweede kind te cre¨eren. Omdat de waarde 1 opgegeven werd voor de indexparameter, wordt het tweede atoom aan de lijst toegevoegd voor het eerste atoom; de index van het oorspronkelijke atoom wordt veranderd in een 2. De resulterende atoomcontainer wordt getoond in figuur 5.14.

81

QTAtom secondAtom; FailOSErr (QTInsertChild (container, kParentAtomIsContainer, ’abcd’, 2000, 1, 0, nil, &secondAtom));

QT atoom container

Index = 1 Offset = 32

‘abcd’

‘abcd’

2000

1000

Index = 2 Offset = 52

Figuur 5.14: De QT atoomcontainer na het toevoegen van een tweede atoom. Verder voorziet de API ook nog in functies voor het kopi¨eren van atomen, het verwijderen van atomen, voor het uitvoeren van zoekbewerkingen,. . . Dergelijke geavanceerde bewerkingen zijn niet mogelijk met klassieke atomen. De beschrijving van een video-effect wordt bijvoorbeeld gerealiseerd aan de hand van een QT atoom container. Dit is ook het geval voor de input map.

5.5.3

De creatie van movies.

De creatie van videotracks aan 30 fps. De duur van een videobeeld wordt opgeslagen in het time-to-sample atoom dat bevat is in het sample table atoom. Deze duur kan niet ge¨ınterpreteerd worden zonder de mediatijdschaal die het aantal tijdseenheden vastlegt dat per seconde verstrijkt. In dit voorbeeld heeft ieder frame dezelfde duur waardoor het time-to-sample atoom slechts ´e´en entry heeft die van toepassing is op alle videobeelden in de mediadata. Zolang de verhouding tussen beeldduur en mediatijdschaal 1:30 blijft, kan eender welke combinatie van waarden gebruikt worden voor de duur en de tijdschaal. Stel dat de duur van een beeld gelijkgesteld wordt aan 10 TE, dan is de corresponderende mediatijdschaal 300 en is er sprake van een exacte beeldsnelheid van 30 beelden per seconde. Hoe groter de tijdschaal, hoe kleiner de maximale duur. Een tijdschaal heeft standaard de waarde 600. Voor ons voorbeeld is dit een goede waarde voor de mediatijdschaal van de videotrack. Dit vereenvoudigt namelijk het conversiewerk in het geval dat de movietijdschaal eveneens gelijkgesteld wordt aan 600 en maakt een exacte beeldsnelheid van 30 fps

82

mogelijk. Bovendien is 600 eveneens het kleinste gemeen veelvoud van 24, 25 en 30, wat handig is voor het rekenwerk indien men een movie moet cre¨eren. De movietijdschaal kan onafhankelijk gekozen worden van de mediatijdschaal. Aangezien het echter interessant is om te vermijden dat movie edits niet belanden op beeldgrenzen, is het een goed idee om de movietijdschaal gelijk te kiezen aan de mediatijdschaal, of om de movietijdschaal zo te kiezen dat het een geheel veelvoud is van de mediatijdschaal. Zoals reeds eerder gezien wordt de movietijdschaal bijgehouden in het movie header atoom. Met een mediatijdschaal van 600 in het media header atoom, bevat het time-to-sample atoom de waarden zoals aangegeven in tabel 5.2. Atom size

24

Atom type

’stts’

Version/Flags

0

Number of entries

1

Sample count

n

Sample duration

20

Tabel 5.2: Het time-to-sample atoom in het geval van een videospoor dat afgespeeld wordt aan 30 beelden per seconde.

De creatie van audiotracks aan 44.1 kHz Bij audio wordt de duur van ieder audiosample gelijkgesteld aan 1. Doorgaans is het immers niet nodig om editeerbewerkingen binnen een audiosample te kunnen uitvoeren. Daarom zal het time-to-sample atoom, horende bij een audiotrack, slechts ´e´en entry bevatten die van toepassing is op alle audiosamples. Met een waarde van 44100 voor het media header atoom, bevat het time-to-sample atoom de waarden zoals aangegeven in tabel 5.3. Dit atoom geeft niet aan of het geluid mono of stereo is, en of er gebruikt gemaakt werd van 8-bit of 16-bit samples. Deze informatie is opgeslagen in het sample description atoom. Deze datastructuur bevindt zich ook in het sample table atoom.

5.5.4

Werken met edit lists

Edit atomen (’edts’) worden gebruikt om de stukken media te defini¨eren die moeten gebruikt worden bij het opbouwen van een track voor een movie. De edits zelf zijn opgenomen in een edit list tabel, waarbij iedere entry bestaat uit een tijdsoffset, een duur

83

Atom size

24

Atom type

’stts’

Version/Flags

0

Number of entries

1

Sample count

n

Sample duration

1

Tabel 5.3: Het time-to-sample atoom in het geval van een audiospoor dat afgespeeld wordt aan 44100 audiosamples per seconde.

en een afspeelsnelheid. Deze tabel ligt opgeslagen in het edit list atoom (’elst’). Dit atoom wordt gebruikt om een tijdstip in movietijd af te beelden op een tijdstip in mediatijd, en dus uiteindelijk ook op mediadata. Edit lists laten o.a. toe om een segment van een movie te herhalen zonder dat hierbij mediadata moet gedupliceerd worden. Veronderstel een movie die bestaat uit ´e´en track, waarbij de mediatijdschaal de waarde 100 heeft en waarbij de mediaduur gelijk is aan 1000 (10 seconden). Voor dit voorbeeld heeft de movietijdschaal de waarde 600. Indien er geen edits zijn in de movie, dan bevat het edit atoom de waarden zoals weergeven in tabel 5.4. Atom size

36

Atom type

’edts’ Atom size

28

Atom type

’elst’

Version/Flags

0

Number of entries

1

Track Duration

6000 (10 seconds)

Media time

0

Media rate

1.0 (0x00010000)

Tabel 5.4: Het edit atoom indien er geen edits zijn in de movie. Omdat dit een movie beschrijft die slechts uit ´e´en track bestaat, bedraagt de duur van de track in het track header atoom 6000 en heeft de duur van de movie in het movie header atoom eveneens de waarde 6000. Indien nu de track gewijzigd wordt om mediadata af te spelen van 0 naar 2 seconden, en vervolgens om mediadata af te spelen van 0 naar 10 seconden, dan bevat het edit atoom de waarden zoals vertoond in tabel 5.5.

84

Atom size

48

Atom type ’edts’ Atom size

40

Atom type

’elst’

Version/Flags

0

Number of entries

2

Track Duration[1]

1200 (2 seconds)

Media time[1]

0

Media rate[1]

1.0

Track Duration[2]

6000 (10 seconds)

Media time[2]

0

Media rate[2]

1.0

Tabel 5.5: De layout van het edit atoom indien mediadata hergebruikt wordt. Omdat de track nu 2 seconden langer is, heeft de duur van de track in het track header atoom de waarde 7200, en bedraagt de duur van de movie in het movie header atoom eveneens 7200. Stel nu dat gevraagd wordt om tijdstip 1800 in movietijd af te beelden op het corresponderende tijdstip in mediatijd, dan mogen we hier niet zomaar de regel van drie toepassen en 1800 delen door 6. Dan zouden we immers de eerste edit negeren. Om deze toch in rekening te brengen moeten we 1800 verminderen met 1200 (de duur van de eerste edit in movietijd). Op die manier bekomen we 600 en dit mag wel gedeeld worden door 6. Momenteel spelen de mediasamples van tijdstip 0 naar tijdstip 2, waarna ze afgespeeld worden van tijdstip 0 naar tijdstip 10. Indien we enkel het segment beschouwen dat herhaald wordt (van tijdstip 0 naar tijdstip 2) en het afspelen tegen een verdubbelde snelheid, dan behouden we de oorspronkelijke duur. Het edit atoom bevat dan de waarden zoals weergegeven a.d.h. van tabel 5.6. Omdat de duur van de track is teruggebracht tot 10 seconden, is de duur van de track in het track header atoom 6000, en bedraagt de duur van de movie in het movie header atoom 6000. Merk op dat, indien edits zo gekozen worden dat sommige samples niet gebruikt worden, het flattening proces deze samples normaal gezien uit de mediadata verwijdert. Dit is echter niet altijd het geval: indien bijvoorbeeld de eerste 30 frames verwijderd worden en het eerste frame is een key frame en het volgende key frame zit maar op positie 35, dan zullen de eerste 30 frames door QuickTime niet verwijderd worden omwille van data-afhankelijkheid.

85

Atom size

60

Atom type

’edts’ Atom size

52

Atom type

’elst’

Version/Flags

0

Number of entries

3

Track Duration[1]

600 (1 second)

Media time[1]

0

Media rate[1]

2.0

Track Duration[2]

600 (1 second)

Media time[2]

0

Media rate[2]

2.0

Track Duration[3]

4800 (8 seconds)

Media time[3]

200

Media rate[3]

1.0

Tabel 5.6: Hergebruik van mediadata met veranderende afspeelsnelheden.

5.5.5

Data interleaving

Om een optimale afspeelsnelheid te bekomen, is het vaak nodig om een movie te cre¨eren met gemultiplexeerde data (interleaved data). De data voor de movie wordt in het bestand in tijdsvolgorde geplaatst zodat data voor een specifieke tijd in de movie eveneens heel dicht bij elkaar ligt opgeslagen in het bestand. Dit betekent dat data, afkomstig van verschillende tracks, alternerend opgeslagen wordt. Data interleaving zal eveneens progressief downloaden mogelijk maken3 . Om dit principe te illustreren beschouwen we een movie met een video- en een audiospoor. Figuur 5.15 toont hoe de moviedata verzameld werd, en hoe de data moet gesynchroniseerd worden. In dit voorbeeld is de videodata opgenomen aan 10 fps en zijn de audiosamples gegroepeerd in chunks die een halve seconde duren. Figuur 5.16 toont de inhoud van het moviedata-atoom na data interleaving. Zoals besproken in paragraaf 2.7 kan interleaving uitgevoerd worden tijdens het flattening proces. In dit voorbeeld begint het bestand met het movie-atoom (’moov’), gevolgd door het moviedata-atoom (’mdat’). Merk ook op dat het geluidsspoor een zekere 3

Merk op dat data interleaving ook nog in een andere context kan gebruikt worden. Zo wordt deze techniek bijvoorbeeld toegepast op GSM-audiosamples met als bedoeling de correlatie tussen transmissiefouten te minimaliseren zodat foutcorrigerende codes hun werk beter kunnen uitvoeren.

86

1 sec

Tijd

2 sec

3 sec

Video track

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Audio track

1

2

3

4

5

6

7

Figuur 5.15: Non-interleaved mediadata. File 'moov'

'mdat'

1

2

1 2 3 4 5

3

6 7 8 9 10

4

11 12 13 14 15

Figuur 5.16: Interleaved mediadata. voorsprong gegeven wordt teneinde mogelijke vertragingen en storingen in het geluid te vermijden. Dit betekent dat geluids- en videodata met een offset van 1 seconde van elkaar verschoven zijn.

5.5.6

Meerdere databestanden gebruiken

De data reference index die voor een bepaald sample gebruikt wordt teneinde z’n locatie te kennen, wordt opgeslagen in de corresponderende sample beschrijving. Vandaar dat een track die gebruik maakt van meerdere databestanden, ook meerdere sample beschrijvingen zal bevatten. Telkens wanneer de locatie van een sample wijzigt of wanneer het formaat van een sample wijzigt (doordat er bijvoorbeeld gebruik gemaakt wordt van een ander coderingsschema), verandert ook de sample beschrijving. Het sample-to-chunk atoom bepaalt welke sample beschrijving er gebruikt moet worden voor een gegeven sample. Veronderstel dat het sample description atoom de waarden bevat zoals die worden voorgesteld in tabel 5.7.

87

Atom size

...

Atom type

’stsd’

Version/Flags

0

Number of entries

2 Sample description size[1]

...

Data format[1]

’tmcd’

Reserved[1]

0

Data reference index[1]

1

(sample data)[1]

...

Sample description size[2]

...

Data format[2]

’tmcd’

Reserved[2]

0

Data reference index[2]

2

(sample data)[2]

...

Tabel 5.7: Het sample description atoom. Indien er maar ´e´en sample per chunk aanwezig is en indien de eerste 10 samples gebruik maken van sample description 2 en de volgende 30 samples gebruik maken van sample description 1, dan bevat het sample-to-chunk atoom de datawaarden zoals weergegeven in tabel 5.8. Atom size

40

Atom type

’stsc’

Version/Flags

0

Number of entries

2

First chunk[1]

1

Samples per chunk[1]

1

Sample description ID[1]

2

First chunk[2]

11

Samples per chunk[2]

1

Sample description ID[2]

1

Tabel 5.8: Het sample-to-chunk atoom. Tabel 5.9 bevat de waarden van het data reference atoom.

88

Atom size

...

Atom type ’dinf’ Atom size

...

Atom type

’dref’

Version/Flags

0

Number of entries

2

Size[1]

...

Type[1]

’alis’

Version[1]

0

Flags[1]

0 (niet zelfstandig)

Data reference[1]

[alias verwijzend naar bestand #1]

Size[2]

...

Type[2]

’rsrc’

Version[2]

0

Flags[2]

0 (niet zelfstandig)

Data reference[2]

[alias verwijzend naar bestand #2]

Tabel 5.9: Het data reference atoom.

5.5.7

XMLT-componenten

Zoals ik op het einde van hoofdstuk 4 beloofd heb, zal ik hier mijn uitleg verderzetten over de zelfgeschreven XMLT-componenten. Meer bepaald zal ik hun precieze werking verduidelijken aan de hand van pseudocode. Deze code zal illustreren hoe de verschillende componenten omspringen met tijd en data. De XMLT-importcomponent De importcomponent geeft aan een applicatie de mogelijkheid om XML-data in een QuickTime movie te plaatsen. • Indien ( MaakSpoor ) – Maak een nieuw spoor NewTrack. – Maak een nieuwe XMLT-mediacontainer. – Geef NewTrack terug als identificatie van het zojuist aangemaakte spoor. • Anders

89

– Ontvang een XML sample van een applicatie, samen met de duur van het sample en het tijdstip waarop deze aan de track moet toegevoegd worden. Beiden worden uitgedrukt in movietijd. De XML-data kan zich in een bestand bevinden of in een buffer in het geheugen. – Converteer de opgegeven duur van movietijd naar mediatijd. – Haal de mediacontainer op voor het opgegeven XMLT-spoor waaraan het XML sample moet toegevoegd worden. – Start een editeersessie. – Bouw een beschrijving op van het sample, hierbij het dataformaat specificerend (’XMLT’). – Voeg het sample toe aan de mediacontainer en ontvang het tijdstip in mediatijd waarop het XML sample aan de container werd toegevoegd. – Be¨eindig de editeersessie. – Voeg een referentie naar het XML sample toe aan het spoor. De parameters die hierbij moeten opgegeven worden zijn het tijdstip in movietijd waarop het sample moet afgespeeld worden (de locatie van het sample in het spoor), het zojuist verkregen mediatijdstip (de locatie van het sample in de mediacontainer), en de duur van het XML sample, uitgedrukt in mediatijd. De XMLT-exportcomponent De exportcomponent geeft aan een applicatie de mogelijkheid om XML-data uit te extraheren uit een QuickTime movie. • Converteer de opgegeven starttijd van het XML sample van movietijd naar mediatijd. • Open de mediacontainer voor het opgegeven spoor. • Geef de media handler de opdracht om het XML sample op te halen. • Sluit de mediacontainer voor het opgegeven spoor. • Geef de inhoud van het XML sample aan de applicatie. Dit kan gebeuren via een geheugenbuffer. Het XML sample kan echter ook weggeschreven worden naar een bestand op schijf. De XMLT media handler component De media handler component geeft aan een applicatie de mogelijkheid om XML-data af te spelen. Dit is, XML samples inlezen uit een QuickTime moviebestand en in een XML-bestand plaatsen.

90

• Geef de data handler de opdracht om het XML sample op te halen. • Indien dit sample het eerste sample is: construeer de hoofding voor het XMLdocument. • Bereken de huidige systeemtijd en voeg het bekomen resultaat toe aan het XML sample. • Schrijf het XML sample weg in het opgegeven bestand. • Indien dit sample het laatste sample is: construeer de afsluitende tags voor het XML-bestand.

91

Hoofdstuk 6 Netwerkdiensten Sedert enkele jaren zijn we getuige van een explosieve groei op het gebied van de ontwikkeling en het gebruik van netwerkapplicaties die audio en video verzenden en ontvangen over een netwerk. Nieuwe multimediatoepassingen zoals Internetradio, leren op afstand, telefonie over IP,. . . hebben hun intrede gedaan. De eisen die deze applicaties stellen, verschillen aanzienlijk van deze die geponeerd worden door klassieke datageori¨enteerde toepassingen zoals e-mail, FTP, enzoverder. In tegenstelling tot deze applicaties worden multimediatoepassingen doorgaans gekenmerkt door een grote gevoeligheid voor vertragingen en is er typisch ook sprake van een zekere tolerantie qua dataverlies. Onderwerp van dit hoofdstuk is de integratie van QuickTime met netwerktechnologie. We zullen zien dat QuickTime op dit vlak heel wat te bieden heeft, zowel aan de kant van de server als aan de kant van de client.

6.1

Movies aanbieden via een webpagina

Veel Internetgebruikers hebben aan hun browser de QuickTime plug-in toegevoegd. Deze plug-in maakt de functionaliteit van QuickTime beschikbaar voor movies die gedownload worden via bv. het Internet. Via een browser kan een webpagina QuickTime movies op 2 manieren aanbieden: linking en embedding.

6.1.1

Linking

Linking maakt gebruik van gewone hypertext links om QuickTime movies met een webpagina te linken. De volgende link is hiervan een voorbeeld: Een wired movie Meer geavanceerde resultaten kunnen bekomen worden door gebruik te maken van frames en de tag . Deze laten toe een movie te vertonen in een ander venster.

92

Het is mogelijk om de grootte van het venster te controleren en dit zelfs te verbergen. Een dergelijke lijn HTML-code ziet er typisch als volgt uit: Een wired movie

6.1.2

Embedding

Een nadeel van het gebruik van linking is het feit dat een QuickTime movie alleen en tegen een monotone achtergrond verschijnt. Het is niet mogelijk om het gedrag van de QuickTime plug-in vanaf een webpagina te be¨ınvloeden, en er is maar in heel beperkte mate controle mogelijk over de manier waarop een movie aan een gebruiker gepresenteerd wordt. Het toepassen van embedding of het inbedden van een movie zal deze nadelen wegwerken. Hiertoe moet gebruik gemaakt worden van de tag <EMBED>. Embedding heeft als voordeel dat het mogelijk is om een movie eender waar op een pagina te positioneren, en maakt het ook mogelijk om een achtergrondkleur te specificeren en te zeggen welke afbeeldingen, links en tekst er naast een QuickTime movie moeten verschijnen. Embedding zal eveneens toelaten om parameters te versturen naar de QuickTime plug-in, meer bepaald wordt elke parameter die niet door de browser kan ge¨ınterpreteerd worden, doorgestuurd naar deze plug-in. Via de parameters is het bijvoorbeeld mogelijk de QuickTime plug-in duidelijk te maken dat een movie eindeloos moet herhaald worden, dat alle beelden moeten afgespeeld worden, dat de movie controller niet mag getoond worden,. . . Een voorbeeld hiervan is de volgende regel HTML: <EMBED SRC=“WiredMovies.mov” WIDTH=“320” HEIGHT=“256” VOLUME=“100” AUTOPLAY=“true” CONTROLLER=“true” LOOP=“true”> Merk op dat op het Windows platform een embed tag moet ingekapseld worden in een object tag vanaf Internet Explorer 5.5. Reden hiervoor is dat Microsoft Netscape-style plug-ins niet meer ondersteunt vanaf versie 5.5 van hun populaire browser. Hierdoor zag Apple zich genoodzaakt een ActiveX-component te ontwikkelen teneinde dit compatibiliteitsprobleem te omzeilen.

6.2

Enkele netwerktechnieken

Er zijn verschillende manieren om het afleveren van een movie, via een netwerk zoals het het Internet, te verbeteren. Een aantal van deze technieken zijn reeds aan bod gekomen. Denk maar aan progressief downloaden waarbij een movie wordt afgespeeld van zodra deze op de computer van de gebruiker begint aan te komen, en het gebruik van referentie movies. Deze laatste laten toe om uit een collectie van movies de meest geschikte te selecteren, en dit naargelang de eigenschappen van het computersysteem en de netwerkconnectie van een gebruiker. Een QuickTime movie kan ook een browser oproepen om op die manier toegang te verkrijgen tot het Internet. Dit kan gebeuren door een URL in een tekstspoor op te

93

nemen. Verder kan men ook nog gebruik maken van poster movies. Een poster movie bestaat uit ´e´en beeld, afkomstig van een andere movie, en een URL voor de volledige movie. Het beeld bevindt zich in een grafisch spoor terwijl de URL is ondergebracht in een tekstspoor. Wanneer een gebruiker op een poster movie klikt, vervangt het zichzelf door de volledige movie, waarbij deze dan over het Internet wordt gedownload. Poster movies zijn klein waardoor het mogelijk is om er zeer veel op te nemen in een webpagina.

6.3

Ware-tijdsstroming

Stroming houdt in dat er movies verstuurd worden van een server naar een client over een netwerk zoals het Internet. De server breekt een movie op in pakketten die over het netwerk kunnen verzonden worden. Aan de zijde van de ontvanger worden de pakketten verzameld en terug in elkaar gezet zodat de movie kan afgespeeld naarmate data binnenkomt. Een serie bij elkaar horende pakketten wordt een stream of stroom genoemd.

6.3.1

Situering

Stroming is verschillend van een gewone bestandsuitwisseling in die zin dat de client de movie afspeelt naarmate deze over het netwerk binnenkomt. Er wordt dus niet gewacht met het afspelen van een movie totdat alle data gedownload werd. QuickTime movies kunnen gestroomd worden via verschillende protocollen, zoals • HTTP (HyperText Transfer Protocol) • FTP (File Transfer Protocol) • RTP (Real-time Transport Protocol) HTTP en FTP zijn in essentie protocollen die aangewend worden voor het betrouwbaar uitwisselen van bestanden. Deze protocollen worden vaak gebruikt in combinatie met progressief downloaden. Het RTP-protocol wordt daarentegen gebruikt voor real-time streaming. Dit wil zeggen dat moviepakketten in ware tijd verzonden worden, m.a.w. een movie die ´e´en minuut duurt wordt over het netwerk in ´e´en minuut verstuurd (na handshaking en buffering uitgevoerd te hebben). De pakketten zijn voorzien van een tijdstempel zodat de clientsoftware weet in welke volgorde de pakketten moeten vertoond worden aan de gebruiker. Waretijdsstroming werkt zowel met vooraf opgenomen data als met live content. Er kan zelfs sprake zijn van een combinatie van beide, bijvoorbeeld reclame die toegevoegd wordt aan een rechtstreeks verslag van een voetbalwedstrijd. Stromen kunnen ´e´en-op-´e´en zijn (unicast) of ´e´en-op-meerdere (multicast). Omwille van de gelaagdheid en de modulariteit

94

van de QuickTime architectuur is het voor bestaande applicaties mogelijk om real-time movies af te spelen met weinig tot geen codeverandering. Merk op dat het HTTP-protocol voor sommige toepassingen ook aangewend wordt voor ware-tijdsstroming. Hierbij kunnen we denken aan MP3-broadcasting via ICY (IceCast1 style streaming), een protocol dat net zoals RTP/RTSP ondersteund wordt door de streaming server van Apple. Het feit dat het mogelijk is MP3-bestanden te stromen is in grote mate te danken aan het gegeven dat, wanneer een MP3 in stukken opgebroken wordt, deze nog steeds afspeelbaar zijn. Bestanden stromen over HTTP brengt wel een grote overhead met zich mee, onder meer te wijten aan het feit dat HTTP gebruik maakt van TCP. Vandaar dat dit alleen maar gebruikt wordt voor relatief eenvoudige toepassingen. MP3-bestanden kunnen trouwens ook gestroomd worden via RTP/RTSP. Tabel 6.1 geeft een klein overzicht van de kenmerken van de streaming server van Apple en vergelijkt deze met twee andere streaming servers.

6.3.2

Het real-time streaming protocol

Personen die gebruik maken van multimediadiensten, die aangeboden worden over een netwerk zoals het Internet, willen vaak enige controle uitoefenen over hoe een movie afgespeeld wordt. Denk hierbij aan het pauzeren van een movie, aan het vooruitspoelen van een movie,. . . m.a.w. aan functionaliteit die men terug kan vinden wanneer men bijvoorbeeld een video bekijkt of wanneer men bijvoorbeeld naar een CD luistert. RTSP, gedefinieerd in RFC 2326, is een protocol dat dergelijke diensten aanbiedt. Het beschrijft dus geen compressietechnieken voor audio of video. RTSP zal ook geen eisen opleggen wat betreft het gebruikte transportmiddel voor de mediadata (UDP/TCP) of wat betreft de manier waarop de data gebufferd wordt, noch zal het iets zeggen over hoe data in pakketten over een netwerk moeten verstuurd worden. Het real-time streaming protocol is in essentie een protocol dat een mediaspeler zal toelaten controle uit te oefenen over de transmissie van een datastroom. Het is eveneens wat men noemt een out-of-band protocol omdat RTSP-boodschappen over een aparte connectie verzonden worden, dus gescheiden van de dataconnectie (cfr. FTP).

6.3.3

Het real-time transport protocol

Het real-time transport protocol is gelijkaardig aan de welbekende HTTP- en FTPprocollen die gebruikt worden voor het uitwisselen van bestanden. RTP, gedefinieerd in RFC 1889, is echter speciaal ontworpen om te voldoen aan de speciale eisen van waretijdsstroming. 1

IceCast is een open source audio streaming server.

95

Bedrijf

Apple Computer

Microsoft

RealNetworks

Software

Darwin Streaming Server

Windows Services

Server OS

Apple Macintosh, Windows, Linux, Sun Solaris

Windows

Windows, Sun Solaris, Linux, Compaq Tru64, HP Unix, IBM AIX, FreeBSD

Client OS

Apple Macintosh, Windows

Apple Macintosh, Windows (vorige versie ook beschikbaar voor Sun Solaris)

Windows, Apple Macintosh, third-party Unix ondersteuning

MPEG-4 ondersteuning

Ja

Nee

Ja

Te configureren via browser

Ja

Ja

Ja

Prijs

Gratis

Wordt meegeleverd met Windows 2000 Server (niet afzonderlijk beschikbaar)

Varieert van gratis voor 25 gelijktijdige gebruikers tot $5995 en hoger voor 100 tot 2000 gebruikers.

Media

RealSystem iQ

Tabel 6.1: Kenmerken van een aantal streaming servers (Bron: [Woo02]). Stukken audio of video, afkomstig van de zendende kant van een multimediatoepassing, worden ingekapseld in RTP-pakketten. Ieder RTP-pakket wordt op zijn beurt ondergebracht in een UDP-pakket. RTP kan beschouwd worden als een sublaag van de transportlaag omwille van bepaalde diensten die het aanbiedt aan een applicatie, zoals sequentienummers en tijdstempels. Sequentienummers laten een applicatie toe te controleren of pakketten ontbreken of niet in volgorde zijn toegekomen. Tijdstempels maken het voor een toepassing mogelijk de data correct in de tijd af te spelen. Anderzijds kan men RTP ook situeren in de applicatielaag omdat de ontwikkelaar van een multimediatoepassing doorgaans expliciet verantwoordelijk is voor het toevoegen van een RTP-header aan een stuk mediadata bij verzending en doorgaans ook expliciet verantwoordelijk is voor het terug interpreteren van de informatie in de hoofding bij ontvangst. Merk op dat RTP over UDP slechts verkeer in ´e´en richting toelaat, namelijk van zender naar ontvanger. RTSP, dat gebruik maakt van TCP, laat daarentegen tweerichtingsverkeer

96

toe. Dit is immers noodzakelijk voor de interactie met een gebruiker. HTTP GET (80) Web Browser

Web Server myMoviePlayList.sdp (3769) SETUP (554)

A t o m i c P l a y e r

PLAY (554) Video stream (5006)

D S S /

Audio stream (5004) PAUSE (554)

Q T T S

TEARDOWN (554)

Client

Server

Figuur 6.1: De interactie tussen een client en de streaming server. Merk op dat de streaming server in principe bestaat uit 4 elementen: een perl-gebaseerde HTTP Web Admin Server (poort 1220), een RTSP-server (poort 554), een RTP-server (poort 7070) en een ICY-server (poort 8000).

Figuur 6.1 toont een overzicht van de communicatie tussen de streaming server van QuickTime, de Darwin Streaming Server2 , en Atomic Player. Via een browserapplicatie wordt er aan een webserver een bestand opgevraagd dat een beschrijving bevat van de te openen streaming sessie. Dit metabestand zal informatie bevatten over de data die gestroomd wordt. Het gebruik van metabestanden is aan te raden omdat op die manier een rechtsreekse communicatie mogelijk is tussen de streaming server en de multimediatoepassing; anders wordt de browsertoepassing als intermediair gebruikt en dit kan tot problemen leiden zoals onnodige vertragingen. In ons geval bevat het metabestand een referentie naar een multimediastroom via een RTSP-URL. Figuur 6.1 maakt ook duidelijk dat er sprake is van een video- en een audiostroom die simultaan afgespeeld worden en dat hiervoor twee aparte RTP-verbindingen gebruikt worden. Verder stellen we vast dat de gebruiker via het RTSP-protocol o.a. de mogelijkheid heeft om het afspelen van een movie te starten, te pauzeren en te stoppen. Onderstaande listing toont de inhoud van het metabestand, de SDP-file myMoviePlayList.sdp, die aan de streaming import component van Atomic Player beschrijft hoe de streaming sessie eruit ziet. SDP staat voor Session 2

Op het Macintosh platform gebruikt men de QuickTime Streaming Server (QTSS); op alle andere platformen moet men de Darwin Streaming Server (DSS) installeren. QTSS en DSS verschillen van elkaar op vlak van performantie en ondersteuning. Er zijn geen verschillen qua aangeboden functionaliteit.

97

Description Protocol en wordt besproken in RFC 2327. v=0 o=QTSS Play List 872838989 872857415 IN IP4 217.136.219.26 s=C:\Program Files\Darwin Streaming Server\playlists\myMoviePlayList c=IN IP4 127.0.0.1 a=x-broadcastcontrol:RTSP t=0 0 b=AS:1091 m=audio 5004 RTP/AVP 96 b=AS:95 a=rtpmap:96 X-QDM/44100/2 a=control:trackID=1 a=x-bufferdelay:3.02 m=video 5006 RTP/AVP 97 b=AS:995 a=rtpmap:97 X-SV3V-ES/90000 a=control:trackID=2 In het metabestand myMoviePlayList.sdp worden er twee RTP-stromen gedefinieerd: ´e´en voor audio en ´e´en voor video. We kunnen ook vaststellen dat er aan de mediaspeler gevraagd wordt om gedurende de initialisatie van de streaming sessie 3 seconden aan data te bufferen. Verder merken we eveneens op dat er gegevens ter beschikking gesteld worden over het gebruikte IP-protocol (IPv4), de te gebruiken netwerkadressen en poorten, de gebruikte compressieformaten (QDM en SV3), enzoverder. In het geval van een MP3-broadcast kan men bijvoorbeeld gebruik maken van een metafile (myMp3Playlist.m3u) die als inhoud de URL icy://127.0.0.1:8000/music bevat. Music noemt men een mount point; dit maakt het mogelijk een afspeellijst te identificeren via een URL. Voor het openen van een movie via een RTSP-URL maakt men soms ook gebruik van een pointer movie. Dit is een gewoon tekstbestand met als extensie mov en met als inhoud bijvoorbeeld de volgende gegevens: rtsptext rtsp://my.streamingserver.com/sample.mov

6.3.4

Unicast, multicast en relaying

In een unicast (zie ook [Inc01e]) contacteert de client de server door middel van een SDP-bestand of door middel van het opgeven van een RSTP-URL. In het geval van een SDP-bestand beschikt de client reeds over alle nodige informatie. Bij het opgeven van een RTSP-URL moeten gegevens over de streaming sessie - zoals het aantal stromen, de gebruikte mediatypes en codecs,. . . - nog verzonden worden naar de client. Nadien pas worden de eigenlijke stromen naar de client verstuurd over RTP. Wanneer een QuickTime movie over RTP gestroomd wordt, wordt ieder spoor als een aparte stroom verzonden.

98

In een multicast wordt slechts ´e´en stroom3 over een netwerk van multicast compatibele routers verstuurd. Dit zal de hoeveelheid netwerktraffiek zeer sterk reduceren in het geval dat stromen naar een groot aantal clients moeten verstuurd worden. Deze laatste moeten gebruik maken van een SDP-file om zich te kunnen aansluiten bij een multicast. Dit bestand zal een groepsadres bevatten. Niet alle routers ondersteunen echter multicasting. QuickTime clients die zich achter dergelijke routers bevinden kunnen toch nog een multicast ontvangen door gebruik te maken van reflectors. Een reflector is een RTSPserver die zich aansluit bij een multicast en die deze multicast dan converteert naar een aantal unicasts. In een multicast of bij een rechtstreekse transmissie kan een gebruiker niet overschakelen van het ene punt in de stroom naar het andere. Een andere geavanceerde eigenschap die ondersteund wordt door de Darwin Streaming Server is relaying. De basisidee achter relaying is heel eenvoudig en is nauw verwant met de principes die schuil gaan achter multicasting, namelijk dat een server gelimiteerd wordt door de bandbreedte van zijn netwerkconnectie. Zelfs al is er sprake van een 100 megabit connectie naar het Internet, toch is het onmogelijk om een onbeperkt aantal gebruikers tegelijkertijd te bedienen in het geval van unicasts. Maar, indien nu ´e´en van de gebruikers de stroom zou kunnen doorsturen naar een aantal andere gebruikers die zich dicht bij die ene gebruiker bevinden, dan zou dit al een hoop bandbreedte schelen. De stroom die dan uitgezonden wordt, neemt de vorm aan van een boomstructuur, net zoals dat het geval is bij multicasting.

6.3.5

Ware-tijdsstroming of progressief downloaden

QuickTime ondersteunt stroming over RTP en HTTP. Hieronder volgt een opsomming van de voordelen van RTP-stroming. • RTP kan gebruikt worden voor het verzorgen van rechtstreekse transmissies en ondersteunt eveneens multicasting. • Ware-tijdsstroming maakt gebruik van UDP/IP-technologie (sommigen spreken ook wel eens over “spray and pray” of “send and forget” technologie). Hierbij worden verloren gegane pakketten niet opnieuw verstuurd. Daartoe steunt men op het principe dat een kleine storing in het beeld of het geluid nog altijd beter is dan een schokkerige presentatie doordat er voortdurend moet gewacht worden op data die opnieuw moet verzonden worden. Ook is retransmissie in een rechtstreekse uitzending weinig zinvol. Merk eveneens op dat multicasting niet mogelijk is via TCP/IP-technologie omdat het TCP-protocol een connectiege¨ori¨enteerd protocol is. UDP daarentegen is connectieloos, net zoals het IP-protocol. Een connectiege¨ori¨enteerde verbinding houdt in dat volgende stappen doorlopen worden: 3

Deze zal wel nog bestaan uit verschillende substromen naargelang het aantal tracks in de movie.

99

1. Opzetten van een verbinding waarbij bronnen (buffers, frequenties, tijdsintervallen,. . . ) moeten gereserveerd worden. Dit kan zowel plaatsvinden in het netwerk (bv. QoS in een ATM-netwerk) als aan de kant van de zender en de ontvanger. 2. Het eigenlijke versturen van data. 3. Het verbreken van de verbinding waarbij de gereserveerde bronnen terug vrijgegeven worden. • Ware-tijdsstroming laat toe dat een gebruiker lange movies of continue transmissies kan bekijken of beluisteren zonder dat er lokaal meer dan een paar seconden data hoeft opgeslagen te worden. Voor draadloze netwerken en handheld toestellen is dit een uiterst belangrijke eigenschap. • Door gebruik te maken van RTP onder controle van RTSP, is het voor een gebruiker zelfs mogelijk over te schakelen naar een willekeurig punt in een movie zonder dat hierbij de tussenliggende data moet gedownload worden. In het geval van een rechtstreekse uitzending is dit natuurlijk niet mogelijk; QuickTime kent dan een oneindige duur toe aan de movie. • Het is mogelijk om slechts ´e´en track te stromen over RTP, dit in tegenstelling tot HTTP waar een ganse movie moet gestroomd worden. RTP-stromen kunnen toegevoegd worden aan een movie door gebruik te maken van streaming tracks. Een streaming track (’strm’) is een spoor in een QuickTime movie dat een URL bevat naar de te stromen data. • Een QuickTime movie die voorzien is van streaming tracks kan ook nog gewone sporen bevatten die bijvoorbeeld referenties bevatten naar data die zich lokaal in het computersysteem bevindt. Dit laat toe een rechtstreekse uitzending, of data die opgeslagen is op een netwerkserver, te combineren met materiaal dat zich bevindt op de harde schijf van een gebruiker of dat verspreid werd via een CD-ROM. • RTP-stroming maakt alleen gebruik van die bandbreedte die het echt nodig heeft. Het spreidt de hoeveelheid benodigde bandbreedte in de tijd, wat een zeer interessante eigenschap is voor draadloze netwerken. Hieronder volgt een opsomming van de voordelen van stroming over HTTP. • Een QuickTime bestand kan gestroomd worden vanaf eender welke HTTP-server. Dit laatste kan zelfs een gewone PC zijn die uitgerust is met de correcte software. Ware-tijdsstroming kan echter enkel gerealiseerd worden via een RTP-server. De meeste firewalls en netwerkconfiguratieschema’s laten HTTP-boodschappen zonder problemen door. Dit is echter niet altijd het geval voor RTP-stromen, waardoor bijvoorbeeld gebruik moet gemaakt worden van HTTP-tunneling. Dit is een techniek waarbij RTP-pakketten ingekapseld worden in HTTP-pakketten. De kwaliteit

100

zal hetzelfde blijven maar de belasting voor het netwerk zal zwaarder worden wegens de grotere pakketten. Indien het netwerk dit niet aankan zal er pakketverlies optreden. Aangezien er nu gebruik gemaakt wordt van HTTP-tunneling zal TCP dit detecteren en zal het voortdurend retransmissies aanvragen wat de verzadiging van het netwerk alleen nog maar vergroot. De DSS zal hierop reageren door de te versturen datastroom te verkleinen: er zullen dan bijvoorbeeld enkel nog key frames of audiodata verstuurd worden. • HTTP-stroming gebruikt TPC/IP-technologie om er zeker van te zijn dat alle pakketten op hun bestemming aankomen. Desnoods worden ze opnieuw verstuurd. Indien er niet genoeg bandbreedte voorhanden is om een movie in ware tijd te versturen, zal HTTP-stroming de ontvanger data laten bufferen totdat er voldoende info aanwezig is om de movie af te spelen. Bij RTP gaan niet aangekomen pakketten definitief verloren, wat een realiteit is bij een netwerk zoals het Internet. Verlies van data in een LAN komt eerder zelden voor. • Eender welke QuickTime movie kan gestroomd worden via HTTP. RTP-stroming ondersteunt alleen het stromen van video, audio, tekst, en MIDI. Om een movie met andere mediatypes te kunnen stromen, zoals sprites, moet er gesteund worden op HTTP. Voor meer uitleg over sprites verwijs ik naar paragraaf 7.2. Uit het bovenstaande kunnen we afleiden dat ´e´en van de voornaamste eisen bij RTPstroming bestaat uit het feit dat de beschikbare bandbreedte van het netwerk groter moet zijn dan de datasnelheid van de te stromen movie. Indien dit niet het geval is gaan er onherroepelijk pakketten verloren en valt de presentatie van een movie volledig in het water. Verlies van volledige videobeelden wordt in QuickTime bijvoorbeeld tegengegaan door videobeelden als een raster voor te stellen en elk onderdeel van het raster te versturen als een apart RTP-pakket. Wanneer dan enkele pakketten ontbreken is dat nog geen ramp en zal dit min of meer kunnen hersteld worden. Dit is soms merkbaar bij het ontvangen van de eerste beelden.

6.3.6

Openen van streaming movies

Omwille van de krachtige importfaciliteiten van QuickTime komt het openen van een streaming movie op vrijwel hetzelfde neer als het openen van een klassieke movie. Een streaming movie kan geopend wordt via • een moviebestand dat streaming tracks bevat • een SDP-bestand (gebruikt bij (gesimuleerde) live streams) • een URL (gebruikt bij movies-on-demand)

101

Het openen van een movie via een URL zoals RTSP://qtss.domain.com/sample.mov correspondeert in grote mate met het bekijken van een video. Als gebruiker heeft men de volledige controle over het verloop van de presentatie. Het zich aansluiten bij een streaming sessie via een SDP-bestand komt in feite neer op het aanzetten van de televisie; men belandt in het midden van een uitzending zonder dat men hier iets aan kan doen, m.a.w. de controlemogelijkheden van een gebruiker zijn in deze situatie beperkt. Het is eveneens mogelijk om een moviebestand te openen via een HTTP- of FTP-URL, en waarbij het moviebestand streaming tracks bevat. De Movie Toolbox zal detecteren welke technieken er gebruikt worden en zal automatisch de gepaste importcomponenten oproepen. Het openen van een movie via een moviebestand dat streaming tracks bevat, is interessant omdat het op die manier mogelijk is data, die niet kan gestroomd worden, te koppelen aan data die wel kan gestroomd worden. In sommige situaties kan dit heel interessant zijn. Zo is het niet mogelijk om trackreferenties, die o.a. gebruikt worden bij video-effecten en chapter lists, te stromen. Door deze referenties echter toe te voegen aan een movie, voorzien van ´e´en of meerdere streaming tracks, en de betreffende movie dan bijvoorbeeld via HTTP te downloaden en lokaal te openen, kan dergelijke functionaliteit toch nog aangeboden worden aan een gebruiker. Deze werkwijze is ook interessant indien er gewerkt wordt met data die geen pakketverlies tolereert, zoals tekst. Voor de gebruikerservaring is dit niet zo erg aangezien dergelijke data meestal slechts een klein onderdeel vormt van een multimediapresentatie. Voor mediatypes die niet tolerant zijn qua dataverlies kan er eveneens gebruik gemaakt worden van RTP over TCP of zelfs van het RTSP-protocol. Een andere mogelijkheid is de introductie van semi-betrouwbaarheid door gebruik te maken van redundante transmissies. Deze laatste techniek kan bijvoorbeeld aangewend worden bij het stromen van een teksttrack. Bij redundante transmissie wordt een RTP-pakket dus meerdere malen verstuurd gedurende de duur van het sample. Hierbij wordt het betreffende pakket telkens integraal opnieuw verstuurd met hetzelfde sequentienummer, dezelfde tijdsmarkering en dezelfde payload. Men zou dus bij het dumpen van de pakketten die over de verbinding verstuurd worden een aantal maal hetzelfde pakket zien. Deze techniek is zeker niet bandbreedtevriendelijk wanneer ze gebruikt wordt bij mediatypes die een hoge bandbreedte vereisen. Daarom zal ze enkel gebruikt worden bij mediatypes die een lage bandbreedte nodig hebben, zoals tekst en tweens. Door telkens te werken met hetzelfde RTP-sequentienummer kunnen duplicaten aan ontvangerszijde gedetecteerd en verwijderd worden. Pakketten kunnen op verschillende manieren verstuurd worden tijdens een retransmissie-interval: bijvoorbeeld d.m.v. 4 uniforme retransmissies, of meer complex, via een aantal exponentieel toenemende intervallen binnen de duur van het sample. Het openen van een streaming movie neemt typisch ook meer tijd in beslag dan het openen van een movie met enkel lokale inhoud. Aangezien bepaalde tracks verzonden worden als een stroom van RTP-pakketten, moet de client voor elk van dergelijke sporen

102

een netwerkconnectie opzetten. Bovendien is er vaak ook nog een controleverbinding nodig. Men moet er eveneens rekening mee houden dat er netwerkproblemen kunnen optreden en dat er in eerste instantie helemaal niets gekend is over de eigenschappen van de data die binnengehaald wordt. Een applicatie moet deze dynamisch veranderende karakteristieken - zoals hoogte, breedte, duur en of er al dan niet audio aanwezig is - in acht nemen en zal aanvankelijk moeten gebruik maken van een aantal standaardinstellingen. Het bufferen van data en het openen van connecties naar de gepaste media handlers wordt in QuickTime termen prerolling genoemd. Dit wordt uitgevoerd na de nodige netwerkverbindingen opgezet te hebben (preprerolling). Indien een applicatie gebruik maakt van een movie controller wordt preprerolling automatisch uitgevoerd. Preprerolling kan synchroon of asynchroon uitgevoerd worden. Asynchroon wil zeggen dat de functie onmiddellijk terugkeert zodat de applicatie ander werk kan uitvoeren. Deze laatste zal op geregelde tijdstippen wel expliciet processortijd moeten geven aan het preprerolling mechanisme. Verder maakt Apple’s streaming server ook nog gebruik van skip protection. Dit is een marketing term voor een collectie van spitsvondigheden die door de DSS aangewend worden om de kwaliteit van een stroom te verbeteren. Een essentieel onderdeel van skip protection is reliable UDP, een combinatie van anticiperend bufferen op basis van continue metingen van de beschikbare bandbreedte, retransmissies van verloren gegane pakketten en controle over de verzadiging van het netwerk (congestion control, cfr. het terugvallen op de transmissie van key frames). Deze drie technieken kunnen onafhankelijk van elkaar toegepast worden maar samen leveren ze een extreem hoge betrouwbaarheid op qua aflevering van pakketten. Stromen kunnen ook voorwaartse foutcorrectie en dataredundantie bevatten maar dit zijn eerder technieken waarvoor compressie- en pakketisatiecomponenten verantwoordelijk zijn en die verborgen gehouden worden voor de streaming server. Ondanks het feit dat Apple’s reliable UDP sterke overeenkomsten vertoont met TCP is het niet hetzelfde. Zo is er geen sprake van flood control en implementeert de Darwin Streaming Server evenmin het Nagle-algoritme4 . De streaming server buffert data omwille van de volgende drie vaststellingen: 1. Sommige pakketten komen later toe dan andere omdat ze bijvoorbeeld vertraging ondervonden in een router. Door gebruik te maken van buffering kunnen latere pakketten toch nog gebruikt worden wanneer ze in het buffervenster vallen. Dit venster heeft standaard een grootte van drie seconden. 2. De bandbreedte die een movie nodig heeft is wisselvallig. Het optreden van een sceneverandering in een movie komt typisch overeen met een grotere nood aan bandbreedte (spikes). Een buffer geeft de vrijheid om deze pieken wat meer te spreiden in de tijd zodat ze niet resulteren in dataverlies. 4

Dit algoritme wordt door TCP aangewend om te vermijden dat er teveel kleine pakketten of tinygrams moeten verstuurd worden. Men kan dit realiseren door gebruik te maken van vertraagde bevestigingen (delayed ack’s).

103

3. Video- en audiodata hebben doorgaans verschillende transmissietijden aan de kant van de zender. Een buffer maakt het mogelijk om deze datastromen terug met elkaar te synchroniseren aan de kant van de client. Wanneer de streaming server vaststelt dat er voldoende bandbreedte aanwezig is, zal het, naargelang de configuratie, proberen om nog meer data binnen te halen, en dit in de mate van het mogelijke (cfr. een rechtstreekse uitzending). Soms kan dit echter tot een verzadiging van de netwerkconnectie leiden (bijvoorbeeld wanneer de door de DSS gebruikte bandbreedte heel dicht aanleunt bij de werkelijke bandbreedte) waardoor er pakketverlies en retransmissies optreden die de situatie uiteindelijk alleen nog maar erger maken. Merk ook op dat skip protection er voor zal zorgen dat de laatste seconden van een streaming movie volledig vanuit de buffer afgespeeld worden.

6.3.7

Een movie klaarmaken voor stroming

QuickTime movies die enkel bestaan uit audio- en videotracks kunnen klaargemaakt worden voor stroming door het toevoegen van hinttracks. Deze tracks zullen aan de RTPserver vertellen hoe de mediadata in pakketten moet opgedeeld worden. Indien een movie trackreferenties bevat voor objecten zoals sprites of effecten, moeten er twee movies gecre¨eerd worden: een server movie en een client movie. Audiospoor

Audiostroom

RTP Server

UDP/IP

Streaming Spoor

Videospoor

Videostroom

Hintspoor

UDP/IP Controlestroom

URL van de server movie.

Hintspoor

Server movie

RTSP Server

Client movie

TCP/IP

Figuur 6.2: Situering van een server movie en een client movie.

Server movies Een streaming movie voor een RTP-server kan aangemaakt worden door hinttracks (’hint’) toe te voegen aan een reeds bestaande movie, ´e´en voor elk spoor dat moet gestroomd worden. Dit wordt gerealiseerd via een aantal geschikte exportcomponenten. De server maakt gebruik van de hinttracks in een streaming QuickTime movie om de mediadata te converteren naar een stroom van RTP-pakketten. Dit maakt de QuickTime Streaming Server codec agnostisch. De RTP-server hoeft niets af te weten van QuickTime mediatypes of codecs. De hinttracks in het moviebestand leveren de informatie die nodig is om QuickTime mediadata

104

om te zetten naar RTP-pakketten. Iedere hinttrack bevat de nodig informatie om voor ieder datapakket een correcte hoofding te kunnen construeren. De hinttrack zal eveneens een wijzer afleveren naar de mediadata die moet opgenomen worden in een pakket. De RTP-server moet wel weten hoe QuickTime moviebestanden opgebouwd zijn zodat het deze kan parsen. Op die manier is de server in staat om iedere hinttrack te lokaliseren en kan de server vervolgens op zoek gaan naar de de corresponderende sampledata waarnaar verwezen wordt vanuit het hintspoor. Dit spoor zal hierbij heel wat waarden bevatten die reeds op voorhand berekend werden. Op die manier kan de RTP-server gemakkelijker en sneller RTP-pakketten aanmaken en versturen. Hinttracks kunnen er dus voor zorgen dat de hoeveelheid door de RTP-server uit te voeren werk tot een minimum beperkt wordt. Bijgevolg is het mogelijk dat een RTPserver in staat is om data effici¨enter te versturen wanneer deze zich in een QuickTime movie bevindt, zelfs al verstaat de RTP-server het gebruikte mediatype of codec waardoor het in principe geen hinttracks nodig heeft. Bijvoorbeeld, een RTP-server kan in staat zijn om H.263-videodata te interpreteren. Het generen van een bijhorende stroom van RTPpakketten vergt echter bijzonder veel rekenwerk omdat in het geval van H.263-videodata moeilijk is om exacte pakketgrenzen te bepalen. Via een hinttrack kan deze informatie op voorhand berekend en opgeslagen worden in het hintspoor. Een movie die voorzien werd van hinttracks hoeft geen zelfstandige movie te zijn. De movie mag nog steeds referenties bevatten naar samples die opgeslagen liggen in andere bestanden, alhoewel dit omwille van performantieredenen afgeraden wordt. Hierbij kunnen de volgende opmerkingen gemaakt worden: • Men moet gebruik maken van bestandsspecificaties die zowel begrepen worden door het systeem waarop de movies gecre¨eerd werden als door het systeem waarop de RTP-server draait. • Nadat de movie opgeslagen werd mag het relatief pad naar de verschillende databestanden niet meer veranderen. Dit kan het gemakkelijkst gerealiseerd worden door gebruik te maken van kleine letters in bestandsnamen, zonder spaties, en door de verschillende bestanden (databestanden en moviebestand) onder te brengen in dezelfde directory. Hinttracks mogen pas toegevoegd worden gedurende de laatste stap bij het maken van een streaming movie. Van zodra er een editeerbewerking uitgevoerd wordt op een movie toevoegen of verwijderen van samples, flattening,. . . - worden de hintsporen ongeldig. Deze moeten dan verwijderd en terug toegevoegd worden. Merk op dat hintsporen standaard ook op passief staan zodat ze niet interfereren met de manier waarop een movie afgespeeld wordt.

105

Client movies Een client streaming movie kan aangemaakt worden door streaming tracks toe te voegen aan een gewone movie. Iedere streaming track wordt gekenmerkt door het type ’strm’ en bevat ´e´en mediasample, zijnde een tekststring die een URL bevat naar een server movie. Een movie die streaming tracks bevat kan bijvoorbeeld gedownload worden via HTTP en dan lokaal afgespeeld worden. In dat geval maakt de computer van de gebruiker een netwerkverbinding met de gespecificeerde RTSP-server en dit voor iedere streaming track in de movie. Merk op dat een client movie nooit audio- of videodata bevat afkomstig van een server movie; deze data wordt vertoond en daarna verwijderd. De meest eenvoudige gedaante van een client movie heeft ´e´en streaming track die een URL bevat naar de server movie. Op een meer complex niveau kan een client movie ook referenties bevatten naar lokaal opgeslagen mediadata. Deze techniek kan bijvoorbeeld aangewend worden om een live stream te combineren met lokale data of om movieelementen toe te voegen die niet kunnen gestreamed worden. Een streaming track kan, net zoals eender welke andere track, beginnen op een willekeurig punt in movietijd. Laat ons bijvoorbeeld kijken naar het toevoegen van een chapterlist, een movieelement dat trackreferenties vereist, aan een streaming movie. In een eerste stap moet de teksttrack waarin de beschrijvingen opgeslagen liggen van de verschillende hoofdstukken, ge¨extraheerd worden uit de originele movie. Daarna kan dit tekstspoor verwijderd worden en is het mogelijk om het resterende deel op te slaan als een hinted server movie. De client movie moet dan de volgende elementen bevatten: • Een lokale passieve teksttrack die de chapter list bevat. • Een streaming track die verwijst naar de server movie. • Een track referentie van het type ’chap’ in de streaming track die naar de chapter list track verwijst zodat QuickTime de passieve teksttrack niet negeert bij het openen van de movie. De resulterende server en client movies zullen samenwerken zodat ware-tijdsstroming mogelijk is van de originele movie. Merk op dat, in tegenstelling tot andere tracks, een streaming track referenties kan bevatten naar meerdere datastromen van een verschillend type. Een streaming track in een client movie kan bijvoorbeeld een URL bevatten naar een server movie met audio-, video-, en tekstsporen.

6.3.8

Media packetizers en reassemblers

Hinting wordt uitgevoerd door een exportcomponent, meer bepaald door een media packetizer component. QuickTime zal voor ieder spoor automatisch de gepaste media packetizer

106

component selecteren, en dit naargelang het type van het spoor. De output van een dergelijke component zal op z’n beurt doorgestuurd worden naar een packet builder die dan het eigenlijke hintspoor opbouwt. Media packetizers zijn dus componenten die in staat zijn om QuickTime mediadata op te breken in pakketten die geschikt zijn voor RTPtransmissie. Packet reassembler componenten zijn in staat om de ontvangen pakketten terug in elkaar te zetten tot afspeelbare mediadata. Packetizers en reassemblers worden paarsgewijs geschreven; ´e´en om te pakketiseren tijdens transmissie, de ander om pakketten terug in elkaar te zetten bij ontvangst. Media packetizers worden gebruikt gedurende rechtstreekse uitzendingen en gedurende de creatie van hintsporen. Reassemblers worden gebruikt bij het ontvangen van streaming data. Deze componenten kunnen al dan niet geoptimaliseerd zijn voor de verwerking van een bepaald mediatype of compressieformaat zoals Sorenson Video 3. Atomic Player

Movie Toolbox

ConvertMovieToFile() Track Media

Movie Exporter Hinter Component

Media Packetizer

Packet Builder

Hint Track

Figuur 6.3: De creatie van een hintspoor. RTP-transmissie doet zijn best om pakketten zo goed mogelijk af te leveren maar het kan geen garanties bieden. Over het Internet is datatransmissie inherent verlieshebbend. Pakketten kunnen verloren gaan of zelfs niet verzonden worden, ze kunnen in een andere volgorde toekomen of een aanzienlijke vertraging ondervinden. Opdat stroming onder deze omstandigheden goed zou kunnen werken, moet er vaak heel wat intelligentie toegevoegd worden aan de zender en de ontvanger, meer bepaald aan de media packetizer en de packet reassembler. Denk hierbij aan het reeds gegeven voorbeeld waarbij een videobeeld in stukken opgedeeld wordt, of aan het stromen van tekstsporen waarbij er gebruik gemaakt wordt van dataredundantie. Merk op dat niet alleen mediadata moet gestroomd worden maar ook metadata, zoals bijvoorbeeld transformatiematrices en afmetingen. Dit gebeurt door het afspreken van speciale regels of functies tussen een media packetizer en bijhorende reassembler. Via de QuickTime API is het mogelijk om eigen packetizer en reassembler componenten te schrijven. Hierbij kan men, in analogie met media handlers, ook terugvallen op een aantal basiscomponenten die veel uitgevoerde functies reeds kant en klaar aanbieden.

6.3.9

Het formaat van een hintspoor

Zoals we al gezien hebben wordt iedere track in een server movie voorzien van een hintspoor. Voor een gegeven track is het perfect mogelijk om meerdere hinttracks te cre¨eren

107

zodat het op die manier mogelijk is de transmissie over een netwerk te optimaliseren in functie van de pakketgrootte. Hinttracks zijn op dezelfde manier opgebouwd als de reeds besproken QuickTime sporen. Standaard QuickTime datastructuren, zoals trackreferenties, worden gebruikt om verwijzingen op te slaan naar de eigenlijke data. De tracks waarin deze eigenlijke data zich bevindt moeten door de RTP-server kunnen gelokaliseerd worden zodat die in beperkte mate op de hoogte moet zijn van het QuickTime bestandsformaat. Immers, om de hinttracks en de tracks met de eigenlijke data te kunnen vinden in een QuickTime movie moet de atoomstructuur van de betreffende movie doorwandeld worden. Dit kan uitgevoerd worden m.b.v. een aantal functies uit de QuickTime API. Bij de implementatie van de RTP-server of de overdracht van de server naar een ander platform is er wel voorzichtigheid geboden op het vlak van endian conversies aangezien data in een QuickTime movie doorgaans opgeslagen wordt in het big-endian formaat. Net zoals een effectspoor trackreferenties bevat naar de inputtracks, zo is dat ook het geval voor een hinttrack. Aan de trackheader zal er een track reference atoom (’tref’) toegevoegd worden dat als payload een kindatoom heeft met daarin de ID van de track die gehint wordt door het hintspoor. In principe is het dus ook mogelijk om met ´e´en hintspoor meerdere mediatracks te hinten. Merk op dat het voorlopig niet mogelijk is om, uitgaande van een mediaspoor, te bepalen welke hinttrack er gebruikt wordt. Er moet telkens in de andere richting gewerkt worden. Iedere track in een server movie wordt verzonden als een aparte RTP-stroom, en het recept om een mediastroom te pakketiseren ligt opgeslagen in een corresponderende hinttrack. Ieder sample in een hinttrack vertelt de RTP-server hoe het een bepaalde hoeveelheid mediadata moet opdelen in pakketten. Het bevat alle informatie om een pakketheader op te bouwen van het correcte type, en bevat eveneens een wijzer naar de data die thuishoort in het pakket. Een hinttrack kan een user data atoom bevatten dat op zijn beurt over een aantal atomen beschikt die informatie bevatten die specifiek is voor de track. Meer bepaald is er normaal gezien sprake van drie kindatomen: • Een atoom (’name’) dat de naam van de track bevat, zoals “Hinted sound track”. • Een hint track information atoom (’hinf’) met spoorstatistieken, zoals het aantal pakketten dat moet verstuurd worden, de grootte van de pakketten, en de gemiddelde bitsnelheid. • Een hint information atoom (’hnti’) dat SDP-data bevat voor de track. Dit atoom kan ook voorkomen op het niveau van de movie en bevat dan informatie die van toepassing is op alle tracks in een movie. De SDP-data zal ondergebracht zijn in een kindatoom van het type ’sdp ’. Merk op dat het vierde karakter een ASCII blanco karakter voorstelt (hex 20). De payload van dit atoom is bijvoorbeeld een string zoals “m=audio 0 RTP/AVP 96”. Deze tekst zal dan op de juiste plaats toegevoegd

108

worden aan een SDP-bestand, in overeenkomst met de regels zoals die vastgelegd werden in het RFC-document voor het Session Description Protocol. Samples in een hintspoor bevatten of verwijzen naar de data die via pakketten moet verstuurd worden. Door gebruik te maken van het track data reference atoom en het sample table atoom kan men de bestandsspecificatie en de byte-offset terugvinden voor ieder sample, zoals uitgelegd in het hoofdstuk over het QuickTime bestandsformaat. Het dataformaat van een sample in een hinttrack is vastgelegd via de sample beschrijving. Op het moment van schrijven wordt enkel het RTP-dataformaat ondersteund aangezien de streaming server nog volop in ontwikkeling is. Samples in een hinttrack zijn dus geen atomen: hun type kan gevonden worden in de sample beschrijving, en de grootte kan teruggevonden worden in de sample tabel. Zoals reeds gezien bevat de sample beschrijving ook een verwijzing naar een entry in de tabel die opgeslagen ligt in het data reference atoom. Wat betreft samples in een hintspoor kunnen we de volgende vaststellingen doen: • Ieder sample wordt gebruikt voor het genereren van ´e´en of meerdere RTP-pakketten. • Alle pakketten in een sample hebben dezelfde RTP-tijdsmarkering. • Iedere sample bevat een tabel, de packet table, met ´e´en entry per pakket dat moet verzonden worden. • Iedere entry in de packet table bevat een RTP-header en het sequentienummer voor een specifiek pakket, alsook een datatabel. Verder wordt er ook bijgehouden of het betreffende pakket al dan niet gebruikt wordt voor retransmissie (cfr. tekst) en of het pakket indien nodig mag genegeerd worden. • De datatabel bevat een entry voor ieder blok opeenvolgende data dat tot het pakket behoort. • Een pakket kan samengesteld worden aan de hand van meerdere datablokken. Zo zou een datatabel een entry kunnen bevatten voor een klein hoeveelheid data opgeslagen in de datatabel zelf, een tweede entry voor data die opgeslagen ligt in een ander sample in het hintspoor, en een derde entry die een verwijzing bevat naar data in een mediasample dat zich in het eigenlijke mediaspoor bevindt. Merk op dat hintsamples op dezelfde manier gelokaliseerd worden als de samples in een mediaspoor, namelijk door het data reference atoom en het sample table atoom te raadplegen. Merk ook op dat er niet noodzakelijk een ´e´en-op-´e´en correspondentie bestaat tussen pakketten en mediasamples. Een pakket kan meerdere mediasamples bevatten terwijl een groot mediasample kan opgebroken worden in verschillende pakketten. In het laatste geval zal de packet table meerdere entries bevatten.

109

Hoofdstuk 7 Interactiviteit QuickTime movies kunnen niet alleen afgespeeld worden - er kan eveneens mee gespeeld worden. Movies kunnen interageren met een gebruiker, een browser, een server en met elkaar. Op die manier kunnen ze gebruikt worden als een controlemiddel, een videospel, een puzzel, een muziekinstrument,. . . Hoe movies omspringen met dergelijke vormen van interactiveit wordt in dit hoofdstuk aangekaart.

7.1

Virtuele Realiteit

QuickTime VR is een mediatype dat gebruikers de mogelijkheid geeft fotorealistische, driedimensionele beelden te bekijken. Het resultaat noemt men ook wel eens immersive imaging, of beeldvorming waarbij de gebruiker als het ware ondergedompeld wordt in een andere wereld. VR movies zijn volledig interactief. Een gebruiker kan rondbewegen in een virtuele wereld en kan eveneens in- en uitzoomen op objecten. Iedere QuickTime VR movie bevat ´e´en scene, zijnde een collectie van ´e´en of meerdere knopen (nodes). QuickTime definieert twee soorten knopen: • Een objectknoop toont een voorwerp waarbij de gebruiker de mogelijkheid geboden wordt om het object vanuit verschillende hoeken te bekijken, hierbij al dan niet gebruik makend van een zoomfunctie. Men kijkt dus als het ware van buiten naar binnen. • Een panoramische knoop toont een omgeving waarbij een gebruiker als het ware van binnen naar buiten kijkt, hierbij al dan niet rondbewegend in de virtuele wereld. Een scene kan uit meerdere knopen van een verschillend type bestaan. Hierbij kan men bijvoorbeeld denken aan het interieur van een winkel. Een gebruiker kan navigeren van de ene afdeling naar de andere door middel van een aantal panoramische knopen.

110

Wanneer deze dan plotseling een interessant product ziet, kan hij/zij overschakelen naar een objectknoop om het voorwerp beter te kunnen bekijken. Wanneer een QuickTime VR movie meerdere knopen bevat, kan de gebruiker bewegen van de ene knoop naar de andere op voorwaarde dat de maker van de movie een link voorzien heeft tussen de verschillende knopen. Iedere link zal grafisch voorgesteld worden door middel van een hot spot, een deel van het moviegebied dat aan een gebruiker duidelijk maakt dat er interactie mogelijk is. Uiteraard is het ook mogelijk om code te schrijven waardoor de gebruiker automatisch van de ene knoop naar de andere beweegt.

7.1.1

Objectknopen

Data die gebruikt wordt voor de voorstelling van een object een QuickTime VR movie, wordt opgeslagen als een sequentie van afzonderlijke frames in een videotrack. Elk frame stelt hierbij een beeld voor van het voorwerp, bekeken vanuit een bepaalde hoek. Ook beelden die gebruikt worden voor het voorstellen van een hot spot, worden in een videotrack opgeslagen. De eigenlijke QuickTime VR track (’qtvr’) zal dan verwijzingen bevatten naar deze videosporen via track reference atomen.

+90°

180°

0°

-90°

Figuur 7.1: Een VR object kan vanuit verschillende hoeken bekeken worden. Een gebruiker heeft een zeer grote bewegingsvrijheid bij het bestuderen van een object: hij/zij kan 360 graden ronddraaien in een horizontaal vlak rond het voorwerp en kan daarbij eveneens een hoek maken met dit horizontaal vlak. De waarde van die hoek is begrepen tussen -90 graden (het voorwerp wordt van onderuit bekeken) en 90 graden (het

111

voorwerp wordt van bovenuit bekeken). Dit wordt ge¨ıllustreerd aan de hand van figuur 7.1. Het cre¨eren van de beelden, nodig bij de driedimensionele voorstelling van het object, kan gebeuren zoals beschreven wordt in hoofdstuk 17 van [Tow99]. Start vanaf een hoek van 0 graden in het horizontaal vlak en roteer 360 graden rond het voorwerp, m.a.w. maak een roteerbeweging rond het voorwerp in het horizontaal vlak. Gedurende deze rotatie kan er bijvoorbeeld om de 10 graden halt gehouden worden met de bedoeling een beeld vast te leggen van het voorwerp. Zo bekomen we 36 beelden. Vervolgens roteren we in een vlak dat een hoek maakt van 10 graden met het horizontaal vlak en waarbij we wederom om de 10 graden stoppen teneinde een beeld te kunnen maken van het voorwerp. Op die manier bekomen we 684 (36 * 19) afzonderlijke beelden. Deze worden opgeslagen als een ´e´endimensionale sequentie van frames in een videotrack waarvan het formaat begrepen wordt door de VR movie controller. Deze laatste zal gepast reageren op de reacties van de gebruiker en telkens het correcte frame opvragen aan de QuickTime VR media handler.

1,1

1,2

1,3

1,4

…

1,m

2,1

2,2

2,3

…

…

n,1

n,2

…

n,m

Figuur 7.2: Een sequentie van beelden horende bij een objectknoop (−90 ◦ ≤ n ≤ 90 ◦ , −180 ◦ ≤ m ≤ 180 ◦ ).

Ieder frame in de videotrack komt dus overeen met een bepaald standpunt van de gebruiker. Merk op dat het mogelijk is om per perspectief meerdere frames op te slaan. Hierdoor kan men voor een bepaald standpunt een beeldanimatie aanmaken. Dit maakt het bijvoorbeeld mogelijk een effect te bereiken zoals een brandende vlam, horende bij een virtuele kandelaar.

7.1.2

Panoramische knopen

De data die gebruikt wordt om een panorama voor te stellen, wordt in een QuickTime movie opgeslagen als een sequentie van individueel gecomprimeerde tegels, waarbij iedere tegel overeenkomt met een movie frame. Samen vormen deze tegels ´e´en enkel beeld. De tegelvorming is zeer goed merkbaar bij het inladen van een panorama via een trage netwerkverbinding. Een panorama wordt typisch bekomen door 360 graden rond te draaien en door om de zoveel graden een beeld vast te leggen van het landschap. Deze (overlappende) beelden worden dan door speciale software samengevoegd tot een cilindrische projectie van de werkelijkheid. Men spreekt van een horizontale of verticale cilinder naar-

112

gelang de gebruiker van een QuickTime VR movie van links naar rechts, of van boven naar onder kan kijken, en vice versa. Bij een kubisch panorama zijn beiden mogelijk.

7.2

Sprites en wired movies

Een sprite, of een “verschijning”, is een grafisch object dat eenmaal gedefinieerd wordt en dat dan geanimeerd wordt met behulp van speciale QuickTime routines. Sprites zullen doorgaans veel minder geheugen in beslag nemen dan andere animatietechnieken, juist omdat ze slechts eenmaal moeten gespecificeerd worden. Bijvoorbeeld, een klassieke animatie van een botsende bal zal doorgaans bestaan uit een sequentie van bitmaps die snel na elkaar afgespeeld worden om beweging te simuleren. Bij een sprite daarentegen zal er maar van ´e´en bitmap gebruik gemaakt worden, samen met een aantal kleine datastructuren die de locatie van de bal zullen beschrijven. Een QuickTime sprite is dus een alleenstaande geanimeerde afbeelding. Wanneer het scherm beschouwd wordt als een podium, dan kan men sprites vergelijken met acteurs die op een willekeurig moment kunnen opduiken en terug verdwijnen, rondbewegen of zelfs van vorm kunnen veranderen. Een sprite kan men dus ook bekijken als een compacte datastructuur die gekenmerkt wordt door een locatie op het scherm, een rotatie, een schaal, en een verwijzing naar een collectie afbeeldingen. Het is ook mogelijk om een sprite te laten reageren op bepaalde acties die al dan niet door een gebruiker veroorzaakt werden. Men spreekt dan van een wired sprite en het proces waarbij interactie toegevoegd wordt aan een sprite, en meer in het algemeen aan een movie, noemt men wiring. Wired sprites worden typisch gebruikt voor het plaatsen van knoppen bovenop het afspeelgebied van een movie. Een actie van een gebruiker kan dan bijvoorbeeld tot gevolg hebben dat een QuickTime event gegenereerd wordt, zoals het starten van een animatie. De event zal er doorgaans ook voor zorgen dat de afbeeldingsindex van een sprite veranderd wordt waardoor er een afbeelding vertoond wordt van een ingedrukte knop. Op die manier is het mogelijk om een eigen interface toe te voegen aan een QuickTime movie. Via Atomic Player kan een eenvoudige wired movie aangemaakt worden. De interactiviteit bestaat uit een hot spot waarop de gebruiker kan klikken. Wanneer dit gebeurt, opent QuickTime de standaard browserapplicatie van de gebruiker en wordt deze naar een bepaalde website gedirigeerd. Dit is bijvoorbeeld interessant in het geval dat de movie een commercieel product promoot. Indien de gebruiker ge¨ınteresseerd is in het voorwerp kan deze via een eenvoudige klik met de muis overschakelen naar een webstek waar meer informatie te vinden is, zoals een online winkel. Dit alles wordt gerealiseerd door aan de movie een teksttrack toe te voegen met daarin een uitgebreide versie van een gewoon tekstsample. Een normaal tekstsample bestaat uit een 16-bits lengtewoord, gevolgd door de tekst die bij het sample hoort. Optioneel kunnen er echter ook nog ´e´en of meerdere atomen aan toegevoegd worden (text atom extensions).

113

Deze extra atomen zijn klassieke atomen: een 32-bits lengteveld, gevolgd door een 32bits typeveld, gevolgd door de data in het atoom. Deze data moet opgeslagen worden in big-endian formaat. Het eigenlijke tekstsample bevat de beschrijving van de website. Deze informatie zal via de hot spot aan de gebruiker getoond worden. Aan de beschrijving wordt er een klassiek atoom toegevoegd dat als payload een QT atoomcontainer heeft. In deze container wordt er informatie bewaard over het gedeelte van de beschrijving dat aanklikbaar is voor de gebruiker, m.a.w. de defini¨ering van een hyperlink, en op welke actie er moet gereageerd worden, samen met een bijhorende actieparameter. In deze context bestaat de actie uit het klikken met de muis en is de actieparameter de URL van de website die moet bezocht worden. De zojuist beschreven procedure staat ook bekend als het toevoegen van een HREFtrack aan een QuickTime movie. In het geval van Atomic Player wordt er gewerkt met een HREF-track die gebruik maakt van een hot spot waarop een gebruiker moet klikken, m.a.w. een interactieve HREF-track. Verder heeft men ook nog automatische HREFtracks. Deze roepen een webbrowser op bij het openen van een movie of bij het verstrijken van een bepaald tijdstip, en dit zonder tussenkomst van een gebruiker.

7.3

AppleScript

AppleScript is een taal die heel sterke overeenkomsten vertoont met het Engels en die gebruikers de mogelijkheid biedt om scripts te schrijven. Deze kunnen aangewend worden om de acties van een computersysteem of een toepassing te controleren. Scripts zijn vooral handig om veel voorkomende taken te automatiseren. Denk hierbij aan het herbenoemen van 75 bestanden in een directory zodat ze allemaal eindigen op de extensie TIFF. Het als gebruiker zelf moeten uitvoeren van dergelijke repetitieve bewerkingen kan heel frustrerend zijn. Om taken tot een goed einde te brengen, wisselen het besturingssysteem en applicaties voortdurend boodschappen met elkaar uit. Sommige van deze boodschappen zijn instructies, andere worden bijvoorbeeld enkel gebruikt voor het uitwisselen van informatie. Opdrachten die vastgelegd zijn in een AppleScript worden ingelezen door het besturingssysteem en vertaald naar boodschappen. Vervolgens worden deze naar applicaties verstuurd zodat die de opgegeven taken kunnen realiseren. Scripts kunnen ook gebruikt worden in combinatie met QuickTime. Men kan hierbij denken aan een droplet1 dat in staat is om een moviebestand te plaatsen op een andere computer via TCP/IP en dat de QuickTime mediaspeler op die computer vervolgens 1

Een droplet is een script dat uitgevoerd wordt wanneer een bestand of een folder bovenop het icoon van het script losgelaten wordt. Een applet daarentegen is een script dat uitgevoerd wordt door op het betreffende icoon te dubbelklikken.

114

de opdracht heeft de betreffende movie af te spelen. Een ander script kan bijvoorbeeld gebruikt worden om alle passieve tracks in een movie te verwijderen.

7.4

SMIL

SMIL staat voor Synchronized Multimedia Integration Language. Het is een standaard die gedefinieerd werd door het World Wide Web Consortium of het W3C en die gebruikt wordt voor het beschrijven van multimediapresentaties (zie ook [W3Cb]). De QuickTime mediaspeler en Atomic Player kunnen eenvoudige SMIL-presentaties weergeven. SMIL op zich is eigenlijk niet zo goed in interactiviteit maar het is wel een goede illustratie van het movie-in-movie concept. Bovendien kunnen er in een SMIL-presentatie wired movies opgenomen worden zodat het toch nog een zekere interactiviteit ondersteunt met een gebruiker. Een SMIL-presentatie vertoont grote overeenkomsten met een QuickTime movie; het is eveneens mogelijk om computerdata zoals afbeeldingen, tekst, audio, en video te presenteren in de tijd. SMIL-presentaties worden beschreven aan de hand van een SMILdocument, een tekstbestand dat specificeert welke mediaelementen moeten gepresenteerd worden, en waar en wanneer deze moeten gepresenteerd worden. Alles wat tekst kan genereren (AppleScript, Perl, CGI,. . . ), kan dus ook een SMIL-document aanmaken. Mediaelementen in een SMIL-document worden gespecificeerd met behulp van een URL. Dit kunnen zowel bestanden zijn - zoals tekstbestanden, JPEG-afbeeldingen, enzoverder - als live streams. De URLs die de mediaelementen specificeren kunnen gebruik maken van protocollen zoals HTTP, FTP, RTSP, FILE,. . . Wanneer een SMIL-document in QuickTime ge¨ımporteerd wordt, worden de gerefereerde mediaelementen omgezet naar QuickTime movietracks (’moov’), en het SMILdocument beschrijft hoe deze tracks moeten vertoond worden in tijd en ruimte. Movietracks zijn gelijkaardig aan tekstsporen, videosporen, of audiotracks. Ze worden echter gekenmerkt door een eigen tijdsbasis waardoor ze - onafhankelijk van de tijdsbasis van de movie die ze bevat - vooruit, achteruit of herhaald kunnen afgespeeld worden. Het zijn in feite movies die vervat zijn in een movie. Een voorwaarde opdat QuickTime een SMIL-presentatie zou kunnen verzorgen, is uiteraard dat de mediaelementen door QuickTime moeten kunnen afgespeeld worden. Verder is het ook zo dat QuickTime op het moment van schrijven de volledige SMILspecificatie nog niet ondersteunt. Wel voegt QuickTime een aantal eigen uitbreidingen toe aan de SMIL-standaard. Men kan hierbij denken aan een element dat ervoor zorgt dat een SMIL-presentatie automatisch afgespeeld wordt bij het openen van een SMILdocument of aan een element dat een volgende presentatie selecteert indien de huidige presentatie afgelopen is. In [Inc01c] wordt dit in meer detail beschreven. Zoals reeds gezegd cre¨eert de SMIL-importcomponent een movietrack voor iedere mediaelement in de SMIL-compositie. Door gebruik te maken van dit nieuw tracktype hoeft

115

de SMIL-importer het type van het mediaelement niet op voorhand te weten. Het maakt gewoon een nieuwe movietrack aan voor ieder mediaelement waarna dit spoor, op het moment dat het element moet afgespeeld worden, gebruik maakt van QuickTime’s uitgebreide importfaciliteiten. Dit nieuw tracktype wordt ge¨ımplementeerd door middel van een uiterst geavanceerde media handler. QuickTime zal standaard de toegang tot de mediadata zolang mogelijk proberen uitstellen. Wanneer alle mediaelementen immers in het begin van de presentatie gedowload worden, kan dit aanleiding geven tot grote wachttijden. Bovendien is dit niet altijd mogelijk, denk hierbij maar aan stroming. Dit is ook niet zinvol wanneer een gebruiker halverwege de presentatie plotseling beslist om deze te stoppen. De SMIL-importer cre¨eert ook altijd een videotrack die gebruikt wordt voor de voorstelling van het root-layout element. Hieronder ziet u een listing van een SMIL-document dat twee QuickTime movies aan een gebruiker presenteert. Bij het importeren van dit document worden er door de SMIL-importer 7 sporen aangemaakt: 6 moviesporen die corresponderen met de 6 mediaelementen in het document en 1 videospoor dat het root-layout element voorstelt en gedurende de ganse presentatie vertoond wordt, al dan niet bedekt door de andere tracks. <smil xmlns:qt=“http://www.apple.com/quicktime/resources/smilextensions” qt:autoplay=“true” qt:timeslider=“true”> <seq>
116

src=“data:text/plain, QuickTime en SMIL” /> <seq> <par>