J a v a Μ edia Fra.rr»w iork

ΤΕΙ ΚΑΒΑΛΑΣ ΣΧΟΛΗ ΔΙΟΙΚΗΣΗΣ ΚΑΙ ΟΙΚΟΝΟΜΙΑΣ ΤΜΗΜΑ ΔΙΑΧΕΙΡΙΣΗΣ ΠΛΗΡΟΦΟΡΙΩΝ ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ με θέμα: ΤΟ JAVA MEDIA FRAMEWORK ΓΙΑ ΕΦΑΡΜΟΓΕΣ ΕΠΕΞΕΡΓΑΣΙΑΣ ΣΥΝΕΧΩΝ ΜΕΣΩΝ J a v a Μ edia Fra.rr»w iork ΕΠΟΠΤΕΥΩΝ ΚΑΘΗΓΗΤΗΣ : ΣΤΕΡΓΙΟΣ ΠΑΠΑΔΗΜΗΤΡΙΟΥ ΟΝΟΜΑΤΕΠΩΝΥΜΟ ΦΟΙΤΗΤΡΙΑΣ: ΜΑΡΙΑ ΚΟΝΤΟΓΕΩΡΓΗ ΑΕΜ: 1109 Σεπτέμβριος 2011

ΠΙΝΑΚΑΣ ΠΕΡΙΕΧΟΜΕΝΩΝ Εισαγωγή... 4 1. Λεπτομερές Χρονικό Μοντέλο... 6 1.1 Χρόνος Χαμηλού επιπέδου: Κλάσεις Time και TimeBase...7 1.2 H Διασύνδεση Clock...9 1.3 Χρόνος Υψηλού Επιπέδου: Η Διασύνδεση Controller... 12 1.4 Χρονισμός ενός Player... 17 2. Έλεγχος και Αλυσίδες Επεξεργασίας... 20 3. Διαχείριση Πολυπλοκότητας...22 3.1 Η Κλάση του Manager... 24 3.1.1 Δημιουργία ενός Player...25 3.1.2 Δημιουργία ενός Processor... 27 3.1.3 Δημιουργία μιας DataSource...29 3.1.4 Δημιουργία ενός DataSink... 31 3.2 Ερωτήματα/Αιτήματα στον Manager... 32 4. Τα περί Ελέγχου... 41 4.1 Οπτικός Έλεγχος για τον Χρήστη... 45 4.2 Λήψη Αντικειμένων Control... 46 5. Προέλευση Μέσων και Μορφή Μέσων...49 5.1 DataSource... 50 5.2 Κλωνοποιήσιμες και Συγχωνευμένες DataSources...53 5.3 MediaLocator...54 5.4 SourceStream και Buffer...55 5.5 Μορφή (Format)... 56 6. MediaHandler...59 7. Aναπαραγωγή Μέσων... 60 2

7.1 Διασύνδεση Player...60 7.2 MediaPlayer Bean...65 8. Έλεγχος πολλαπλών Players/Controllers... 65 9. Εφαρμογή: Player των Μέσων... 66 10. Αναπαραγωγή των Μέσων με έναν Processor... 79 11. Διατήρηση Μ έσω ν...80 11.1 DataSink... 81 11.1.1 Συμβάντα του DataSink...83 11.2 Plugins... 84 11.2.1 PluginManager...86 11.2.2 Αποπολυπλέκτης (Demultiplexer)...88 11.2.3 Κωδικοαποκωδικοποιητής (Codec)...89 11.2.4. Εφέ (Effect)... 90 11.2.5 Πρόγραμμα Απόδοσης (Renderer)...90 11.2.6 Πολυπλέκτης (Multiplexer)...91...91 12. Επεξεργασία Μ έσω ν... 92 12.1 Χρονική κλίμακα του Processor (Timescale)...93 12.2 Διασύνδεση Processor... 96 12.3 Δημιουργία και Προγραμματισμός των Processors... 100 12.3.1 ProcessorModel...103 12.3.2 TrackControl... 106 12.4 Κλάση Βοηθητικού προγράμματος: ΜediaStatistics... 110 12.5 Κλάση Βοηθητικού προγράμματος: Location2Location...123 13. Αποτύπωση των μέσων...138 13.1 JMFRegistry και JMStudio... 139 13.2 CaptureDeviceManager...140 3

13.3 ΟΒρΙϋΓθϋθνϊοθίηΙο...142 13.4 ΟΒρΙϋΓθϋβνϊοβ... 143 13.5 Αποτύπωση Ήχου ή Εικόνας με την εφαρμογή SimpleRecorder... 143 Επίλογος... 152 ΒΙΒΛΙΟΓΡΑΦΙΑ... 154 Εισαγωγή Η παρούσα εργασία περιγράφει τον έλεγχο των μέσων βάσει χρόνου (timebased media) με την Διασύνδεση Προγραμματισμού Εφαρμογών (API) του JMF (Java Media Framework). Στο πλαίσιο αυτής της εργασίας, ο έλεγχος χρησιμοποιείται με την ευρύτερη έννοια για να καλύψει όλες τις ενέργειες που αφορούν τα time-based media. Αυτός ο περιεκτικός ορισμός περιλαμβάνει αυτό που θεωρείται γενικότερα επεξεργασία: αποκωδικοποίηση, κωδικοποίηση, διακωδικοποίηση (αποκωδικοποίηση από τη μία μορφή και κωδικοποίησή της στην άλλη), εφέ, φίλτρα, πολυπλεξία, και αποπολυπλεξία, καθώς και πηγή δεδομένων αυτών καθαυτών: αποτύπωση, ανάγνωση από το αρχείο, και έξοδο (παρουσίαση ή αποθήκευση). Στην πραγματικότητα, η θεμελιώδης προσέγγιση για τον έλεγχο μπορεί να περιγραφεί με τα εξής τρία βήματα: 1. Προέλευση μέσων (Source media) 2. Επεξεργασία μέσων (Process media) 3. Έξοδος μέσων (Output media) Το Σχήμα 1 παρουσιάζει αυτά τα τρία βήματα ελέγχου 4

Σχήμα 1 Τρία βήματα του ελέγχου των μέσων με το JMF. Αυτός ο έλεγχος μπορεί να είναι αλυσιδωτός: Η έξοδος ενός σταδίου ελέγχου μπορεί να λειτουργήσει ως είσοδο για ένα άλλο. Για παράδειγμα, ένα τμήμα ελέγχου μπορεί να διασφαλίσει μια ταινία που «ρέει» στο Διαδίκτυο και να την αποπολυπλέξει σε διαφορετικά tracks ήχου και εικόνας που αποθηκεύονται σε διαφορετικά αρχεία. Μια δεύτερη υπομονάδα ελέγχου μπορεί τότε να πάρει τα δεδομένα εξόδου ήχου και να προσθέσει εφέ αντήχησης (reverb effect) σε ένα τμήμα πριν το πολυπλέξει με το track εικόνας και να αποθηκεύσει την ταινία που θα προκύψει. Το Βήμα 2, η επεξεργασία μπορεί να εμπεριέχει πολυβαθμιδωτή ενέργεια, που ίσως περιλαμβάνει εφέ (effects), κωδικοαποκωδικοποιητές (codecs), πολυπλέκτες (multiplexers) και αποπολυπλέκτες (demultiplexers). Το Σχήμα 2 αποτελεί ένα σχηματικό διάγραμμα που δείχνει την πολυβαθμιδωτή επεξεργασία και την αλυσίδα ελέγχου. Η παρούσα εργασία κατηγοριοποιείται σε τρία μεγάλα τμήματα, καθένα εκ των οποίων αποτελείται από τις ακόλουθες ενότητες: Κύρια βήματα και κλάσεις με ρόλους στην αλυσίδα ελέγχου Επεξεργασία Αποτύπωση μέσων 5

Σχήμα 2 Αλυσίδα επεξεργασίας μέσων Το πρώτο τμήμα αποτελεί ένα φάσμα θεμάτων που καλύπτουν την προσέγγιση που χρησιμοποιείται από το JMF στην επίτευξη ελέγχου στα μέσα και αποτελεί μια απαραίτητη εισαγωγή στις λεπτομέρειες των τελευταίων ενοτήτων. Πιο συγκεκριμένα, συμπεριλαμβάνει μια πιο λεπτομερή περιγραφή του χρονικού μοντέλου του JMF και μια εισαγωγή στις βασικές κλάσεις του manager, καθώς και αναλύσεις για τους Ελέγχους (Controls), τις Πηγές δεδομένων (DataSources) και τα Δοχεία Δεδομένων (DataSinks). Το δεύτερο τμήμα αφορά την επεξεργασία και ξεκινάει με την εξέταση της διεύρυνσης κλάσεων διακοπής χρόνου που το JMF χρησιμοποιεί για την επεξεργασία. Κατόπιν, τα θέματα των προηγούμενων ενοτήτων περιγράφονται με διάφορα παραδείγματα επεξεργασίας (όπως η διακωδικοποίηση). Το τελευταίο τμήμα καλύπτει το θέμα της αποτύπωσης μέσων, λαμβάνοντας δείγματα ήχου ή εικόνας άμεσα από τις συσκευές που είναι συνδεδεμένες με τον υπολογιστή. 6

1. Λεπτομερές Χρονικό Μοντέλο Το JMF χρησιμοποιεί μια στρωματοποιημένη προσέγγιση κατά την αναπαράσταση του χρόνου του. Στους χαμηλού επιπέδου τερματικούς του χρονικού μοντέλου βρίσκονται οι κλάσεις για την αναπαράσταση χρόνου με ακρίβεια νανοδευτερολέπτων. Στους υψηλού επιπέδου τερματικούς του μοντέλου, το JMF αντιμετωπίζει τους controllers ως ένα ενιαίο σύνολο καταστάσεων που μεταβαίνουν από την μια στην άλλη υπό τον έλεγχο του προγράμματος. 1.1 Χρόνος Χαμηλού επιπέδου: Κλάσεις Time και TimeBase Οι δυο κλάσεις, η Time και η SystemTimeBase, και μια διασύνδεση, η TimeBase, περιγράφουν λεπτομερώς το χαμηλού επιπέδου χρονικό μοντέλο του JMF. Στα χαμηλά στρώματα της ιεραρχίας και ίσως η πιο θεμελιώδης είναι η κλάση του Time. Το αντικείμενο Time αναπαριστά μια συγκεκριμένη στιγμή στο χρόνο με ακρίβεια ενός νανοδευτερολέπτου. Το Σχήμα 3 απεικονίζει τους κατασκευαστές (constructors) της κλάσης του Time και τις δημόσιες (public) μεθόδους. Time Class Tim e(double seconds) Time(long nanoseconds) tong getnanoseconds() double getsecondsq Σχήμα 3 Η κλάση του Time Τα αντικείμενα Time συνήθως επιστρέφονται από μεθόδους που χρησιμοποιούνται για να υποβάλλουν ερωτήματα για την προσωρινή 7

κατάσταση άλλου αντικειμένου. Για παράδειγμα, το ποσοστό του συνολικού χρόνου αναπαραγωγής σε μερικά μέσα. Ομοίως, τα αντικείμενα Time μπορούν να χρησιμοποιηθούν για να μεταβάλλουν τις προσωρινές ιδιότητες ενός αντικειμένου. Για παράδειγμα, για τον προσδιορισμό μιας συγκεκριμένης χρονικής στιγμής από την οποία ξεκινάει η αναπαραγωγή μέσων, το αντικείμενου του Time μπορεί να χρησιμοποιηθεί ως εξής: 1. Να κατασκευάσει ένα αντικείμενο Time με μια τιμή, ρυθμισμένο σε δευτερόλεπτα ή νανοδευτερόλεπτα, ως αντιστάθμισμα από την έναρξη αναπαραγωγής των μέσων κατά την οποία θα έπρεπε να ξεκινήσει η αναπαραγωγή. 2. Να περάσει αυτό το αντικείμενο από την μέθοδο setmediatime ( ) του αντικειμένου Player. H κλάση του Time διαθέτει επίσης μια ειδική σταθερά, την TIME_UNKNOWN. Αυτή η σταθερά βρίσκει εφαρμογές σε πλαίσια κατά τα οποία ένα αντικείμενο μπορεί να ερωτηθεί για την διάρκεια των μέσων με τα οποία συνδέεται, αλλά το μήκος του δεν έχει ή δεν μπορεί να διαπιστωθεί. Η κλάση του Time καθορίζει μια μεμονωμένη στιγμή στον χρόνο, ενώ τα μέσα βάσει χρόνου, από τη φύση τους, είναι πιο δυναμικά και ποικίλλουν σε χρόνο. Η υποστήριξη του JMF για τον κτύπο (1 νανοδευτερόλεπτο ανά κτύπο) του χρόνου βρίσκεται υπό την μορφή της διασύνδεσης TimeBase. Η διασύνδεση TimeBase είναι σημαντική και η μόνη που εφαρμόζεται από διάφορες σημαντικές κλάσεις. (Πιο συγκεκριμένα, υπάγεται σε άλλες βασικές διασυνδέσεις όπως στις Controller και Player, που επεκτείνουν τη διασύνδεση.) Η διασύνδεση TimeBase καθορίζει μόνο δυο μεθόδους, που και οι δύο χρησιμοποιούνται για να υποβάλλουν ερωτήματα για τον τρέχοντα χρόνο του αντικειμένου TimeBase. Η μέθοδος gettime ( ) επιστρέφει ένα αντικείμενο Time. Ένα εναλλακτικό μέσο λήψης των ίδιων πληροφοριών είναι η μέθοδος getnanoseconds ( ), που επιστρέφει ένα αντικείμενο μεγάλου μεγέθους (long object). Δεν υπάρχει κάποια διάταξη σ TimeBase για την 8

μεταβολή του χρόνου. Μπορεί να ερωτηθεί μόνο σχετικά με την τρέχουσα κατάστασή του. Ως προεπιλεγμένη εφαρμογή της διασύνδεσης TimeBase, το JMF παρέχει την κλάση SystemTimeBase. Η SystemTimeBase έχει έναν μοναδικό κενό κατασκευαστή και μόνο δυο μεθόδους που έχουν καθοριστεί στη διασύνδεση TimeBase. Εναλλακτικά, η χρονοβάση του συστήματος (system time base) μπορεί να ληφθεί μέσω της μεθόδου getsystemtimebase ( ) της κλάσης του Manager. 1.2 H Διασύνδεση Clock Αυτές οι κλάσεις που εφαρμόζουν την διασύνδεση TimeBase παρέχουν διαρκείς κτύπους, μη μεταβαλλόμενη πηγή χρόνου. Ωστόσο, ο έλεγχος των μέσων σημαίνει την παροχή ελέγχου σε προσωρινές ιδιότητες αυτών των μέσων: ικανότητα εκκίνησης ή διακοπής των μέσων σε τυχαίες θέσεις καθώς και έλεγχο του ρυθμού τους (για παράδειγμα, γρήγορο προχώρημα ή ανάγνωση προς τα πίσω/γρήγορη επιστροφή σε έναν player). Η διασύνδεση Clock αποτελεί το μέσο με το οποίο επιτυγχάνεται αυτό, και εφαρμόζεται από αντικείμενα που υποστηρίζουν το χρονικό μοντέλο του JMF. Με πολλούς τρόπους, η διασύνδεση Clock είναι ζωτικής σημασίας τόσο ως σύνδεσμος μεταξύ των χρονικών μοντέλων χαμηλού και υψηλού επιπέδου όσο και ως βασική διασύνδεση της Διασύνδεσης Προγραμματισμού Εφαρμογών (API). Οι διασυνδέσεις Controller, Player και Processor, όλες οι κεντρικές ως προς την λειτουργικότητα του JMF, επεκτείνουν το Clock. Τα Clocks είναι τυπικά συνδεδεμένα με ένα αντικείμενο μέσων (media object). Πράγματι, ο έλεγχος στα μέσα όπως η αναπαραγωγή ή η επεξεργασία συνεπάγεται την σύνδεση του Clock με αυτό το μέσο. (Επειδή οι διασυνδέσεις Controller, Player και Processor επεκτείνουν το Clock, το αντικείμενο Player ή Processor είναι επίσης ένα ρολόι (clock)). Ένα Clock χρησιμεύει τόσο ως χρονόμετρο για το μέσο του όσο και ως μέσο μεταβολής και προσαρμογής του 9

χρόνου αυτού του μέσου. Ο χρόνος που κρατάει ένα ρολόι (clock) είναι γνωστός και ως χρόνος των μέσων (media time). Τα clocks επιτυγχάνουν δυο εργασίες, την παρακολούθηση και την μεταβολή της ροής του χρόνου των συνδεδεμένων τους μέσων χρησιμοποιώντας ένα TimeBase. Όπως αναφέρθηκε, τα αντικείμενα TimeBase αντιπροσωπεύουν συνεχείς κτύπους και μη μεταβαλλόμενο χρόνο. Επομένως, το Clock παρέχει αναχαρτογράφηση ή μετατροπή από τον χρόνο του TimeBase με αυτόν που συνδέεται με τα μέσα. Αυτό είναι μια απλή γραμμική μετατροπή που απαιτεί τρεις παραμέτρους: το ρυθμό (για παράδειγμα της αναπαραγωγής), τον χρόνο έναρξης των μέσων, και τον χρόνο έναρξης της χρονοβάσης. Βάσει των παραπάνω, ο χρόνος των μέσων μπορεί να προσδιοριστεί ως εξής: media_time = media_start_time + rate x (time_base_time L- time_base_start_time) Οι σημασίες των προηγούμενων όρων είναι ως εξής: Χρόνος των μέσων (Media time)- Η θέση των μέσων στον χρόνο. Για παράδειγμα, εάν ένα ηχητικό μήνυμα ήταν διάρκειας ενός λεπτού, ο χρόνος των μέσων θα κυμαινόταν από 0 έως 60 δευτερόλεπτα. Χρόνος έναρξης των μέσων (Media start tim e)-^ αντιστάθμισμα εντός των μέσων από το οποίο θα ξεκινήσει η αναπαραγωγή. Εάν η αναπαραγωγή ξεκινήσει από την έναρξη των μέσων, αυτή η τιμή είναι 0. Εάν ξεκινήσει στα 7,5 δευτερόλεπτα, αυτή η τιμή θα είναι 7,5. Ρυθμός (Rate)- Ο ρυθμός της παρέλευσης του χρόνου για τα μέσα. Ο ρυθμός για το 1 αντιπροσωπεύει μια φυσιολογική περιέλιξη προς τα εμπρός (για παράδειγμα, αναπαραγωγή), ενώ η τιμή -5 θα αντιπροσωπεύσει γρήγορη επαναληπτική περιέλιξη. Χρόνος Χρονοβάσης (Time base time)- Ο χρόνος του αντικειμένου TimeBase που το Clock περιλαμβάνει. Αυτό ξεκινάει τους 10

κτύπους (αύξηση) μόλις το αντικείμενο Clock δημιουργηθεί και δεν σταματάει ποτέ να λειτουργεί. Χρόνος έναρξης της Χρονοβάσης (Time base start time)- Ο χρόνος του αντικειμένου TimeBase κατά τον οποίο το Clock ξεκινάει και συγχρονίζεται με την TimeBase. Για παράδειγμα το Clock μπορεί να ξεκινήσει 3,2 δευτερόλεπτα μετά τη δημιουργία του Clock (και επομένως η TimeBase δημιουργήθηκε επίσης και άρχισε να κτυπάει). Έτσι, αυτός ο χρόνος έναρξης της χρονοβάσης θα είναι 3,2 δευτερόλεπτα. Το Clock μπορεί να βρίσκεται σε δυο πιθανές καταστάσεις: Started ή Stopped. Ένα clock ξεκινάει καλώντας την μέθοδο syncstart ( ). Αυτή η μέθοδος SyncStart ( ) δέχεται ένα μόνο όρισμα ως χρόνο έναρξης της χρονοβάσης από την οποία το Clock πρέπει να ξεκινήσει. Μόλις το αντικείμενο TimeBase του Clock επιτύχει αυτόν τον χρόνο, το ρολόι (clock) θα συγχρονιστεί με την TimeBase και θα μεταβεί σε κατάσταση Started. Αυτός ο μηχανισμός επιτρέπει στο Clock να ρυθμιστεί για την έναρξη σε κάποιο μελλοντικό χρόνο (ή σε τρέχοντα χρόνο περνώντας την μέθοδο syncstart ( ) στον τρέχοντα χρόνο του αντικειμένου TimeBase του Clock). Οποιεσδήποτε αλλαγές στον χρόνο (έναρξης) των μέσων και στο ρυθμό πρέπει να διεξαχθούν πριν την εισαγωγή του Clock σε κατάσταση Started. Προσπαθώντας να χρησιμοποιήσουμε αυτές τις μεθόδους που διεξάγουν αυτές τις λειτουργίες σε ένα Clock σε κατάσταση Started, αυτό θα έχει ως αποτέλεσμα να εμφανιστεί η ένδειξη ClockStartedError. Επομένως, τα συνήθη βήματα που ακολουθούνται για την έναρξη ενός ρολογιού (clock) είναι τα εξής: 1. Διακοπή του ρολογιού (clock) εάν έχει μόλις ξεκινήσει 2. Ρύθμιση του χρόνου (έναρξης) των μέσων του Clock 3. Ρύθμιση του ρυθμού του Clock. 4. syncstart ( ) το Clock Η αρχική κατάσταση του Clock είναι Stopped. Αφότου το clock βρίσκεται σε κατάσταση Started, μπορεί να σταματήσει με έναν εκ των δύο τρόπων. Μπορεί είτε να σταματήσει αμέσως με την μέθοδο stop ( ), ή μπορεί να ρυθμιστεί ο 11

χρόνος διακοπής των μέσων (media stop time). Μόλις ο χρόνος των μέσων επιτύχει (εάν έχει ήδη υπερβεί) αυτόν τον χρόνο, το Clock θα αρχίσει να σταματάει. Τέλος αξίζει να σημειωθεί ότι είναι πιθανό να συγχρονιστούν δυο ή περισσότερα Clocks ρυθμίζοντάς τα να χρησιμοποιούν το ίδιο αντικείμενο TimeBase. Η διασύνδεση Clock παρουσιάζει μεθόδους για την λήψη και τη ρύθμιση του αντικειμένου TimeBase που συνδέεται με το Clock. Το Σχήμα 4 παρουσιάζει όλες τις μεθόδους της διασύνδεσης του Clock. Εκτός των άλλων που έχουν ειπωθεί, οι μέθοδοι που χρησιμοποιούνται συχνά είναι οι εξής: getmediatime ( ) και getmediananoseconds ( ). Για παράδειγμα, αυτές μπορούν να κληθούν επανειλημμένως ως μέσα που αναπαράγονται για να παρέχουν κάποια ανάδραση σε παρερχόμενο χρόνο για τον viewer. Ομοίως, οι setrate ( ) και setmediatime ( ) χρησιμοποιούνται για να παρέχουν έλεγχο στον χρήστη κατά τα σενάρια αναπαραγωγής (playback), αλλά μπορούν μόνο να κληθούν όταν το ρολόι (clock) είναι σταματημένο. C lo c k Interface long getmediananosecondso Tim e getm ediatim e() float getrateq Tim e getstoptim a() Time getsynchtime() TimeBase gettimebase() Tim e maptotimebase(tim e t) void setm ediatim e(tim e now) float setrateffloat factor) void setstoptime(time stoptime) void stopq Void synchstart(time at) Σχήμα 4 Η διασύνδεση Clock. 1.3 Χρόνος Υψηλού Επιπέδου: Η Διασύνδεση Controller H διασύνδεση Controller επεκτείνει άμεσα το Clock σε τρία πεδία: 12

Διευρύνει την έννοια του Stopped σε έναν αριθμό καταστάσεων που αφορούν την κατανομή των πόρων, έτσι ώστε να καταστεί καλύτερη η παρακολούθηση και ο έλεγχος της χρονοβόρας διαδικασίας. Παρέχει έναν μηχανισμό συμβάντος βάσει του οποίου μπορεί να διεξαχθεί η παρακολούθηση των καταστάσεων. Παρέχει έναν μηχανισμό βάσει του οποίου μπορούν να ληφθούν τα αντικείμενα που παρέχουν περαιτέρω έλεγχο στον controller. Στην κορυφή της διασύνδεσης βρίσκεται ο ευρέως χρησιμοποιούμενος Player- και οι διασυνδέσεις του Processor. Η επίτευξη μιας κατάστασης όπου ο έλεγχος, η επεξεργασία ή η αναπαραγωγή των μέσων μπορεί να ξεκινήσει, δεν αποτελεί μια στιγμιαία λειτουργία. Οι πόροι πρέπει να συγκεντρωθούν για να υποστηρίξουν αυτόν τον έλεγχο. Οι εργασίες που συμπεριελήφθησαν στην συγκέντρωση των πόρων περιλαμβάνουν το άνοιγμα αρχείων για ανάγνωση, φόρτωση ενδιάμεσης μνήμης, ή απόκτηση αποκλειστικού ελέγχου των συσκευών υλικού (π.χ. αποκωδικοποιητής υλικού). Αυτό το σημείο περιγράφεται στην επόμενη υποενότητα στην οποία ο χρόνος έχει ληφθεί για να συγκεντρώσει πόρους έτσι ώστε να μπορέσει να εμφανιστεί η αναπαραγωγή ενός βίντεο. Η διασύνδεση Controller υποδιαιρείται σε κατηγορία Stopped του Clock σε πέντε στάδια που αντανακλούν την κατάσταση ετοιμότητας του Controller: πόσο κοντά βρίσκεται στο να μπορέσει να ξεκινήσει. Αυτές οι πέντε καταστάσεις, προκειμένου να ξεκινήσει η λιγότερο έτοιμη (least prepared) έως την έτοιμη (prepared), είναι οι εξής: -Unrealized- Έχει δημιουργηθεί ένας Controller αλλά δεν έχει αναλάβει την συγκέντρωση πόρων. -Realizing- Μια κατάσταση μετάβασης που αντικατοπτρίζει το γεγονός ότι ο Controller συγκεντρώνει πληροφορίες σχετικά με τους πόρους που χρειάζονται για την εργασία του, καθώς και τη συγκέντρωση αυτών καθαυτών των πόρων. 13

-Realized- Μια σταθερή κατάσταση που αντικατοπτρίζει ένας Controller που έχει συγκεντρώσει όλους τους μη αποκλειστικούς πόρους που χρειάζονται για μια εργασία. -Prefetching- Κατάσταση μετάβασης που αντικατοπτρίζει το γεγονός ότι ο Controller συγκεντρώνει όλους τους πόρους που απαιτούνται για την εργασία του, που δεν ελήφθησαν σε κατάσταση realizing. Τυπικά αυτό σημαίνει την απόκτηση αποκλειστικής χρήσης των πόρων όπως το υλικό. -Prefetched- Ο Controller έχει αποκτήσει όλους τους απαραίτητους πόρους, έχει διεξάγει όλη την επεξεργασία προεκκίνησης (pre-startup processing), και είναι έτοιμος να ξεκινήσει. Η διασύνδεση Controller παρέχει έλεγχο προγράμματος για την κίνηση μεταξύ αυτών των καταστάσεων μέσω μιας σειράς μεθόδων. Ομοίως, η διασύνδεση Controller επιτρέπει την παρακολούθηση αυτών των μεταβάσεων στο πρόγραμμα μέσω ενός συστήματος συμβάντων. Τα αντικείμενα μπορούν να εφαρμόσουν την διασύνδεση ControllerListener και επομένως να αποσταλούν συμβάντα όπως οι μεταβάσεις του Controller μεταξύ διάφορων καταστάσεων. Το Σχήμα 5 παρουσιάζει τις μεθόδους και τις συνδεδεμένες μεταβάσεις μεταξύ των καταστάσεων. Το Σχήμα 6 παρουσιάζει τα συμβάντα που δημιουργούνται κατά τις μεταβάσεις του Controller μεταξύ των καταστάσεών του. Σχήμα 5 Μέθοδοι Controller που προκαλούν μεταβάσεις καταστάσεων 14

Σχήμα 6 Συμβάντα που δημιουργούνται κατά τις μεταβάσεις ενός ^ η ϋ ο! ^ μεταξύ των καταστάσεων Όπως φαίνεται στο Σχήμα 5, ένας Controller έχει πέντε μεθόδους για τον έλεγχο της μετάβασης μεταξύ των καταστάσεων. Οι μέθοδοι κίνησης προς τα εμπρός είναι οι εξής: realize ( ), prefetch ( ), και syncstart ( ) (από την διασύνδεση Clock), για την μετακίνηση του Controller σε κατάσταση πιο έτοιμη (more prepared) και εν τέλει σε κατάσταση Started. Είναι ασύγχρονες - επιστρέφουν αμέσως, αλλά η παραγόμενη ενέργεια γενικά χρειάζεται κάποιο χρόνο για να ολοκληρωθεί. Όταν η μετάβαση ολοκληρωθεί (ή διακοπεί από μια κλήση stop ( ) ή άλλη τέτοια κλήση), αναρτάται ένα συμβάν. Οι μέθοδοι αντίστροφης κατεύθυνσης είναι οι stop ( ) και deallocate ( ). Αυτές αποτελούν τις σύγχρονες μεθόδους. Η stop ( ) χρησιμοποιείται για να διακόψει έναν Controller που έχει ξεκινήσει Οι μεταβάσεις του Controller σε κατάσταση Prefetched (ή σε μερικές περιπτώσεις όπου οι πόροι πρέπει να εκχωρηθούν: Realized) και ενδέχεται στη συνέχεια να κάνει επανεκκίνηση. Η deallocate ( ) απελευθερώνει τους πόρους που έχουν καταναλωθεί από έναν Controller και πρέπει να χρησιμοποιηθούν για αυτό το σκοπό (για παράδειγμα, σε μια μέθοδο stop ( ) μιας μικροεφαρμογής (applet)). Η deallocate ( ) δεν μπορεί να κληθεί σε έναν Started Controller, διότι πρέπει να προηγηθεί διακοπή. H deallocate ( ) επιστρέφει έναν Controller σε κατάσταση Realized εάν βρίσκεται σε αυτήν την κατάσταση ή καλύτερα (σε μια κατάσταση παρόμοια με Started), διαφορετικά ο Controller επιστρέφει σε κατάσταση Unrealized. 15

Ένας Controller αναρτά συμβάντα σχετικά με τις αλλαγές της κατάστασής του. Αυτά τα αντικείμενα, καθώς επιθυμούν να ενημερωθούν για τα συμβάντα του Controller πρέπει να εφαρμόσουν την διασύνδεση ControllerListener. Η διασύνδεση ControllerListener αποτελείται από μια μεμονωμένη μέθοδο, την public synchronized void controllerupdate (ControllerEvent e) Τα αντικείμενα κοινοποιούν την επιθυμία τους να τους αποσταλούν τα συμβάντα Controlleris, καλώντας την μέθοδο Controlleris addcontrollerlistener ( ). Τα συμβάντα που αναρτώνται από έναν Controller εμπίπτουν σε μια εκ των τεσσάρων κατηγοριών: Μεταβάσεις κύκλου ζωής Αναγνώριση μεθόδου Πληροφορίες αλλαγής κατάστασης Ειδοποίηση σφάλματος Η TransitionEvent ή μια υποκλάση όπως η EndOfMediaEvent, αποτελεί μέσο αναφοράς αλλαγής κατάστασης του Controller. Τα συμβάντα αναγνώρισης μεθόδων RealizeCompleteEvent, PrefetchCompleteEvent, StartEvent, DeallocateEvent, και StopByRequestEvent χρησιμοποιούνται για να συνδέσουν την εκπλήρωση των αντίστοιχων μεθόδων- για παράδειγμα, η realize ( ) - που κάλεσαν τον Controller. Υπάρχουν τρία συμβάντα αλλαγής κατάστασης: RateChangeEvent, StopTimeChangeEvent, και MediaTimeSetEvent που ενημερώνουν τον listener για τις αλλαγές στο ρυθμό, την διακοπή του χρόνου, και όταν ένας νέος χρόνος των μέσων έχει ρυθμιστεί. Τα σφάλματα εμπίπτουν στην κλάση ControllerErrorEvent και συμπεριλαμβάνουν τα εξής: ResourceUnavailableEvent, DataLostErrorEvent και InternalErrorEvent. Άλλα σφάλματα εμφανίζονται ως εξαιρέσεις. Για παράδειγμα, στην προσπάθεια να syncstart έναν Controller πριν επιτύχει την κατάσταση Prefetched, θα έχει ως αποτέλεσμα να εμφανιστεί ένα NotPrefetchedError. 16

Το Σχήμα 7 παρουσιάζει όλες τις μεθόδους και τις σταθερές του Controller που δεν κληρονομούνται από τις διασυνδέσεις Clock ή Duration. Ανάμεσα στις σημαντικές μεθόδους της διασύνδεσης που δεν έχουν ειπωθεί προηγουμένως υπάγονται οι μέθοδοι close ( ), getstartlatency ( ), getcontrol ( ), και η getcontrols ( ). Close ( ) χρησιμοποιείται για να απελευθερώσει όλους τους πόρους και διακόπτει όλες τις δραστηριότητες που συνδέονται με έναν Controller. Ο Controller δεν μπορεί πλέον να χρησιμοποιηθεί (καλούνται οι μέθοδοί του) αφότου έχει κλείσει. Η μέθοδος getstartlatency ( ) επιστρέφει μια εκτίμηση του χρονικού περιθωρίου που απαιτείται στην χειρότερη περίπτωση πριν την παρουσίαση του πρώτου πλαισίου δεδομένων. Χρησιμοποιείται για να παρέχει μια εκτίμηση για τις κλήσεις του syncstart ( ). Η εκτίμηση είναι πιο ακριβής εάν ο Controller βρίσκεται σε κατάσταση Prefetched. Οι μέθοδοι getcontrol ( ) και getcontrols ( ) παρέχουν ένα μέσο για την απόκτηση των αντικειμένων Control. Αυτές μπορούν να χρησιμοποιηθούν για να μεταβάλλουν την συμπεριφορά του Controller. Οι Controls και Controllers αποτελούν δυο διαφορετικά πράγματα παρά την ατυχή ομοιότητα τους στο όνομά τους. Οι Controls θα περιγραφούν αναλυτικότερα σε επόμενη ενότητα. Time LATENCY^UNKNOWN Int Unrealized Int Realizing Ini Realized int Preteicing Int Prefetched int Started Controller Interface Void addcontrollerlistener(controllerlistener listener) void close)) void deallocate)) Control getcontro!(string aspect2control) Control)) getcontrols)); Tim e getstartlatency)) int getstate)) int gettargetstate)) void prefetch)) void realize)) void removecontrollerlistener)controllerlistener listener) Σχήμα 7 Η διασύνδεση Controller 1.4 Χρονισμός ενός Player 17

Για να περιγράψουμε τις έννοιες που καλύπτονται σε αυτήν την ενότητα και την διασύνδεση μεταξύ υψηλού και χαμηλού επιπέδου χρονικών μοντέλων που υποστηρίζει το JMF, η απλή μικροεφαρμογή του player BBPApplet τροποποιήθηκε ελαφρώς. Η τροποποίηση αποτελείται από την χρονοσήμανση και την εκτύπωση κάθε συμβάντος του Controller που έχει ληφθεί από την μικροεφαρμογή. Αυτό παρέχει μια απεικόνιση της χρονικής πορείας του player από τη στιγμή που ξεκίνησε η αναπαραγωγή μέχρι τον χρόνο που σταμάτησε η αναπαραγωγή του μέσου (mpeg video). Η τροποποίηση αυτή καθεαυτή είναι απλή, και από το να αναπαραχθεί ξανά ο κώδικας ολόκληρης της μικροεφαρμογής, θα αναλυθούν μόνο οι αλλαγές που διεξήχθησαν. Ένα αντικείμενο SystemTimeBase κατασκευάστηκε αμέσως πριν την εκκίνηση του Player. Κάθε φορά που εισαγόταν η μέθοδος controllerupdate ( ), στο αντικείμενο SystemTimeBase υποβάλλονταν ερωτήματα ως προς τον χρόνο, και αυτή η τιμή καθώς και το συμβάν που ελήφθη εμφανίζονταν στην οθόνη. Τα τρία βήματα ήταν τα εξής: 1. Όπου δηλώνονται άλλα χαρακτηριστικά όπως ο Player, δηλώνουν και επιπλέον χαρακτηριστικό -ένα αντικείμενο τύπου SystemTimeBase. // The object to be used to timestamp Controller events, protected SystemTimeBase timer; 2. Αμέσως πριν την ασύγχρονη κλήση του player.start ( ), δημιουργείστε ένα αντικείμενο SystemTimeBase στην μέθοδο init ( ). Από την στιγμιαία περιέλιξη προς τα εμπρός, ο timer θα συνεχίσει να κτυπάει με (ενδεχομένως) ακρίβεια νανοδευτερολέπτων. timer = new SystemTimeBase(); p l a y e r. s t a r t ( ) ; 3. Στην μέθοδο controllerupdate, υποβλήθηκε αμέσως ερώτημα σ αντικείμενο timer ως προς τον χρόνο του, και το εκτύπωσε (αφού μετατράπηκε σε δευτερόλεπτα) και το συμβάν που ελήφθη. // Print the time the event was received, together with the event, 18

// to the screen. System.out.printIn(MM+(double)timer.getNanosecondsQ/Time.0NE_ S E ^ N D + : + e ) ; Η έξοδος των δεδομένων χρονισμού όταν η μικροεφαρμογή που αναπαρήγαγε ένα mpeg video διάρκειας περίπου άνω των δυο λεπτών περιγράφεται στη Λίστα 1. Κάθε συμβάν του Controller που έχει ληφθεί από μια κλάση (που δημιουργείται από έναν Player) έχει χρονοσφραγίδα και έχει παραχθεί. Τα συμβάντα συμβαίνουν σε χρονολογική σειρά με μια χρονοσφραγίδα (timestamp) (σε δευτερόλεπτα), όντας το πρώτο τμήμα πληροφοριών στην γραμμή, που ακολουθείται από το συμβάν αυτό καθεαυτό. Το Σχήμα 8 παρουσιάζει τις μεταβάσεις των καταστάσεων μέσα στο χρόνο, λαμβάνοντας τις πιο σημαντικές πληροφορίες. Realizing Prefetching... 0.00 0.0 6 1.60 -> 1.Θ7 2.59 160.06 Timer object Informed that Told about Realize Prefetch Created. Player is in process length of completed, completed of transition to video. and playback started state. started. Video finished playing. Σχήμα 8 Χρονοδιάγραμμα για τα συμβάντα που λαμβάνει ένας Player κατά την παρουσίαση ενός video Λίστα 1 Χρονισμός εξόδου πληροφοριών από την τροποποιημένη BBPApplet (Bare Bones Player Applet) 19

0.06: javax.media.transitionevent! source=com.sun.media.content.video.mpeg,handle r@275d39,previous=unrealized,current=realizing,target=started ] 1.6: javax.media. DurationL?pdateEvent[source=com.sun.media. content, video, mpeg.handler@275d39,duration^ avax.media.time@l0f e2b 1.87: javax.media.realizecompleteevent[source=com.sun.media.content.video.mpeg.h andler@275d39,previous=realizing,current=realized,target=started] 2.59: javax.media.transitionevent[source=com.sun.media.content.video.mpeg.handle r@275d39,previous*realized,current=preietching,target=started ] 2.59: javax.media.pref etchcompleteevent [source=com.sun.media.content.video.mpeg. Handler@275d39, previous=prefetching,current Pref etched, target=started j 2.59: javax.media.startevent[source=com.sun.media.content.video.mpeg.handler@275 d39,previous=prefetched,current=started,target=started,mediatime=javax.media.tim e@36e39f,timebasetime=javax.media.time@19dc16 i 160.06: javax.media.endofmediaevent[source=com.sun.media.content.video.mpeg.hand ler@275d39,previaus=started,current=prefetched,target=prefetched,mediatime=javax,med ia.t ime@60a26f j 160.06: javax.media.durationllpdateeventj source=com.sun.media.content.video.mpeg. Handler@27Sd39,duration=j avax.media.time#484a05 Αυτό που είναι σαφές από την έξοδο και το σχήμα είναι ότι τα στάδια για την προετοιμασία της αναπαραγωγής των μέσων είναι χρονοβόρα, ιδιαίτερα από την άποψη ενός υπολογιστή που εκτελεί εκατομμύρια οδηγίες ανά δευτερόλεπτο. Το στάδιο realizing καταλαμβάνει πάνω από ένα ενάμισι δευτερόλεπτο, ενώ το στάδιο prefetch απαίτησε σχεδόν τρία τέταρτα ενός δευτερολέπτου, όλα για τα μέσα που αποθηκεύονται τοπικά στον σκληρό δίσκο. 2. Έλεγχος και Αλυσίδες Επεξεργασίας Τέσσερεις βασικές κλάσεις παίζουν κεντρικό ρόλο στον έλεγχο και την επεξεργασία του JMF. Αυτές οι τέσσερεις κλάσεις σχηματίζουν τους συνδέσμους σε μια αλυσίδα της οποίας το πρώτο στοιχείο είναι πάντα μια προέλευση μέσων. Ανάλογα με μια συγκεκριμένη εργασία που το μέσο τότε χειρίζεται (όπως αναπαραγωγή ή επεξεργασία), αυτός ο χειρισμός μπορεί να αποτελεί το τελικό αποτέλεσμα αυτό καθεαυτό (όπως ενός Player), ή ο χειρισμός μπορεί να έχει ως αποτέλεσμα νέα πηγή δεδομένων ή ακόμα και διαρκές αντικείμενο μέσων (media object) (για παράδειγμα ένα νέο αρχείο μέσων). 20

Το Σχήμα 9 παρουσιάζει τις βασικές κλάσεις που συμπεριλαμβάνονται στην αναπαραγωγή των μέσων. Τα μέσα προέρχονται μέσω ενός αντικειμένου DataSource. Αυτό χρησιμοποιείται για να δημιουργήσει ένα αντικείμενο Player, που αποδίδει το μέσο στις κατάλληλες συσκευές υλικού. Σχήμα 9 Αναπαραγωγή μέσων με το JMF: Τα μέσα προέρχονται μέσω μιας DataSource και αναπαράγονται με έναν Player. Το Σχήμα 10 παρουσιάζει τις βασικές κλάσεις που συμπεριλαμβάνονται στην επεξεργασία των μέσων. Όπως και με την αναπαραγωγή των μέσων, το πρώτο βήμα για την επεξεργασία αποτελεί η προέλευση των μέσων μέσω ενός αντικειμένου DataSource. Αυτό κατόπιν τίθεται υπό επεξεργασία - ένας περιεκτικός όρος που περιλαμβάνει πολυπλεξία/αποπολυπλεξία, εφέ, και διακωδικοποίηση. Το αποτέλεσμα της επεξεργασίας είναι άλλο ένα DataSource. Διευκρινίζοντας ότι η επεξεργασία μπορεί να είναι αλυσιδωτή, το DataSource που παράγεται στο πρώτο στάδιο της επεξεργασίας μπορεί να χρησιμεύσει ως DataSource εισόδου για ένα δεύτερο κύκλο επεξεργασίας. Ομοίως, η επεξεργασία θα μπορούσε να διεξαχθεί και τα αποτελέσματα να δοθούν στο αντικείμενο Player για τελική απόδοση (παρουσίαση). Σχήμα 10 Χρησιμοποιώντας έναν Processor: Η είσοδος φτάνει από ένα DataSource και ο Processor δημιουργεί ένα DataSource ως αποτέλεσμα της επεξεργασίας. 21

Το Σχήμα 11 παρουσιάζει τις εν λόγω βασικές κλάσεις όταν τα μέσα βάσει χρόνου (time-based media) που πρόκειται να παραχθούν, υπάρχουν μετά το πέρας του τερματισμού του προγράμματος JMF που τα παράγει. Όπως σε όλες τις περιπτώσεις, το αρχικό μέσο προέρχεται μέσω ενός αντικειμένου DataSource. Κατόπιν αυτό τυπικά τίθεται υπό επεξεργασία, όπως η διακωδικοποίηση σε διαφορετική μορφή, για να παραχθεί ένα νέο DataSource. Το DataSink για αυτό το δεύτερο DataSource λαμβάνεται έτσι ώστε να μπορέσουν να διατηρηθούν τα μέσα (για παράδειγμα, εγγεγραμμένα σε ένα αρχείο). Σχήμα 11 Χρησιμοποιώντας ένα DataSink σε δεδομένα εξόδου. Το DataSource που παράγεται από έναν Processor χρησιμεύει ως είσοδος στο DataSink. Οι κλάσεις του Player, Processor, DataSource και DataSink όλες αποτελούν τους MediaHandlers. Τόσο η διασύνδεση MediaHanldler όσο και οι τέσσερεις κλάσεις περιγράφονται σε ξεχωριστές ενότητες παρακάτω στην παρούσα εργασία. Τα μέσα λήψης περιπτώσεων για αυτές τις κλάσεις υπό το JFM επικεντρώνονται μέσω της κλάσης του manager που περιγράφεται παρακάτω. 3. Διαχείριση Πολυπλοκότητας Τα μέσα βάσει χρόνου (time-based media) αποτελούν μια ευρεία κατηγορία που συμπεριλαμβάνει όχι μόνο διαφορετικούς τύπους μέσων (π.χ. ήχου και εικόνας), αλλά επίσης και διαφορετικούς τύπους περιεχομένων (π.χ. QuickTime και AVI), και διαφορετικές μορφές συμπίεσης (π.χ. MPEG και CinePak). Αυτό οδηγεί σε πληθώρα διάφορων μέσων που διαφέρουν σε εννοιολογικό επίπεδο (οπτικό ή ακουστικό) στην ακολουθία δυαδικών ψηφίων (bit) βάσει των οποίων κωδικοποιούνται. Περαιτέρω πολυπλοκότητα 22

προστίθεται από το πλήθος συσκευών υλικού από τα οποία τα μέσα μπορούν να αποτυπώνονται, και στα οποία μπορούν να αποδοθούν. Από την άλλη μεριά, ο στόχος του JMF είναι να παρουσιάσει μια ενιαία, ανεξάρτητη από πλατφόρμες διασύνδεση για τον έλεγχο, την επεξεργασία, την αποτύπωση και την απόδοση των μέσων. Αυτό σημαίνει, για παράδειγμα, ένα ενιαίο πρόγραμμα που αναπαράγει τα μέσα ανεξαρτήτως των στοιχείων της κωδικοποίησής τους, και όχι ένα διαφορετικό πρόγραμμα για κάθε τύπο (category x content_type x encoding_scheme) των μέσων. Το JMF επιλύει με επιτυχία αυτά τα δυο αντικρουόμενα στοιχεία παρέχοντας τέσσερεις κλάσεις του manager των οποίων ο πρωταρχικός ρόλος είναι να εντοπίσουν τις πολυάριθμες κλάσεις που απαιτούνται για την υποστήριξη του χειρισμού των μέσων, ενώ προστατεύουν τον χρήστη από αυτήν την πολυπλοκότητα μέσω της παροχής απλής και σταθερής διασύνδεσης. Ουσιαστικά, οι managers δρουν ως μεσίτες ή μεσάζοντες μεταξύ του κώδικα του χρήστη και της αναγκαίας πολύπλοκης λειτουργικότητας που παρέχεται από το JMF. Το γεγονός αυτό παρέχει στον κώδικα του χρήστη ένα απλό και αφαιρετικό μοντέλο, απαλλαγμένο από ανεπιθύμητη πολυπλοκότητα. Το Σχήμα 12 περιγράφει τον εννοιολογικό ρόλο των managers. Η BBPApplet (Bare Bones Player Applet) παρέχει ένα καλό παράδειγμα αυτής της αφαιρετικότητας που διεξάγεται από τους managers. Η μικροεφαρμογή απλά ζητάει από τον manager να δημιουργήσει ένα αντικείμενο (Player) που να μπορεί να αναπαράγει τα μέσα όπως έχει υποδείξει. Ο manager ανταποκρίνεται με ένα αντικείμενο κατάλληλο για την εργασία. Το τρέχον αντικείμενο που παρέχεται θα εξαρτηθεί από τον τύπο του περιεχομένου και την μορφή των υπό εξέταση μέσων. Ωστόσο, από την οπτική γωνία της μικροεφαρμογής (applet), υπάρχει απλά ένα αντικείμενο Player που θα διεξάγει την εργασία. Ο manager απέκρυψε όλες τις λεπτομέρειες της εύρεσης και κατασκευής μιας παρουσίας της κατάλληλης κλάσης. 23

Player Interface void addcomtroller(controller tobecontrolled) Component getcontrolpanelcomponento GainControl getgaincontrol() Component getvisualcomponento void removecontroller(controller nologertobecontrolled) void start() Σχήμα 12 Ρόλος των κλάσεων manager (για παράδειγμα, Manager) ως μητρώο και προστασία του κώδικα του χρήστη από την αναγκαία πολυπλοκότητα των κλάσεων για την υποστήριξη του πλήθους των μορφών των μέσων. Το JMF διαθέτει τέσσερεις κλάσεις manager -καθεμία φέρει το όνομα Manager, σε ικανοποιητικό βαθμό. Καθεμία εκ των κλάσεων παρουσιάζει έναν αριθμό από στατικές μεθόδους μέσω των οποίων παρέχουν την υπηρεσία τους. Οι τέσσερεις κλάσεις είναι οι εξής: Manager- Η κεντρική κλάση management από την οποία λαμβάνονται οι Players, Processors, DataSources και DataSinks. Αυτός ο manager περιγράφεται στην επόμενη υποενότητα. CaptureDeviceManager- Ο Manager που ενθυλακώνει την γνώση των συσκευών απόδοσης (π.χ. ακουστικές ή οπτικές κάρτες απόδοσης) συνδεδεμένες με το μηχάνημα. Αυτός ο manager περιγράφεται προς το τέλος της εργασίας. PackageManager- O manager που παρέχει γνώση και έλεγχο στα πακέτα που συμβάλλουν στην λειτουργικότητα του JMF. PlugInManager- Ο manager που ενθυλακώνει τη γνώση των εγκατεστημένων plug-ins, καθώς και ένα μέσο καταχώρησης νέων. Το μοντέλο JMF ενός plug-in περιλαμβάνει πολυπλέκτες, αποπολυπλέκτες, κωδικοαποκωδικοποιητές, εφέ και προγράμματα απόδοσης (renderers). Παρόλο που υπάρχουν κενοί κατασκευαστές (constructors) για όλες τις κλάσεις εκτός από την κλάση Manager, όλες οι μέθοδοι που παρουσιάζονται 24

από τους manager είναι στατικές: Επικαλούνται με τη χρήση του ονόματος της κλάσης, και δεν χρειάζονται την παρουσία της κλάσης που κατασκευάζεται πριν να μπορέσει να επικαλεστεί. Συνεπώς, για παράδειγμα, για τη λήψη πληροφοριών για μια συγκεκριμένη αποκαλούμενη CaptureDevice, ο κώδικας πρέπει να είναι γραμμένος ως εξής: String devicename = "... " ; // Set to the actual name of the device CaptureDevicelnfo capturedinfo = CaptureDeviceManager.getDevice(deviceName); και όχι String devicename="..."; // Set to the actual name of the device CaptureDeviceManager capturedmanager = new CaptureDeviceManager( ); CaptureDevicelnfo capturedinfo = capturedmanager.getdevice(devicename); 3.1 Η Κλάση του Manager H κλάση του manager αποτελεί την ενιαία πιο σημαντική κλάση του manager, και εύλογα την πιο σημαντική κλάση στο JMF, δεδομένου του ρόλου της στη δημιουργία των Players, Processors, DataSinks και DataSources. Το Σχήμα 13 παρουσιάζει τις μεθόδους της κλάσης του Manager. Όπως μπορούμε να δούμε, ο Manager διαθέτει μεθόδους για τη δημιουργία των DataSources, DataSinks, Players και Processors. Έχει ήδη αναφερθεί σε προηγούμενη ενότητα ότι αυτές οι τέσσερεις κλάσεις παίζουν πρωταρχικό ρόλο στον έλεγχο και στην επεξεργασία των μέσων. Δεδομένης της σπουδαιότητάς τους, η σπουδαιότητα του Manager ως ο μόνος παράγοντας της δημιουργίας τους δεν θα πρέπει να υποτιμηθεί. 25

Σχήμα 13 Η κλάση του Manager Παρόλο που οι ακόλουθες ενότητες περιγράφουν τις κλάσεις Player, Processor, DataSource και DataSink, η δημιουργία τους μέσω της κλάσης του Manager περιγράφεται σε αυτήν την ενότητα. 3.1.1 Δημιουργία ενός Player Τα αντικείμενα που υλοποιούν την διασύνδεση Player χρησιμοποιούνται για τον έλεγχο της αναπαραγωγής (playback) των μέσων. Η κλάση του Manager παρέχει έξι μεθόδους για τη δημιουργία ενός Player. Οι τρεις εξ αυτών δημιουργούν έναν Unrealized Player: createplayer ( ), ενώ οι άλλες τρεις δημιουργούν έναν Realized (δηλαδή, με μερικούς πόρους και περισσότερο σε ετοιμότητα εκκίνησης) Player: createrealizedplayer ( ). Οι τρεις εκδοχές createrealizedplayer ( ) παρέχονται ως μέσο για να επιταχύνουν την δημιουργία ενός Player. Η μέθοδος καλεί μπλοκ (δηλαδή η επόμενη γραμμή του κώδικα δεν εκτελείται μέχρι την μετάβασή του Player σε κατάσταση Realized). Αυτό έχει το πλεονέκτημα ότι το Realized συμβάν δεν χρειάζεται να ακουστεί από αυτόν που επικαλείται την μέθοδο (και επομένως οι μέθοδοι όπως η getvisualcomponent ( ) μπορούν να κληθούν ως την επόμενη γραμμή). 26

Οι τρεις εκδοχές των μεθόδων δημιουργίας ενός Player (είτε για έναν Unrealized ή για έναν Realized Player) αποδέχονται τόσο έναν MediaLocator, URL, όσο και μια DataSource ως την μοναδική παράμετρο. Τα βήματα για τη δημιουργία ενός Player που ακολουθεί ένας Manager είναι τα ακόλουθα: 1. Μετατροπή του URL σε έναν MediaLocator (εάν χρησιμοποιείται μέθοδος βάσει URL). 2. Δημιουργία μιας DataSource για τον MediaLocator (εάν δεν χρησιμοποιείται μέθοδος βάσει DataSource). 3. Λήψη ενός Player που μπορεί να χειριστεί την DataSource. 4. Σύνδεση της DataSource με τον Player. 5. Επιστροφή του αντικειμένου Player. O! μέθοδοι δημιουργίας βάσει URL και MediaLocator είναι οι πιο ευρέως χρησιμοποιούμενες, διότι αντιστοιχούν στο τυπικό σενάριο κατά το οποίο χρησιμοποιείται ένας Player. Τα μέσα βρίσκονται σε κάποιες θέσεις (π.χ. σε ένα αρχείο) και χρειάζεται μόνο η αναπαραγωγή τους. Από την άλλη μεριά, η μέθοδος βάσει DataSource είναι χρήσιμη όταν η αναπαραγωγή αποτελεί το τελικό αποτέλεσμα σε μια αλυσίδα που συμπεριέλαβε άλλου είδους επεξεργασία (που παρήγαγε μια DataSource) σε προηγούμενα βήματα. Επομένως η τυπική χρήση του Manager για τη δημιουργία ενός Player είναι η εξής: MediaLocator locator = new MediaLocator(...); // Specify media location; Player player = Manager.createPlayer(locator); Εναλλακτικά, ένας Realized Player θα μπορούσε να δημιουργηθεί με την μέθοδο createrealizedplayer ( ) ως εξής: MediaLocator = new MediaLocator(...); // Specify the media location; Player player = Manager.createRealizedPlayer(locator); Κατά τη δημιουργία ενός αντικειμένου Player, ο Manager ακολουθεί ένα σύνολο αλγορίθμων αναζήτησης μέσω διαφόρων κλάσεων του Player 27

αναζητώντας έναν ικανό να χειριστεί τον τύπο του περιεχομένου που καθορίζει η DataSource (που κατασκευάστηκε ως προηγούμενο μέρος της διαδικασίας εάν η DataSource δεν ήταν εφοδιασμένη με αυτήν την μέθοδο). Η διαδικασία είναι μια απλή γραμμική επανάληψη μέσω της λίστας των κατασκευασμένων ονομάτων της κλάσης μέχρι να βρεθεί αυτό που θα είναι ικανό να χειριστεί τα μέσα. Εάν ο Manager δεν μπορεί να δημιουργήσει έναν Player, ενδεχομένως να εμφανίσει μια loexception (δηλαδή ένα αρχείο που δεν υπάρχει), μια NoPlayerException (δηλαδή, έναν τύπο περιεχομένου που δεν χειρίζεται το JMF), ή στην περίπτωση των μεθόδων createrealizedplayer ( ), μια CannotRealizedException (δηλαδή, δεν θα μπορούσε να λάβει τους απαραίτητους πόρους). Οι Players θα συζητηθούν περαιτέρω σε επόμενη ενότητα. 3.1.2 Δημιουργία ενός Processor Τα αντικείμενα που υλοποιούν την διασύνδεση Processor χρησιμοποιούνται για τον έλεγχο της επεξεργασίας των μέσων. Η κλάση του Manager παρέχει τέσσερεις μεθόδους για τη δημιουργία ενός Processor. Οι τρεις εξ αυτών δημιουργούν έναν Unrealized Processor: createprocessor ( ), ενώ η τελική μέθοδος δημιουργεί έναν Realized (δηλαδή, με μερικούς πόρους και περισσότερο σε ετοιμότητα εκκίνησης) Processor: createrealizedprocessor ( ). Η μέθοδος createrealizedprocessor ( ) παρέχεται ως μέσο για να επιταχύνει την δημιουργία ενός Processor. Η μέθοδος καλεί μπλοκ (δηλαδή η επόμενη γραμμή του κώδικα δεν εκτελείται μέχρι να γίνει ο Processor Realized). Αυτό έχει ένα πλεονέκτημα που το Realized συμβάν δεν χρειάζεται να ακουστεί από τον επικαλούμενο της μεθόδου. Η μέθοδος createrealizedprocessor ( ) δέχεται μια μοναδική παράμετρο δηλαδή το ProcessorModel, το οποίο καθορίζει πλήρως την μορφή εισόδου ή εξόδου των μέσων, και επομένως τη διεξαγωγή της επεξεργασίας. 28

Οι τρεις μεταβλητές του createprocessor ( ) έχουν την ίδια μορφή όπως και για τη δημιουργία του Player: αποδοχή είτε ενός MediaLocator, URL ή της DataSource ως μοναδική παράμετρο. Ομοίως, ο Manager ακολουθεί την ίδια διαδικασία για τη δημιουργία ενός Processor όπως και για τη δημιουργία ενός Player. 1. Μετατροπή του URL σε έναν MediaLocator (εάν χρησιμοποιείται μέθοδος βάσει URL). 2. Δημιουργία μιας DataSource για τον MediaLocator (εάν δεν χρησιμοποιείται μέθοδος βάσει DataSource). 3. Λήψη ενός Processor που μπορεί να χειριστεί την DataSource. 4. Σύνδεση της DataSource με τον Processor. 5. Επιστροφή του αντικειμένου Processor. O! μέθοδοι δημιουργίας βάσει URL και MediaLocator θα πρέπει να χρησιμοποιηθούν στην περίπτωση όπου η επεξεργασία αποτελεί το πρώτο βήμα στην αλυσίδα ελέγχου. Εναλλακτικά, εάν αποτελεί επόμενο βήμα (για παράδειγμα αλυσιδωτή επεξεργασία), η μέθοδος βάσει DataSource πρέπει να χρησιμοποιηθεί. Επομένως η τυπική χρήση του Manager για τη δημιουργία ενός Processor είναι η εξής: MediaLocator locator = new MediaLocator(...); // Specify media location; Processor processor = Manager.createProcessor(locator); Εναλλακτικά, ένας Realized Processor θα μπορούσε να δημιουργηθεί με την μέθοδο createrealizedprocessor ( ) ως εξής: //Specify the model for processing ProcessorModel model = new ProcessorModel...); // Create the processor Processor processor = Manager.createRealizedProcessor(model); 29

Κατά τη δημιουργία ενός αντικειμένου Processor, ο Manager ακολουθεί ένα σύνολο αλγορίθμων αναζήτησης μέσω διαφόρων κλάσεων του Processor για να αντιστοιχήσει στην ίδια προσέγγιση όπως χρησιμοποιείται και για τη δημιουργία του Player. Εάν ο Manager δεν μπορεί να δημιουργήσει έναν Processor, ενδεχομένως να εμφανίσει μια ^Exception (δηλαδή ένα αρχείο που δεν υπάρχει), μια NoProcessorException (δηλαδή, έναν τύπο περιεχομένου που δεν χειρίζεται το JMF), ή στην περίπτωση των μεθόδων createrealizedprocessor ( ), μια CannotRealizedException (δηλαδή δεν θα μπορούσε να λάβει τους απαραίτητους πόρους). Οι Processors θα συζητηθούν περαιτέρω σε επόμενη ενότητα. 3.1.3 Δημιουργία μιας DataSource Οι DataSouces αποτελούν τα μέσα από τα οποία οι Players, Processors, ή DataSinks λαμβάνουν τα δεδομένα τους. Η δημιουργία ενός Player, Processor ή DataSink πάντα περιλαμβάνει μια DataSource, είτε παρέχεται διεξοδικά κατά την μέθοδο δημιουργίας (όπως κατά τη δημιουργία ενός Datasink), είτε δημιουργείται ως μέρος μιας ευρύτερης διαδικασίας (όπως κατά τη δημιουργία ενός Player όπου παρέχεται ο MediaLocator). Οι λεπτομέρειες των DataSources παρατίθενται πλήρως σε επόμενη ενότητα. Υπάρχουν δυο μέθοδοι για τη δημιουργία μιας DataSource από έναν προσδιορισμό θέσης (URL ή MediaLocator) με τη χρήση της createdatasource ( ). Υπάρχουν επίσης άλλες δυο μέθοδοι για τη δημιουργία εξειδικευμένων DataSources: η συγχώνευση της DataSource (μια που συνδυάζει δυο ή περισσότερες DataSources) με createmergingdatasource ( ) και η δημιουργία μιας κλωνοποιήσιμης DataSource (μιας που μπορεί να κλωνοποιηθεί για να τεθεί υπό επεξεργασία ή αναπαραγωγή από διαφορετικά συστήματα ταυτόχρονα) με την createcloneabledatasource ( ). 30

Η λίστα 2 παρουσιάζει έναν αριθμό από μεθόδους δημιουργίας της DataSource που χρησιμοποιούνται σε ένα υποθετικό σενάριο κατά το οποίο δημιουργούνται δυο DataSources, η μία κλωνοποιείται (ώστε να μπορέσει για διεξαχθεί διπλή επεξεργασία), και κατόπιν οι δυο πηγές συνδυάζονται. Λίστα 2 Υποθετικό Σενάριο ϋβίββοϋγοθ MediaLocator firstlocation = new MediaLocatorj..,); //Location of 1" media MediaLocator secondlocation = new MediaLocator(...); // Location of 2nd media try { // Create the two datasources. DataSource firstsrc = Manager.createDataSource(firstLocation); DataSource secondsrc = Manager.createDataSource(secondLocation); // Create cloneable version of 2ni src, then clone it. DataSource cloneablesrc = Manager.createCloneableDataSource(secondSrc); DataSource clonea = cloneablesrc.createclone(); // Create a merged DataSource combining the 1st and 2"d DataSources. DataSource s r c A r ra y - new D atasource 12 ] ; s r c A r r a y ib l = f i r s t S r c, s r c A r r a y [ 1 ) - clonea,; Oatasouroed merge-dsrcs - Manager.createditorgingDatasource/srcArray); Οι DataSources αναγνωρίζονται από το πρωτόκολλο που υποστηρίζουν. Κατά τη δημιουργία μιας DataSource, η κλάση του Manager ακολουθεί μια παρόμοια προσέγγιση όπως αυτή που χρησιμοποιήθηκε από τη δημιουργία του Player και του Processor. Συντάσσεται μια λίστα των κλάσεων που υποστηρίζουν το καθορισμένο πρωτόκολλο (από το URL ή τον MediaLocator) και αυτή η λίστα αναζητείται γραμμικά μέχρι να βρεθεί μια κλάση ικανή να καθορίσει την προέλευση των μέσων. Αστοχία στη δημιουργία μιας DataSource από ένα URL ή έναν MediaLocator θα έχει ως αποτέλεσμα η μέθοδος να εμφανίσει μια ^Exception ή μια NoDataSourceException. Η αστοχία στη δημιουργία της συγχώνευσης της DataSource θα έχει ως αποτέλεσμα να εμφανιστεί μια IncompatibleSourceException. 31

3.1.4 Δημιουργία ενός DataSink Τα DataSinks χρησιμοποιούνται για να λάβουν τα μέσα από μια DataSource και να αποδοθούν σε μια συγκεκριμένη θέση (π.χ. ένα αρχείο). Η κλάση του Manager παρέχει μια μοναδική μέθοδο, την createdatasink ( ), για τη δημιουργία ενός DataSink. Η μέθοδος δέχεται δυο παραμέτρους- μια DataSource από την οποία προέρχονται τα μέσα, και έναν MediaLocator που καθορίζει την θέση προορισμού. Τα βήματα που ακολουθεί η κλάση του Manager κατά τη δημιουργία μιας παρουσίας DataSource είναι όμοια με αυτά που χρησιμοποιούνται για τη δημιουργία μιας DataSource -με το πρωτόκολλο του MediaLocator που χρησιμοποιείται για τη σύνταξη μιας λίστας των κλάσεων του DataSink που υποστηρίζουν το πρωτόκολλο. Αυτή η λίστα κατόπιν αναζητείται για την εύρεση της κατάλληλης κλάσης για την οποία μπορεί να δημιουργηθεί μια παρουσία. Αστοχία στη δημιουργία ενός DataSink θα έχει ως αποτέλεσμα να εμφανιστεί μια ΝοDataSink exception. Τα DataSinks περιγράφονται σε ακόλουθη ενότητα. Ωστόσο, ως παράδειγμα της χρήσης τους, η Λίστα 3 παρουσιάζει ένα τμήμα (δημιουργία ενός αντικειμένου) της διαδικασίας κατά την οποία θα μπορούσε να χρησιμοποιηθεί ένα DataSink για τη δημιουργία αντιγράφου του αρχείου των μέσων. (Προφανώς θα ήταν μακράν πιο αποτελεσματικό για να γίνει απλά αντιγραφή του αρχείου με τη χρήση των εντολών του λειτουργικού συστήματος.) Λίστα 3 Μερικά από τα Κύρια Βήματα για τη Χρήση ενός Αντικειμένου DataSink String origin = "file:..."; - String destination = file:...'1; MediaLocator originlocation = new MediaLocator( origin); MediaLocator destinationlocation = new MediaLocator( destination); Processor p = Manager. createrealizedprocessor( null); DataSource src = p. g e t D a t a O u t p u t O ; DataSink dest = M a n a g e r.createdatasink{src,destinationlocation); 32

3.2 Ερωτήματα/Αιτήματα στον Manager Εκτός από τις μεθόδους για τη δημιουργία των Players, Processors, DataSources και DataSinks, η κλάση του Manager παρέχει έναν αριθμό μεθόδων πληροφοριών- μεθόδων που παρέχουν πληροφορίες για τη διαμόρφωση και την υποστήριξη της εγκατεστημένης έκδοσης του JMF. Αυτές οι μέθοδοι πληροφοριών είναι οι διάφορες μέθοδοι get* ( ): gethint ( ) - Λαμβάνει πληροφορίες για hints που παρέχονται στο JMF. GetCacheDirectory ( )- Προσδιορίζει τον κατάλογο που χρησιμοποιεί το JMF για προσωρινή αποθήκευση. getdatasourcelist ( )- Προσδιορίζει τις κλάσεις DataSource που υποστηρίζουν ένα συγκεκριμένο πρωτόκολλο. gethandlerclasslist ( )- Προσδιορίζει τις κλάσεις του Player που υποστηρίζουν έναν συγκεκριμένο τύπο περιεχομένου. getprocessorclasslist ( )- Προσδιορίζει τις κλάσεις του Processor που υποστηρίζουν έναν συγκεκριμένο τύπο περιεχομένου. Η μέθοδος gethint ( ) πρέπει να μεταβιβαστεί ως μια εκ των σταθερών που καθορίζονται στην κλάση του Manager (π.χ. CACHING) και επιστρέφει τη ρύθμιση για αυτήν ως παρουσία του Αντικειμένου (Object). Η μέθοδος getcachedirectory ( ) δεν έχει παραμέτρους και επιστρέφει ένα String. Οι τρεις μέθοδοι get*list ( ), getdatasourcelist ( ), gethandlerclasslist ( ) και getprocessorclasslist ( ) καθεμιά αποδέχεται ένα String που καθορίζει τον τύπο περιεχομένου ή το πρωτόκολλο, για το οποίο υποβάλλεται ερώτημα στην υποστήριξη. Οι μέθοδοι επιστρέφουν έναν Vector. Τα στοιχεία του Vector είναι τα Strings, και αυτά τα Strings είναι οι πλέον κατάλληλες ονομασίες των κλάσεων που παρέχουν αυτήν την υποστήριξη. Η Λίστα 4 αποτελεί μια εφαρμογή του ManagerQuery, που χρησιμοποιεί τις πληροφορίες που συγκεντρώνουν τις μεθόδους του Manager για να παρέχουν στον χρήστη λεπτομέρειες σχετικά με το JMF. Κατά την εκτέλεση του 33

προγράμματος, οι χρήστες μπορούν να υποβάλλουν ερωτήματα στο JMF για την υποστήριξη του (Players, Processors, ή DataSources) για διαφορετικές μορφές και πρωτοκόλλα. Εναλλακτικά, μια ολοκληρωμένη εικόνα μπορεί να σχηματιστεί εάν δεν καθοριστούν συγκεκριμένες μορφές και πρωτόκολλα: Σε αυτήν την περίπτωση καταγράφονται όλες οι κλάσεις που υποστηρίζουν όλες τις γνωστές μορφές. Ομοίως, μια γραφική εφαρμογή GUIManagerQuery, βάσει ManagerQuery. Παρέχει την ίδια λειτουργικότητα όπως το ManagerQuery αλλά με γραφική διασύνδεση χρήστη. 34

Λίστα 4 Η Εφαρμογή του ΜθΠθςθΓΟϋθΓγ που χρησιμοποιείται για να ανακαλύψει πληροφορίες σχετικά με το ύμρ. /ft******»»*.*...,aw*,... ' ManagerQuery - Query the manager class about the configuration and * support of the installed JMF version. Managerduery is a text-based * application that provides a report on the support of the JMF for * P la y e r s, P r o c e s s o rs and D a ta S in k s. if * W ith o u t any c o m m a n d -lin e a rg u m e n ts M a n a g e rq u e ry p r i n t s a c o m p le te * (LONG) l i s t o f P la y e r, P r o c e s s o r, and D a ta S o u rc e c la s s e s t h a t * s u p p o r t th e v a r i o u s f o r m a t s, p r o t o c o l s, and c o n t e n t t y p e s. * * A l t e r n a t i v e l y i t i s p o s s i b l e t o p r o v id e c o m m a n d -lin e a rg u m e n ts ' s p e c i f y i n g th e f o r m a t o r p r o t o c o l f o r w h ic h s u p p o r t i s t o be * c h e c k e d - The means o f c a l l i n g i s as f o l l o w s : * ja v a M an a g e rq u e ry [ [ -h -pf-cfj s u p p o r t l s u p p o r t 2... s u p p o r t N ] * The -h f l a g s p e c i f i e s h a n d le r s ( P la y e r s ) o n l y. ' The -p f l a g s p e c i f i e s P r o c e s s o r s o n l y. * The -d f l a g s p e c i f i e s D a ta S c u r c e s o n l y. * L e a v in g o f f t h e f l a g d e f a u l t s b e h a v io u r t o c h e c k in g f o r P la y e r s * o n ly. it * F o r in s t a n c e : * ja v a M an a g e rq u e ry -h mp3 u la w * w o u ld l i s t th e C la s s e s c a p a b le o f P la y in g t h e MP3 (MPEG, L a y e r 3 ) * and u- Law formats (codecs). * * M an a g e rq u e ry a lw a y s p r i n t s t h e v e r s i o n o f JMF, c a c h in g d i r e c t o r y, * and h i n t s p r i o r t o a n y o t h e r o u t p u t. * * ^ a u t h o r S p ik e B a r lo w M r* * * *'*'* *-** ** ** * * * '* * * - '* '* - * - * * # * * * * * * * * '* * * * - * * " * - * * * * * * * * * * * '* * * '* - * '* * * * * - * '* ^ import javax.media.*; import javax.media.protocol.*; import javax.media.format.*; import java.util.*; public class ManagerQuery { /////////////////////////////////////////////////// // Constants to facilitate selection of the // approprite get*list() method. /////////////////////////////////////////////////// public Static final int HANDLERS = 1; public Static final int PROCESSORS = 2; public static final int DATASOURCES = 3; /////////////////////////////////////////////////////// II Array containing all the content types that JMF2.1.1 // supports. This is used when the user provides no // command -line arguments in order to generate a // complete list of support for all the content types. ///////////////////////////////////////////////////////// 35