Implementatie en uitbreiding van de Media Fragments-speci ... · Implementatie en uitbreiding van...

Faculteit Ingenieurswetenschappen en Architectuur

Vakgroep Electronica en Informatiesystemen

Voorzitter: prof. dr. ir. Jan Van Campenhout

Implementatie en uitbreiding van de

Media Fragments-specificatie op Android

door

Tim DE MEY

Promotoren: prof. dr. ir. Rik Van de Walle, Brecht Stubbe

Begeleiders: Wim Van Lancker, dr. Davy Van Deursen

Masterproef ingediend tot het behalen van de academische graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Academiejaar 2011–2012

Voorwoord

Graag wil ik even de tijd nemen om iedereen te bedanken die er direct of onrechtstreeks voor

gezorgd heeft dat ik deze masterproef kon aanvatten.

Eerst en vooral gaat mijn dank uit naar Davy voor zijn geduld als ik even niet mee was, voor

het nalezen van de teksten en om mij er steeds vriendelijk op te wijzen als er te weinig structuur

zat in de tekst. Ik wil zeker ook Wim niet vergeten, die jammer genoeg sinds januari er niet

meer bij kon zijn.

Verder wil ik ook de promotoren prof. Rik Van de Walle en Brecht Stubbe bedanken voor het

onderwerp. Ik programmeer zeer graag en ben dan ook met plezier de uitdaging aangegaan om

op een onbekend platform een applicatie te maken.

Ik bedank ook de persoon achter de schuilnaam ’WTFMAN’ (wiens echte naam ik niet ken)

vanop het 9lives-forum om zijn GSM aan mij te verkopen, zodat ik thuis over een echt Android-

apparaat beschikte om op te werken.

Tim De Mey, mei 2012

Toelating tot bruikleen

”De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen

van de masterproef te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met be-

trekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten

uit deze masterproef.”

“The author gives permission to make this master dissertation available for consultation and to

copy parts of this master dissertation for personal use.

In the case of any other use, the limitations of the copyright have to be respected, in particular

with regard to the obligation to state expressly the source when quoting results from this master

dissertation.”

Tim De Mey, mei 2012

Implementatie en uitbreiding van deMedia Fragments-specificatie op Android

door

Tim DE MEY

Masterproef ingediend tot het behalen van de academische graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Academiejaar 2011–2012

Promotoren: prof. dr. ir. Rik Van de Walle, Brecht Stubbe

Begeleiders: Wim Van Lancker, dr. Davy Van Deursen

Vakgroep Electronica en Informatiesystemen

Voorzitter: prof. dr. ir. Jan Van Campenhout

Faculteit Ingenieurswetenschappen

Universiteit Gent

Samenvatting – In het weblandschap worden media-objecten nog steeds als ’foreign objects’

beschouwd: zij worden niet door de browser zelf maar door een plugin gerenderd. Bovendien

kunnen deze objecten niet op een URI-gebaseerde manier gefragmenteerd worden. De Media

Fragments-specificatie tracht dit laatste probleem op te lossen. In deze masterproef wordt Media

Fragments uitgelegd, alsook waarom er nood is aan implementaties van deze specificatie. Er werd

ook een Media Fragments parser geschreven en een implementatie op het Android-platform.

Trefwoorden – Media Fragments, Android, Mobiel, HTML5, standaardisatie

Extending and implementing the Media Fragmentsspecification on the Android platform

Tim De Mey

Supervisor(s): Davy Van Deurzen, Rik Van de Walle

Abstract—In the web universe, media objects are still con-sidered ’foreign objects’, as they are being rendered by aplugin rather than the browser itself. Moreover, these typesof objects cannot be fragmented in a URI-based manner.This article briefly describes the Media Fragments specifica-tion, a URI-based approach for fragmenting media objects,and explains the need for implementations of this specifica-tion. In addition, we investigate how Media Fragments canbe extended in a useful manner. In the rest of the article, wedescribe the steps taken to create a Media Fragments com-patible video player on the Android platform, and explainthe investigations we made to diminish an Android powereddevice’s data traffic consumption when using Media Frag-ment URI’s.

Keywords— Media Fragments, Android, Mobile, HTML5,Standardisation

I. Introduction

MEDIA objects are still considered ’foreign objects’due to two reasons. First, they are treated by

browsers as a black box. More specifically, browsers relyon plugins, such as Flash, to have audio and video get ren-dered. Secondly, media objects cannot be fragmented ina standardized, URI-based manner. In contrast with this,objects of certain MIME-types can be fragmented as listedin Table I [2], [3].

TABLE I

MIME-types and their URI-based fragmentation

application/pdf ...book.pdf#page=34text/html ...index.html#somethingtext/plain ...text.txt#line=32,40

HTML5 solves the black box problem by introducing the<video> and <audio> tags [4]. Media objects referenced ina web page are thus no longer hidden from the browser asthey were by usage of the generic <object> and <embed>

HTML tags. On the other hand, there is still no stan-dardized way to fragment media objects via the URI. TheMedia Fragments specification tries to address this issue.

II. The Media Fragments specification

Media Fragments specifies how media objects can befragmented via the fragment identifier within a URI [1].Given a URI, the ’primary resource’ - e.g. the referenceto a media file - can be distinguished from the fragmentidentifier by the ’#’ character (see also Table I). The spe-cification defines fragmentation along four dimensions:• Temporal dimension - example: ...#t=10,20. The videowill play from the 10th to 20th second.

• Spatial dimension - example: ...#xywh=10,20,40,60.A rectangle starting at 10 pixels from the left, 20 pixelsfrom the top, 40 pixels wide and 60 pixels high, will bedrawn on top of the video, with the outside area darkenedor some similar effect, to draw attention to the rectangle’sinside content.• Track dimension - example: ...#track=video. Thetrack named ’video’ will be extracted from the media con-tainer.• ID dimension - example: ...#id=chapter-1. Thenamed temporal segment ’chapter-1’ will be played.

Multiple key-value pairs can be entered by glueing themwith a ’&’, e.g. ...#t=10,20&xywh=10,20,40,60.

III. Problem Definition

The Media Fragments specification aims to be stan-dardized. To achieve this, implementations for the spe-cification have to be created in order to get feedback of im-plementors and to prove that the specification is useful andimplementable. This way the specification can be adaptedand improved. There are already such implementations,but not on mobile devices. Such implementations wouldcontribute greatly to the specification, as these devices aregenerally limited in bandwidth; Using Media Fragments’temporal dimension, mobile video players wouldn’t needto buffer data beyond the point where the temporal frag-ment ends. In addition, a mobile implementation of thespecification would prove that Media Fragments is also im-plementable on devices other than computers, as all imple-mentations have been made on such devices.

Spatial fragmentation defines a static rectangle. Thismay cause some difficulties when trying to focus spatiallyon a moving or an enlarging object within a video. Thisexample indicates that Media Fragments should be investi-gated to determine whether there is room for improvementor extensions.

IV. Media Fragments on Android

A mobile ’app’ has been built on the Android platform.This app uses a Media Fragments parser library, which wasdeveloped first.

A. Media Fragments URI parser library

The Media Fragments parser takes a single URI as itsinput and parses the fragment identifier as a Media Frag-ments URI. First, the fragment identifier is split into key-value pairs. Secondly, percent-decoding is applied (e.g.’%74’ becomes ’t’). Then, for each pair, a specific value

parser will be selected based on the valid key (e.g. ’t’, de-noting the temporal dimension, will induce the use of aTemporalValueParser).

When parsing stops, all valid pairs can be requested inan object-oriented manner. The parser is available as alibrary (.jar file) for usage in any application.

B. Android Media Fragments player

Not all of the Media Fragments dimensions are supportedin the app as it was technically impossible to implementthem (e.g. extracting a track from a media container).The spatial dimension is fully implemented and the tempo-ral dimension can be supplied by using Normal Play Time(NPT) notation.

A URI can be entered at the start screen. A secondscreen will be displayed which shows the parsing results.The third component is the actual Media Fragments en-abled video player. This component can be selected ashandling component by a user, for example, when clickingon a link in a browser that is referring to a video resource.

Figure 1 shows two screenshots of the app. It is possibleto zoom in on a spatial fragment. When the device rotates,the video will rotate accordingly to match the device’s neworientation. The temporal fragment is indicated by theyellow color on the progress bar.

Fig. 1. 2 screenshots

C. Bandwidth consumption

Various efforts have been made to make our video playerjust download the video data needed to display a particulartemporal fragment, specified by a Media Fragments URI,as the standard Android SDK doesn’t provide any way ofcontrolling bandwidth usage.

• Compiling and using the FFmpeg library on Android tocalculate the needed byte ranges.• Using a proxy server which will only download the neededdata, and blocks requests to the real outside server for datanot within the allowed range.• Write the needed data to a file first, while replacing all’missing data’ with stuff bytes.

x,y,w,h x,y,w,hkeep

x,y,w,hinterpolate

temporal fragment

t0s 20s 40s 60s 80s

Fig. 2. A schematic visualisation of a trajectory

• Using the Vitamio media library, where normally thestandard Android SDK media library would be used. Vita-mio allows to control the data buffer size, where the SDKdoes not.Except for the Vitamio library approach, all these methodshave several disadvantages. Using Vitamio led to stutteringvideo.

V. Extending Media Fragments

A new dimension has been proposed to Media Frag-ments. The trajectory dimension (traj key) describes arectangle’s dimensions and coordinates in function of time.Multiple rectangle-time pairs can be specified, and flagsspecify the transition behaviour between such pairs. Fig-ure 2 shows a visualisation for the Media Fragments URIt=7,70&traj=x,y,w,h;k;x,y,w,h;40;i;x,y,w,h, wherethe ’k’-flag and ’i’-flag stand for ’keep’ and ’interpolate’,respectively. The first one makes the current rectangle stayfixed until the next rectangle is specified. The second onemakes the rectangle gradually move and grow or shrink tothe dimensions of the next rectangle.

VI. Conclusions

We investigated how Media Fragments could be imple-mented on a mobile device, and chose Android as the mo-bile platform. A Media Fragments compatible video playerhas been created, and we investigated how data trafficcould be diminished, given that a video player wants toplay only a temporal fragment of a video. Furthermore,we proposed an extension to Media Fragments to supportspatial-temporal fragmentation.

References

[1] Raphael Troncy, Erik Mannens, Silvia Pfeiffer andDavy Van Deursen. Media Fragments URI 1.0 (ba-sic), W3C Proposed Recommendation, Available athttp://www.w3.org/TF/media-frags/.

[2] E. Wilde and M. Duerst. URI Fragment Identi-fiers for the text/plain Media Type, Available athttp://tools.ietf.org/html/rfc5147

[3] Adobe Solutions Network, PDF Open Param-eters, Available at http://partners.adobe.com/-public/developer/en/acrobat/PDFOpenParameters.pdf

[4] Ian Hickson. HTML5 - A vocabulary and associated APIsfor HTML and XHTML, W3C Working Draft, Available athttp://www.w3.org/TR/html5/.

INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 ’Foreign objects’ versus ’first-class citizens’ . . . . . . . . . . . . . . . . . 1

1.1.2 Evolutie van het inbedden van media in webpagina’s . . . . . . . . . . . . 2

1.1.3 Bestaande URI-fragmentatiespecificaties . . . . . . . . . . . . . . . . . . . 3

1.1.4 URI-fragmentatie voor media-objecten . . . . . . . . . . . . . . . . . . . . 5

1.1.5 Introductie van de Media Fragments-specificatie . . . . . . . . . . . . . . 6

1.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Literatuurstudie 9

2.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Syntax en semantiek van Media Fragments . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 t – Temporele as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 xywh – Spatiale as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 track – Track-as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.4 id – Benoemde hoofdstukken . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Historiek en huidige status van de specificatie . . . . . . . . . . . . . . . . . . . . 13

2.4 Verwerking van Media Fragments-URI’s . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Efficiente datatrafiek op het Android-besturingssysteem 17

3.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Bestaande software-architectuur m.b.t. mediamanipulatie . . . . . . . . . . . . . 18

3.3 Mogelijkheden tot besparing van bandbreedte . . . . . . . . . . . . . . . . . . . . 19

INHOUDSOPGAVE ii

3.3.1 Wegschrijven naar een bestand . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 FFmpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.3 Proxyserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.4 File spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.5 Andere mediabibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Ontwikkelen van een Media Fragments URI-parser 27

4.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Parse-algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Unit tests en logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 Broncode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Ontwikkelen van een compatibele mediaspeler 35

5.1 Requirements en features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Algemene app-levenscyclus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Broncode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Uitbreiding van de Media Fragments-specificatie 41

6.1 Spatiaal-temporele fragmentatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1.2 Invoering van het traj-sleutel-waardepaar . . . . . . . . . . . . . . . . . . 42

6.1.2.1 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.2.2 Ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.2.3 Notatie in het URI-fragment . . . . . . . . . . . . . . . . . . . . 44

6.1.3 Implementatie in de parser . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1.4 Implementatie in de videospeler . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2 Andere uitbreidingsmogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Conclusies 48

Bijlagen 49

INHOUDSOPGAVE iii

A Software Development Kit (SDK) 50

B Native Development Kit (NDK) 52

C Java Native Interface (JNI) 54

D FFmpeg 56

E Traject-URI formaatspecificatie 58

Bibliografie 59

Lijst van figuren 61

Lijst van tabellen 62

Lijst van afkortingen

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

IDE Integrated Development Environment

JNI Java Native Interface

NDK Native Development Kit

NPT Normal Play Time

PCM Pulse Code Modulation

PDF Portable Document Format

SDK Software Development Kit

SMPTE Society of Motion Picture and Television Engineers

URI Uniform Resource Locator

VM Virtual Machine

INLEIDING 1

Hoofdstuk 1

Inleiding

1.1 Situering

1.1.1 ’Foreign objects’ versus ’first-class citizens’

In het hedendaagse weblandschap spreken we over ’first-class citizens’ en ’foreign objects’.

Hiermee bedoelt men dat bepaalde objecten wel en andere dan weer niet beschouwd worden

als een volwaardig onderdeel van het weblandschap. Dit komt omdat de HTML-specificatie oor-

spronkelijk ontwikkeld was om tekst weer te geven op een geordende manier, en geen rekening

hield met het al dan niet ingebed weergeven van allerlei objecten zoals PDF-bestanden, applets,

audio en video.

Het ontwikkelen en toevoegen van plugins maakte dit later wel mogelijk. Flash is zo’n plugin,

en YouTube1 is een zeer goed voorbeeld van een website die hiervan gebruik maakt om video’s

in zijn webpagina in te bedden en af te spelen. Tot januari 2010 was een Flash-installatie

noodzakelijk om er video’s te kunnen bekijken. Sindsdien is er ook een HTML5-experiment

bezig, waarbij videoplayback niet langer steunt op Flash. Gebruikers kunnen echter nog steeds

de keuze maken tussen beide technologieen.

Plugins zijn eigenlijk een vreemde eend in de bijt; zij breiden de mogelijkheden van een browser

uit naar zaken die niet in de HTML-specificatie zijn opgenomen. Objecten die van dergelijke

plugins afhangen, zoals audio en video, of een PDF-viewer of een Java-applet, worden ’foreign

objects’ genoemd.

1http://youtube.com

http://youtube.com

1.1 Situering 2

1.1.2 Evolutie van het inbedden van media in webpagina’s

’Foreign objects’, in het bijzonder audio- en video-objecten, konden voor het bestaan van

HTML5 ingeladen worden in een webpagina m.b.v. de <embed>-tag in de broncode. De

plugin gelinkt met het MIME-type van het gerefereerd object, was dan verder verantwoordelijk

voor de correcte weergave van de inhoud van deze tag. Een object inbedden met MIME-type

application/x-shockwave-flash geeft bijvoorbeeld aan dat de Flash-plugin vereist is om dat

object weer te geven.

Het volgend voorbeeld toont het gebruik van de <embed>-tag aan voor het inbedden van een

Flash-video. Het stukje code werd uit de broncode van een YouTube-pagina2 geplukt (de waarde

van het flashvars-attribuut werd weggelaten voor het overzicht te bewaren):

Voorbeeld 1 (YouTube Flash player - <embed>)

<embed type=” app l i c a t i o n /x−shockwave−f l a s h ” s r c=”http :// s . ytimg . com/yt/←↩

swfbin /watch as3−v f l−u99wM. swf ” width=”640” id=”movie p layer ” he ight=”←↩

390” f l a s h v a r s=” . . . ” a l l ow s c r i p t a c c e s s=”always ” a l l ow f u l l s c r e e n=” true ” ←↩

bgco lo r=”#000000”>

De <embed>-tag werd echter in 1995 door de Netscape-browser geıntroduceerd3 en was voor

HTML5 nooit opgenomen in een HTML-specificatie [6, 2]. De meeste browsers ondersteunen

het gebruik van deze tag wel, maar ’officieel’ is het dus zeker niet: een webpagina die van deze

tag gebruik maakt, zal niet correct valideren met de gekende W3C-validator4.

De reden voor de introductie van deze ’bastaard-tag’ kan worden verklaard door de onvol-

maaktheid van de toenmalige HTML-specificatie en daarom werd met HTML 4.0 de <object>-

tag ingevoerd in 1997. In de specificatie van HTML 4.0 staat letterlijk:

Previous versions of HTML allowed authors to include images (via IMG) and applets

(via APPLET). These elements have several limitations:

� They fail to solve the more general problem of how to include new and future

media types. (...)

2http://www.youtube.com/watch?v=cieYQ_8JUmQ3http://1997.webhistory.org/www.lists/www-talk.1995q3/0578.html via http://www.webmonkey.com/

2008/09/history_of_img_and_embed_tags/4http://validator.w3.org/

http://www.youtube.com/watch?v=cieYQ_8JUmQ

http://1997.webhistory.org/www.lists/www-talk.1995q3/0578.html

http://www.webmonkey.com/2008/09/history_of_img_and_embed_tags/

http://www.webmonkey.com/2008/09/history_of_img_and_embed_tags/

http://validator.w3.org/

1.1 Situering 3

To address these issues, HTML 4.0 introduces the OBJECT element, which offers

an all-purpose solution to generic object inclusion. (...)

Het volgend voorbeeld toont hoe een YouTube-video op een correcte manier kan worden ingebed

gebruik makend van de <object>-tag.

Voorbeeld 2 (YouTube Flash player - <object>)

<ob j e c t type=” app l i c a t i on /x−shockwave−f l a s h ” s t y l e=”width :425 px ; he ight :350←↩

px ; ” data=”http ://www. youtube . com/v/7 6B6vwE83U”><param name=”movie” ←↩

value=”http ://www. youtube . com/v/7 6B6vwE83U” />

</ ob j e c t>

Tot hier toe dienden audio en video nog steeds door een plugin te worden verzorgd, zij het sinds

HTML 4.0 het best via de <object>-tag. Daar brengt HTML5 verandering in.

Eerst nog een voorbeeld. Zoals gezegd in voorgaande subsectie, voert YouTube een experiment

uit waarbij de video’s niet langer steunen op Flash. De video uit Voorbeeld 1 kan inderdaad

bekeken worden in YouTube’s HTML5-beta5, en dan is de broncode van de webpagina als volgt:

Voorbeeld 3 (YouTube HTML5 player - <video>)

<video c l a s s=”video−stream” x−webkit−a i r p l a y=” al low ” s r c=”http :// o−o .←↩

p r e f e r r e d . belgacom−bru1 . v5 . l s c a che1 . c . youtube . com/videoplayback ? sparams←↩

=. . . ” data−youtube−id=”cieYQ 8JUmQ”></ video>

In Voorbeeld 3 staat een vrij nieuwe tag: HTML5 introduceert de <video>- en <audio>-tags.

D.w.z. dat deze types media door de uitgeklede browser gerenderd worden indien deze de

HTML5-specificatie correct en volledig implementeert; er zijn geen plugins nodig. Anders gezegd:

omdat audio en video m.b.v. deze twee tags onafhankelijk worden van plugins, zijn ze niet langer

’foreign objects’ maar ’first-class citizens’. Of toch niet?

1.1.3 Bestaande URI-fragmentatiespecificaties

Video en audio zijn inderdaad nog geen volwaardige ’first-class citizens’, want met de nieuwe

tags wordt nog steeds een volledig media-object gerefereerd. In contrast daarmee kunnen we

5http://www.youtube.com/html5

http://www.youtube.com/html5

1.1 Situering 4

MIME-type Voorbeeld Omschrijving

application/pdf ...book.pdf#page=34 Springt naar pagina 34 in book.pdf

text/html ...index.html#something Springt naar het element op de webpagina

met identifier “something”

text/plain ...text.txt#line=32,40 Selecteert lijnen 32 t.e.m. 40 in test.txt

Tabel 1.2: Bestaande URI-fragments voor bepaalde MIME-types

m.b.v. de <a>-tag naar webpagina’s, maar specifieker, naar onderdelen van die webpagina’s

linken indien we gebruik maken van een zogenaamd ’URI fragment’ [1].

Voorbeeld 4 (URI fragments voor MIME-type text/HTML)

<div id=” f i r s t ”> . . .</ div>

<div id=” second”>

<a h r e f=” index . html#f i r s t ”>This links to the div with id ' first '</a>

</ div>

De hash (#) in bovenstaand voorbeeld is het karakter waar het ’URI fragment’ of ’fragment

identifier’ begint. Wat na dit karakter komt, geeft aan waar er intern naar wordt gerefereerd

binnenin index.html, en dat is het div-element met identifier “first”. Als deze bestaat, dan

springt de browser na het klikken op de link naar deze plaats in de webpagina.

Algemeen gezien zijn webpagina’s infeite objecten met MIME-type text/html. Het zijn niet

de enige objecten die gefragmenteerd kunnen worden; enkele andere objecten met bijhorende

MIME-types worden gegeven in tabel 1.2. De populairste ’fragment identifier’ hoort echter bij

text/html. Voor alle MIME-types in de tabel zijn specificatiedocumenten beschikbaar [10, 5, 6].

Op YouTube is het mogelijk om video’s te laten starten vanaf een bepaald tijdstip op een URI-

gebaseerde manier.

Voorbeeld 5 (YouTube’s URI-gebaseerde mediafragmentatie)

http : // www . youtube . com/watch ?v=suRsxpoAc5w#t=01m14s

1.1 Situering 5

Deze notatie (#t=00m00s) is niet gestandaardiseerd, en werkt naar alle waarschijnlijkheid enkel

op YouTube. De volgende sectie bespreekt deze problematiek: de afwezigheid van een gestan-

daardiseerde manier om media-objecten te fragmenteren.

1.1.4 URI-fragmentatie voor media-objecten

Video- en audio-objecten zijn nog steeds geen ’first-class citizens’. Met de <video>- en <audio>-

tags gespecificeerd in HTML5 kunnen we deze media wel inbedden in een webpagina zonder de

nood aan een plugin, echter is de mogelijkheid tot mediafragmentatie d.m.v. een URI-fragment

nog steeds afwezig.

URI-fragmentatie op objecten met MIME-type video/* en audio/* dient te gebeuren op een

nieuwe, andere manier; media is in de eerste plaats tijdsgebaseerd dus is het zinvol om deze bvb.

te fragmenteren op basis van tijdspunten.

De onmogelijkheid tot video- en audiofragmentatie in de HTML5-specificatie leidt tot de vol-

gende drie tekortkomingen:

� Het is onmogelijk om de video (automatisch) te laten starten of stoppen op gegeven tijds-

punten (temporele as);

� Bij video is het onmogelijk om te focussen op een zogenoemde ’region of interest’; d.w.z.

dat er een spatiaal gebied, veelal een rechthoek, wordt afgebakend en ’in de schijnwerpers

wordt gezet’ (spatiale as);

� Het is onmogelijk om enkel een bepaalde deelverzameling van alle beschikbare tracks

(video, audio, ondertiteling) af te spelen. Bvb. speel de video af met de Nederlandse

i.p.v. de Engelse audio (track-as).

In subsectie 1.1.3 werd vergeleken met het intern refereren van webpagina’s. Deze vergelijking

gaat op, omdat de context behouden blijft: een URI-fragment op zichzelf is zinloos. De URI die

refereert naar het volledig ongefragmenteerd mediabestand blijft steeds beschikbaar, net zoals

een webpagina ook volledig wordt ingeladen.

Video en audio zullen pas ’first-class citizens’ zijn wanneer ze zich niet langer als een black

box gedragen, m.a.w. als het mogelijk wordt om te refereren naar fragmenten hiervan. De

fragmentatie kan dan gebeuren op basis van eigenschappen van media-objecten: een temporeel

gebied, een spatiaal gebied, ...

1.2 Probleemstelling 6

1.1.5 Introductie van de Media Fragments-specificatie

Om video en audio tot ’first-class citizens’ te promoveren moet URI-fragmentatie gespecificeerd

worden voor de overeenkomstige MIME-types.

Media Fragments is een specificatie met het oog op URI-gebaseerde fragmentatie van video en

audio [8]. Analoog met de voorbeelden uit tabel 1.2 wordt een mediafragment (waar media

staat voor video of audio) gerefereerd door een URI, waarvan het gedeelte voor de hash (#)

verwijst naar de zogenoemde ’primary resource’ (het eigenlijke object waarop fragmentatie wordt

toegepast) en het gedeelte achter de hash de ’fragment identifier’ is.

Voorbeeld 6 (Mediafragmentatie met Media Fragments)

<video s r c=”movie .mp4#t=10 ,20” />

<video s r c=”movie .mp4#xywh=100 ,100 ,480 ,360 ” />

Voorbeeld 6 geeft een voorbeeld van temporele fragmentatie (t) en spatiale fragmentatie (xywh).

Deze fragmentatie is inderdaad URI-gebaseerd [4]. De Media Fragments-specificatie wordt uit-

voerig besproken in hoofstuk 2.

1.2 Probleemstelling

Om Media Fragments te kunnen standaardiseren, moet de eenvoud, bruikbaarheid en implemen-

teerbaarheid ervan aangetoond worden.

Er zijn reeds implementaties gemaakt: als Firefox-plugin6, een parser voor Media Fragments-

URI’s in Javascript7, een webpagina die gebruik maakt van Javascript om de videospeler aan te

sturen8, en tenslotte een speler in HTML5 (dus met <video>-tag in de broncode!) en Flash9[7].

Temporele fragmentatie al geımplementeerd in Webkit, een open source browser engine10, zonder

het gebruik van plugins.

Er zijn echter nog geen implementaties op mobiele platformen. Deze apparaten beschikken

typisch over lagere bandbreedte wat hen minder geschikt maakt om lange video’s op te bekijken

6http://www.w3.org/2008/WebVideo/Fragments/code/plugin/7http://tomayac.com/mediafragments/mediafragments.html8http://www.annodex.net/~silvia/itext/mediafrag.html9http://ninsuna.elis.ugent.be/MediaFragmentsPlayer10https://bugs.webkit.org/show_bug.cgi?id=65838

http://www.w3.org/2008/WebVideo/Fragments/code/plugin/

http://tomayac.com/mediafragments/mediafragments.html

http://www.annodex.net/~silvia/itext/mediafrag.html

http://ninsuna.elis.ugent.be/MediaFragmentsPlayer

https://bugs.webkit.org/show_bug.cgi?id=65838

1.3 Methodologie 7

waarvan de gebruiker enkel een deel wil zien. Media Fragments kan hier een uitweg bieden:

door het opgeven van een URI-fragment weet de speler op voorhand welk deel van de video

moet gedownload worden. De bruikbaarheid van Media Fragments zou hierdoor aangetoond

kunnen worden.

Hoe meer implementaties van de specificatie, hoe meer wordt aangetoond dat Media Fragments

implementeerbaar en bruikbaar is. Een implementatie op een mobiel apparaat helpt dan ook

om Media Fragments een stap dichter te krijgen bij standaardisatie, gezien de specificatie dan

door een extra platform wordt ondersteund.

De Media Fragments-specificatie dient ook onderzocht te worden op uitbreidingen. Deze mogen

de specificatie niet te complex maken en er moet aangetoond worden dat zij van enig nut zijn.

De probleemstelling van deze masterproef is dus samengevat:

� Er is nood aan een implementatie van een videospeler op een mobiel apparaat, die de

specificatie ondersteunt.

� Er moet onderzocht worden hoe efficient met bandbreedte kan worden omgesprongen,

gegeven dat slechts een fragment van de video bekeken wordt.

� De specificatie moet worden onderzocht op uitbreidingen. Deze uitbreidingen dienen ook

geımplementeerd te worden.

1.3 Methodologie

Er wordt eerst uitgebreid kennis gemaakt met de Media Fragments-specificatie door het lezen

van artikels en de eigenlijke specificatie.

Het schrijven van de applicatie zal gebeuren op een Android-apparaat. Hiervoor werden ver-

schillende introducties en tutorials gelezen alvorens aan de slag te kunnen gaan. Er worden

verschillende methodes geımplementeerd en getest om de efficientie van het bandbreedtegebruik

te onderzoeken.

Er wordt een parser voor Media Fragments-URI’s geschreven. Deze parser wordt opgevat als

bibliotheek en zal gebruikt worden door de applicatie op het Android-platform.

De Media Fragments-specificatie wordt onderzocht op nuttige uitbreidingen. Er wordt bekeken

hoe deze uitbreidingen zich zullen vertalen in het URI-fragment, in welke mate deze botsen

1.3 Methodologie 8

met de bestaande specificatie en hoe de uitbreidingen kunnen geımplementeerd worden in de

applicatie.

LITERATUURSTUDIE 9

Hoofdstuk 2

Literatuurstudie

Zoals gezegd in hoofdstuk 1, zullen we de Media Fragments-specificatie implementeren in een

applicatie op Android. In de eerste plaats wordt de huidige Media Fragments-specificatie

bestudeerd en wordt bekeken hoe deze kan uitgebreid en eventueel verbeterd worden. Verder in

dit hoofdstuk bekijken we de bestaande media-architectuur op Android-aangestuurde appa-

raten en wordt onderzocht hoe en in welke mate we deze bestaande functionaliteit op het

Android-platform kunnen aanwenden om bandbreedte te besparen bij het afspelen van een

mediafragment, daar we typisch slechts een deel van de ’primary resource’ willen afspelen.

2.1 Introductie

Media Fragments is een specificatie die omschrijft hoe objecten met MIME-type video/* of

audio/* kunnen gefragmenteerd worden, gebaseerd op een URI. Zoals de MIME-types al doen

vermoeden, betreft het media-objecten.

Gegeven een door een URI gerefereerde ’primary resource’, in dit geval dus een video- of audio-

object, bekomen we een afgeleide video, respectievelijk audiotrack, die enkel en alleen bestaat

uit een fragment van het origineel. Zoals gezegd in vorig hoofdstuk, moet fragmentatie op

media gebeuren op een andere manier dan het gebeurt met objecten met een ander MIME-type.

Met een ’media fragment’ wordt dan ook een temporeel of spatiaal deelgebied of een selectie

van tracks bedoeld, afgeleid van de ’primary resource’; ook combinaties hiervan zijn toegestaan

binnen de Media Fragments-specificatie.

In de rest van deze sectie wordt de syntax en semantiek van Media Fragments toegelicht en volgt

2.2 Syntax en semantiek van Media Fragments 10

een evaluatie van de huidige specificatie. Andere, voor deze masterproef niet relevante delen uit

de specificatie worden niet besproken; hiervoor wordt verwezen naar het specificatiedocument [8].

2.2 Syntax en semantiek van Media Fragments

Media Fragments specificeert ’fragments identifiers’ die bestaan uit een of meerdere door het

’&’-karakter gescheiden sleutel-waardeparen, waarvoor de notatie <sleutel>=<waarde> geldt.

Voorbeeld 7 (Media Fragments sleutel-waardeparen)

http : // example . com/movie . mp4#t=3,16&xywh=10 ,20 ,150 ,100

Er zijn hier twee sleutels: t en xywh. Ze hebben respectievelijk de waarden 3,16

en 10,20,150,100. http://example.com/movie.mp4 refereert naar de ’primary re-

source’ movie.mp4. Met de ’fragment identier’ t=3,16&xywh=10,20,150,100 wordt

een fragment afgeleid dat start op seconde 3 en eindigt op seconde 16. Bovendien

wordt enkel een deel van het totaalbeeld getoond: een rechthoek vanaf pixel (10,20),

150 pixels breed en 100 pixels hoog.

Er zijn 4 mogelijke sleutels: t (”temporele as”), xywh (”spatiale as”), track (”track-as”) en id.

Een waarde bestaat soms uit twee delen: de eenheid en het suffix. De eenheid is dan impliciet

of expliciet aanwezig. Zo is in voorbeeld 7 de waarde van de xywh-sleutel uitgedrukt in pixels,

omdat deze eenheid de standaard is, maar het spatiaal gebied (de rechthoek) kon evengoed in

percentages worden uitgedrukt.

Voorbeeld 8 (Media Fragments eenheden)

http : // example . com/movie . mp4#xywh=10 ,20 ,150 ,100

http : // example . com/movie . mp4#xywh=pixel : 10 ,20 ,150 ,100

Deze twee fragmenten zijn identiek aan elkaar, omdat pixel het standaardeenheid

is voor de sleutel xywh. Het suffix is gegeven door 10,20,150,100.

http : // example . com/movie . mp4#xywh=percentage : 25 , 25 ,50 ,50

Dit fragment toont een spatiaal gebied uit de ’primary resource’: een gecentreerde

rechthoek die de helft zo breed en de helft zo hoog is als de originele afmetingen. De

eenheid percentage moet er expliciet staan, want het is niet het standaardeenheid.


De syntax van een suffix kan verschillen naargelang de gebruikte eenheid.

In de volgende subdeelsecties wordt dieper ingegaan op elk van de vier mogelijke sleutels en

bijhorende eenheden (indien van toepassing). Voor details zoals exacte syntax van suffixen

wordt verwezen naar de Media Fragments-specificatie.

2.2.1 t – Temporele as

De temporele as is wellicht de belangrijkste. Hiermee kan een temporeel fragment van een

’primary resource’ worden afgeleid.

Algemeen is de syntax t=eenheid:a,b waarbij a en b tijdspunten zijn die het temporeel fragment

specificeren. Bij het weglaten van a wordt de begintijd van de ’primary resource’ bedoeld, en

analoog voor b de eindtijd. Voor de temporele as bestaan er drie soorten eenheden: npt, smpte

en clock.

� npt: dit staat voor Normal Play Time. Dit formaat wordt gebruikt als we de start-

en/of stoptijd van het fragment willen aangeven met een tijdsafzet vanaf het begin van de

’primary resource’. Dit is het standaardeenheid.

� smpte, smpte-25, smpte-30, smpte-30-drop: deze eenheden kunnen gebruikt worden

indien exacte framenauwkeurigheid vereist is. De verschillende nummers slaan op het

aantal frames per seconde in de video.

� clock: dit eenheid11 is van nut bij livestreams. Er wordt geen tijdsafzet meegegeven zoals

bij het npt-eenheid, maar een exacte datum en tijd waarop gestreamed werd.

Voorbeeld 9 (Media Fragments temporele as)

http : // example . com/movie . mp4#t=10 ,20

http : // example . com/movie . mp4#t=npt : 15

http : // example . com/movie . mp4#t=npt : , 1 7

Het eerste fragment speelt de video af vanaf seconde 10 en eindigt het afspelen op

seconde 20. Het tweede fragment start op seconde 15 en stopt op het einde van de

video en het derde fragment start bij het begin en stopt op seconde 17.

11idem


2.2.2 xywh – Spatiale as

Met deze sleutel kan een spatiaal gebied worden geextraheerd uit een video.

Er zijn juist twee eenheden:

� pixel: dit is de standaardeenheid en het drukt de positie vanaf de linkerbovenhoek en

grootte van het spatiaal gebied uit in pixels.

� percent: drukt de positie vanaf de linkerbovenhoek en grootte van het spatiaal gebied uit

in percentages van de originele breedte en hoogte.

Een voorbeeld voor de spatiale as werd al gegeven in voorbeeld 8.

2.2.3 track – Track-as

De track-as selecteert een track uit het mediabestand, zoals een video-, audio- of ondertitel-

ingstrack.

Deze sleutel kent geen eenheden. De bijhorende waarden moeten uiteraard wel terug te vinden

zijn in de gerefereerde video- of audiocontainer, zodat een bestaande track kan geextraheerd

worden.

Voorbeeld 10 (Media Fragments temporele as)

http : // example . com/movie . mp4#track=video&track=subtitle

Dit fragment selecteert de tracks met namen ’video’ en ’subtitle’ uit de videocon-

tainer.

2.2.4 id – Benoemde hoofdstukken

Deze waarde van de id-sleutel is een identifier, die in de videocontainer de naam of het nummer

is van een hoofdstuk (in een film, bvb.), wat dus leidt tot een temporeel fragment.

Deze sleutel kent net zoals track geen eenheden.

Voorbeeld 11 (Media Fragments id)

http : // example . com/movie . mp4#id=chapter−1

Dit extraheert de sectie uit de video met naam ’chapter-1’.

2.3 Historiek en huidige status van de specificatie 13

Status Datum publicatie

W3C Working Draft 17.12.2009




W3C Candidate Recommendation 01.12.2011

W3C Proposed Recommendation 15.03.2012

Tabel 2.1: Historiek van de Media Fragments-specificatie

2.3 Historiek en huidige status van de specificatie

De specificatie is al sinds 2009 in ontwikkeling en heeft al verschillende stadia doorgemaakt:

’Working Draft’, ’Candidate Recommendation’ en ’Proposed Recommendation’. Op de W3C-

website12 vinden we een (Engelstalige) uitleg voor deze termen.

� ’Working Draft’ is de indicatie dat de specificatie beschreven in het document nog in

ontwikkeling is.

� ’Candidate Recommendation’ indiceert dat de specificatie stabiel is. Er worden implemen-

taties en feedback verwacht.

� ’Proposed Recommendation’ duidt aan dat er implementaties zijn gemaakt. De specificatie

kan nu geevalueerd worden.

De verschillende stadia voor de Media Fragments-specificatie zijn weergegeven in tabel 2.1.

Media Fragments bevindt zich in het ’Proposed Recommendation’-stadium. In deze versie van

de specificatie zijn niet alle hierboven beschreven assen en eenheden nog opgenomen. De meest

recente versie van Media Fragments specificeert volgende assen:

� Temporele as (t): enkel npt-eenheid

� Spatiale as (xywh): zowel percent- als pixel-eenheid

De temporele prefixen clock en smpte en varianten, de track- en id-as zijn dus niet langer

opgenomen.

12http://www.w3.org/Consortium/Process/Process-19991111/tr.html

http://www.w3.org/Consortium/Process/Process-19991111/tr.html

2.4 Verwerking van Media Fragments-URI’s 14

2.4 Verwerking van Media Fragments-URI’s

Het gebruik van Media Fragments staat een videospeler toe om efficienter gebruik te maken van

bandbreedte. De speler weet namelijk meteen op welke posities het afspelen begint en eindigt;

hierdoor hoeft enkel die data gedownload te worden, die overeenstemt met het afgebakend tijds-

gebied.

Deze beschouwing is beschreven in een Working Draft van de Media Fragments-specificatie [9].

Het omschrijft op welke manier een videospeler de juiste data kan binnenhalen, ook wanneer het

zelf niet in staat is om het tijdsgebied te vertalen in byte-offsets. De onderhandelingen tussen

videospeler (of abstracter, de ’client’ of ’User Agent’) en server zijn beschreven in het document

met HTTP en RTSP. De eenvoudigste situatie wordt getoond in voorbeeld 12.

Voorbeeld 12 (Verbeterd bandbreedtegebruik)

Een webpagina heeft een video ingebed die verwijst naar de volgende URI:

http : // www . example . com/video . ogv#t=10 ,20

De videospeler weet hoe het het opgegeven tijdsgebied kan vertalen naar byte-offsets,

heeft de video niet in zijn buffer en stuurt een HTTP-request naar de server:

GET /video . ogv HTTP /1 .1

Host : www . example . com

Accept : video/*

Range : bytes=19147−22890

De Range-parameter geeft aan dat niet de gehele resource moet teruggestuurd wor-

den, maar enkel het aangegeven bytebereik. Als alle randvoorwaarden voldaan zijn

(bestand aanwezig, aangevraagd bytebereik bestaat, ...) dan zal de server antwoor-

den met een Partial Content-response:

HTTP /1 .1 206 Partial Content

Accept−Ranges : bytes

Content−Length : 3743

Content−Type : video/ogg

Content−Range : bytes 19147−22880/35614993

Etag : ”b7a60−21f7111−46f3219476580”

{binary data}

Voorbeeld 12 is letterlijk overgenomen uit de specificatie en beschrijft het scenario wanneer

2.5 Evaluatie 15

de User Agent (UA) het bytebereik zelf kan bepalen en het fragment voor de eerste keer wordt

aangevraagd. Figuur 2.1 toont de communicatie tussen verschillende actoren voor dit voorbeeld.

Ook deze figuur is overgenomen uit een Working Draft van de specificatie [9].

Figuur 2.1: Het opvragen van de nodige data voor een temporeel fragment.

2.5 Evaluatie

De Media Fragments-specificatie tracht uniformiteit te krijgen in het weblandschap m.b.t. URI-

gebaseerde fragmentatie op media-objecten, net zoals er andere types objecten bestaan waar

URI-gebaseerde fragmentatie al op gespecificeerd is. In combinatie met HTML5 geeft dit enige

voordelen:

� Het renderen van audio en video gebeurt door de browser waarin deze media wordt

afgespeeld en niet langer door een plugin. Ontwikkelaars kunnen meteen ondersteuning

voorzien en niet te hoeven vertrouwen op een plugin waar zij geen controle over hebben.

Dit kan de stabiliteit van browsers alleen maar ten goede komen.

� Met een Media Fragments-URI die rechtstreeks of onrechtstreeks verwijst naar een tem-

poreel fragment, hoeft nooit teveel data te worden gedownload. Indien het eindtijdstip

van het fragment werd meegegeven in de URI, kan berekend worden welke data precies

2.5 Evaluatie 16

moet gedownload worden om dat fragment af te spelen. Dit bespaart datatrafiek i.v.m.

bufferingstechnieken.

� De combinatie van HTML5 en Media Fragments leidt tot een korte, krachtige en betekenisvolle

notatie in de broncode van een webpagina.

� Uniformiteit m.b.t. URI-gebaseerde fragmentatie.

Toch kan de Media Fragments-specificatie nog uitgebreid worden.

� Spatiale fragmentatie is statisch. De rechthoek blijft gedurende het ganse fragment staan

en beweegt niet mee. Er is dus nog plaats in de specificatie voor een spatiaal-temporele

as.

� Een rechthoek kan voldoende blijken in veel gevallen, maar er zijn situaties denkbaar

waarin andere, of meerdere vormen tegelijkertijd nuttig blijken.

EFFICIENTE DATATRAFIEK OP HET ANDROID-BESTURINGSSYSTEEM 17

Hoofdstuk 3

Efficiente datatrafiek op het

Android-besturingssysteem

3.1 Introductie

De website voor Android-ontwikkelaars omschrijft Android als volgt13:

Android is a software stack for mobile devices that includes an operating system,

middleware and key applications.

Het programmeren op Android gebeurt hoofdzakelijk in de programmeertaal Java. Android

bevat een VM, ’Dalvik’, die de Java-apps draait. Voor het schrijven van pure Java-apps is de

SDK (zie bijlage A) voldoende.

Voor stukken code die zeer performant moeten zijn, kan in C of (gelimiteerd) in C++ worden

geprogrammeerd. Hierbij komt Android’s NDK van pas (zie bijlage B). Het aanspreken van

C-code vanuit de Java-app gebeurt dan met JNI (zie bijlage C).

Het ontwikkelen van een Media Fragments-applicatie (“app”) op een door Android aangestuurd

apparaat vereist vooraf het onderzoeken van de bestaande software-architectuur m.b.t. het

manipuleren van media. De app moet namelijk Media Fragments-URI’s syntactisch, maar ook

semantisch kunnen interpreteren, en voor dat laatste is soms metadata van het af te spelen

mediabestand vereist zoals de afmetingen van een video.

13http://developer.android.com/guide/basics/what-is-android.html

http://developer.android.com/guide/basics/what-is-android.html

3.2 Bestaande software-architectuur m.b.t. mediamanipulatie 18

Verder moet worden nagegaan in welke mate toegang en controle kan worden verkregen over func-

tionaliteit die verborgen is in Android’s bovenste laag – de SDK – bijvoorbeeld de manier waarop

videodata wordt gedownload of gestreamed met het oog op bandbreedtebesparing. Hierbij kan

het nuttig zijn om toegang te hebben tot de data zelf (de bits).

3.2 Bestaande software-architectuur m.b.t. mediamanipulatie

In de SDK vinden we slechts enkele klassen terug die enigszins de benodigde functionaliteit

bieden: MediaMetadataRetriever, AudioTrack en MediaPlayer.

� MediaMetadataRetriever is in staat om metadata uit mediabestanden te halen. Dit laat

toe om Media Fragments-URI’s semantisch te interpreteren, zoals bijvoorbeeld nodig is bij

het gebruik van de track- en id-sleutels (zie subsecties 2.2.3 en 2.2.4).

� AudioTrack is een klasse die toelaat om audio af te spelen, waarbij de input bestaat uit

bits (en geen abstractie hiervan zoals bestanden, URI’s, ...). Dit maakt het mogelijk om

het binnentrekken van de data los te koppelen van het afspelen van de media. Enig nadeel:

de audiodata moet met PCM14 geencodeerd zijn. Bovendien gaat het hier enkel om audio,

dus voor video biedt dit geen oplossing.

� MediaPlayer laadt media in, speelt het af en voorziet in start-, stop- en doorspoel-

mogelijkheden, waarbij technische details verborgen zijn. Via deze klasse kan ook ele-

mentaire metadata worden opgevraagd, zoals afmetingen van een video.

Bij enkele vroege tests met de MediaPlayer-klasse, leren we dat Android’s ingebouwde media-

speler enkel data downloadt vanaf het punt dat er wordt afgespeeld. Echter, de speler stopt niet

met downloaden tot het einde van de video of audiotrack bereikt is. Indien een temporeel frag-

ment werd aangevraagd, is dit zeer ongewenst gedrag m.b.t. de lagere bandbreedte die typisch

is bij mobiele apparaten (bvb. via het GSM-netwerk). Of, bij het bekijken van een temporeel

fragment van een video in hoge kwaliteit, zal een enorme hoeveelheid data nutteloos gedownload

worden.

Uit al het voorgaande trekken we 3 conclusies:

14Pulse Code Modulation: een ongecomprimeerd audioformaat dat op Windows meestal voorkomt met .wav-

extensie

3.3 Mogelijkheden tot besparing van bandbreedte 19

Header Header

Fragmentdata Fragmentdata

0000...

...0000

Figuur 3.1: Niet gedownloade data wordt vervangen door nullen.

� Het semantisch interpreteren van Media Fragments-URI’s is mogelijk, gegeven de URI zelf

en de MediaMetadataRetriever-klasse;

� De app kan gebruik maken van MediaPlayer voor het afspelen van video;

� Bandbreedtebesparing wordt moeilijk met de SDK en er moet dus verder gezocht worden

naar oplossingen hiervoor.

3.3 Mogelijkheden tot besparing van bandbreedte

Wellicht het belangrijkste aspect van Media Fragments is de temporele fragmentatie. In de

achtergrond zou enkel die data uit het media-object nodig zijn die overeenstemt met het aangevraagd

fragment.

De voorgaande subsectie leert ons echter dat bandbreedte besparen moeilijk wordt met de SDK.

In de volgende subsecties worden enkele pogingen besproken om dit probleem op te lossen.

3.3.1 Wegschrijven naar een bestand

Het idee bestaat eruit om, gegeven een niet-lokale mediabron, enkel de header data te down-

loaden, gevolgd door de nodige data die overeenstemt met het aangevraagd temporeel fragment.

Vervolgens wordt op het Android-apparaat exact hetzelfde bestand weggeschreven maar de niet-

gedownloade data wordt vervangen door nullen (zie figuur 3.1).

Er werd nagegaan of een Android-apparaat in staat was om het ’half’ bestand nog steeds af te

spelen binnenin het temporeel gebied. Met het Java-programma Isoviewer15 (gebouwd op de

’mp4parser’-bibliotheek) werd de algemene structuur van een MP4-bestand bestudeerd[3], en op

welke manier in dit formaat de blokken video- en audiodata op metaniveau worden gerefereerd

15http://code.google.com/p/mp4parser/

http://code.google.com/p/mp4parser/


in de header. Eens vertrouwd met deze container kon m.b.v. een hexadecimale editor een

groot aantal bytes vervangen worden door nulbytes. Belangrijk hierbij is dat we vervangen tot

juist aan de positie waar een datablok start. Er kan namelijk niet van eender waar in de data

begonnen worden met decoderen - men moet steeds starten van een zogenaamd ’random access

point’. Dit is een videodatablok dat decodeert tot een volledig videoframe, en niet afhangt van

voorgaande of volgende frames. In de header van een MP4-bestand worden de byte-offsets naar

deze random access points in een gecomprimeerde lijst opgeslaan - handig voor het snelzoeken in

een video. Met deze lijst bepalen we op welke posities data kan worden vervangen door nullen.

Er ontstaat dus een nieuw bestand met een groot aantal nutteloze bytes. Bij het afspelen op

het Android-apparaat is het belangrijk dat we de video eerst ’doorspoelen’ naar het temporeel

fragment, en dan pas laten afspelen. De videospeler-app zou kunnen crashen op plaatsen in het

bestand waar nullen de originele data vervangen.

Het resultaat hiervan is dat het werkt. Er kan afgespeeld worden binnenin het temporeel frag-

ment; daarbuiten zal de speler crashen.

Als we het extraheren van de data voor het temporeel fragment nu automatiseren, hebben we

infeite een oplossing voor het bandbreedteprobleem. Echter zijn er enkele grote nadelen bij deze

aanpak:

� Het is niet formaat-onafhankelijk. Er moet voorzien worden in een implementatie om

elk door Android ondersteund formaat te kunnen analyseren om zo de juiste databytes

te extraheren. Uiteraard kan beroep worden gedaan op verschillende Java-bibliotheken,

maar of bevatten deze bugs, of bestaan ze gewoon niet voor een bepaald formaat, of

kunnen deze niet op Android worden gebruikt; het laatste heeft te maken met het feit dat

op Android-apparaten de Dalvik VM wordt gebruikt en niet een uitgebreidere VM zoals

op computers.

� Het feit dat er een nieuw bestand moet gecreeerd worden maakt deze methode traag. Niet

alleen moeten de nodige bytes eerst worden weggeschreven omdat we afspelen van een

bestand, maar ook de nutteloze nulbytes. In het geval dat het temporeel gebied zich verop

in de video situeert, ontstaat er een groot aantal nutteloze bytes die allen moeten worden

opgeslaan. Dit scenario is bijvoorbeeld sowieso onhaalbaar bij video’s met hoge resolutie

of van lange duur.


� Op mobiele apparaten is het beschikbaar geheugen typisch klein, wat het wegschrijven van

nutteloze data nog onaantrekkelijker maakt.

Het eerste probleem i.v.m. formaatonafhankelijkheid zou eventueel kunnen opgelost worden met

FFmpeg. Aangezien deze C-bibliotheek zowat alle gekende videoformaten ondersteunt, kunnen

we metadata op een abstracte manier ophalen. Dit wordt besproken in subsectie 3.3.2.

3.3.2 FFmpeg

FFmpeg is een framework geschreven in C voor het afspelen, coderen, decoderen, transcoderen,

muxen, demuxen, filteren, ... van video. Het is gratis en biedt ondersteuning voor vrijwel alle

gangbare formaten en codecs. Het steunt hierbij op de mogelijkheden van verschillende libraries

zoals onder meer libavcodec en libavformat.

FFmpeg zou de oplossing kunnen zijn voor het bandbreedteprobleem. Via de libraries is het

namelijk mogelijk om alle metadata uit een video te extraheren op een abstracte en formaaton-

afhankelijke manier, in tegenstelling tot Android SDK waar enkel de niet-technische informatie

uit de header toegankelijk is. Met deze metadata kan dan bepaald worden waar de data voor

het aangevraagd temporeel fragment zich bevindt in het videobestand.

Er stellen zich wel enkele problemen:

� FFmpeg is geschreven in C. Kunnen we dit framework compileren voor een Android device?

� Kunnen we de FFmpeg-methodes aanspreken vanuit de Java-app?

� Kunnen we de juiste metadata extraheren? En verder: gezien we nutteloze data niet

downloaden, moet eerst de gestripte header geanalyseerd worden. Zal FFmpeg correct

werken met een videobestand waarvan enkel de header overblijft?

FFmpeg compileren voor gebruik onder Android werd al gedaan16, net zoals het aanspreken van

de code vanuit de Java-kant van de app17. In de testopstelling werd de native code gecompileerd

naar armeabi-architectuur.

Metadata-extractie met FFmpeg werkt goed op complete bestanden, maar niet op bestanden

die bestaan uit enkel headerdata. Alle statische metadata zoals titel, auteur, ... kan steeds

16http://www.roman10.net/how-to-build-ffmpeg-for-android/17http://www.roman10.net/how-to-build-android-applications-based-on-ffmpeg-by-an-example/

http://www.roman10.net/how-to-build-ffmpeg-for-android/

http://www.roman10.net/how-to-build-android-applications-based-on-ffmpeg-by-an-example/


uitgelezen worden, maar de applicatie crasht echter bij het berekenen van de data-offset van

het temporeel fragment. FFmpeg itereert namelijk door de data, en vereist dat deze data ook

effectief bestaat. Bij een test waarbij de data vanaf het vijfde random access point uit een

videobestand verwijderd werd, crashte FFmpeg inderdaad in de 5de iteratie. Het verwijderen

van deze data gebeurde net zoals in vorige subdeelsectie door gebruik te maken van Isoviewer

en een hexadecimale editor.

Voor meer details i.v.m. het gebruik van FFmpeg in Android-apps wordt verwezen naar Bijlage D.

FFmpeg biedt dus geen uitweg voor het bandbreedteprobleem. Op dit punt werd beslist om

FFmpeg te laten voor wat het is. Het aanpassen van FFmpeg-code is enerzijds een delicate en

tijdrovende operatie, anderzijds ligt het te ver van het eigenlijke doel van deze masterproef.

3.3.3 Proxyserver

Een andere mogelijkheid is het implementeren van een valse HTTP-server op het Android-

apparaat. Wanneer de te bouwen applicatie een Media Fragments URI krijgt, zal hij de in-

gebouwde videocomponent uit de SDK een herbouwde URI meegeven die verwijst naar een

onbestaand bestand op de valse server. Op het moment dat de ingebouwde videocomponent

de video progressief wil downloaden (afspelen tijdens het downloaden), ’onderschept’ de valse

server deze aanvraag. Aangezien de valse server wordt opgezet door de app, kent deze de Media

Fragments parameters die werden meegegeven met de oorspronkelijke URI. De valse server zal

dan enkel die bytes downloaden die overeenstemmen met het aangevraagd temporeel fragment;

vraagt de ingebouwde videocomponent bytes aan buiten dat bereik dan stuurt de valse server

een HTTP-bericht terug dat dit niet mogelijk is. Figuur 3.2 illustreert deze aanpak.

Bij deze aanpak zijn er opnieuw enkele problemen.

� De ingebouwde videocomponent kan zich onverwacht gedragen, als deze niet de data krijgt

waar om gevraagd werd. Die zou eeuwig kunnen wachten, of simpelweg crashen. In beide

gevallen zal de applicatie onbruikbaar zijn. Bovendien kan de ingebouwde videocomponent

veranderen met elke update aan het Android besturingssysteem. Rommelen met de manier

waarop de ingebouwde videospeler data downloadt, lijkt dus niet aangewezen.

� Een bijkomend probleem is dat de valse server moet weten hoe het bytebereik berekend

wordt, gegeven een temporeel gebied in de video. Dit is formaatafhankelijk en dus zou


http://localhost/movie.mp4

seekto()

onSeekCompleted-event

data 0-100000

data 0-100000

data 0-100000

onBufferingUpdate-event

data 100000-165000

data 100000-165000

data 100000-165000

data 100000-200000

onBufferingUpdate-event

getCurrentPosition()

position

getCurrentPosition()

position

stop()

start()

onPrepared-event

data 0-100000

A:App B:Videocomponent C:Proxyserver D:example.com

Figuur 3.2: De lokale proxyserver (vandaar het localhost-adres) zorgt ervoor dat

enkel de data wordt gedownload die overeenstemt met het aangevraagd temporeel

fragment. Alvorens de app aan de videocomponent vraagt om te starten met

afspelen, laat die hem eerst doorspoelen naar het temporeel fragment, zodat er

zeker niet afgespeeld wordt van locaties waar geen data beschikbaar is. De app

vraagt regelmatig de huidige afspeellocatie op. Op basis hiervan kan de app

beslissen om te stoppen met afspelen, als het einde van het temporeel fragment

bereikt zou zijn.


de valse server alle formaten moeten ondersteunen die Android kan afspelen. Dit zou

duplicatie van functionaliteit betekenen, aangezien ingebouwde videocomponent dit al kan

(maar dus ook controleert hoe de videodata gedownload wordt).

Het probleem i.v.m. formaatonafhankelijkheid kan eventueel opgelost worden met een iets

gewijzigde aanpak. De valse server hoeft niet langer exact die data te downloaden die overeen-

stemt met het temporeel fragment, maar zou bijvoorbeeld steeds een vaste hoeveelheid data

kunnen bufferen zolang het temporeel fragment afspeelt. Op die manier kan er hoogstens zoveel

data nutteloos gedownload worden als de buffer groot is, want het bufferen stopt als het einde

van het temporeel fragment bereikt is tijdens het afspelen.

3.3.4 File spoofing

Zou het niet mogelijk zijn om de videospeler om de tuin te leiden door te verwijzen naar een

virtueel (video)bestand? Hiermee bedoelen we dat er een object wordt gecreeerd dat zich tegen-

over de videocomponent gedraagt als een echt bestand, maar we laten het intern functioneren

zoals we het willen: de bytes halen we niet op vanuit een opslagmedium (zoals intern geheugen,

een SD-kaart, ...), maar via het netwerk m.b.v. de URI die verwijst naar de video. Als de

videocomponent dan data wil lezen uit dit virtueel bestand, sturen we de juiste bytes indien het

bytes betreft uit het overeenstemmend temporeel gebied, en nulbytes indien dit niet zo is.

Hiervoor werd de broncode van de klassen File en FileDescriptor bestudeerd18, maar telkens

stoten we tegen hetzelfde probleem: gegeven een referentie naar een bestand (afgeleid van File

of FileDescriptor), zal Android in de native OS-laag de data effectief trachten op te halen uit

het onbestaand bestand. Het is dus onmogelijk om de calls te onderscheppen in de SDK-laag.

Infeite is dit een variant op de methode met een proxyserver zoals in bovenstaande subdeelsectie,

maar deze manier werd het eerst uitgeprobeerd. Waar de HTTP-server vervangbaar is, is dat

voor een bestand onmogelijk.

3.3.5 Andere mediabibliotheken

De in Android’s SDK voorziene bibliotheken die ontwikkelaars dienen te gebruiken om video in

te bouwen in apps, is zeer afgesloten; het is bij wijze van spreken enkel mogelijk om een video

18Android is open source. De broncode kan gedownload worden vanaf http://source.android.com/source/

downloading.html

http://source.android.com/source/downloading.html

http://source.android.com/source/downloading.html

3.4 Conclusie 25

te starten en te stoppen en controle over interne procedures is afgeschermd.

We zoeken naar een andere, uitgebreidere bibliotheek en vinden Vitamio19. Deze is gebaseerd op

de bestaande Android-architectuur, maar breidt deze uit met functionaliteit zoals ondersteuning

voor ondertitels en de mogelijkheid tot het instellen van de buffergrootte. De klassen in deze

bibliotheek hebben heel wat gelijkenissen met die uit de media-architectuur uit Android SDK.

Vitamio is gebaseerd op FFmpeg. Om deze bibliotheek te kunnen gebruiken moet er een aparte

’plugin’ geınstalleerd worden die toelaat om media te decoderen. M.b.v. de bibliotheek kan deze

plugin dan aangesproken worden.

Bij tests met Vitamio vallen de resultaten echter tegen: het beeld is niet synchroon met het

geluid en het beeld is ook niet vloeiend in tegenstelling tot de standaard mediaspeler. Dit ligt

aan twee factoren: ten eerste wordt gebruik gemaakt van FFmpeg, waar met de standaard

Android SDK directer op de hardware wordt gewerkt en ten tweede gebeurde de test op een

low-end apparaat.

Dit maakt Vitamio ongeschikt om te gebruiken.

3.4 Conclusie

Android geeft ons genoeg instrumenten om een Media Fragments-app te schrijven, maar wilt

het de ontwikkelaar gemakkelijker maken (of juist moeilijker?) door zo weinig mogelijk controle

te geven over de technische details in de achtergrond.

Het bandbreedteprobleem kan telkens herleid worden naar andere problemen. Niettemin zijn er

wel enkele oplossingen mogelijk.

� Een media-object eerst wegschrijven naar een bestand kent te veel nadelen: te traag,

foutgevoelig en niet geschikt op mobiele apparaten met gelimiteerde opslagcapaciteit.

� De FFmpeg-methode werkt niet met headerdata zonder bijhorende videodata. Het aan-

passen van FFmpeg-code is te complex en kan formaatafhankelijkheid introduceren.

� Een proxyserver kan werken, en heeft het voordeel dat niet eerst het (partieel) media-object

moet gedownload worden: streamen blijft mogelijk.

19http://vov.io/vitamio/

http://vov.io/vitamio/

3.4 Conclusie 26

� File spoofing is onmogelijk, tenzij broncode van het Android OS wordt aangepast. Dit

laatste zorgt ervoor dat de app alleen zou kunnen draaien op apparaten met die aangepaste

broncode, wat niet wenselijk is.

� De Vitamio-bibliotheek was zeker het proberen waard maar presteert niet goed.

ONTWIKKELEN VAN EEN MEDIA FRAGMENTS URI-PARSER 27

Hoofdstuk 4

Ontwikkelen van een Media

Fragments URI-parser

4.1 Algemeen

Nog voor het implementeren van de Android-app en parser, werd al beslist dat de parser volledig

apart ontwikkeld zou worden. De parser werd dus opgevat als een bibliotheek. Eens klaar, kon

die gebruikt worden in de Android-app. Dit had meerdere redenen:

� Het ontwikkelen van een Java-bibliotheek laat toe dat de code getest kan worden zonder

nood aan een Android-apparaat, wat een trage schakel uit het ontwikkelproces haalt.

� Er kan parallel gewerkt worden aan de parser en aan de Android-app. Als een nieuwe

versie van de parser klaar is, hoeven we maar een bestand te vervangen om van de nieuwe

parserbibliotheek gebruik te kunnen maken.

� Als bibliotheek is de parser ook beschikbaar in andere projecten.

In de volgende sectie wordt de architectuur in grote lijnen besproken.

4.2 Architectuur

De parser is geschreven op een manier dat ze gemakkelijk uit te breiden is, voor latere toevoeg-

ingen aan de Media Fragments-specificatie. Daarom is een aantal keren abstractie gebruikt. In

4.2 Architectuur 28

AbstractValueParser AbstractValue Suffix-en

TemporalValueParser TemporalValue NPTSuffix

SMPTESuffix

ClockSuffix

SpatialValueParser SpatialValue SquareSuffix

TrackValueParser TrackValue Trackuffix

IDValueParser IDValue IDSuffix

Tabel 4.2: AbstractValueParser-, AbstractValue- en Suffix-implementaties

figuur 4.1 wordt de hoofdstructuur van de parser getoond. Merk op dat voor de overzichtelijkheid

in deze en volgende figuren alleen structuren opgenomen zijn, geassocieerd met de temporele en

spatiale as uit de Media Fragments-specificatie.

Het uitbreiden van de parser voor een nieuwe as gebeurt door implementaties te schrijven voor

drie klassen:

� AbstractValueParser is de abstracte voorstelling van een waardeparser. Bij elke sleutel

(t, xywh, ...) hoort een unieke waardeparser.

� AbstractValue is de abstractie van een geparsete waarde uit een sleutel-waardepaar.

� Suffix is de abstractie van een geparsete parameter uit een waarde.

Alle klassen die AbstractValueParser, AbstractValue en Suffix implementeren, worden voor

de volledigheid gegeven in tabel 4.2.

MFUriParser is de klasse waar ’gestart’ wordt. Er kan een URI of fragment ingegeven worden.

Na het parsen kunnen alle geldige en ongeldige sleutel-waardeparen opgevraagd worden. Zo’n

paar wordt voorgesteld door de klasse Pair. De methodesignaturen in deze klasse spreken

voor zich, enkel getValueObj() hoeft misschien een woordje uitleg. Pair maakt gebruik van

een AbstractValueParser-instantie die de waarde uit het sleutel-waardepaar parset, en een

AbstractValue aanmaakt met daarin alle informatie over die waarde. Pair kiest de juiste

4.2 Architectuur 29

instantie van een AbstractValueParser op basis van de sleutel uit het sleutel-waardepaar. Dit

wordt verduidelijkt in voorbeeld 13 en op figuur 4.2 is dit getoond.

Voorbeeld 13 (Parsen van sleutel-waardepaar)

Stel dat het te parsen sleutel-waardepaar gegeven is door t=10,20. Op basis van

de sleutel t beslist de klasse Pair dat een TemporalValueParser geschikt is om de

waarde te parsen. Deze waardeparser maakt een TemporalValue-object aan met alle

geparsete data.

Een AbstractValue bestaat altijd uit een Unit en een of meerdere Suffix-objecten.

Voorbeeld 14 (Parsen van eenheid en suffixen)

Een TemporalValueParser beslist op basis van de waarde 10,20 uit het sleutel-

waardepaar t=10,20 dat de eenheid ’npt’ is, daar er geen expliciet eenheid aanwezig

is. Bij dit eenheid horen 2 suffixen: de begin- en eindtijd van het temporeel fragment.

De suffixen zullen dan instanties zijn van NPTSuffix.

4.2 Architectuur 30

MFUriParser

+ getPair(int) : Pair

+ getPairCount() : int

+ getValidPair(int) : Pair

+ getValidPairCount() : int

+ getValidPairs() : List<Pair>

+ parseFragment(String) : void

+ parseUri(String) : URI

+ printValidPairList() : String

Pair

+ SPATIAL : int

+ TEMPORAL : int

+ getName() : String

+ getType() : int

+ getTypeName() : String

+ getValue() : String

+ getValueObj(): AbstractValue

+ isValid() : boolean

+ parse() : void

AbstractValueParser

+ getValue() : String

+ getValueObj() : AbstractValue

+ isValid() : boolean

+ parse() : void

+ setValue(String value) : void

# getParserName : String

# getParserType : int

AbstractValue

+ getUnit() : Unit

+ print() : String

# getSuffix(int nr) : Suffix

# getSuffixCnt() : int

Suffix

+ print() : String

Figuur 4.1: Hoofdstructuur van de Media Fragments-parser

4.2 Architectuur 31

Abs

tract

Valu

ePars

er

+ge

tVal

ue(

):

Str

ing

+ge

tVal

ueO

bj(

):

Ab

stra

ctV

alu

e

+is

Val

id()

:b

ool

ean

+p

arse

():

void

+se

tVal

ue(

Str

ing

valu

e):

voi

d

#ge

tPar

serN

ame

:S

trin

g

#ge

tPar

serT

yp

e:

int

Sp

ati

alV

alu

eP

ars

er

Tem

pora

lValu

eP

ars

er

Abs

tract

Valu

e

+get

Un

it()

:U

nit

+p

rint(

):

Str

ing

#get

Su

ffix(i

nt

nr)

:S

uffi

x

#get

Su

ffixC

nt(

):

int

Sp

ati

alV

alu

e

-are

a:

Sp

ati

alS

uffi

x

Tem

pora

lValu

e

-ar

ea:

Su

ffix

+T

emp

oralV

alu

e(N

PT

Su

ffix,

NP

TS

uffi

x)

+T

emp

oralV

alu

e(S

MP

TE

Su

ffix,

SM

PT

ES

uffi

x)

Un

it

+S

PA

TIA

LP

ER

CE

NT

AG

E:

int

+S

PA

TIA

LP

IXE

L:

int

+T

EM

PO

RA

LN

PT

:in

t

+get

Typ

e()

:in

t

+p

rint(

):

Str

ing

Su

ffix

+p

rint(

):

Str

ing

Squ

are

Su

ffix

+get

H()

:in

t

+get

W()

:in

t

+get

X()

:in

t

+get

Y()

:in

t

NP

TS

uffi

x

+get

Hh

():

int

+get

Mm

():

int

+get

Ms(

):

int

+get

Ss(

):

int

Fig

uu

r4.2

:A

rch

itec

tuu

rva

nd

eM

edia

Fra

gmen

ts-p

arse

r

4.3 Parse-algoritme 32

4.3 Parse-algoritme

De parser krijgt als input een URI of URI-fragment en voert dan de volgende stappen uit:

1. Indien een URI werd opgegeven, wordt het URI-fragment hieruit geextraheerd op basis

van het eerste voorkomen van het #-teken.

2. ’Percent-encodings’ in het fragment worden omgezet in echte karakters. Bvb. ’%74’ staat

voor ’t’.

3. Het URI-fragment wordt gesplitst in paren (Pair-klasse), welke worden gescheiden met

het &-teken.

4. Voor elk paar wordt de sleutel en waarde geextraheerd op basis van het eerste voorkomen

van het =-teken. De sleutel wordt vergeleken met bekende sleutels: indien de sleutel

onbekend is, wordt dit paar ongeldig gemarkeerd en stopt het parsen voor dit paar.

5. Voor elk paar met een geldige sleutel, wordt op basis hiervan een klasse gebruikt (bvb.

TemporalValueParser) die specifiek voor deze sleutel, de waarde van het paar kan parsen.

6. Indien de waarde een ’:’-teken bevat, zal de tekst voor dit teken als eenheid worden

beschouwd en de tekst na dit teken als het suffixgedeelte. Herkent de waardeparser de een-

heid voor de sleutel niet, dan neemt de waardeparser de standaardeenheid en beschouwt

de totale waarde als het suffixgedeelte. Indien het suffixgedeelte niet geldig blijkt, wordt

dit paar als ongeldig gemarkeerd.

4.4 Unit tests en logging 33

Voorbeeld 15 (Parse-algoritme stappen)

De parser krijgt volgende input:

http : // example . com/movie . mp4#%74=0:20,0:40&xywh=10 ,10 ,80 ,

Hieruit wordt de URI geextraheerd en percent-encodings worden omgezet:

t=0:20 ,0:40& xywh=10 ,10 ,80

Er worden 2 paren herkend. Voor het temporele paar wordt de t-sleutel herkend

en zal de waarde worden geparsed met TemporalValueParser. Deze ziet 0: als de

eenheid maar herkent deze niet. De temporele standaardeenheid npt wordt genomen

en 0:20,0:40 als suffixgedeelte. Dit blijkt uiteindelijk een correct paar te zijn.

SpatialValueParser zal het spatiaal paar ongeldig markeren, omdat de waarde

incorrect is.

4.4 Unit tests en logging

Voor het testen van de parser werden 132 unit tests gedefinieerd. Alle voorbeelden uit de

specificatie zijn hierin vervat, zodat met zekerheid gezegd kan worden dat de parser volledig

werkt. Ook ’percent encodings’ worden correct verwerkt.

Voor het loggen van output van de parser wordt de interface MFLoggerHandle geımplementeerd.

Tijdens het ontwikkelproces werd op deze manier het logging-framework Log4J20 aangeschakeld.

Er werd voor deze methode gekozen omdat Log4J niet werkt op Android apparaten, en er

gemakkelijk moet kunnen verwisseld worden tussen verschillende loggingmethodes. Figuur 4.3

verduidelijkt dit principe.

4.5 Broncode

De DVD bij dit document bevat de broncode van de Media Fragments parser, onder de vorm

van een Netbeans-project. U vindt de projectstructuur onder de map ’parser’.

20http://logging.apache.org/log4j/

http://logging.apache.org/log4j/

4.5 Broncode 34

MFLogger

+ getMFLogger() : MFLogger

+ getMFLoggerHandle() : MFLoggerHandle

+ setMFLoggerHandle(MFLoggerHandle) : void

<<interface>>

MFLoggerHandle

# err(String)

# getName(): String

# info(String)

# warn(String)

MFLog4JLogger MFDummyLogger

Figuur 4.3: Deze architectuur laat toe om Log4J af te schakelen als de parser-

bibliotheek op Android-apparaten werd gebruikt.

ONTWIKKELEN VAN EEN COMPATIBELE MEDIASPELER 35

Hoofdstuk 5

Ontwikkelen van een compatibele

mediaspeler

5.1 Requirements en features

Vooraf dient er beslist te worden wat de vereisten zijn voor de app, en welke functionaliteit deze

moet bieden.

� Eerst en vooral: de app zal draaien op een mobiel apparaat, een smartphone, en dus moet

de gebruiker dit ook voelen. De video draait mee met de orientering van het scherm,

schaalt mee, en de besturing moet gebeuren met aanrakingen op het scherm.

� De temporele as wordt enkel geımplementeerd voor de standaardeenheid npt: de andere

eenheden bieden weinig meerwaarde op een mobiel apparaat. Zo vereist smpte kennis over

het exact aantal frames per seconde in een video en clock heeft enkel nut bij livestreams.

� De spatiale as wordt volledig ondersteund.

� De track- en id-as worden niet geımplementeerd, omwille dat het technisch onmogelijk is

om met de Android SDK tracks te extraheren. Ook het opvragen van begin- en eindtijden

van gedefinieerde hoofdstukken, zoals bij een DVD, is niet mogelijk.

� De app moet, naast zelfstandig te kunnen starten uit het app-menu, ook gestart kunnen

worden en fragmentatie toepassen als de gebruiker op een link naar een media-object klikt

in een browser.

5.2 Algemene app-levenscyclus 36

5.2 Algemene app-levenscyclus

Een Android-app bestaat algemeen uit meerdere Activity’s. Een Activity is het geheel van een

UI (hetgeen wat dus op een gegeven moment op het scherm getoond wordt) met achterliggende

code. Een app kan dan overgaan van de ene naar de andere Activity. Bijvoorbeeld: uit een

lijst van contactpersonen moet iemand gekozen moet worden. Wanneer de gebruiker klikt op

’kiezen’ dan wordt overgegaan van de huidige naar een andere Activity: deze bestaat uit een

lijst van contactpersonen (de UI), en de code die er ondermeer voor zorgt dat naar de oproepende

Activity wordt teruggekeerd met een referentie naar de geselecteerde contactpersoon. In figuur

5.1 wordt dit getoond.

Figuur 5.1: De linkse Activity start de rechtse door te ’klikken’ op ’Contacts’.

Gemakkelijk gezegd, staat elk ’volledig scherm’ voor een andere Activity. Eender welke app

kan een Activity van een andere app oproepen, als deze laatste app dat ’toestaat’ in een

beschrijvend metabestand (AndroidManifest.xml). Zo is het mogelijk om een browser-app te

laten starten, als de oproepende app voorziet in een HTTP-URI (http://...). Het Android-

besturingssysteem filtert de lijst van mogelijke applicaties.

De Media Fragments-app zal uiteraard op z’n minst een videospeler-Activity bevatten: het

scherm waarin de video wordt afgespeeld. We kunnen dan in het metabestand aangeven dat

deze Activity mag gestart worden uit een browser met de volgende lijnen:

5.3 Implementatie 37

Voorbeeld 16 (Activity-filtering)

<a c t i v i t y

android:name=” . VideoPlayer ”

<in tent− f i l t e r>

<ac t i on android:name=”android . i n t en t . a c t i on .VIEW” />

<data android :scheme=”http ” android:mimeType=” video /*” />

<category android:name=”android . i n t en t . category .BROWSABLE” />

</ intent− f i l t e r>

</ a c t i v i t y>

Bij het klikken op een link in een browser, wordt aan het Android-systeem een

zogenaamd Intent-object gegeven met daarin de beschrijving van de actie. De

Media Fragments-app geeft hier aan dat het enkel wil reageren op de actie ’VIEW’

met categorie ’BROWSABLE’. Bovendien moet de link refereren naar een object met

MIME-type video/*: de Media Fragments-app zal dus niet worden aangeboden in

een lijst van mogelijke apps, als er bijvoorbeeld wordt geklikt op een link naar een

webpagina.

Merk op dat in Android-versies voor 3.0 (Honeycomb) er een bug bestaat waarbij bij het klikken

op een link in een browser, de ’fragment identifier’ uit de URI verdwijnt. De Media Fragments-

app ontvangt dus wel de URI naar de ’primary resource’ maar geen fragmentinformatie. Deze

bug werd gerapporteerd21. Concreet wil dit zeggen dat de app wel werkt in Android-versies voor

Honeycomb, maar indien gestart vanuit een browser, zal geen fragmentering worden toegepast:

de video speelt in zijn geheel af. De URI zal in deze gevallen moeten gekopieerd worden, en

ingegeven worden in de Media Fragments-app zelf.

5.3 Implementatie

De app bestaat uit 3 Activity’s. Een waar een (Media Fragments) URI kan ingegeven wor-

den, een waar de geparsete sleutel-waardeparen worden opgelijst en een waar de video wordt

afgespeeld. In figuur 5.2 worden de eerste twee getoond.

Het belangrijkste is natuurlijk de derde Activity, de videospeler zelf. Deze wordt gestart als

in een browser op een videolink wordt geklikt. In figuur 5.3 wordt de speler getoond.

De video wordt steeds zo groot mogelijk weergegeven terwijl de verhouding van videobreedte en

21http://code.google.com/p/android/issues/detail?id=25100

http://code.google.com/p/android/issues/detail?id=25100


Figuur 5.2: De linkse Activity is het startscherm van de Media Fragments-app,

waarin de URI kan worden ingegeven. De tweede controleert de URI en lijst de

geldige en ongeldige sleutel-waardeparen op.

Figuur 5.3: De videospeler in portretmodus

-hoogte gerespecteerd wordt. De video wordt ook centraal gezet. Als het apparaat van orientatie

verandert, worden de afmetingen en marges herberekend.

In figuur 5.2 zien we meteen de toepasing van het sleutel-waardepaar xywh=percent:0,0,50,50

dat werd ingegeven in de eerste Activity. Inderdaad: de rechthoek begint op 0% van de breedte

en hoogte, en eindigt op 50% van de totale breedte en hoogte van de video-afmetingen.

Het spatiaal fragment werd geımplementeerd met een semitransparante ’overlay’ waarin een

rechthoek kan worden uitgespaard. De app houdt de 4 parameters van de spatiale as bij zoals

ze zijn opgegeven in de URI: er wordt geen omzetting gedaan van percent- naar pixelnotatie of

omgekeerd. Pas bij het starten van de video of na herorientering van het apparaat, worden de

werkelijke coordinaten op het scherm berekend, om afrondingsfouten tegen te gaan.


Figuur 5.4: Inzoomen op een spatiaal fragment

Er kan worden ingezoomed op een spatiaal fragment door een lange aanraking op de rechthoek.

Dat fragment wordt dan full-screen weergegeven zoals in figuur 5.4. Op deze afbeelding ziet

u overigens ook de voortgangsbalk waarop het temporeel fragment met geel staat aangeduid.

Verder zijn ook knoppen beschikbaar om het afspelen te pauzeren, om het temporeel fragment

opnieuw te bekijken, enz. De voortgangsbalk en knoppen kunnen weggelaten of teruggebracht

worden met een korte aanraking op het scherm.

Dat de videospeler ook werkt in horizontale orientatie van het apparaat, ziet u in figuur 5.5.

Als de speler het einde van het temporeel fragment bereikt, pauzeert de speler, tenzij de gebruiker

vooraf had doorgespoeld naar een tijdstip buiten het temporeel fragment.

Figuur 5.5: De videospeler in landschapsmodus, normaal en ingezoomed op een

spatiaal fragment.

5.4 Broncode 40

5.4 Broncode

De DVD bij dit document bevat de broncode van de “Media Fragments player”, onder de vorm

van een Eclipse-project. U vindt de projectstructuur onder de map ’player’.

UITBREIDING VAN DE MEDIA FRAGMENTS-SPECIFICATIE 41

Hoofdstuk 6

Uitbreiding van de Media

Fragments-specificatie

6.1 Spatiaal-temporele fragmentatie

6.1.1 Motivatie

De huidige Media Fragments-specificatie omvat zowel temporele als spatiale fragmentatie. Bij

dit laatste behoudt het spatiaal ’focusgebied’ zijn statische positie gedurende de gehele lengte

van de video, wat in enkele situaties ongewenst kan zijn:

� Het object waarop de focus gelegd wordt, kan bewegen, zodat dit object op bepaalde

tijdstippen slechts gedeeltelijk zichtbaar is of zelfs helemaal uit het focusgebied verdwijnt.

� Het object waarop de focus gelegd wordt, kan vergroten of verkleinen, zodat een aanpassing

van de grootte van het focusgebied gewenst is. Het initieel groot genoeg maken van het

focusgebied zodat het object steeds binnen de grenzen zou vallen, is geen goede oplossing:

bij een klein object en groot focusgebied is er van ’focus’ nauwelijks sprake.

Het introduceren van een spatiaal-temporele as in de Media Fragments-specificatie is dus gerecht-

vaardigd. Vanaf nu noemen we een spatiaal-temporeel fragment een ’traject’.

In de volgende sectie wordt besproken hoe deze nieuwe fragmentatiewijze ontworpen werd met

het oog op eenvoud en uniformiteit met de bestaande specificatie.

6.1 Spatiaal-temporele fragmentatie 42

6.1.2 Invoering van het traj-sleutel-waardepaar

6.1.2.1 Vereisten

Het invoeren van een nieuwe as stelt een aantal eisen. Voor een traject zijn dit volgende zaken:

� Er mag geen interferentie met andere assen optreden. Wanneer zowel spatiale fragmen-

tatie als een spatiaal-temporeel traject wordt opgegeven, moet op elk tijdstip in de video

eenduidig te achterhalen zijn waar het spatiaal gebied zich bevindt.

� Voor uniformiteit met de huidige specificatie, maar eveneens voor de eenvoud, wordt een

traject beschreven a.d.h.v. koppels van spatiale gebieden en tijdstippen. De notaties voor

spatiale gebieden gebeuren zoals in de xywh-sleutel-waardeparen en de tijdstippen zoals

in de t-sleutel-waardeparen (enkel npt-notatie). Het opgeven van de coordinaten van de

rechthoeken kan dus ook gebeuren in pixel- of percentwaarden.

� De beschrijving van een bepaald traject moet uniek zijn.

� Voor uniformiteit met de huidige specificatie, mag maar een traject worden opgegeven. Er

mag dus maar een sleutel-waardepaar voor deze nieuwe as voorkomen in het URI-fragment.

De combinatie van twee trajecten die elkaar in de tijd niet zouden overlappen, moet dus

te beschrijven zijn in een traject. Merk op dat dit de uniciteit van vorig puntje in de hand

werkt.

6.1.2.2 Ontwerp

Het algemeen idee achter een traject is dat er verschillende spatiale gebieden in de tijd worden

gespecificeerd, en dat met vlaggen wordt aangeduid hoe er van het ene spatiaal gebied naar het

andere wordt overgegaan in de tijd. Figuur 6.1 verduidelijkt dit idee.

In figuur 6.1 zijn er 3 spatiale gebieden opgegeven. Het eerste gebied (groen) komt steeds overeen

met de starttijd van het temporeel fragment en het laatste gebied (rood) met de eindtijd van

het temporeel fragment. Deze twee gebieden (en enkel deze twee) zijn dus steeds impliciet

geassocieerd met een tijdstip. Bij alle tussenliggende gebieden (blauw) moet wel een tijdstip

worden opgegeven. Als de speler zich bevindt op seconde 44, dan wordt exact dat spatiaal gebied

getoond dat overeenkomt met de waarde in het blauw vierkant. Hoe het spatiaal gebied zich

gedraagt tussen de opgegeven gebieden in, hangt af van de vlag:


x,y,w,h x,y,w,hkeep

x,y,w,hinterpolate

temporeel fragment

t0s 20s 40s 60s 80s

Figuur 6.1: Schematische voorstelling van een traject in een video van 87 seconden.

Het fragment start op 7 seconden en eindigt op 70 seconden.

x,y,w,h x,y,w,hinterpolate keep

temporeel fragment

t0s 20s 40s 60s 80s

Figuur 6.2: De ’keep’-vlag als laatste vlag

� interpolate (i): laat de rechthoek geleidelijk overgaan van het opgegeven gebied naar het

volgend opgegeven gebied. Het interpoleren gebeurt lineair volgens de tijd. Deze vlag mag

enkel gebruikt worden tussen twee opgegeven rechthoeken.

� keep (k): behoud de afmetingen van het gebied tot het volgend opgegeven gebied of tot

het einde van het fragment. Deze vlag komt overeen met spatiale fragmentatie, gezien de

rechthoek statisch blijft staan.

Indien de laatste vlag in het traject de ’keep’-vlag is, dan moet de rechthoek, die overeenkomt

met het einde van het spatiaal fragment, niet opgegeven worden aangezien de coordinaten hier-

van nutteloos zijn (er wordt niet naar geınterpoleerd). In dit geval komt de laatst opgegeven

rechthoek niet overeen met het einde van het fragment, en moet er dus wel een tijdstip worden

opgegeven. Een voorbeeld hiervan ziet u in figuur 6.2.

We kunnen een traject beschouwen als een uitbreiding van spatiale fragmentatie: de rechthoek


hoeft zich niet langer statisch te gedragen. Omgekeerd is een spatiaal fragment een traject

zonder tussengebieden en interpolatie. Een traject is dus ’backwards compatible’ met spatiale

fragmentatie.

Anderzijds blijft temporele fragmentatie ongewijzigd met de nieuwe as: de tijdsaanduidingen in

de spatiaal-temporele as hebben geen invloed op de begin- en eindtijd van het fragment.

We zouden de spatiale as dus eerder kunnen uitbreiden en de invoering van een volledig nieuwe

as overbodig maken. Echter:

� Een speler die de notatie voor spatiaal-temporele fragmentatie niet zou verstaan omdat hij

de notatie voor de xywh-sleutel verwacht, verliest dan alle opgegeven spatiale fragmentatie.

� Een speler die de nieuwe as niet herkent, negeert deze volledig en zal dus kunnen terugvallen

op spatiale fragmentatie d.m.v. de xywh-sleutel (indien opgegeven).

6.1.2.3 Notatie in het URI-fragment

Het Engels woord voor ’traject’ is ’trajectory’. We noemen de nieuwe vlag traj.

We laten twee eenheden toe om coordinaten van de rechthoeken te noteren in pixel- of percent-

waarden, wat uniform is met xywh: pixel en percent.

De waarde van het sleutel-waardepaar is een iteratie van rechthoekcoordinaten met dezelfde no-

tatie als in xywh, een tijdspunt in npt-notatie (geen tijdspunt voor de eerste, en indien opgegeven,

de laatste rechthoek) en een vlag i of k. Deze 3 componenten (coordinaten, tijd, vlag) worden

telkens door een puntkomma.

Voor de exacte formaatspecificatie voor de spatiaal-temporele as wordt u verwezen naar bijlage E.

De formaatspecificatie wordt toegepast in voorbeeld 17.

Voorbeeld 17 (Media Fragments traj-sleutel-waardepaar)

http : // example . com/movie . mp4#t=10,25&traj=percent : 2 5 , 2 5 , 5 0 , 5 0 ; k←↩

; 2 5 , 2 5 , 5 0 , 5 0 ; 1 5 ; i ; 35 , 25 ,60 ,60

De video speelt van seconde 10 tot 25. Van seconde 10 tot 15 blijft de rechthoek

statisch (k). Vanaf seconde 15 wordt geınterpoleerd tot seconde 25 (einde van het

temporeel fragment). Hierbij zal de rechthoek licht naar rechts bewegen (35 - 25 =

10%) en ook iets groter worden.


TrajectoryValueParser

TrajectoryValue

+ getSuffixCnt() : int

+ getSuffix(int) : Suffix

TrajectorySuffix

+ FLAG INTERPOLATE : char

+ FLAG KEEP : char

TrajectoryFlagSuffix

+ getFlag() : char

TrajectorySquareTempSuffix

+ getTime() : NPTSuffix

+ getSquare() : SquareSuffix

Figuur 6.3: Het uitbreiden van de Media Fragments-parser naar ondersteuning

voor spatiaal-temporele fragmentatie.

6.1.3 Implementatie in de parser

Het uitbreiden van de parser is snel gebeurd door het bijschrijven van enkele klassen (zie hoofd-

stuk 4, sectie 4.2). Gezien de overeenkomsten qua notaties van de waarden horend bij de

xywh- en t-sleutels, kunnen we bestaande parsercode hergebruiken. Zo wordt de tijd geparsed

door TemporalValueParser en de rechthoekcoordinaten door SpatialValueParser. Voor de

volledigheid worden de bijkomende klassen in figuur 6.3 getoond (zonder abstractieklassen).

6.1.4 Implementatie in de videospeler

De implementatie in de videospeler zet de geparsete parameters uit de URI om naar een 2-

dimensionale array van getallen, voor het afspelen begint. Op deze manier worden al heel wat

berekeningen op voorhand gedaan en moeten deze niet telkens herhaald worden, bijvoorbeeld bij

het doorspoelen van de video. Een entry van deze array bevat informatie over hoe het spatiaal

gebied zich moet gedragen gedurende een bepaald tijdsgebied in de video. Deze tijdsgebieden

zijn telkens gedefinieerd door twee aansluitende tijdspunten. Deze tijdspunten zijn de begintijd

van de video, de begintijd van het temporeel fragment, de opgegeven tijdstippen in de waarde

6.2 Andere uitbreidingsmogelijkheden 46

temporeel fragment

t0s 20s 40s 60s 80s

Figuur 6.4: Omzetting naar arraywaarden

van het traj-sleutel-waardepaar, en de eindtijd van het temporeel fragment en van de video.

In figuur 6.4 wordt dit gevisualiseerd: een grijs vierkantje staat voor een entry in de array. In de

figuur zijn dit er 7: twee voor begin- en eindtijd van de video, nog twee voor begin- en eindtijd

van het fragment en drie voor de rechthoeken opgegeven in het traj-sleutel-waardepaar.

Elke entry bevat 8 getallen. [t1 t2 e i x y w h

]Hierin staan t1 en t2 respectievelijk voor begin- en eindtijd van het tijdsgebied waarvoor deze

array array wordt gedefinieerd. e duidt aan of er spatiale fragmentatie moet worden toegepast,

i geeft aan of er geınterpoleerd moet worden naar de volgende rechthoek en de vier resterende

getallen zijn de dimensies van de huidige rechthoek. Merk op dat in de laatste entry van de

array, enkel de dimensiegetallen van nut zijn (om in het laatste gebied te kunnen interpoleren).

Tijdens het afspelen van de video wordt dan op basis van de huidige afspeelpositie bepaald

welke entry van de array geldig is. Eens gevonden, kan meteen de correcte spatiale fragmentatie

worden toegepast.

Na deze uitbreiding ondersteunt de Media Fragments-speler spatiaal-temporele fragmentatie.

Vier screenshots van de app worden weergegeven in figuur 6.5 voor het URI-fragment

t=10,25&traj=percent : 1 0 , 1 0 , 1 0 , 8 0 ; i ; 2 5 , 2 5 , 5 0 , 5 0 ; 1 5 ; k ; 5 0 , 5 0 , 4 0 , 1 0 ; 2 0 ; k

6.2 Andere uitbreidingsmogelijkheden

Er kan ook aan andere uitbreidingen worden gedacht, bijvoorbeeld:

� Meerdere spatiale gebieden tegelijkertijd tonen

6.2 Andere uitbreidingsmogelijkheden 47

Figuur 6.5: Enkele screenshots van de app op seconden 10, 13, 14 en 20 voor

een bepaald URI-fragment (zie tekst). Merk op dat op seconde 13 interpolatie

plaatsvindt tussen de rechthoeken op seconde 10 en 15. Vanaf seconde 20 is de

rechthoek statisch.

� Meerdere spatiaal-temporele gebieden tegelijkertijd tonen

� Andere vormen dan rechthoeken mogelijk maken

Er moet evenwel op gelet worden dat de specificatie niet overladen wordt met nutteloze eigen-

schappen die zelden gebruikt zullen worden. Alsook, hoe groter de specificatie, hoe complexer

de URI. Dit wensen we te vermijden.

CONCLUSIES 48

Hoofdstuk 7

Conclusies

In deze masterproef werd onderzocht hoe de Media Fragments-specificatie kon geımplementeerd

worden op een mobiel apparaat, en hiervoor werd het Android-platform geselecteerd. Een Media

Fragments videospeler werd gebouwd die gebruik maakt van een Media Fragments URI-parser

en er werd nagegaan hoe de datatrafiek positief kon worden beınvloed door kennis van een

temporeel fragment gespecificeerd in een Media Fragments URI. De resultaten hiervan hebben

niet geleid tot een implementatie die controle over de datatrafiek kan uitoefenen.

De Media Fragments-specificatie werd uitgebreid naar ondersteuning voor spatiaal-temporele

fragmentatie en dit werd ook geımplementeerd in de Android app.

49

Bijlagen

SOFTWARE DEVELOPMENT KIT (SDK) 50

Bijlage A

Software Development Kit (SDK)

Het eerste wat moet gebeuren is het opzetten van de programmeeromgeving. Dit houdt in dat

de SDK wordt gedownload en geınstalleerd, en deze ondersteund wordt door de ontwikkelings-

omgeving (IDE, Integrated Development Environment). Met het oog hierop werden reeds enkele

plugins voor meerdere IDE’s ontwikkeld: ’nbandroid’ voor Netbeans, ’ADT plugin’ voor Eclipse.

Voor deze masterproef werd met Eclipse gewerkt.

De SDK komt er in verschillende versies: voor elke update (uitgezonderd bugfixes) aan het

Android-besturingssysteem (OS, Operating System) wordt een nieuwe SDK uitgebracht. Elke

versie van het OS krijgt een naam, die trouwens gebaseerd is op namen van veelal zoete

etenswaren, waarbij de SDK een overeenkomstig nummer krijgt.

Versie SDK-nummer(s) Naam

1.5 3 Cupcake

2.2.x 8 Froyo

2.3.x 10 Gingerbread

3.x 11-13 Honeycomb

4.x 14-15 Ice Cream Sandwich

Tabel A.2: Een greep uit de verschillende Android-versies

De SDK voorziet een emulator om applicaties in ontwikkeling te testen, indien geen fysiek

SOFTWARE DEVELOPMENT KIT (SDK) 51

apparaat voorhanden. Deze reageert echter steeds met een grote vertraging op invoer waardoor

beslist werd om te programmeren op een echt apparaat. Dit werd de Samsung Galaxy Ace welke

draait op Android v2.3 (Gingerbread). De minimumversie van de SDK is dus 10: de applicatie

zal niet kunnen geınstalleerd worden op apparaten met Android v2.2 (Froyo) of lager. Er kon

ook getest worden op andere devices aangekocht door Multimedialab: een HTC Wildfire S, een

Samsung Galaxy Tab en een Galaxy Nexus.

Figuur A.1: De Android emulator met SDK 10, onder Ubuntu 11.10.

Om een applicatie te schrijven met de Android SDK werden verschillende tutorials gevolgd en

heel wat documentatie gelezen op de Android Developer website22. Zo kon een basis worden

gelegd om van te vertrekken.

22http://developer.android.com/

http://developer.android.com/

NATIVE DEVELOPMENT KIT (NDK) 52

Bijlage B

Native Development Kit (NDK)

Zoals beschreven in subsectie 3.2, kan er geen controle over de datatrafiek worden uitgeoefend

tijdens het afspelen van een video via de standaard ingebouwde media-architectuur van Android.

Een oplossing hiervoor is het implementeren van een eigen videospeler, maar dit vereist dat er

geprogrammeerd wordt in native code, geschreven in C. Een eigen videospeler programmeren zou

wel heel wat extra werk kunnen opleveren en ligt eigenlijk buiten de opzet van deze masterproef;

toch kan het geen kwaad om te kijken hoeveel werk er effectief in zou kruipen om alsnog een

beslissing te maken over het wel of niet implementeren.

Het decoderen van video’s zouden we namelijk niet zelf moeten programmeren: FFmpeg is

een gratis library geschreven in C voor het encoderen en decoderen van video en audio en het

ondersteunt zowat alle gangbare containers en codecs (zie ook bijlage D).

De Native Development Kit (NDK) stelt ons in staat om te programmeren in C en C++. Deze

voorziet allerlei tools, waaronder compilers, om native code werkend te krijgen op een Android

device. Veelal bevatten Android-apparaten processoren voor de ARM-instructieset. De NDK

compileert dan naar ARM-code.

Net zoals de SDK, kan er na een paar tutorials en het lezen van enkele documenten aan de

slag worden gegaan. De native broncode moet eerst apart gecompileerd worden en komt dan

allemaal terecht in een bibliotheek die via JNI (Java Native Interface, zie ook bijlage C) kan

aangesproken worden vanuit Java-code.

De NDK compileert native code met de tool ndk-build.

Het ganse proces om C-code werkend te krijgen op een Android-apparaat bestaat in principe

uit twee grote stappen:

NATIVE DEVELOPMENT KIT (NDK) 53

� Schrijf de C-code (.c) en de bijhorende headers (.h). Voorzie een bestand Android.mk

waarin omschreven staat hoe de code moet gecompileerd worden - bijvoorbeeld enkel voor

de armeabi-instructieset en niet voor armv7 - en refereer van hieruit naar andere benodigde

bibliotheken. Deze bestanden moeten alle drie in de map jni/ onder de projectstructuur

van een Android-app. De methodes in de C-code die vanuit Java dienen aangesproken

te worden, moeten voldoen aan een specifieke signatuur met bepaalde sleutelwoorden (zie

bijlage C).

� Compileer m.b.v. de bij NDK bijgeleverde tool ndk-build. Als output wordt een of

meerdere .so-bestanden verkregen: een voor elke bibliotheek en een voor de zelfgeschreven

code die op deze bibliotheken steunt. .so is de extensie voor bibliotheken onder Linux,

Android is Linux-gebaseerd. De gegenereerde bestanden worden automatisch in de map

libs/armeabi/ onder de projectstructuur geplaatst, indien gecompileerd werd voor arme-

abi.

Na deze twee stappen kan de C-code worden aangesproken vanuit de Java-code van de eigenlijke

app.

JAVA NATIVE INTERFACE (JNI) 54

Bijlage C

Java Native Interface (JNI)

Java Native Interface (JNI) is een deel van de Java Application Programming Interface (API)

en is de interface waarbij vanuit Java-code andere, gecompileerde niet-Java-code kan worden

aangesproken. Deze code wordt ’native code’ genoemd en wordt veelal gebundeld in bibliotheken

(.so-bestanden).

Stel dat de bibliotheken na het compileerproces aanwezig zijn onder de map libs/ in de pro-

jectstructuur van de Android-app. Dan zijn er nog enkele stappen nodig om de native code aan

te spreken. In voorbeeld 18 worden deze toegelicht.

JAVA NATIVE INTERFACE (JNI) 55

Voorbeeld 18 (Aanspreken native code via JNI)

Indien de bibliotheek libtest.so heet (het prefix lib en suffix .so worden au-

tomatisch aan de naam “test” geplakt tijdens het compileerproces), schrijf dan in de

Java-klasse thiz.is.a.Clazz volgend stuk code:

s t a t i c {

System . loadLibrary ( ” t e s t ” ) ;

}

In diezelfde klasse, definieer volgende methode:

pub l i c nat ive String getMessage ( ) ;

Het native-sleutelwoord duidt aan dat er in de code binnen libtest.so een C-

methode bestaat met volgende signatuur:

JNIEXPORT jstring JNICALL Java_thiz_is_a_Clazz_getMessage

( JNIEnv* env , jobject o )

waarbij jstring equivalent is met String uit Java, en de naam van de methode

duidelijk overeenstemt met de naam en package van de klasse en naam van de

methode getMessage().

Bij het aanroepen van de methode getMessage() in Java, zal de native methode

worden aangesproken en resultaat teruggeven.

JNI en de NDK maken het nu samen mogelijk om stukken van de applicatie te schrijven in

native code en deze op te roepen vanuit de Java-code van de applicatie, die overigens in de

Dalvik Virtual Machine (Dalvik VM) draait.

FFMPEG 56

Bijlage D

FFmpeg

Binnen FFmpeg-code worden de databytes van een video opgedeeld in struct AVPacket’s. Alle

pakketten kunnen benaderd worden door gebruik te maken van een AVPacketList, een gelinkte

lijst met aan de kop een AVPacket en als staart weer een AVPacketList. Om te berekenen

hoeveel databytes overgeslaan moeten worden, is het noodzakelijk om door deze gelinkte lijst te

lopen. In Tabel D.2 staan enkele nuttige velden vermeld uit deze struct.

Type Naam Uitleg

int64_t pts Timestamp die aangeeft wanneer het gedecodeerd

pakket moet worden weergegeven

uint8_t * data Array van databytes

int size Aantal bytes in data

int duration Hoelang dit pakket moet worden weergegeven

Tabel D.2: Enkele velden uit de AVPacket-struct

In theorie is enkel header data uit het MP4-bestand nodig voor de berekening; het opvra-

gen van het volgend AVPacket uit de gelinkte lijst faalt echter waar het volgend AVPacket

zou overeenkomen met weggelaten databytes. In de praktijk faalt dit bij de eerste opvraging,

aangezien we enkel over header data beschikken. M.b.v. Isoviewer werd dan berekend hoeveel

databytes nodig waren voor bijvoorbeeld exact de eerste 4 pakketten. FFmpeg liep in dat geval

FFMPEG 57

inderdaad vast bij de 5de iteratie. Deze test toont aan dat header data volstaat voor de bereken-

ing, althans in het geval van een MP4-bestand. Het feit dat FFmpeg dit niet zo implementeert,

kan te maken hebben met abstractielagen om compatibel te zijn met andere formaten die niet

over dergelijke header data beschikken.

TRAJECT-URI FORMAATSPECIFICATIE 58

Bijlage E

Traject-URI formaatspecificatie

trajprefix = %x74.72.61.6A ; "traj"

trajunitparam = [ xywhunit ":" ] trajparam

xywhunit = %x70.69.78.65.6C ; "pixel"

/ %x70.65.72.63.65.6E.74 ; "percent"

trajparam = xywh ";" flag

flag = flagk / flagi

flagk = "k" [ ";" midpoint ]

flagi = "i" ";" point

midpoint = xywh ";" npttime ";" flag

point = xywh ";" [ npttime ";" flag ]

xywh = 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT

BIBLIOGRAFIE 59

Bibliografie

[1] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifier (URI): Generic

Syntax, pages 24–25. IETF, 2005. Beschikbaar op http://tools.ietf.org/html/

rfc3986#section-3.5.

[2] Ian Hickson. HTML5 - A vocabulary and associated APIs for HTML and XHTML, W3C

Working Draft. Beschikbaar op http://www.w3.org/TR/html5/.

[3] ISO/IEC. ISO/IEC 14496-12: Information technology — Coding of audio-visual objects

part 12: Iso base media file format. 2008.

[4] Erik Mannens, Davy Van Deursen, Raphael Troncy, Silvia Pfeiffer, Conrad Parker, Yves

Lafon, Jack Jansen, Michael Hausenblas, and Rik Van de Walle. A URI-based Approach

for Addressing Fragments of Media Resources on the Web. Technical report.

[5] Adobe Solutions Network. PDF Open Parameters, pages 7–8. Adobe Systems Inc.,

2005. Beschikbaar op http://partners.adobe.com/public/developer/en/acrobat/

PDFOpenParameters.pdf.

[6] Dave Raggett, Arnaud Le Hors, and Ian Jacobs. HTML 4.0 Specification, W3C Recom-

mendation. Beschikbaar op http://www.w3.org/TR/1998/REC-html40-19980424/.

[7] Jakub Sendor. Implementing the Media Fragments URI Specification: Media Fragments

Firefox Extension. Technical report. Beschikbaar op http://www.w3.org/2008/WebVideo/

Fragments/talks/2010-06-30-Jakub_Sendor-Media_Fragment_Firefox_Plugin.pdf.

[8] Raphael Troncy, Erik Mannens, Silvia Pfeiffer, and Davy Van Deursen. Media Fragments

URI 1.0 (basic), W3C Proposed Recommendation. Beschikbaar op http://www.w3.org/

TR/media-frags/.

http://tools.ietf.org/html/rfc3986#section-3.5

http://tools.ietf.org/html/rfc3986#section-3.5

http://www.w3.org/TR/html5/

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf

http://www.w3.org/TR/1998/REC-html40-19980424/

http://www.w3.org/2008/WebVideo/Fragments/talks/2010-06-30-Jakub_Sendor-Media_Fragment_Firefox_Plugin.pdf

http://www.w3.org/2008/WebVideo/Fragments/talks/2010-06-30-Jakub_Sendor-Media_Fragment_Firefox_Plugin.pdf

http://www.w3.org/TR/media-frags/

http://www.w3.org/TR/media-frags/

BIBLIOGRAFIE 60

[9] Raphael Troncy, Erik Mannens, Silvia Pfeiffer, and Davy Van Deursen. Media Frag-

ments URI 1.0, W3C Working Draft. Beschikbaar op http://www.w3.org/TR/2010/

WD-media-frags-20100624/.

[10] E. Wilde and M. Duerst. URI Fragment Identifiers for the text/plain Media Type. Beschik-

baar op http://tools.ietf.org/html/rfc5147.

http://www.w3.org/TR/2010/WD-media-frags-20100624/

http://www.w3.org/TR/2010/WD-media-frags-20100624/

http://tools.ietf.org/html/rfc5147

LIJST VAN FIGUREN 61

Lijst van figuren

2.1 HTTP-verkeer bij een temporeel fragment . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Niet gedownloade data wordt vervangen door nullen. . . . . . . . . . . . . . . . . 19

3.2 Bandbreedtebesparing met een proxyserver . . . . . . . . . . . . . . . . . . . . . 23

4.1 Hoofdstructuur van de Media Fragments-parser . . . . . . . . . . . . . . . . . . . 30

4.2 Architectuur van de Media Fragments-parser . . . . . . . . . . . . . . . . . . . . 31

4.3 Logging-architectuur van de Media Fragments-parser . . . . . . . . . . . . . . . . 34

5.1 Het starten van een Activity vanuit de huidige Activity . . . . . . . . . . . . . 36

5.2 De eerste twee schermen van de Media Fragments-app . . . . . . . . . . . . . . . 38

5.3 De videospeler in portretmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4 Inzoomen op een spatiaal fragment . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.5 De videospeler in landschapsmodus . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 Schematische voorstelling van een traject . . . . . . . . . . . . . . . . . . . . . . 43

6.2 De ’keep’-vlag als laatste vlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Uitbreiding van de Media Fragments-parser voor spatiaal-temporele fragmentatie 45

6.4 Omzetting naar arraywaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.5 Interpolatie in spatiaal-temporele fragmentatie . . . . . . . . . . . . . . . . . . . 47

A.1 De Android emulator met SDK 10, onder Ubuntu 11.10. . . . . . . . . . . . . . . 51

LIJST VAN TABELLEN 62

Lijst van tabellen

1.2 Bestaande URI-fragments voor bepaalde MIME-types . . . . . . . . . . . . . . . 4

2.1 Historiek van de Media Fragments-specificatie . . . . . . . . . . . . . . . . . . . . 13

4.2 AbstractValueParser-, AbstractValue- en Suffix-implementaties . . . . . . . 28

A.2 Een greep uit de verschillende Android-versies . . . . . . . . . . . . . . . . . . . . 50

D.2 Enkele velden uit de AVPacket-struct . . . . . . . . . . . . . . . . . . . . . . . . . 56

Implementatie en uitbreiding van de Media Fragments-speci ... · Implementatie en uitbreiding van...

Documents

Transcript of Implementatie en uitbreiding van de Media Fragments-speci ... · Implementatie en uitbreiding van...