improving the performance of media servers providing ...lgis.informatik.uni-kl.de/archiv/... ·...

Dipl.-Inform. Ulrich Marder

UNIVERSITÄTKAISERSLAUTERN

Improving the Performance of Media Servers

Providing Physical Data Independence—Problems,

Concepts, and Challenges

Ulrich Marderwww.ulrich-marder.de

Multimedia Database Support for Digital LibrariesSeminar at Schloss Dagstuhl, 29.08.-03.09.99

VirtualMedia VirtualMedia

Ulrich Marder

Click on the slides to switch between big slides and small slides with notes.

http://www.ulrich-marder.de

Dagstuhl-Seminar 99351, 29.08.-03.09.99 2Dipl.-Inform. Ulrich Marder


Outline

• Problems– Applications requiring physical data independence– Bad performance—the crux with unified data formats

• Concepts– The transformation independence abstraction– Interface considerations– Virtual media objects—Swanky quick-change artists on stage– Materialization—Saving the show on backstage

• Challenges– Solving the optimization problem(s)– Integration with common DBMS technology



Typical Applications

MultimediaDatabaseSystem

Desktop-PC Workstation Mac II

RecherchePresentation

AcquisitionAnalysing

EditingComposing

Global Media Data(Media Assets)

HeterogeneousClients

DifferentApplications



Problems Occuring during MO Life Cycle

Content/Media Sem.

Max.Quality

Dataformat'

Int(Media)

MO

Content/Media Sem.

Quality

Data format

ExtA

MO

Content/Media Sem.

Quality'

Dataformat''

ExtB

MO

Content'/Media Sem'

Quality''

Dataformat'''

ExtC

MO'

Content''/Media Sem''

Max.Quality

Dataformat''''

Int(Media')

MO''

Cre

ate

Ret

rieve

(MO

)

Ret

r_M

od(M

O)

Mod

ify(M

O)

Problem:Problem:Possibleloss ofdata

Problem:Problem:Bad performance, ifData format‘‘ = Dataformat ≠≠ Data format‘

Problem:Problem:Optimization to bebased on internal data(Data format‘)

ServerSide

ClientSide

Time



Consequences

• Allow modifications, but prevent information loss– Do some kind of versioning

• Prioritize access path to older versions (originals)

• First, optimize the most common case– Use the most popular external data format(s) internally

• May vary at run-time• May introduce redundance

• Second, make efforts to optimize the more special cases– Modify-operations must be expressable w/o any references to

or assumptions on the internal data format• Dynamic optimization (at the server-side)• Mapping of abstract semantics to executable operations is hard

and may produce imperfect results



Transformation Independence AbstractionFreedom for Clients—Heavy Work for Servers

• Create, retrieve, and modify by transformation request– Describes what result the client expects

• Data format & quality• Modify-operations

– Does not prescribe an algorithm to achieve the result• No helper-operations• Only semantically significant operation sequences

– Does not prescribe where to execute operations– Does not prescribe what is to be materialized

• Thus, three dimensions for optimization:– Algorithm: (Re-)ordering, substitution (of operations)– Place of execution: data-centric, client-centric, HW-centric,...– Materialization: redundant, non-redundant, client-centric,...

Interface Considerations

<?XML version=”1.0” standalone=”yes”?><VMDESC>

<SOURCE><MOID ALIAS=”BC_Video” REF=”CNN_Videos/4711”>

</MOID></SOURCE>

<VIRTUAL NAME=”TranscriptedSpeech”MAINTYPE=”TEXT”SUBTYPE=”PLAIN”ENCODING=”UTF-8”>

<TRANSFORMATION NAME=”Transcription”><OPERATION NAME=”Transcript”><INPUT NAME=”BC_Video”/><PARAM NAME=”Language” VALUE=”EN”/>

</OPERATION></TRANSFORMATION>

</VIRTUAL>

A sample transformation request (VirtualMedia descriptor)

<VIRTUAL NAME=”Speech”MAINTYPE=”AUDIO”SUBTYPE=”WAVEFORM”ENCODING=”WAV”>

<QUALITY><SAMPLING_FREQUENCY>44100</SAMPLING_FREQUENCY><SAMPLE_DEPTH>16</SAMPLE_DEPTH>

</QUALITY>

<TRANSFORMATION><OPERATION NAME=”NOP”><INPUT NAME=”BC_Video”/>


</VIRTUAL>

</VMDESC>



Virtual Media Objects—A schematical view

Client-VMO

Filterm+1

Filter l

VMOmoid=1

VMOmoid=k

Filter 1

Filter 2

Filter m

MOmid=1

MOmid=2

MOmid=n

A materia-lization withinternal id

A virtualMO withexternal id

Realizes one(or more)specificmodify-operation(s)

Datastream



VirtualMedia Transformation Request Graph

VMOmoid=CNN_Videos/4711

TranscriptVClient-VMO

“TranscriptedSpeech”

Client-VMO“Speech”

Virtual mediaobject of typeVideo

Virtual mediafilter (acceptingany media input)

Tasks:• Find appropriate materializations of VMOs• Replace virtual filters with optimal, semantically

correct implementation

Audio/Waveform/WAV

Text/Plain/UTF-8

External dataformat acceptedby the client



VirtualMedia Materialization Graph

MOmid=4711/Soundtrack

MOmid=4711/Clip1

MOmid=4711/Clip2

MOmid=4711/Clip3

AssembleI

ComposeI


Audio/Waveform/WAV/Stereo

Video/SingleStream/MotionJPEG

Video/MultipleStream/*

Instantiablemedia filter

A primarymateria-lization withinternal id

Internal dataformat providedby materialization

MOmid=4711/Assembled Video/MultipleStream/AVI

A secondary materialization with internal id



Transformation Request Resolution (1)


TranscriptIClient-VMO



Virtualmedia objectof type Video

Instantiable mediafilter (implementingthe virtualtranscript-filter)

Data formatprovided by thefilter (matchesclient request)

DecomposeV

Text/Plain/UTF-8

Audio/Waveform/WAV/Mono

Data formataccepted bythe filterVideo/MultipleStream/*

Audio/Waveform/WAV

Audio/*

New virtualmedia filter



Transformation Request Resolution (2)

TranscriptIClient-VMO



Materializationof the VMO oftype Audio

Matches format of MOm

Audio2MonoI

Text/Plain/UTF-8


Data format providedby the converter isaccepted by thetranscript-filter


Audio/Waveform/WAV

New instantiablemedia filter(converter)




Adding a Materialization


Existing primaryand secondarymaterializations

MOmid=4711/Transcript

TranscriptV

New derivedmaterializationof type TextText/Plain/UTF-8

New branch ofthe materia-lization graph

Text/Plain/UTF-8

TranscriptI

Audio2MonoI




Remembering history may be usefulto detect obsolete materializations



Challenges

• Refine VM-graph-transformation algorithm– Approach: Rule-based algebraic optimization (well understood)– Floorers: Secondary and derived materializations—how to

control the risk of trading quality for performance?Ä Quality assessment of materializations (use fuzzy system?)

• Refine VirtualMedia model– Parametrized VMOs (templates)– Hierarchically structured VM-graphs (encapsulation)

• Integration with common DBMS technology– Exploit extensibility– Object-relational features facilitate tight integration– But: media server especially adapted to VirtualMedia required



ORDBMS

VM/FVM-SysDB

S1

VMOs,Configurations,Statistics, ...

KANGAROOMedia Server

Application Media channel(s)

SQL-Q

ueriesC1

Software Architecture Proposal

Control




Sn

S3

S2

Media servercluster storing allmaterializations

Ressourcemanagement,process andchannelinstantiation

Media server withmedia processingcapabilities (filter)

Reducible toAPI +Comm. Prot.



Conclusions

• Problems with physical data independence– Bad performance due to frequent format conversions– Loss of data due to irreversible modify-operations– All optimization must be based on internal data representation

• Concepts– Transformation independence

• Abstract semantics at API-level• Multiple optimization dimensions (algorithm, materialization, ...)

– VirtualMedia• Optimal matching of transformation request graphs and

materialization graphs

• Challenges– Pretty to much to enumerate...



Additional Material

• VirtualMedia home page athttp://pfau.informatik.uni-kl.de/virtualmedia

• SMIL-presentation based on the present slides

– Available after the seminar (scheduled for sept.)– URL (a link will be provided at the home page)

http://pfau.informatik.uni-kl.de:8090/ramgen/presentations/Dagstuhl99/real/slideshow.smi

– RealPlayer® G2 required for playback

http://pfau.informatik.uni-kl.de/virtualmedia

http://pfau.informatik.uni-kl.de:8090/ramgen/presentations/Dagstuhl99/real/slideshow.smi



Appendix 1: Sample Create-request<?XML version=”1.0” standalone=”yes”?><VMDESC>

<SOURCE><MOM ALIAS=”Sound”REF=”File://Client1/Media/sound.wav”MAINTYPE=”AUDIO” SUBTYPE=”WAVEFORM”ENCODING=”WAV”><QUALITY><SAMPLING_FREQUENCY>44100</SAMPLING_FREQUENCY><SAMPLE_DEPTH>16</SAMPLE_DEPTH><CHANNELS>Stereo</CHANNELS>

</QUALITY></MOM><MOM ALIAS=”Clip1”REF=”File://Client1/Media/clip1.avi”MAINTYPE=”VIDEO” SUBTYPE=”SINGLESTREAM”ENCODING=”AVI/MJPEG”><QUALITY><IMAGE_WIDTH>704</IMAGE_WIDTH><IMAGE_HEIGHT>480</IMAGE_HEIGHT><FRAME_RATE>25</FRAME_RATE>

</QUALITY></MOM>

<MOM ALIAS=”Clip2” ...>...</MOM><MOM ALIAS=”Clip3” ...>...</MOM>

</SOURCE>

<VIRTUAL NAME=”BC_Video” MAINTYPE=”VIDEO”SUBTYPE=”MULTIPLESTREAM”>

<TRANSFORMATION><OPERATION NAME=”Assemble”><INPUT NAME=”Clip1”/><INPUT NAME=”Clip2”/><INPUT NAME=”Clip3”/><PARAM SEQUENCE=”Clip1, Clip2, Clip3”/><OUTPUT NAME=”Clip”/>

</OPERATION><OPERATION NAME=”Compose”><INPUT NAME=”Sound”/><INPUT NAME=”Clip”/>


</VIRTUAL>

</VMDESC>

1

Dipl.-Inform. Ulrich Marder


� �� ! �� "�� #"$ ��%�&'�� ()�� *�% ��" +

, �� " +�� , ��% % ��"

- . / 0 1 243�5 / 6 7 /8 8 8 9 : ; < = > ? @ A�B < C D < 9 C D

Multimedia Database Support for Digital LibrariesSeminar at Schloss Dagstuhl, 29.08.-03.09.99

VirtualMedia VirtualMedia

This presentation deals with media servers providing physical dataindependence. Today’s media servers - especially continuous media servers -usually do not provide physical data independence at all. One - if not themain - reason for this is performance. Physical data independence withoutoptimization costs a lot of performance. Therefore, we are looking for asolution of this optimization problem.

2



EGF�H�I J KML

NPO�Q RS�T U�V�WXZY�[�[�\ ] ^ _ ` ] a�b�c�d e f�g�] d ] b�h4[�i$j�c ] ^ _ \�k�_ ` _4] b�k�e [�e b�k�e b�^ eXml�_ kn[�e d o a�d p'_ b�^ e qr` i�e�^ d g�s�tu] ` ing�b�] o ] e knk�_ ` _4o a�d p'_ ` c

vxw4y�z�{�|�}�~ ��m�� '� � � �� m� �� Z�� '� �� 4�� r� �4� ��$�� m�'� � � � � � � � � � � ��r� � ¡�� u� �� ¢��

£x¤�¥�¦�§ § ¨�©�ª¨�«¬m ®$¯ °�± ²�³u´ µ�¶�®�·�´ ± ¸'± ¹ º ´ ± ®�²�·�» ®�¼$¯ ¶ ¸'½ ¾ ¿¬mÀ ²�´ ¶ ³ » º ´ ± ®�²�Áu± ´ µnÂ ®�¸�¸'®�²�Ã�Ä�Å'4´ ¶ Â µ�²�®$¯ ®�³ Æ

This is a short overview of the talk.

We begin with looking at the problems that actually cause the performanceloss. Most of this has to do with the ‘standard solution’ for providingphysical data independence, that is using unified data formats. There is aquotation from Herbert Mencken which is certainly true in this case: “Forevery problem there is one solution which is simple, neat, and wrong.”

Next, concepts for a better solution are introduced. The most abstract versionof these concepts is the so-called transformation independence abstraction.Then, we will show how this abstraction can be realized by virtual mediaobjects.

Finally, some remarks on the challenges still waiting will be made.

3



ÇÉÈnÊ!Ë Ì4Í�Î�ÏÐÊ�Ê!Î Ë Ì�Í�Ñ�Ë Ò'Ó�Ô

MultimediaDatabaseSystem

Desktop-PC Workstation Mac II

RecherchePresentation

AcquisitionAnalysing

EditingComposing

ÕÖ ×�Ø�Ù Ö�Ú'Û Ü�Ý Ù4Þ�Ù ß Ùà Ú'Û Ü�Ý Ù�á�â â Û ß â ã

ä Û ß Û å ×�æ Û ç�Û ×�è�âé�Ö Ý Û ç�ß â

Þ�Ý ê ê Û å Û ç�ßá�ë�ë�Ö Ý ì Ù ß Ý ×�ç�â

This is an application scenario showing a typical situation where physicaldata independence would be highly beneficial. There is global media data -sometimes called media assets - stored in a MMDBMS. There areheterogeneous clients with different capabilities of storing, processing, andpresenting media data. And there are different applications. Some only wantto retrieve media objects for presentation or possibly printing. Others createor modify media objects. And again others create media objects by editingand combining existing ones. But note that there is sort of unbalance:Usually there are many applications of the presentation type but few of theother types. The latter, however, often have stronger quality demands.

4



í�î�ï'ð!ñ òuóPôÐõGö�ö4÷�î�ø ù�úüû�÷�îø ùMúüýPõÿþ'ø �$ò��nö�ñ ò

Content/Media Sem.

Max.Quality

Dataformat’

Int(Media)

MO

Content/Media Sem.

Quality

Data format

ExtA

MO

Content/Media Sem.

Quality’

Dataformat’’

ExtB

MO

Content’/Media Sem’

Quality’’

Dataformat’’’

ExtC

MO’

Content’’/Media Sem’’

Max.Quality

Dataformat’’’’

Int(Media’)

MO’’

Cre

ate

Ret

rieve

(MO

)

Ret

r_M

od(M

O)

Mod

ify(M

O)

� � � � � ��

� � � � � � � ! " #%$ & ' ( ) ' *+" , - & . / (Data format‘‘ = Dataformat ≠ Data format‘

0 1 2 3 4 5 6 78 9 : ; <=; > ? : ; @ A=: @%B CB ? D C E%@ A%; A : C F A ? G E ? : ?(Data format‘)

H I J K I JH L M I

NPO L I QSRH L M I

T U V+W

On this slide part of the life cycle of a media object (MO) in such a system isshown.

First, the MO is created by some application. The external and internal dataformats may be different. Second, another application will eventuallyretrieve this object. Again, the external and internal data format may bedifferent. Also, the quality of the retrieved object may change. In the thirdcase, some modifications of the MO are invoked prior to to retrieving it. Themodifications are only to be applied to the MO delivered, but not to be madepersistent. In the last case, the MO is updated in the database.

One can observe three problems here:

First, we get bad performance if the external formats are equal but differentfrom the internal format. We can assume that this will happen quitefrequently (except the creating application happens to choose an exoticexternal format). Hence, any solution enforcing data conversion to a unifiedinternal format is far from being optimal.

Second, all optimization regarding modify-operations has to be based on theinternal data format. Thus, there is no chance of leaving optimization to theclient application.

And third, the update-operation generally causes a loss of informationbecause many modifications are irreversible. This problem is not particularlydependent on physical data independence. Its solution, however, isdependent on the materialization strategy and, thus, subject to optimization.

5



XZY\[^]`_badc^_e[gfh_e]

ikj\l l m npoqmsr`t u t vPw=x t msy{z |=}`~{x{�`� �S� �%y{x{t y{u ms� o�w+x t msyZl m`z z��{�� P�\�h�P� �=��P�S�P� � � � �P�=� �%�

�^�S� � � � � � � � �s� � � � � �=�S� � �h� �h� ¡S� �%¢ � � � � � £P� ¤ � � � ¥ � £P� � ¦§©¨`ª « ¬S ®+¯s°` ª ±qª ²%³´ µ{³´±q¯s¬S`¶P¯`±�±q¯s·Z¶S¸+¬ ³

¹�ºh» ¼h½ ¾%¼{¿\ÀP» ½%Á%ÀPÁ%Â%Ã Ä Ås¼ ÆS½ ¼ Å Ç%Ä ÃPÈ%Ä ½ ÄeÉ ÀPÅ ¿\Ä ½ Ê » Ë=Ì Ç%½ ¼ Å Ç=Ä Ã Ã ÍÎ^Ï�Ð Ñ`Ò Ð Ó ÑhÐ ÔSÓ ÕSÖP× Ô Ø Ù�ÚÎ^Ï�Ð ÑhØ ÖSÔ Ó Û Ü ÕSÝ Ú Ó Ú Ü ÕSÖPÜ Ð ÖSÝ Ú

Þàß+áPâPãsä{åsæ+çqè%é`á\áPê ê ãsë ì í�ì ãîãsï`ì ð çqð ñ%á´ì ò{á´çqãsë á´í ï`á%âPð è+ó âSè+í á%íô�õ\öP÷%ø ù úPû öPü%ý þ ÿ � ø ö�� Pýhý �Sü%þ ý � � ÿ �� ý� �� ö ÿ �Pú þ ý ù ý þ ý �� ý �� ööPþsÿ � � ��\ü�� ø ö��sö�� %ýhø �� ý þ �=ÿ �P÷%ÿ � ÿhù öPþ �\ÿ �� ! " � �� # � " � � �%$ � "&" '&(�) ( * + ( * , ) � -&( .��/�� !&!&� �&01� 2�� 3&) " * � � "�) ( �� &" � � )" �1( 4 ( � 5 " � 3 6 ( � !&( * � " � � ��)�� )'&� * -� ��-7�� 1! * � - 5�� ( � �%!&( * 2 ( � "&* ( ) 5 6 " )

The following consequences can be drawn from the previous observations.

First, we certainly want to allow modifications, but we also want to preventinformation loss. Therefore, some kind of version control will be required. Incontrast to more traditional versioning models, the access path to the olderversion is always to be prioritized. That means, an application maintainingan external reference to an MO will always get it unmodified by otherapplications.

Considering optimization, we should optimize the most common case in thefirst place. And that means, quite obviously, that we have to use the mostpopular external formats also as internal formats in order to prevent formatconversions as often as possible. Of course, what is popular may vary duringthe life cycle of an MO. This variation may also introduce redundance - thatis materialization in different formats at the same time.

But we should also attempt to optimize the more special cases. This meansoptimizing media modifications at the server. As a precondition suchoperations must be expressablewithout any reference to or even assumptionson the internal format. Then, it would be possible to do optimization bydynamic programming. However, mapping of such abstract operations toreally executable operations is subject to some semantic fuzziness and,hence, may occasionally produce imperfect results.

6



8:9�;%<>=�?&@A9 BC;%D�E @A<GF<�H�I�J�IK<�H�I�<>L7INMPOQ=�D&9�;%L�D&E @A<R�S T T U�V�WYX V�S�Z�[ \ T ]�^ _ `ba�T c d eKf:V�S g%X V�S�h T S d�T S _

iCj�k l�mn l�o�k l�n k p l&q l�o�mr1s:tbu�s�p v w�x wzy {�|�}�~ � �{ ��|�y � �}�{��7� ��~�y�N�1� � � � � �� 7� � � � �� &��

�� ¡�¢ £�� ¤ ¥ � ¦��§�� ¨&¥ � ¦ © � ª&« � � � ¥ � ¬�

®N¯1°�± ²�³°�´µ�¶ ± ² · ¶ ¸ ¹�±7º ³�º » ¼ °�¶ ¸ ´ ½�¾Y´ °%º · ½�¸ ± ¿&±7´ ½�±1¶ ± ² À�» ´Á�Â�Ã�Ä�Å Æ Ç&Å È É Ã Ç�Å È Ê Ë Ì Ã Í�ÎÁ>Ï�Í&Æ Ð7Î Å Ñ%Ê Í&Ë Ì Ò Ê Æ Æ Ð7Î Ì Ó Í�Ì Ô Ì Ò Ê Í&Ë�Ã Ç&Å È Ê Ë Ì Ã ÍKÎ Å Õ Ö�Å Í�Ò Å Î

×NØ1Ù�Ú Û�ÜÙ�ÝÞ�ß Ú Û à ß á â�Ú�ã�ä�Ú ß Ú7Ý Ù%Ú å&Ú à æÝ Ú7Ù�Þ�Ú ß ç Ý á Ù�ÜÛ×NØ1Ù�Ú Û�ÜÙ�ÝÞ�ß Ú Û à ß á â�Ú�ã�ä�ç Ý�á Û�Ý Ù%â�Ú7è�ç Ý Ú ß á ç é á ê Ú ë

ìîí�ï1ð1ñ ò�ó ï7ô õ�õ�ö�÷ øzõ�ù1ñ ÷ ú�ù1ñ�û ú�ô�ü ýAþ ÿ �zÿ ��þ ÿ ü�� !�"� � � � !�� #� ��$��%�� & � � �� ('�� & ) �*��$�� +�� ) !�� & � &,� ) � �� ) � ) � � � �� ) � �� ) � -�./� ) � �� ) � 0 0 0�(1�& � � � � & � � 2 & � � �� !��& �� !��& �� ) � � � �� ) � �� ) � 0 0 0

Transformation independence is the most abstract version of our mediaserver concept. It is kind of extension of the traditional data independenceparadigm because it considers data format, data quality, and datamodifications together. All these aspects are described by the client in a so-called transformation request, which can be used to create, retrieve, andmodify MOs.

Also note that a transformation request

- does not prescribe an algorithm to achieve the result,

- does not prescribe where to execute operations,

- and does not prescribe what is to be materialized.

Thus, we get three dimensions for optimizing at the server. The server canreorder or substitute operations according to appropriate rules. The servercan decide for each operation wether it should be executed where the data is,where the client is, or where special hardware supporting it is. And theserver may choose to materialize MOs redundantly (or not) - or even at theclient’ s machine.

7



3�465�798�: ;=<97(>@?�46A�B CD798�;=5�B ?�46A

<?XML ver si on=” 1.0” st andal one=” yes” ?>

<VMDESC>

<SOURCE>

<MOID ALI AS=” BC_Video” REF=” CNN_Videos/4711” >

</ MOID>

</ SOURCE>

<VIRTUAL NAME=” TranscriptedSpeech”

MAI NTYPE=” TEXT”

SUBTYPE=” PLAIN”

ENCODI NG=” UTF-8” >

<TRANSFORMATION NAME=” Transcription” >

<OPERATION NAME=” Transcript” >

<INPUT NAME=” BC_Video” / >

<PARAM NAME=” Language” VALUE=” EN” / >

</ OPERATION>

</ TRANSFORMATION>

</ VIRTUAL>

E#F G H=I,J KML N G O�F P Q N HRG L S Q O9N K T U�K F L�V W�S N L U�G J XRK Y,S G�Y,K F Z N S I,L Q N [<VIRTUAL NAME=” Speech”

MAI NTYPE=” AUDIO”

SUBTYPE=” WAVEFORM”

ENCODI NG=” WAV” >

<QUALITY>

<SAMPLING_FREQUENCY>44100</ SAMPLING_FREQUENCY><SAMPLE_DEPTH>16</ SAMPLE_DEPTH>

<! - - Alternatively specify

<PROFI LE>CD- AUDI O</ PROFI LE>

- - >

</ QUALITY>

<TRANSFORMATION>

<OPERATION NAME=” NOP” >

<INPUT NAME=” BC_Video” / >

</ OPERATION>

</ TRANSFORMATION>

</ VIRTUAL>

</ VMDESC>

This a sample transformation request that the client may send to the server. Itis also sometimes called a VirtualMedia descriptor. This request firstreferences a media object which is stored in the database. This is a Videoobject. Next, the request describes two so-called virtual objects that are to bedelivered to the client. Each virtual object has a type and format description,transformation description, and optionally a quality description. Thetransformation description of the first virtual object means that it should be atranscription of the video referenced in the source-part. The second virtualobject is the audio-part of the same video-object. Its quality is specified verydetailed - so, another possibility would be using certain quality profiles.

8



\^] _�`�aDb=c#dfe9gD] bih^jlk e9m9`,n�oqprn�m�sDe9tfb=`,] m9b=c#uR] ewv

x�y z { |�} ~��l�

� z y } { ��

�� M�

��l�� 9�

��l��

��

�� M�

��

¡l¢M£¤ ¥�¦�§

¨l©Mª« ¬�M®

¯l°M±² ³�´�µ¶w·*¸ ¹ º » ¼ ¸ ½¾ ¼ ¿ ¸ ¹ ¼ À ÁÃÂÃ¼ ¹ Ä¼ Á ¹ º » Á ¸ ¾ ¼ Å

¶�Æ ¼ » ¹ Ç ¸ ¾È*É�ÂÃ¼ ¹ Äº Ê ¹ º » Á ¸ ¾ ¼ ÅË,º ¸ ¾ ¼ ¿ º Ì�À Á ºÍ À »,·*À » º ÎÌ Ï º Ð ¼ Ñ ¼ Ð·*À Å ¼ Ñ Ò ½À Ï º » ¸ ¹ ¼ À Á Í Ì Î

Ó�¸ ¹ ¸Ì ¹ » º ¸ ·

This graph should clarify what we mean by virtual media objects (VMO).The virtual objects described in the transformation request are actuallyclient-VMOs appearing as end-nodes of this graph. Database objects that arevisible to the client are also VMOs having an external media object id(moid). The graph also shows the relation between materializations andVMOs. The materializations, however, are not visible to clients and,therefore, have only internal ids. The edges of the graph determine how thedata has to flow in order to materialize the VMOs. At arbitrary points withinthat data flow filters can be placed that realize one (or maybe more) specificmodify-operation.

9



Ô^Õ Ö�×�ØDÙ=Ú ÛÝÜwÞlÕ Ùàß@Ö�Ù=á6â�ã ä�Ö�åfÙ=×,Õ ä�áçæèÜ9élØDÜ9â�×6êëÖ�Ù=ìDí

î�ïlðñ�ò ó ô õ ö ÷ ÷ ø ù ó ô ú ò û ü ý þ ÿ ÿ �� ! " # $ % ! # # � & '

(�) * + ,�- . /�0�12 3 4 5 5 6 7 8

9�: ; < = > ? @BA C : >D E F A G < D H < I J AK L M N O

P�Q R S T U V WBX Y Q UZ Q V S X R\[ U ] ] X ^ S Q _ `U _ abWBX Y Q U�Q _ ^ T S cdfe�g hBg ijlknm o�prq s�s�t uns�t m q v wBxyq v w t m q z m { q v m uno�|bu�}n~��y��|jl�bw snz q � w��\m t v ��q zn} m z v w t |��fm v �runs�v m xyq z � | w x�q o�v m � q z z �� unt t w � v�m xysnz w xyw o�v q v m uno

� � � � � � �� \� ��

� � � � � � � � � � � � � ¡ ¢

£ ¤ ¥ ¦ § ¨ © ª « © ¥ ©¬ § ®B© ¥ © ¯ ¯ ¦ ° ¥ ¦ «± ² ¥ ³ ¦�¯ ª ´ ¦ ¨ ¥

This is the previously shown transformation request translated into its graphrepresentation.

The start-node of this graph is the video-object which is the source object ofthe transformation request. The two virtual objects of the transformationrequest become end-nodes of the graph. The edges pointing to these end-nodes are labeled with the requested type and format specification. Thetranscript operation specified in the request is turned into an accordingvirtual media filter, which is placed within the the data flow from the sourceobject to the text-object. The filter must be virtual because its input isvirtual.

There are now two tasks for the server:

Find an appropriate materialization of the video-object. And replace thevirtual filter with its optimal, sematically correct implementation.

Before explaining that algorithm in some more detail, we should take a lookat the materialization graph of the virtual video-object.

10



µ·¶ ¸b¹nº¼»l½ ¾À¿fÁ�¶ »Â¾À»l¹n¿Ã¸b¶ »l½ ¶ Ä�»l¹n¶ ÅyÆÈÇÉ¸b»lÊ�Ë

Ì�ÍÏÎÐ Ñ Ò Ó Ô Õ Õ Ö × Ø Ù Ú Ñ Û Ü Ý Þ ß

à�áÏâã ä å æ ç è è é ê ë ã ì èí�îÏïð ñ ò ó ô õ õ ö ÷ ø ð ù úû�üÏýþ ÿ � � � � � � � � þ � �

� � ��

��

��! "�# $ % & ' ( ( ) * $ % + # , - . / 0 0

1 2 % $ # - 354 6 + 7 # 8 "9- 3 1 * - : ; + 8 + #

* $ % + # - : $ < = > + : ; 8 + 4 "9-? # ; $ # < @ A B C * $ % + # - ? 2 > ; $ D > + : ; 8 + 4 "9- E

F G H I J G I K J L M NO N P K J5Q K M I N RSUT R K O J R VO J I N R K J WM K X J I K Y G�Z�K I [K G I N R G J M K P

F G I N R G J M P J I JQ Y R O J I T R Y \ K P N PL V O J I N R K J M K X J I K Y G

]!^`_a b c d e f f g h i i j k9l m j b n a b j o g p q m r a s m j t r u j v k9g h n wxUy z { | } ~ � � �� z � � � � � � � � � | }`�� } � z � } � � � ~

The materialization graph of a VMO contains all its materializations andhow they are related to the VMO. There are different types ofmaterializations: primary, secondary, and derived materializations. The latterwill be considered on one of the following slides. Primary materializationsare provided at create-time of the VMO and are assumed to provide themaximum available quality of the VMO. Secondary materializations arecreated by the server purely for optimization purposes - usually withoutinforming the applications. Hence, the server may create or destroysecondary materializations whenever this seems likely to improve theperformance of the MMDBMS. As shown in the example, materializationgraphs can also contain media filters. But in contrast to the transformationrequest graph, these media filters are already instantiable. This is possiblebecause the input data formats are always known.

11



��9��`�� !� �U��¡�U��¢ � �� ¤£5¥5¦

§�¨!©ª�« ¬ ® ¯ ° ° ± ² ¬ ³ « ´ µ ¶ · ¸ ¸ ¹�º » ¼5½ ¾ º ¿ À�Á Â Ã5Ä Å Æ Ç�È É Ê�Ë!ÌÍ Î Ï Ð Ñ Ò Ó Ï Ô Õ Ö × Ø Ù Õ × × Ó Ú Û

Ü5Ý Þ ß à�á â ã�ä!åæ ç è é é ê ë ì

í5î ï ð ñ ò óô�õ ö î ò5÷ ø ù õ ú ð÷ û ð ü ý õ�þ ÿ � � ��

� � � � � � � �� ! � � � � �

"�# $ %�&(' %�) # *

+ , - . / 0 1 2 3 4 / 5 + 6 7 8

9 : ; 3 < / =>2 ? , @ < A B�/= 9 C / D�< 4 <E F G F>H I J K�F GF L L M N G M O�P QG R M>H S T G M JU V W X Y Z [ \ ] ^ V _ ] X ` ^ a X b c�Z d

e \ W V Y Z f>b g X h Y a c�Z f>e U

e \ W V Y Z d

i j kml n o p q r st j u n r>v n s p j o

We are now considering the transformation request resolution algorithm bylooking at how it transforms the original request graph of the example.

In the snapshot shown on the slide the virtual transcript-filter is replaced bysome instantiable transcript filter. This filter introduces new requirements onthe data formats. While the output format of the filter nicely matches theclient’ s request, the input specification does not fit at all: it has to be anaudio-object whereas the input supplied by the VMO is a video-object. Sincethe transformation request does not say anything about how to turn the videointo audio, the resolution algorithm chooses a default rule for resolving thismismatch, which is inserting a (virtual) decompose-filter. Obviously, thesame considerations apply to the second client-VMO.

To continue the resolution process this intermediate graph must now beconnected with the materialization graph.

12



wyx�zm{}|�~��(x��zm�� ({��|��}��|��(� �� ({��

�� >� � � � � � ¡>¢ £ ¤ ¥ ¦ § ¨ª©�«¬ ® ¯ ° ± ² ® ³ ´ µ ¶ · ¸ ´ ¶ ¶ ² ¹ º

»>¼ ½ ¾ ¿ À Á ÂªÃ�ÄÅ Æ Ç È È É Ê Ë

Ì�Í Î Ï Ð Ñ Í Ò Ñ Ó Í Î Ñ Ô ÕÔ Ö Î × Ï�Ø>Ì�Ù�Ô ÖÎ Ú Û Ï Ü�Ý Þ ß à

á�â ã ä å æ ç�è é ê ë�â ã é è á�ì�í

î�ï ð ñ ò�ó�ô(ò�õ ò�ö

÷ ø ù ú û ü ý þ ÿ � û � ÷ � � �

� � � ÿ � û >þ ø � � � �û � � û ��

�� ! � " ��# � $ � � � � � �� %� # # � � � � � ! � " �� $ % # � � � � & � � ' � � �

( ) * + , - .�/ 0 1 2 , 3 4�-.�( 5 - 6 7 1 3 1 ,

( ) * + , - .�/ 0 1 2 , 3 4�- .�( 58�9 :<; = > ? @ = ? ; @ A B 9C 9 D ; @�E ; B ? 9 FG H I = J 9 F ? 9 F K

LNMPOQ R S T U V V W X Y Z [ R \ ] ^ _ `

This slide shows the result of the transformation request resolution.

The virtual decompose-filter which had been introduced intermediatelycould be eliminated again, because it is the inverse of the compose-filter inthe materialization graph. Thus, the resolution algorithm finds the primarymaterialization of the video-soundtrack being the optimal source object forthe client’ s request. There is a slight format mismatch between thematerialization and the input-specification of the transcript-filter, which isresolved by inserting a suitable converter-filter. Note that, to make this work,the algorithm must be told that such converters are semantically neutral.This might, however, be untrue in some rare situations, which is the reasonwhy we cannot expect the algorithm to always work perfectly with respect topreserving the semantics of the client’s request.

13



acbdbNe fhgjilkmion�prqse iot e uvion�e wxf

y{zN|}�~ � � � � � � � � � � � ~ � � � � � �

� � � � � � � �P� � � �� s� � � � � � � � ��

N¡P¢£ ¤ ¥ ¦ § ¨ ¨ © ª « ¬ ® ¯ « £ ° ±

²´³ µ ¶�· ¸ ³ ¹ º�» ¼

½�¾ ¿xÀ Á Â Ã Ä Á ÀÅ�Æ Ç È É Ê Æ Ë Ê Ì Æ Ç Ê Í ÎÍ Ï Ç Ð Ñ È�Ò Ó Ô ÕÖ × Ø Ù Ú Û Ü Ý Þ ß Ú à Ö á â ã

ä�å æ<ç è é ê ë ìsí îï ì å�ð�é ï å è ñ é òó ñ ô é ï ñ í êPõ è é ö ì

÷ ø ù ú û ü ý þ ÿ � û � ÷ � � ��

�� ! " # $ %�& ' ( ) # * +�$%�� , $ - . ( * ( #

/10324 5 6 7 8 9 9 : ; < = > 5 ? @ A B C

D = 5 4 < : E�A F G H < @ I�:E�D J : K�< > <

L�M N�M N�O M P Q R S3T Q U V W P X3N�Y X3O M�Z U M [ Z \V W^] M V M _ V W O U W \ M V M�N�Y V M P Q Y \ Q ` Y V Q W R U

After resolving the transformation request the server may detect that thecosts of creating the transcription are very high compared to the costs ofstoring it for later reuse. To enable reuse a new branch of the materializationgraph must be created, leading from the VMO to the derived materialization.Obviously, this branch must include all virtual filters, thus describing thesemantics of the new materialization. Additionally, it is advisable to includethe real origin of derived materializations in the graph. This helps assessingthe actuality and quality of the materialization, which is necessary to decidewether the client’ s quality demands are met if the server uses thematerialization to fulfill a certain request.

14



acbedgf f hjilkmhon

prqms�t u v�smwyx{z |�} ~��^��z � } ~�v�� t �^} ��~�� u �^vc~�� |��} u � �� 3�� y¡ ¢j� � �� £�¥¤�� ¦ � � �� §g� �� ¨�� m�� ©{�� ¢c� �� ª� � � «g��¬�� j�� §g¬ ��^�� ¬ �� ®¯�°�±�² ³ ´ µ ¶g² · · ¸ · · ¹y¸ º�µ�»�¼�¹y² µ ¸ ½ ´ ² ³ ´ ¾ ² µ ´ »�º�·�¿ ±�· ¸ª¼ ±�¾ ¾ ¶g· ¶�· µ ¸ ¹�À Á

ÂrÃmÄ�Å Æ Ç�ÄmÈ�Æ É Ê Ë�Ì�Í ÎÏÄ�Ð�Æ Ì1ÑÏÒ^Ð�Ä�ÍÓ¥Ô�Õ Ö Õ ×�Ø Ù Ö Ú Û Ø ÜmÝªÞ1ß�à�á Ù Ø ×�â�ã Õ Ù Ø à äÓ¥åjÚ Ø Ö Õ Ö æ ç�Ú æ Õ ã ã ègà Ù Ö é�æ Ù é�Ö Ø ÜgÝªÞ1ê ë Ö Õ â�ç�à�á Ø ì�æ Õ â�à é�ã Õ Ù Ú í�ì�ä

îrï ð�ñ ò�ó�ô õ�ñ ö ÷^ðløeö ñ ùcú�÷^ûÏû�÷�ðýüyþªÿ��eñ ò�ú ùªð�÷�� ÷^ó�� !� � " #�� " � � � � � ��$% �� & '(� )�� !� � � * � �� +� )�� ),� �+-!� � � �� ./� )�� 0� � 1� �� )

The development of the VirtualMedia concept has just started. Hence, itshould be no surprise that we are still facing a considerable number ofchallenges.

The next one to be tackled is refinement and formalization of the graphtransformation algorithm for resolving and optimizing the client’s requests.We are currently considering rule-based algebraic optimization as apromizing approach. One of the most difficult parts of the algorithmprobably is controlling the employment of secondary and derivedmaterializations, because, ultimately, this requires sort of quality assessmentof materializations.

Especially from the client’s point of view, there certainly is a need forrefining the VirtualMedia model itself, e. g. by introducing parametrizedVMOs as easy-to-use templates or by enabling hierarchical structures inVM-graphs.

For realizing the VirtualMedia concept we currently favorite integration withcommon DBMS-technology. Thereby, the extensibility features of modernDBMSs could be exploited. Such DBMSs, however, are not capable ofprocessing media streams in real-time. Therefore, we propose an architecturewhere the work is shared between an appropriately extended OR-DBMS andseveral specialized media servers.

15



243+5(6!798:!;(< =>@?4AB C D E@F

G HI�JLK M NO P Q R S T U V W X S P Q M NY X W X S M X S Z M N [ [ [

\ ] ^ _ ] ` a ab�c d e f g c h i c h

j/k�k�l m n o�p m q�r s%t u v w�x y w z z t { | } ~��

�4�/��+��@�0�� 0�0��/��(�L�+�

� � ¡ ¢ � £

¤ ¥ ¦ § ¥ ¨ © ©ª�« ¬ ® ¯ « ° ± « °² ³ ´ µ ³ ¶ · ·¸�¹ º » ¼ ½ ¹ ¾ ¿ ¹ ¾

À Á Â Ã Á Ä Å ÅÆ�Ç È É Ê Ë Ç Ì Í Ç Ì

Ë Î

Ï Ð

Ï Ñ

ÒLÓ Ô Õ Ö�× Ó Ø Ù Ó ØÚ Û Ü × Ý Ó Ø�× Ý Þ Ø Õ ß à@Ö Û Ûá Ö Ý Ó Ø Õ Ö Û Õ â Ö Ý Õ Þ ß ×

ã�Ó × × Þ Ü Ø Ú Óá Ö ß Ö à Ó á Ó ß Ý äå Ø Þ Ú Ó × × Ö ß ÔÚ æ Ö ß ß Ó ÛÕ ß × Ý Ö ß Ý Õ Ö Ý Õ Þ ßÒLÓ Ô Õ Ö�× Ó Ø Ù Ó Ø ç%Õ Ý æá Ó Ô Õ Ö å Ø Þ Ú Ó × × Õ ß àÚ Ö å Ö è Õ Û Õ Ý Õ Ó ×�é ê Õ Û Ý Ó Ø ë

ã�Ó Ô Ü Ú Õ è Û Ó�Ý Þì�í î ïð Þ áLáLñ í Ø Þ Ý ñ

The OR-DBMS-extension stores all the VMOs. Additionally, it manages thewhole system configuration, statistics, and so on. And, of course, it mustimplement the request resolution algorithm. Besides that, there is a cluster ofmedia servers managing the materializations and providing the mediaprocessing capabilities, where each server may specialize on certain mediatypes or filter operations. The whole cluster is fully controlled by the OR-DBMS-extension. That means, the client application can only open achannel to the media servers by sending an appropriate transformationrequest to the OR-DBMS. Usually, there is also a media server on the clientmachine. This could be a fully functional server allowing filtering or evenmaterialization directly on the client, or it could be merely a stub providingonly the interface between the application and the media server cluster.Anyway, it is only the server - not the application - that knows about this andhas to consider it for optimization.

16



òôó/õ�ö0÷ ø�ù�ú ó(õûùüþýLÿ ��

�� "!�# $ % &�$ '(� )�* #� �+�#-, &.% $ # /�+�# )�,�% &�$ '0� ,�* &�)�1�# $ 2 3 &�)�2��4�&�2 2�&�%� �� , �5 �+�#�, &.3 $ $ # 16# $ 2 3 7�8 #-'0&� �3 % 9�: &�!�# $ � , 3 &�)�2�<;�8 8�&�!�, 3 '03 = � , 3 &�)>'(+�2 ,�7�#�7�� 2 # "&�)>3 )�, # $ )�� 8� �� , �-$ # !�$ # 2 # )�, � , 3 &�)

?A@5B�C�D�E�F�G HI�J�K L M�N O P�K Q0L R S P�M>S M�T�U V�U M�T�U M�W U

XZY�[6\ ] ^ _ ` ]�\ a b"_ c6] d ` \�_ ]6Y�e f g h a i a hXZj.k h ] d l h a�m l ] d b"d n _ ] d m c.o d b"a c�\ d m c�\�p _ h q m ^ d ] r6b"s b"_ ] a ^ d _ h d n _ ] d m c�s t t t u

v<w-x y z {�| } ~(� ��x |�� "� � �"� � � �6� � �-� �6� � � �� "� � � � �5� � � �� 6� � � �6�6�� "� � � � � � � � � � � � � ��

�A�-�-�� ¡�¢ £ ¤ ¤ ¥.¤ ¦.§(¨�© ª"¤ ¦.£ «�¨�§(£ ¢ ¬ ¤ £

We have shown that there are considerable problems when attempting toprovide physical data independence with a media server (or MM-DBMS).Such systems tend to require frequent format conversions resulting in badperformance. They may inadvertently lose data due to irreversible updates.And hiding the internal data representation from the client obviously meansthat all the strongly necessary optimization is to be accomplished by theserver.

Our proposed media server concept is based on a generalization of dataindependence called transformation independence. This abstraction reducesthe creation, retrieval, and modification of media objects to what can becalled the “pure application semantics” . The consequence are multipleoptimization dimensions being left for exploitation at the server. TheVirtualMedia concept realizes transformation independence based on virtualmedia objects being described by filter graphs. With this concept,optimization can be basically characterized as the process of matchingtransformation request graphs and materialization graphs.

Since we are just at the beginning of developing these concepts, there arestill a lot of challenges to be mastered, like formalizing and evaluating thealgorithms and realizing the concept using available DBMS-technology andmedia server components.

18



QSRTRVU�WTXTY Z\[^]�_�`bacRTd Ufehg�UE`bi UEj^g�UEkVlTUEm�i

<?XML ver si on=” 1.0” st andal one=” yes” ?>

<VMDESC>

<SOURCE>

<MOM ALI AS=” Sound”

REF=” File://Client1/Media/sound.wav”

MAI NTYPE=” AUDIO” SUBTYPE=” WAVEFORM”

ENCODI NG=” WAV” >

<QUALITY>

<SAMPLING_FREQUENCY>44100

</ SAMPLING_FREQUENCY>

<SAMPLE_DEPTH>16</ SAMPLE_DEPTH>

<CHANNELS>Stereo</ CHANNELS>

</ QUALITY>

</ MOM>

<MOM ALI AS=” Clip1”

REF=” File://Client1/Media/clip1.avi”

MAI NTYPE=” VIDEO” SUBTYPE=” SINGLESTREAM”

ENCODI NG=” AVI/MJPEG” >

<QUALITY>

<IMAGE_WIDTH>704</ IMAGE_WIDTH>

<IMAGE_HEIGHT>480</ IMAGE_HEIGHT>

<FRAME_RATE>25</ FRAME_RATE>

</ QUALITY>

</ MOM>

<MOM ALI AS=” Clip2” . . . >. . . </ MOM>

<MOM ALI AS=” Clip3” . . . >. . . </ MOM>

</ SOURCE>

<VIRTUAL NAME=” BC_Video” MAI NTYPE=” VIDEO”

SUBTYPE=” MULTIPLESTREAM” >

<TRANSFORMATION>

<OPERATION NAME=” Assemble” >

<INPUT NAME=” Clip1” / >



<PARAM SEQUENCE=” Clip1, Clip2, Clip3” / >

<OUTPUT NAME=” Clip” / >

</ OPERATION>

<OPERATION NAME=” Compose” >

<INPUT NAME=” Sound” / >

<INPUT NAME=” Clip” / >

</ OPERATION>

</ TRANSFORMATION>

</ VIRTUAL>

</ VMDESC>

This is the transformation request (with some omissions) that would result inthe creation of the materialization graph shown on slide no. 10 (without thesecondary materialization).

improving the performance of media servers providing ...lgis.informatik.uni-kl.de/archiv/... ·...

Documents