praktische studie van vrml, x3d en mpeg-4...
TRANSCRIPT
Faculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Praktische Studie en Analyse
van VRML, X3D en MPEG-4
Systems
door Bart Mollet
Promotor: prof. dr. ir. R. Van de WalleThesisbegeleider: lic. W. De Neve
Afstudeerwerk ingediend tot het behalen van de academische graad vanLicentiaat in de Informatica
Academiejaar 2003–2004
Dankwoord
In de eerste plaats wens ik mijn thesisbegeleider Wesley De Neve te bedanken voor devele ideeen en aanvullingen die hij me gaf voor de demo’s bij deze thesis. Verder bedankik hem ook voor het nalezen van deze tekst en de verbeteringen die hij voorstelde bij depresentaties die ik over deze thesis maakte. Ook wil ik iedereen van het Multimedia Lab,waaronder mijn promotor prof. dr. ir. Rik Van de Walle, bedanken voor de kritischeopmerkingen bij de presentaties. Verder wil ik ook Jean Le Feuvre bedanken voor deantwoorden die hij gaf op mijn vragen over BIFS en de software van zijn GPAC-project.
De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen endelen van de scriptie te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onderde beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichtingde bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.
1 juni 2004
i
Praktische Studie en Analye
van VRML, X3D en MPEG-4 Systems
doorBart Mollet
Afstudeerwerk ingediend tot het behalen van de academische graad van Licentiaat in deInformatica
Academiejaar 2003–2004
Universiteit GentFaculteit Toegepaste WetenschappenVakgroep Elektronica en InformatiesystemenVoorzitter: prof. dr. ir. J. Van Campenhout
Promotor: prof. dr. ir. R. Van de WalleThesisbegeleider: lic. W. De Neve
Samenvatting
Multimediapresentaties kunnen beschouwd worden als een schikking in ruimte en tijdvan audiovisuele elementen. Video, audio, afbeeldingen en tekst zijn voorbeelden vandergelijke elementen. Deze presentaties zijn echter niet meer beperkt tot het louter
”pre-
senteren” van die verschillende elementen. Interactiviteit vormt een niet te onderschattenmeerwaarde. Naast een bespreking en vergelijking van enkele open formaten (VRML,X3D, BIFS en XMT) voor het opstellen van dergelijke interactieve audiovisuele presen-taties, worden in deze thesis ook enkele praktische applicaties besproken.
Trefwoorden: VRML, hierarchische scenebeschrijving, scenegraaf, multimediapresenta-tie, X3D, BIFS, MPEG-4, XMT-A, XMT-Ω
ii
Inhoudsopgave
1 Inleiding 1
2 VRML - Virtual Reality Modeling Language 3
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Algemeen overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Scenebeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Gebeurtenissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Hergebruik van code . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Bestandsformaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Software voor creatie en weergave van een VRML-wereld . . . . . . 10
2.3 Interactiviteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Navigeren door een VRML-wereld . . . . . . . . . . . . . . . . . . . 10
2.3.2 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Animatie via interpolatorknopen . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Externe mediabronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Tekortkomingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 X3D - eXtensible 3D 18
3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Algemeen overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Bestandsformaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Uitbreidingen en verschillen t.o.v. VRML . . . . . . . . . . . . . . . . . . . 21
3.3.1 Componenten en profielen . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Grafische uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Snellere weergave van de scene . . . . . . . . . . . . . . . . . . . . . 23
3.3.4 Interactiviteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
iii
3.3.5 Externe mediabronnen . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 BIFS - Binary Format for Scene Description 25
4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Doelstellingen van MPEG-4 Systems . . . . . . . . . . . . . . . . . . . . . 27
4.3 Scenebeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Knoop-types in de scenegraaf . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 Numerieke referenties naar knopen en velden . . . . . . . . . . . . . 28
4.3.3 Gebruik van externe mediabronnen . . . . . . . . . . . . . . . . . . 29
4.3.4 Geavanceerdere layout-mogelijkheden . . . . . . . . . . . . . . . . . 29
4.3.5 Interactie met mediastromen . . . . . . . . . . . . . . . . . . . . . . 30
4.3.6 Dynamisch wijzigen van de scene . . . . . . . . . . . . . . . . . . . 30
4.3.7 Gebruikersinteractie . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.8 Interactie met de server . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.9 MPEG-J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.10 Verdere uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Het Object Descriptor raamwerk . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Object Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Elementary Stream Descriptor . . . . . . . . . . . . . . . . . . . . . 33
4.5 BIFS-Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 BIFS-Anim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Bestandsformaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7.1 Contextafhankelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.2 Kwantisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Stroming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 XMT - Extensible MPEG-4 Textual Format 40
5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Algemeen overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 XMT-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1 Bestandsformaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.2 Binaire versus tekstuele representatie . . . . . . . . . . . . . . . . . 41
5.4 XMT-Ω . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Tijdsmodel en synchronisatie . . . . . . . . . . . . . . . . . . . . . 45
5.4.2 Gebeurtenissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.3 Animatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4.4 Een uitgewerkt voorbeeld . . . . . . . . . . . . . . . . . . . . . . . 46
iv
6 Samenvattend overzicht 48
7 Een trailer-mozaıek in MPEG-4 50
7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3 Gebruikte software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.4 Scenebeschrijving van de gebruikersinterface . . . . . . . . . . . . . . . . . 52
7.4.1 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4.2 Layout van de verschillende objecten . . . . . . . . . . . . . . . . . 54
7.4.3 Wisselen van scherm . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.4.4 Weergeven van de trailers . . . . . . . . . . . . . . . . . . . . . . . 55
7.4.5 Een script als controle-orgaan . . . . . . . . . . . . . . . . . . . . . 55
7.5 Voordelen, nadelen en mogelijke uitbreidingen . . . . . . . . . . . . . . . . 57
8 Een mediaspeler in MPEG-4 58
8.1 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.2 Gebruikte software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.3 Scenebeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.1 Synchronisatie van de verschillende stromen . . . . . . . . . . . . . 59
8.3.2 Aansturen van mediastromen . . . . . . . . . . . . . . . . . . . . . 60
8.3.3 Ondertiteling via een animatiestroom . . . . . . . . . . . . . . . . . 62
8.3.4 Wisselen van audio, video en ondertiteling . . . . . . . . . . . . . . 63
8.3.5 Sceneselectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.4 Scenebrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.4.1 Het keuzemenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4.2 Verplaatsen van de taakbalk . . . . . . . . . . . . . . . . . . . . . . 66
8.4.3 Java-implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9 Besluit 69
A Inhoud bijgevoegde CD-ROM 70
A.1 VRML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2 X3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.2.1 filmzaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.2.2 kamer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.3 MPEG-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B Een overzicht van het GPAC-project 74
v
Bibliografie 76
Lijst van figuren 78
Lijst van tabellen 80
vi
Lijst van gebruikte afkortingen
ASCII American Standard Code for Information InterchangeAVI Audio Video InterleavedBIFS Binary Format for Scene DescriptionCML Chemical Markup LanguageDRM Digital Rights ManagementEAI External Authoring InterfaceES Elementary StreamESD Elementary Stream DescriptorH-Anim Humanoid AnimationIEC International Electrotechnical CommissionIOD Initial Object DescriptorIPI Intellectual Property IdentificationIPMP Intellectual Property Management and ProtectionISO International Organization for StandardizationJPEG Joint Photographic Experts GroupMIDI Musical Instrument Digital InterfaceMPEG Moving Picture Expert GroupNCT Node Coding TableNDT Node Data TypeNURBS Non-uniform Rational B-SplinesOCI Object Content InformationOCR Object Clock ReferenceOD Object DescriptorPNG Portable Network GraphicsQP Quantization ParameterRTSP Real Time Streaming ProtocolSL Sync LayerSMIL Synchronized Multimedia Integration LanguageSVG Scalable Vector GraphicsURL Uniform Resource LocatorVRML Virtual Reality Modeling LanguageWAV Waveform Audio File FormatX3D Extensible 3DXML Extensible Markup LanguageXMT Extensible MPEG-4 Textual FormatXSL Extensible Stylesheet LanguageXSLT Extensible Stylesheet Language Transformations
vii
Hoofdstuk 1
Inleiding
Een multimediapresentatie wordt typisch opgebouwd uit verschillende elementen. Er kan
gebruikgemaakt worden van audio, video, tweedimensionale of driedimensionale afbeel-
dingen, tekst,. . . Om de beoogde presentatie te bekomen moeten deze elementen in ruimte
georganiseerd worden. De ondertitels bij een film moeten bijvoorbeeld onderaan het beeld
komen. Niet enkel in de ruimte maar ook in de tijd moeten de verschillende elementen
georganiseerd worden. De ondertitels van daarnet moeten niet enkel op de juiste plaats,
maar ook op het juiste moment verschijnen.
Enkel een ordening in ruimte en tijd levert misschien wel een aantrekkelijke presentatie,
maar de opmaaktalen die in deze thesis besproken worden bieden meer. Via verschillen-
de mechanismen kan immers ook interactiviteit toegevoegd worden aan de multimedia-
presentaties. Een goede film bekijken is leuk, maar het wordt pas echt aantrekkelijk
wanneer we tijdens de film op het hoofd van onze favoriete acteur kunnen klikken om de
laatste roddels over hem te lezen. Uiteraard wordt de film dan even onderbroken zodat
we niks hoeven te missen. Interessante mogelijkheden waar de hier besproken opmaak-
talen misschien een oplossing voor kunnen bieden. En waarom zouden we het bij twee
dimensies houden? De film zouden we dan kunnen bekijken in een virtueel cinemacomplex
(figuur 1.1) waarbij we uiteraard eerst even langs de kassa gaan om met onze creditcard
een ticketje te kopen.
In hoofdstuk 2 wordt een overzicht gegeven van VRML (Virtual Reality Modeling
Language). Aan de hand van deze opmaaktaal wordt ook de definitie van een scenegraaf
ingevoerd, een datastructuur die de basis vormt van alle besproken opmaaktalen. Het vol-
gende hoofdstuk (hoofdstuk 3) handelt over X3D (eXtensible 3D), de opvolger van VRML.
In hoofdstuk 4 wordt dieper ingegaan op BIFS (Binary Format for Scene Description).
Deze scenebeschrijvingstaal is een deel van de recente MPEG-4-standaard. In hoofdstuk
5 bespreken we tenslotte XMT (Extensible MPEG-4 Textual Format). Deze opmaaktaal
vormt een XML-gebaseerd equivalent voor het binaire BIFS. Na een algemeen overzicht
van de besproken opmaaktalen in hoofdstuk 6 volgen nog 2 hoofdstukken waarin ingegaan
1
Figuur 1.1: Een virtueel cinemabezoek
wordt op enkele concrete MPEG-4-applicaties. Als bijlage bij deze thesis is een cd-rom
voorzien waarvan de inhoud in appendix A besproken wordt.
2
Hoofdstuk 2
VRML - Virtual Reality Modeling
Language
2.1 Inleiding
In dit hoofdstuk worden de mogelijkheden van VRML besproken. Het is niet de bedoeling
om in dit eindwerk een cursus VRML aan te bieden. De geınteresseerde lezer kan hiervoor
terecht bij de specificaties van de internationale standaard ([3],[1]) en hoofdstuk 2 van [21].
Op het Internet zijn ook heel wat handleidingen te vinden waar VRML aan de hand van
praktische voorbeelden beschreven wordt (o.a. [11] en [9]).
Na een definiering van de VRML-standaard, worden in dit hoofdstuk eerst kort de con-
cepten beschreven die aan de basis liggen van deze scenebeschrijvingstaal (scenegraaf, kno-
pen, routes, sensors, events,. . . ). Nadien wordt een overzicht gegeven van het bestands-
formaat en de nodige software voor het aanmaken en bekijken van VRML-bestanden. In
de bespreking die daarna volgt zullen enkele interessante kenmerken besproken worden
die een aanzet geven tot een vergelijking met andere recentere scenebeschrijvingstalen zo-
als X3D (eXtensible 3D), XMT (eXtensible MPEG-4 Textual Format) en BIFS (Binary
Format for Scene Description), die in volgende hoofdstukken behandeld worden.
2.2 Algemeen overzicht
VRML is een internationale standaard voor het beschrijven van interactieve 3D-scenes.
Zo’n scene wordt in de context van VRML vaak ‘wereld’ genoemd. Deze scenebeschrij-
vingstaal werd ontwikkeld en onderhouden door het Web3D Consortium met als voor-
naamste doel gebruik op het Internet. VRML werd gestandariseerd door ISO/IEC [3]. In
deze thesis bespreken we VRML97. Deze versie van VRML ligt immers aan de basis van
3
MPEG-4 BIFS. Een meer recente versie van VRML, namelijk VRML2000 is compatibel
met de X3D standaard die in het volgend hoofdstuk besproken wordt.
De criteria die bij het ontwikkelen van VRML voorop gesteld werden zijn:
• Ontwikkeling van software die in staat is om VRML-bestanden te creeren en te
wijzigen. Tevens moet voorzien worden in programma’s om andere vaak gebruikte
bestandsformaten voor 3D om te zetten in VRML-scenes.
• De mogelijkheid voorzien om dynamische 3D-objecten te gebruiken en te combineren
en op die manier herbruikbaarheid toe te laten.
• De mogelijkheid voorzien voor auteurs om zelf nieuwe types objecten te definieren
die niet expliciet voorzien zijn in VRML.
• Implementatie van de standaard moet mogelijk zijn op verschillende types systemen.
• Arbitrair grote 3D-werelden toelaten.
In de specificatie van VRML wordt dus niet enkel aangegeven hoe 3D-objecten gede-
finieerd moeten worden. Er worden ook heel wat voorzieningen getroffen die de auteur
van een 3D-wereld toelaten om meer geavanceerde kenmerken zoals bijvoorbeeld interac-
tiviteit, (geanimeerde) texturen en geluiden toe te voegen aan die wereld.
2.2.1 Scenebeschrijving
De manier waarop de 3D-wereld beschreven wordt in VRML ligt aan de basis van de
scenebeschrijving in de andere opmaaktalen die in deze thesis besproken worden. De
concepten die hier ingevoerd worden zullen dan ook in volgende hoofdstukken opnieuw
opduiken.
De scenegraaf
Een 3D-scene wordt in VRML beschreven aan de hand van een scenegraaf. Deze data-
structuur bevat de beschrijving van alle objecten in de 3D-wereld en hun onderlinge rela-
ties. De scenegraaf is een gerichte acyclische graaf. Het gebruik van deze datastructuur
voor het beschrijven van 3D-werelden laat de VRML-auteur toe de scenes te beschrijven
op een hoog abstractieniveau. Men hoeft zich geen zorgen te maken om de details van het
renderen van de scene. De auteur van de scene beschrijft wat er moet gerenderd worden,
niet hoe. In figuur 2.1 wordt een eenvoudige scenegraaf weergegeven van een model van
een marsrobot 1. De robot wordt opgedeeld in verschillende eenvoudigere objecten. Deze
1zie http://mars.sgi.com/worlds/sojourner/annotated rover.html
4
Figuur 2.1: Een vereenvoudigde scenegraaf
Cone
field SFFloat bottomRadius 1 # (0, infinity)
field SFFloat height 2 # (0, infinity)
field SFBool side TRUE
field SFBool bottom TRUE
Figuur 2.2: Specificatie van een kegel
kunnen op hun beurt opnieuw opgesplitst worden. Deze decompositie wordt verder door-
gevoerd tot het niveau van de elementaire vormen die in VRML voorzien zijn (kubussen,
balken, kegels, . . . ).
Knopen
De knopen waaruit de scenegraaf is opgebouwd worden niet enkel gebruikt om de elemen-
taire bouwstenen van de 3D-wereld te beschrijven, maar ook om hun onderlinge relaties,
hun posities in de ruimte en hun gedrag te bepalen. Een Transform-knoop kan kan bij-
voorbeeld gebruikt worden om een translatie te beschrijven die van toepassing is op alle
kinderen van die knoop in de scenegraaf. In de VRML-standaard is een uitgebreid gamma
aan knopen voorzien, maar het staat een VRML-auteur vrij om zelf nieuwe knopen te
definieren om zo nieuwe vormen en functionaliteiten toe te voegen.
Elke knoop in VRML heeft een naam die begint met een hoofdletter. Voorbeelden
zijn Shape, Cone, Point, Group. Elke knoop heeft een of meerdere velden waarvan de
waarden het uitzicht en gedrag van het object beschrijven. Figuur 2.2 uit de specificatie
van VRML geeft bijvoorbeeld de verschillende velden van een kegel.
5
Velden
Elk veld in een knoop is van een bepaald type. Mogelijke types zijn
eventIn: Gebeurtenis die ontvangen wordt door de knoop. Andere knopen kunnen de
waarde van dit veld wijzigen.
eventOut: Gebeurtenis die uitgezonden wordt door de knoop. Andere knopen kunnen
deze gebeurtenis ontvangen maar niet wijzigen.
exposedField: veld dat zowel ontvangen als gewijzigd kan worden door andere knopen.
field: Veld dat niet zichtbaar is voor andere knopen.
Zoals uit figuur 2.2 ook blijkt heeft elk veld van een knoop een bepaald datatype
(SFFloat, SFBool, SFTime, MFFloat,. . . )2, een naam (bottomRadius, height,. . . ) en een
default-waarde (wanneer deze default-waarde volstaat, hoeft het veld niet opgenomen te
worden in de scenebeschrijving). In de specificatie van VRML wordt indien nodig ook
aangegeven wat de toegelaten waarden van een veld zijn.
Velden met als datatype SFNode of MFNode verwachten als waarde een of meerdere kno-
pen. Op die manier wordt de hierarchische structuur verkregen waarvan sprake. Wanneer
een knoop als veldwaarde een lijst van knopen verwacht, spreekt men van groeperings-
knopen. Een groeperingsknoop definieert een lokaal coordinatenstelsel voor zijn kinderen
in de scenegraaf, relatief ten opzichte van het stelsel bepaald door de ouderknoop van de
groeperingsknoop.
2.2.2 Gebeurtenissen
Om te begrijpen hoe in VRML animatie en interactiviteit kan verkregen worden zullen
we hier nog 2 belangrijke concepten bespreken, namelijk gebeurtenissen (events genoemd
in VRML) en de afhandeling ervan via zogenaamde routes.
Events
Zoals eerder vermeld wordt het uitzicht en gedrag van de verschillende objecten in een
VRML wereld beschreven door gepaste waarden aan de verschillende velden van de knopen
in een scenegraaf toe te kennen. Events bieden een manier om deze waarden dynamisch te
wijzigen. Van zodra de waarde van een veld gewijzigd wordt, wijzigt ook het overeenkom-
stige gedrag van het object. De eventIn-velden worden gebruikt om events op te vangen,
2De voorvoegsels SF en MF betekenen respectievelijk dat de opgegeven waarde enkelvoudig of meer-voudig moet zijn
6
DEF Muis TouchSensor
DEF Klok TimeSensor cycleInterval 3.0
ROUTE Muis.touchTime TO Klok.startTime
Figuur 2.3: Definiering van een route
terwijl eventOut-velden events kunnen uitzenden (exposedField-velden zijn tot beide in
staat). Hoewel veel knopen de events rechtstreeks afhandelen via hun eventIn velden,
komt het in praktische voorbeelden vaker voor dat een object gewijzigd wordt door zijn
ouder in de scenegraaf.
Routes
Om effect te hebben wordt een eventOut-veld van een knoop via een route verbonden met
een eventIn-veld van een tweede knoop. Uiteraard moeten beide velden van hetzelfde
datatype zijn. Routes kunnen dus beschouwd worden als de link tussen gebeurtenisge-
nererende knopen en gebeurtenisontvangende knopen. In het codefragment in figuur 2.3
wordt bijvoorbeeld een route tussen een TouchSensor en een TimeSensor gedefinieerd.
Merk op dat het DEF-commando toelaat een naam toe te kennen aan een knoop in de
scenegraaf (zie paragraaf 2.2.3). Op het moment dat de gebruiker met de muis klikt op
dat deel van de 3D-wereld waaraan de TouchSensor gehecht is, wijzigt de waarde van
het touchTime-veld (eventOut) van deze TouchSensor. Deze wijziging heeft als gevolg
dat de gedefinieerde route actief wordt en het startTime-veld (exposedField) van de
TimeSensor wijzigt. Op dat moment zal deze TimeSensor gestart worden. De velden
van deze ”klok”kunnen dan, zoals later zal blijken, gebruikt worden om bijvoorbeeld een
animatie aan te sturen.
Typisch is er meer dan een route nodig om het gewenste effect te bereiken. Stel dat
we een deur willen openen als de gebruiker er op klikt met de muis. Het klikken op de
deur zal als effect hebben dat een TimeSensor gestart wordt. Deze TimeSensor zal op
zijn beurt een OrientationInterpolator (zie paragraaf 2.4) aansturen. Die laatste zal
dan de gepaste rotatie doorgeven aan de Transform-knoop die de deur zal roteren en dus
openen.
Een eventOut-veld kan via verschillende routes ook aan verschillende eventIn-velden
gekoppeld worden (men spreekt dan van fan-out). Een schakelaar kan bijvoorbeeld ge-
bruikt worden voor het aan- en uitzetten van verschillende lampen in een kamer. Ook kan
een eventIn-veld aan verschillende eventOut-velden gekoppeld zijn (fan-in). Een lamp
kan zo bijvoorbeeld door verschillende schakelaars aan- of uitgezet worden.
7
Shape
appearance DEF Uitzicht Appearance
material Material...
geometry Cone...
Shape
appearance USE Uitzicht
geometry Sphere...
Figuur 2.4: Gebruik van DEF en USE
2.2.3 Hergebruik van code
In VRML zijn enkele voorzieningen getroffen voor het hergebruik van code.
Het DEF-commando
Met behulp van het DEF-commando kan aan een bepaalde knoop in de scenegraaf een
naam worden toegekend. Deze naam kan dan later in de code gebruikt worden om te
verwijzen naar die knoop, bijvoorbeeld bij het definieren van een route (figuur 2.3). Het
USE-commando laat toe een verwijzing op te nemen in de scenegraaf om een knoop te
hergebruiken. In het codefragment van figuur 2.4 wordt aan het uitzicht (kleur, textuur,
...) van de kegel (Cone) een naam toegekend. Deze naam wordt dan met het USE-
commando gebruikt om het uitzicht van de bol te bepalen. Wijzigingen die gemaakt
worden aan deze knoop zullen merkbaar zijn in zowel de kegel als de bol, zodat beiden
op elk moment hetzelfde uitzicht hebben.
Prototypes
Zoals in paragraaf 2.2 reeds aangehaald, is het mogelijk om in VRML zelf nieuwe knopen
te definieren. Dit kan met behulp van prototypes. Deze prototypes kunnen samen met
de scenebeschrijving in een VRML bestand staan (met behulp van het PROTO-commando)
of ze kunnen ook in afzonderlijke bestanden gedefinieerd worden (met behulp van het
EXTERNPROTO-commando). Een binnenhuisarchitect die zijn klanten 3D-modellen van het
ontwerp wil tonen kan bijvoorbeeld gebruikmaken van een bibliotheek met prototypes van
meubelen om zijn modellen op te bouwen. Net als bij de in de standaard voorziene knopen
kunnen bij prototypes ook velden voorzien worden die het gedrag en het uitzicht van het
object bepalen. Bij een prototype voor een tafel kunnen bijvoorbeeld velden voorzien
worden die de oppervlakte, de hoogte en de kleur van de tafel bepalen.
8
#VRML V2.0 utf8
Shape
geometry Box
size 2 8 4 # Balk van 2m x 8m x 4m
appearance Appearance
material Material
diffuseColor 1 0 0 # rode kleur
Figuur 2.5: VRML-code voor een rode balk
2.2.4 Bestandsformaat
Om een idee te hebben van de wijze waarop scenes in VRML beschreven worden en om
later een vergelijking te kunnen maken met de bestandsformaten van andere opmaaktalen,
wordt in deze paragraaf een beknopt overzicht gegeven van het gebruikte bestandsformaat
in VRML.
Eenvoudige ASCII-tekstbestanden worden gebruikt om een scenegraaf te definieren.
Hoewel een VRML-bestand een beschrijving kan bevatten van een enkel object, bevatten
de meeste VRML-bestanden een beschrijving van volledige werelden die bestaan uit een
grote verzameling verschillende objecten. Het codefragment uit figuur 2.5 beschrijft een
rode balk van 2m op 8m op 4m (afmetingen in VRML worden in meter opgegeven).
Een VRML-bestand start steeds met dezelfde regel. Hierbij geeft het eerste deel
(#VRML V2.0) aan dat het bestand code bevat die voldoet aan de tweede versie van de
VRML beschrijvingstaal. Het tweede deel geeft de gebruikte encodering aan. VRML
gebruikt de UTF-8 internationale standaard. Er werd voor deze standaard gekozen omdat
een breed gamma aan talen en speciale karakters ondersteund wordt. Hierdoor kunnen
auteurs code schrijven in hun eigen taal.
De rest van het bestand bestaat uit een tekstuele beschrijving van de 3D-objecten.
Hierbij wordt het uitzicht en het gedrag van de knopen in de scenegraaf gedefinieerd.
De extensie van deze bestanden is .wrl, een afkorting voor ‘world’. Andere extensies
zijn evenwel ook gebruikelijk wanneer de scenebeschrijving gecomprimeerd werd met de
GZIP-tool3. Gecomprimeerde VRML-bestanden zijn tot twee derden kleiner dan de over-
eenkomstige beschrijving in ASCII-formaat. De extensies die gebruikt worden voor deze
gecomprimeerde versies zijn .wz en .wrz. Sommige oudere VRML-browsers hebben moei-
lijkheden met deze extensies, zodat ook vaak .wrl gebruikt wordt voor de gecomprimeerde
versie van de scenebeschrijving.
3zie http://www.gzip.org/
9
2.2.5 Software voor creatie en weergave van een VRML-wereld
Uit voorgaande paragraaf is duidelijk dat een auteur in principe niks meer dan een tekst-
editor nodig heeft om VRML-scene aan te maken. Er bestaan evenwel verschillende com-
puterprogramma’s die een grafische interface aanbieden voor het aanmaken van VRML-
bestanden. Bij vele geavanceerde 3D-pakketten kan ook geexporteerd worden naar een
VRML-bestand.
VRML-werelden kunnen bekeken worden met behulp van zogenaamde VRML-brow-
sers. Deze applicaties interpreteren de scenegraaf zoals die beschreven staat in een VRML-
bestand en tonen de overeenkomstige 3D-wereld aan de gebruiker. VRML-browsers kun-
nen alleenstaande applicaties zijn of kunnen als plugin voorzien zijn in een internetbrowser.
Op het Internet zijn verschillende gratis VRML-browsers te vinden. Voor deze thesis werd
vooral gebruik gemaakt van BS Contact VRML4.
Een overzicht van applicaties voor het aanmaken en bekijken van VRML-bestanden is
beschikbaar op de website van het Web3D Consortium [1].
2.3 Interactiviteit
2.3.1 Navigeren door een VRML-wereld
Een VRML-browser moet niet enkel in staat zijn om de scenebeschrijving te interpreteren
en weer te geven op het scherm. Deze applicaties moeten tevens in staat zijn de gebruiker
doorheen de VRML-wereld te laten navigeren. Een gebruiker wordt in de wereld voorge-
steld door een zogenaamde avatar. Met behulp van invoerapparaten zoals muis, joystick
en toetsenbord kan de gebruiker zijn avatar doorheen de wereld laten lopen (figuur 2.6).
Figuur 2.6: Met behulp van een avatar kan de gebruiker door een VRML-wereld navigeren.
4zie http://www.bitmanagement.de
10
Group
children[
TouchSensor
Shape
geometry Box ...
Shape
geometry Sphere ...
]
Shape
geometry Cone ...
Figuur 2.7: De TouchSensor
Uiteraard blijft de interactie met de VRML-wereld niet beperkt tot enkel navigeren
doorheen de wereld. Met behulp van sensoren kan meer geavanceerde gebruikersinteractie
verkregen worden.
2.3.2 Sensoren
Sensoren zijn knopen in de hierarchie die definieren wanneer gebeurtenissen gecreeerd
moeten worden. Er wordt een onderscheid gemaakt tussen inputsensoren en omgevings-
sensoren. Hier wordt een korte omschrijving gegeven van de beschikbare sensoren. Voor
verdere details wordt verwezen naar de specificaties ([3]).
Sensoren zijn van toepassing op alle kinderen van hun ouder. In de scenegraaf is
een sensorknoop typisch een broer van de knopen waarop hij van toepassing is. In het
codefragment in figuur 2.7 is de TouchSensor van toepassing op de Box en Sphere, maar
niet op de Cone.
Inputsensoren
Inputsensoren worden geactiveerd wanneer de gebruiker met de muis (of gelijkaardige
hardware zoals een joystick) een bepaald deel van de ruimte betreedt of wanneer hij erop
klikt.
TouchSensor: Deze sensor laat toe om de positie van de muis te achterhalen, of de knop-
pen van de muis al dan niet ingedrukt zijn, welke verplaatsing de muis gedaan heeft.
Met behulp van deze sensor kunnen bijvoorbeeld knoppen geımplementeerd worden
die een animatie starten of stoppen.
11
CylinderSensor: Een CylinderSensor reageert op muisbewegingen en genereert rotaties
die overeenkomen met deze bewegingen. Hiermee kan de auteur van de VRML-
wereld de gebruiker bijvoorbeeld toelaten een veelvlak om een as te draaien.
SphereSensor: Muisbewegingen worden door deze sensor omgezet in rotaties om de oor-
sprong van het lokale assenstelsel. Het veelvlak uit het vorige voorbeeld kan nu om
zijn middelpunt geroteerd worden door de gebruiker.
Anchor: Deze groeperingsknoop heeft een veld url. Wanneer de gebruiker klikt op een
van de kinderen van deze knoop, wordt de url ingeladen. Indien deze url wijst naar
een VRML-bestand, wordt de huidige wereld vervangen door de wereld waar de
url naar wijst. Indien de url niet naar een VRML-bestand verwijst, wordt door de
VRML-browser de gepaste actie ondernomen. Hierdoor is het mogelijk om in een
VRML-wereld bijvoorbeeld een link naar de webpagina van de auteur te plaatsen.
PlaneSensor: Een PlaneSensor zet muisbewegingen om in translaties in een vlak even-
wijdig aan het Z=0 vlak in het lokaal coordinatenstelsel.
GeoTouchSensor: VRML voorziet een optionele uitbreiding van de implementatie met
ondersteuning voor geospatiale applicaties. Deze knoop is onderdeel van die uit-
breiding en heeft gelijkaardige functionaliteiten als de TouchSensor.
Omgevingssensoren
In tegenstelling tot de inputsensoren worden omgevingssensoren niet direct door de ge-
bruiker gestart door bijvoorbeeld een klik met de muis. Deze sensoren reageren op de
huidige positie en bewegingen van de avatar in de 3D-wereld.
ProximitySensor: Deze sensor genereert events wanneer de gebruiker een bepaald gebied
in de ruimte binnenkomt, in dat gebied beweegt en wanneer het gebied verlaten
wordt.
TimeSensor: Deze sensor reageert niet op input van de gebruiker, maar genereert events
die gerelateerd zijn aan het tijdsverloop. Van dit type sensor kan handig gebruik-
gemaakt worden voor het genereren van animaties.
VisibilitySensor: Met deze sensor kan gedetecteerd worden of een bepaald deel van de
wereld al dan niet zichtbaar is voor de gebruiker.
Collision: Deze sensor laat toe botsingen te detecteren tussen de gebruiker en objecten
of tussen objecten onderling.
12
De verschillende eventOut-velden van een sensor kunnen via een route verbonden
worden met een eventIn-veld van een andere knoop in de scenegraaf. Op die manier kan
een wereld dynamisch aangepast worden afhankelijk van input van de gebruiker of van de
verlopen tijd.
2.4 Animatie via interpolatorknopen
Interpolatorknopen kunnen gebruikt worden voor het creeren van animatie gebaseerd
op sleutelframes. Een dergelijk knoop definieert een stuksgewijze lineaire functie f(t)
over het interval (−∞,∞). De functie wordt gedefinieerd door aan het veld key enkele
sleutelwaarden toe te kennen (t) en aan het veld keyValue de overeenkomstige waarden
(f(t)). Een interpolatorknoop evalueert vervolgens f(t) voor een willekeurige waarde t die
via het eventIn-veld set_fraction opgegeven wordt. Hoe deze evaluatie precies gebeurd
staat beschreven in de specificaties [3]. Volgende interpolatorknopen zijn voorzien:
ColorInterpolator: Wordt gebruikt voor het interpoleren over verschillende kleuren (ty-
pe SFColor).
CoordinateInterpolator: Interpolatie over coordinaten in de ruimte (type MFVec3f).
GeoPositionInterpolator: Gelijkaardig aan CoordinateInterpolator, maar geospa-
tiale coordinaten (type SFVec3f).
NormalInterpolator: Kan gebruikt worden voor interpolatie over een verzameling nor-
maalvectoren (type MFVec3f).
NurbsPositionInterpolator: Interpolatie over de punten van een 3D nurbs kromme
(type SFVec3f).
OrientationInterpolator: Interpolatie over een verzameling rotaties (type SFRota-
tion).
PositionInterpolator: Interpolatie over een verzameling positievectoren (type SFVec-
3f).
ScalarInterpolator : Interpolatie over een verzameling reele waarden (type SFFloat).
De interpolatorknopen genereren gebeurtenissen via hun eventOut-velden. Deze kun-
nen dan via een route verbonden worden aan het gepaste veld van het object dat geani-
meerd wordt. Het value_changed-veld van een OrientationInterpolator kan zo bij-
voorbeeld aan een het rotation-veld van een Transform-knoop verbonden worden (figuur
2.8). De rotatie heeft dan onmiddellijk effect op alle kinderen van die Transform-knoop.
13
DEF DraaiendeKubus Transform
rotation 0 0 0
children[
Shape
geometry Cube...
appearance...
]
DEF Rotatie OrientationInterpolator
key [ 0 0.5 1 ]
keyValue [ 0 1 0 0 , 0 1 0 3.4, 0 1 0 6.8 ]
DEF Klok TimeSensor
loop TRUE
ROUTE Klok.fraction_changed TO Rotatie.key
ROUTE Rotatie.keyValue TO DraaiendeKubus.rotation
Figuur 2.8: Combinatie van TimeSensor en OrientationInterpolator voor het ronddraaienvan een kubus.
Figuur 2.9: Een script-knoop kan opgenomen worden in de route-definities
2.5 Scripts
Voor meer geavanceerd gedrag van de VRML-wereld kan gebruikgemaakt worden van een
Script-knoop. Deze knopen kunnen gebeurtenissen van andere knopen ontvangen en zelf
gebeurtenissen uitzenden. Een Script-knoop bevat programmacode waarmee de gegevens
van de ontvangen gebeurtenissen verwerkt kunnen worden om gepaste gebeurtenissen uit
te zenden. VRML-browsers ondersteunen minstens EcmaScript[2]. Daarnaast kunnen ze
ook andere script-talen ondersteunen.
In figuur 2.9 wordt bijvoorbeeld een script gebruikt om de huidige tijd van een Time-
Sensor (datatype SFTime) om te zetten naar een waarde van het datatype MFString dat
aan een Text-knoop kan doorgegegeven worden via een route. Op die manier kan de
14
tijdswaarde 6532,15 (uitgedrukt in seconden) door de script-knoop bijvoorbeeld omgezet
worden naar de tekst “1u 48min 52sec”.
Wanneer de eventIn- en eventOut-velden in de Script-knoop gedefinieerd zijn en
de nodige functionaliteit geımplementeerd is, kan een Script-knoop opgenomen worden
in de definities van de routes. Scripts kunnen ook rechtstreeks de waarden van velden
in bepaalde knopen wijzigen wanneer deze knopen als veldwaarde beschikbaar zijn in de
Script-knoop.
Via een Script kan ook extra informatie van de VRML-browser verkregen worden.
Wanneer gebruikgemaakt wordt van EcmaScript kan bijvoorbeeld het object Browser
gebruikt worden. Dit object laat toe om onder andere volgende informatie te verkrijgen:
• naam en versie van de browser
• de url van het huidige VRML-bestand
• de huidige beeldsnelheid
• de huidige snelheid waarmee de gebruiker in de wereld beweegt
Verder is het via een script ook mogelijk om VRML-code in te laden van een ander
bestand, VRML-code te genereren en toe te voegen aan de huidige wereld en routes te
verwijderen of toe te voegen.
VRML voorziet ook de mogelijkheid in de Script-knoop een URL op te nemen naar
een Java-programma zodat meer geavanceerde algoritmes kunnen toegevoegd worden aan
de functionaliteit van de scene. De mogelijkheden hiervoor werden gedefinieerd in de
External Authoring Interface ([4]). Hiermee is het ook mogelijk om vanuit applicaties
VRML-werelden te beınvloeden, bijvoorbeeld in een applet op een webpagina.
2.6 Externe mediabronnen
In de opmaak van een VRML-wereld kan ook gebruikgemaakt worden van externe bron-
nen zoals afbeeldingen, audio- en videobestanden. Afbeeldingen kunnen gebruikt worden
als texturen voor de 3D-objecten. Een VRML-browser die aan de standaard voldoet, moet
minstens ondersteuning bieden voor JPEG- en PNG-afbeeldingen. In het bijzonder kan
een videofragment gebruikt worden als textuur voor een object. De MovieTexture-knoop
biedt dergelijke functionaliteit aan. Via het url-veld van deze knoop wordt een videobe-
stand opgegeven. Om aan de standaard te voldoen, dienen browsers MPEG-1 Systems
(audio en video) en MPEG-1 Video (video) bestandsformaten te ondersteunen.
De video kan via diezelfde MovieTexture-knoop ook aangestuurd worden. Via de
velden loop, startTime, stopTime en speed kan men respectievelijk aangeven of, de
15
video automatisch herhaald moet worden, het tijdsstip waarop de video start opgeven,
het tijdsstip waarop de video stopt opgeven en de snelheid van afspelen instellen.
Ook kunnen in een VRML-wereld geluiden gebruikt worden. In een Sound-knoop
geeft de auteur van de 3D-wereld de locatie van de geluidsbron, de richting van het ge-
luid, de intensiteit, de draagwijdte,... van het geluid aan. Een dergelijke knoop heeft een
AudioSource-knoop als kind. Een AudioSource-knoop heeft gelijkaardige functionalitei-
ten als de MovieTexture-knoop. Een VRML-browser moet minstens audiobestanden in
WAV-formaat ondersteunen. De specificaties van de VRML-standaard raden ook onder-
steuning van het MIDI-formaat5 aan.
Wanneer gebruikgemaakt wordt van afbeeldingen, video of audio, wordt in de scene-
beschrijving een verwijzing opgenomen met behulp van een URL. Deze mediabronnen
worden dus niet in hetzelfde bestand als de scenebeschrijving opgeslaan. Dit vormt vaak
een probleem wanneer in de scenegraaf relatieve URL’s opgenomen worden in plaats van
absolute verwijzingen.
2.7 Toepassingen
VRML laat toe om redelijk geavanceerde 3D-werelden te creeren. Op het Internet zijn heel
wat voorbeelden te vinden van 3D-modellen van robots, gebruiksvoorwerpen, gebouwen
en zelfs volledige steden. Aangezien voor het bekijken van VRML-werelden slechts een
eenvoudige plugin voor webbrowsers nodig is, kan men heel wat scenario’s uitdenken
waarbij een 3D-wereld een nuttige aanvulling is bij een tweedimensionale webpagina. Zo
is het bijvoorbeeld mogelijk de kleur en velgen voor je nieuwe wagen meteen op een 3D-
model te bekijken 6.
2.8 Tekortkomingen
Hoewel VRML een groot succes kende bij auteurs van 3D-werelden, heeft het niet het
verwachte succes op het Internet. Redenen hiervoor zijn onder andere ([7]):
• Er is geen interactie van serverzijde mogelijk. Een VRML-wereld is volledig gekend
bij het inladen van het VRML-bestand.
• Stroming wordt niet ondersteund door VRML. Dit is een groot nadeel aangezien
VRML-werelden heel wat details moeten beschrijven om realistisch te ogen. Gevolg
hiervan is dat de bestanden vaak heel groot zijn, uiteraard een nadeel wanneer het
doel is om 3D-werelden via het Internet beschikbaar te stellen.5zie http://www.midi.org/6zie http://www.bitmanagement.de/demos/BMW Konfigurator/bmw.en.html
16
• VRML werkt met het “download-and-play”-concept zodat de gebruiker soms lang
moet wachten tot de volledige scene en alle externe mediabronnen ingeladen zijn
(Veel VRML-browsers gaan echter anders te werk en tonen de scene van zodra dit
mogelijk is, eventueel zonder texturen e.d.)
• Zelfs de eenvoudigeste animaties (bijvoorbeeld een draaiende tol) vragen redelijk
veel lijnen code.
• VRML biedt geen ondersteuning voor 2D.
• VRML kan geen degelijke synchronisatie garanderen.
• Er is geen enkele ondersteuning binnen de VRML-standaard voor encryptie en di-
gitale rechten.
17
Hoofdstuk 3
X3D - eXtensible 3D
3.1 Inleiding
Zoals in het vorige hoofdstuk een overzicht gegeven werd van de mogelijkheden van VRML,
wordt in dit hoofdstuk hetzelfde gedaan voor X3D[5]. Na een globaal overzicht van deze
scenebeschrijvingstaal wordt een overzicht gegeven van de belangrijkste verschillen met
VRML. De specificaties van de X3D-standaard zijn ook vrij beschikbaar op de website
van het Web3D-consortium[1].
3.2 Algemeen overzicht
X3D is de opvolger van VRML. Net als VRML is het niet enkel een bestandsformaat voor
de beschrijving en uitwisseling van 3D-objecten. Met X3D is een auteur ook in staat om
het gedrag van de 3D-wereld te bepalen wanneer die aan de gebruiker getoond wordt.
X3D wil een uitbreiding vormen op VRML en heeft daartoe volgende doelstellingen
vooropgesteld:
• Ondersteuning voor verschillende bestandsformaten (zie paragraaf 3.2.1).
• Nieuwe objecten toevoegen met extra functionaliteiten op gebied van grafische vorm-
geving, gedrag en interactiviteit.
• Opdelen van de specificatie in zogenaamde profielen (zie paragraaf 3.3.1).
3.2.1 Bestandsformaat
De X3D-standaard voorziet momenteel in twee verschillende bestandsformaten. Scenebe-
schrijvingen kunnen zowel met het VRML-bestandsformaat als met XML[20] beschreven
18
<Shape> Shape
<Appearance> appearance Appearance
<Material diffuseColor="1 0 0" material Material
emissiveColor="1 0 0"/> diffuseColor 1 0 0
</Appearance> emissiveColor 1 0 0
<Sphere radius="0.5"/>
</Shape>
geometry Sphere
radius 0.5
Figuur 3.1: Een rode bol beschreven in het XML- en het VRML-formaat
Klasse Aantal scenes Gemiddelde bestandsgrootte (bytes)X3D VRML
Sounds 24 10407 10399Sensors 84 5201 4760Miscellaneous 22 3903 3210Lights 82 7519 6619Interpolators 31 16134 16057HumanoidAnimation 20 299807 324357GroupingNodes 58 14923 11974Geometry 102 15463 15147GeometricProperties 46 22840 22524BindableNodes 74 5173 4728BinaryCompression 13 210556 209661Appearance 181 12839 11438
Tabel 3.1: Bestandsgroottes van beide bestandsformaten in X3D
worden. Figuur 3.1 geeft de beschrijving van een rode bol in beide formaten. Naast deze
twee tekstuele formaten wordt momenteel ook werk gemaakt van een binair formaat voor
X3D.
Het gebruik van het XML-bestandsformaat laat eenvoudige integratie in bestaande
applicaties en webservices toe. Zo zijn er bijvoorbeeld XSLT-transformaties beschikbaar
om chemische bindingen, beschreven in CML (Chemical Markup Language)1 om te zet-
ten naar een X3D-model2. Ook leent het XML-formaat zich uitstekend voor onderlinge
uitwisseling tussen verschillende auteurs en computersystemen.
Tabel 3.1 geeft een vergelijking tussen de bestandsgroottes van een aantal scenes be-
schreven in beide formaten. Voor deze metingen werd gebruikgemaakt van de X3D Con-
formance Suite die bestaat uit 737 scenes en die vrij beschikbaar is op de website van
1zie http://www.xml-cml.org/2zie http://www.3dez.net/X3D/CML/
19
Bestandstype extensieVRML-syntax .x3dvVRML-syntax + gzip .x3dvzXML .x3dXML + gzip .x3dzbinair .x3dbbinair + gzip .x3dbz
Tabel 3.2: De X3D-bestandstypes en hun extensies
het Web3D Consortium[1]. Alle 737 scenes zijn in zowel het XML gebaseerd als het
VRML-gebaseerd formaat beschikbaar. Zoals uit de tabel blijkt zijn de bestanden in
VRML-syntax gemiddeld kleiner dan de overeenkomstige XML-beschrijving. Het verschil
(gemiddeld 1%) is niet significant genoeg om op basis hiervan een voorkeur voor een van
beide formaten te hebben.
Hoewel de XML-syntax als een verbetering ten opzichte van de VRML-syntax be-
schouwd kan worden omwille van de overdraagbaarheid naar andere applicaties en syste-
men blijft de grootte van de bestanden een probleem in een webomgeving. Daartoe werd
gestart met de ontwikkeling van een binair formaat voor X3D-beschrijvingen3. Net als bij
VRML kunnen de X3D-bestanden ook gecomprimeerd worden met de gzip-tool.
3.2.2 Software
Net zoals bij VRML volstaat een eenvoudige teksteditor voor het aanmaken van een
X3D-wereld. Aangezien X3D ook een XML-gebaseerd bestandsformaat aanbiedt, kan
een auteur echter handig gebruikmaken van bestaande applicaties voor het creeren en
bewerken van XML-bestanden. In die optiek is via de website van het Web3D Consortium
X3D-edit4 beschikbaar, een uitbreiding op de grafische XML-editor Xeena5 van IBM.
Steeds meer commerciele softwarepaketten laten ook toe om X3D bestanden te importeren
en exporteren.
Voor het bekijken van X3D-werelden volstaat een X3D-browser, die als alleenstaande
applicatie of als plugin voor een webbrowser kan optreden. Xj3D6 is een dergelijke browser
die ontwikkeld werd in Java door het Web3D Consortium en gratis ter beschikking is op
hun website.
3Een Request For Proposal werd uitgeschreven in juli 2003. In maart 2004 werden de eerste voorstellenbesproken op het Web3D 2004 Symposium
4zie http://www.web3d.org/x3d/content/README.X3D-Edit.html5zie http://www.alphaworks.ibm.com/tech/xeena6zie http://www.xj3d.org/
20
3.3 Uitbreidingen en verschillen t.o.v. VRML
De scenegraaf (met bijhorende concepten als knopen, gebeurtenissen, routes,. . . ) zoals die
in het vorige hoofdstuk (zie paragraaf 2.2.1) besproken werd, vormt ook de basis van de
scenebeschrijving bij X3D. Er zijn echter enkele belangrijke verschillen en uitbreidingen
op te merken.
3.3.1 Componenten en profielen
In de specificatie van X3D worden de verschillende knopen onderverdeeld in zogenaamde
componenten en profielen.
Componenten
Een component omvat een bepaalde collectie knopen met een gelijkaardige functionaliteit.
Zo’n component bestaat uit de definiering van de knopen en een aanduiding van de ver-
schillende niveaus van implementatie. De Geometry3D-component bevat bijvoorbeeld de
knopen voor het creeren van driedimensionale vormen. Bij implementatie van het laagste
niveau van deze component dient men enkel de knopen Box, Cone, Cylinder en Sphere te
voorzien. Bij het tweede niveau moet ook ondersteuning voor IndexedFaceSet voozien
zijn, waarbij enkele velden optioneel zijn. Het hoogste niveau (in dit voorbeeld is dat
niveau 4) voorziet dan ondersteuning voor alle mogelijke knopen in de component en alle
velden in die knopen.
Profielen
Een profiel is een verzameling van componenten op een bepaald niveau van implementatie.
Een X3D-bestand moet aangeven welk profiel er gebruikt wordt in de scenebeschrijving
die het bevat (zie figuur 3.2). In tegenstelling tot componenten moeten profielen niet
noodzakelijk gezien worden als een hierarchie van functionaliteiten. Profielen hebben als
doel verschillende toepassingsdomeinen te profileren. De verschillende profielen zijn:
Core: Het absolute minimum.
Full: Omvat alle componenten op hun hoogste niveau van implementatie.
Immersive: Voorziet in alle mogelijkheden van VRML97. Ondersteuning voor volledige
virtuele werelden met volledige voorziening wat betreft navigatie en sensoren.
Interactive: Verschillende bijkomende sensorknopen, bijkomende mogelijkheden voor
belichting en extra groeperingsknopen.
21
<X3D profile="Interchange">
<Scene>
...
</Scene>
</X3D>
Figuur 3.2: In een X3D-bestand wordt het gebruikte profiel aangeduid.
Interchange: Ondersteuning voorzien voor basisvormen, texturen, belichting en anima-
tie. Dit profiel is vooral bedoeld voor uitwisseling van objecten en animaties en
implementatie in eenvoudige software zoals applets.
MPEG-4 interactive: Basiscomponent voor interoperabiliteit met de MPEG-4-standaard.
Zoals later zal blijken kunnen scenebeschrijvingen die voldoen aan dit profiel opge-
nomen worden in een MPEG-4-scenebeschrijving.
Deze opdeling in profielen en componenten laat bedrijven toe hun X3D-software te
beperken tot bepaalde profielen. Een architect die een 3D-model van een nieuw gebouw
wenst te maken neemt misschien genoegen met het Interchange profiel terwijl een inge-
nieur die een nieuwe robot wil modelleren waarschijnlijk zal kiezen voor het Interactive
profiel zodat het 3D-model van de robot ook aangestuurd kan worden. De architect en de
ingenieur hebben verschillende noden wat betreft hun software. Software-ontwikkelaars
kunnen daarop inspelen door te kiezen voor bepaalde profielen en toch gebruikmaken van
een open standaard als X3D. Ook kunnen auteurs ervan uitgaan dat hun scenes die in
een bepaald profiel gemaakt zijn ook bekeken kunnen worden op andere systemen en met
andere softwarepaketten die wel hetzelfde profiel ondersteunen.
3.3.2 Grafische uitbreidingen
In vergelijking met VRML zijn er enkele grafische uitbreidingen toegevoegd aan de scene-
beschrijving in X3D.
Ondersteuning voor 2D
In tegenstelling tot VRML, dat enkel 3D-werelden toelaat, is het met X3D ook moge-
lijk om tweedimensionale objecten in de scene op te nemen. De knopen die 2D-objecten
voorstellen zijn gegroepeerd in de Geometry2D-component en bevatten ondermeer de mo-
gelijkheid om cirkelbogen, rechthoeken, driehoeken en polygonen in de scene op te nemen.
De voorzieningen om ook 2D-objecten toe te laten, maken het bijvoorbeeld mogelijk een
vlak statuspaneel op te nemen met gegevens over het driedimensionele machinemodel dat
bekeken wordt.
22
NURBS-component
In X3D kan de auteur van een multimediapresentatie gebruikmaken van NURBS (Non-
uniform Rational B-Splines). NURBS bieden een eenvoudige en efficiente manier om
krommen en oppervlakken te bechrijven. In tegenstelling tot andere wijzen om krommen
te beschrijven (bijvoorbeeld door samenstelling van lijnstukken) ogen dergelijke NURBS
heel glad. Daar NURBS met parametervoorstellingen beschreven worden, kan de hoeveel-
heid data om complexe oppervlakken te beschrijven beperkt gehouden worden.
Animatie van het menselijk lichaam
Met zijn H-Anim-component (Humanoid Animation) levert X3D ook de mogelijkheid te
werken met menselijke karakters in de 3D-werelden.
3.3.3 Snellere weergave van de scene
VRML voorziet in zijn specificaties geen ondersteuning voor incrementele opbouw van
de 3D-wereld. Hoewel VRML-browsers vaak anders te werk gaan, is het in principe de
bedoeling de scene pas aan de gebruiker te tonen wanneer zowel de scenebeschrijving als de
nodige scripts, texturen, video- en audiobestande ingeladen zijn. X3D laat deze eis vallen
zodat een 3D-wereld eerst in zijn eenvoudigste vorm getoond kan worden aan de gebruiker
en dat de externe bronnen in de scene opgenomen worden van zodra ze beschikbaar zijn.
3.3.4 Interactiviteit
Zoals in paragraaf 2.3 besproken kan een gebruiker in een VRML-wereld naast het navi-
geren met muis en toetsenbord, de muis (of joystick) ook gebruiken om de scene aan te
sturen. In X3D liggen net als in VRML de sensor-knopen aan de basis van de gebruikers-
interactie. Naast interactie met de muis kan ook dankbaar gebruikgemaakt worden van
de KeySensor- en StringSensor-knoop om invoer van het toetsenbord te lezen. Binnen
de X3D Source & Tool Development Working Group worden ook experimenten gedaan
met andere invoerapparatuur zoals handschoenen met bewegingssensoren (Digital Data
Glove) 7.
3.3.5 Externe mediabronnen
Net als in VRML kan er in een X3D-scene gebruikgemaakt worden van externe media-
bronnen. In VRML is er echter geen enkele voorziening waarmee kan nagegaan worden
7http://freewrl.sourceforge.net/
23
of bijvoorbeeld een video-bestand reeds volledig ingeladen is en aan de gebruiker getoond
kan worden. In X3D wordt aan dit tekort een oplossing geboden door middel van de
LoadSensor-knoop. Met deze knoop kan nagegaan worden of een externe mediabron vol-
ledig ingeladen is of een schatting gegeven worden hoelang het downloaden nog zal duren.
Op die manier kan men ook de scene aanpassen en tijdens het inladen van de externe
mediabron bijvoorbeeld een gepaste boodschap aan de gebruiker tonen.
3.4 Toepassingen
Uiteraard kunnen gelijkaardige toepassingen als met VRML bereikt worden met X3D.
Maar wegens de uitbreidingen die voorzien zijn ten opzichte van de VRML97-standaard
liggen meer mogelijkheden binnen het bereik. Binnen het Web3D consortium zijn ver-
schillende werkgroepen opgericht rond de ontwikkeling van X3D. Zo doet bijvoorbeeld
MEDX3D onderzoek naar mogelijke toepassingen in de medische wereld. Men denkt
hierbij onder andere aan 3D modelering van de menselijke anatomie en simulatoren voor
chirurgische ingrepen.
24
Hoofdstuk 4
BIFS - Binary Format for Scene
Description
4.1 Inleiding
MPEG-4 is een standaard ontwikkeld door MPEG (Moving Picture Expert Group).
MPEG-4 heeft als doel een standaard te ontwikkelen die de creatie van interactieve multi-
media mogelijk maakt met een veel grotere flexibiliteit dan de bestaande mogelijkheden.
Hierbij wordt voornamelijk gedacht aan toepassingen voor digitale televisie, interactie-
ve grafische toepassingen en multimedia op het Internet. Deze standaard bestaat uit
verschillende delen[15]:
• Part 1: Systems. Dit deel handelt over scenebeschrijving, multiplexen, synchroni-
satie, bufferbeheer en beheer van digitale rechten.
• Part 2: Visual. Dit deel specificeert de gecodeerde representatie van natuurlijke en
synthetische video-objecten.
• Part 3: Audio. Dit deel specificeert de gecodeerde representatie van natuurlijke en
synthetische audio-objecten.
• Part 4: Conformance Testing. Beschrijving voor het testen van MPEG-4 implemen-
taties.
• Part 5: Reference Software.
• Part 6: Delivery Multimedia Integration Framework (DMIF). Beschrijving van een
protocol voor het stromen van multimedia.
• Part 7: Optimized Visuel Reference Software.
25
• Part 8: Carriage of MPEG-4 content over IP networks.
• Part 9: Reference Hardware Description.
• Part 10: Advanced Video Coding (AVC).
In het kader van dit eindwerk beperken we ons tot deel 1 (Systems). In MPEG-1 en
MPEG-2 wordt met de term”Systems” verwezen naar de architectuur, het multiplexen en
de synchronisatie. MPEG-4 Systems breidt deze zaken uit met scenebeschrijving, inter-
activiteit, beschrijving van de inhoud en programmeerbaarheid [6]. Samen met MPEG-4
Visual en MPEG-4 Audio biedt MPEG-4 Systems een krachtige manier voor de creatie
van interactieve multimedia.
Figuur 4.1: MPEG-4 Systems
MPEG-4 maakt, in tegenstelling tot MPEG-1 en MPEG-2, gebruik van het begrip
“Object”. Een MPEG-2 scene bestaat dan uit een audio- en een video-object. MPEG-4
scenes worden opgebouwd met een willekerig aantal audiovisuele objecten van uiteen-
lopende vormen[15]. Figuur 4.1 geeft een overzicht van de basisblokken van MPEG-
4 Systems. De verschillende audiovisuele objecten waaruit de interactieve presentatie
bestaat, worden via zogenaamde elementaire stromen bij de gebruiker afgeleverd. De
scenebeschrijvingsstroom bevat de scenegraaf zoals die in vorige hoofdstukken reeds aan
bod kwam. In deze graaf kunnen verwijzingen opgenomen worden naar elementen in de
Object Descriptor-stroom (OD) die op hun beurt verwijzingen bevatten naar de eigenlijke
video- of audiostromen.
BIFS (Binary Format for Scene Description) is de binaire scenebeschrijvingstaal die
binnen de MPEG-4 standaard gebruikt wordt. Zoals in de inleiding reeds vermeld, wordt
26
in dit hoofdstuk een algemeen overzicht gegeven van de mogelijkheden die MPEG-4 en
BIFS bieden en komen in volgende hoofdstukken praktische voorbeelden aan bod.
Voor de voorbeelden in dit hoofdstuk en volgende hoofdstukken wordt gebruikgemaakt
van BIFSText, een tekstuele representatie van het binaire formaat. Dit bestandsformaat
gebruikt dezelfde syntax als VRML zodat het lezen van voorbeelden in dit formaat geen
hindernis zal vormen.
4.2 Doelstellingen van MPEG-4 Systems
Het MPEG-4 Requirements document[14] geeft een opsomming van alle doelstellingen
die vooropgesteld werden bij de ontwikkeling van MPEG-4. Deel 4.1 van dit document
somt de vereisten voor MPEG-4 Systems op. Net als VRML en X3D moet ook deze
standaard de mogelijkheid bieden audiovisuele objecten op te nemen in een interactieve
multimediapresentatie. Deze objecten kunnen zowel van natuurlijke (bv videofragment
van een voetbalwedstrijd) als van synthetische aard zijn (bv een 3D-animatie). Efficiente
codering van een MPEG-4-scene is een tweede belangrijk doel. Hier wordt aan voldaan
door voor alle objecten die gebruikt worden bij de opbouw van een interactieve presentatie
een efficiente binaire codering te eisen.
Een opmerkelijke doelstelling is het integreren van externe applicaties in een scene
door middel van applicatietexturen. Zo zou het bijvoorbeeld mogelijk gemaakt worden
om een HTML-pagina te bekijken in een browser die als textuur aan een object in de
scene toegewezen is. Ook worden in het MPEG-4 Requirements document verschillende
mogelijkheden voor het verkrijgen van de scene gespecificeerd (lokaal bestand, stroming,
progressief downloaden van de scene,. . . ). Ook de verschillende eisen wat betreft gebrui-
kersinteractie worden beschreven. Hierbij is naast de interactie zoals die ook bij VRML
en X3D voorzien is, onder andere sprake van het toekennen van URL’s aan objecten zodat
klikken op die objecten resulteert in het afhandelen van de URL, het voorzien van een
communicatiekanaal van de gebruiker naar de server,. . .
Verder worden nog eisen gesteld betreffende foutafhandeling, bestandsformaten, com-
patibiliteit met andere video- of audiostandaarden, referenties naar MPEG-71 documen-
ten,. . . Voor meer details wordt verwezen naar het MPEG-4 Requirements document [14].
4.3 Scenebeschrijving
Net zoals bij VRML en X3D het geval is, maakt ook BIFS voor de beschrijving van de
scenes gebruik van een scenegraaf met zijn knopen, routes, events,. . . Er zijn echter enkele
1MPEG-7 is een standaard voor het beschrijven van metadata horende bij een audiovisueel object
27
belangrijke verschillen en uitbreidingen op te merken die hier kort opgesomd worden.
Enkele van deze zaken worden verder in dit of volgende hoofdstukken meer gedetailleerd
besproken.
4.3.1 Knoop-types in de scenegraaf
De hierarchische structuur van de scenegraaf wordt bekomen doordat sommige knopen als
waarden voor bepaalde velden een of meerdere andere knopen krijgen. In VRML en X3D
zijn er slechts 2 datatypes voor dergelijke velden, met name SFNode (1 enkele knoop) en
MFNode (meerdere knopen). BIFS voorziet echter meerdere mogelijke knooptypes (Node
Data Type - NDT) en er wordt bij alle velden ook exact gespecificeerd welk type knopen
zij als waarde kunnen krijgen. Een knoop kan ook meerdere datatypes hebben wanneer
dezelfde knoop als kind kan voorkomen in verschillende contexten. Een Shape-knoop is
bijvoorbeeld zowel van het type SF3DNode als van het type SF2DNode omdat deze knoop
zowel in een 3D- als in een 2D-context kan voorkomen.
4.3.2 Numerieke referenties naar knopen en velden
In VRML en X3D kan men met behulp van het DEF-commando een naam toekennen
aan een bepaalde knoop in de scene. Verder in de scenebeschrijving kan deze naam dan
bijvoorbeeld gebruikt worden om in een route-definitie naar die knoop te verwijzen. Ook
naar de velden werd met hun naam verwezen. Uiteraard is het in BIFS ook mogelijk om
in route-definities, script-knopen,. . . te verwijzen naar andere knopen en hun velden.
De tekstuele namen die men aan een knoop kan hechten bij het opmaken van de scene-
beschrijving worden in de binaire representatie echter vervangen door gehele getallen. Doel
hiervan is een compactere codering van de scenegraaf te bekomen. Een nadeel hiervan is
uiteraard dat de scenebeschrijvingen minder leesbaar worden voor de mens na omzetting
van het binaire formaat naar een tekstueel formaat. In VRML en X3D kan men immers
betekenisvolle namen kiezen die de leesbaarheid van de code ten goede komen.
In een route-definitie worden ook de namen van het bronveld en het doelveld niet
langer gebruikt. Alle velden in een knoop krijgen in de MPEG-4-specificaties een index
mee. Deze index kan dan door routes of scripts gebruikt worden om naar de juiste velden
te verwijzen. Ook hiermee wordt een optimale codering nagestreefd. Bij een knoop met
7 velden zijn 3 bits voldoende om elk veld een unieke index te geven (23 = 8 > 7). In de
binaire representatie de namen van de velden opnemen zou heel wat meer bits eisen. In de
opmaak van de scenebeschrijving kan de auteur hier wel gebruikmaken van de veldnamen
om er naar te verwijzen en ook na decodering zijn de veldnamen beschikbaar.
28
4.3.3 Gebruik van externe mediabronnen
In VRML en X3D kan men externe bronnen zoals video, afbeeldingen en geluidsbestan-
den gebruiken in de scene door een url op te nemen naar het betreffende bestand. Het
opnemen van dergelijke externe bronnen in een MPEG-4-presentatie vergt heel wat meer
werk dan enkel het opnemen van een url naar het juiste bestand en in tegenstelling tot
VRML en X3D is het nu wel mogelijk om deze externe mediabronnen op te nemen in het-
zelfde bestand als de scenebeschrijving. Hiervoor wordt gebruikgemaakt van het Object
Descriptor-raamwerk, waar in paragraaf 4.4 dieper op ingegaan wordt. De mediatypes
die ondersteund worden door MPEG-4 worden opgesomd in tabel 4.1.
MediaDescription objectTypeIndication streamTypeObject Descriptor Stream MPEG4Systems1 - 0x01 ObjectDescriptor
- 0x01BIFS Stream version 1 MPEG4Systems1 - 0x01 SceneDescription
- 0x03BIFS Stream version 2 MPEG4Systems2 - 0x02 SceneDescription
- 0x03MPEG-4 Visual Stream MPEG4Visual - 0x20 Visual - 0x04MPEG-4 Audio Stream MPEG4Audio - 0x40 Audio - 0x05MPEG-2 Visual Stream MPEG2VisualSimple - 0x60 Visual - 0x04profiles Simple, Main, MPEG2VisualMain - 0x61SNR, Spatial, High, 422) MPEG2VisualSNR - 0x62
MPEG2VisualSpatial - 0x63MPEG2VisualHigh - 0x64MPEG2Visual422 - 0x65
MPEG-2 Audio Stream MPEG2AudioMain - 0x66 Audio - 0x05/ Part 7 -AAC (profiles MPEG2AudioLowComplexity - 0x67Main, Low Complexity,Scalable Sampling Rate)
MPEG2AudioScaleableSamplingRate- 0x68
MPEG-2 Audio StreamPart 3
MPEG2AudioPart3 - 0x69 Audi - 0x05
MPEG-1 visual stream MPEG1Visual - 0x6A Visual - 0x04MPEG-1 audio streamPart 3
MPEG1Audio - 0x6B Audio - 0x05
JPEG Visual stream JPEG - 0x6C Visual - 0x04
Tabel 4.1: Ondersteunde mediatypes in MPEG-4 [10]
4.3.4 Geavanceerdere layout-mogelijkheden
In VRML en X3D kunnen objecten op de gewenste locatie geplaatst worden in de scene
door gebruik te maken van de juiste translaties. Hiervoor moeten alle afmetingen van de
objecten gekend zijn en moet de auteur van de scene een belangrijke inspanning leveren
29
om de juiste translaties te bepalen. BIFS voorziet voor de layout van de objecten twee
extra knopen. Zowel de Form-knoop als de Layout-knoop bieden mogelijkheden om hun
kinderen automatisch te schikken in de beschikbare ruimte. In de praktische voorbeelden
uit hoofdstukken 7 en 8 worden deze knopen meer in detail besproken.
4.3.5 Interactie met mediastromen
De knopen voor het integreren van video (MovieTexture) of audio (AudioClip) in VRML
en X3D voorzien velden voor het aansturen van deze media-objecten (starten, stop-
pen,. . . ). Ook BIFS voorziet dergelijke knopen voor het opnemen van audio of video.
Een belangrijk verschil in MPEG-4 is echter dat de velden startTime en stopTime, die
gebruikt worden om aan te geven wanneer de video afgespeeld moet worden, aangevuld
worden met bijkomdende knopen. Er werd gekozen om enkele knopen te introduceren die
enkel het aansturen van media-objecten als taak hebben. Het grote voordeel hiervan is
dat deze nieuwe knopen onafhankelijk zijn van het media-object dat ze aansturen. Ze kun-
nen gebruikt worden voor videostromen, audiostromen en zelfs andere MPEG-4-stromen.
De knopen waarvan sprake zijn de MediaControl- en MediaSensor-knoop. Hun werking
komt aan bod in hoofdstuk 8.
4.3.6 Dynamisch wijzigen van de scene
BIFS heeft voorzieningen om scenes te wijzigen na verloop van tijd. Hiervoor zijn twee
mechanismen voorzien. BIFS-Command wordt gebruikt voor eenvoudige wijzigingen in de
scene uit te voeren. BIFS-Anim is een meer geavanceerd mechanisme dat in een afzon-
derlijke stroom gegevens voor animaties levert. Deze mechanismen maken het mogelijk
een scene die gestroomd wordt naar de gebruiker te wijzigen door commando’s vanop de
server. Een typisch voorbeeld hierbij is het aanpassen van de hoofdpunten van het laatste
nieuws in een MPEG-4-scene met het journaal.
4.3.7 Gebruikersinteractie
BIFS gebruikt voor het toevoegen van interactiviteit aan de scene hetzelfde mechanisme
als VRML en X3D. Ook hier wordt gebruikgemaakt van sensorknopen om invoer van
de gebruiker te detecteren. In het hoofdstuk over X3D werd reeds vermeld dat er bij-
komende knopen (o.a. KeySensor) voorzien werden in deze context zodat de interactie
niet langer beperkt blijft tot invoer met de muis. BIFS breidt dit nog verder uit door
de voorziening van een generieke InputSensor-knoop. Deze knoop hangt af van enkele
externe elementen, met name een User Interaction Stream en een User Interaction
Decoder.
30
4.3.8 Interactie met de server
BIFS voorziet ook in een knoop, de ServerCommand-knoop, die het toelaat om een bood-
schap (een tekstbericht) te verzenden naar een opgegeven locatie (een URL). Deze knoop
biedt uiteraard heel wat mogelijkheden voor het creeren van geavanceerde interactieve
scenes. Als reactie op een bericht die de server ontvangt kan bijvoorbeeld via BIFS-Command
de scene gewijzigd worden.
4.3.9 MPEG-J
De terminals waarop de MPEG-4-presentaties getoond worden hebben uiteenlopende ken-
merken. Zowel dektop-computers als mobiele apparaten horen immers tot de doelgroep
van MPEG-4. De meeste van de die beoogde terminals hebben echter de mogelijkheid
om computerprogramma’s uit te voeren, zodat het aansturen van de scenes met compu-
terprogramma’s binnen de mogelijkheden ligt. Hiervoor biedt MPEG-4 de mogelijkheid
samen met de scenebeschrijving ook Java-programma’s naar de gebruiker te sturen voor
geavanceerde aansturing van de scene. In die context wordt gesproken van MPEG-J.
Dit mechanisme is in zekere zin vergelijkbaar met de EAI van VRML[4]. Verschil is
echter dat bij de VRML-EAI een interface gedefinieerd wordt voor het aansturen van
VRML-werelden vanuit externe applicaties (en de Java-binding daarvoor werd ook vast-
gesteld in de standaard). MPEG-J daarentegen maakt integraal deel uit van een MPEG-
4-presentatie in een afzonderlijke MPEG-J-stroom. De functionaliteiten bij beiden zijn
echter gelijkaardig. In deze thesis wordt hier niet verder op ingegaan, meer informatie
hierover kan bijvoorbeeld gevonden worden in hoofdstuk 5 van [15].
4.3.10 Verdere uitbreidingen
Naast de zaken die hierboven aan bod kwamen zijn er in BIFS nog andere uitbreidingen
ten opzichte van VRML en X3D. Zo is er bijvoorbeeld de TermCap-knoop die toelaat om
gegevens van de terminal waarop de MPEG-4-scene bekeken wordt in rekening te brengen
(bepaalde delen van de scene kunnen bijvoorbeeld verborgen worden als de terminal niet
voldoet aan opgegeven voorwaarden). De ApplicationWindow-knoop laat toe externe
applicaties op te nemen in de scene. Met behulp van de AnimationStream-knoop kan
controle uitgeoefend worden op een animatiestroom (cfr BIFS-Anim). De Conditional-
knoop kan gebruikt worden om enkele BIFS-Commands te bundelen en uit te voeren.
Met de Valuator-knoop kunnen waarden omgezet worden in waarden van een ander
datatype. BIFS voorziet ook in heel wat meer mogelijkheden wat betreft audio (o.a.
stereo, surround, akoestische eigenschappen,. . . ).
31
Figuur 4.2: De AudioSource-knoop verwijst naar een audiostroom via een OD
4.4 Het Object Descriptor raamwerk
Zoals in figuur 4.1 reeds aangegeven werd, wordt een MPEG-4-presentatie samengesteld
uit verschillende zogenaamde elementaire stromen. Deze stromen kunnen media-objecten
zijn (video, audio, . . . ) maar ook de scenebeschrijving of een animatiestroom worden in
dergelijke elementaire stromen aangeleverd. Deze stromen hebben uiteraard verschillende
eigenschappen en kenmerken. Om die te beschrijven maakt BIFS gebruik van het Object
Descriptor-raamwerk.
4.4.1 Object Descriptor
Zoals in figuur 4.2 aangegeven vormt een Object Descriptor de verbinding tussen de scene-
beschrijving in de scenegraaf en de elementaire stroom die het eigenlijke audiovisuele ob-
ject aanlevert. Een dergelijke Object Descriptor kan aanzien worden als een container die
alle informatie bevat horende bij een of meerdere elementaire stromen. Voor elke elemen-
taire stroom die door een Object Descriptor omschreven wordt, wordt een Elementary
Stream Descriptor voorzien.
Aan elke Object Descriptor wordt een ObjectDescriptorID toegewezen die uniek is in
de hele scene. Het is dit identificatienummer dat in de scenegraaf kan gebruikt worden in
het url-veld van een knoop om te verwijzen naar bijvoorbeeld een audio-stroom. Net zoals
de audiovisuele objecten via elementaire stromen aan de MPEG-4-terminal beschikbaar
32
DecoderConfigDescriptor Informatie die de decoder nodigt heeftom de stroom in te lezen. Bevat on-der meer het type van de elementai-re stroom (visual, audio, scenebeschrij-ving,. . . ) en de gebruikte codering(JPEG, MPEG-1, MPEG-2, MPEG-4)(zie ook tabel 4.1).
SLConfigDescriptor Configuratie voor de synchronisatielaagvan de MPEG-4-terminal.
IPMP DescriptorPointer Beschrijving en beheer van intellectuelerechten.
LanguageDescriptor Beschrijving van de taal van de elemen-taire stroom.
QoS Descriptor Quality Of Service Descriptor. Voor-al bedoeld voor de mediaservers en degateways die de stromen op een intelli-gente manier doorsturen.
RegistrationDescriptor Beschrijving van stromen die niet totMPEG-4 behoren. Hiermee kan een ap-plicatie specifieke datatstromen gebrui-ken die niet in de standaard bevat zijn.
Tabel 4.2: Enkele onderdelen van een Elementary Stream Descriptor
gesteld worden, worden ook de Object Descriptors via een ObjectDescriptor-stroom
aangeleverd.
In het bijzonder is met elke MPEG-4-scene een initiele Object Descriptor geassocieerd
die de terminal toegang verleent tot de volledige scene. Typisch omschrijft deze Initial
Object Descriptor twee elementaire stromen. De eerste bevat de scenebeschrijving terwijl
de tweede de andere Object Descriptors bevat waarnaar verwezen wordt in de scenebe-
schrijving.
4.4.2 Elementary Stream Descriptor
Zoals eerder reeds vermeld kan een Object Descriptor meerdere elementaire stromen
(Elementary Stream - ES) beschrijven. Elk van deze elementaire stromen wordt be-
schreven met behulp van een Elementary Stream Descriptor (ESD) en krijgt ook een
uniek identificatienummer toegewezen (ES_ID). In tabel 4.2 wordt een overzicht gegeven
van alle informatie die een ESD kan bevatten over de bijhorende elementaire stroom[15].
Hoewel een Object Descriptor meerdere elementaire stromen kan beschrijven stelt de-
ze slechts een object voor. De verschillende elementaire stromen vormen verschillende
mogelijke alternatieven voor de mediastroom (linkerdeel van figuur 4.3). Zo kan bijvoor-
beeld een video-object beschikbaar zijn in verschillende versies. Het is dan de taak van de
33
Figuur 4.3: Er kan een hierarchie toegewezen worden aan de verschillende elementaire stromenin een Object Descriptor
MPEG-4-terminal om de versie te kiezen die best bij de mogelijkheden van het systeem
past. Ook is het mogelijk een onderlinge hierarchie aan de elementaire stromen binnen een
Object Descriptor toe te kennen met behulp van het dependsOn_ES_ID (rechterdeel van
figuur 4.3). Zo kan een basiskwaliteit van de mediastroom voorzien worden met verschil-
lende verbeteringslagen. Beide mechanismen kunnen aangewend worden om schaalbare
multimediapresentaties te creeren.
Vaak is het nodig dat twee verschillende elementaire stromen synchroon lopen. Een
typisch voorbeeld hierbij is een videostroom met een bijhorende audiostroom. Men kan
deze eis ook aangeven in de Elementary Stream Descriptor door met behulp van het veld
OCR_ES_ID (OCR staat voor Object Clock Reference) te verwijzen naar het ES_ID van een
andere elementaire stroom. Wanneer geen waarde opgegeven wordt voor dit veld lopen
alle stromen synchroon met de initiele stroom.
4.5 BIFS-Command
Eens de scene zichtbaar is voor de gebruiker kan de server deze nog steeds wijzigen met
het zogenaamde BIFS-Command-mechanisme. Zo kan bijvoorbeeld een videofragment in
de scene door de server vervangen worden door een ander fragment. Dit mechanisme kan
ook gebruikt worden om grote scenes beetje bij beetje op te bouwen om zo de vereiste
bandbreedte te beperken. In tegenstelling tot andere audiovisuele presentaties (zoals
webpagina’s of VRML-scenes) heeft een BIFS-presentatie dus ook een tijdsdimensie [16].
Onder de noemer BIFS-Command worden functionaliteiten verzameld die volgende
operaties mogelijk maken:
• De huidige scene vervangen door een totaal nieuwe scene.
• Knopen, velden en hun waarden en routes toevoegen aan de huidige scene.
• Knopen, velden en hun waarden en routes verwijderen uit de huidige scene.
• Knopen, velden en hun waarden en routes wijzigen.
34
Figuur 4.4: Het BIFS-Anim protocol
4.6 BIFS-Anim
Animaties kunnen in VRML en X3D beschreven worden met behulp van interpolator-
knopen. Nadeel hiervan is dat de animatie volledig deel uitmaakt van de scene en dus niet
dynamisch gewijzigd kan worden. Zoals besproken worden de scenes in deze opmaaktalen
ook eerst volledig ingeladen voor ze aan de gebruiker getoond worden. Bij uitgebreide ani-
maties dienen dus ook de vele sleutels en hun sleutelwaarden van de interpolator-knopen
eerst ingeladen worden, wat een tweede belangrijk nadeel vormt van deze werkwijze.
BIFS combineert de stroming-functionaliteit en de mogelijkheid om dynamisch scenes
te wijzigen om deze nadelen ongedaan te maken. De animaties kunnen dus perfect voor-
zien worden gebruikmakend van het BIFS-Command-mechanisme. Er wordt echter ook
een alternatief aangeboden in de vorm van BIFS-Anim(ation).
BIFS-Anim maakt gebruik van een animatie-masker (Figuur 4.4) die een lijst bevat van
knopen en velden die geanimeerd moeten worden. Er wordt naar deze objecten verwezen
met hun uniek identificatienummer dat ze kregen met behulp van het DEF-commando. De
gegevens over de animatie zelf worden naar de scene gestroomd via de animatiestroom.
De veldwaarden in die stroom kunnen initiele waarden zijn om de velden opnieuw te
initialiseren of kunnen aanpassingen zijn voor de vorige waarde van het veld. Net als
bij sommige video-coderingen worden deze beide respectievelijk aangeduid met I-frame
(Intra-frame) en P-frame (Predictive).
4.7 Bestandsformaat
BIFS voorziet een binair bestandsformaat dat de scenebeschrijvingen heel efficient co-
deert. Het gebruikte formaat vormt een compromis tussen sterke compressie enerzijds
35
en uitbreidbaarheid, eenvoudige parsing en eenvoudige specificatie anderzijds [16]. Als
voorbeeld wordt een idee gegeven van de binaire voorstelling van de scene uit figuur 2.5:
1. Een hoofding met wat globale informatie over de gebruikte codering.
2. Een binaire waarde voor de Shape-knoop.
3. Een bit die aangeeft dat alle velden van de Shape-knoop sequentieel gegeven zullen
worden in plaats van index-waarde paren.
4. Een binaire representatie van de Box-knoop, zijnde:
(a) Een binaire waarde voor de Box-knoop.
(b) Een bit om aan te geven dat de velden van de Box-knoop zullen opgegeven
worden met hun volgnummer.
(c) Het volgnummer van het size-veld.
(d) Een binaire representatie van de SFVec3f-waarde 2 8 4.
(e) Een bit om aan te geven dat er geen velden meer gespecificeerd zullen worden
van de Box-knoop.
5. Een binaire representatie van de Appearance-knoop (hier niet verder uitgewerkt).
In tabel 5.1 wordt een overzicht gegeven van de bestandsgroottes van enkele typische
MPEG-4-scenes. In paragraaf 5.3.2 in het hoofdstuk over XMT wordt meer uitleg gegeven
over de waarden van deze tabel. In de rest van deze paragraaf worden enkele technieken
belicht die gebruikt worden bij de binaire codering van de scenegraaf.
4.7.1 Contextafhankelijkheid
Zoals ook uit bovenstaand voorbeeld blijkt wordt gebruikgemaakt van de context voor co-
dering van velden en hun waarden. De kinderen van de Shape-knoop worden bijvoorbeeld
sequentieel opgesomd. Uit de context kan dan afgeleid worden welke knopen dit precies
zijn. Na het inlezen van de binaire waarde voor de Shape-knoop en de bit die aangeeft dat
de velden sequentieel zullen opgegeven worden, weet een decoder dus welke types knopen,
velden en waarden er ingelezen moeten worden. Om deze codering zo efficient mogelijk
te doen wordt gebruikgemaakt van de kennis over de verschillende mogelijke datatypes
die een knoop kan hebben (zie paragaaf 4.3.1). Voor elk van zijn types krijgt een knoop
dan ook een vast bitpatroon toegekend. Wanneer de Shape-knoop bijvoorbeeld in een
3D-context voorkomt wordt gebruikgemaakt van de 6-bit code 100100 (= 36) omdat deze
knoop positie 36 heeft in de lijst van de 48 mogelijke SF3DNodes.
36
Niet enkel voor de codering van de hierarchie van de scenegraaf wordt gebruikgemaakt
van kennis van de context. Ook bij het coderen van de velden en hun waarden in de knopen
wordt hierop ingespeeld. Met elke knoop wordt een knoopcoderingstabel (NCT - Node
Coding Table) geassocieerd met informatie over de manier waarop de verschillende velden
in de knoop gecodeerd moeten worden. In appendix B van [21] wordt hier dieper op
ingegaan.
4.7.2 Kwantisatie
In BIFS kan ook gebruikgemaakt worden van kwantisatie voor het efficienter coderen
van de scene. Kwantisatie kunnen we definieren als het voorstellen van een (mogelijk
oneindig) grote verzameling waarden met een veel kleinere verzameling van waarden.
Uiteraard gaat hierbij vaak informatie verloren. Als we bijvoorbeeld alle reele waarden
tussen 0 en 5 afbeelden op het geheel getal dat er het dichtst bij ligt kan nooit bepaald
worden welk getal aanleiding gaf tot uitvoerwaarde 3 (zowel 2.67, 3.02, . . . behoren tot de
mogelijkheden).
In BIFS-Anim (zie paragraaf 4.6) wordt standaard gebruikgemaakt van kwantisatie,
in BIFS-Command (zie 4.5) is dit optioneel en kan de auteur van de scene de parameters
voor de kwantisatie opgeven via de QuantizationParameter-knoop. Deze knopen kunnen
zowel globaal als lokaal gedefinieerd worden. Wanneer ze als lokaal gedefinieerd worden,
wordt de beschreven kwantisatie enkel toegepast op de knoop (en de kinderen ervan) die
volgt op de QuantizationParameter-knoop. Globale kwantisatie geldt voor alle knopen
die nog volgen en dezelfde ouder hebben als de QuantizationParameter-knoop.
Er zijn verschillende types kwantisatie gedefinieerd die overeenstemmen met de ver-
schillende numerieke velden van de verschillende knoop-types. In het eenvoudige voorbeeld
van figuur 4.5 wordt een lokale kwantisatieparameter in de scenebeschrijving toegevoegd
voor de codering van de kleur van een bol. Normaal gezien worden voor de codering
van een kleur 24 bits gebruikt (8 voor elk van de rode, groene en blauwe component van
de kleur). Het veld colorNbBits met waarde 1 geeft aan dat voor elk van de RGB-
componenten slechts 1 bit gebruikt moet worden. Een waarde 0 stemt dan overeen met
de minimum-waarde die opgegeven wordt in het colorMin-veld (hier 0) en een waar-
de 1 representeert de maximumwaarde die opgegeven wordt in het colorMax-veld (0.5).
De donkerblauwe kleur van de bol uit figuur 4.5 wordt dan gecodeerd met 3 bits (001)
in plaats van de oorspronkelijke 24 (00000000 00000000 01111111). In [8] wordt het
aantal nodige bits voor het beschrijven van een cartoon gereduceerd tot een derde van
de oorspronkelijke grootte door gepast gebruik te maken van kwantisatiegegevens in de
scenebeschrijving. Uiteraard moet steeds afgewogen worden of het efficienter is gebruik te
maken van een QuantizationParameter daar deze uiteraard ook de nodige opslagruimte
vraagt.
37
...
QuantizationParameter
isLocal true
colorNbBits 1
colorMin 0
colorMax 0.5
Shape
appearance Appearance
material Material
diffuseColor 0 0 1
geometry Sphere
...
Figuur 4.5: De QuantisationParameter-knoop wordt gebruikt voor efficientere codering vande kleur van een object.
4.8 Stroming
Een van de belangrijkste tekortkomingen van opmaaktalen als VRML of X3D is het feit
dat er geen voorzieningen zijn voor het stromen van de scenes. De scenebeschrijving en
alle nodige externe mediabronnen zoals audio- en videobestanden moeten eerst volledig
gedownload worden voor de gebruiker iets te zien krijgt. Hoewel het met MPEG-4 Systems
ook mogelijk is een dergelijk scenario te hebben, biedt deze MPEG-standaard ook moge-
lijkheden voor het stromen van de audiovisuele objecten en zelfs van de scenebeschrijving.
Deze stroming zorgt voor een snellere weergave bij de gebruiker. In het bijzonder kan een
scene samengesteld worden uit verschillende mediabronnen die op verschillende locaties
staan en op verschillende manieren aangeleverd worden. BIFS omvat ook mogelijkheden
voor de synchronisatie van de verschillende stromen in een dergelijk scenario. Een voor-
beeld waarbij een scene in een lokaal bestand andere MPEG-4-presentaties inlaadt vanop
een streaming server wordt besproken in een volgend hoofdstuk.
4.9 Toepassingen
Zoals in de inleiding van dit hoofdstuk reeds aangegeven is MPEG-4 een standaard die heel
wat domeinen in verband met multimedia bundelt. MPEG-4 Systems neemt in dat geheel
een belangrijke plaats in. Dit deel van de standaard laat immers toe alles te bundelen tot
aantrekkelijke interactieve presentaties.
Zoals in de inleiding van dit hoofdstuk reeds vermeld kan MPEG-4 zijn weg vinden in
38
de ontwikkeling van de digitale televisie. In de ontwikkeling van de interactieve televisie in
Vlaanderen, wordt momenteel gebruikgemaakt van een combinatie van MPEG-2 voor de
audiovisuele data en Java als programmeertaal voor de interactieve functionaliteiten[17].
MPEG-4 (inclusief MPEG-J) belooft een waardig alternatief te leveren voor deze techno-
logieen.
MPEG-4 kan ook gebruikt worden voor het aanbieden van multimedia via het Inter-
net. Een uitgewerkt voorbeeld van een bestaande internet-applicatie die omgezet werd in
MPEG-4 wordt besproken in hoofdstuk 7. Een ander domein waarbij MPEG-4 een be-
langrijke invloed kan hebben is de vele multimedia die op CD-ROM worden aangeboden
en zelfs de interface van DVD’s kan geımplementeerd worden in MPEG-4.
39
Hoofdstuk 5
XMT - Extensible MPEG-4 Textual
Format
5.1 Inleiding
In het vorige hoofdstuk werd een overzicht gegeven van het binair scenebeschrijvings-
formaat BIFS voor het opmaken van MPEG-4-presentaties. Het Extensible MPEG-4
Textual Format (XMT) waar dit hoofdstuk over handelt biedt een tekstueel formaat aan
voor het beschrijven van dergelijke MPEG-4-presentaties (MPEG-4 Part 1 : Systems).
Dit bestandsformaat vereenvoudigt de creatie en het onderhoud van MPEG-4-presentaties
door mens of computer. Ook voor de eenvoudige uitwisseling van scenes is XMT een
goed formaat. De betekenisvolle tekstuele namen die de auteur aan knopen toekent en
eventuele verhelderende commentaar in de beschrijving gaan immers niet verloren zoals
bij het binaire BIFS. Als basis voor XMT werd gekozen voor de opmaaktaal XML[20]
omwille van de vele reeds bestaande toepassingen voor het werken met XML.
5.2 Algemeen overzicht
In XMT worden de knopen uit de scenegraaf voorgesteld door XML-elementen. De velden
van deze knopen worden voorgesteld als attributen van deze elementen. De hierarchie van
de scenegraaf wordt naar een XML-representatie vertaald door elementen op te nemen
binnen andere elementen. Net als BIFS heeft XMT ook de nodige voorzieningen voor het
beschrijven van externe mediabronnen die samen met de scenebeschrijving de uiteindelijke
MPEG-4-presentatie voorstellen.
De naam XMT is een verzamelnaam voor zijn twee varianten, XMT-Ω en XMT-A. Met
XMT-Ω kan een auteur een MPEG-4-scene op een hoog niveau van abstractie beschrijven,
XMT-A daarentegen leunt nauw aan bij het binaire BIFS. Bij de ontwikkeling van XMT
40
werd ook de uitwisselbaarheid met X3D en SMIL (Synchronized Multimedia Integration
Language[18]) als een van de doelstellingen vooropgesteld.
5.3 XMT-A
Alle mogelijkheden van MPEG-4 Systems zoals die besproken werden in het vorige hoofd-
stuk kunnen met behulp van XMT-A beschreven worden. Een XMT-A beschrijving omvat
dus een ondubbelzinnige bepaling van het binaire formaat van een MPEG-4-presentatie.
Een groot deel van de X3D-standaard wordt ondersteund door de MPEG4 Systems stan-
daard en de representatie van die knopen is dan ook volledig identiek in zowel X3D als
in XMT-A. XMT-A biedt ook ondersteuning voor het OD-raamwerk. Dus met XMT-A
kan een auteur niet enkel de objecten waaruit de scene bestaat beschrijven, maar ook
elementen als Object Descriptor (OD), OCI beschrijvingen, IPMP-beschrijvingen,. . .
5.3.1 Bestandsformaat
Zoals reeds vermeld is XMT een XML-gebaseerd bestandsformaat. Een XMT-A document
heeft een <Header>-element waarin verschillende <meta>-elementen kunnen opgenomen
worden met informatie over de scene. Ook het <InitialObjectDescriptor>-element
wordt in dit <Header>-element opgenomen. Na het <Header>-element komt een <Body>-
element met de beschrijving van de scene[12]. Alle constructies zoals die in het vorige
hoofdstuk ingevoerd werden hebben een XML-representatie in dit XMT-A formaat waar
verder niet op ingegaan wordt. Een uitgebreide bespreking kan gevonden worden in
hoofdstuk 6 van [15].
In het codefragment van figuur 5.1 wordt een scene beschreven waarbij de gebruiker op
een groen vierkant kan klikken om het vierkant op te vullen. In figuur 5.2 wordt een idee
gegeven van diezelfde scene in BIFS-formaat. Om de codefragmenten niet te overladen
werden de Object Descriptors weggelaten.
5.3.2 Binaire versus tekstuele representatie
In tegenstelling tot louter tekstuele beschrijvingstalen als VRML en X3D is het bij
XMT niet de bedoeling dat mediaspelers het XMT-bestandsformaat (XMT-A of XMT-
Ω ) ondersteunen. Scenebeschrijvingen opgemaakt in XMT worden eerst omgezet naar
het binaire BIFS alvorens ze beschikbaar gesteld worden voor afspelen. Door het be-
houd van de logische namen en de commentaar geeft XMT uiteraard wel een manier om
scenebeschrijvingen onderling uit te wisselen zonder dat de bedoeling van de auteur en
de betekenis van de constructies verloren gaan.
41
<?xml version="1.0" encoding="UTF-8" ?>
<XMT-A ...>
<Header>
...
</Header>
<Body>
<Replace>
<Scene>
<OrderedGroup>
<children>
<Shape>
<appearance>
<Appearance>
<material>
<Material2D DEF="MaterialVierkant" emissiveColor="0 1 0"/>
</material>
</Appearance>
</appearance>
<geometry>
<Rectangle size="100 100"/>
</geometry>
</Shape>
<TouchSensor DEF="SensorVierkant"/>
</children>
</OrderedGroup>
<ROUTE fromNode="SensorVierkant" fromField="isActive"
toNode="MaterialVierkant" toField="filled"/>
</Scene>
</Replace>
</Body>
</XMT-A>
Figuur 5.1: Een eenvoudige scene in XMT-A formaat
42
OrderedGroup
children [
Shape
appearance Appearance
material DEF N0 Material2D
emissiveColor 0 1 0
geometry Rectangle
size 100 100
DEF N1 TouchSensor
]
ROUTE N1.isActive TO N0.filled
Figuur 5.2: De scene uit figuur 5.1 in BIFSText
In tabel 5.1 wordt een overzicht gegeven van de bestandsgroottes van een aantal scenes
beschreven in XMT-A en hun binaire representatie (mp4-bestanden). Voor deze meting
werd gebruikgemaakt van de scenes in de GPAC Regression Test Suite 1 die behoren tot
het GPAC-project (zie appendix B). De scenes waarin gebruikgemaakt wordt van externe
mediabronnen (audio, video of afbeeldingen) werden niet opgenomen in de meting omdat
deze externe bronnen wel opgenomen worden in het mp4 bestand maar uiteraard niet
bijdragen tot de bestandsgrootte van de XMT-A beschrijving. Op deze manier krijgen
we een beeld van de bestandsgroottes van 136 scenes die enkel uit synthetische objecten
bestaan.
De scenes werden opgedeeld in verschillende klassen volgens de functionaliteit die ze
implementeren. Er is een duidelijk merkbaar verschil in bestandsgroottes tussen de binaire
representatie en de tekstuele beschrijving, gemiddeld neemt het mp4-bestand 30% van de
grootte van het overeenkomstige XML-bestand in beslag. Ter illustratie werd in de tabel
ook het BT-bestandsformaat2 opgenomen.
5.4 XMT-Ω
In beschrijvingstalen als VRML, X3D of XMT-A worden de multimediapresentaties be-
schreven op het niveau van knopen in een scenegraaf en moet men routes definieren voor
het sturen van gebeurtenissen. XMT-Ω daarentegen stelt auteurs in staat om het tem-
poreel gedrag en de layout van multimediapresentaties te bepalen op een hoog niveau
1Vrij te downloaden op http://gpac.sourceforge.net/downloads.php2BIFS Text
43
Klasse Aantal Gemiddelde bestandsgrootte (bytes)scenes MP4 XMT-A BT
Background2D 1 827 2370 1274Appearance 6 1060 3281 2389Sensors 10 908 2695 1663Text 12 1420 5666 4718Proto 14 2985 7409 5789Scripts 10 1326 4832 3399Commands 28 975 2930 1688InputSensor 2 2543 11252 8731Grouping 19 1559 7055 5821Geometry 5 1104 3606 2530Special 9 1073 2658 1492ATG 20 1208 4367 3251
Tabel 5.1: Bestandsgroottes van een aantal MPEG-4-scenebeschrijvingen
<xmt-o ...>
<head> ... </head>
<body>
<seq>
<img id="foto1" src="1.jpg" dur="10s"/>
<img id="foto2" src="2.jpg" dur="10s"/>
<img id="foto3" src="3.jpg" dur="indefinite"/>
</seq>
</body>
</xmt-o>
Figuur 5.3: Een diavoorstelling beschreven in XMT-Ω
van abstractie. Het codefragment in figuur 5.3 beschrijft bijvoorbeeld een diavoorstelling
waarin de eerste twee foto’s 10 seconden getoond worden. De derde foto blijft zichtbaar tot
wanneer de presentatie afgesloten wordt. Diezelfde diavoorstelling in bijvoorbeeld XMT-
A beschrijven zou heel wat meer lijnen code vergen. Deze eenvoudige representatievorm
van mogelijk complexe scenes heeft ook een positieve invloed op de uitwisselbaarheid en
onderhoudbaarheid van de code. Software voor creatie van MPEG-4-bestanden kan deze
beschrijving in XMT-Ω dan omzetten naar de overeenkomstige binaire BIFS-representatie
met de nodige Object Descriptors, elementaire stromen,. . .
XMT-Ω is sterk gebaseerd op SMIL[15]. SMIL is opgedeeld in verschillende functionele
modules (synchronisatie, media, scene-overgangen, . . . ). XMT-Ω functioneert als gasttaal3 voor heel veel van deze modules. Op die manier kan SMIL-code geıntegreerd worden
in XMT-Ω scenebeschrijvingen en wordt interoperabiliteit tussen beiden verkregen. Zo-
3Een gasttaal wordt gedefinieerd als een XML-gebaseerde taal die SMIL-modules integreert in zijnsyntax.
44
Element Beschrijving<par> Afspelen van alle kinderen, mogelijk gelijktijdig.<seq> Afspelen van alle kinderen, een voor een.<excl> Afspelen van een kind tegelijk, geen vastgelegde volgorde.
Tabel 5.2: Tijdscontainers in XMT-Ω
Attribuut Beschrijvingdur Speelduur van het element.begin Starttijd van het element.end Eindtijd van het element.min Minimale speelduur van het element.max Maximale speelduur van het element.
Tabel 5.3: Tijdsattributen in XMT-Ω
als XMT-Ω voor audio, video, afbeeldingen en tekstuele data SMIL omvat, omvat deze
beschrijvingstaal ook SVG (Scalable Vector Graphics[19])voor synthetische 2D-objecten
zoals rechthoeken en cirkels.
Hoewel XMT-Ω een hoog abstractieniveau wil aanbieden, is er toch de mogelijkheid
om XMT-A codefragmenten op te nemen in de scenebeschrijving. Deze werkwijze biedt de
auteur een manier om voor bepaalde delen van de scenebeschrijving toch over te gaan op
het niveau van knopen en routes. Op die manier kan een bepaalde constructie bijvoorbeeld
efficienter geımplementeerd worden dan de BIFS-code die door software zou gegenereerd
worden.
5.4.1 Tijdsmodel en synchronisatie
In XMT-Ω zijn er zowel elementen als attributen beschikbaar voor het controleren van de
tijd waarop audiovisuele objecten zichtbaar zijn in de presentatie en voor het controleren
van hun onderlinge synchronisatie. Tabel 5.2 geeft de drie zogenaamde tijdscontainers
en hun functionaliteit. Deze elementen kunnen gebruikt worden om hun kinderen in
de scenegraaf te groeperen volgens een vastgelegde tijdslijn. De attributen die gebruikt
kunnen worden voor de momenten waarop bepaalde elementen zichtbaar zijn, worden
opgesomd in tabel 5.3. Verder is er ook de mogelijkheid om het tijdsverloop te beınvloeden.
Zo is het bijvoorbeeld mogelijk een video-object twee maal zo snel te laten afspelen. Ook
is het bijvoorbeeld mogelijk een animatie de eerste x seconden te versnellen van stilstand
naar de volle snelheid om op het einde van de animatie geleidelijk terug tot stilstand te
komen. Op die manier geven de animaties een meer realistische indruk.
45
5.4.2 Gebeurtenissen
Net zoals in VRML of X3D vormen gebeurtenissen de basis van de gebruikersinteractie
en de interactie tussen objecten in de scene. De gebruikelijke bewegingen van de muis
resulteren in het genereren van de bijhorende events (mouseup, mousedown, mouseover,
. . . ). Ook gebeurtenissen als botsingen tussen 2 objecten, wijziging van de zichtbaarheid
van een object of de wijziging van de afstand tussen 2 objecten zijn beschikbaar. Deze ge-
beurtenissen kunnen dan door de auteur van de audiovisuele presentatie gebruikt worden
in de beschrijving ervan.
5.4.3 Animatie
In BIFS zijn er voor de animatie van objecten verschillende mogelijke mechanismen. Een
eerste is gebruik te maken van interpolatorknopen en routes om de gepaste eigenschappen
van de knopen te wijzigen. Een gelijkaardige manier is ook in XMT-Ω beschikbaar met be-
hulp van het <set>-element. Verder zijn er ook complexere <animate>-, <animateColor>-
en <animateMotion>-elementen die een abstractie vormen van de bijhorende interpola-
torknopen in BIFS[15]. Ook kan gebruikgemaakt worden van BIFS-Anim stromen.
5.4.4 Een uitgewerkt voorbeeld
Figuur 5.4: Een presentatie beschreven in XMT-Ω
46
Als voorbeeld van een uitgewerkte scene beschreven in XMT-Ω wordt een presentatie
gemaakt met een voorstelling van een film4.
In figuur 5.4 wordt de presentatie weergegeven. Linksboven wordt de trailer van de
film afgespeeld terwijl rechtsboven enkele foto’s uit de film verschijnen. Onderaan komen
alle acteurs in beeld met hun echte naam en hun rol in de film. Voor dit voorbeeld
werd gebruikgemaakt van de”IBM Toolkit for MPEG-4”5. In de header van de XMT-
Ω beschrijving worden eerst enkele gebieden op het scherm gedefinieerd. Elk van deze
gebieden krijgt een unieke naam. In de body van de beschrijving worden dan verschillende
constructies opgenomen gelijkaardig aan die uit figuur 5.3. De scenebeschrijving en het
resulterende MPEG-4-bestand zijn beschikbaar in bijlage A.
4Dit voorbeeld is gebaseerd op de demo getiteld ”Temporal synchronization of media within MPEG-21Digital Item Declarations” die beschikbaar is op http://multimedialab.elis.ugent.be/demo.asp
5zie http://www.alphaworks.ibm.com/tech/tk4mpeg4
47
Hoofdstuk 6
Samenvattend overzicht
In onderstaande tabel wordt een overzicht gegeven van de belangrijkste kenmerken van
de verschillende opmaaktalen die in vorige hoofdstukken besproken werden. Aangezien in
XMT-Ω ook XMT-A constructies kunnen opgenomen worden, worden beide opmaaktalen
samengevat in de kolom met hoofding XMT. Sommige delen van deze tabel in verband
met VRML en BIFS zijn overgenomen uit [7]
VRML X3D BIFS XMTBestandsformaat ASCII XML, ASCII
en binairbinair XML
Compressie gzip gzip Binair be-standsfor-maat enkwantisatie
niet van toe-passing
Compositie vanobjecten
enkel 2D 2D en 3D 2D en 3D 2D en 3D
DynamischeCompositie
geen onder-steuning
geen onder-steuning
voorzien viahet BIFS-Commandmechanisme
idem BIFS
Animatie Met behulpvan interpo-lators
AnaloogVRML, uit-breiding vaninterpolatorsvoor 2D
Analoog X3D+ BIFS-command enBIFS-Animraamwerk
idem BIFS
48
VRML X3D BIFS XMTBeheer digitalerechten
geen onder-steuning
geen onder-steuning
voorzieningvia het OD-raamwerk
idem BIFS
Compositiemedia-objectenvan verschillen-de bronnen
voorzien voorzien voorzien+ OD-raamwerkvoor beschrij-ving vande media-objecten
idem BIFS
Stroming geen onder-steuning
geen onder-steuning
Volledig ge-baseerd opstroming
Niet van toe-passing
Synchronisatietussen verschil-lende audiovisu-ele objecten
zwakke on-dersteuning,niet op fra-megebaseerdebasis
idem VRML zeer goedeondersteu-ning, syn-chronisatieop frame-gebaseerdebasis
idem BIFS
Gebeurtenissen-model
via routes via routes via routes via routes
Scripting ECMAScripten Java
ECMAScripten Java
ECMAScripten Java
ECMAScripten Java
Beschikbaresoftware
Heel veel soft-ware beschik-baar
Beperkte hoe-veelheid
Zeer beperktehoeveelheid
idem BIFS
Onafhankelijkheidtussen scene-beschrijving enmedia-objecten
Geen. Media-objectenworden recht-streeks inde scenebe-schrijvingopgenomen
idem VRML Volledigeonafhanke-lijkheid viahet OD-raamwerk
idem BIFS
2D tekeningen Niet beschik-baar
Beschikbaar Beschikbaar Beschikbaar
3D tekeningen Beschikbaar Beschikbaar Beschikbaar BeschikbaarInteractiviteit Enkel met
muis (enaanverwan-ten zoalsjoystick)
Uitbreidingtov VRMLmet toetsen-bord
Uitbreidingtov X3D meteen generiekeInputSensor
idem BIFS
Component-gebaseerdearchitectuur
Neen Ja Ja Ja
Opdeling in pro-fielen
Neen Ja Ja Ja
49
Hoofdstuk 7
Een trailer-mozaıek in MPEG-4
7.1 Inleiding
In dit hoofdstuk wordt concreet ingegaan op de opbouw en werking van een typische
MPEG-4-applicatie. De Belgische internetprovider Telenet biedt sinds een aantal maan-
den de zogenaamde PCTV1 aan. Via een website kunnen Telenet-klanten filmfragmenten
en televisieprogramma’s bekijken. Ook op andere websites worden gelijkaardige initiatie-
ven getoond. De laatste film-trailers kunnen bijvoorbeeld bekeken worden op de website
van Apple2. De applicatie die in dit hoofdstuk wordt voorgesteld, biedt een gelijkaardige
functionaliteit. Concreet zal in deze MPEG-4-demo een interface geboden worden die de
gebruiker toelaat enkele film-trailers te bekijken. Het initiele scherm is afgebeeld in figuur
7.1.
7.2 Doelstellingen
De beoogde applicatie moet voldoen aan enkele voorwaarden. We wensen een geıntegreer-
de oplossing te bereiken door alle functionaliteiten in MPEG-4 te voorzien. Net als de
gebruikersinterface moeten ook de filmfragmenten zelf in MPEG-4-bestanden beschikbaar
gesteld worden. Daarnaast moet het voor de gebruiker ook mogelijk zijn een keuze te ma-
ken tussen verschillende versies van hetzelfde film-fragment (Simulstore3). Concreet werd
ervoor gekozen een grote en kleine versie van elke trailer te voorzien. Uiteraard kan dit
eenvoudig uitgebreid worden naar andere vormen van schaalbaarheid. Andere doelstel-
lingen zijn de film-trailers via een streaming server aan te bieden en bij het bekijken van
1zie http://www.telenet.be/pctv2zie http://www.apple.com/trailers/3De term simulstore wordt gebruikt wanneer verschillende versies van eenzelfde mediastroom beschik-
baar zijn op een server
50
Figuur 7.1: De gebruiker kan een keuze maken tussen verschillende beschikbare trailers.
een trailer een weblink te tonen naar een website met meer informatie over de betreffende
film.
7.3 Gebruikte software
Voor het aanmaken van het mp4-bestand met de gebruikersinterface werd gebruikgemaakt
van de software van het GPAC-project (zie appendix B). In dit softwarepakket zijn on-
der andere een MPEG-4-terminal (Osmo) en een MPEG-4-encoder/decoder (MP4Box)
voorzien. Opnieuw worden de code-voorbeelden in BIFSText gegeven. Dit formaat wordt
ook volledig door MP4Box ondersteund. Als streaming server werd gekozen voor de gratis
Darwin Streaming Server van Apple4 die gebruikmaakt van het Real Time Streaming Pro-
tocol5. De trailers werden in het QuickTime-bestandsformaat (*.mov) gedownload van
Apple’s website en met QuickTime Pro omgezet naar ongecomprimeerde avi-bestanden.
Deze werden gecodeerd naar mp4-bestanden met behulp VirtualDub6 en GraphEdit7.
Hierbij werd gebruikgemaakt van de 3ivx-codec8.
4zie http://developer.apple.com/darwin/projects/streaming5RTSP - http://www.rtsp.org/6zie http://www.virtualdub.org7zie http://www.microsoft.com8zie http://www.3ivx.com
51
Figuur 7.2: Nadat de gebruiker een van beide versies gekozen heeft, wordt de trailer getoond.
7.4 Scenebeschrijving van de gebruikersinterface
Bij het openen van de scene krijgt de gebruiker een mozaıek te zien waarop de verschillende
beschikbare trailers geafficheerd worden (figuur 7.1). Om een bepaalde trailer te kiezen
kan de gebruiker klikken op de bijhorende afbeelding. Wanneer dat gebeurt, wordt de
mozaıek verborgen en krijgt de gebruiker een keuzescherm te zien waarbij opgegeven
moet worden welke versie van de gekozen trailer moet getoond worden. Na die keuze
verschijnt een derde en laatste scherm waarin de trailer uiteindelijk getoond wordt (zie
figuur 7.2). Bij de laatste twee schermen kan de gebruiker bovenaan op de balk klikken
om terug te keren naar de mozaıek. Bij het afspelen van de film wordt onderaan een link
naar de bijhorende webpagina geplaatst en wordt een tijdsaanduiding weergegeven. In
wat volgt wordt dieper ingegaan op enkele aandachtspunten en interessante delen van de
scenebeschrijving.
In dit en het volgende hoofdstuk worden enkele definities van knopen gegeven. De
structuur van deze definities wordt in figuur 7.3 gegeven. Het veldtype kan field,
eventOut, eventIn of exposedField zijn. Het datatype is bijvoorbeeld SFTime, SFBool,. . .
NaamVanDeKnoop
veldType datatype naam defaultWaarde #extraInfo
...
Figuur 7.3: De definitie van een knoop.
7.4.1 Prototypes
Zoals eerder in dit eindwerk vermeld is, is het als auteur mogelijk om zelf nieuwe knopen te
definieren. Dit gebeurt typisch wanneer men verwacht deze knopen nog in andere scenes
te gebruiken of wanneer de objecten die door die nieuwe knopen geımplementeerd worden
52
veelvuldig gebruikt worden in de huidige scene maar met wisselende kenmerken9. Voor
deze toepassing werden 2 prototypes voorzien.
ImageButton
De gebruiker moet een keuze kunnen maken uit verschillende trailers. In het keuzescherm
krijgt de gebruiker hiervoor een aantal knoppen te zien waarop een afbeelding van de
verschillende trailers staat. Voor deze knoppen werd een prototype voorzien waarvan de
definitie in figuur 7.4 te zien is. De waarde van het veld size bepaalt de grootte van
de knop en heeft als standaard-waarde 140 op 106 pixels. Via het textureUrl-veld kan
de url van de afbeelding die gebruikt moet worden opgegeven worden. Deze velden zijn
van het type exposedField en hun waarden kunnen dus bij initialisatie van een nieuwe
ImageButton opgegeven worden. Daarnaast zijn ook 2 eventOut-velden voorzien waarmee
de toestand van de knop kan gedetecteerd worden, isOver heeft als waarde true als met
de muis over de knop bewogen wordt en isActive wanneer geklikt wordt op de knop.
PROTO ImageButton[
exposedField SFVec2F size 140 106 # size of button
exposedField MFString textureUrl [] # url texture
eventOut SFBool isOver # mouse over
eventOut SFBool isActive # click
]
Figuur 7.4: De definitie van de ImageButton-knoop.
TextLink
In figuur 7.5 wordt de definitie van de TextLink-knoop gegeven. Deze knoop implemen-
teert een tekstuele link waarvan de tekst via het text veld kan ingesteld worden. Ook
hier kan de toestand van de muis gedetecteerd worden via de velden isOver en isActive.
Deze knoop wordt gebruikt voor de keuze van de gewenste grootte van de gekozen trailer
en voor de www-link naar de betreffende website.
PROTO TextLink[
exposedField MFString text [] # text
eventOut SFBool isOver # mouse over
eventOut SFBool isActive # click
]
Figuur 7.5: De definitie van de TextLink-knoop.
9Indien eenzelfde object meermaals in een scene voorkomt kan men gebruikmaken van de commando’sDEF en USE
53
7.4.2 Layout van de verschillende objecten
Het is perfect mogelijk om alle objecten met behulp van de gepaste translaties (mogelijk
via de Transform2D-knoop) op de juiste plaats op het scherm te plaatsen. Deze manier is
echter weinig flexibel en vergt de kennis van alle afmetingen van de objecten in de scene.
Voor de positionering van de objecten is het beter gebruik te maken van de Form-knoop
waarvan de definitie in figuur 7.6 is weergegeven. Deze knoop plaatst zijn kinderen volgens
de opgegeven restricties.
Form
eventIn MFNode addChildren []
eventIn MFNode removeChildren []
exposedField MFNode children []
exposedField SFVec2f size -1 -1 #QP=12
exposedField MFInt32 groups [] #QP=13 NbBits=10 Bounds=[-1,1022]
exposedField MFString constraints []
exposedField MFInt32 groupsIndex [] #QP=13 NbBits=10 Bounds=[-1,1022]
Figuur 7.6: De definitie van de Form-knoop.
Als voorbeeld wordt in figuur 7.7 de code weergegeven voor de opmaak van een deel van
het keuzescherm. De drie objecten die hier moeten geplaatst worden zijn een rechthoek
met een afbeelding van de film, een TextLink voor de grote versie van de film en TextLink
voor de kleine versie. Deze drie objecten worden opgenomen in het children-veld van
de Form-knoop. In het groups-veld wordt een opdeling gemaakt van de verschillende
kinderen in groepen volgens hun volgnummer in de children-knoop (hierbij wordt de
waarde -1 gebruikt als afbakening van de groepen). Zo vormt elk kind afzonderlijk een
groep en is er een vierde groep die bestaat uit kind 2 en 3 (de twee TextLink-objecten).
Vervolgens worden in het veld constraints de verschillende restricties vermeld. Het
veld groupsIndex tenslotte geeft aan op welke groepen de restricties van toepassing zijn
(opnieuw wordt -1 als afbakening gebruikt). Zo worden groepen 1 en 2 links gealigneerd
(AL), groepen 1 en 3 rechts (AR) en groepen 1 en 4 worden verticaal gespreid over de
beschikbare ruimte (SVin). Het resultaat is te zien in het linkerdeel van figuur 7.2.
7.4.3 Wisselen van scherm
Zoals reeds vermeld zijn er in deze demo drie verschillende schermen te onderscheiden
(mozaıek, keuze van de versie en afspelen van de trailer). Om op een eenvoudige manier
te kunnen wisselen tussen deze schermen wordt gebruikgemaakt van een Switch-knoop.
Aan een dergelijke knoop kunnen verschillende objecten als kinderen gehecht worden
54
Form
groups [1 -1 2 -1 3 -1 2 3 -1]
constraints ["AL" "AR" "SVin"]
groupsIndex [1 2 -1 1 3 -1 1 4 -1]
children[
Shape
... #rechthoek met afbeelding
DEF BIGBTN TextLinktext "GROOT"
DEF SMALLBTN TextLinktext "KLEIN"
]
Figuur 7.7: Gebruik van de Form-knoop voor de positionering van de objecten.
waarvan er op elke moment slechts 1 zichtbaar is. Welk kind getoond wordt kan ingesteld
worden door de waarde van het whichChoice-veld te wijzigen.
7.4.4 Weergeven van de trailers
Een van de doelstellingen was de trailers via een streaming server beschikbaar te stel-
len. Aangezien deze filmpjes zelf een MPEG-4-scene vormen met onder andere een
scenebeschrijvingsstroom, een audiostroom en een videostroom kan hier niet gebruikge-
maakt worden van verschillende Elementary Stream Descriptors voor deze stromen. Het
Object Descriptor-raamwerk laat echter wel toe een MPEG-4-scene als een enkel elemen-
taire stroom te beschouwen en op die manier op te nemen in een andere scene. In de
Object Descriptor dienen nu geen Elementary Stream Descriptors opgenomen te worden,
maar kan gewoon een url opgegeven worden naar het betreffende mp4-bestand zoals in
figuur 7.8 aangegeven.
Om de trailer vervolgens in de scene op te nemen, wordt als waarde voor het url-
veld van de Inline-knoop de overeenkomsige ObjectDescriptorID opgegeven. Diezelfde
waarde wordt gebruikt in het url-veld van een MediaSensor-knoop en een MediaControl-
knoop waarvan de functionaliteit in paragrafen 8.3.2 en 8.3.2 besproken wordt.
7.4.5 Een script als controle-orgaan
Het zou perfect mogelijk zijn om zonder gebruik te maken van een Script-knoop een
MPEG-4-presentatie te maken die voldoet aan de opgestelde voorwaarden uit 7.2. Er
is bij de implementatie van dit voorbeeld voor gekozen er toch gebruik van te maken.
Reden hiervoor is dat het heel wat zaken sterk vereenvoudigt en de scenebeschrijving
overzichtelijk houdt. Via de variabelen en functies van een script kan eenvoudig de huidige
55
Figuur 7.8: De Object Descriptors verwijzen naar bestanden op een streaming-server
toestand van de presentatie onthouden worden of kunnen meer geavanceerde berekeningen
gedaan worden. Zoals eerder vermeld kunnen de waarden van de verschillende velden in
een knoop ook rechtstreeks gewijzigd worden door een script. Deze manier van werken
bespaart uiteraard heel wat ROUTE-definities.
In deze implementatie wordt de Script-knoop voor volgende zaken gebruikt:
• Het bijhouden van tabellen met de url’s voor de afbeelding, de website, de grote
versie en de kleine versie van elke trailer.
• Een functie voor het wijzigen van de trailer. Deze functie verbergt de mozaıek,
wijzigt de afbeelding op het keuzescherm voor de versies van de film en stelt de
variabele currentTrailerIndex in met het nummer van de gekozen trailer voor
gebruik in de toekomst.
• Een functie voor het instellen van de grote versie van de trailer en een voor de kleine
versie van de trailer. Deze functies geven de variabele currentTrailer de gepaste
url met behulp van de waarde van currentTrailerIndex.
• Een functie voor het afspelen van de trailer. Deze functie verbergt het keuzescherm
en wijzigt het url-veld van de MediaControl-knoop, Inline-knoop en MediaSensor-
knoop.
• Een functie voor het openen van de juiste website wanneer de gebruiker op de
www-link klikt. Hierbij wordt gebruikt gemaakt van het standaard object Browser.
Wanneer een url naar een mp4-bestand wijst, zal de huidige scene vervangen wor-
den door deze nieuwe scene. Wanneer het gaat om een andere url (zoals in dit
56
geval een webpagina) wordt de afhandeling van deze oproep overgelaten aan het
computersysteem waarop de scene bekeken wordt.
• Een functie voor het omzetten van de verlopen tijd bij het bekijken van de trailer
naar een leesbaar formaat.
7.5 Voordelen, nadelen en mogelijke uitbreidingen
Voor het gebruik van deze applicatie volstaat een MPEG-4-terminal. Dit is een be-
langrijk verschil met bijvoorbeeld de PCTV van Telenet waarvoor eisen gesteld worden
wat betreft het besturingssysteem, de webbrowser en de mediaspeler. Op de website
van Telenet is te lezen dat er gewerkt wordt aan oplossingen voor systemen die momen-
teel niet ondersteund worden. Hierbij wordt onder andere ook gedacht aan MPEG-4.
Waar bij de vernoemde voorbeelden gebruik gemaakt wordt van verschillende technolo-
gien (webpagina’s, QuickTime-bestanden, ...) wordt in deze oplossing enkel van MPEG-4
gebruikgemaakt zodat de oplossing zoals in dit hoofdstuk beschreven, een geıntegreerde
en gestandaardiseerde oplossing vormt.
Een nadeel bij deze demo is dat de gebruiker zelf een keuze moet maken tussen de ver-
schillende versies van de aangeboden trailers. Ideaal zou zijn mocht de MPEG-4-terminal
deze keuze zelf maken afhankelijk van de systeemkenmerken waarop de applicatie bekeken
wordt. Deze mogelijkheid wordt geboden door het Object Descriptor-raamwerk, maar mo-
menteel is het niet mogelijk dergelijke bestanden (met meerdere video- en audiostromen)
te stromen via de Darwin Streaming Server. Ook de Termcap-knoop waarmee eigenschap-
pen van de MPEG-4-terminal in rekening gebracht kunnen worden, kan gebruikt worden
in dergelijk scenario. Uiteraard zullen ook tegenstanders van deze geautomatiseerde keuze
te vinden zijn.
Een mogelijke uitbreiding van deze applicatie is het inbouwen van ondersteuning voor
beheer van digtale rechten. In het eerdere aangehaalde voorbeeld van de Telenet PCTV
zijn bepaalde beeldfragmenten beveiligd tegen kopieren via de Windows Media 9 DRM
module10. Ook moeten de Telenet-klanten zich aanmelden voor ze een video kunnen be-
kijken. Deze uitbreidingen zouden een belangrijke meerwaarde bieden aan deze demo.
Mogelijke oplossingen hiervoor kunnen gevonden worden door het gebruik van de voor-
zien ondersteuning voor IPMP in MPEG-4 of gebruik van de de ServerCommand-knoop
waarmee een communicatiekanaal van de gebruiker naar de server kan voorzien worden.
10zie http://www.microsoft.com/windows/windowsmedia/drm/
57
Hoofdstuk 8
Een mediaspeler in MPEG-4
Uit de bespreking van de MPEG-4-scenebeschrijvingstaal blijkt duidelijk dat ook meer
geavanceerde multimediascenes binnen de mogelijkheden liggen. In dit hoofdstuk wordt
gebruikgemaakt van BIFS om een videospeler te implementeren.
8.1 Doelstellingen
De applicatie moet de gebruikelijke functionaliteiten van een mediaspeler voorzien (afspe-
len, pauze, stop, herhalen). In de applicatie die in hoofdstuk 7 besproken werd, wordt de
gebruiker voor het afspelen van de trailer gevraagd een keuze te maken uit verschillende
kwaliteiten (Simulstore). In de applicatie die hier besproken wordt breiden we deze mo-
gelijkheid uit. De gebruiker moet nu in staat zijn om tijdens het afspelen van de video
de kwaliteit te wijzigen. Concreet worden van hetzelfde videofragment 4 versies voorzien
(de originele en de drie vormen van schaalbaarheid). Ook de kwaliteit van het geluid
moet ingesteld kunnen worden (2 kwaliteiten of geen geluid). Naast deze functionalitei-
ten moet ook ondertiteling in verschillende talen voorzien worden en de mogelijkheid om
naar bepaalde scenes in de video te springen.
8.2 Gebruikte software
Net als bij de implementatie van de applicatie in hoofdstuk 7 werd gebruikgemaakt van
MP4Box voor het coderen van het uiteindelijke mp4-bestand. In dit voorbeeld wor-
den alle video- en audiostromen in een enkel mp4-bestand opgenomen samen met de
scenebeschrijving en de ondertiteling. Voor het creeren van de verschillende video- en
audiokwaliteiten werd gebruikgemaakt van VirtualDub1 en ffmpeg2. De videosequenties
1zie http://www.virtualdub.org2zie http://ffmpeg.sourceforge.net/
58
Figuur 8.1: Een videospeler in MPEG-4.
zijn gecodeerd met de XViD-codec3 en de audiostromen met MP3.
8.3 Scenebeschrijving
In figuur 8.1 wordt de interface van de applicatie getoond. Centraal komt de video, onder-
aan de controleknoppen (pauze, stop,. . . ) en rechts de keuzeknoppen voor ondertiteling
en scene. Voor de positionering van deze elementen wordt opnieuw gebruikgemaakt van de
Form-knoop (zie paragraaf 7.4.2). In wat volgt worden opnieuw enkele aandachtspunten
besproken.
8.3.1 Synchronisatie van de verschillende stromen
Een belangrijke uitdaging bij de implementatie van deze demo is het synchroniseren van
alle mediastromen. Beeld, audio en ondertiteling moeten immers gelijk lopen. Ook bij het
omschakelen naar een andere video- of audiokwaliteit moet de hele presentatie synchroon
verderlopen. Zoals in hoofdstuk 4 besproken, wordt aan elke elementaire stroom een
uniek identificatienummer toegekend (ES_ID) en kan in de Elementary Stream Descriptors
(ESD) verwezen worden naar een andere elementaire stroom via het veld OCR_ES_ID om
synchronisatie af te dwingen tussen deze beide stromen.
We kunnen dus alle elementaire stromen naar een elementaire stroom laten wijzen en
zo de gewenste synchronisatie afdwingen. Hiervoor hebben we nood aan een elementaire
stroom die gedurende de hele presentatie aanwezig is. In deze applicatie is er geen enkele
3zie http://www.xvid.org/
59
Figuur 8.2: De verschillende mediastromen wijzen naar een OCR-stroom om onderlinge syn-chronisatie te verkijgen.
voor de hand liggende stroom die voldoet aan deze vereiste. Er kan immers gewisseld
worden tussen verschillende videostromen, audiostromen en ondertitels.
MPEG-4 voorziet een oplossing voor dit probleem. Er kan immers gebruikgemaakt
worden van een zogenaamde OCRStream (OCR staat voor Object Clock Reference). Deze
stroom vormt geen eigenlijk audiovisueel object maar kan dienen als referentiestroom voor
de andere stromen. In de Elementary Stream Descriptor van deze OCR-stroom kunnen
we de duur aangeven voor deze stroom. Uiteraard stellen we die tijdsduur gelijk aan de
duur van de video die we wensen af te spelen.
8.3.2 Aansturen van mediastromen
In MPEG-4 kunnen, net als in VRML en X3D, video’s als texturen voor objecten gebruikt
worden door gebruik te maken van de MovieTexture-knoop. Voor het aansturen van
deze videostromen kan gebruikgemaakt worden van de eerder vermelde MediaControl-
en MediaSensor-knoop.
De MediaControl-knoop
Het moet voor de gebruiker mogelijk zijn het afspelen van de video te onderbreken of te
stoppen. Om deze functionaliteiten te implementeren kan gebruikgemaakt worden van
de MediaControl-knoop waarvan de definitie in figuur 8.3 getoond wordt. Als waarde
60
voor het url-veld dient een verwijzing naar een Object Descriptor te worden opgegeven.
In deze applicatie wordt dus een verwijzing geplaatst naar de eerder besproken OCR-
stroom. Aansturen van deze stroom heeft onmiddellijk effect op alle stromen die aan deze
OCR-stroom gelinkt zijn.
MediaControl
exposedField MFURL url []
exposedField SFTime mediaStartTime -1
exposedField SFTime mediaStopTime 3.40282e+038
exposedField SFFloat mediaSpeed 1
exposedField SFBool loop FALSE
exposedField SFBool preRoll TRUE
exposedField SFBool mute FALSE
exposedField SFBool enabled TRUE
eventOut SFBool isPreRolled FALSE
Figuur 8.3: De definitie van de MediaControl-knoop.
Met het veld mediaSpeed kan de snelheid waarmee de video afgespeeld wordt, beınvloed
worden. Een negatieve waarde zorgt ervoor dat de video achterwaarts afgespeeld wordt.
Dit veld zou kunnen gebruikt worden om terug te spoelen en door te spoelen in een video.
De waarde van loop geeft aan of de video na afloop automatisch herhaald moet worden
en met mute kan het tonen van de video onderbroken worden (de video loopt verder in de
achtergrond).
Met behulp van deze knoop en een Script-knoop sturen we het videofragment aan.
Volgende acties werden voorzien
• speel: de snelheid gelijkstellen aan 1
• pauze: de snelheid gelijkstellen aan 0 en de starttijd gelijkstellen aan -1
De velden mediaStartTime en mediaStopTime moeten als volgt geınterpreteerd wor-
den:
• mediaStartTime = -1: De video zal starten vanaf zijn huidig tijdstip. Als deze klok
reeds gestopt werd, zal de video afspelen vanaf het begin. Wanneer de klok enkel
gepauzeerd werd, zal de video verderspelen vanaf het huidige tijdstip.
• mediaStartTime ≥ 0: De video zal starten vanaf het opgegeven tijdstip. Wanneer
dit tijdstip groter is dan de totale duur van de video, zal de video niet afgespeeld
worden.
• mediaStopTime < mediaStartTime: De video blijft spelen tot het einde (en wordt
afhankelijk van het loop-veld herhaald).
61
• mediaStopTime ≥ mediaStartTime: De video blijft spelen tot de stoptijd bereikt
is.
De MediaSensor-knoop
De MediaSensor-knoop laat toe de huidige toestand van het object dat opgegeven werd in
het url-veld te achterhalen. Zo kunnen onder andere de totale duur (mediaDuration) en
de reeds verlopen tijd (mediaCurrentTime) opgevraagd worden. In deze applicatie worden
deze velden gebruikt om de gebruiker een tijdsaanduiding te geven van de speeltijd van
de video en om de positie van de schuifbalk te bepalen.
MediaSensor
exposedField MFURL url []
eventOut SFTime mediaCurrentTime 0
eventOut SFTime streamObjectStartTime 0
eventOut SFTime mediaDuration 0
eventOut SFBool isActive FALSE
eventOut MFString info []
Figuur 8.4: De definitie van de MediaSensor-knoop.
8.3.3 Ondertiteling via een animatiestroom
Hoewel er uiteraard andere methoden denkbaar zijn om ondertiteling in de scene te voor-
zien, wordt er in deze scene gebruikgemaakt van animatiestromen. Met elke taal waarin
ondertitels voorzien zijn associeren we een animatiestroom. Deze stromen worden net als
de video- en audiostromen gelinkt aan de OCR-stroom om ook de ondertitels synchroon
te laten lopen met het beeld en geluid.
RAP AT 5003 IN 4
REPLACE TXT.string BY ["Ze zijn gekomen voor mij."]
RAP AT 7000 IN 4
REPLACE TXT.string BY []
RAP AT 7002 IN 4
REPLACE TXT.string BY ["Wat willen ze?"]
Figuur 8.5: Commando’s in de animatiestroom voor de ondertiteling.
Een dergelijke animatiestroom bestaat dan uit een opeenvolging van commando’s om
62
de tekst op het scherm te wijzigen. In figuur 8.5 staan bijvoorbeeld volgende commando’s
voor de ondertiteling in stroom 4 opgesomd:
• 5003 milliseconden na de start van de stroom wordt de waarde van het String-
veld van de knoop met naam TXT (toegekend met het DEF-commando) gewijzigd in
"Ze ... voor mij.".
• 1997 milliseconden later wordt datzelfde veld leeggemaakt.
• 2 milliseconden na het vorige commando wordt de tekst "Wat willen ze?" als
ondertitel ingesteld.
8.3.4 Wisselen van audio, video en ondertiteling
BIFS voorziet de Conditional-knoop voor het conditioneel uitvoeren van commando’s. In
het buffer-veld (van het type SFCommandBuffer) van deze knoop kunnen BIFS-command
statements opgenomen worden. De waarde van het activate-veld op true plaatsen of
het reverseActivate op false zorgen ervoor dat deze commando’s uitgevoerd worden.
Conditional
eventIn SFBool activate FALSE
eventIn SFBool reverseActivate FALSE
exposedField SFCommandBuffer buffer
eventOut SFBool isActive FALSE
Figuur 8.6: Definitie van de Conditional-knoop.
Figuur 8.7: De gebeurtenissen voor het wijzigen van de video.
63
Gebruikmakend van deze knoop, de hierboven besproken werkwijze voor het opne-
men van de verschillende mediastromen in de scene en de gepaste definiering van enkele
routes is het betrekkelijk eenvoudig dynamisch te wisselen tussen de verschillende on-
dertitels, audio- en videostromen. Enkel de waarde van het url-veld in de juiste knoop
moet gewijzigd worden. Zoals in de applicatie van het vorige hoofdstuk wordt ook hier
gebruikgemaakt van prototypes voor het implementeren van knoppen. In figuur 8.7 wordt
als voorbeeld het wijzigen van de video door het klikken op een knop weergegeven. Links
op de figuur staan de gebeurtenissen beschreven en rechts de overeenkomstige delen van
de scenebeschrijving.
8.3.5 Sceneselectie
In de videospeler worden ook enkele knoppen voorzien waarmee de gebruiker naar bepaal-
de scenes in het videofragment kan springen. Dit kan op eenvoudige wijze gebeuren door
de waarde van het mediaStartTime-veld te wijzigen naar het tijdstip waarop de gewenste
scene start. Het codefragment uit figuur 8.8 illustreert dit.
DEF SETSCENE_1 Conditional
bufferREPLACE CONTROL.mediaStartTime BY 0.0
DEF SETSCENE_2 Conditional
bufferREPLACE CONTROL.mediaStartTime BY 8.4
DEF SETSCENE_3 Conditional
bufferREPLACE CONTROL.mediaStartTime BY 11.5
DEF SETSCENE_4 Conditional
bufferREPLACE CONTROL.mediaStartTime BY 19.7
DEF SETSCENE_5 Conditional
bufferREPLACE CONTROL.mediaStartTime BY 22.5
Figuur 8.8: Springen naar een scene in een video.
8.4 Scenebrowser
In de zonet besproken MPEG-4-applicatie is het dus mogelijk om tijdens het afspelen van
de video naar vooraf gedefinieerde scenes over te schakelen. Deze werkwijze wordt ook
toegepast in een andere applicatie die aansluit bij het eindwerk van een medestudent. In
die thesis [13] werden enkele algoritmes geımplementeerd voor het automatisch detecteren
64
Figuur 8.9: Door te klikken op de video wordt een taakbalk zichtbaar.
van scene-overgangen4 in een video. Deze gegevens worden door de hier besproken appli-
catie ingelezen en genereren een MPEG-4-presentatie die de gebruiker toelaat doorheen
die verschillende scenes te navigeren.
Concreet wordt een scene aangemaakt waarbij op de bronvideo kan geklikt worden om
een taakbalk te laten verschijnen (zie figuur 8.9). Op deze taakbalk zijn knoppen voorzien
om de video te onderbreken en te stoppen. De implementatie van deze functionaliteit
kwam eerder al aan bod. Verder is er ook een knop voorzien om de taakbalk opnieuw te
verbergen. Naast deze knoppen is er ook de mogelijkheid de gegevens van de verschillende
scenes te bekijken en naar een bepaalde scene in de video te springen. Deze taakbalk kan
door de gebruiker ook verplaatst worden op het scherm.
De meeste functionaliteiten van deze MPEG-4-presentatie werden reeds besproken.
In wat volgt worden nog enkele specifieke BIFS-constructies en de werking van de Java-
applicatie voor het genereren van de scene besproken. De broncode van deze applicatie is
beschikbaar op bijgevoegde CD-ROM.
8.4.1 Het keuzemenu
Voor de implementatie van het keuzemenu voor de sceneselectie wordt gebruikgemaakt
van de Layout-knoop (zie figuur 8.10. Deze groeperingsknoop zorgt voor een automati-
sche schikking van zijn kinderen in de voorziene ruimte. Er zijn enkele velden voorzien
waarmee men deze schikking kan beınvloeden (leftToRight geeft aan of de kindknopen
van links naar rechts of van rechts naar links moeten geschikt worden, topToBottom geeft
4We gebruiker hier de term scene. De vermelde thesis handelt eerder over het detecteren van ca-merashots dan het detecteren van scenes. Een scene moet dan aanzien worden als een verzamelingcamerashots die semantisch bij elkaar horen.
65
aan of de kindknopen van boven naar onder of van onder naar boven moeten geschikt
worden, wrap geeft aan of overgegaan moet worden naar een nieuwe regel wanneer de vol-
ledige breedte gebruikt is en met justify kan de uitlijning van de kindknopen bepaald
worden). Daarnaast zijn er ook enkele velden waarmee het scrollen van de kinderen kan
beınvloed worden. smoothScroll de waarde true geven zorgt voor een meer natuurlijke
scroll, scrollVertical geeft aan of er horizontaal of verticaal gescrolld moet worden en
scrollRate geeft de snelheid aan waarmee gescrolld moet worden (een negatieve waarde
zorgt voor scrollen in de andere richting).
Layout
eventIn MFNode addChildren []
eventIn MFNode removeChildren []
exposedField MFNode children []
exposedField SFBool wrap FALSE
exposedField SFVec2f size -1 -1 #QP=12
exposedField SFBool horizontal TRUE
exposedField MFString justify ["BEGIN"]
exposedField SFBool leftToRight TRUE
exposedField SFBool topToBottom TRUE
exposedField SFFloat spacing 1
exposedField SFBool smoothScroll FALSE
exposedField SFBool loop FALSE
exposedField SFBool scrollVertical TRUE
exposedField SFFloat scrollRate 0
Figuur 8.10: Definitie van de Layout-knoop.
Voor het keuzemenu geven we als kinderen aan deze Layout-knoop een verzameling
knoppen die overeenstemmen met de verschillende scenes in de video. Daarnaast voorzien
we 2 knoppen waarmee de gebruiker doorheen dit menu kan navigeren. Wanneer de
gebruiker met de muis over zo’n knop beweegt, wordt aan de scrollRate een waarde
verschillend van nul gegeven. Scrollen in de andere richting (met de tweede knop) gebeurt
zoals gezegd door het teken van de scrollRate te wijzigen. Wanneer de muis niet over
een knop beweegt, stellen we de scrollRate gelijk aan nul.
8.4.2 Verplaatsen van de taakbalk
Wat betreft de BIFS-scenebeschrijving van deze applicatie moet enkel nog verduidelijkt
worden hoe het mogelijk gemaakt wordt de taakbalk te laten verplaatsen door de gebrui-
ker. Hiervoor wordt gebruikgemaakt van de PlaneSensor2D waarvan de definitie in 8.11
getoond wordt. Deze knoop wordt opgenomen als kind in een groeperingsknoop en is van
toepassing op alle kinderen van die ouderknoop. In het beschouwde voorbeeld wordt deze
66
knoop dus opgenomen in dezelfde groep als het keuzemenu en de functieknoppen. Met
behulp van de velden maxPosition en minPosition kan dan aangegeven worden in welk
deel van de ruimte de gebruiker de taakbalk kan bewegen.
PlaneSensor2D
exposedField SFBool autoOffset TRUE
exposedField SFBool enabled TRUE
exposedField SFVec2f maxPosition 0 0
exposedField SFVec2f minPosition 0 0
exposedField SFVec2f offset 0 0
eventOut SFBool isActive FALSE
eventOut SFVec2f trackPoint_changed 0 0
eventOut SFVec2f translation_changed 0 0
Figuur 8.11: Definitie van de PlaneSensor2D-knoop.
8.4.3 Java-implementatie
Het java-programma vraagt de gebruiker de bestanden met de video-stroom, de audio-
stroom en de informatie over de scenes op te geven. De applicatie leest de scenegegevens in
en genereert een scenebeschrijving en een mp4-bestand met het resultaat zoals hierboven
besproken.
Bronbestand met scene-informatie
# Ouput_EdgeDetect
fps=24.005
(0,76);
[Cut];
(76,120);
[FadeIn];
(196,31);
[FadeIn];
(227,17);
[Cut];
(244,16);
...
Figuur 8.12: Voorbeeld van een bronbestand met scenebeschrijvingen.
Figuur 8.12 toont een voorbeeld van een bronbestand voor de applicatie zoals het
door de software, horende bij de vermelde thesis[13], gegenereerd wordt. De eerste lijn is
een commentaarregel die in deze bespreking geen betekenis heeft. De tweede vermeldt de
67
beeldsnelheid van de beschouwde video. De volgende lijnen moeten twee aan twee bekeken
worden. Hierbij bevat de eerste lijn een koppel gehele getallen waarbij het eerste getal
het volgnummer is van het frame waarop de scene start. Het tweede getal is de lengte (in
frames) van de scene. De tweede lijn van het lijnenpaar bevat een sleutelwoord dat bij die
scene hoort. In dit voorbeeld zijn deze sleutelwoorden de wijze waarop overgegaan wordt
van de vorige naar de huidige scene. Voor meer details hierover wordt verwezen naar [13].
Video- en audiostromen.
Er zijn verschillende bestandsformaten mogelijk voor de video en audio die gebruikt moet
worden. Voor de audio kan bijvoorbeeld de audiostroom uit een avi-bestand gebruikt
worden door pad/naar/bestand.avi#audio als bestand voor de audio op te nemen (de
video stroom uit een avi-bestand verkrijgt men door #video te gebruiker als achter-
voegsel. Ook kunnen elementaire stromen uit een mp4-bestand gebruikt worden (bv
pad/naar/bestand.mp4#10). Alle mogelijke formaten voor audio en video zoals in tabel
4.1 opgegeven zijn mogelijk.
68
Hoofdstuk 9
Besluit
In deze thesis werd een overzicht geboden van enkele opmaaktalen voor het beschrijven
van interactieve audiovisuele presentaties. Hierbij werd gestart van een overzicht van de
mogelijkheden van VRML en de uitbreidingen die X3D daarbij biedt. Na een beknopt
overzicht van BIFS en XMT werden enkele praktische toepassingen besproken.
Momenteel zijn de beschikbare tools voor het creeren van interactieve MPEG-4-pre-
sentaties heel beperkt in aantal. Dus hoewel deze standaard heel wat verbeteringen en
uitbreidingen biedt ten opzichte van VRML en X3D is het nog even wachten op een
echte doorbraak. Voor X3D en vooral voor VRML zijn wel tal van WYSIWYG-tools1
beschikbaar waardoor ook mensen met minder technische kennis interactieve scenes kun-
nen creeren. Ook voor het bekijken van X3D en VRML presentaties is heel wat (al dan
niet gratis) software beschikbaar. Op stabiele MPEG-4-scenebrowsers is het nog even
afwachten.
Met de in deze thesis gebruikte MPEG-4-tools was het nog niet mogelijk driedimensi-
onele scenes aan te maken. Het spreekt voor zich dat met 3D meer geavanceerde en meer
aantrekkelijke MPEG-4-scenes gegenereerd kunnen worden, zodat ook het voorbeeld uit
de inleiding van deze thesis tot de mogelijkheden zal behoren.
Een vervolg op deze thesis zou ook kunnen bestaan uit een praktische studie van de
verschillende uitbreidingen die MPEG-4 biedt ten opzichte van VRML en X3D. Denk
hierbij maar aan de vele mogelijkheden die haalbaar zijn wanneer binnen de scene een
communicatiekanaal met de server kan opengesteld worden. Afhankelijk van de invoer van
de gebruiker kan die server de scene dan gepast wijzigen. Ook het ontwikkelen van prak-
tische toepassingen waarbij gebruik gemaakt wordt van de IPMP-voorzieningen binnen
MPEG-4 kan een interessante piste voor praktische toepassingen vormen.
1What You See Is What You Get
69
Bijlage A
Inhoud bijgevoegde CD-ROM
In deze appendix wordt een overzicht gegeven van de inhoud van de bijgevoegde cd-rom.
Naast de presentaties die over deze thesis gegeven werden en deze thesis in pdf-formaat
bevat deze ook een aantal demo’s.
A.1 VRML
In de map ~/vrml kan een eenvoudige VRML-wereld gevonden worden. In deze we-
reld wordt gebruikgemaakt van een OrientationInterpolator-knoop, een TimeSensor-
knoop en een Script-knoop om een animatie aan te sturen waarbij de maan rond de
Aarde draait en de Aarde rond de zon (figuur A.1). Voor de sterrenhemel wordt gebruik-
gemaakt van een extern VRML-bestand. Voor het maan- en het aardoppervlak wordt
gebruikgemaakt van afbeeldingen.
Figuur A.1: Een animatie van de Aarde, de maan en de zon
70
A.2 X3D
A.2.1 filmzaal
De map ~/x3d/filmzaal/ op de cd-rom bevat de scene die afgebeeld werd in figuur 1.1
in de inleiding van deze thesis. Er wordt gebruikgemaakt van een extern bestand met een
model van een zetel. Met behulp van DEF- en USE-commando’s wordt met deze zetel een
rij van zetels opgebouwd. Deze rij krijgt ook een naam toegekend en wordt gebruikt om de
zaal met rijen zetels te vullen. Met behulp van een MovieTexture-knoop wordt een film
afgebeeld op het witte doek in de zaal. Ook wordt gebruikgemaakt van de SpotLight-
knoop om enkele spots aan het plafond te voorzien. Wanneer de gebruiker klikt op het
wit scherm (TouchSensor) wordt deze actie via een route naar een Script-knoop geleid.
De code in deze laatste knoop zorgt er dan voor dat de film gestart wordt en de lichten
gedoofd (of omgekeerd indien de film aan het spelen was).
A.2.2 kamer
In de map ~/x3d/kamer/ kan een 3D-wereld gevonden worden die een kamer voorstelt
waarin enkele objecten in opgenomen zijn om de interactiviteit met sensorknopen te illu-
streren.
Openen van een deur
De gebruiker kan op een deur klikken waardoor een animatie start die de deur opent (of
sluit). Hierbij wordt gebruikgemaakt van een TouchSensor die een TimeSensor start. De-
ze TimeSensor stuurt een OrientationtInterpolator aan die op zijn beurt de orientatie
van de deur wijzigt zodat deze opengaat. Deze deur werd geımplementeerd als een PROTO
voor eventueel hergebruik.
Een loeiende koe
Om het effect van een ProximitySensor te illustreren werd in de scene ook een model
van een koe opgenomen (uit een extern bestand). Wanneer de gebruiker te dicht bij deze
koe komt, begint deze te loeien. . .
Een film op televisie
In de kamer is ook een model van een televisie opgenomen. Hierop zijn ook een start-
en stopknop voorzien die de film starten en stoppen. Dit illustreert het opnemen van
71
externe bronnen in de scene. Voor dit televisietoestel is ook gebruikgemaakt van LOD-
knoop1. Deze knoop laat toe bepaalde delen van de 3D-wereld te verbergen wanneer de
gebruiker niet in de buurt is. Dit om de X3D-browser nutteloos rekenwerk te besparen.
In dit voorbeeld werden 3 toestanden van het televisietoestel geımplementeerd. Indien de
gebruiker ver genoeg is, wordt het televisietoestel getekend als een zwarte balk, wanneer
de gebruiker nadert wordt een textuur aan die balk toegevoegd en wanneer de gebruiker
vlakbij het toestel is worden het filmfragment en de start- en stopknop zichtbaar. Deze
drie toestanden worden getoond in figuur A.2.
Figuur A.2: Drie niveaus van detail met behulp van een LOD-knoop
Er wordt nog gebruikgemaakt van een PlaneSensor om de gebruiker de mogelijkheid te
geven het schilderij op de muur te verplaatsen en een SphereSensor waarmee de gebruiker
een zwevende kubus kan doen draaien. Voor elk van de beproken functionaliteiten werd
ook een ViewPoint gedefinieerd. Dit laat de gebruiker toe om naar voorop vastgelegde
plaatsen in de ruimte te bewegen, hoe dit precies gebeurt hangt af van de X3D-browser.
A.3 MPEG-4
De map ~/mpeg4/ bevat de verschillende MPEG-4-applicaties die in de tekst beschreven
werden. ~/mpeg4/gladiator/ bevat de scene die besproken werd in paragraaf 5.4.4,
~/mpeg4/mediaspeler/ bevat de applicatie uit hoofdstuk 8 en ~/mpeg4/scenebrowser/
de Java-toepassing besproken in paragraaf 8.4. In figuur A.3 wordt de gebruikersinterface
van deze applicatie afgebeeld.
De trailer-mozaık uit hoofdstuk 7 kan teruggevonden worden in de map ~/mpeg4/mo-
zaiek/. Van deze laatste zijn twee versies beschikbaar. De eerste is een versie waarbij de
1LOD = Level of Detail
72
trailer van het lokaal bestandssysteem ingeladen wordt. Bij de tweede versie wordt ge-
bruikgemaakt van een streaming server. Voor het bekijken van deze demo moeten trailers
op een streaming server2 te staan. De url’s die gebruikt worden in de scenebeschrijving zijn
van de vorm rtsp://localhost/<<trailer>>.mp4. Mogelijk moet de scenebeschrijving
aangepast worden.
Figuur A.3: De GUI van de scenebrowser-applicatie
2Hiervoor kan bijvoorbeelde de gratis Darwin Streaming Server van Apple gebruikt worden (ziehttp://developer.apple.com/darwin/projects/streaming
73
Bijlage B
Een overzicht van het GPAC-project
Voor de applicaties uit hoofdstuk 7 en hoofdstuk 8 werd gebruik gemaakt van de tools van
het GPAC-project[10] (GPAC Project On Advanced Content). Met dit project wil men
een klein en flexibel alternatief bieden voor de MPEG-4 Systems referentiesoftware 1. Op
dit ogenblik is er enkel ondersteuning voor 2D maar een eerste versie die ook 3D voorziet
wordt weldra beschikbaar gesteld. Deze software wordt ontwikkeld en onderhouden aan
de Ecole Nationale Superieure des Telecommunications2 te Parijs en is beschikbaar onder
de GPL-licentie3.
Volgende tools zijn beschikbaar binnen dit project:
• MP4Box: Deze applicatie verzamelt enkele functionaliteiten voor het produceren
van MPEG-4-inhoud en bevat volgende mogelijkheden:
– Toevoegen van de nodige informatie aan mp4-bestanden voor het stromen van
deze bestanden.
– Genereren van het mp4-bestand horende bij een scenebeschrijving opgesteld in
XMT-A of BIFSText.
– Genereren van de scenebeschrijving in XMT-A of BIFSText formaat uit een
mp4-bestand.
– Omzetten van mp3- en avi-bestanden naar mp4-bestanden.
– Toevoegen van mediastromen aan een scene of stromen extraheren uit een
scene.
Veder biedt MP4Box nog enkele extra functionaliteiten zoals bijvoorbeeld het om-
zetten van een bestand met ondertitels naar een BIFS-Anim-stroom.
1zie http://www.iso.ch/iso/en/ittf/PubliclyAvailableStandards/14496-5 Compressed directories/2zie http://www.enst.fr3GPL = GNU General Public License, zie http://www.gnu.org/licenses/gpl.html
74
• Osmo4-GPAC: Een 2D MPEG-4 Systems speler. Zowel lokale mp4-bestanden als
gestroomde scenes kunnen afgespeeld worden (gebruik makend van het Real Time
Streaming Protocol4).
• V4Studio: Dit is een heel experimentele WYSIWYG-tool voor de creatie van MPEG-
4-presentaties. Een stabiele versie van deze tool is niet voor de nabije toekomst
gepland.
Voor veel taken wordt gebruik gemaakt van externe plugins. Een overzicht van de
gebruikte plugins is beschikbaar op de webpagina van het project.
4RTSP - http://www.rtsp.org/
75
Bibliografie
[1] Web3D consortium. http://www.web3d.org/.
[2] ECMAScript Language Specification. December 1999. http://www.ecma-
international.org/publications/standards/Ecma-262.htm.
[3] ISO/IEC 14772-1:1997. Information Technology - Computer Graphics and Image
Processing. The Virtual Reality Modeling Language (VRML) - Part1: Functional
Specification and UTF-8 Encoding. 1997.
[4] ISO/IEC 14772-2:2004. Information technology – Computer graphics and image pro-
cessing. The Virtual Reality Modeling Language (VRML) - Part 2: External autho-
ring interface (EAI). 2004.
[5] ISO/IEC FDIS 19775-1:200x. Information technology Computer graphics and image
processing Extensible 3D (X3D). 2003.
[6] O. Avaro, A. Eleftheriadis, C. Herpel, G. Rajan, and L. Ward. Mpeg-4 systems:
Overview. Signal Processing: Images Communication, 15:281–298, 2000.
[7] C. Concolato and J.C. Dufourd. Comparison of mpeg-4 bifs and some other mul-
timedia description languages. In Workshop and exhibition on MPEG-4, San Jose,
June 2002.
[8] C. Concolato, J.C. Dufourd, and J.C. Moissinac. Creating and encoding of cartoons
using mpeg-4 bifs: Methods and results. IEEE Transactions on circuits and systems
for video technology, 13:1129–1135, 2003.
[9] A.R. Fernandes. VRML Interactive Tutorial.
http://www.lighthouse3d.com/vrml/tutorial/.
[10] Jean Le Feuvre. GPAC Project on Advanced Content. http://gpac.sourceforge.net.
[11] Vapour Technology Ltd. Floppy’s VRML97 Tutorial, 2002.
http://web3d.vapourtech.com/tutorials/vrml97/.
76
[12] K. Michelle, D. Wood, and L. Cheok. Extensible MPEG-4 Textual Format (XMT).
2000. http://www.acm.org/sigs/sigmm/MM2000/ep/michelle/.
[13] Stefaan Moens. Studie en analyse van geavanceerde algoritmes voor videosegmenta-
tie. Master’s thesis, Universiteit Gent, 2004.
[14] ISO/IEC JTC1/SC29/WG11 N3534. Mpeg-4 requirements document. 2000.
[15] F. Pereira and T. Ebrahimi. The MPEG-4 Book. Prentice Hall, 2002.
[16] J. Signes, Y. Fisher, and A. Eleftheriadis. Mpeg-4’s binary format for scene descrip-
tion. Signal Processing: Image Communication, 15:321–345, 2000.
[17] P. Van de Poel. Telenet iDTV Platform-Diensten. 2004.
http://www.roulartaseminars.be/nl/idtv/default.htm.
[18] W3C. Synchronized Multimedia Integration Language (SMIL 2.0). W3C Recommen-
dation. August 2001. http://www.w3.org/TR/smil20/.
[19] W3C. Scalable Vector Graphics (SVG) 1.1 Specification. W3C Recommendation.
January 2003. http://www.w3.org/TR/SVG/.
[20] W3C. Extensible Markup Language (XML) 1.0 (Third Edition). W3C Recommenda-
tion. February 2004. http://www.w3.org/TR/2004/REC-xml-20040204/.
[21] A.E. Walsh and M. Bourges-Sevenier. MPEG-4 Jump-Start. Prentice Hall, 2002.
77
Lijst van figuren
1.1 Een virtueel cinemabezoek . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Een vereenvoudigde scenegraaf . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Specificatie van een kegel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Definiering van een route . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Gebruik van DEF en USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 VRML-code voor een rode balk . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Met behulp van een avatar kan de gebruiker door een VRML-wereld navi-
geren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 De TouchSensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Combinatie van TimeSensor en OrientationInterpolator voor het rond-
draaien van een kubus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Een script-knoop kan opgenomen worden in de route-definities . . . . . . . 14
3.1 Een rode bol beschreven in het XML- en het VRML-formaat . . . . . . . . 19
3.2 In een X3D-bestand wordt het gebruikte profiel aangeduid. . . . . . . . . . 22
4.1 MPEG-4 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 De AudioSource-knoop verwijst naar een audiostroom via een OD . . . . . 32
4.3 Er kan een hierarchie toegewezen worden aan de verschillende elementaire
stromen in een Object Descriptor . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Het BIFS-Anim protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 De QuantisationParameter-knoop wordt gebruikt voor efficientere code-
ring van de kleur van een object. . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Een eenvoudige scene in XMT-A formaat . . . . . . . . . . . . . . . . . . . 42
5.2 De scene uit figuur 5.1 in BIFSText . . . . . . . . . . . . . . . . . . . . . . 43
78
5.3 Een diavoorstelling beschreven in XMT-Ω . . . . . . . . . . . . . . . . . . 44
5.4 Een presentatie beschreven in XMT-Ω . . . . . . . . . . . . . . . . . . . . 46
7.1 De gebruiker kan een keuze maken tussen verschillende beschikbare trailers. 51
7.2 Nadat de gebruiker een van beide versies gekozen heeft, wordt de trailer
getoond. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3 De definitie van een knoop. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4 De definitie van de ImageButton-knoop. . . . . . . . . . . . . . . . . . . . 53
7.5 De definitie van de TextLink-knoop. . . . . . . . . . . . . . . . . . . . . . . 53
7.6 De definitie van de Form-knoop. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.7 Gebruik van de Form-knoop voor de positionering van de objecten. . . . . 55
7.8 De Object Descriptors verwijzen naar bestanden op een streaming-server . 56
8.1 Een videospeler in MPEG-4. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.2 De verschillende mediastromen wijzen naar een OCR-stroom om onderlinge
synchronisatie te verkijgen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.3 De definitie van de MediaControl-knoop. . . . . . . . . . . . . . . . . . . . 61
8.4 De definitie van de MediaSensor-knoop. . . . . . . . . . . . . . . . . . . . . 62
8.5 Commando’s in de animatiestroom voor de ondertiteling. . . . . . . . . . . 62
8.6 Definitie van de Conditional-knoop. . . . . . . . . . . . . . . . . . . . . . . 63
8.7 De gebeurtenissen voor het wijzigen van de video. . . . . . . . . . . . . . . 63
8.8 Springen naar een scene in een video. . . . . . . . . . . . . . . . . . . . . . 64
8.9 Door te klikken op de video wordt een taakbalk zichtbaar. . . . . . . . . . 65
8.10 Definitie van de Layout-knoop. . . . . . . . . . . . . . . . . . . . . . . . . 66
8.11 Definitie van de PlaneSensor2D-knoop. . . . . . . . . . . . . . . . . . . . . 67
8.12 Voorbeeld van een bronbestand met scenebeschrijvingen. . . . . . . . . . . 67
A.1 Een animatie van de Aarde, de maan en de zon . . . . . . . . . . . . . . . 70
A.2 Drie niveaus van detail met behulp van een LOD-knoop . . . . . . . . . . . 72
A.3 De GUI van de scenebrowser-applicatie . . . . . . . . . . . . . . . . . . . . 73
79
Lijst van tabellen
3.1 Bestandsgroottes van beide bestandsformaten in X3D . . . . . . . . . . . . 19
3.2 De X3D-bestandstypes en hun extensies . . . . . . . . . . . . . . . . . . . 20
4.1 Ondersteunde mediatypes in MPEG-4 [10] . . . . . . . . . . . . . . . . . . 29
4.2 Enkele onderdelen van een Elementary Stream Descriptor . . . . . . . . . . 33
5.1 Bestandsgroottes van een aantal MPEG-4-scenebeschrijvingen . . . . . . . 44
5.2 Tijdscontainers in XMT-Ω . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Tijdsattributen in XMT-Ω . . . . . . . . . . . . . . . . . . . . . . . . . . 45
80