Πτυχιακή Εργασία. του φοιτητή Χαράλαμπου Ρότσου

Transcript

1 Πτυχιακή Εργασία του φοιτητή Χαράλαμπου Ρότσου Ανάπτυξη συστημάτων μετάδοσης και ασφάλειας σε δίκτυα μετάδοσης περιεχομένου για τη διανομή ψηφιακής τηλεόρασης Επιβλέπων Καθηγητής: Δουληγέρης Χρήστος Ιούνιος 2006

2 Κατάλογος περιεχομένων 1. Εισαγωγή Πρόλογος Έρευνα Πεδίου Διαδικτυακή τηλεόραση MPEG MOVING PICTURE EXPERTS GROUP MPEG MPEG System Digital Video Broadcast Common Scrambling Algorithm DVB Conditional Access Common Scrambling Algorithm Μετάδοση δεδομένων Εισαγωγή Μεταφορά δεδομένων - Real Time Transport Protocol(RTP) Επικοινωνία Streamer και client Real Time Streaming Protocol(RTSP) Περιγραφή συνεδρίας - Session Description Protocol(SDP) Videolan Client VLC Η Ιστορία του VLC VLC API Modules Σχεδίαση Αρχιτεκτονική...55 Transcoder...55 Web Server...57 Streamer...58 Client Η ασφάλεια στο CDN Υλοποίηση Μεταγλώττιση προγράμματος RTSP SERVER RTSP Client Κρυπτογράφηση Αποκρυπτογράφηση Logging Mozilla Plugin Εγχειρίδιο Χρήστη Χρήση του VLC VLM (VideoLAN Manager) και Διεπαφή Telnet Mozilla Plugin Προτάσεις Βελτίωσης Βελτιστοποίηση της διαδικασίας αλλαγής κλειδιών Βελτιστοποίηση του συστήματος μετάδοσης Συμπεράσμτα...92 Συμπλήρωμα Α. Patch Κώδικα...97

3 1. Εισαγωγή

4 1.1 Πρόλογος Στα πλαίσια των πρόσφατων τεχνολογικών εξελίξεων παρατηρείται μία ανάπτυξη νέων υπηρεσιών. Μία από αυτές είναι και η διαδικτυακή τηλεόραση. Η υπηρεσία αυτή γνωρίζει αρκετά μεγάλη άνθηση τα τελευταία χρόνια με πάνω από 1000 κανάλια να λειτουργούν τη στιγμή αυτή στο διαδίκτυο και με χιλιάδες συνδρομητές σε αυτά. Η διαδικτυακή τηλεόραση επιτρέπει μέσω ενός απλού υπολογιστή και μίας γρήγορης σύνδεσης στο διαδίκτυο να παρακολουθήσουμε μία πληθώρα τηλεοπτικών προγραμμάτων από όλο τον κόσμο ή να επιλέξουμε την παρακολούθηση κάποιας συγκεκριμένης ταινίας (video on demand). Με την ανάπτυξη παράλληλα των δικτύων διανομής περιεχομένου η υπηρεσία αυτή καταφέρνει να αυξάνει τον αριθμό των πελατών που μπορεί να εξυπηρετήσει μικραίνοντας το κόστος λειτουργίας. Η παρούσα μελέτη αποτελεί μια έρευνα των προαναφερθέντων τεχνολογιών. Εκπονήθηκε στα πλαίσια του μαθήματος Πτυχιακή Εργασία του τέταρτου έτους του τμήματος Πληροφορικής του Πανεπιστημίου Πειραιώς. Αποτελεί ένα τμήμα μόνο ενός συστήματος, που αναπτύσσεται σε συνεργασία με τους φοιτητές Γιώργο Μπάκουλη και Στέφανο Βυζικίδη και υπό την εποπτεία και αμέριστη βοήθεια του υποψήφιου διδάκτορα του Πανεπιστημίου Πειραιώς Δημήτρη Γλυνού. Το σύστημα που αναπτύσσουμε ονομάζεται CDN και αποτελεί μια ολοκληρωμένη πλατφόρμα διανομής ψηφιακής τηλεόρασης μέσω δικτύου TCP/IP. Η πλατφόρμα έχει ως κύριο στόχο την ανάπτυξη μίας ανοιχτού κώδικα πλατφόρμας, η οποία θα καλύπτει τις ανάγκες μίας υπηρεσίας διαδικτυακής τηλεόρασης, θα μπορεί να ελέγχει την πρόσβαση των χρηστών στα διάφορα προγράμματα που προσφέρει και θα διαθέτει σύστημα χρέωσης. Το κομμάτι που μελετήθηκε από την παρούσα εργασία είναι η υλοποίηση του συστήματος μετάδοσης και παραλαβής των δεδομένων των ταινιών. Για την ανάπτυξή του χρησιμοποιήθηκε ως βάση το πρόγραμμα videolan client, το οποίο υλοποιεί μια πληθώρα σύγχρονων τεχνολογιών συμπίεσης και μετάδοσης video. Για τη μετάδοση των δεδομένων χρησιμοποιείται το πρωτόκολλο MPEG-2 ως φορέας του μέσου, ενώ χρησιμοποιούμε την τεχνολογία RTP για την πακετοποίηση και μετάδοση του ρεύματος μέσω ενός δικτύου, καθώς και το πρωτόκολλο RTSP για την επικοινωνία των χρηστών με τον εξυπηρετητή μέσων και τον έλεγχο του ρεύματος δεδομένων. Επίσης, στην εργασία αυτή μελετώνται οι δυνατότητες ασφαλούς μετάδοσης του ρεύματος με τη χρήση αλγορίθμων κρυπτογράφησης. Για την κρυπτογράφηση του ρεύματος δεδομένων των ταινιών που διαμοιράζει το πρόγραμμα στην υλοποίησή μας χρησιμοποιούμε το αλγόριθμο DVB- CSA. O αλγόριθμος αυτός αναπτύχθηκε από το διεθνή οργανισμό DVB για την κρυπτογράφηση ρευμάτων δεδομένων πραγματικού χρόνου και χρησιμοποιείται από πολλά σύγχρονα συστήματα συνδρομητικής τηλεόρασης, καθώς αποτελεί μια λύση με εύκολη υλοποίηση, χαμηλές απαιτήσεις και υψηλό επίπεδο ασφάλειας. Για να ενισχύσουμε το επίπεδο ασφάλειας του συστήματος υλοποιήσαμε και ένα σύστημα αλλαγής κλειδιών κρυπτογράφησης για τον αλγόριθμο, το οποίο ανά τακτά χρονικά διαστήματα ενημερώνει τους εγγεγραμμένους πελάτες για το νέο κλειδί. Το παρόν κείμενο οργανώνεται σε 5 ενότητες. Στην πρώτη ενότητα θα επιχειρήσουμε να παρουσιάσουμε γενικά τον τρόπο λειτουργίας και την αρχιτεκτονική του συστήματος CDN. Στη δεύτερη ενότητα θα παρουσιάσουμε το πρωτόκολλό MPEG 2 που χρησιμοποιούμε ως μέσο μεταφοράς των ταινιών και θα εστιάσουμε ιδιαίτερα στο επίπεδο συστήματος του πρωτοκόλλου, το οποίο χρησιμοποιείται από την εφαρμογή μας. Στο τρίτο κεφάλαιο θα παρουσιάσουμε τα πρωτόκολλα RTSP και RTP, καθώς και τον τρόπο που χρησιμοποιούνται από την εφαρμογή μας. Στην τέταρτη ενότητα θα παρουσιάσουμε τον αλγόριθμο κρυπτογράφησης DVB CSA, καθώς και το σύστημα κρυπτογράφησης που αναπτύξαμε με βάση αυτών. Τέλος, στην πέμπτη ενότητα τος προγράμματος θα παρουσιάσουμε το πρόγραμμα videolan client, καθώς και τις λεπτομέρειες χρήσης του προγράμματος από την εφαρμογή μας.

5 2. Έρευνα Πεδίου

6 2.1 Διαδικτυακή τηλεόραση Το σύστημα CDN συγκαταλέγεται στην κατηγορία συστημάτων διαδικτυακής τηλεόρασης (Internet TV ή Internet Protocol Television (IPTV) ή Television on the desktop (TOD) ή Television over Internet Protocol (TOIP) ). Με την έννοια διαδικτυακή τηλεόραση περιγράφουμε ένα σύστημα, το οποίο παρέχει υπηρεσίες ψηφιακής τηλεόρασης χρησιμοποιώντας ένα απλό δίκτυο tcp / ip. Η ιδέα ανάπτυξης μιας τέτοιας υπηρεσίας εμφανίζεται από αρκετά παλιά, από τις αρχές της δεκαετίας του 90. Η ιδέα όμως έμεινε για αρκετά χρόνια στα χαρτιά εξαιτίας τεχνικών δυσκολιών. Τα κύρια προβλήματα ήταν η χωρητικότητα των δικτύων, που εκείνη την εποχή ήταν πολύ μικρή αφού μία βασική σύνδεση δε ξεπερνούσε τα 56 Kbps, ενώ οι προσωπικοί υπολογιστές δεν ήταν ιδιαίτερα διαδεδομένοι ακόμα, συνεπώς μια τέτοια υπηρεσία θα είχε υψηλό κόστος ανά χρήστη λόγω του μικρού αγοραστικού κοινού. Στον ορισμό της συνδρομητικής τηλεόρασης θα μπορούσαμε να καθορίσουμε δύο βασικές υπηρεσίες που μπορεί να προσφέρει ένα τέτοιο σύστημα. Στην πρώτη κατηγορία περιλαμβάνονται οι υπηρεσίες Video on demand. Στην περίπτωση αυτή ο χρήστης συνδέεται απευθείας στον εξυπηρετητή και ζητά να του μεταδοθεί κάποιο συγκεκριμένο βίντεο μέσω μίας απευθείας σύνδεσης ένα προς ένα με τον εξυπηρετητή. Συνήθως, ο πελάτης έχει δυνατότητες ελέγχου του ρεύματος δεδομένων του βίντεο όπως θα είχε και κατά την αναπαραγωγή ενός τοπικού αρχείου βίντεο. Στη δεύτερη κατηγορία έχουμε τις υπηρεσίες broadcast. Στην περίπτωση αυτή ο εξυπηρετητής μεταδίδει ένα πρόγραμμα σε μεγάλο αριθμό πελατών ταυτόχρονα, με τρόπο παρόμοιο με μια επίγεια μετάδοση. Συνήθως, σε τέτοιες μεταδόσεις τα συστήματα χρησιμοποιούν τη δυνατότητα multicast του διαδικτύου, η οποία μας επιτρέπει να μεταδίδουμε ένα ρεύμα δεδομένων σε μία ομάδα πελατών. Στην περίπτωση αυτή, ο έλεγχος του ρεύματος δεδομένων από τους πελάτες δεν είναι αναγκαίος. Η πρώτη προσπάθεια ανάπτυξης μίας ολοκληρωμένης υπηρεσίας διαδικτυακής τηλεόρασης ξεκίνησε το 1994 στη Νορβηγία. Στόχος ήταν η διανομή δεκαπεντάλεπτων βίντεο με τα τοπικά νέα των διαφόρων περιοχών της χώρας. Στο παραδοσιακό σύστημα μετάδοσης της τηλεόρασης το κρατικό κανάλι αφιέρωνε κάποιο χρόνο του προγράμματος, στον οποίο η κάθε περιοχή εξέπεμπε ένα διαφορετικό σήμα, που περιελάμβανε ένα σύντομο δελτίο ειδήσεων με τα τοπικά νέα. Στο σύστημα αυτό όμως υπήρχε ένας εγγενής περιορισμός εξαιτίας της επίγειας μετάδοσης στην οποία βασιζόταν. Για να παρακολουθήσει κάποιος τα νέα κάποιας άλλης περιοχής θα έπρεπε υποχρεωτικά να μετακινηθεί κοντά σε κάποιον από τους πομπούς της περιοχής αυτής με κάποιο δέκτη. Για την αντιμετώπιση του προβλήματος αυτού το εθνικό ίδρυμα ερευνών την Νορβηγίας ανέπτυξε το σύστημα LAVA[1]. Το σύστημα αυτό επιτρέπει στους χρήστες του να λάβουν σε ψηφιακό βίντεο, μέσω του διαδικτύου, τα τοπικά νέα οποιασδήποτε περιοχής της Νορβηγίας επιθυμούν. Για τη χρήση του οι προγραμματιστές ανέπτυξαν μία μικρή εφαρμογή-πελάτη, η οποία λειτουργούσε ως plugin στον περιηγητή ιστοσελίδων Navigator. Με το πρόγραμμα αυτό ο κάθε χρήστης μπορούσε, επιλέγοντας το αντίστοιχο link από μία ιστοσελίδα, η οποία παρουσίαζε όλα τα διαθέσιμα δελτία ειδήσεων, να συνδεθεί σε κάποιον από τους ειδικούς εξυπηρετητές του συστήματος και να παρακολουθήσει τα νέα κάποιας άλλης περιοχής μέσω streaming video. Το σύστημα αυτό παρείχε δυνατότητες ελέγχου του ρεύματος δεδομένων στους χρήστες επιτρέποντάς τους, παράλληλα, να ελέγχουν την αναπαραγωγή του video, ενώ διατηρούσε τα διάφορα video με τα νέα της κάθε περιοχής για μία εβδομάδα. Παρόμοια συστήματα αναπτύχθηκαν μετά από σύντομο χρονικό διάστημα και από άλλα διεθνή κανάλια. Το CNN παρείχε μία παρόμοια υπηρεσία με εκπαιδευτικούς προσανατολισμούς. Το σύστημα αυτό είχε ένα αρχείο με μορφωτικά θέματα, όπως γεωγραφία, πολιτιστικά κ.α., στα οποία μπορούσε ο κάθε χρήστης να συνδεθεί και να τα παρακολουθήσει ανά πάσα στιγμή[2]. Παράλληλα, αναπτύχθηκαν και υπηρεσίες ζωντανής μετάδοσης του προγράμματος κάποιων καναλιών. Χαρακτηριστικά παραδείγματα είναι το NBC broadcasts, με θεματολογία σχετική με οικονομικά, και το CBS News Up-to-the-Minute, το οποίο παρουσίαζε αποκλειστικά ειδήσεις. Τα δύο αυτά προγράμματα είχαν ζωντανή μετάδοση και δε μπορούσε ο χρήστης να αναζητήσει παλαιότερα βίντεο. Την τρέχουσα περίοδο με την ανάπτυξη ειδικότερα της τεχνολογίας ADSL, η οποία έδωσε τη

7 δυνατότητα στους χρήστες να έχουν μεγάλες ταχύτητες με χαμηλό κόστος, η υπηρεσία της διαδικτυακής τηλεόρασης έχει κεντρίσει το ενδιαφέρον πολλών μεγάλων εταιριών και πολλά εμπορικά συστήματα έχουν αναπτυχθεί. Ήδη, η microsoft προσφέρει τη συνδρομητική υπηρεσία MSN TV, στην οποία ο χρήστης μπορεί να συνδεθεί είτε μέσω του υπολογιστή του είτε, εναλλακτικά, μέσω ειδικών κουτιών, τα οποία αποτελούν υλοποιήσεις υπολογιστών χαμηλού κόστους και να παρακολουθήσει κάποιο από τα διαθέσιμα κανάλια που προσφέρονται. Παρόμοιες υπηρεσίες παρέχονταν και από την εταιρία AOL στην Αμερική υπό το όνομα AOLTV. Η υπηρεσία αυτή όμως τερματίστηκε πρόσφατα, καθώς δεν είχε την οικονομική επιτυχία που αναμενόταν. Στην κατηγορία της διαδικτυακής τηλεόρασης τον τελευταίο καιρό πολλοί περιλαμβάνουν και την περίπτωση τηλεοπτικών προγραμμάτων τα οποία παράγονται για να διαμοιραστούν αποκλειστικά μέσω διαδικτύου μέσω ΗΤΤP ή Peer to Peer συστημάτων. Επίσης, μία ακόμα ενδιαφέρουσα εταιρία διαδικτυακής τηλεόρασης είναι και η Jump TV. Η υπηρεσία αυτή προσφέρει στους πελάτες της, με κάποια μηνιαία συνδρομή βέβαια, πρόσβαση μέσω του διαδικτύου σε πάνω από 180 επίγεια κανάλια από όλο τον κόσμο. Έτσι, ο κάθε χρήστης μπορεί να παρακολουθεί προγράμματα άλλων χωρών μέσω ενός απλού υπολογιστή με μία γρήγορη σύνδεση στο διαδίκτυο, αποφεύγοντας έτσι την αγορά ακριβού εξοπλισμού δορυφορικής τηλεόρασης.

8 2.2 MPEG Στο κεφάλαιο αυτό θα παρουσιάσουμε τις λεπτομέρειες του πρωτοκόλλου MPEG. Το πρωτόκολλο αυτό αποτελείται από πολλά ξεχωριστά κομμάτια, όπως θα δούμε και παρακάτω και καθορίζει μεταξύ άλλων πρότυπα συμπίεσης εικόνας και ήχου, πρότυπα πολύπλεξης ρευμάτων δεδομένων πραγματικού χρόνου, πρότυπα επικοινωνίας εξυπηρετητή και πελατών κ.α. Η σημαντικότερη χρησιμότητα του πρωτοκόλλου στην εφαρμογή που αναπτύξαμε είναι η χρήση του στην πολύπλεξη των ρευμάτων μίας παρουσίασης. Για τη μετάδοση των δεδομένων μίας ταινίας η εφαρμογή μας χρησιμοποιεί το πρότυπο MPEG-TS για την πολύπλεξη και την πακετοποίηση των δεδομένων. Πρόκειται για ένα πρότυπο ειδικά σχεδιασμένο για δικτυακή χρήση, το οποίο είναι αρκετά ανθεκτικό σε σφάλματα μετάδοσης και χρησιμοποιείται ευρέος στις μεταδόσεις δορυφορικής ψηφιακής τηλεόρασης MOVING PICTURE EXPERTS GROUP Το ακρωνύμιο MPEG (Moving Picture Experts Group) είναι τα αρχικά μιας ομάδας εργασίας του International Organisation for Standarization (ISO) και του International Electrotechnical Commision (IEC), η οποία είναι επιφορτισμένη με την ανάπτυξη προτύπων κωδικοποίησης για ψηφιακό βίντεο και ήχο. Συγκεκριμένα, το επίσημο όνομα της ομάδας είναι ISO/IEC JTC 1/SC 29/WG 1 και η εργασία που έχει αναλάβει περιγράφεται ως ανάπτυξη διεθνών προτύπων για τη συμπίεση, αποσυμπίεση, επεξεργασία και κωδικοποιημένη αναπαράσταση κινούμενης εικόνας, ήχου και συνδυασμού αυτών των δύο, με στόχο την ικανοποίηση των αναγκών ποικίλων εφαρμογών. Η ομάδα ξεκίνησε τις εργασίες της το 1988 και σήμερα αριθμεί 350 μέλη τόσο από το χώρο της βιομηχανίας όσο και από τον ακαδημαϊκό χώρο. Πρόκειται για μία ευρέως αποδεκτή ομάδα εργασίας και τα πρωτόκολλα που έχει μέχρι στιγμής εκδώσει χρησιμοποιούνται ευρέως από τη βιομηχανία. Συγκεκριμένα, μέχρι σήμερα η ομάδα έχει εκδώσει 6 πρότυπα: 1. MPEG-1: Το πρώτο πρωτόκολλο που εκδόθηκε από την επιτροπή ήταν το MPEG-1 και εκδόθηκε το 1992 στο Λονδίνο. Πρόκειται για την πρώτη έκδοση της ομάδας και αφορά την ανάπτυξη προτύπων συμπίεσης ήχου και εικόνας για την αποθήκευση μέσων με ρυθμό μέχρι 1.5 Mbit/sec και ποιότητα που αντιστοιχεί στο πρότυπο VHS. Το πρωτόκολλο είναι χωρισμένο σε πέντε μέρη. Στο πρώτο μέρος παρουσιάζει ένα πρότυπο, το Program Stream(PS), το οποίο επιτρέπει το συγχρονισμό και την πολύπλεξη ρευμάτων ήχου και εικόνας. Στο δεύτερο μέρος το πρότυπο καθορίζει έναν αλγόριθμο συμπίεσης βίντεο σε ποιότητα VHS και απόδοση 1,15 Mbit/s χρησιμοποιώντας των αλγόριθμο συμπίεσης jpeg για το κάθε frame του video. Στο τρίτο μέρος του πρωτοκόλλου περιγράφεται μια νέα τεχνική συμπίεσης ήχου, το MP3 το οποίο είναι από τα πιο διαδεδομένα πρότυπα συμπίεσης ήχου σήμερα. Το πρότυπο αυτό βασίζεται τόσο στη τεχνική συμπίεση δεδομένων PCM όσο και σε κάποιες παρατηρήσεις της επιστήμης της ψυχοακουστικής. Τα διαθέσιμα profil ρυθμού δεδομένων για το MP3 είναι 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 και 320 kbit/s, ενώ οι διαθέσιμες συχνότητες δειγματοληψίας είναι 32, 44.1 και 48 Khz. Σε γενικές γραμμές το πρότυπο mp3 επιτρέπει τη συμπίεση με απόδοση 1:10 ενός ηχητικού σήματος με μηδενική σχεδόν απώλεια πιστότητας. Στο τέταρτο μέρος του πρωτοκόλλου περιγράφονται κάποιες μέθοδοι ελέγχου συμβατότητα ενός συστήματος με το πρωτόκολλο MPEG- 1. Τέλος στο πέμπτο μέρος του πρωτόκολλο παρουσιάζεται ένα σύστημα MPEG-1 υλοποιημένο στη γλώσσα προγραμματισμού C. Το πρωτόκολλο MPEG 1 αν και σήμερα θεωρείται ξεπερασμένο για την κωδικοποίηση βίντεο, κάποια μέρη του χρησιμοποιούνται σε μεγάλο βαθμό σε καθημερινές εφαρμογές όπως στη δημιουργία video-cd και στη συμπίεση αρχείων ήχου. 2. MPEG-2: Το δεύτερο πρωτόκολλο που επικύρωσε η επιτροπή ήταν το MPEG-2. Η πρώτη επίσημη έκδοσή του ήταν το Το πρωτόκολλο αυτό μας ενδιαφέρει καθώς χρησιμοποιείται σε μεγάλο βαθμό στην εφαρμογή μας. Το MPEG 2 συνολικά αποτελείται από 11 μέρη, με τα πέντε πρώτα να έχουν ίδιο θέμα με το MPEG-1. Οι κυριότερες διαφορές μεταξύ των δύο πρωτοκόλλων εντοπίζονται σε 2 κυρίως σημεία στα 5 πρώτα κεφάλαια. Στο πρώτο μέρος του, το πρωτόκολλο MPEG - 2 παρουσιάζει ένα νέο πρότυπο πολύπλεξης και πακετοποίησης των διαφόρων ρευμάτων ενός μέσου. Το πρότυπο αυτό ονομάζεται Transport Stream (TS) και στόχο έχει την αποδοτικότερη

9 αποστολή μέσων μέσω του διαδικτύου, ενώ παράλληλα επεκτείνεται το υπάρχον πρότυπο Program Stream (PS) επιτρέποντας την αποτελεσματικότερη αποθήκευση ρευμάτων. Στο δεύτερο κεφάλαιο του MPEG 2 που αφορά τα πρότυπα συμπίεσης βίντεο, το πρωτόκολλο καθορίζει μια προέκταση του υπάρχοντος προτύπου που επιτρέπει την υποστήριξη διαπλεκόμενων εικόνων (interlaced images) δυνατότητα η οποία επιτρέπει την αποδοτικότερη συμπίεση. Επίσης σε αυτήν την έκδοση η ερευνητική ομάδα παρουσίασε κάποια νέα κεφάλαια στο πρωτόκολλο. Στο έκτο και δέκατο κεφάλαιο παρουσιάζεται το πρωτόκολλο DSM-CC (Digital Storage Media Command and Control), το οποίο επιτρέπει τη δημιουργία συνεδριών μεταξύ ενός πελάτη και ενός εξυπηρετητή μέσων, καθώς και τον απομακρυσμένο έλεγχο των εξυπηρετητών. Στο έβδομο κεφάλαιο παρουσιάστηκε ένα νέο πρότυπο κωδικοποίησης ήχου, το ACC, το οποίο επιτρέπει την κωδικοποίηση πολυκάναλων ρευμάτων ήχου. Τέλος, στο όγδοο κεφάλαιο το πρωτόκολλο καθορίζει μεθόδους διαχείρισης εικόνων βίντεο για τις οποίες το χρώμα αναπαρίσταται με περισσότερα από 8 bits ενώ στο ένατο κεφάλαιο παρουσιάζει μια διεπαφή ανάμεσα στο Transport Stream και στον αποκωδικοποιητή, που στόχο έχει να καλύψει τις ανάγκες του DSM-CC για τη δημιουργία συνεδριών. 3. MPEG-4: Η τρίτη έκδοση πρωτοκόλλου από την ομάδα MPEG ήταν το MPEG-4. Το πρωτόκολλο αυτό έχει συνολικά 21 κεφάλαια, διατηρώντας βέβαια τους τίτλους των 6 πρώτων ίδιους με αυτούς τους MPEG-2. Το πρωτόκολλο αυτό παρουσιάστηκε επίσημα το 1998 και είχε ως τίτλο Κωδικοποίηση οπτικοακουστικών αντικειμένων. Σε γενικές γραμμές, η έκδοση αυτή του πρωτοκόλλου είχε ως πρωταρχικό στόχο την προσθήκη της δυνατότητας κωδικοποίησης μεμονωμένων αντικειμένων σε μία παρουσίαση στα ήδη υπάρχοντα πρωτόκολλα. Μερικές από τις επεκτάσεις που υποστηρίζονται είναι η δυνατότητα διαχείρισης πολλαπλών ρευμάτων ήχου με διαφορετική κωδικοποίηση του καθενός και διαφορετικής χρηστικότητα καθώς και η δυνατότητα διαχείρισης 3D αντικειμένων. Επίσης προστέθηκε ένας μηχανισμός διαχείρισης και προστασίας δικαιωμάτων, που προκύπτουν από μεμονωμένα αντικείμενα ενός αρχείου. Τέλος, το πρωτόκολλο παρουσίασε και κάποιους νεότερους και αποδοτικότερους αλγορίθμους συμπίεσης ήχου και βίντεο (AVC). Το MPEG-4 μπορεί ποια να καλύψει ρυθμούς μετάδοσης δεδομένων μέχρι 1 Gbit/s. 4. MPEG-7: Το πρωτόκολλο αυτό είναι το τέταρτο πρωτόκολλο που εκδόθηκε από την ομάδα. Η μελέτη του ξεκίνησε τον Απρίλιο του 1997 και ακόμα βρίσκεται υπό ανάπτυξη. Αποτελείται συνολικά από 11 κεφάλαια. Το MPEG - 7 καθορίζει κάποιες νέες δυνατότητες για τα παλιότερα πρωτόκολλα που στόχο έχουν τον εμπλουτισμό τους με δυνατότητες αποθήκευσης μεταπληροφοριών που περιγράφουν τα δεδομένα του αρχείου. Τα δεδομένα αυτά υπακούν σε κάποιο δεδομένο σχήμα και μπορούν να αναφέρονται σε εικόνες, σε ήχο και σε απλό κείμενο. 5. MPEG-21: Το πρωτόκολλο MPEG-21 είναι το όραμα της ομάδας για το μέλλον στον τομέα των πολυμέσων. Η ανάπτυξη του ξεκίνησε το Μάιο Ιούνιο του Το MPEG-21 είναι ένα ανοιχτό πρωτόκολλο που στόχο έχει την ανάπτυξη ενός πλαισίου για τον έλεγχο των δικαιωμάτων σε εφαρμογές πολυμέσων. Ποιο συγκεκριμένα το πρωτόκολλο καθορίζει ένα πρότυπο για μια Γλώσσα έκφρασης δικαιωμάτων (Rights Expression Language) με την οποία μπορεί να εμπλουτίζεται κάθε αρχείο πολυμέσων και η οποία καθορίζει την άδεια, τα δικαιώματα και τους περιορισμούς που επιβάλει ο δημιουργός του περιεχομένου στους χρήστες. Σε γενικές γραμμές το MPEG-21 προσπαθεί να εισάγει τις έννοιες της δημιουργίας, πρόσβασης, της ανταλλαγής και διαχείρισης ηλεκτρονικών δικαιωμάτων στο σημερινό πλαίσιο ανάπτυξης πολυμέσων με τρόπο ο οποίος να μη γίνεται αντιληπτός άμεσα από τους χρήστες. Η ανάπτυξη του προτύπου αυτού έχει ως κύριο στόχο τη καταπολέμηση της πειρατείας η οποία αναπτύσεται σε μεγάλο βαθμό από τα δίκτυα Peer to Peer. Το πρωτόκολλο αυτό βρίσκεται ακόμα υπό ανάπτυξη και στοχεύει να αλλάξει κατά πολύ τον τρόπο που αντιλαμβανόμαστε τις εφαρμογές πολυμέσων. Η ομάδα εργασίας πέρα από τα παραπάνω πρότυπα που παρουσιάζουν ολοκληρωμένες λύσεις όσον αφορά στη συμπίεση και μετάδοση μιας παρουσίασης, εξέδωσε και κάποια ακόμα που ασχολούνται με κάποιο υποσύνολο της διαδικασίας αυτής. Στην παραπάνω κατηγορία ανήκει το MPEG-A, το οποίο παρέχει ένα πλαίσιο για την ενοποίηση στοιχείων από τα διάφορα πρότυπα συμπίεσης MPEG σε ένα πρότυπο το οποίο θα είναι κατάλληλο για κάποια συγκεκριμένη αλλά ευρέος χρησιμοποιούμενη εφαρμογή, το MPEG-B, το οποίο παρουσιάζει ένα πλαίσιο για την αποθήκευση MPEG ρευμάτων σε xml αρχεία κ.α.

10 Η ομάδα ανάπτυξης του MPEG αποτελείται τόσο από ακαδημαϊκούς εγνωσμένης αξίας όσο και από εκπροσώπους της βιομηχανίας. Η ανάπτυξη των πρωτοκόλλων γίνεται μέσα από ανοιχτές προσκλήσεις για προτάσεις, οι οποίες γίνονται μόνο προς τα μέλη της ομάδας. Με βάση τις προτάσεις, που γίνονται, οι ομάδες που έχουν αναλάβει την ανάπτυξη κάποιου προτύπου προτείνουν κάποιο αρχικό κείμενο το οποίο μέσα από συζητήσεις και ψηφοφορίες καταλήγει στην τελική δημοσίευση. Η ανάπτυξη βέβαια των προτύπων του MPEG δέχεται από πολλούς κριτική, καθώς είναι αρκετά κλειστή διαδικασία και τα τελικά πρότυπα δεν είναι ελεύθερα σε όλους τους χρήστες, αναγκάζοντας τους ενδιαφερόμενους να καταβάλουν κάποιο ποσό στον ISO για να λάβουν αντίγραφα των προτύπων MPEG 2 Το πρωτόκολλο MPEG 2 παρουσιάστηκε ως επίσημο πρωτόκολλο αρχικά το Νοέμβριο του 1994 στη Σιγκαπούρη. Η πρώτη αυτή έκδοση περιελάμβανε μόνο τα τρία πρώτα κεφάλαια του πρωτοκόλλου. Τα υπόλοιπα οκτώ κεφάλαια παρουσιάστηκαν ένα χρόνο αργότερα. Η ανάπτυξη αυτού του νέου πρωτοκόλλου είχε ως κύριο έναυσμα το αίτημα κάποιων εταιριών της βιομηχανίας ψηφιακής εικόνας για τη προσθήκη κάποιων δυνατοτήτων στο MPEG-1. Το βασικότερο πρόβλημα που ανέκυπτε στο MPEG 1 ήταν ότι η ποιότητα του προτύπου VHS που απέδιδε ήταν χαμηλή σε σχέση με την ποιότητα των πρότυπων PAL και του HDTV που χρησιμοποιούνταν εκείνη την εποχή από τη τηλεόραση. Επίσης, οι μελέτες μέχρι τότε έδειχναν ότι ο αλγόριθμος που χρησιμοποιούσε το MPEG - 1 ήταν αρκετά αναποτελεσματικός σε σχέση με τους αλγορίθμους που είχαν αναπτυχθεί εκείνη την εποχή για τη συμπίεση video, ενώ παράλληλα ο νέος αλγόριθμος συμπίεσης του MPEG 2 θα έπρεπε να είναι συμβατός με αυτόν του MPEG 1 ώστε να υπάρχει μια συνέχεια μεταξύ των δύο πρωτοκόλλων. Παρόμοιο πρόβλημα αντιμετώπιζε η ομάδα ανάπτυξης και με τον ήχο. Για να διασφαλιστεί μια αρμονική λύση, που θα κάλυπτε μια ευρεία γκάμα εφαρμογών, η ομάδα εργασίας ανέπτυξε το MPEG 2 σε στενή συνεργασία με τις ομάδες μελέτης ITU-TS Study Group και Expert Group for ATM Video Coding. Εκτός των δύο αυτών ομάδων, άλλοι αντιπρόσωποι των σχεδιαστών των ITU-TS, EBU, ITU-RS, SMPTE και North America HDTV εργάστηκαν επίσης στο MPEG 2. Για την επίλυση όλων αυτών των προβλημάτων το νέο πρωτόκολλο MPEG 2 παρουσίασε στο δεύτερο κεφάλαιο του προτύπου ένα νέο αλγόριθμο συμπίεσης δεδομένων video, ο οποίος χρησιμοποιούσε ως βάση τον αλγόριθμο του MPEG 1 με κάποιες επεκτάσεις, όπως η υποστήριξη της τεχνικής της διαπλεκόμενης διαμόρφωσης βίντεο και η κλιμάκωση συμπιεσμένου βίντεο. Η τεχνική της διαπλεκόμενης διαμόρφωσης προήλθε από τα πρότυπα PAL και NTSC που χρησιμοποιούνται στη μετάδοση σήματος τηλεόρασης και επιτρέπει την παραγωγή διπλάσιου αριθμού πλαισίων σε σχέση με το ρυθμό λήψης. Συγκεκριμένα, σε κάθε αλλαγή πλαισίου ο αποκωδικοποιητής σήματος αλλάζει αρχικά μόνο τις μισές γραμμές προκαλώντας όμως έτσι τη ψευδαίσθηση στο θεατή ότι πρόκειται για δυο διαφορετικά πλαίσια. Η τεχνική της κλιμάκωσης συμπιεσμένου βίντεο από την άλλη, επιτρέπει τη συμπίεση του βίντεο σε διαφορετικές ποιότητες κατά την κωδικοποίηση, ώστε να καλύπτονται οι ανάγκες των διαφόρων εφαρμογών που θα χρησιμοποιήσουν το πρότυπο. Στον αλγόριθμο συμπίεσης υπάρχουν και πολλά άλλα προηγμένα χαρακτηριστικά, τα οποία είναι πέρα από τη σκοπιμότητα αυτής της παρουσίασης και δεν θα αναλυθούν περαιτέρω. Ο νέος αλγόριθμος συμπίεσης του ρεύματος βίντεο τελικά καταφέρνει να πετύχει επιπλέον συμπίεση των δεδομένων κατά 20% όταν χρησιμοποιείται η διαπλεκόμενη διαμόρφωση βίντεο και μπορεί να αποδώσει τηλεοπτικό σήμα με ποιότητα σύμφωνη με το πρότυπο Composite TV με ρυθμό μετάδοσης μικρότερο από 6 Mbit/s. Στο δεύτερο κεφάλαιο του πρωτοκόλλου MPEG 2 παρουσιάζεται επίσης και μια νέα προσέγγιση όσον αφορά τις υποστηριζόμενες ποιότητες εικόνας. Στο MPEG 1 το πρωτόκολλο καθόριζε μία μόνο ποιότητα εικόνας με ανάλυση 352 x 240 pixel που χρειαζόταν ρυθμό αποστολής δεδομένων 1,5 Mbit/s. Αργότερα, βέβαια, αυτό άλλαξε και με κάποιες βελτιώσεις το πρότυπο επέτρεπε την αποστολή ενός βίντεο με ρυθμό μέχρι 4 Mbit/s με ταυτόχρονη βελτίωση της ποιότητας του βίντεο. Στο πρότυπο MPEG 2 η επιτροπή ανάπτυξης διάλεξε μια διαφορετική προσέγγιση επιλέγοντας το καθορισμό διαφόρων προφίλ ποιότητας εικόνας, όπου το καθένα

11 κάλυπτε μία μεγάλη γκάμα εφαρμογών και με ρυθμούς αποστολής από 4 100Mbit/s. Τα προφίλ αυτά σχεδιάστηκαν κατάλληλα για να αντιπροσωπεύουν τις ανάγκες κάποιων γενικών ομάδων εφαρμογών. Τα διαφορετικά προφίλ του πρωτοκόλλου εμφανίζονται στο πίνακα 1 με τους αντίστοιχους ρυθμούς μετάδοσης. Τα προφίλ αυτά διατάσσονται σε ένα πίνακα 5 x 4. Στον κατακόρυφο άξονα του πίνακα αυτού έχουμε τα διαφορετικά επίπεδα ανάλυσης του βίντεο που μπορεί να υποστηρίζονται. Τα πρότυπα που χρησιμοποιούνται είναι 4: το χαμηλό επίπεδο (Low Level) που καθορίζει ανάλυση 352 x 288 pixel, ρυθμό ανανέωσης 30 πλαίσια/s και ρυθμό μετάδοσης 4 Mbit/s, το κύριο επίπεδο (Main Level) που καθορίζει ανάλυση 720 x 576 pixel, ρυθμό ανανέωσης 30 πλαίσια/s και ρυθμό μετάδοσης 15 Mbit/s, το υψηλό επίπεδο 1440 (High-1440 level) που καθορίζει ανάλυση 1440 x 1152 pixel, ρυθμό ανανέωσης 30 πλαίσια/s και ρυθμό μετάδοσης 60 Mbit/s και το υψηλό επίπεδο (High Level) που καθορίζει ανάλυση 1920 x 1152 pixel, ρυθμό ανανέωσης 30 πλαίσια/s και ρυθμό μετάδοσης 80 Mbit/s. Ο οριζόντιος άξονας εκφράζει τα διάφορα προφίλ που καθορίζονται σε σχέση με τους τύπους πλαισίων που χρησιμοποιούμε, το ρυθμό δειγματοληψίας χρώματος και τον αριθμό των ρευμάτων. Σε αυτόν τον άξονα καθορίζονται συνολικά 5 προφίλ: το απλό προφίλ (Simple Profile), το οποίο είναι μη κλιμακούμενο, δε χρησιμοποιεί πλαίσια B και εμφανίζει υποδειγματοληψία με ρυθμό 4:2:0, το κύριο προφίλ (Main Profile) που εμφανίζει υποδειγματοληψία με ρυθμό 4:2:0, το προφίλ κλιμάκωσης SNR (SNR profile) το οποίο υποστηρίζει κλιμακούμενο Signal-To-Noise ratio για τη συμπίεση των δεδομένων και εμφανίζει υποδειγματοληψία με ρυθμό 4:2:0, το χωρικό προφίλ κλιμάκωσης (Spatial Profile), το οποίο χρησιμοποιεί χωρική κλιμάκωση για περαιτέρω συμπίεση του ρεύματος δειγματοληψίας και υποδειγματολειψία 4:2:0 και το υψηλό προφίλ (High Profile), το οποίο χρησιμοποιεί υποδειγματοληψία 4:2:2 ή 4:2:0. Τα προφίλ που περιγράψαμε παραπάνω μπορούν να συνδυαστούν με κάποιο πρότυπο για τα πλαίσια του βίντεο και να καθοριστούν έτσι οι λεπτομέρειες της κωδικοποίησης του ρεύματος βίντεο. Σημαντικό είναι να τονίσουμε σε αυτό το σημείο, ότι το MPEG - 2 καθορίζει ποιοι συνδυασμοί είναι επιτρεπτό να υλοποιηθούν, καθώς δεν επιτρέπει όλους τους δυνατούς συνδυασμούς. Κάθε δυνατός συνδυασμός καλύπτει τις ανάγκες μιας μεγάλης κατηγορίας εφαρμογών με κοινές ανάγκες. Για παράδειγμα, το DVD και η ψηφιακή δορυφορική τηλεόραση χρησιμοποιούν το κύριο προφίλ (Main Profile) με τα χαρακτηριστικά του βίντεο να αντιστοιχούν στο κύριο επίπεδο (Main Level). Επίπεδο/Όνομ α προφίλ Απλό Προφίλ Κύριο Προφίλ προφίλ κλιμάκωσης SNR όχι πλαίσια B μη κλιμακούμενο πλαίσια Β χωρικό προφίλ κλιμάκωσης Υψηλό προφίλ 04:02:00 04:02:02 κλιμακούμενο SNR χωρική κλιμάκωση υψηλό επίπεδο 80 Mbit/s 100 Mbit/s υψηλό επίπεδο Mbit/s 60 Mbit/s 80 Mbit/s κύριο επίπεδο 15 Mbit/s 15 Mbit/s 15 Mbit/s 20 Mbit/s χαμηλό επίπεδο 15 Mbit/s 15 Mbit/s Πίνακας 1: Προφίλ ποιότητας εικόνας του προωτοκόλλου MPEG-2 Όσον αφορά στον ήχο, το πρωτόκολλο MPEG-2 καθορίζει δύο νέα πρότυπα συμπίεσης με δυνατότητες πολυκαναλικού ήχου. Ο πρώτος αλγόριθμος συμπίεσης ονομάζεται MPEG -2 BC (MPEG-2 Backward Compatible) και καθορίζεται στο τρίτο κεφάλαιο του πρωτοκόλλου. Το όνομα του αλγορίθμου δεν είναι τυχαίο αλλά εκφράζει τη δυνατότητα που έχει ο συγκεκριμένος αλγόριθμος να είναι συμβατός με τον αλγόριθμο που καθορίστηκε στο MPEG 1. Το πρότυπο παρέχει συνολικά μέχρι πέντε κανάλια εύρους ζώνης (αριστερό, δεξιό, κεντρικό και δύο κανάλια

12 surround), συν ένα πρόσθετο κανάλι χαμηλής συχνότητας και μέχρι 7 κανάλια σχολιασμού πολλαπλών γλωσσών. Ο αλγόριθμος συμπίεσης επεκτείνει την κωδικοποίηση στερεοφωνικών και μονοφωνικών καναλιών με μισούς ρυθμούς δειγματοληψίας (16kHz, 22,05kHz και 24kHz), κάτι που βελτιώνει σημαντικά την ποιότητα στα 64 Kbit/s. ή λιγότερο ανά κανάλι. Το πρότυπο είναι καθοδικά συμβατό με το υπάρχον πρότυπο MPEG 1 Audio Standard. Το πρωτόκολλο επίσης καθορίζει και ένα ακόμα πρότυπο κωδικοποίησης στο έβδομο κεφάλαιο και το οποίο ονομάζεται Advanced Audio Coding. Οι λεπτομέρειες του AAC δεν υπήρχαν αρχικά στο MPEG 2 και προστέθηκαν πολύ αργότερα το Σεπτέμβρη του Το πρότυπο αυτό είναι πρακτικά πολύ καλύτερο τόσο από τα πρότυπα του MPEG 1 όσο και από το MPEG 2 BC ως προς τη δυνατότητα συμπίεσης των δεδομένων ενώ μπορεί να χειριστεί πολύ περισσότερα ρεύματα τόσο από το MPEG 1 όσο και από το MPEG 2 BC. Συγκεκριμένα, το πρότυπο αυτό επιτρέπει το χειρισμό μέχρι 48 καναλιών εύρους ζώνης και 16 πρόσθετων καναλιών χαμηλής συχνότητας ενώ παράλληλα επιτρέπει το χειρισμό υψηλότερων συχνοτήτων δειγματοληψίας σε σχέση με το MP3 (96kHz σε σχέση με 48kHz). Αλγοριθμικά, η μόνη διαφορά μεταξύ του AAC και του MPEG 1 είναι στον τρόπο εφαρμογής των διαφόρων φίλτρων, διαφορά η οποία επιτρέπει όμως στο AAC να έχει σε κάποιες περιπτώσεις έως και 50% καλύτερη συμπίεση. Στο πρωτόκολλο MPEG-2 επίσης παρουσιάζεται για πρώτη φορά και ένα πρότυπο για την ανάπτυξη καναλιών ελέγχου τόσο για ρεύματα MPEG-2 όσο και για ρεύματα MPEG-1. Το πρότυπο αυτό παρουσιάζεται στο έκτο κεφάλαιο του MPEG-2 και παρουσιάζει ένα μοντέλο client/server το οποίο χρησιμοποιεί για τη σύνδεσή του είτε το ρεύμα δεδομένων του MPEG είτε κάποιου άλλου ανεξάρτητου δικτύου. Η δυνατότητα αυτή αρχικά χρησιμοποιήθηκε για τον απομακρυσμένο έλεγχο της λήψης του βίντεο δίνοντας δυνατότητες παρόμοιες με αυτές ενός VCR (play, pause, fast-forward etc), στη συνέχεια όμως το πρότυπο επεκτάθηκε και τώρα περιλαμβάνει μία πληθώρα δυνατοτήτων όπως απομακρυσμένη κλήση συναρτήσεων (RPC), κατέβασμα προγραμμάτων κ.α. Η αρχιτεκτονική του προτύπου περιλαμβάνει 3 οντότητες: τον πελάτη, τον εξυπηρετητή, και το διαχειριστή πόρων (Session Resource Manager). Σε μια γενική άποψη του πως αλληλεπιδρούν μεταξύ τους αυτές οι τρεις οντότητες μπορούμε να πούμε ότι ο εξυπηρετητής παρέχει κάποιες υπηρεσίες στον πελάτη, ενώ και οι δύο είναι πελάτες στον SRM. Το SRM με τη σειρά του είναι υπεύθυνο για την κατανομή και διαχείριση των πόρων του δικτύου στους πελάτες. Το πρότυπο που παρουσιάζεται στο MPEG δίνει αρκετές δυνατότητες προς υλοποίηση από κάποια εφαρμογή, οι οποίες όμως δεν της είναι όλες απαραίτητες για να είναι λειτουργική και είναι θέμα της εφαρμογή ποιες δυνατότητες χρειάζεται να αναπτύξει. Γενικά το DSM-CC αναπτύσσει πέντε βασικά πρωτόκολλα επικοινωνίας: Χρήστη με Χρήστη: Το πρωτόκολλο αυτό καθορίζει τις λεπτομέρειες υλοποίησης της δυνατότητας απομακρυσμένης πρόσβασης από τον πελάτη στα αντικείμενα του εξυπηρετητή. Χρήστη με Δίκτυο: Το πρωτόκολλο αυτό αφορά την επικοινωνία των πελατών και των εξυπηρετητών με το SRM. Χρησιμοποιείται για τη δέσμευση δικτυακών πόρων και τη συσχέτιση των πόρων με κάποια συνεδρία. προφίλ μετάδοσης MPEG: Το πρωτόκολλο αυτό καθορίζει κάποια προφίλ για τη μετάδοση των διαφόρων μηνυμάτων DSM-CC. Download: Το πρωτόκολλο αυτό, με διάφορες διαφοροποιήσεις, καθορίζει τις λεπτομέρειες της μεταφοράς δεδομένων από τον εξυπηρετητή σε κάποιο πελάτη, είτε μέσω του υπάρχοντος ρεύματος δεδομένων του MPEG, είτε μέσω κάποιου ξεχωριστού διαύλου. Switched Digital Broadcast Channel Change Protocol (SDB/CCP): Το πρωτόκολλο αυτό καθορίζει τις λεπτομέρειες για τη δυνατότητα αλλαγής καναλιού λήψης για το ρεύμα δεδομένων του MPEG. Το πρωτόκολλο αυτό επιτρέπει στον εξυπηρετητή να γνωρίζει ποιοι πελάτες λαμβάνουν δεδομένα σε κάθε κανάλι και είναι αρκετά χρήσιμο στην περίπτωση υπηρεσιών pay-per-view.

13 2.2.3 MPEG System Το MPEG 2 όπως είδαμε και παραπάνω καθορίζει ένα πρότυπο για την πολύπλεξη ενός ή περισσοτέρων στοιχειωδών ρευμάτων ήχου και βίντεο, καθώς και άλλων δεδομένων, μιας παρουσίασης σε ένα ή περισσότερα ρεύματα κατάλληλα για αποθήκευση ή μετάδοση [4]. Οι λεπτομέρειες για τον τρόπο λειτουργίας της πολύπλεξης του MPEG 2 καθορίζονται στο πρώτο κεφάλαιο του πρωτοκόλλου. Η χρήση του προτύπου MPEG 2 για την πολύπλεξη δε απαιτεί η κωδικοποίηση ή η συμπίεση των δεδομένων των ρευμάτων να έχει γίνει σύμφωνα με το πρότυπο του MPEG 2 αλλά μπορεί να έχει χρησιμοποιηθεί οποιοσδήποτε συμβατός αλγόριθμος συμπίεσης. Τη δυνατότητα αυτή χρησιμοποιούμε εκτενώς και στην παρούσα εφαρμογή, καθώς η συμπίεση του ρεύματος βίντεο γίνεται με βάση το πρότυπο H.264 το οποίο είναι νεότερο του MPEG 2 και μας δίνει καλύτερη ποιότητα εικόνας σε χαμηλότερο ρυθμό μετάδοσης, με μεγαλύτερες όμως από την άλλη πλευρά απαιτήσεις σε CPU. Η διαδικασία πολύπλεξης των επί μέρους ρευμάτων ακολουθεί μια στρωματική προσέγγιση δύο επιπέδων και παρουσιάζεται διαγραμματικά στην εικόνα 2. Στην πρώτη φάση της διαδικασίας πολύπλεξης του MPEG 2, το σύστημα παράγει ένα ρεύμα πακέτων που ονομάζεται συσκευασμένο στοιχειώδες ρεύμα (Packetized Elementary Stream) για κάθε στοιχειώδες ρεύμα δεδομένων (Elementary Stream). Σε γενικές γραμμές ένα στοιχειώδες ρεύμα είναι ένα ρεύμα συμπιεσμένου ήχου, εικόνας ή και απλών δεδομένων. Συνήθως, προκύπτει από την έξοδο κάποιου κωδικοποιητή και τα δεδομένα είναι αποκλειστικά ενός τύπου. Τα Στοιχειώδη ρεύματα που αφορούν ήχο ή εικόνα γενικά είναι οργανωμένα σε μονάδες πρόσβασης (access units). Μία μονάδα πρόσβασης αναπαριστά μία θεμελιώδη μονάδα κωδικοποίησης. Κάτι τέτοιο για το ρεύμα βίντεο μπορεί να είναι ένα πλαίσιο, ενώ για το ρεύμα ήχου μπορεί να είναι κάποια κομμάτι δεδομένης διάρκειας. Εικόνα 2: MPEG -2 System Κάθε Elementary stream καταλήγει σε ένα MPEG 2 επεξεργαστή ο οποίος συγκεντρώνει τα δεδομένα και δημιουργεί το συσκευασμένο στοιχειώδες ρεύμα (Packetized Elementary Stream). Το ρεύμα PES είναι μία λογική κατασκευή που είναι χρήσιμη μόνο στις υλοποιήσεις του πρωτοκόλλου

14 και δεν μπορεί να χρησιμοποιηθεί για τη μετάδοση ή αποθήκευση ενός μέσου. Το κάθε πακέτο PES, που προκύπτει από τον επεξεργαστή, μπορεί να ποικίλει ως προς το μέγεθος αλλά δε μπορεί να είναι μεγαλύτερο από 65 Kb, ενώ περιλαμβάνει και μία επικεφαλίδα 8 byte τουλάχιστον. Η δομή ενός PES πακέτου εμφανίζεται στην εικόνα 3. Η επικεφαλίδα του αποτελείται από τα εξής πεδία: Start Code: Το πρώτα 3 bytes ενός πακέτου PES είναι ίδια για κάθε πακέτο και χρησιμοποιούνται για να καθορίσουν την αρχή του πακέτου. Η τιμή λοιπόν αυτή για κάθε πακέτο είναι 0x Stream ID: Το stream_id πεδίο ενός πακέτου PES περιγράφει το στοιχειώδες ρεύμα στο οποίο ανήκουν τα περιεχόμενο του πακέτου. Γενικά ισχύει ότι οι κωδικοί που αρχίζουν από 110x xxxx αντιστοιχούν σε ρεύματα ήχου, οι κωδικοί 1110 xxxx αντιστοιχούν σε video και ο κωδικός αντιστοιχεί σε πακέτο ελέγχου του ρεύματος, όπως περιγράφεται στο έκτο κεφάλαιο του MPEG 2 για το DSM-CC. PES_packet_length: Το πεδίο αυτό έχει μέγεθος 16 bit και καθορίζει τον αριθμό bytes που αποτελούν το πακέτο. Το μέτρημα των bytes ξεκινά μετά από το τελευταίο bit του πεδίου αυτού. Μια ειδική περίπτωση για το πεδίο είναι η τιμή 10, που αντιστοιχεί στην περίπτωση στην οποία το πακέτο δεν έχει συγκεκριμένο μέγεθος, και επιτρέπεται μόνο σε PES πακέτα τα οποία προκύπτουν από κάποιο στοιχειώδες ρεύμα βίντεο και πρόκειται να μετασχηματιστούν σε ρεύμα μεταφοράς. PES Scrambling Control(PSC): Το πεδίο αυτό έχει μέγεθος 2 bit και καθορίζει αν το πακέτο μας είναι κρυπτογραφημένο ή όχι. Η κρυπτογράφηση αφορά μόνο το επίπεδο του ρεύματος του PES και δεν καθορίζει τι θα γίνει στα επόμενα επίπεδα. Η κρυπτογράφηση εφαρμόζεται μόνο στα δεδομένα του πακέτου και όχι στην επικεφαλίδα του. Η τιμή 00 του πεδίου καθορίζει ότι το πακέτο δεν έχει κρυπτογραφηθεί, ενώ οι υπόλοιπες τιμές αφήνουν ελεύθερη την ερμηνεία τους στην υλοποίηση του πρωτοκόλλου. PES Priority (PP): Το πεδίο αυτό καθορίζει τη προτεραιότητα του πακέτου και έχει μέγεθος ένα bit. Μία τιμή 1 σημαίνει ότι το πεδίο έχει υψηλότερη προτεραιότητα. Η ερμηνεία της τιμής του πεδίου χρησιμοποιείται από τον αποπλέκτη του συστήματος κατά τη δημιουργία του θεμελιώδους ρεύματος. Data Alignment Indicator (DAI) : Το πεδίο αυτό έχει μέγεθος 1 bit και καθορίζει αν το περιεχόμενο του πακέτου ξεκινά με το start code του video μας ή το syncword του ρεύματος ήχου. Copyright Information (CI): Το πεδίο αυτό έχει μέγεθος 1 bit και καθορίζει αν το περιεχόμενο του ρεύματος προστατεύεται από κάποιο copyright. Η περιγραφή του copyright περιλαμβάνεται σε ειδικούς πίνακες που μπορεί να χρησιμοποιεί μία εφαρμογή για να επεκτείνει τις δυνατότητες του MPEG 2 πρωτοκόλλου. Οriginal Or Copy: Το πεδίο αυτό καθορίζει αν το περιεχόμενο του ρεύματος πακέτων είναι το πρωτότυπο ή κάποιο αντίγραφο ενός αρχικού ρεύματος. Η τιμή 1 αντιστοιχεί στην περίπτωση που το ρεύμα είναι το πρωτότυπο και η τιμή 0 στην περίπτωση που το ρεύμα είναι αντίγραφο. PTS DTS flags: Το πεδίο αυτό έχει μέγεθος 2 bit και καθορίζει αν στο πακέτο περιέχονται πληροφορίες για το πότε θα πρέπει να γίνει η αποπολύπλεξη και η αναπαραγωγή του πακέτου. Οι πληροφορίες αυτές περιλαμβάνονται σε ειδικά πεδία του πακέτου, τα οποία βρίσκονται μετά από την επικεφαλίδα του πακέτου και πριν τα δεδομένα. Τα πεδία αυτά είναι το Presentation Time Stamp (PTS), το οποίο αφορά το χρόνο αναπαραγωγής και το Decoding Time Stamp (DTS), το οποίο αφορά το χρόνο αποκωδικοποίησης των δεδομένων. Έχουν μέγεθος 33 bit και καθορίζουν το χρόνο με βάση το ρολόι του συστήματος, το οποίο χρησιμοποιεί ως μονάδα μέτρησης το 1/90000 sec -1. Επίσης, το πρωτόκολλο καθορίζει ότι στο αρχικό πεδίο δε μπορεί να έχουμε τιμή 01, δηλαδή δε μπορούμε να έχουμε ένα πεδίο DTS και να μην έχουμε ένα πεδίο PTS. ESCR flag: Το πεδίο αυτό καθορίζει αν το πακέτο περιέχει κάποιο πεδίο ESCR. Το πεδίο ESCR περιλαμβάνεται μεταξύ της επικεφαλίδας και των δεδομένων του πακέτου και καθορίζει το χρόνο μέσα στον οποίο θα πρέπει να έχει φτάσει το τελευταίο bit στην είσοδο του αποκωδικοποιητή του ρεύματος.

15 ES Rate flag: Η σημαία αυτή καθορίζει αν στο πακέτο μας περιλαμβάνεται, μετά το τέλος της επικεφαλίδας, ο ρυθμός αποστολής δεδομένων του ρεύματος ES. Ο ρυθμός αποστολής εκφράζεται από έναν ακέραιο 22 bit, ο οποίος έχει ως μονάδα μέτρησης τα 50 bytes/sec. Η τιμή αυτή αποθηκεύεται από το σύστημα και ισχύει μέχρι την αποστολή της επόμενης τιμής. DSM Trick Mode Flag: Πρόκειται για μα σημαία, η οποία καθορίζει την ύπαρξη ενός πεδίου trick mode μετά το τέλος της επικεφαλίδας. Το πεδίο trick mode καθορίζει το ρυθμό αναπαραγωγής του βίντεο. Copyright Information Flag: Η σημαία αυτή καθορίζει ότι μετά το τέλος της επικεφαλίδας περιλαμβάνεται ένα πεδίο με πληροφορίες για τα δικαιώματα χρήσης του περιεχομένου του ρεύματος. PES CRC flag: Η σημαία αυτή καθορίζει ότι το πακέτο αυτό περιέχει τον CRC κωδικό του προηγούμενου πακέτου. Με τον κωδικό αυτό ο παραλήπτης μπορεί να ελέγξει τυχόν σφάλματα μετάδοσης και να τα διορθώσει. PES Extension Flag: Η σημαία αυτή καθορίζει αν το ρεύμα περιλαμβάνει ένα extra πεδίο μετά την επικεφαλίδα του πακέτου, το οποίο περιλαμβάνει διάφορες πληροφορίες για το πακέτο PES_packet_Length Start Code PSC P P D A I rest of options and data C I O C PTS DTS Εικόνα 3: Επικεφαλίδα Packetised Elementary Stream E S C R E S R Stream ID T R I C K C I C R C P E S E I Στη δεύτερη φάση της διαδικασίας πολύπλεξης τα πακέτα PES συνδυάζονται σε ένα ή περισσότερα ρεύματα προγράμματος (Program Stream) ή σε ένα ρεύμα μεταφοράς (Transport Stream). Τα δύο αυτά ρεύματα αναπτύχθηκαν για να καλύψουν αντίστοιχα τις ανάγκες δύο μεγάλων ομάδων γνωστών ή αναπτυσσόμενων εφαρμογών. Έτσι ενσωματώνουν ένα μεγάλο βαθμό ευελιξίας ενώ ταυτόχρονα επιβεβαιώνουν ότι υπάρχει διαλειτουργικότητα ανάμεσα σε διάφορες υλοποιήσεις συσκευών. Το ρεύμα προγράμματος (Program Stream) του MPEG-2 είναι ανάλογο του στρώματος συστήματος (system layer) του MPEG 1. Το αποτέλεσμά του είναι ο συνδυασμός ενός ή περισσοτέρων ρευμάτων PES πακέτων με κοινό μετρητή χρόνο σε ένα και μοναδικό ρεύμα. Αυτό το ρεύμα δεδομένων χρησιμοποιείται συνήθως σε περιβάλλοντα σχετικά με πολύ μικρή πιθανότητα σφάλματος και είναι κατάλληλο για εφαρμογές που ασχολούνται με επεξεργασία των πληροφοριών του ρεύματος όπως διαδραστικές πολυμεσικές εφαρμογές. Τα πακέτα ρεύματος προγράμματος είναι μεταβλητού μεγέθους. Σε αυτά συνήθως περιλαμβάνονται πληροφορίες χρονισμού οι οποίες χρησιμοποιούνται για να καθορίσουν από το σύστημα μια σταθερή καθυστέρηση κατή τη μεταφορά των πακέτων από την είσοδο του κωδικοποιητή στην έξοδο του αποκωδικοποιητή. Ένα πακέτο ρεύματος προγράμματος αποτελείται από πολλά επιμέρους πακέτα PES τα οποία έχουν κοινό χρόνο. Γενικά η δομή ενός πακέτου του ρεύματος προγράμματος εμφανίζεται και στην εικόνα 4. Βλέπουμε ότι κάθε πακέτο αποτελείται από μία επικεφαλίδα και διάφορα PES πακέτα. Η επικεφαλίδα έχει μέγεθος 15 bytes και αποτελείται από τα εξής πεδία: pack start code: Το πεδίο αυτό έχει μέγεθος 4 byte και είναι μια σταθερά που καθορίζει την αρχή ενός πακέτου ρεύματος προγράμματος.

16 System Clock Reference: Το πεδίο αυτό έχει μέγεθος 42 bit και χρησιμοποιείται από το πρότυπο για τον καθορισμό του χρόνου κατά τον οποίο θα πρέπει το τελευταίο bit του πακέτου να έχει φτάσει στην είσοδο του αποκωδικοποιητή. Program Mux Rate: Πρόκειται για ένα πεδίο 22 bit το οποίο καθορίζει το ρυθμό πολύπλεξης που είχε το σύστημα κατά την επεξεργασία του πακέτου. Το πεδίο αυτό χρησιμοποιεί ως μονάδα μέτρησης τα 50 bytes/second. Pack Stuffing Length & Stuffing Byte: Το πεδίο Pack Stuffing Length έχει μέγεθος 3 bit και καθορίζει τον αριθμό bit που περιλαμβάνει το πεδίο Stuffing Byte. Το πεδίο αυτό χρησιμοποιείται από τον κωδικοποιητή για την τροποποίηση του πακέτου ώστε να καλύπτει τις ανάγκες του καναλιού μετάδοσης του πακέτου. Τα πεδία αυτά μπορούν να χρησιμοποιηθούν από το σύστημα για παράδειγμα για να στρογγυλοποιήσουν το μέγεθος του πακέτου ώστε το μέγεθός του πακέτου σε bit να είναι πολλαπλάσιο του 8. Το πεδίο αυτό δε μπορεί να έχει κάποια ειδική ερμηνεία από το σύστημα και αφαιρείται από το πακέτο κατά την επεξεργασία του πακέτου από τον αποκωδικοποιητή. Marker Bit: Το πεδίο αυτό έχει μέγεθος 1 bit και χρησιμοποιείται από το σύστημα για τη στοίχιση των πεδίων του πακέτου. Η τιμή του είναι πάντα 1. System Header: Το πεδίο αυτό έχει μέγεθος 12 byte και περιλαμβάνει πληροφορίες που αφορούν τη λειτουργία του συστήματος. Η πληροφορία αυτή δεν περιλαμβάνεται σε κάθε πακέτο, αλλά εκπέμπεται ανά τακτά χρονικά διαστήματα από τον κωδικοποιητή pack start code ( ) 1 SCR mb SCR mb SCR mb SCR mb program mux rate mb mb reserved PSL stuffing byte system header... DATA... Εικόνα 4: Πακέτο Program System Το ρεύμα μετάδοσης (Transport Stream) συνδυάζει ένα η περισσότερα επί μέρους ρεύματα δεδομένων που βασίζονται σε ένα ή περισσότερους μετρητές χρόνου σε ένα και μοναδικό ρεύμα. Το ρεύμα μετάδοσης σχεδιάστηκε για χρήση σε περιβάλλοντα με μεγάλη πιθανότητα λάθους, όπως αποθήκευση ή μετάδοση σε περιβάλλοντα με θόρυβο. Γενικά το ρεύμα μεταφοράς μπορεί να χρησιμοποιηθεί σε πολλά επίπεδα σε μία εφαρμογή πολυμέσων που χρησιμοποιεί στρώμα, και έχει σχεδιαστεί για αποδοτική και εύκολη υλοποίηση του σε εφαρμογές που χρησιμοποιούν δίκτυα υψηλών ταχυτήτων. Γενικά το ρεύμα μετάδοσης σχεδιάστηκε για να μπορεί μια εφαρμογή να εκτελεί εύκολα κάποιες λειτουργίες. Κάποιες από αυτές τις λειτουργίες είναι: 1. Ανάκτηση ενός μόνο συγκεκριμένου συμπιεσμένου ρεύματος δεδομένων, από τα ρεύματα που περιλαμβάνει το ρεύμα μεταφοράς. 2. Εξαγωγή ενός μόνο συγκεκριμένου συμπιεσμένου ρεύματος δεδομένων, από τα ρεύματα που περιλαμβάνει το ρεύμα μεταφοράς, και δημιουργία νέου ρεύματος που θα περιλαμβάνει μόνο το ρεύμα αυτό. 3. Δημιουργία ενός ρεύματος μετάδοσης από ρεύματα προγράμματος για τη μετάδοση των πληροφοριών σε κάποιο περιβάλλον με σφάλματα και δημιουργία μετά από το ρεύμα

17 μετάδοσης των αρχικών ρευμάτων προγράμματος. Το ρεύμα μετάδοσης αποτελείται και αυτό από πακέτα. Το μέγεθός του κάθε πακέτου είναι σταθερό και είναι 188 byte ενώ περιλαμβάνεται και μία επικεφαλίδα μεγέθους 4 byte. Η δομή της επικεφαλίδας εμφανίζεται στην εικόνα 5 και αποτελείται από τα εξής πεδία. Sync Byte: Το πεδίο αυτό σηματοδοτεί την αρχή ενός πακέτου του ρεύματος μεταφοράς. Το μέγεθός του είναι 8 bit και η τιμή του είναι ίση με ' ' (0x47). Transport Error Indicator: Η σημαία αυτή καθορίζει ότι τα δεδομένα που μεταφέρει το πακέτο περιέχουν κάποιο σφάλμα. Το πεδίο αυτό αποκτά τιμή 1 από οντότητες εξωτερικές του επιπέδου του ρεύματος όταν αντιληφθούν ότι κάποιο σφάλμα συνέβη κατά την αποστολή των δεδομένων. Payload Unit Start Indicator: Η σημαία αυτή χρησιμοποιείται για να σηματοδοτήσει ότι το πακέτο περιέχει τα πρώτα byte κάποιου νέου πακέτου PSI ή PES. Transport Priority: Η σημαία αυτή καθορίζει την προτεραιότητα πακέτου ανάμεσα στα πακέτα του ίδιου ρεύματος προγράμματος. Μία τιμή 1 καθορίζει μεγάλη προτεραιότητα για τα δεδομένα του πακέτου και μπορεί να χρησιμοποιηθεί από τον αποκωδικοποιητή του συστήματος για τη διαχείριση των δεδομένων ενός στοιχειώδους ρεύματος. PID: Το πεδίο αυτό έχει μέγεθος 13 bit και καθορίζει το είδος των δεδομένων που μεταφέρει το πακέτο. Η τιμή του πεδίου αυτού μπορεί να χρησιμοποιηθεί σε συνεργασία με τους πίνακες του ρεύματος για να καθοριστεί σε ποιο ακριβώς στοιχειώδες ρεύμα αντιστοιχούν τα δεδομένα που μεταφέρει το πακέτο. Transport Scrambling Control: Το πεδίο αυτό έχει μέγεθος 2 bit και χρησιμοποιείται για να καθοριστεί αν τα δεδομένα του πακέτου είναι κρυπτογραφημένα ή όχι. Η κρυπτογράφηση αφορά αποκλειστικά και μόνο τα δεδομένα του πακέτου και σε καμία περίπτωση την επικεφαλίδα. Adaptation Field Control: Το πεδίο αυτό έχει μέγεθος 2 bit και καθορίζει τί ακριβώς περιλαμβάνεται μετά το τέλος της επικεφαλίδας. Το πρώτο bit καθορίζει αν μετά το τέλος της επικεφαλίδας περιλαμβάνεται ένα πεδίο adaptation. Το πεδίο adaptation έχει μεταβλητό μέγεθος και περιλαμβάνει διάφορες πληροφορίες. Ένα από τα πιο σημαντικά πεδία είναι το PCR (Program Clock Reference) με βάση το οποίο η εφαρμογή μας καθορίζει τα σημεία στα οποία θα πρέπει να γίνει αλλαγή κλειδιού κρυπτογράφησης. Το δεύτερο bit του πεδίου καθορίζει αν τα πακέτο περιέχει δεδομένα ή είναι κενό. Continuity Counter: Το πεδίο αυτό είναι ένας μετρητής 4 bit ο οποίος αυξάνεται κατά ένα κάθε φορά που αποστέλλεται ένα νέο πακέτο με κάποιο συγκεκριμένο PID. Το πεδίο αυτό μπορεί να χρησιμοποιηθεί για την ανακάλυψη τυχόν σφαλμάτων αποστολής. Το ρεύμα προγράμματος και το ρεύμα μετάδοσης έχουν σχεδιαστεί για διαφορετικά είδη εφαρμογών. Είναι δυνατόν και λογικό να μπορούμε να μετατρέψουμε ένα είδος ρεύματος σε κάποιο άλλο καθώς το ένα ρεύμα δεν είναι υποσύνολο του άλλου. Για τη μετατροπή των ρευμάτων μια εφαρμογή μπορεί να χρησιμοποιήσει την κοινή δομή των PES πακέτων. Βέβαια, οι πληροφορίες που περιέχονται σε ένα πακέτο του ρεύματος προγράμματος δεν είναι δυνατόν να αποκτηθούν άμεσα από τις πληροφορίες των επικεφαλίδων των πακέτων ρεύματος μετάδοσης, αλλά μπορούν να δημιουργηθούν από κάποια περαιτέρω επεξεργασία των πακέτων.

18 sync_byte T E I P U S I T P T P DATA... DATA Εικόνα 5: Πακέτο Transport Stream PID TSC AFC CC Στο πρώτο κεφάλαιο του πρωτοκόλλου MPEG-2 ιδιαίτερη μνεία γίνεται και για τον συγχρονισμό των διαφόρων ρευμάτων. Η λειτουργία αυτή είναι αρκετά σημαντική αφενός για τη σωστή αναπαραγωγή των παρουσιάσεων, αλλά παράλληλα η εφαρμογή μας χρησιμοποιεί τις πληροφορίες χρονισμού που μεταδίδονται για τον υπολογισμό των χρονικών στιγμών κατά τις οποίες οι πελάτες θα πρέπει να να ζητήσουν το επόμενο κλειδί κρυπτογράφησης. Για το συγχρονισμό των επιμέρους ρευμάτων κάθε υλοποίηση του πρωτοκόλλου θέτει κάποια μέγιστα κατώφλια για τη μετάδοση και ανάκτηση πακέτων, τόσο του ρεύματος του προγράμματος, όσο και του ρεύματος μεταφοράς. Συγκεκριμένα, το κατώφλι θα πρέπει να καθορίζει το μέγιστο επιτρεπτό χρόνο που απαιτείται για τη συμπίεση του ρεύματος, την τοπική αποθήκευση, την πολύπλεξη, τη μετάδοση ή την αποθήκευση, την αποπολύπλεξη, την αποκωδικοποίηση και την αναπαραγωγή του ρεύματος. Για το λόγο αυτό λοιπόν το πρωτόκολλο καθορίζει ότι σε κάθε τύπου πακέτου θα πρέπει περιλαμβάνονται πληροφορίες που αφορούν χρόνο και οι οποίες χρησιμοποιούνται για τον υπολογισμό της καθυστέρησης από άκρη σε άκρη. Ο υπολογισμός των χρόνων γίνεται με τη βοήθεια ενός κοινού συστήματος μέτρησης χρόνου, το οποίο ονομάζεται Ρολόι Συστήματος (System Time Clock). Με βάση αυτό το ρολόι το πρωτόκολλο εισάγει σε κάθε πακέτο PES ένα πεδίο Σφραγίδας Χρόνου Παρουσίασης (Presentation Time Stamps). Οι σφραγίδες αυτές καθορίζουν το χρόνο αναπαραγωγής ενός πακέτου με βάσει ένα ρολόι παλμών 90 khz. Όπως είδαμε και παραπάνω το πρωτόκολλο αναπτύσσει περαιτέρω τα όρια μετάδοσης δεδομένων εισάγοντας κάποια extra πεδία στα πακέτα των ρευμάτων, τα οποία καθορίζουν επακριβώς τους χρόνους που θα πρέπει να φτάσουν τα δεδομένα στο κάθε επίπεδο του πρωτοκόλλου. Έτσι λοιπόν έχουμε το πεδίο αναφοράς Ρολογιού προγράμματος (Program Clock Reference) και το προαιρετικό πεδίο Αναφοράς Ρολογιού Στοιχειώδους Ρεύματος (Elementary Stream Clock Reference) για το ρεύμα προγράμματος και το πεδίο Αναφοράς Ρολογιού Συστήματος (System Clock Reference) για το ρεύμα μεταφοράς. Τα πεδία αυτά καθορίζουν το μέγιστο επιτρεπτό χρόνο που μπορεί να κάνει το πακέτο μέχρι την είσοδό του στον αποκωδικοποιητή.

19 2.3 Digital Video Broadcast Common Scrambling Algorithm Στο κεφάλαιο αυτό θα παρουσιάσουμε το σύστημα ασφαλείας που αναπτύξαμε για το CDN. Η ανάπτυξη ενός τέτοιου συστήματος είναι αναγκαία για οποιαδήποτε εφαρμογή ψηφιακής τηλεόρασης, αφού συνήθως οι εταιρίες συνδρομητικής τηλεόρασης επιθυμούν να έχουν κάποιο επίπεδο ελέγχου ώστε να επιτρέπουν μόνο στους εγγεγραμμένους χρήστες να παρακολουθούν στο ποιός θα παρακολουθήσει τα προγράμματά τους. Το σύστημα ασφάλειας εφαρμόζει, σε γενικές γραμμές, έναν αλγόριθμο κρυπτογράφησης δύο επιπέδων στα δεδομένα της ταινίας που μοιράζει ο streamer, ενώ παράλληλα μοιράζει το κλειδί αποκρυπτογράφησης μόνο στους εγγεγραμμένους χρήστες της υπηρεσίας. Με τη μέθοδο αυτή επιτρέπεται η παρακολούθηση του προγράμματος μόνο από τους χρήστες που θα χρεωθούν. Για την κρυπτογράφηση του ρεύματος δεδομένων επιλέχθηκε ο αλγόριθμος CSA, o οποίος έχει αναπτυχθεί από την επιτροπή DVB και χρησιμοποιείται σχεδόν από όλα τα σύγχρονα συστήματα δορυφορικής τηλεόρασης. Πρόκειται για έναν αλγόριθμο αρκετά γρήγορο και με χαμηλές απαιτήσεις, ιδανικό για την κρυπτογράφηση δεδομένων πραγματικού χρόνου DVB Conditional Access Ο αλγόριθμος DVB CSA είναι κομμάτι της πλατφόρμας ψηφιακής τηλεόρασης DVB, η οποία αναπτύσσεται από τον οργανισμό Digital Video Broadcast Project. Το DVB Project είναι ένα consortium εμπορικών εταιριών με πάνω από 270 μέλη από όλο τον κόσμο. Η έρευνα του οργανισμού προσανατολίζεται στην ανάπτυξη προτύπων για όλα τα θέματα που μπορεί να αφορούν τη μετάδοση ψηφιακής τηλεόρασης, καθώς και την ανάπτυξη νέων υπηρεσιών σε αυτήν. Η έρευνα στο DVB οργανώνεται με βάση τα θέματα που μελετώνται (modules) και τις ομάδες εργασίας. Τα αποτελέσματα κάθε ομάδας κατατίθενται στην επιτροπή Steering, η οποία είναι το ανώτατο όργανο του project και αποφασίζει τί πρόκειται να εκδοθεί ως επίσημο standard. Τη στιγμή αυτή το project έχει περισσότερες από 30 ομάδες, οι οποίες μελετούν διάφορες πτυχές της ψηφιακής τηλεόρασης και των προεκτάσεών της, καθώς και τις νομικές διαδικασίες που είναι αναγκαίες για την κατοχύρωση των δικαιωμάτων από τα πρωτόκολλα που εκδίδονται. Ο αλγόριθμος CSA χρησιμοποιείται από μια προέκταση του DVB, το Conditional Access module, που αναπτύχθηκε από την επιτροπή για τη διαχείριση και μετάδοση κρυπτογραφημένου σήματος. Η διαχείριση κρυπτογραφημένου σήματος είναι αρκετά σημαντική για την επιτροπή, καθώς ένας μεγάλος αριθμός των μελών της είναι εταιρίες παροχής συνδρομητικής τηλεόρασης και εταιρίες κατασκευής συσκευών διανομής συνδρομητικής τηλεόρασης, με αποτέλεσμα να είναι αναγκαία η ανάπτυξη κοινά αποδεκτών προτύπων κρυπτογράφησης για τη σωστή διανομή του σήματος. Εξάλλου, είναι φυσικό υπηρεσίες ψηφιακής τηλεόρασης να παραχωρούνται μόνο επί πληρωμή ή να μη διανέμονται ελεύθερα στο κοινό. Το κομμάτι του conditional access, λοιπόν, περιλαμβάνει πολλά υποπεδία για τον έλεγχο πρόσβασης στο σήμα, όπως το μηχανισμό κωδικοποίησης και αποκωδικοποίησης του σήματος, το μηχανισμό διαχείρισης πελατών, το μηχανισμό πιστοποίησης πελατών κ.α. Δυστυχώς, πολλά από το κομμάτια του Conditional Access μέχρι στιγμής δεν έχουν προτυποποιηθεί, όπως το κομμάτι της Subscriber Managment System (SMS) και του Subscriber Authorization System (SAS) και η κάθε εταιρία ακολουθεί μια δικιά της προσέγγιση. Η μη προτυποποίηση αυτού του κομματιού του DVB συνέβη εξαιτίας του ότι οι εταιρίες του consortium είχαν ήδη αναπτύξει κάποιες λύσεις όταν ξεκίνησαν την έρευνα για τα συγκεκριμένα ζητήματα, ενώ οι περισσότερες λύσεις που προτείνονταν είχαν μεγάλες αποκλείσεις μεταξύ τους με αποτέλεσμα να είναι οικονομικά ασύμφορη η μεταπήδηση σε κάποια άλλη προσέγγιση. Επίσης, πολλά μέλη του consortium είναι αρνητικά στην ανάπτυξη προτύπων για τα συστήματα διαχείρισης πελατών καθώς θεωρούν ότι κάτι τέτοιο ελοχεύει πολλούς κινδύνους για την ασφάλεια των συστημάτων τους. Σε ένα κλασσικό σύστημα συνδρομητικής ψηφιακής τηλεόρασης ο εξυπηρετητής και οι πελάτες έχουν αμφίδρομη επικοινωνία μεταξύ τους. Η επικοινωνία βέβαια μπορεί να μη γίνεται μέσα από το ίδιο κανάλι επικοινωνίας. Στην περίπτωση της δορυφορικής τηλεόρασης, για παράδειγμα, η αποστολή σημάτων από τον πελάτη στον εξυπηρετητή μέσω της δορυφορικής είναι

20 αδύνατη και οικονομικά ασύμφορη. Για αυτόν το λόγο πολλές φορές επιλέγεται κάποιος άλλος δίαυλος επικοινωνίας, όπως το τηλεφωνικό δίκτυο. Οι πελάτες, συνήθως, για να παρακολουθήσουν ένα πρόγραμμα θα πρέπει να εγγραφούν και να αυθεντικοποιηθούν από τον εξυπηρετητή. Από εκεί και πέρα η υλοποίηση της ασφάλειας διαφέρει από υλοποίηση σε υλοποίηση. Η επικοινωνία στη συνέχεια της διαδικασία αυτής βασίζεται σε μηνύματα DSM CC, τα οποία παρουσιάσαμε περιληπτικά στο κεφάλαιο 3. Τα μηνύματα αυτά αποστέλλονται σαν πακέτα του ρεύματος TS και μπορούν να επεκταθούν από το κάθε σύστημα και να αποκτήσουν πρόσθετη λειτουργικότητα. Για την αντιμετώπιση του προβλήματος διαλειτουργικότητας του συστήματος ασφαλείας των διαφόρων πλατφόρμων ψηφιακής τηλεόρασης, η επιτροπή έχει προτείνει δύο λύσεις: το SimulCrypt και το MultiCrypt. Η πρώτη προσέγγιση, το SimulCrypt, μεταφέρει την επίλυση του προβλήματος στους προμηθευτές ψηφιακής τηλεόρασης. Ο προμηθευτής θα πρέπει να μεταδίδει τις αναγκαίες πληροφορίες διαχείρισης του DVB-CA πολλές φορές, έτσι ώστε να καλύπτεται κάθε δυνατή περίπτωση υλοποίησης του CA. Για τη λύση αυτή, καθορίζεται ένα κοινό συντακτικό για τα μηνύματα του CA και χρησιμοποιείται ο κοινός αλγόριθμος κρυπτογράφησης CSA για το ρεύμα των πολυμέσων. Έτσι, για παράδειγμα, σε κάθε νέο αίτημα του παροχέα για αλλαγή κλειδιού κρυπτογράφησης, ο παροχέας θα πρέπει να μεταφράζει το αίτημα ώστε να είναι αντιληπτό από κάθε υλοποίηση και να το αποστέλλει μέσω του ρεύματος μεταφοράς του MPEG. Η υλοποίηση αυτή, βέβαια, όπως γίνεται αντιληπτό, επιβάλλει μεγάλη σπατάλη bandwidth από τη σύνδεση του παροχέα με του πελάτες, ενώ παράλληλα αντιμετωπίζει προβλήματα επεκτασιμότητας. Από την άλλη πλευρά, βέβαια, αποτελεί μια αρκετά καλή λύση χαμηλού κόστους. Η δεύτερη προσέγγιση που προτάθηκε από την ομάδα ανάπτυξης του DVB ήταν το MultiCrypt. Το MultiCrypt παρουσιάζει μία λύση από την πλευρά του πελάτη. Η προσέγγιση αυτή προτείνει τη δημιουργία ενός ενδιάμεσου σταδίου επεξεργασίας των μηνυμάτων CA στον αποκωδικοποιητή, το οποίο θα μπορεί να λάβει μηνύματα μίας συγκεκριμένης υλοποίησης και να τα μεταφράσει σε κάποια άλλη συγκεκριμένη. Το ενδιάμεσο αυτό στάδιο θα υλοποιείται με τη βοήθεια κάποιας αποσπόμενης κάρτας, η οποία θα αντιστοιχεί σε μία δεδομένη μετάφραση υλοποιήσεων. Η λύση όμως αυτή εμφανίζει πολλά μειονεκτήματα, καθώς μια τέτοια κάρτα έχει αρκετά υψηλό κόστος, ενώ μέχρι στιγμής οι κάρτες που πωλούνται στο εμπόριο χρησιμοποιούν ένα πολύ μικρό υποσύνολο από τις δυνατότητες που έχουν οι αποκωδικοποιητές. Η επιτροπή παράλληλα ανέπτυξε και ένα πρωτόκολλο για την προτυποποίηση της επικοινωνίας του CA με το υπόλοιπο σύστημα αποκωδικοποίησης στην περίπτωση του Multicrypt. Τη δουλειά αυτή αναλαμβάνει το module DVB Common Interface, το οποίο καθορίζει μία διεπαφή για τη διαχείριση κωδικοποιημένου σήματος. Οι λεπτομέρειες της διεπαφής αυτής καθορίζονται στο [6].Το module αυτό θεωρεί κάποια γενικά αποδεκτή δομή για τον αποκωδικοποιητή του πελάτη και καθορίζει 2 βασικές διεπαφές: τη διεπαφή μεταφοράς ρεύματος δεδομένων και τη διεπαφή χειρισμού. Η διεπαφή μεταφοράς δεδομένων διαχειρίζεται τα πακέτα που λαμβάνει το σύστημα. Το σύστημα καθορίζει στη διεπαφή ποια ρεύματα δεδομένων θέλει να λάβει και η διεπαφή δίνει στο υπόλοιπο ρεύμα τα πακέτα δεδομένων αποκρυπτογραφημένα Common Scrambling Algorithm Ο αλγόριθμος CSA παρουσιάστηκε αρχικά από το Electronical Telecommunication Standards Institute (ETSI) και υιοθετήθηκε από το DVB το Μάιο του Η επιτροπή κρατάει ακόμα και σήμερα τις λεπτομέρειες της υλοποίησης μυστικές, με συμφωνίες που υπογράφονται από το κάθε μέλος της οργάνωσης και απαγορεύει την υλοποίηση των αλγορίθμων σε επίπεδο λογισμικού. Η μόνη γνώση που υπήρχε για χρόνια για τον αλγόριθμο ήταν από τεχνικές αναφορές του ETSI και κάποιες λεπτομέρειες από την καταχώρηση της πατέντας. Η κατάσταση αυτή άλλαξε το φθινόπωρο του 2002 όταν εμφανίστηκε το πρόγραμμα FreeDec. Το πρόγραμμα αυτό υλοποιούσε τον αλγόριθμο CSA σε λογισμικό. Σε μικρό χρονικό διάστημα το πρόγραμμα ερευνήθηκε μέσω αντίστροφης μηχανικής και ο αλγόριθμος σύντομα κατανοήθηκε πλήρως. Μετά από αυτήν την εξέλιξη, η DVB αναγκάστηκε και εξέδωσε την περιγραφή του αλγορίθμου [7]. Η υλοποίηση του αλγορίθμου CSA που χρησιμοποιήσαμε, έγινε σε επίπεδο λογισμικού και έδωσε πολύ καλά αποτελέσματα. Οι δοκιμές που έγιναν σε ένα φορητό υπολογιστή με επεξεργαστή

21 AMD Turion στα 1800 MHz με μνήμη 512 Mb έδειξαν μικρή επιβάρυνση της συνολικής χρήσης της μνήμης και μικρή επιβάρυνση του επεξεργαστή από την υλοποίηση του αλγορίθμου. Χαρακτηριστικά, παραθέτουμε κάποιες δοκιμαστικές εκτελέσεις του προγράμματος τόσο απ' την πλευρά του πελάτη όσο και από την πλευρά του εξυπηρετητή και δίνουμε χαρακτηριστικά τους συνολικούς χρόνους εκτέλεσης και τη μνήμη που δεσμεύτηκε. Πέρα από την αρκετά γρήγορη υλοποίηση του CSA σε επίπεδο λογισμικού, o αλγόριθμος εμφανίζει αρκετά μεγάλη ασφάλεια για το περιεχόμενο των πακέτων. Στο [8] παρουσιάζεται μία τυπική ανάλυση του αλγορίθμου κρυπτογράφησης και αποδεικνύεται ότι ο αλγόριθμος παρουσιάζει μια συμμετρία η οποία μας επιτρέπει να αποκρυπτογραφήσουμε τα δεδομένα του ρεύματος επιλύοντας 2 28 γραμμικά συστήματα με περίπου 40 μεταβλητές και 60 γραμμικές σχέσεις, κατά μέσο όρο. Μια τέτοια λύση υλοποιήθηκε σε επίπεδο λογισμικού σε ένα σύστημα Macintosh PowerPC με επεξεργαστή 1,5 Mhz και το ρεύμα αποκρυπτογραφήθηκε σε λιγότερο από μια ώρα. Κάτι τέτοιο, βέβαια, είναι αρκετά καλό αν σκεφτούμε ότι το πρόγραμμά μας μπορεί να αλλάζει κλειδί κρυπτογράφησης κάθε 20 δευτερόλεπτα. Στο [9] βέβαια, παρουσιάζεται μια άλλη προσέγγιση για την εύρεση του κλειδιού κρυπτογράφησης, η οποία εισάγει σφάλματα στο κρυπτογραφημένο ρεύμα και μελετά το αποτέλεσμα της αποκρυπτογράφησης. Η διαδικασία αυτή βελτιώνει αρκετά το χρόνο εύρεσης του κλειδιού κρυπτογράφησης, αλλά το αποτέλεσμα είναι και πάλι αρκετά υψηλό σε σχέση με το χρόνο αλλαγής κλειδιού. Ο αλγόριθμος κρυπτογράφησης είναι ένας συνδυασμός δυο κρυπτογραφικών αλγορίθμων: ενός αλγορίθμου κρυπτογράφησης πακέτου και ενός αλγορίθμου ρεύματος. Οι δύο αυτοί αλγόριθμοι χρησιμοποιούν ένα ίδιο κλειδί 64 bit και το αποτέλεσμα του πρώτου αλγορίθμου δίνεται ως είσοδος στον αλγόριθμο ρεύματος. Η λειτουργία των δύο αυτών αλγορίθμων κρυπτογράφησης εμφανίζεται στην εικόνα 6. Το κλειδί κρυπτογράφησης καθορίζεται από το module του DVB Conditional Access και συνήθως τα σύγχρονα συστήματα μετάδοσης ψηφιακής τηλεόρασης αλλάζουν το κλειδί κάθε δευτερόλεπτα. Στο πρόγραμμά μας, η υλοποίηση του αλγορίθμου CSA γίνεται στο αρχείο modules/mux/mpeg/csa.c. Η κρυπτογράφηση και αποκρυπτογράφηση γίνεται στα πακέτα του TS ρεύματος. Η διαδικασία της κρυπτογράφησης γίνεται στη συνάρτηση csa_encrypt του csa.c, ενώ η αποκρυπτογράφηση γίνεται στο csa_decrypt. Στις συναρτήσεις αυτές περνάμε τη δομή που περιγράφει τις λεπτομέρειες του αλγορίθμου (κλειδιά κ.τ.λ.), ένα δείκτη στη δομή του πακέτου που θέλουμε να στείλουμε, καθώς και τον αριθμό των bytes που περιέχει και το αν το πακέτο είναι ζυγό ή μονό. Η τελευταία παράμετρος είναι απαραίτητη γιατί σε κάθε περίπτωση το κλειδί αντιστρέφεται. Ο αλγόριθμος σπάει αρχικά τα περιεχόμενα του πακέτου σε κομμάτια των 64 bits, στα οποία εφαρμόζει τον αλγόριθμο κρυπτογράφησης πακέτου. Στη συνέχεια, το κρυπτογραφημένο πακέτο το εισάγουμε στον αλγόριθμο ρεύματος και επιστρέφουμε το αποτέλεσμα στη μνήμη που έχουμε δεσμεύσει για το πακέτο μας. void csa_encrypt( csa_t *c, uint8_t *pkt, int i_pkt_size, int b_odd ) uint8_t *ck; uint8_t *kk; int i, j; int i_hdr = 4; /* hdr len */ uint8_t ib[184/82][8], stream[8], block[8]; int n, i_residue; /* Καθορισμός bit κρυπτογράφησης πακέτου */ pkt[3] = 0x80; if( b_odd ) pkt[3] = 0x40; if( b_odd ) ck = c->o_ck; kk = c->o_kk; else ck = c->e_ck; kk = c->e_kk; /* υπολογισμός μεγέθους πακέτου που θα κωδικοποιηθεί */

22 i_hdr = 4; if( pkt[3]&0x20 ) /* αποφεύγουμε να κωδικοποιήσουμε τις extra πληροφορίες που περιέχονται στην επικεφαλίδα */ i_hdr = pkt[4] 1; n = (i_pkt_size - i_hdr) / 8; i_residue = (i_pkt_size - i_hdr) % 8; if( n <= 0 ) pkt[3] &= 0x3f; return; /**/ for( i = 0; i < 8; i ) ib[n1][i] = 0; /* εφαρμογή του block Cypher στο αρχικό μας πακέτο */ for( i = n; i > 0; i-- ) for( j = 0; j < 8; j ) block[j] = pkt[i_hdr8*(i-1)j] ^ib[i1][j]; csa_blockcypher( kk, block, ib[i] ); /* Αρχικοποιήση του stream cypher αλγορίθμου */ csa_streamcypher( c, 1, ck, ib[1], stream ); for( i = 0; i < 8; i ) pkt[i_hdri] = ib[1][i]; for( i = 2; i < n1; i ) csa_streamcypher( c, 0, ck, NULL, stream ); for( j = 0; j < 8; j ) pkt[i_hdr8*(i-1)j] = ib[i][j] ^ stream[j]; if( i_residue > 0 ) csa_streamcypher( c, 0, ck, NULL, stream ); for( j = 0; j < i_residue; j ) pkt[i_pkt_size - i_residue j] ^= stream[j]; Η διαδικασία της αποκρυπτογράφησης είναι παρόμοια με τη διαδικασία κρυπτογράφησης. void csa_decrypt( csa_t *c, uint8_t *pkt, int i_pkt_size ) uint8_t *ck; uint8_t *kk; uint8_t ib[8], stream[8], block[8]; int i_hdr, i_residue; int i, j, n; /* έλεγχος bit κρυπτογράφησης πακέτου */ if( (pkt[3]&0x80) == 0 ) /* αν το πακέτο δεν είναι κρυπτογραφημένο δεν χρειάζεται αποκρυπτογράφηση */ return; if( pkt[3]&0x40 ) ck = c->o_ck; kk = c->o_kk; else ck = c->e_ck; kk = c->e_kk; /* καθορισμός του σημείου από το οποίο θα ξεκινήσει η αποκρυπτογράφηση */ pkt[3] &= 0x3f; i_hdr = 4; if( pkt[3]&0x20 ) /* Αν η σημαία adaptation είναι 1 τότε θα πρέπει να παραβλέψουμε και το πεδίο adaptation */ i_hdr = pkt[4] 1; if( i_hdr < 8 ) return; /* αρχικοποίηση κατάσταση του csa */ csa_streamcypher( c, 1, ck, &pkt[i_hdr], ib );

23 n = (i_pkt_size - i_hdr) / 8; if( n < 0 ) return; i_residue = (i_pkt_size - i_hdr) % 8; for( i = 1; i < n 1; i ) csa_blockdecypher( kk, ib, block ); if( i!= n ) csa_streamcypher( c, 0, ck, NULL, stream ); for( j = 0; j < 8; j ) /* xor του ib με το ρεύμα */ ib[j] = pkt[i_hdr8*ij] ^ stream[j]; //Εφαρμογή Αποκρυπτογράφηση πακέτου //Εφαρμογή Αποκρυπτογράφηση ρεύματος else /* ειδική εφαρμογή του αλγορίθμου για το τελευταία byte δεδομένων */ for( j = 0; j < 8; j ) ib[j] = 0; for( j = 0; j < 8; j ) pkt[i_hdr8*(i-1)j] = ib[j] ^ block[j]; if( i_residue > 0 ) csa_streamcypher( c, 0, ck, NULL, stream ); for( j = 0; j < i_residue; j ) pkt[i_pkt_size - i_residue j] ^= stream[j]; Αλγόριθμος κρυπτογράφησης πακέτου Ο αλγόριθμος κρυπτογράφησης πακέτου είναι ένας επαναληπτικός αλγόριθμος με κλειδί μεγέθους 64 bit. Για την κρυπτογράφηση / αποκρυπτογράφηση ενός μηνύματος είναι αναγκαίο το κλειδί να επεκταθεί από 8 σε 56 bytes. Η επέκταση του κλειδιού γίνεται σύμφωνα με τον εξής επαναληπτικό τύπο: k k E 64i,...,64i 63 = 0,...,63,i=0 ρ k E 64 i 1,...,64 i 1 0x0i0i0i0i0i0i0i0i1 i 6 Ο αλγόριθμος αρχικοποιεί τα πρώτα bit του κλειδιού με τα bit του αρχικού κλειδιού. Στις επόμενες 6 οκτάδες bytes ο τύπος χρησιμοποιεί τα bits της προηγούμενης ακριβώς οκτάδας εφαρμόζοντας μια μετάθεση και στο τελικό αποτέλεσμα εφαρμόζει ένα exclusive or με κάποια συγκεκριμένη σταθερά μήκους 64 bit, 0. Η διαδικασία δημιουργίας του εκτεταμένου κλειδιού στο vlc γίνεται στη συνάρτηση csa_computekey στο αρχείο /modules/mux/mpeg/csa.c. Η τιμή του υπολογίζεται μία μόνο φορά όταν καθορίζουμε μια νέα τιμή για το κλειδί της κρυπτογράφησης. Το πρόγραμμα χρησιμοποιεί την μετάθεση του πίνακα 2 για τον τύπο που παρουσιάσαμε παραπάνω, ενώ ως σταθερά 0 χρησιμοποιεί σε κάθε επανάληψη τον αύξοντα αριθμό της επανάληψης Πίνακας 2: Πίνακας μετάθεσης του αλγορίθμου csa στο vlc

24 static void csa_computekey( uint8_t kk[57], uint8_t ck[8] ) int i,j,k; int bit[64]; int newbit[64]; int kb[9][8]; /* Φορτώνουμε στο array kb[7][1..8] το αρχικό κλειδί */ for( i = 0; i < 8; i ) kb[7][i1] = ck[i]; /* υπολογίζουμε επαναληπτικά τα επόμενα array kb[6..1][*] */ for( i = 0; i < 7; i ) for( j = 0; j < 8; j ) //υπολογίζουμε τα vectors κάθε επανάληψης for( k = 0; k < 8; k ) //μελετάμε ένα-ένα τα bits του byte bit[j*8k] = (kb[7-i][1j] >> (7-k)) & 1; //αναζητούμε την τιμή του bit(0 ή 1) newbit[key_perm[j*8k]-1] = bit[j*8k]; //η νέα θέση του bit for( j = 0; j < 8; j ) //γεμίζουμε ένα ενδιάμεσο πίνακα kb[6-i][1j] = 0; for( k = 0; k < 8; k ) kb[6-i][1j] = newbit[j*8k] << (7-k); //γεμίζουμε τον ενδιάμεσο πίνακα με τις //σωστές τιμές /* υπολογίζουμε το τελικό array κάνοντας xor κάθε vector με τον αριθμό της επανάληψης */ for( i = 0; i < 7; i ) for( j = 0; j < 8; j ) kk[1i*8j] = kb[1i][1j] ^ i; //δημιουργούμε το τελικό array Για την κρυπτογράφηση ενός μηνύματος ο αλγόριθμος χρησιμοποιεί 64 bits του μηνύματος κάθε φορά. Αν το μήκος του μηνύματος δεν είναι πολλαπλάσιο του 64 τότε καθορίζεται ότι το τελευταίο κομμάτι γεμίζει με μηδενικά. Ο αλγόριθμος διατηρεί μια εσωτερική κατάσταση μεγέθους 8 bytes. H κατάσταση αυτή αρχικοποιείται με το κομμάτι του μηνύματος που θέλουμε να κρυπτογραφήσουμε ή να αποκρυπτογραφήσουμε. Παράλληλα, καθορίζεται ένας κυκλικός μετασχηματισμό φ. Ο αλγόριθμος δέχεται ως είσοδο την εσωτερική κατάσταση του αλγορίθμου και ένα byte από το κλειδί που φτιάξαμε παραπάνω και μας δίνει ως έξοδο 8 byte, τα οποία αποθηκεύονται ως η εσωτερική κατάσταση του αλγορίθμου. Η εφαρμογή του αλγορίθμου επαναλαμβάνεται 56 φορές και στο τέλος παίρνουμε το κρυπτογραφημένο / αποκρυπτογραφημένο μήνυμα. Ο μετασχηματισμός φ έχει ως βάση δύο συναρτήσεις, τις f και f'. Οι συναρτήσεις αυτές δέχονται ως είσοδο μία 8-bit τιμή και δίνουν ως έξοδο μια μετάθεση των bit της εισόδου. Οι συναρτήσεις αυτές συνδέονται με τη σχέση f=σ f', ενώ και οι δύο έχουν ένα μέγιστο μήκος κύκλου. H κρυπτογράφηση του μηνύματος μπορεί να περιγραφεί από τον εξής τύπο: S r = P, r=0 φ S r 1, k E 8r,..., k E 8r 7,1 r 56 C=S 56 όπου το C είναι το τελικό κρυπτογραφημένο κείμενο, το S r είναι η εσωτερική κατάσταση του αλγορίθμου στο γύρο r και k E είναι το εκτεταμένο κλειδί. Η διαδικασία αποκρυπτογράφησης είναι ίδια με τη διαδικασία κρυπτογράφησης, μόνο που δίνουμε ως είσοδο στον παραπάνω τύπο το κρυπτογραφημένο μήνυμα και μετά την 56η επανάληψη παίρνουμε το αρχικό κείμενο. Στον κώδικα του vlc η υλοποίηση του αλγορίθμου γίνεται στο αρχείο /modules/mux/mpeg/csa.c στις συναρτήσεις csa_blockencrypt και csa_blockdecrypt. Οι συναρτήσεις αυτές δέχονται ως είσοδο το εκτεταμένο κλειδί kk και το μήνυμα εισόδου ib και επιστρέφουν το αποτέλεσμα στο array bd. Το πρόγραμμα χρησιμοποιεί τον πίνακα 2 για τη μετάθεση των bit για τις συναρτήσεις f και f'.

25 Επίσης, οι μετασχηματισμοί φ και φ -1 έχουν τους εξής τύπους: φ s 0,..., s 7, k = s 1, s 2 s 0, s 4 s 0, s 5, s 6 f ' k s 7, s 7, s 0 f k s 7 φ 1 s 0,..., s 7, k = s 7 f s 6 k, s 0, s 7 s 1 f s 6 k, s 7 s 2 f s 6 k, s 7 s 3 f s 6 k, s 4, s 5 f ' s 6 k, s 6 static void csa_blockdecypher( uint8_t kk[57], uint8_t ib[8], uint8_t bd[8] ) int i; int perm_out; int R[9]; int next_r8; /* Αρχικοποίηση της εσωτερικής κατάστασης με το αρχικό κρυπτογραφημένο μύνημα */ for( i = 0; i < 8; i ) R[i1] = ib[i]; // επανάληψη της εφαρμογής του μετασχηματισμόυ φ φορές for( i = 56; i > 0; i-- ) const int sbox_out = block_sbox[kk[i]^r[7]];//υπολογισμός του f(s 6 k) perm_out = block_perm[sbox_out]; //υπολογισμός του f'(s 6 k) next_r8 = R[7]; //αποθηκεύουμε τη τιμή που θα πάρει το νέο s 8 R[7] = R[6] ^ perm_out; R[6] = R[5]; R[5] = R[4] ^ R[8] ^ sbox_out; R[4] = R[3] ^ R[8] ^ sbox_out; R[3] = R[2] ^ R[8] ^ sbox_out; R[2] = R[1]; R[1] = R[8] ^ sbox_out; R[8] = next_r8; for( i = 0; i < 8; i ) bd[i] = R[i1]; static void csa_blockcypher( uint8_t kk[57], uint8_t bd[8], uint8_t ib[8] ) int i; int perm_out; int R[9]; int next_r1; /* Αρχικοποίηση της εσωτερικής κατάστασης με το αρχικό κρυπτογραφημένο μήνυμα */ for( i = 0; i < 8; i ) R[i1] = bd[i]; // επανάληψη της εφαρμογής του μετασχηματισμόυ φ φορές for( i = 1; i <= 56; i ) const int sbox_out = block_sbox[kk[i]^r[8]];//υπολογισμός του f(s 7 k) perm_out = block_perm[sbox_out]; //υπολογισμός του f'(s 7 k) next_r1 = R[2]; //αποθηκεύουμε τη τιμή που θα πάρει το νέο s 1 R[2] = R[3] ^ R[1]; R[3] = R[4] ^ R[1]; R[4] = R[5] ^ R[1]; R[5] = R[6]; R[6] = R[7] ^ perm_out; R[7] = R[8]; R[8] = R[1] ^ sbox_out; R[1] = next_r1; for( i = 0; i < 8; i ) ib[i] = R[i1]; Αλγόριθμος κρυπτογράφησης ρεύματος Το δεύτερο κομμάτι του αλγορίθμου CSA είναι ένας αλγόριθμος κρυπτογράφησης ρεύματος. Ο αλγόριθμος αυτός μοντελοποιεί τη λειτουργία ενός κυκλώματος, το οποίο αποτελείται από 2 καταχωρητές ολίσθησης (feedback-shift-registers) και ένα συνδυαστή (combiner). Ο αλγόριθμος δέχεται ως είσοδο 8 byte κάθε φορά. Η διαδικασία της κρυπτογράφησης παρουσιάζεται και στην εικόνα 7. Ο αλγόριθμος έχει δύο μοντέλα λειτουργίας. Το πρώτο είναι η λειτουργία αρχικοποίησης κατά την οποία αρχικοποιούνται οι δομές του αλγορίθμου. Η δεύτερη λειτουργία είναι η παραγωγική λειτουργία, στην οποία ο αλγόριθμος παράγει ψευδοτυχαία bit με βάση τα bit που

26 έχουμε εισάγει. Εικόνα 7: Κύκλωμα υλοποίησης αλγορίθμου κρυπτογράφησης ρεύματος Η διαδικασία της αρχικοποίησης είναι σχετικά απλή. Ο αλγόριθμος χρησιμοποιεί το κλειδί κωδικοποίησης, καθώς και τα πρώτα 32 byte του σήματος. Το κλειδί κωδικοποίησης χρησιμοποιείται για την αρχικοποίηση των καταχωρητών. Οι καταχωρητές Α και Β είναι μεγέθους 40 bit. Η αρχικοποίησή τους γίνεται σύμφωνα με τον εξής τύπο: a i, j = k 4i j, i 7 0, else b i, j = k 32 4i j,i 7 0, else Ο τύπος αυτός παράγει μήτρες 10x4 στοιχείων. Οι τελευταίες 3 σειρές των μητρών είναι γεμάτες με μηδενικά. Αφού αρχικοποιηθούν οι καταχωρητές, ο αλγόριθμος χρησιμοποιεί το πρώτο μπλοκ του ρεύματος μαζί με τον καταχωρητή D σαν είσοδο και επαναλαμβάνει 32 φορές τη διαδικασία αρχικοποίησης. Σε κάθε επανάληψη το κύκλωμα διαβάζει μόνο δεδομένα, τα οποία προκύπτουν από τα δεδομένα του μπλοκ που πρόκειται να κρυπτογραφηθεί. Επίσης, σε κάθε επανάληψη εισάγεται ένα μόνο byte, το οποίο χωρίζεται σε 2 μπλοκ των 4 bit, τα οποία ανάλογα με το αν ο αριθμός της επανάληψης είναι μονός ή ζυγός χρησιμοποιούνται καταλλήλως από τους καταχωρητές Α και Β. Συγκεκριμένα, τα 2 block προκύπτουν από τον εξής τύπο:

27 Ι Α, Ι Β = ( SB 0 div 24, SB 0 mod 2 4 ), για τους μονούς γύρους ( SB 0 mod 2 4, SB 0 div 2 4 ), αλλιώς Σε κάθε επανάληψη το κύκλωμα ολισθαίνει τους καταχωρητές Α και B κατά 4 bit και εισάγει στην αρχή κάθε καταχωρητή 4 νέα bit, τα οποία προκύπτουν από τους εξής τύπους: a ' 0 =a 9 X D I A b' 0 =b 6 b 9 Y I B A' = a' 0, a 0, a 1, a 2, a 3, a 4, a 5, a 6, a 7, a 8 B '= b' 0, b 0, b 1, b 2, b 3, b 4, b 5, b 6, b 7, b 8, p=0 rol b' 0, b 0, b 1, b 2, b 3, b 4, b 5, b 6, b 7, b 8, p=1 Η τιμή των νέων bit στον καταχωρητή a δίνεται από την αποκλειστική διάζευξη μεταξύ των τελευταίων 4 bit του καταχωρητή a, του αποτελέσματος του καταχωρητή X, του Ι Α και της εξόδου του κυκλώματος D. Στον καταχωρητή B εισάγονται 4 bit, τα οποία προκύπτουν από την αποκλειστική διάζευξη μεταξύ του καταχωρητή X, του I B, των τελευταίων 4 bit του καταχωρητή b και το περιεχόμενο του καταχωρητή Y. Τα τέσσερα αυτά bit αντιστρέφονται σε σειρά στην περίπτωση που το περιεχόμενο του καταχωρητή Y είναι μη μηδενικό. Το κύκλωμα στη συνέχεια καθορίζει 7 S-box, τα οποία δέχονται ως είσοδο 5 bit από τον καταχωρητή Α και δίνουν στην έξοδο 2 bit. Γενικά, ένα S-Box είναι μια συνάρτηση, η οποία αντιστοιχίζει κάποια δυαδική τιμή εισόδου σε κάποια δυαδική τιμή εξόδου, που έχει πάντα μικρότερο μέγεθος. Τα S-box αυτά χρησιμοποιούνται για τον καθορισμό των τιμών των καταχωρητών X, Y, Z, p και q. Η πλήρης περιγραφή του τρόπου που λειτουργούν αυτά τα S-box παρουσιάζεται διεξοδικά στον πίνακα 3. Το τελευταίο κομμάτι του κυκλώματος είναι ο συνδυαστής. Ο συνδυαστής δίνει ως έξοδο 4 bit σε κάθε κύκλο υπολογισμού, τα οποία αποθηκεύονται στον καταχωρητή D. Το κομμάτι αυτό του κυκλώματος διαθέτει μια εσωτερική μνήμη, η οποία αποτελείται από τους καταχωρητές E, F και c. Η τιμή του καταχωρητή E καθορίζεται, όπως φαίνεται και στο σχήμα 7, από την τιμή του καταχωρητή F. Η τιμή του καταχωρητή E εξαρτάται από την τιμή του καταχωρητή q, η οποία με τη σειρά της καθορίζεται από μία από τις S-box συναρτήσεις, που περιγράφονται στο πίνακα 3. Σε περίπτωση που η συνάρτηση δώσει έξοδο ίση με 1, τότε ο καταχωρητής F παίρνει τιμή ίση με (Ε Ζ C)mod16, διαφορετικά παίρνει την τιμή του καταχωρητή E. Τέλος, η τιμή του καταχωρητή c καθορίζεται και αυτή από την τιμή του καταχωρητή q αλλά και από το αποτέλεσμα του (Ε Ζ C)mod16. Ο καταχωρητής αυτός χρησιμοποιείται για να αποθηκεύει το bit υπερχείλισης για την πράξη (Ε Ζ C). Η τιμή του καταχωρητή διατηρείται όταν το q=0. Τελικά, η τιμή του καταχωρητή D καθορίζεται από τον εξής τύπο: B 3 out =b 2,0 b 5,1 b 6,2 b 8,3 B 2 out =b 5,0 b 7,1 b 2,3 b 3,2 B 1 out =b 4,3 b 7,2 b 3,0 b 4,1 B out 0 =b 8,2 b 5,3 b 3,0 b 7,0 D= E Z B out Πίνακας 3: Πίνακας συναρτήσεων των S-BOX Στη φάση λοιπόν της αρχικοποίησης, το πρόγραμμα διαβάζει bytes από τα δεδομένα του μπλοκ που θέλουμε να κρυπτογραφήσουμε και αποθηκεύει στον καταχωρητή D την έξοδο του συνδυαστή.

28 Το αποτέλεσμα του καταχωρητή χρησιμοποιείται, όπως είδαμε και στην αρχή της παρουσίασης, για τη δημιουργία των νέων bit που εισάγονται στους καταχωρητές A και B. Η φάση της παραγωγής ψευδοτυχαίων bit ακολουθεί παρόμοια διαδικασία με την αρχικοποίηση του κυκλώματος. Η βασική διαφορά έγκειται στο ότι σε κάθε κύκλο το κύκλωμα δε δέχεται στην είσοδο του νέα bit αλλά αντίθετα τα παράγει στην έξοδο. Σε κάθε επανάληψη οι καταχωρητές Α και B ολισθαίνουν και πάλι κατά 4 bit αλλά τα νέα bit υπολογίζονται με βάση τους εξής τύπους: a' 0 =a 9 X b' 0 =b 6 b 9 Y A' = a' 0, a 0, a 1, a 2, a 3, a 4, a 5, a 6, a 7, a 8 B '= b' 0, b 0, b 1, b 2, b 3, b 4, b 5, b 6, b 7, b 8, p=0 rol b' 0, b 0, b 1, b 2, b 3, b 4, b 5, b 6, b 7, b 8, p=1 Η τιμή των νέων bit στον καταχωρητή A δίνεται από την αποκλειστική διάζευξη μεταξύ των τελευταίων 4 bit του καταχωρητή A και του αποτελέσματος του καταχωρητή X, ενώ στον καταχωρητή B εισάγονται 4 bit τα οποία προκύπτουν από την αποκλειστική διάζευξη μεταξύ της έκτης και της τελευταίας, κατά σειρά, τετράδας bit του καταχωρητή B και το περιεχόμενο του καταχωρητή Y. Τα τέσσερα αυτά bit αντιστρέφονται σε σειρά στην περίπτωση που το περιεχόμενο του καταχωρητή Y είναι μη μηδενικό. Η έξοδος του κυκλώματος καθορίζεται από τα περιεχόμενα του καταχωρητή D. Η τιμή του καταχωρητή D καθορίζεται με παρόμοιο τρόπο με τη διαδικασία αρχικοποίησης του συστήματος. Τελικά, στην έξοδο του κυκλώματος δίνονται 2 bit τα οποία υπολογίζονται από τον εξής τύπο: Out 1 =D 1 D 0 Out 1 =D 3 D 2 Στον κώδικα του vlc η υλοποίηση του αλγορίθμου γίνεται στο αρχείο /modules/mux/mpeg/csa.c, στη συνάρτηση csa_streamcypher. Οι συναρτήσεις αυτές δέχονται ως είσοδο τον ακέραιο b_init, που καθορίζει τη λειτουργία του κυκλώματος, το εκτεταμένο κλειδί ck και το μήνυμα εισόδου sb και επιστρέφουν το αποτέλεσμα στο array cb. Το κύκλωμα υλοποιείται προγραμματιστικά και οι καταχωρητές που χρησιμοποιούνται αποθηκεύονται σε μεταβλητές στη δομή c. static void csa_streamcypher( csa_t *c, int b_init, uint8_t *ck, uint8_t *sb, uint8_t *cb ) int i,j, k; int extra_b; int s1,s2,s3,s4,s5,s6,s7; int next_a1; int next_b1; int next_e; if( b_init ) // Στη φάση της αρχικοποιήσης φορτώνουμε τα 32 bits του CK στο A[1]..A[8] // και 32 bits του CK στο B[1]..B[8] στους υπόλοιπους καταχώρητες θέτουμε τιμές 0 for( i = 0; i < 4; i ) c->a[12*i0] = ( ck[i] >> 4 )&0x0f; c->a[12*i1] = ( ck[i] >> 0 )&0x0f; c->b[12*i0] = ( ck[4i] >> 4 )&0x0f; c->b[12*i1] = ( ck[4i] >> 0 )&0x0f; c->a[9] = c->a[10] = 0; c->b[9] = c->b[10] = 0; c->x = c->y = c->z = 0; c->d = c->e = c->f = 0; c->p = c->q = c->r = 0; // Σε κάθε επανάληψη επεξεργαζόμαστε 8 bytes for( i = 0; i < 8; i ) int op = 0; int in1 = 0; /* gcc warn */ int in2 = 0; if( b_init ) in1 = ( sb[i] >> 4 )&0x0f; //κατά την αρχικοποίηση διαβάζουμε 1 byte από το sb

29 in2 = ( sb[i] >> 0 )&0x0f; // Σε κάθε επανάληψη δίνουμε στην έξοδο 2 bit for( j = 0; j < 4; j ) // από τον καταχωρητή A, 35 bits επιλέγονται ως είσοδο στα 7 s-boxes // 5 bits είσοδος ανά s-box, 2 bits έξοδος ανά s-box s1 = sbox1[ (((c->a[4]>>0)&1)<<4) (((c->a[1]>>2)&1)<<3) (((c->a[6]>>1)&1)<<2) (((c->a[7]>>3)&1)<<1) (((c->a[9]>>0)&1)<<0) ]; s2 = sbox2[ (((c->a[2]>>1)&1)<<4) (((c->a[3]>>2)&1)<<3) (((c->a[6]>>3)&1)<<2) (((c->a[7]>>0)&1)<<1) (((c->a[9]>>1)&1)<<0) ]; s3 = sbox3[ (((c->a[1]>>3)&1)<<4) (((c->a[2]>>0)&1)<<3) (((c->a[5]>>1)&1)<<2) (((c->a[5]>>3)&1)<<1) (((c->a[6]>>2)&1)<<0) ]; s4 = sbox4[ (((c->a[3]>>3)&1)<<4) (((c->a[1]>>1)&1)<<3) (((c->a[2]>>3)&1)<<2) (((c->a[4]>>2)&1)<<1) (((c->a[8]>>0)&1)<<0) ]; s5 = sbox5[ (((c->a[5]>>2)&1)<<4) (((c->a[4]>>3)&1)<<3) (((c->a[6]>>0)&1)<<2) (((c->a[8]>>1)&1)<<1) (((c->a[9]>>2)&1)<<0) ]; s6 = sbox6[ (((c->a[3]>>1)&1)<<4) (((c->a[4]>>1)&1)<<3) (((c->a[5]>>0)&1)<<2) (((c->a[7]>>2)&1)<<1) (((c->a[9]>>3)&1)<<0) ]; s7 = sbox7[ (((c->a[2]>>2)&1)<<4) (((c->a[3]>>0)&1)<<3) (((c->a[7]>>1)&1)<<2) (((c->a[8]>>2)&1)<<1) (((c->a[8]>>3)&1)<<0) ]; /* δημιουργία του Bout από τα bit του καταχωρητή B (χρησιμοποιείται για τον υπολογισμό του D) */ extra_b = ( ((c->b[3]&1)<<3) ^ ((c->b[6]&2)<<2) ^ ((c->b[7]&4)<<1) ^ ((c->b[9]&8)>>0) ) ( ((c->b[6]&1)<<2) ^ ((c->b[8]&2)<<1) ^ ((c->b[3]&8)>>1) ^ ((c->b[4]&4)>>0) ) ( ((c->b[5]&8)>>2) ^ ((c->b[8]&4)>>1) ^ ((c->b[4]&1)<<1) ^ ((c->b[5]&2)>>0) ) ( ((c->b[9]&4)>>2) ^ ((c->b[6]&8)>>3) ^ ((c->b[3]&2)>>1) ^ ((c->b[8]&1)>>0) ) ; // T1 = αποκλειστική διάζευξη όλων των δεδομένων εισόδου // τα in1,in2, D χρησιμοποιούνται από το T1 μόνο στη αρχικοποίηση και όχι στην παραγωγή next_a1 = c->a[10] ^ c->x; if( b_init ) next_a1 = next_a1 ^ c->d ^ ((j % 2)? in2 : in1); // T2 = αποκλειστική διάζευξη όλων των δεδομένων εισόδου // τα in1,in2 χρησιμοποιούνται από το T1 μόνο στη αρχικοποίηση και όχι στην παραγωγή next_b1 = c->b[7] ^ c->b[10] ^ c->y; if( b_init) next_b1 = next_b1 ^ ((j % 2)? in1 : in2); // αν το p=0, χρησιμοποιείται, ενώ αν p=1, τότε αναστρέφουμε το αποτέλεσμα if( c->p ) next_b1 = ( (next_b1 << 1) ((next_b1 >> 3) & 1) ) & 0xf; // T3 = αποκλειστική διάζευξη όλων των δεδομένων εισόδου c->d = c->e ^ c->z ^ extra_b; // T4 = άθροισμα των Z E r next_e = c->f; if( c->q ) c->f = c->z c->e c->r; // r is the carry c->r = (c->f >> 4) & 1; c->f = c->f & 0x0f; else c->f = c->e; c->e = next_e; for( k = 10; k > 1; k-- ) c->a[k] = c->a[k-1]; c->b[k] = c->b[k-1]; c->a[1] = next_a1; c->b[1] = next_b1; c->x = ((s4&1)<<3) ((s3&1)<<2) (s2&2) ((s1&2)>>1); c->y = ((s6&1)<<3) ((s5&1)<<2) (s4&2) ((s3&2)>>1); c->z = ((s2&1)<<3) ((s1&1)<<2) (s6&2) ((s5&2)>>1); c->p = (s7&2)>>1; c->q = (s7&1); // σε κάθε επανάληψη το κύκλωμα παράγει 2 bit τα οποία // παράγονται από το περιεχόμενο του καταχωρητή D με xor ανά 2 op = (op << 2)^ ( (((c->d^(c->d>>1))>>1)&2) ((c->d^(c->d>>1))&1) ); // στη φάση αρχικοποίησης επιστρέφουμε τα αρχικά δεδομένα cb[i] = b_init? sb[i] : op;

30 2.4.1 Εισαγωγή 2.4 Μετάδοση δεδομένων Στο κεφάλαιο αυτό θα παρουσιάσουμε τα πρωτόκολλα που χρησιμοποιεί η εφαρμογή μας για τη μετάδοση των δεδομένων μιας ταινίας, αλλά και για την επικοινωνία των πελατών με το streamer. Για την κάλυψη αυτών των αναγκών επιλέχθηκε μια σουίτα πρωτοκόλλων που αναπτύχθηκε από το IETF και τα οποία σχεδιάστηκαν αποκλειστικά για χρήση σε εφαρμογές που χρησιμοποιούν δεδομένα πραγματικού χρόνου. Για τη μετάδοση των δεδομένων του streamer στους πελάτες του συστήματος επιλέξαμε το πρωτόκολλο RTP. Πρόκειται για ένα πρωτόκολλο που αναπτύχθηκε για να καλύψει τις ανάγκες εφαρμογών πολυμέσων που χρησιμοποιούν multicasting για τη μετάδοση των δεδομένων. Για την επικοινωνία της εφαρμογής του πελάτη με τον εξυπηρετητή, το πρόγραμμά μας χρησιμοποιεί το πρωτόκολλο RTSP. Τέλος, στο κεφάλαιο αυτό παρουσιάζουμε και το πρωτόκολλο sdp, το οποίο χρησιμεύει στην περιγραφή ρευμάτων δεδομένων Μεταφορά δεδομένων - Real Time Transport Protocol(RTP) Για τη μετάδοση των ταινιών από το streamer στους πελάτες χρησιμοποιείται το πρωτόκολλο RTP. Το πρωτόκολλο αυτό καθορίζει έναν τρόπο μετάδοσης δεδομένων και αντιστοιχεί στο επίπεδο μεταφοράς δεδομένων του προτύπου OSI. Το RTP σχεδιάστηκε κυρίως για τη μετάδοση δεδομένων πραγματικού χρόνου, όπως ο ήχος και η εικόνα, μέσω της δυνατότητας multicast του πρωτοκόλλου, αν και τώρα πια χρησιμοποιείται και για unicast μεταδόσεις. Η ανάπτυξή του έγινε από το Audio- Visual Working group του IETF και το πρώτο επίσημο reference παρουσιάστηκε το 1996[11]. Το πρωτόκολλο αυτό αποτέλεσε την αφετηρία για την ανάπτυξη εξειδικεύσεων του πρωτοκόλλου για συγκεκριμένα πρότυπα συμπίεσης ήχου και εικόνας. Το πρωτόκολλο σε γενικές γραμμές καθορίζει ένα παραμετροποιήσιμο τρόπο πακετοποίησης δεδομένων πραγματικού χρόνου. Το κάθε πακέτο που παράγεται με βάση το RTP χρησιμοποιεί την πλατφόρμα TCP/IP για τη μετάδοσή του στο παραλήπτη. Η σχεδιαστική επιλογή της χρήσης ενός ακόμα ενδιάμεσου επιπέδου πακετοποίησης των δεδομένων των ρευμάτων της εφαρμογής μας έγινε κυρίως γιατί μας επιτρέπει να έχουμε ένα επίπεδο εμπιστοσύνης σε μια multicast udp σύνδεση. Ως γνωστόν, μια udp σύνδεση δε μας δίνει κάποια ασφάλεια σε ότι αφορά την παράδοση ενός πακέτου, ενώ η χρήση μίας tcp σύνδεσης, η οποία εξασφαλίζει υψηλή ασφάλεια κατά την αποστολή δεδομένων, δε μας παρέχει τη δυνατότητα multicasting που διαθέτει το udp πρωτόκολλο. Έτσι επιλέχθηκε το RTP ως πρωτόκολλο μετάδοσης δεδομένων. Όπως φαίνεται και παρακάτω στην παρουσίαση της δομής ενός RTP πακέτου, το πρωτόκολλο δίνει μέσω της σύνταξής του τη δυνατότητα να αναπτυχθούν έλεγχοι για τη σωστή αποστολή των δεδομένων αλλά και την ανάπτυξη δυνατοτήτων ανάνηψης από σφάλματα αποστολής δεδομένων[13]. Τέτοιες δυνατότητες, δυστυχώς, δεν αναπτύσσονται από την εφαρμογή μας, αλλά είναι εύκολο να υλοποιηθούν με τη χρήση του RTCP (RTP Control Protocol) πρωτοκόλλου. Το πρωτόκολλο γενικά παρέχει 4 βασικές δυνατότητες σε μια εφαρμογή: 1. Καθορισμός τύπου δεδομένων που μεταφέρει 2. Αρίθμηση πακέτων 3. Εισαγωγή χρονικών αναφορών 4. Παρακολούθηση παράδοσης πακέτων. Οι δυνατότητες αυτές δίνονται από τα πεδία της επικεφαλίδας. Κάθε πακέτο αποτελείται από μια επικεφαλίδα και από τα δεδομένα του ρεύματος. Στο RTP καθορίζονται κάποια βασικά πεδία για την επικεφαλίδα τα οποία είναι υποχρεωτικό να υπάρχουν σε όλα τα πακέτα, ενώ καθορίζει και κάποια επιπλέον πεδία που μπορούν να καλύψουν τυχόν ανάγκες

31 μιας εφαρμογής. Η γενική δομή ενός πακέτου εμφανίζεται και στην εικόνα Ver P S CC Μ PT sequence number timestamp rest of options and data Εικόνα 8: Πακέτο RTP Τα πρώτα 64 bit, όπως φαίνεται και παραπάνω, είναι δεδομένα σε κάθε RTP πακέτο, αποτελούν την επικεφαλίδα του και ορίζονται ως εξής: protocol version (2 bit): Το πεδίο αυτό καθορίζει την έκδοση του πρωτοκόλλου που χρησιμοποιείται από το RTP. Η τρέχουσα έκδοση του πρωτοκόλλου είναι η έκδοση 2 (η τιμή 1 έχει χρησιμοποιηθεί ήδη από την προηγούμενη έκδοση του προγράμματος, ενώ η τιμή 0 χρησιμοποιήθηκε αρχικά κατά τις δοκιμές του πρωτοκόλλου). Padding (1 bit): Το πεδίο αυτό καθορίζει αν το πακέτο μας περιέχει στο τέλος του κάποια extra bit. Ο αριθμός των bit αυτών καθορίζεται από το τελευταίο byte του πακέτου το οποίο καθορίζει πόσα ακριβώς bit θα πρέπει να παραλειφθούν, συμπεριλαμβανομένων και των 8 τελευταίων bit. Αυτά τα πρόσθετα bit τις περισσότερες φορές είναι απαραίτητα από αλγορίθμους κρυπτογράφησης, οι οποίοι απαιτούν δεδομένο μέγεθος πακέτου ως είσοδο. extension (1 bit): Το bit αυτό καθορίζει αν το πακέτο μας περιέχει μία ακριβώς προέκταση στην επικεφαλίδα του. Η προέκταση αυτή εμφανίζεται ακριβώς μετά το τέλος της καθορισμένης επικεφαλίδας. Το πρωτόκολλο RTP διαθέτει ένα μηχανισμό επέκτασης, ο οποίος επιτρέπει σε μια εφαρμογή να επεκτείνει την υπάρχουσα αρχιτεκτονική του και να προσθέτει νέα πεδία με πληροφορίες για το περιεχόμενο του πακέτου. Το RTP μέχρι στιγμής διαθέτει πλήθος διαφορετικών υλοποιήσεων ανάλογα το είδος των δεδομένων που μεταφέρει. Η επέκταση αυτή καθορίζει ένα τύπο δεδομένων που μπορεί να μεταφέρει ένα πακέτο ανεξάρτητα από τον τύπο δεδομένων που μπορεί να περιλαμβάνει, επιτρέποντας με αυτό τον τρόπο την αγνόηση αυτού του πεδίου από κάποια εφαρμογή. CSRC count (4 bit): Το πεδίο αυτό χρησιμοποιείται για τον καθορισμό του αριθμού των CSRC αναγνωριστικών τα οποία περιέχει το πακέτο. Τα CSRC αναγνωριστικά είναι αριθμοί 32 bit, οι οποίοι μπορούν να καθορίσουν μονοσήμαντα μια πηγή δεδομένων σε μια δεδομένη συνεδρία. Marker (1 bit): Το πεδίο marker δεν έχει κάποια δεδομένη λειτουργικότητα στο RTP και μπορεί να χρησιμοποιηθεί από την εφαρμογή με όποια σημασιολογία επιθυμεί. Γενικά, χρησιμοποιείται από το επίπεδο εφαρμογής για να σηματοδοτήσει σημαντικά γεγονότα για κάποια εφαρμογή, όπως τα όρια κάποιου πλαισίου. Το πρωτόκολλο επιτρέπει επίσης στην εφαρμογή να καθορίσει και πρόσθετα πεδία marker. payload type (7 bit): Το πεδίο αυτό χρησιμοποιείται για να καθορίσει τον τύπο των δεδομένων που μεταφέρονται από το πακέτο. Για τη σωστή διαχείριση του πρωτοκόλλου οι δημιουργοί του τονίζουν ότι είναι σημαντικό όταν αναπτύσσουμε μια εφαρμογή που χρησιμοποιεί το RTP να έχουμε καθορίσει από την αρχή μια αντιστοίχηση των διαφόρων ρευμάτων δεδομένων με αντίστοιχους κωδικούς για το πεδίο payload type. Επίσης, το πρωτόκολλο καθορίζει ότι μια εφαρμογή που δεν αναγνωρίζει το payload type ενός πακέτου οφείλει να το αγνοήσει. sequence number (16 bit): Το πεδίο sequence number αυξάνει κατά ένα για κάθε πακέτο που αποστέλλει ο streamer στους πελάτες. Το πεδίο αυτό μπορεί να χρησιμοποιηθεί για τη διόρθωση της σειράς λήψης των πακέτων από τον πελάτη, ενώ παράλληλα επιτρέπει τον έλεγχο για τυχόν απώλειες πακέτων. Το πρωτόκολλο καθορίζει ότι η αρχική τιμή του πεδίου

32 αυτού πρέπει πάντα να είναι τυχαία, για λόγους κυρίως ασφάλειας, σε περίπτωση που η μετάδοση των δεδομένων χρησιμοποιεί κρυπτογράφηση. timestamp (32 bit): Το πεδίο αυτό καθορίζει τη χρονική στιγμή που δημιουργήθηκαν τα δεδομένα του πακέτου. Το πρωτόκολλο δεν καθορίζει τη μονάδα μέτρησης χρόνου για το πεδίο αυτό. Καθορίζει όμως, ότι θα πρέπει να έχει μεγάλη διακριτική ικανότητα και να εξαρτάται από τη συχνότητα της πηγής δεδομένων. Επίσης, κάποια πακέτα μπορεί να έχουν κοινές τιμές στο πεδίο αυτό. SSRC (32 bit): Το πρωτόκολλο RTP επιτρέπει σε μια εφαρμογή να λαμβάνει δεδομένα από πολλές πηγές ταυτόχρονα. Για κάθε πηγή το πρωτόκολλο ορίζει ότι πρέπει να δημιουργείται ένα μοναδικό αναγνωριστικό για τη διάρκεια τη συνεδρίας. Το πεδίο λοιπόν αυτό περιλαμβάνει το αναγνωριστικό της πηγής με βάση την οποία θα γίνει ο συγχρονισμός δεδομένων του πακέτου. CSRC (32 bit): Το πεδίο αυτό καθορίζει τις πηγές από τις οποίες προήλθαν τα δεδομένα του πακέτου. Ο αριθμός των πηγών, που μπορεί να προήλθε το πακέτο, μπορεί να είναι μέχρι 15 και καθορίζεται από το πεδίο CC όπως είδαμε και πιο πριν. Το RTP πρωτόκολλο καθορίζει επίσης και ένα μηχανισμό επέκτασης. Ο μηχανισμός επέκτασης μπορεί να χρησιμοποιηθεί από κάποια εφαρμογή για την αποστολή δεδομένων, τα οποία δε μπορούν να περιγραφούν από τα υπάρχοντα πεδία ενός RTP πακέτου. Ένα τέτοιο πεδίο είναι εύκολο να αγνοηθεί από κάποια εφαρμογή, η οποία δεν αναγνωρίζει αυτή την προέκταση. Γενικά, μία προέκταση του RTP αποτελείται από ένα πεδίο 4 byte η σημασία του οποίου καθορίζεται από την εφαρμογή, ένα πεδίο length, το οποίο καθορίζει το μέγεθος της προέκτασης με μονάδα μέτρησης τα 4 bytes και τη τιμή του πεδίου καθορίζεται από την εφαρμογή επέκταση επικεφαλίδας Εικόνα 9: Πεδίο επέκτασης RTP μήκος Επικοινωνία Streamer και client Real Time Streaming Protocol(RTSP) Ένα σημαντικό κομμάτι της εργασίας που παρουσιάζουμε αναλώθηκε στη μελέτη και υλοποίηση ενός ευρέως αποδεκτού πρωτοκόλλου για την ασφαλή επικοινωνία μεταξύ του εξυπηρετητή πολυμέσων και των πελατών. Η επικοινωνία αυτή ήταν αναγκαία, καταρχήν για να μπορούν οι πελάτες να ενημερώνονται για τα κλειδιά κρυπτογράφησης δυναμικά, ενώ παράλληλα μας επιτρέπει να καθορίζουμε δυναμικά σε κάθε πελάτη τον τρόπο με τον οποίο θα παραλάβει τα δεδομένα του. Για την επικοινωνία των οντοτήτων αυτών τελικά επιλέγει το πρωτόκολλο RTSP, καθώς κάλυπτε τις ανάγκες που περιγράψαμε και αφετέρου ένα κομμάτι της υλοποίησης που απαιτούσε ήταν ήδη ενσωματωμένο στον κώδικα του vlc, η υλοποίησή του οποίου υπάρχει ήδη στις βιβλιοθήκες livemedia της live.com. Το RTSP είναι ένα πρωτόκολλο διαχείρισης ρευμάτων δεδομένων πραγματικού χρόνου. Αναπτύχθηκε από τον οργανισμό IETF και το πρώτο επίσημο RFC εκδόθηκε το 1998[X]. Το πρωτόκολλο σε γενικές γραμμές επιτρέπει σε ένα χρήστη να συνδεθεί σε ένα εξυπηρετητή πολυμέσων και να ελέγξει τη λειτουργία του εξυπηρετητή απομακρυσμένα στέλνοντας κατάλληλα μηνύματα. Είναι ανεξάρτητο από το ρεύμα αποστολής δεδομένων, με την έννοια ότι δεν καθορίζει ούτε απαιτεί κάποιο δεδομένο τρόπο αποστολής των δεδομένων και προσφέρει ένα κοινά αποδεκτό τρόπο για την επικοινωνία μεταξύ του εξυπηρετητή και των πελατών για τη διαχείριση των ρευμάτων. Η ομάδα ανάπτυξης χρησιμοποίησε σαν βάση για τη δημιουργία του RTSP το HTTP. Βέβαια το πρωτόκολλο έχει πολλές διαφορές από το HTTP, καθώς πολλά από τα χαρακτηριστικά

33 του HTTP χρειάζονται επέκταση για να μπορούν να καλύπτουν τις ανάγκες ενός εξυπηρετητή πολυμέσων. Μερικές από τις πιο σημαντικές διαφορές είναι ότι το RTSP καθορίζει ένα σύνολο καταστάσεων για τους εμπλεκόμενους σε μια συνεδρία και ότι επιτρέπει και στον εξυπηρετητή να στέλνει αιτήματα στους πελάτες του. Το RTSP, όπως αναφέραμε και στην εισαγωγή, καθορίζει ένα σύνολο καταστάσεων τόσο για τους πελάτες όσο και για τους εξυπηρετητές της συνεδρίας (εικόνα 10). Οι καταστάσεις αυτές είναι παρόμοιες και για τις δύο κατηγορίες εμπλεκομένων και καθορίζονται ως εξής: 1. Init: Η κατάσταση Init είναι η αρχική κατάσταση κάθε συστήματος. Ο εξυπηρετητής βρίσκεται σε αυτήν την κατάσταση όταν είναι έτοιμος και αναμένει κάποια αίτηση SETUP για να ξεκινήσει τη δέσμευση πόρων αλλά δεν έχει ήδη λάβει κάποια μέχρι εκείνη τη στιγμή, ενώ οι πελάτες βρίσκονται σε αυτή τη κατάσταση μόνο όταν αναμένουν απάντηση για κάποιο SETUP μήνυμα που έχουν στείλει. 2. Ready: Στην κατάσταση Ready οι οντότητες που εμπλέκονται έχουν δεσμεύσει όλους τους αναγκαίους πόρους και είναι έτοιμες να αναπαράγουν τα μέσα. Σε αυτήν την κατάσταση βρίσκονται ο εξυπηρετητής και ο πελάτης όταν έχει αποσταλεί μια επιτυχής αίτηση SETUP ή όταν έχει αποσταλεί μια επιτυχής αίτηση PAUSE, ενώ η οντότητα ήταν σε κατάσταση playing. 3. Playing: Στην κατάσταση Play βρίσκεται μια οντότητα της συνεδρίας RTSP όταν έχει ξεκινήσει η αναπαραγωγή των μέσων. Στην κατάσταση αυτή μπορούν να βρεθούν τόσο ο εξυπηρετητής όσο και ο πελάτης στην περίπτωση που έχει αποσταλεί επιτυχώς μια αίτηση PLAY. 4. Recording: Στην κατάσταση Record βρίσκεται μια οντότητα της συνεδρίας RTSP όταν έχει ξεκινήσει η καταγραφή των μέσων. Στην κατάσταση αυτή μπορούν να βρεθούν τόσο ο εξυπηρετητής όσο και ο πελάτης στη περίπτωση που έχει αποσταλεί επιτυχώς μια αίτηση RECORD. Η μετάβαση από μια κατάσταση σε κάποια άλλη, όπως φαίνεται από την παραπάνω περιγραφή αλλά και από την εικόνα 10, γίνεται μόνο κατά την ανταλλαγή μηνυμάτων (βέβαια σε αυτή τη γενική περίπτωση θα πρέπει να συμπεριλάβουμε και την τετριμμένη περίπτωση κατά την οποία μια unicast σύνδεση διακόπτεται για κάποιο λόγο, οπότε όλα τα μέλη της μεταβαίνουν αυτόματα στην κατάσταση INIT). Εικόνα 10: Διάγραμμα καταστάσεων των οντοτήτων μίας RTSP συνεδρίας Τα μηνύματα στο RTSP παρουσιάζουν μεγάλη ομοιότητα με τα μηνύματα που συναντάμε στο πρωτόκολλο HTTP. Κάθε μήνυμα του RTSP αποτελείται από μια αρχική γραμμή στην οποία περιγράφεται το πρωτόκολλο που χρησιμοποιείται, το περιεχόμενό του πρωτοκόλλου, μια ή περισσότερες γραμμές επικεφαλίδας(header fields) που δίνουν πληροφορίες για το περιεχόμενο του μηνύματος, τον αποστολέα και μια κενή γραμμή. Κατ' επιλογή, ένα μήνυμα μπορεί να περιέχει και ένα σώμα κειμένου(mesage body). Οι τύποι των μηνυμάτων χωρίζονται σε δυο κατηγορίες: τα αιτήματα (requests) και τις απαντήσεις (responses).

34 Ένα μήνυμα προσδιορίζεται ως αίτημα από την πρώτη γραμμή του, η οποία στην περίπτωση αυτή ονομάζεται γραμμή αίτησης. H γραμμή αίτησης γενικά έχει την εξής μορφή: Μέθοδος SP RTSP_URL SP RTSP/1.0 CRLF Κάθε αίτημα καθορίζει μια συγκεκριμένη διαδικασία που περιγράφει. Η διαδικασία αυτή καθορίζεται από το πεδίο μέθοδος της πρώτης γραμμής του μηνύματος. Οι μέθοδοι που μπορούν να χρησιμοποιηθούν από το πρωτόκολλο είναι πλήρως καθορισμένες, χωρίς βέβαια να απαιτείται η υλοποίηση του συνόλου των μεθόδων αυτών από μια υλοποίηση του πρωτοκόλλου (καθορίζεται μόνο ένα μικρό υποσύνολο των μεθόδων, το οποίο απαιτείται για να είναι λειτουργική μία υλοποίηση). Συγκεκριμένα, οι μέθοδοι που ορίζονται από το πρωτόκολλο είναι οι εξής: 1. OPTIONS: Με τη μέθοδο OPTIONS ο αποστολέας ζητάει να μάθει πληροφορίες για τις μεθόδους του RTSP που υποστηρίζει ο παραλήπτης για το δεδομένο URL που καθορίζεται στην πρώτη γραμμή του αιτήματος. Η αίτηση αυτή μπορεί να αποσταλεί τόσο από έναν πελάτη όσο και από έναν εξυπηρετητή και είναι απαραίτητο να υλοποιείται σε ένα πρόγραμμα που υποστηρίζει RTSP. H αποστολή μιας τέτοιας αίτησης μπορεί να λάβει χώρα ανά πάσα στιγμή και δεν επηρεάζει την τρέχουσα κατάσταση του server και του πελάτη. 2. DESCRIBE: Με τη μέθοδο αυτή ένας πελάτης ζητά από έναν εξυπηρετητή την περιγραφή ενός εκ των διαθέσιμων μέσων. Το μέσο που ενδιαφέρει τον πελάτη καθορίζεται από το URI της πρώτης γραμμής. Ο εξυπηρετητής, σε κάθε τέτοια αίτηση, επιστρέφει μια απάντηση στην οποία περιγράφει όλες τις αναγκαίες αρχικοποιήσεις που χρειάζεται να κάνει ο πελάτης αποστέλλοντας setup αιτήσεις, για να ξεκινήσουν τα ρεύματα δεδομένων του μέσου που περιγράφεται. Ένα ενδιαφέρον σημείο είναι ότι η υλοποίηση της μεθόδου describe από έναν εξυπηρετητή δεν είναι αναγκαία, αλλά σε αυτήν την περίπτωση είναι υποχρεωτικό να καθορίζεται κάποιος εναλλακτικός τρόπος με τον οποίο θα περιγράφονται οι αναγκαίες αρχικοποιήσεις ρευμάτων στους πελάτες (http, file κτλ). 3. ANNOUNCE: Η μέθοδος announce έχει διπλή σημασία στο RTSP. Αν ένας πελάτης αποστείλει ένα μήνυμα announce σε έναν εξυπηρετητή, τότε ο εξυπηρετητής θα πρέπει να προσθέσει στα υπάρχοντα μέσα που διαμοιράζονται μια νέα περιγραφή για το μέσο που καθορίζεται στο URI της πρώτης γραμμής. Αν από την άλλη ένα τέτοιο μήνυμα αποσταλεί από έναν εξυπηρετητή σε έναν πελάτη, τότε ο πελάτης οφείλει δυναμικά να αλλάξει τον τρόπο λήψης του ρεύματος σύμφωνα με την περιγραφή που περιλαμβάνει το μήνυμα αυτό. 4. SETUP: Η μέθοδος setup επιτρέπει σε έναν πελάτη να καθορίσει τις παραμέτρους μετάδοσης του ρεύματος δεδομένων. Στη υλοποίηση του πρωτοκόλλου στην εφαρμογή μας, για παράδειγμα, η χρήση της μεθόδου μας επιτρέπει να καθορίσουμε τον τύπο της μετάδοσης (multicast ή unicast) και την πόρτα από την οποία μπορεί κάποιος να λάβει τα δεδομένα. Συνήθως, οι λεπτομέρειες της αποστολής καθορίζονται στο πεδίο Transport της επικεφαλίδας. Επίσης, σε αυτό το σημείο ο εξυπηρετητής οφείλει να δημιουργήσει ένα αναγνωριστικό συνεδρίας το οποίο θα χρησιμοποιείται τόσο από το server όσο και από το client για να αναφέρονται στην τρέχουσα συνεδρία μέχρι να εκδοθεί κάποια αίτηση teardown. 5. PLAY: Η μέθοδος play ορίζει σε έναν εξυπηρετητή ότι θα πρέπει να ξεκινήσει την αποστολή δεδομένων στον πελάτη. Το RTSP τονίζει ότι μια play αίτηση δεν πρέπει ποτέ να αποστέλλεται από έναν πελάτη αν δεν έχει λάβει επιτυχείς απαντήσεις από κάθε αίτηση setup που έχει σταλεί. Σημαντικό επίσης για τη μέθοδο είναι ότι σε κάθε τέτοιο αίτημα είναι υποχρεωτικό να καθορίζεται στο πεδίο range της επικεφαλίδας από ποιό σημείο μέχρι ποιό σημείο του μέσου θα πρέπει ο εξυπηρετητής να στείλει στον πελάτη. Αν το χρονικό διάστημα που καθορίζεται είναι μικρότερο από τη διάρκεια του μέσου, τότε ο εξυπηρετητής δρα όπως θα δρούσε και στην περίπτωση που είχε λάβει ένα αίτημα PAUSE. Επίσης, η μέθοδος επιτρέπει σε έναν πελάτη να καθορίσει τη χρονική στιγμή στην οποία θα ξεκινήσει η αποστολή του ρεύματος δεδομένων.

35 6. PAUSE: Μια αίτηση pause έχει ως αποτέλεσμα την προσωρινή διακοπή της αποστολής του ρεύματος δεδομένων για το ρεύμα που καθορίζεται από το URI στην πρώτη γραμμή της αίτησης. Σε μια τέτοια αίτηση ο εξυπηρετητής σταματά τη μετάδοση δεδομένων χωρίς όμως να απελευθερώνει τους δεσμευμένους πόρους του συστήματος. Η αίτηση αυτή μπορεί να αφορά ένα ολόκληρο μέσο ή μόνο κάποιο από τα ρεύματά του και σε κάθε περίπτωση μετά την αποστολή κάποιας αίτησης play ο πελάτης είναι υπεύθυνος για το συγχρονισμό των διαφόρων ρευμάτων του μέσου. 7. TEARDOWN: Μία αίτηση teardown σταματά τη μετάδοση δεδομένων για το ρεύμα που καθορίζεται από το URI στη πρώτη γραμμή της αίτησης. Όταν ο εξυπηρετητής λάβει μια τέτοια αίτηση τότε απελευθερώνει όσους τυχόν πόρους έχει δεσμεύσει για τη μετάδοση των δεδομένων και επιστρέφει στη κατάσταση init. 8. GET_PARAMETER: Η μέθοδος αυτή χρησιμοποιείται τόσο από τον πελάτη όσο και από τον εξυπηρετητή και επιτρέπει στον αποστολέα της αίτησης να λάβει την τιμή κάποιας παραμέτρου για το ρεύμα ή το μέσο που καθορίζεται στο URI της πρώτης γραμμής. Το όνομα και η τιμή της παραμέτρου καθορίζεται στο σώμα του κειμένου και το πρωτόκολλο δεν καθορίζει κάποια δεδομένη δομή για το τί μπορεί να περιλαμβάνεται στο σώμα ενός τέτοιου μηνύματος, αλλά αφήνει τη δομή ανοιχτή στην υλοποίηση. Το πρωτόκολλο επίσης ορίζει ότι μια αίτηση get_parameter με κενό σώμα μπορεί να χρησιμοποιηθεί και ως ping test για τον έλεγχο της λειτουργίας του παραλήπτη. Τέλος, σημαντική παρατήρηση για τη μέθοδο είναι ότι κάθε τέτοιο αίτημα πρέπει να περιλαμβάνει ένα πεδίο Content-Type, το οποίο θα περιγράφει το περιεχόμενο του σώματος του μηνύματος και, όπως γίνεται αντιληπτό, το πρωτόκολλο έχει μεγάλη ελαστικότητα στο περιεχόμενο των μηνυμάτων. 9. SET_PARAMETER: Με τη μέθοδο set_parameter ο πελάτης ζητά να καθορίσει την τιμή κάποιας παραμέτρου του ρεύματος δεδομένων. Κι εδώ ισχύει ό,τι και στη μέθοδο get_parameter. Σημαντική παρατήρηση είναι ότι, το πρωτόκολλο ορίζει τον τρόπο με τον οποίο σε κάθε αίτηση set_parameter ο πελάτης θα πρέπει να καθορίζει την τιμή μιας μόνο παραμέτρου, έτσι ώστε σε περίπτωση αποτυχίας να γνωρίζει από ποια αίτηση προήλθε το σφάλμα, ενώ παράλληλα ο εξυπηρετητής καθορίζεται όταν λαμβάνει περισσότερες από μια παραμέτρους να μη δέχεται καμία από τις τιμές που αποστέλλονται στην περίπτωση που έστω και μία από όλες τις τιμές έχει κάποιο σφάλμα. 10. REDIRECT: Μια αίτηση redirect αποστέλλεται από έναν εξυπηρετητή σε έναν πελάτη και καθορίζει στον πελάτη ότι πρέπει να συνδεθεί σε κάποιο άλλο εξυπηρετητή για να συνεχίσει να λαμβάνει το ρεύμα δεδομένων. Ο εξυπηρετητής στον οποίο θα συνδεθεί ο πελάτης καθορίζεται από το πεδίο Location της επικεφαλίδας. 11. RECORD: Μια αίτηση record καθορίζει στον παραλήπτη ότι πρέπει να ξεκινήσει η καταγραφή του ρεύματος που περιγράφεται από το URI στην πρώτη γραμμή της αίτησης. Το πρωτόκολλο επιτρέπει και σε αυτή τη μέθοδο όπως και στο play να καθορίσει ένα χρονικό παράθυρο για το οποίο θα γίνει η καταγραφή του ρεύματος. Οι απαντήσεις αντίθετα από τις αιτήσεις έχουν διαφορετική σύνταξη στην πρώτη γραμμή τους. Η πρώτη γραμμή σε μία απάντηση ονομάζεται γραμμή κατάστασης και ακολουθεί το εξής πρότυπο: RTSP-Version SP Status-Code SP Reason-Phrase CRLF Όπως φαίνεται και από το παραπάνω πρότυπο, στη γραμμή κατάστασης ο αποστολέας καθορίζει την έκδοση του πρωτοκόλλου που χρησιμοποιεί, έναν κωδικό που καθορίζει το αποτέλεσμα της αίτησης και ένα string που περιγράφει το αποτέλεσμα της αίτησης. Ο κώδικας κατάστασης είναι ένα χαρακτηριστικό το οποίο το RTSP το κληρονόμησε από το HTTP όποτε και οι τιμές που μπορεί να πάρει είναι ίδιες με αυτές που ορίζονται και στο RFC του HTTP. Σε γενικές γραμμές, το πρωτόκολλο ορίζει 5 βασικές ομάδες περιπτώσεων για τον κώδικα κατάστασης, οι οποίες αντικατοπτρίζονται από το πρώτο ψηφίο του τριψήφιου αυτού αριθμού. Οι κατηγορίες του κωδικού κατάστασης είναι: 1xx(Πληροφόρηση): Η αίτηση παρελήφθη και συνεχίζεται η επεξεργασία.

36 2xx(Επιτυχία): Η αίτηση παρελήφθη επιτυχώς, κατανοήθηκε και έγινε αποδεκτή. 3xx(Αναδρομολόγηση): Ο πελάτης πρέπει να επικοινωνήσει με κάποιον άλλο εξυπηρετητή για να ολοκληρωθεί με επιτυχία η αίτηση. 4xx(Σφάλμα πελάτη): Η αίτηση δεν είναι σωστά συντεταγμένη ή δεν υποστηρίζεται. 5xx(Σφάλμα εξυπηρετητή): Η αίτηση δεν μπορεί να ολοκληρωθεί από τον εξυπηρετητή αν και είναι σωστά συντεταγμένη. Μετά από την πρώτη γραμμή σε κάθε μήνυμα, είτε σε αίτηση είτε σε απάντηση, ακολουθούν τα πεδία επικεφαλίδας. Τα πεδία επικεφαλίδας περιλαμβάνουν γενικές πληροφορίες για το μήνυμα ή για τον αποστολέα και τον πελάτη. Τα πεδία που μπορούν να χρησιμοποιηθούν είναι πλήρως καθορισμένα από το πρωτόκολλο και χωρίζονται σε 4 γενικές κατηγορίες: τα Γενικά πεδία επικεφαλίδας (General Header Field), τα οποία περιλαμβάνουν πληροφορίες, οι οποίες αφορούν το συγκεκριμένο μήνυμα. Τα πεδία αυτά μπορεί να συμπεριλαμβάνονται τόσο σε μία αίτηση όσο και σε μία απάντηση και οι πληροφορίες που εκφράζουν είναι το encoding του μηνύματος, η ημερομηνία αποστολής κ.α. τα πεδία επικεφαλίδων αίτησης (Request Header Field), τα οποία περιέχονται μόνο σε αιτήσεις και περιλαμβάνουν πληροφορίες για τον αποστολέα του μηνύματος, όπως το πρόγραμμα που χρησιμοποιεί, τα στοιχεία αυθεντικοποίησης κ.α. τα πεδία επικεφαλίδων απάντησης (Response Header Field), τα οποία επιτρέπουν στον αποστολέα να συμπεριλάβει πρόσθετες πληροφορίες στο μήνυμα σχετικές με την απάντηση. Τα πεδία αυτά εκφράζουν πληροφορίες σχετικά με το server και τις περαιτέρω δυνατότητες που δίνει για την πρόσβαση στο μέσο που περιγράφεται από το URI της γραμμής απάντησης. τα πεδία επικεφαλίδας οντότητας (Entity Header Fields), τα οποία μπορούν να εκφράσουν μετα-πληροφορίες σχετικές με το σώμα του μηνύματος. Τέτοιες πληροφορίες μπορεί να είναι το μέγεθος του σώματος, ο τύπος των δεδομένων που περιλαμβάνουν κ. α. Το τελευταίο κομμάτι ενός μηνύματος είναι το σώμα του μηνύματος (message body). Το σώμα ενός μηνύματος είναι ένα προαιρετικό στοιχείο και χρησιμοποιείται για να μεταφέρει μία ή περισσότερες οντότητες σώματος. Μία οντότητα σώματος χρησιμοποιείται από τις οντότητες μιας RTSP συνεδρίας για τη μετάδοση πληροφοριών, οι οποίες αφορούν την εφαρμογή. Το περιεχόμενο μιας οντότητας κειμένου καθορίζεται και επεξεργάζεται αποκλειστικά από το επίπεδο εφαρμογής και όχι από το RTSP. Παραδείγματα οντοτήτων σώματος εμφανίζονται και στην υλοποίηση του πρωτοκόλλου από την εφαρμογή μας. Για παράδειγμα, η περιγραφή των ρευμάτων που έχει ο εξυπηρετητής μεταφέρεται στους πελάτες ως σώμα στην απάντηση κάθε αίτησης DESCRIBΕ. Η παρουσία του message body σε ένα μήνυμα εξαρτάται συνήθως από το περιεχόμενο της γραμμής απάντησης ή από τα πεδία επικεφαλίδας. Σε γενικές γραμμές μια αίτηση έχει δικαίωμα να περιλαμβάνει μια οντότητα μηνύματος όταν περιέχει ένα Content-Length ή Transfer-Encoding πεδίο επικεφαλίδας, ενώ μια απάντηση μπορεί να περιλαμβάνει μια οντότητα κειμένου σε κάποιες συγκεκριμένες περιπτώσεις συνδυασμού αίτησης και κωδικού κατάστασης. Ένα τυπικό παράδειγμα λειτουργίας του RTSP στο πρόγραμμά μας εμφανίζεται και στην πίνακα 4.

37 ΠΕΛΑΤΗΣ OPTIONS RTSP:// :8080/test.sdp RTSP/1.0 Cseq: 1 User- Agent: VLC Media Player (LIVE555 Streaming Media v ) DESCRIBE RTSP:// :8080/test.sdp RTSP/1.0 CSeq: 2 Accept: User- Agent: application/sdp VLC Media Player (LIVE555 Streaming Media v ) Cseq: 1 Server : Public: Content- Length : Content-type: Server: Content- Length: ΕΞΥΠΗΡΕΤΗΤΗΣ RTSP/ Ok VLC Server DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER 0 Cseq: 2 Cache- Control: RTSP/ OK application/sdp VLC Server 192 no-cache v=0 o= IN IP s=none t=0 0 a=tool:vlc test2 c=in IP k=prompt m=video 1234 RTP/AVP 33 a=control:rtsp:// :8080/test.sdp/tr ackid=0 SETUP RTSP:// :8080/test.sdp/trackid=0 RTSP/1.0 CSeq: 3 Transport: User- Agent: RTP/AVP;unicast;client_port= VLC Media Player (LIVE555 Streaming Media v ) Transport: Server: Content- Length: RTSP/ OK RTP/AVP/UDP;client_port = VLC Server 0 Cseq: 3 Cache- Control: no-cache Session: PLAY RTSP:// :8080/test.sdp RTSP/1.0 CSeq: 4 Transport: RTSP/ OK RTP/AVP/UDP;client_port =

38 ΠΕΛΑΤΗΣ PLAY RTSP:// :8080/test.sdp RTSP/1.0 Session: Range: npt= User- Agent: VLC Media Player (LIVE555 Streaming Media v ) Server: Content- Length: ΕΞΥΠΗΡΕΤΗΤΗΣ VLC Server 0 Cseq: 3 Cache- Control: no-cache Session: GET_PARAMETER RTSP:// :8080/test.sdp RTSP/1.0 CSeq: 5 Session: User-Agent: Content-type: KI VLC Media Player (LIVE555 Streaming Media v ) text/parameters 4 Content-type: Server: Contentlength: Contentlength: 10 CSeq: 5 Cache- Control: KI= RTSP/ OK text/parameters VLC Server no-cache GET_PARAMETER RTSP:// :8080/test.sdp RTSP/1.0 CSeq: 6 Session: User-Agent: Content-type: Contentlength: 6 IPCR VLC Media Player (LIVE555 Streaming Media v ) text/parameters Content-type: Server: Contentlength: 15 CSeq: 6 Cache- Control: IPCR= RTSP/ OK text/parameters VLC Server no-cache GET_PARAMETER RTSP:// :8080/test.sdp RTSP/1.0 CSeq: 7 Session: User-Agent: Content-type: VLC Media Player (LIVE555 Streaming Media v ) text/parameters Content- 4 Content-type: Server: Contentlength: 4 CSeq: 7 Cache- Control: RTSP/ OK text/parameters VLC Server no-cache

39 ΠΕΛΑΤΗΣ GET_PARAMETER RTSP:// :8080/test.sdp RTSP/1.0 length: KN KN=2 ΕΞΥΠΗΡΕΤΗΤΗΣ RTSP/ OK GET_PARAMETER RTSP:// :8081/test.sdp RTSP/1.0 CSeq: 8 Session: User-Agent: Content-type: Content-length: 4 CK VLC media player (LIVE555 Streaming Media v ) text/parameters Content-type: Server: Content-length: 36 CSeq: 8 Cache-Control: RTSP/ OK text/parameters VLC Server no-cache CK=A9D875CA2A190018FD62DFB5A4322 9E5 GET_PARAMETER RTSP:// :8081/test.sdp RTSP/1.0 CSeq: 9 Session: User-Agent: Content-type: Content-length: 4 NK VLC media player (LIVE555 Streaming Media v ) text/parameters Content-type: Server: Content-length: 36 RTSP/ OK text/parameters VLC Server CSeq: 9 Cache-Control: no-cache NK=5296E8E0B9C5C5F651A2DBAA3C1F 3E8D Πίνακας 4: Σενάριο επικοινωνίας σε μία τυπική συνεδρία στο CDN Η υλοποίηση του RTSP που ακολουθήσαμε στο πρόγραμμά μας ήταν αρκετά απλουστευμένη. Η επικοινωνία μεταξύ πελάτη και εξυπηρετητή είναι μονόδρομη, δηλαδή μόνο ο πελάτης αποστέλλει αιτήσεις στον εξυπηρετητή. Η υλοποίηση του πρωτοκόλλου από την πλευρά του πελάτη υλοποιείται στο αρχείο /modules/demux/livedotcom.cpp. Το αρχείο αυτό, όπως φαίνεται και από το path στο οποίο βρίσκεται, θεωρείται ένα demuxing module και όχι ένα input module όπως θα περίμενε κανείς, καθώς μέσα στο αρχείο περιλαμβάνεται και η λήψη των RTP πακέτων και η απομάκρυνση των επικεφαλίδων τους. Το livedotcom.cpp αρχείο μετά την απάντηση του εξυπηρετητή σε ένα αίτημα DESCRIBE φορτώνει εσωτερικά ένα δεύτερο module για την απόπλεξη των δεδομένων του ρεύματος ανάλογα με το είδος των δεδομένων που περιγράφονται στο sdp αρχείο που αποστέλλεται. Στο αρχείο αυτό το πρόγραμμα χρησιμοποιεί τη βιβλιοθήκη Live Media, τόσο για την υλοποίηση του RTSP, όσο και για τη διαχείριση των RTP πακέτων. Σε γενικές γραμμές, το vlc δημιουργεί ένα νήμα για τη λήψη και απόπλεξη των ρευμάτων δεδομένων. Το νήμα σε κάθε επανάληψη καλεί τη συνάρτηση Demux του livedotcom. Η συνάρτηση αυτή χρησιμοποιεί τη

40 μέθοδο getnextframe του αντικειμένου FramedSource της βιβλιοθήκης Live Media για να λάβει τα δεδομένα του ρεύματος. Το αντικείμενο FramedSource δημιουργείται από κάθε ρεύμα δεδομένων που περιγράφεται στο sdp που παρέλαβε ο πελάτης. Η μέθοδος αυτή δέχεται ως ορίσματα ένα δείκτη σε ένα δεσμευμένο κομμάτι μνήμης, έναν ακέραιο που δείχνει το μέγεθος της μνήμης και 2 συναρτήσεις, μία που εφαρμόζεται σε κάθε πακέτο που λαμβάνεται και μία που καλείται όταν κλείσει η σύνδεση με τον εξυπηρετητή. Οι συναρτήσεις αυτές είναι οι StreamRead και η StreamClose. Η μεν πρώτη μελετά το είδος του ρεύματος από το οποίο λάβαμε το πακέτο και ανάλογα με την πηγή εισάγει το πακέτο σε μία FIFO ουρά για την επεξεργασία του από το κατάλληλο module και η δεύτερη θέτει κατάλληλα flags στη βασική δομή του livedotcom.cpp ώστε να τερματιστεί η λειτουργία του module. Από την πλευρά του streamer ο RTSP εξυπηρετητής υλοποιείται στο αρχείο /modules/stream_out/rtp.c με τη βοήθεια του /src/misc/httpd.c. Για τη δημιουργία ενός RTSP server ο χρήστης θα πρέπει να καθορίσει στις παραμέτρους της γραμμής εντολών η μετάδοση του μέσου να γίνει μέσω του stream out module RTP και η παράμετρος sdp του module να είναι κάποιο url, το οποίο θα χρησιμοποιεί το πρωτόκολλο RTSP. Όταν συντρέχουν οι δύο παραπάνω περιπτώσεις τότε το πρόγραμμα δημιουργεί έναν RTSP server για το domain που ορίσαμε στο sdp. Η υλοποίηση του RTSP server γίνεται στο αρχείο httpd.c. Στο αρχείο αυτό υλοποιείται ένας generic socket server, ο οποίος τρέχει ως ξεχωριστό thread και με τη βοήθεια του οποίου το πρόγραμμα λαμβάνει αιτήσεις από τους πελάτες τόσο για το πρωτόκολλο RTSP όσο και για http. Το νήμα του αρχείου αυτού εκτελεί τη συνάρτηση httpd_hostthread. Η συνάρτηση αυτή περιλαμβάνει ένα αέναο loop, στο οποίο σε κάθε επανάληψη ελέγχονται τα socket του προγράμματος για τυχόν μετάδοση δεδομένων από τους υπάρχοντες πελάτες, αλλά και αν υπάρχουν νέοι πελάτες που ζητούν να συνδεθούν. Επίσης, στο αρχείο αυτό καθορίζεται και η συνάρτηση httpd_urlcatch με την οποία ένα stream out module μπορεί να εγγράψει μια συνάρτηση, η οποία θα είναι υπεύθυνη για τη διαχείριση μιας συγκεκριμένης κατηγορίας αιτήσεων για ένα συγκεκριμένο url. Οι πληροφορίες αυτές αποθηκεύονται σε δομές που καθορίζονται στο httpd.c για κάθε url που διαχειρίζεται ο server και καλούνται αφού πρώτα αναλυθεί η αίτηση που λάβαμε. Το αρχείο RTP.c περιλαμβάνει κώδικα για τη διαχείριση των αιτήσεων RTSP από τους πελάτες στον εξυπηρετητή και για τη δημιουργία της sdp περιγραφής των ρευμάτων. Η διαχείριση των αιτήσεων γίνεται από τις συναρτήσεις RTSPCallback και RTSPCallbackID. Οι συναρτήσεις αυτές λαμβάνουν ως είσοδο τα στοιχεία του πελάτη που έστειλε την αίτηση, τα δεδομένα που περιείχε η αίτηση και ένα δείκτη σε μία δομή που θα περιλάβει τα δεδομένα της απάντησης. Η συνάρτηση RTSPCallback διαχειρίζεται αιτήματα που αφορούν τη συνολική παρουσίαση ενός μέσου (DESCRIBE, PLAY, PAUSE, TEARDOWN, GET_PARAMETER) ενώ η RTSPCallbackId διαχειρίζεται αιτήματα που αφορούν μεμονωμένα ένα ρεύμα του μέσου (SETUP). Η δημιουργία της sdp περιγραφής γίνεται από τη συνάρτηση SDPGenerate. Σε μία τυπική RTSP συνεδρία της εφαρμογής μας, το πρώτο μήνυμα που αποστέλλει ένας πελάτης είναι μία αίτηση OPTIONS για να δει ποιες δυνατότητες υποστηρίζει ο εξυπηρετητής. Στη συνέχεια, ο πελάτης αποστέλλει μια αίτηση DESCRIPTION για κάποια συγκεκριμένη παρουσίαση από αυτές που διαθέτει ο εξυπηρετητής και λαμβάνει ως απάντηση την περιγραφή των ρευμάτων που περιλαμβάνει η παρουσίαση χρησιμοποιώντας το πρωτόκολλο sdp. Στη συνέχεια, ο πελάτης θα πρέπει, όπως καθορίζει και το RTSP, να αποστείλει αιτήσεις SETUP σε όλα τα ρεύματα που καθορίζονται στην sdp περιγραφή για να καθορίσει τις παραμέτρους μεταφοράς (στην εφαρμογή επειδή επιλέγουμε το MPEG-TS για την πολύπλεξη των ρευμάτων της παρουσίασης, πάντα θα έχουμε μόνο ένα ρεύμα) και τελικά να αποστείλει ένα PLAY αίτημα για να ξεκινήσει η αποστολή των δεδομένων. Στη συνέχεια, το πρόγραμμα από την πλευρά του πελάτη ελέγχει τα ορίσματα που δόθηκαν στη γραμμή εντολών κατά την εκτέλεση του vlc και ανάλογα αν έχει καθοριστεί η παράμετρος sout-ts-csa-sk αποστέλλει μία αίτηση GET_PARAMETER για να λάβει τη παράμετρο KI (Key Interval), η οποία καθορίζει το χρονικό διάστημα μεταξύ δύο αλλαγών κλειδιών σε microsec. Σε περίπτωση που ο εξυπηρετητής επιστρέψει τιμή 0 για το KI τότε σημαίνει ότι η τρέχουσα παρουσίαση δεν αλλάζει κλειδιά κρυπτογράφησης. Σε περίπτωση που η τιμή είναι διάφορη του 0 τότε το πρόγραμμα ζητά την τιμή IPCR. Η τιμή αυτή αντιστοιχεί στο πρώτο PCR που αποστέλλεται από τον πολυπλέκτη σε ένα πακέτο TS. Όπως θα δούμε και παρακάτω, το πεδίο

41 αυτό αντιπροσωπεύει το χρόνο που θα πρέπει να φτάσει το πακέτο στον αποκωδικοποιητή του πελάτη. Με βάση αυτήν τη τιμή μπορούμε να υπολογίσουμε τον αριθμό του τρέχοντος κλειδιού με βάση το τύπο: key_number = (PCR IPCR)/KI Η τιμή αυτή είναι σημαντική στη συνέχεια της εκτέλεσης του προγράμματος, καθώς αποτελεί το Intialization Vector του αλγορίθμου κρυπτογράφησης και μπορούμε με τη βοήθειά του να εντοπίσουμε τυχόν σφάλματα. Στη συνέχεια, η εφαρμογή του πελάτη ζητά το ΚΝ (Key Number) από τον εξυπηρετητή. Το KN είναι ο αριθμός του τρέχοντος κλειδιού και είναι απαραίτητο για την αποκρυπτογράφηση του πρώτων κλειδιών του csa. Στη τελευταία φάση της αρχικοποίησης της εφαρμογής του πελάτη αποστέλλονται δύο αιτήσεις GET_PARAMETER στον εξυπηρετητή ζητώντας το τρέχων και το επόμενο κλειδί κρυπτογράφησης για τον αλγόριθμο csa. Κατά τη διάρκεια λήψης των δεδομένων από τον πελάτη, το πρόγραμμα κάνει συχνούς ελέγχους στα PCR των TS πακέτων και υπολογίζει με τη βοήθειά τους το πότε θα πρέπει να γίνει κάποια αλλαγή κλειδιού. Στη διαδικασία αλλαγής κλειδιού κρυπτογράφησης, ο πελάτης αποστέλλει αρχικά μια αίτηση για το τρέχον αριθμό κλειδιών. Η τιμή αυτή χρησιμοποιείται για να ελέγξουμε αν πρόκειται να χρησιμοποιήσουμε το σωστό κλειδί κρυπτογράφησης. Αν η τιμή κλειδιού που μας αποστείλει ο εξυπηρετητής δεν είναι αυτή που θεωρεί ο πελάτης ότι θα έπρεπε να είναι, τότε ο πελάτης ζητά το τρέχον κλειδί κρυπτογράφησης από τον εξυπηρετητή. Σε αντίθετη περίπτωση χρησιμοποιεί απλά το κλειδί που έχει ήδη αποθηκευμένο στη μνήμη. Στη δεύτερη φάση της διαδικασίας αλλαγής κλειδιού ο πελάτης αποστέλλει μία αίτηση για τη λήψη του νέου επόμενου κλειδιού. Η τιμή αυτή θα χρησιμοποιηθεί από το πελάτη στην επόμενη αλλαγή κλειδιού Περιγραφή συνεδρίας - Session Description Protocol(SDP) Για την περιγραφή των διαφορετικών ρευμάτων μιας παρουσίασης το πρόγραμμά μας χρησιμοποιεί το πρωτόκολλο SDP. Το πρωτόκολλο SDP αναπτύχθηκε από το IETF και το τελευταίο επίσημο rfc κυκλοφόρησε τον Απρίλιο του 1998[15]. Η ανάπτυξή του είχε ως στόχο τη δημιουργία ενός πρωτοκόλλου, το οποίο θα μπορεί να περιγράφει πλήρως τις λεπτομέρειες μετάδοσης των διαφόρων ρευμάτων σε μια συνεδρία πολυμέσων και έτσι θα επιτρέπει σε κάποιο παραλήπτη να συμμετέχει αυτόματα στη συνεδρία αυτή. Η περιγραφή αυτή γίνεται σε ASCII text, το οποίο όμως δεν έχει σχεδιαστεί να είναι εύκολα αναγνώσιμο από τον άνθρωπο, αν και δεν είναι δύσκολο για κάποιον να καταλάβει τι περιγράφει ένα αρχείο sdp. Οι περιγραφές του πρωτοκόλλου πέρα από την εφαρμογή τους στο RTSP, η οποία εμφανίζεται και στην εφαρμογή μας, χρησιμοποιούνται στην τεχνολογία sap, όπου o streamer ανά κάποια μικρά τακτά χρονικά διαστήματα αποστέλλει σε κάποια δεδομένη ip και port πληροφορίες σχετικές με τις εκπομπές που διαχειρίζεται εκείνη τη στιγμή περιγραφόμενες από το sdp. Επίσης, μία περιγραφή sdp μπορεί να αποσταλεί μέσω , στο οποίο αν έχει οριστεί η MIME επικεφαλίδα content-type στην τιμή "application/sdp", ο client μπορεί να ξεκινήσει αυτόματα τη συμμετοχή στη συνεδρία που περιγράφεται. Μια περιγραφή sdp αποτελείται από ένα σύνολο γραμμών κειμένου, όπου κάθε μία έχει τη μορφή: <τύπος>=<τιμή> Το πεδίο τύπος είναι πάντα ένας ακριβώς χαρακτήρας. Το πεδίο τιμή είναι τύπου αλφαριθμητικό και η δομή του εξαρτάται από τον τύπο της γραμμής. Γενικά, ένα πεδίο τιμή μπορεί να αποτελείται από ένα δεδομένο αριθμό πεδίων χωρισμένα με κενά ή να μην υπακούει σε κάποια δεδομένη δομή. Η περιγραφή μίας συνεδρίας αποτελείται από μία περιγραφή της συνεδρίας και μία ή περισσότερες περιγραφές των επί μέρους μέσων που αποτελούν την παρουσίαση. Σε γενικές γραμμές, η περιγραφή μίας συνεδρίας ξεκινά με μία γραμμή v= και εκτείνεται μέχρι την αρχή του πρώτου επί μέρους μέσου. Η περιγραφή ενός μέσου, από την άλλη, ξεκινά με μία γραμμή m= και

42 εκτείνεται μέχρι την αρχή του επόμενου μέσου ή μέχρι το τέλος της περιγραφής. Γενικά, τα δυνατά πεδία και η δομή που μπορούμε να έχουμε σε μια sdp περιγραφή είναι τα εξής: Περιγραφή συνεδρίας v= (έκδοση πρωτοκόλλου) o= (κάτοχος / δημιουργός της συνεδρίας) s= (όνομα συνεδρίας) i=* (πληροφορία συνεδρίας) u=* (URI περιγραφής) e=* ( ) p=* (αριθμός τηλεφώνου) c=* (πληροφορίες σύνδεσης μη αναγκαία σε περίπτωση που περιλαμβάνεται στις περιγραφές των μέσων) b=* (πληροφορίες για το bandwidth) Ένας ή περισσότεροι περιγραφείς χρόνου όπως περιγράφονται παρακάτω z=* (καθορισμός χρονικής ζώνης) k=* (κλειδί κρυπτογράφησης) a=* ( μηδέν ή περισσότερα χαρακτηριστικά συνεδρίας) Περιγραφή Χρόνου t= (χρόνος κατά τον οποίο η συνεδρία θα είναι ενεργή) r=* (μηδέν η περισσότερες επαναλήψεις της συνεδρίας) Περιγραφή επιμέρους μέσων m= (όνομα μέσου και διεύθυνση) i=* (τίτλος μέσου) c=* (πληροφορίες σύνδεσης) b=* (πληροφορίες bandwidth) k=* (κλειδί κρυπτογράφησης) a=* (μηδέν ή περισσότερα χαρακτηριστικά μέσου) Στον παραπάνω κατάλογο τα πεδία με αστεράκι είναι προαιρετικά. Το πρωτόκολλο επίσης καθορίζει ότι σε μια sdp περιγραφή επιτρέπεται στον αποστολέα να περιλαμβάνει και άλλους τύπους που δεν περιλαμβάνονται στους παραπάνω. Σε αυτήν την περίπτωση ο parser μιας εφαρμογής απλώς αγνοεί τυχόν τύπους που δεν καταλαβαίνει. Στην περίπτωση της εφαρμογής μας μία τυπική περιγραφή του sdp εμφανίζεται στον πίνακα 3 στην απάντηση της αίτησης DESCRIBE. Αναλυτικά, το περιεχόμενο του σώματος περιγράφει τα εξής: v = 0: Το πεδίο v καθορίζει την έκδοση του πρωτοκόλλου sdp που θα χρησιμοποιείται. Η έκδοση 0 είναι μέχρι στιγμής η μοναδική έκδοση του πρωτοκόλλου. o = IN IP : το πεδίο ο καθορίζει την προέλευση της περιγραφής. Η τιμή του πεδίου θα πρέπει να ακολουθεί το πρότυπο <όνομα χρήστη> <αναγνωριστικό συνεδρίας> <έκδοση> <τύπος δικτύου> <τύπος διεύθυνσης> <διεύθυνση>. Στην τιμή του παραδείγματος βλέπουμε ότι το όνομα χρήστη είναι πάντα κενό. Το αναγνωριστικό της συνεδρίας στην εφαρμογή μας παράγεται από τη συνάρτηση gettimeofday, που επιστρέφει το τρέχον χρόνο εκφρασμένο σε msec. Το πεδίο έκδοση εκφράζει τον αριθμό των διαφορετικών περιγραφών που έχει παράγει μέχρι στιγμής η εφαρμογή και επιτρέπει στους πελάτες να αναγνωρίζουν ποια είναι η τελευταία και ορθότερη περιγραφή. Το πεδίο τύπος δικτύου αντιστοιχεί σε ένα string που στην περίπτωση της εφαρμογής μας περιγράφει τον τύπο του δικτύου και είναι το internet. Ο τύπος διεύθυνσης εκφράζει τον τύπο της διεύθυνσης που περιγράφεται στο τελευταίο πεδίο. Οι δυνατές εκδόσεις που καθορίζονται από το reference του SDP είναι IP4 και IP6. s = NONE: Το πεδίο αυτό εκφράζει τον τίτλο της συνεδρίας. Το πεδίο αυτό μπορεί να καθοριστεί από τις παραμέτρους του module RTP.

43 t = 0 0: Το πεδίο t καθορίζει το χρόνο που θα ξεκινήσει ο συνεδρία και το χρόνο που θα τερματιστεί. Στην περίπτωση της εφαρμογής μας η περιγραφή επιλέγει τιμή μηδέν τόσο για την αρχή όσο και για το τέλος, οι οποίες σημαίνουν για το πρωτόκολλο ότι η συνεδρία είναι μόνιμη και ότι δεν έχει κάποιο καθορισμένο χρόνο ολοκλήρωσης. a = tool:vlc test2: Το πεδίο a περιγράφει κάποια χαρακτηριστικά της συνεδρίας, τα οποία δε μπορούν να εκφραστούν από τα υπόλοιπα πεδία του πρωτοκόλλου. Γενικά, το πεδίο αυτό μπορεί να χρησιμοποιηθεί για την επέκταση του sdp καθώς μπορούν να καθοριστούν διάφορες παράμετροι, οι οποίες θα γίνονται αντιληπτές μόνο από την εφαρμογή μας και θα περνάνε απαρατήρητες από άλλες εφαρμογές. c = IN IP : το πεδίο αυτό καθορίζει τις λεπτομέρειες σύνδεσης για όλα τα μέσα της παρουσίασης. Η τιμή ακολουθεί το πρότυπο <τύπος δικτύου> <τύπος διεύθυνσης> <διεύθυνση>. Τα πεδία αυτά έχουν ίδια δομή με τα πεδία του o. Βέβαια, εδώ καθορίζεται από το πρωτόκολλο ότι σε περίπτωση που η διεύθυνση που ορίζεται είναι multicast να καθορίζεται και ο χρόνος ζωής των πακέτων TTL μετά τη διεύθυνση. k = prompt: Το πεδίο αυτό καθορίζει αν η συνεδρία χρησιμοποιεί κάποιο αλγόριθμο κρυπτογράφησης και ποια κλειδιά χρησιμοποιεί αυτός ο αλγόριθμος για την κρυπτογράφηση - αποκρυπτογράφηση. Η τιμή που χρησιμοποιούμε στην υλοποίησή μας καθορίζει στους πελάτες ότι το κλειδί δεν περιέχεται στην sdp περιγραφή αλλά τα ρεύματα δεδομένων της παρουσίασης είναι κρυπτογραφημένα. m = video 1234 RTP/AVP 33: Το πεδίο αυτό καθορίζει την περιγραφή ενός μέσου της παρουσίασης. Η τιμή του ακολουθεί το πρότυπο <μέσο> <πόρτα> <τύπος μεταφοράς> <> a = control:rtsp:// :8080/test.sdp/trackid=0: Το πεδίο αυτό ακολουθεί πάντα ένα πεδίο m και καθορίζει το URL στο οποίο θα πρέπει να αποστείλει ο πελάτης τις αιτήσεις που αφορούν τον έλεγχο του ρεύματος αυτού.

44 2.5 Videolan Client VLC Στο κεφάλαιο αυτό πρόκειται να παρουσιάσουμε το πρόγραμμα VLC το οποίο αποτέλεσε τη βάση για την ανάπτυξη της εφαρμογή μας. Το πρόγραμμα αυτό είναι ανοιχτού κώδικα και διαθέτει υλοποιημένη υποστήριξη για πολλές από τις δυνατότητες που απαιτούνται όπως RTSP/RTP μετάδοση μέσων, MPEG-2 πολύπλεξη ρευμάτων, καθώς και το πρωτόκολλο συμπίεσης βίντεο H.264. Παράλληλα, το πρόγραμμα είναι μια δοκιμασμένη λύση που έχει χρησιμοποιηθεί σε αρκετά εμπορικά περιβάλλοντα με μεγάλες απαιτήσεις. Το γεγονός αυτό μας επιτρέπει να είμαστε σίγουροι ότι ο κώδικας που έχει γραφτεί για τη μετάδοση μέσων μέσω δικτύου είναι ικανός να καλύψει τις ανάγκες ενός εμπορικού streamer Η Ιστορία του VLC Η ανάπτυξη του project ξεκίνησε το 1996 στο γαλλικό πανεπιστήμιο Ecole Centrale του Παρισιού. Η υλοποίηση του προγράμματος ξεκίνησε από τους φοιτητές που διαχειρίζονταν το δίκτυο του πανεπιστημίου, οι οποίοι είχαν ως στόχο τον να εμπλουτισμό των υπηρεσιών του δικτύου με τη μετάδοση video σε MPEG-2. Ο βασικός στόχος ήταν η μετάδοση τηλεοπτικών προγραμμάτων έτσι ώστε οι φοιτητές να μπορούν να βλέπουν στο δωμάτιό τους, στην εστία του πανεπιστημίου, δορυφορικά τηλεοπτικά προγράμματα μέσω του υπολογιστή τους, αποφεύγοντας έτσι την ανάγκη για κάποια συσκευή τηλεόρασης. Η ομάδα ανάπτυξης του Videolan ξεκίνησε να γράφει μία τυπική client/server λύση, η οποία λειτούργησε μερικώς μέχρι το τέλος του Από το 1998 το αρχικό project εξελίχθηκε και διασπάστηκε σε δύο νέα project το VideoLAN Client (VLC) και το VideoLAN Server (VLS). Τα νέα αυτά προγράμματα σχεδιάστηκαν από την αρχή και ήταν πλήρως συμβατά με τα πρότυπα ανάπτυξης του ανοιχτού λογισμικού. Κατά την ανάπτυξη των προγραμμάτων ιδιαίτερη προσοχή δόθηκε ώστε ο πηγαίος κώδικας να μπορεί να μεταγλωττιστεί τόσο σε linux όσο και σε άλλα λειτουργικά συστήματα όπως BeOS, ΜacOS X και Solaris. Οι πρώτες μεγάλης κλίμακας δοκιμές ξεκίνησαν το Νοέμβριο του 1999 και πραγματοποιούνταν με τη χρήση δεδομένων εισόδου μέσω του δικτύου. Η υποστήριξη αναπαραγωγής δίσκων DVD προστέθηκε αρκετά αργά, μόλις το Η μεγάλη άνθηση του project επήλθε το 2001 όταν ο διευθυντής του Ecole Centrale αποφάσισε να θέσει όλο το λογισμικό του VideoLAN υπό άδεια GPL. Η μετακίνηση αυτή επέτρεψε την ενασχόληση μεγάλου αριθμού ατόμων με το VLC από όλο το κόσμο, προσθέτοντας πολλά νέα χαρακτηριστικά. Επίσης, στο πλαίσιο αυτής της ανάπτυξης τον Ιούνιο του 2001 η ομάδα παρουσίασε και μια μεταφορά του προγράμματος στο περιβάλλον των Windows, με τη βοήθεια της πλατφόρμας cygwin. Στην τρέχουσα φάση του προγράμματος, η ομάδα ανάπτυξης του προγράμματος αποτελείται από 10 άτομα, ενώ πολλοί προγραμματιστές ανά το κόσμο καταθέτουν καθημερινά βελτιώσεις στον κώδικα του προγράμματος. Σταδιακά όμως, πριν από μερικά χρόνια, το project VideoLAN Server άρχισε να εγκαταλείπεται και οι δυνατότητες streaming να ενσωματώνονται στο VideoLAN Client. Ο κύριος λόγος που συνέβη αυτό ήταν διότι το VLC ήταν ένα πρόγραμμα με διπλό ρόλο, το οποίο λειτουργούσε τόσο ως streaming πελάτης στο VLS όσο και ως μια απλή εφαρμογή αναπαραγωγής μέσων όπως π.χ. ένα dvd. Εξαιτίας αυτού, το VLC είχε πιο πολύπλοκη αλλά και πιο εύκολα επεκτάσιμη δομή στον τομέα του ανοίγματος ρευμάτων αλλά και στην απόπλεξή τους. Το VLS, από την άλλη, εξαιτίας του ότι αναλάμβανε μόνο τη μετατροπή MPEG PS σε MPEG TS, ήταν αρκετά απλό στη δομή του. Αυτό είχε ως αποτέλεσμα πριν από μερικά χρόνια το project VLS να εγκαταλειφθεί και να χρησιμοποιείται το VLC στη θέση του. Τα τελευταία χρόνια το VLC έχει αποκτήσει μία πολύ καλή θέση στην αγορά των εφαρμογών πολυμέσων. Χρησιμοποιείται ευρέως από απλούς χρήστες, με πάνω από δέκα εκατομμύρια downloads τα τελευταία χρόνια, ενώ χρησιμοποιείται και σε πολλά προβλήματα πραγματικού κόσμου. Χαρακτηριστικά αναφέρουμε ότι το VLC χρησιμοποιείται από το πανεπιστήμιο Ecole Centrale για το διαμοιρασμό 100 τηλεοπτικών και ραδιοφωνικών καναλιών στους περίπου 1200 υπολογιστές που βρίσκονται στις εγκαταστάσεις του πανεπιστημίου. Επίσης, το VLC χρησιμοποιείται και από τη γαλλική εταιρία παροχής υπηρεσιών internet free ( για τη

45 μετάδοση υπηρεσίας ψηφιακής τηλεόρασης στους συνδρομητές της. Επίσης, υπάρχουν δύο εταιρίες, η anevia και η M2X, οι οποίες έχουν ιδρυθεί από άτομα που κατά καιρούς ασχολήθηκαν και ασχολούνται με το VLC και προσφέρουν συμβουλευτικές υπηρεσίες όσον αφορά εφαρμογές του VLC σε επαγγελματικά περιβάλλοντα. Στη παρούσα φάση το VideoLAN Client βρίσκεται στην έκδοση 0.8.5, ενώ σε πειραματικό στάδιο βρίσκεται η έκδοση Οι υπάρχουσες εκδόσεις υποστηρίζουν τα παρακάτω χαρακτηριστικά: inputs υποστηριζόμενα πρότυπα File, HTTP/FTP, UDP (unicast and multicast), DVD, DVB (satellite) κ.α. output input formats video codecs audio codecs subtitles outputs TCP/UDP Unicast/Multicast, RTP Unicast/Multicast, File, HTTP, MMSH κ.α. MPEG, AVI, ASF, MP4, mkv κ.α. MPEG-1, MPEG-2, MPEG-4, DivX 1/2/3, H264, Theora (με δικά του embeded codecs), WMV1/2, MJPEG κ.α. MPEG Layer 1, 2 και 3, AAC, ac3, Vorbis/Speex, FLAC κ.α. (με δικά του embeded codecs) local, UDP (unicat/multicast), RTP, HTTP, MMSH κ.α. Οι απαιτήσεις του προγράμματος σε πόρους συστήματος είναι αρκετά χαμηλές. Έτσι, για παράδειγμα, από την πλευρά του εξυπηρετητή οι απαιτήσεις εξαρτώνται από τις δυνατότητες που θέλουμε να χρησιμοποιήσουμε. Στο Ecole Centrale, για το διαμοιρασμό σήματος ψηφιακής τηλεόρασης, όπως λαμβάνεται από την κάρτα τηλεόρασης στο δίκτυο της σχολής χρησιμοποιούνται απλοί υπολογιστές με επεξεργαστή PENTIUM I. Βέβαια, από την άλλη, αν είναι απαραίτητη η συμπίεση του σήματος σε πραγματικό χρόνο με βάση το πρωτόκολλο MPEG-4 και ο διαμοιρασμός του, απαιτείται τουλάχιστον ένας πιο σύγχρονος υπολογιστής με επεξεργαστή PENTIUM III στα 1,5 Mhz. Επίσης, το πρόγραμμα προσφέρει τη δυνατότητα VLM, που χρησιμοποιεί και η εφαρμογή μας, η οποία επιτρέπει την ταυτόχρονη αποστολή πολλαπλών διαφορετικών μέσων ταυτόχρονα από μια μόνο διεργασία του VLC. Συγκεκριμένα, με δοκιμές που έκανε η ομάδα ανάπτυξης, το VLC μπορεί να αποστέλλει ταυτόχρονα μέχρι 30 διαφορετικά μέσα χωρίς κανένα πρόβλημα VLC API Το πρόγραμμα VideoLAN Client, που αποτέλεσε τη βάση της εφαρμογής μας, δομείται γύρω από τη βιβλιοθήκη LibVLC. Η βιβλιοθήκη LibVLC είναι η καρδιά του project και προσφέρει μία διεπαφή για πολλές από τις δυνατότητές του όπως τα stream access, audio και video output, plugin handling και thread system. Όλα τα αρχεία υλοποίησης της βιβλιοθήκης βρίσκονται στο φάκελο /src. Στο φάκελο αυτό επίσης περιλαμβάνονται δύο πολύ σημαντικά αρχεία, το αρχείο vlc.c και το libvlc.c. Το πρώτο αρχείο υλοποιεί το πρόγραμμα vlc, κάνοντας κλήσεις στη βιβλιοθήκη libvlc, ενώ το δεύτερο αρχείο υλοποιεί τις συναρτήσεις που αποτελούν τη διεπαφή της libvlc. Επίσης, ο φάκελος src/ περιλαμβάνει και τους εξής υποφακέλους: interface: ο φάκελος αυτός περιέχει κώδικα για τη διαχείριση των αλληλεπιδράσεων του προγράμματος με το χρήστη αλλά και με τις συσκευές του υπολογιστή. audio_output: ο φάκελος αυτός περιέχει κώδικα για τη διαχείριση των διαφόρων module ήχου για την αρχικοποίηση του συστήματος ήχου και την αλληλεπίδραση του προγράμματος με αυτό ( καθορισμός έντασης ήχου κ.α. ). extras: ο φάκελος αυτός περιλαμβάνει κάποιον extra κώδικα που υλοποιεί κάποιες

46 αναγκαίες συναρτήσεις που σε μερικές πλατφόρμες δεν είναι διαθέσιμες. Συγκεκριμένα, πρόκειται για την υλοποίηση κάποιων διαδικασιών τις βιβλιοθήκης libc. input: ο φάκελος αυτός περιλαμβάνει κώδικα για τη διαχείριση των input module. Συγκεκριμένα, ο κώδικας του φακέλου αναλαμβάνει να αρχικοποιήσει τα input module, να διαβάσει τα ρεύματα και να αποστείλει τελικά τα στοιχειώδη ρεύματα στους αποκωδικοποιητές. misc: ο φάκελος αυτός περιλαμβάνει υλοποιήσεις για κάποιες δυνατότητες που είναι χρήσιμες σε κάποια κομμάτια της libvlc. Τέτοιες δυνατότητες είναι για παράδειγμα το σύστημα νημάτων, το σύστημα της ουράς μηνυμάτων, η αναγνώριση των δυνατοτήτων της CPU κ.α. playlist: ο φάκελος αυτός περιλαμβάνει κώδικα για τις βασικές αλληλεπιδράσεις διαχείρισης της λίστας αναπαραγωγής, όπως τα stop, play, next κ.α. stream_output: ο φάκελος αυτός περιλαμβάνει κώδικα για τη διαχείριση των output module του vlc. Επίσης, περιλαμβάνει και την υλοποίηση κάποιων υπηρεσιών δικτύου όπως το πρωτόκολλο sap. video_output: o φάκελος αυτός περιέχει κώδικα για την αναπαραγωγή του βίντεο από τον υπολογιστή. Η χρήση της βιβλιοθήκης είναι σχετικά απλή για την αναπαραγωγή ενός μέσου. Μια τυπική εκτέλεση του VLC βασίζεται στην κλήση τριών συναρτήσεων από τη βιβλιοθήκη. Αρχικά, θα πρέπει να γίνει μια κλήση στη συνάρτηση VLC_Create, η οποία δημιουργεί και αρχικοποιεί τη βασική δομή της βιβλιοθήκης. H συνάρτηση δημιουργεί τα δύο βασικά αντικείμενα του προγράμματος, το vlc και το libvlc, ενώ παράλληλα εντοπίζονται οι δυνατότητες του επεξεργαστή και αρχικοποιείται το σύστημα διαχείρισης των modules. Στη συνέχεια, το πρόγραμμα καλεί τη VLC_Init η οποία αρχικοποιεί τη βιβλιοθήκη του vlc με βάση τις παραμέτρους της γραμμής εντολών, ενεργοποιώντας τα κατάλληλα modules. Στη φάση αυτή, για παράδειγμα, το πρόγραμμα αρχικοποιεί το σύστημα διαχείρισης νημάτων, εντοπίζει όλα τα διαθέσιμα modules στους φακέλους.,./lib και /usr/local/lib/videolan/vlc κ.α. Η κύρια διαδικασία εκτέλεσης του προγράμματος ξεκινά με την κλήση στη συνάρτηση VLC_AddIntf. Η συνάρτηση αυτή λαμβάνει τέσσερα ορίσματα, το id του κύριου vlc αντικειμένου, το οποίο λάβαμε από την κλήση της VLC_Create, το όνομα του module διεπαφής που θέλουμε να φορτωθεί, μία boolean τιμή που καθορίζει αν η κλήση αυτή θα μπλοκάρει την εκτέλεση του νήματος μέχρι να ληφθεί ένα σήμα τερματισμού από τη βιβλιοθήκη και μια boolean τιμή, η οποία καθορίζει αν το πρόγραμμα θα ξεκινήσει απευθείας την αναπαραγωγή της λίστας. Η κλήση αυτή ξεκινά τη διαδικασία φόρτωσης των αναγκαίων module του VLC και επιτρέπει στα modules της διεπαφής να καθορίσουν τη συνέχεια της εκτέλεσης του προγράμματος. Η αρχιτεκτονική της διαδικασίας ενεργοποίησης των διάφορων modules εμφανίζεται και στην εικόνα 11. Όπως φαίνεται και στην εικόνα, η φόρτωση και αρχικοποίηση των διαφόρων modules ακολουθεί μία δομημένη διαδικασία. Σε μία τυπική εκτέλεση του προγράμματος, τα πρώτα modules που φορτώνονται είναι αυτά που χειρίζονται τη διεπαφή του χρήστη με το πρόγραμμα. Συνήθως, το πρόγραμμα δημιουργεί ένα νέο νήμα για κάθε module που φορτώνεται και συνήθως τα νήματα αυτά ελέγχουν περιοδικά αν υπήρξε κάποια αλληλεπίδραση με το χρήστη. Επίσης, στο στάδιο αυτό δημιουργείται και ένα νέο νήμα το οποίο διαχειρίζεται τη playlist του προγράμματος. Το νήμα αυτό εκτελεί τη συνάρτηση RunThread του αρχείου src/playlist/playlist.c. Η συνάρτηση εκτελεί ένα αέναο loop, στο οποίο ελέγχει καταρχήν αν η λίστα είναι ενεργή και κατά δεύτερον αν το τρέχον μέσον στην playlist έχει ολοκληρωθεί, οπότε και καλεί τις κατάλληλες συναρτήσεις για να καταστραφούν όλες οι δομές που χρησιμοποιούνταν από το παλαιό μέσο και να φορτωθεί το επόμενο στη σειρά.

47 Εικόνα 11: Αρχιτεκτονική συστήματος διαχείρισης modules του VLC Στην περίπτωση που κάποιο νέο μέσο πρέπει να φορτωθεί, η βιβλιοθήκη δημιουργεί κάθε φορά ένα νέο νήμα το οποίο διαχειρίζεται τη διαδικασία ανάγνωσης του μέσου. Το νήμα αυτό εκτελεί έναν αέναο βρόχο κατά τον οποίο χρησιμοποιεί συνήθως κάποια modules για την ανάγνωση του μέσου, την απόπλεξή του και την παραγωγή στοιχειωδών ρευμάτων. Για την επικοινωνία μεταξύ τους, τα modules έχουν κάποιες FIFO ουρές τις οποίες μοιράζονται και στις οποίες αποθηκεύουν τοπικά σε block τα δεδομένα που παράγονται σε κάθε φάση. Στη φάση αυτή, επίσης, το πρόγραμμα ελέγχει αν ο χρήστης έχει καθορίσει και κάποια παράμετρο για τη μετάδοση του μέσου μέσω δικτύου. Στην περίπτωση αυτή φορτώνονται και κάποια ακόμα modules για την επανακωδικοποίηση, την πολύπλεξη και την αποστολή του κάθε ρεύματος. Επίσης, δημιουργείται ένα νέο νήμα το οποίο ασχολείται αποκλειστικά με τη μετάδοση των ρευμάτων του μέσου. Παράλληλα, το πρόγραμμα αρχικοποιεί κάποιες δομές οι οποίες αποθηκεύουν πληροφορίες για το περιεχόμενο και την κατάσταση των θεμελιωδών ρευμάτων. Οι δομές αυτές χρησιμοποιούνται και από τα modules που είναι υπεύθυνα για την αναπαραγωγή των θεμελιωδών ρευμάτων καθιστώντας δυνατή με τον τρόπο αυτό την μεταξύ τους επικοινωνία. Το σύστημα διαχείρισης των ρευμάτων εισόδου είναι υπεύθυνο επίσης και για την εύρεση των κατάλληλων modules για την αποκωδικοποίηση των ρευμάτων του μέσου. Η επιλογή του κατάλληλου module γίνεται είτε διαβάζοντας τα μεταδεδομένα του ρεύματος του μέσου, είτε ζητώντας πληροφορίες από τον εξυπηρετητή που διαμοιράζει το μέσο. Τα module αποσυμπίεσης είναι παράλληλα υπεύθυνα και για την αρχικοποίηση των κατάλληλων module για την αναπαραγωγή του βίντεο και της εικόνας. Τα module αυτά είναι υπεύθυνα για την επικοινωνία του προγράμματος με τους οδηγούς της κάρτας γραφικών και της κάρτας ήχου, για τη σωστή αναπαραγωγή του ήχου και της εικόνας. Τα module αυτά χρησιμοποιούν κάποιες FIFO ουρές, οι οποίες γεμίζουν με δεδομένα από τα module αποσυμπίεσης των ρευμάτων. Τα module, λοιπόν, αναπαραγωγής των δεδομένων απλώς αναζητούν στην ουρά αυτή αν βρίσκεται το επόμενο καρέ ή το επόμενο κομμάτι ήχου συγκεκριμένης διάρκειας και το αποστέλλουν στο κατάλληλο υλικό. Το πρόγραμμα για την αναπαραγωγή του ήχου και της εικόνας συνήθως δημιουργεί νέα νήματα. Ο τρόπος λειτουργίας της LibVLC, όπως φαίνεται και από τη μικρή παρουσίαση που πραγματοποιήθηκε παραπάνω, είναι αρκετά δομημένος αλλά και επεκτάσιμος. Η διαδικασία ανάπτυξης κάποιου module είναι εξίσου δομημένη και θα την παρουσιάσουμε σε γενικές γραμμές

48 στη συνέχεια Modules Ο κώδικας των modules του VLC βρίσκεται στο φάκελο modules/ του πηγαίου κώδικα. Κάθε module μπορεί να προσφέρει διαφορετικές δυνατότητες, οι οποίες καλύπτουν τις ανάγκες ενός συγκεκριμένου μέσου ή σε κάποιες περιπτώσεις τις ανάγκες κάποιου συγκεκριμένου περιβάλλοντος. Εξάλλου, η περισσότερη δουλειά για τη μεταφορά του VLC σε μία νέα πλατφόρμα συνήθως επικεντρώνεται στη συγγραφή κατάλληλων module για την επικοινωνία του προγράμματος με το σύστημα ήχου και εικόνας του αντίστοιχου περιβάλλοντος. Η διαχείριση των module γενικά υλοποιείται από τον κώδικα του αρχείου src/misc/modules.c καθώς και στα header αρχεία include/modules.h και include/modules_inner.h. Το αρχείο modules.c υλοποιεί τις βασικές συναρτήσεις για την αρχικοποίηση και την καταστροφή των δομών που χειρίζονται τα modules. Συγκεκριμένα, για τη διαχείριση των module στο αρχείο modules.h ορίζεται η δομή module_bank_t, η οποία περιέχει μια συνδεδεμένη λίστα με τα στοιχεία των διαθέσιμων module που διαθέτει το πρόγραμμα, ενώ καθορίζεται και η δομή module_t, η οποία χρησιμοποιείται για την αποθήκευση των αναγκαίων πληροφοριών για το κάθε module. Επίσης, στο αρχείο αυτό υλοποιούνται οι συναρτήσεις module_initbank, module_loadbuiltins και module_loadplugins, οι οποίες αναζητούν δεδομένα στους καταλόγους που περιγράψαμε παραπάνω και γεμίζουν τη δομή module_bank_t του αντικειμένου libvlc_t με τα στοιχεία του κάθε module. Παράλληλα, για την καταστροφή της δομής και την απελευθέρωση των πόρων μνήμης καθορίζεται η συνάρτηση module_endbank. Στα αρχεία αυτά, βέβαια, οι σημαντικότερες συναρτήσεις για τη διαχείριση των module, είναι η module_need και η module_unneed. Η πρώτη συνάρτηση χρησιμοποιείται για την αναζήτηση κάποιου module που απαιτεί το πρόγραμμά μας και τη φόρτωσή του, ενώ, αντίθετα, η δεύτερη συνάρτηση χρησιμοποιείται για την ελευθέρωση των δομών που χρησιμοποιούνται από κάποιο module. Η αναζήτηση ενός module γίνεται με βάση το όνομά του και τις δυνατότητες που θέλουμε να έχει. Το πρόγραμμα τότε αναζητά από τα διαθέσιμα module αυτό που καλύπτει καλύτερα τις ανάγκες και επιστρέφει μία δομή module_t ή διαφορετικά μια τιμή NULL. Όπως είδαμε στην παρουσίαση του τρόπου λειτουργίας της βιβλιοθήκης, το πρόγραμμα ακολουθεί μια αρθρωτή προσέγγιση για την αναπαραγωγή μέσων. Σύμφωνα με αυτήν την προσέγγιση, το πρόγραμμα καθορίζει ακριβώς τις διαθέσιμες κατηγορίες και υποκατηγορίες στις οποίες μπορεί να ανήκει ένα module. Η κατηγορία που θα επιλεγεί να ανήκει ένα νέο module, θα καθορίσει επακριβώς τη γενική του δομή, καθώς και τις αλληλεπιδράσεις που θα έχει με το υπόλοιπο σύστημα. Γι' αυτόν το λόγο είναι απαραίτητο ο προγραμματιστής να γνωρίζει επακριβώς τις δυνατότητες που θέλει να καλύψει. Οι κατηγορίες που καθορίζονται στο VLC και θα πρέπει να ανήκει ένα module είναι: CAT_INTERFACE: πρόκειται για modules τα οποία υλοποιούν κάποια από τις δυνατότητες διεπαφής του προγράμματος. CAT_AUDIO: Τα modules αυτά υλοποιούν την επικοινωνία του προγράμματος με τους drivers του συστήματος ήχου του υπολογιστή. Πέρα βέβαια από την επικοινωνία, τα modules αυτά μπορεί να υλοποιούν κάποιο φίλτρο ήχου ή κάποια οπτικοποίηση των διακυμάνσεων του ήχου (scope, spectogram κ.α.). CAT_VIDEO: Τα video modules χρησιμοποιούνται γενικά από το πρόγραμμα για την αναπαραγωγή του ρεύματος video από την κάρτα γραφικών του προγράμματος. Πέρα από την αναπαραγωγή ρευμάτων video, τέτοια modules μπορεί να υλοποιούν και την αναπαραγωγή του ρεύματος υποτίτλων του μέσου ή την εφαρμογή κάποιου φίλτρου στο video. CAT_INPUT: Η κατηγορία αυτή περιλαμβάνει ένα μεγάλο αριθμό διαφορετικών module, τα οποία χρησιμοποιούνται στις διάφορες φάσεις της ανάγνωσης των ρευμάτων κάποιου μέσου και στην αποσυμπίεσή του. Έτσι λοιπόν, στην κατηγορία αυτή περιλαμβάνονται module για την πρόσβαση σε κάποιο μέσο και την απόπλεξη και αποσυμπίεση των επιμέρους ρευμάτων

49 του μέσου αυτού. CAT_SOUT: Η κατηγορία αυτή περιλαμβάνει τα modules, τα οποία χρησιμοποιούνται για τη μετάδοση ενός μέσου. Τέτοια modules μπορούν να υλοποιούν την πολύπλεξη, την αποστολή, την πακετοποίηση των δεδομένων κ.α. CAT_ ADVANCED: Τα modules αυτού του τύπου υλοποιούν κυρίως εργασίες, οι οποίες δεν ανήκουν τυπικά στις δυνατότητες ενός συστήματος αναπαραγωγής μέσων. Τέτοιες δυνατότητες είναι η αναγνώριση του τύπου του επεξεργαστή, η δυνατότητα ανάγνωσης κειμένων συνταγμένων με βάση το πρωτόκολλο XML για την ανάγνωση μεταδεδομένων από κάποιο ρεύμα κ.α. CAT_PLAYLIST: Στην κατηγορία αυτή η ομάδα ανάπτυξης κατατάσσει κυρίως modules τα οποία διαχειρίζονται τη λίστα αναπαραγωγής του VLC. Από την παραπάνω παρουσίαση γίνεται εμφανές ότι η κατηγορία στην οποία ανήκει ένα module καθορίζει σε μεγάλο βαθμό τη δομή του, καθώς κάθε κατηγορία καθορίζει κάποιες συγκεκριμένες συναρτήσεις που θα πρέπει να υλοποιούνται από το module. Για τη συγγραφή ενός module, το VLC API καθορίζει μια δεδομένη δομή για το αρχείο κώδικα. Ο προγραμματιστής θα πρέπει αρχικά να καθορίσει τα header αρχεία στα οποία γίνονται αναφορές από το κώδικα μας. Τα βασικά header αρχεία του vlc βρίσκονται στο φάκελο include του πηγαίου κώδικα. Από τα αρχεία αυτά ιδιαίτερο ενδιαφέρον παρουσιάζουν τα header αρχεία με δομή vlc_*.h. Τα αρχεία αυτά αντιστοιχούν σε κάποια υποκατηγορία module και περιγράφουν το βασικό σκελετό του module. Στη συνέχεια, μετά τη δήλωση των header αρχείων που θα πρέπει να συμπεριληφθούν κατά τη μεταγλώττιση του προγράμματος, ο προγραμματιστής θα πρέπει να περιγράψει τα γενικά χαρακτηριστικά του module. Τα χαρακτηριστικά που θα πρέπει να καθοριστούν είναι η κατηγορία και υποκατηγορία του module, το όνομά του, οι συναρτήσεις αρχικοποίησης και τερματισμού του module καθώς και τα χαρακτηριστικά που μπορούν να καθοριστούν από τη γραμμή εντολών. Για την περιγραφή όλων αυτών των χαρακτηριστικών, το VLC διαθέτει συγκεκριμένες μακροεντολές στο αρχείο modules_inner.h. Ο ορισμός των modules θα πρέπει υποχρεωτικά να περικλείεται από τις συναρτήσεις vlc_module_begin() και vlc_module_end(). Η πρώτη συνάρτηση αρχικοποιεί κάποια από τα πεδία της δομής p_module, ενώ η δεύτερη συνάρτηση δημιουργεί ένα αντίγραφο της δομής και το επιστρέφει στη συνάρτηση που δημιούργησε το module. Ενδιάμεσα των δύο αυτών μακροεντολών ο προγραμματιστής αρχικά πρέπει να καθορίσει ένα string με την πλήρη περιγραφή του module με τη χρήση της συνάρτησης set_description() καθώς και το σύντομο όνομα του με τη set_shortname(), ενώ θα πρέπει να καθοριστεί και η κατηγορία και η υποκατηγορία με τη set_category και set_subcategory. Στη συνέχεια, θα πρέπει να καθορίσουμε με ένα string τις δυνατότητες που θα έχει το module με τη μακροεντολή set_capability. Το στοιχείο αυτό είναι απαραίτητο, καθώς με βάση το string αυτό, αλλά και την κατηγορία στην οποία ανήκει το module γίνεται η αναζήτησή του. Το πιο σημαντικό κομμάτι στη δήλωση του module είναι ο καθορισμός των παραμέτρων που δέχεται το module κατά τη φόρτωσή του. Ο προγραμματιστής, γενικά, έχει μία ποικιλία στις κατηγορίες μεταβλητών που μπορεί να χρησιμοποιήσει, καθώς μπορεί να χρησιμοποιήσει τόσο απλούς τύπους, όπως ακέραιους, string, δεκαδικούς και boolean όσο και ειδικούς τύπους, όπως αρχεία και φακέλους στο σύστημα αρχείων του υπολογιστή, καθώς και άλλα modules. Στο τέλος της διαδικασίας καθορισμού του module καθορίζουμε επίσης τις συνάρτησεις ενεργοποίησης και απενεργοποίησης του module. Οι συναρτήσεις αυτές συνήθως ονομάζονται Open και Close. Στη συνέχεια του αρχείου ο προγραμματιστής θα πρέπει να καθορίσει τις βασικές δομές του module. Οι δομές αυτές χρησιμοποιούνται από τα module για τη, μοντελοποίηση των δεδομένων που διαχειρίζονται και ποικίλουν ανάλογα με τη χρηστικότητα του module. Μια βασική δομή που καθορίζεται από κάθε module είναι η δομή *_sys_t, όπου το * συμβολίζει το όνομα της υποκατηγορίας του module. Η δομή αυτή χρησιμοποιείται για την αποθήκευση των διαφόρων μεταβλητών που μπορεί να χρησιμοποιεί το module. Τη δομή αυτή χρησιμοποιήσαμε εκτενώς και στην εφαρμογή μας για την αποθήκευση, για παράδειγμα, των κλειδιών της κρυπτογράφησης και

50 των υπόλοιπων αναγκαίων χαρακτηριστικών από το module απόπλεξης ρευμάτων μεταφοράς. Το αντικείμενο αυτό ορίζεται σαν ένα είδος abstract δομής με τη βοήθεια μίας μακροεντολής #DEFINE *_sys_t *_sys_t;. Με αυτό το τρόπο το σύμβολο της δομής ορίζεται, αλλά οι λεπτομέρειές του καθορίζονται στον πηγαίο κώδικα του κάθε module. Επίσης, στα περισσότερα module καθορίζεται και μια δομή *_t, όπου με το * συμβολίζουμε και πάλι το όνομα της υποκατηγορίας του module. H δομή αυτή είναι κοινή για όλα τα module της κατηγορίας και καθορίζει κάποια βασικά χαρακτηριστικά τους. Τα βασικά πεδία που περιλαμβάνει είναι κάποιοι δείκτες σε άλλες δομές *_t με τις οποίες είναι απαραίτητο να επικοινωνεί το module μας, κάποιοι δείκτες στις βασικές συναρτήσεις που θα πρέπει να υλοποιεί, καθώς και κάποια χαρακτηριστικά της συγκεκριμένης υποκατηγορίας, τα οποία είναι κοινά και υποχρεωτικά για όλα τα module που περιέχει (π.χ. στη κατηγορία sout mux κοινό χαρακτηριστικό μεταξύ των module είναι το αν υποστηρίζεται η δυναμική προσθήκη νέων ρευμάτων κατά την απόπλεξη). Ο ορισμός των δομών *_t σε κάθε περίπτωση περιλαμβάνεται στο αντίστοιχο header αρχείο που έχει δημιουργηθεί για κάθε υποκατηγορία module. Μετά τον καθορισμό των δομών που θα περιλαμβάνει το module, ο προγραμματιστής θα πρέπει να συνεχίσει με την ανάπτυξη του κυρίως μέρους των συναρτήσεων του module. Στην ανάπτυξη των συναρτήσεων σημαντική είναι η υλοποίηση των συναρτήσεων που καθορίζονται στα header αρχεία του προγράμματος. Για παράδειγμα, για κάθε module της κατηγορίας sout mux θα πρέπει υποχρεωτικά να υλοποιείται η συνάρτηση mux, η οποία θα αναλαμβάνει να αποπλέκει το ρεύμα δεδομένων και να τροφοδοτεί με δεδομένα τα στοιχειώδη ρεύματα του MPEG-2. Από τις διάφορες συναρτήσεις που θα περιγράφονται στα header αρχεία μεγάλο ενδιαφέρον παρουσιάζουν οι συναρτήσεις Open, Close και Control. Η συνάρτηση Open καλείται συνήθως μετά τη φόρτωση ενός module και περιλαμβάνει στον κώδικά της το διάβασμα των τιμών που δόθηκαν στη γραμμή εντολών και αφορούν το συγκεκριμένο module, καθώς και την αρχικοποίηση των δομών του module και τη φόρτωση τυχόν άλλων module που μπορεί να απαιτούνται. Η συνάρτηση Close από την άλλη, αναλαμβάνει την απελευθέρωση της μνήμης που έχει δεσμευτεί από το module έτσι ώστε να μην υπάρχουν προβλήματα διαρροής μνήμης από το πρόγραμμά μας. Τέλος, η συνάρτηση Control επιτρέπει σε άλλα module ή στο κυρίως πρόγραμμα να κάνει ερωτήσεις ή να καθορίζει τις λεπτομέρειες της εσωτερικής κατάστασης ενός module. Για τη μεταγλώττιση του πηγαίου κώδικα ενός module η ομάδα του VLC έχει αναπτύξει ένα πολύ καλό σύστημα, βασισμένο στο automake του GNU. Για τη μεταγλώττιση λοιπόν ενός module σε πρώτη φάση θα πρέπει να καθορίσουμε στο σύστημα παραγωγής των δυαδικών αρχείων τί θέλουμε να παράγουμε και με βάση ποιά αρχεία πηγαίου κώδικα. Για το λόγο αυτό θα πρέπει στο αρχείο configure.am (αν ο φάκελος είναι καινούργιος και δεν περιέχει κάποιο φάκελο configure.am τότε αρκεί να δημιουργήσουμε εμείς ένα) να εισάγουμε στο τέλος μια γραμμή: SOURCES_yourmodule = myfile1.c myfile2.c, στην οποία καθορίζουμε ότι το πρόγραμμα θα πρέπει να παράγει ένα αρχείο yourmodule.so ή yourmodule.dll, ανάλογα με το περιβάλλον ανάπτυξης, με βάση τα αρχεία πηγαίου κώδικα myfile1.c και myfile2.c. Με βάση λοιπόν τις αλλαγές, στη συνέχεια θα πρέπει να τρέξουμε την εντολή./bootstrap για να παραχθούν τα Makefiles του κάθε καταλόγου, με βάση τα οποία θα γίνει η μεταγλώττιση του προγράμματος. Για την απλή παραγωγή λοιπόν ενός module, ο χρήστης αρκεί να δώσει στη γραμμή εντολών make yourmodule.so. Για την προσθήκη βέβαια περαιτέρω δυνατοτήτων ο προγραμματιστής θα πρέπει να εισάγει περισσότερες πληροφορίες.

51 3. Σχεδίαση

52 3.1 Αρχιτεκτονική Το CDN, με βάση τις τελευταίες τεχνολογικές εξελίξεις στο χώρο των υπηρεσιών διαδικτύου, έχει ως στόχο να αποτελέσει μία ολοκληρωμένη υλοποίηση ανοιχτού κώδικα ενός μοντέρνου συστήματος διαδικτυακής τηλεόρασης. Το σύστημα θα περιλαμβάνει δυνατότητες, τόσο για ταυτόχρονη μετάδοση του ρεύματος σε πολλαπλούς χρήστες, όσο και δυνατότητα video on demand με τη χρήση RTSP server. Επίσης, στο σύστημα προσθέτουμε μία νέα υπηρεσία, το near video on demand. Στην υπηρεσία αυτή οι εγγεγραμμένοι χρήστες μπορούν να ψηφίσουν τι θα ήθελαν να δουν σε κάποια χρονική ζώνη μέσα από ένα σύνολο ταινιών και προγραμμάτων, δίνοντάς τους έτσι δυνατότητες ανάδρασης με το κανάλι. Με βάση το αποτέλεσμα της ψηφοφορίας το σύστημά μας καθορίζει το περιεχόμενο του προγράμματος. Το σύστημα CDN είναι ένα σύστημα συνδρομητικής τηλεόρασης, που χρησιμοποιεί αποκλειστικά λογισμικό, τόσο στην πλευρά του εξυπηρετητή όσο και από την πλευρά του πελάτη. Η ανάπτυξή του CDN ξεκίνησε το 2005 στα πλαίσια της πτυχιακής εργασίας των φοιτητών του τμήματος πληροφορικής. Στόχος του project είναι η δημιουργία ενός ερευνητικού συστήματος με δυνατότητες εφαρμογής του σε εμπορικά περιβάλλοντα, το οποίο θα καλύπτει πλήρως τις ανάγκες ενός συνδρομητικού καναλιού. Το πρόγραμμα παράλληλα χρησιμοποιεί σε μεγάλο βαθμό και τις δυνατότητες αμφίδρομης επικοινωνίας, που μπορεί να έχει ένας πελάτης σε ένα δίκτυο tcp / ip και παρέχει επίσης τη δυνατότητα ανάδρασης των πελατών μέσω υπηρεσιών near video on demand. Την τρέχουσα περίοδο το σύστημα βρίσκεται ακόμα σε φάση ανάπτυξης και δεν είναι ακόμα πλήρως λειτουργικό. Παρόλα αυτά, μεγάλα κομμάτια του έχουν ήδη υλοποιηθεί. Η αρχιτεκτονική του CDN προσπαθεί σε μεγάλο βαθμό να καλύψει όσο γίνεται πληρέστερα τις ανάγκες ενός συστήματος διαδικτυακής τηλεόρασης. Στη λύση που προτείνεται λαμβάνονται υπόψιν, τόσο οι κλασσικές περιπτώσεις του εξυπηρετητή και των πελατών, όσο και άλλες οντότητες που συμμετέχουν έμμεσα στην υπηρεσία, όπως η περίπτωση των εταιριών παροχής των υπηρεσιών (εταιρίες διανομής ταινιών, εταιρίες παραγωγής τηλεοπτικών προγραμμάτων κ.α.). Η αρχιτεκτονική του CDN παρουσιάζεται στην εικόνα 1. Το σύστημα συνολικά αποτελείται από 4 οντότητες με διακριτούς στόχους και ρόλους, οι οποίες επικοινωνούν μεταξύ τους. Η επικοινωνία γίνεται μέσω οποιουδήποτε δικτύου, το οποίο όμως πρέπει να βασίζεται στο πρωτόκολλο tcp / ip και το οποίο θα επιτρέπει την αμφίδρομη και ικανοποιητική επικοινωνία μεταξύ δύο οποιονδήποτε οντοτήτων. Οι 4 οντότητες που αποτελούν το σύστημα είναι οι εξής: Transcoder Η οντότητα του transcoder αναλαμβάνει την ταξινόμηση και αποθήκευση των διαθέσιμων ταινιών και τη διάθεσή τους στο streamer όταν αυτός τις ζητήσει. Σε πραγματικές συνθήκες η οντότητα αυτή μπορεί να αντιπροσωπεύει μια εταιρία διανομής ταινιών ή το τμήμα αρχειοθέτησης του σταθμού. Οι κυριότερες αλληλεπιδράσεις της οντότητας αυτής με το υπόλοιπο σύστημα είναι να ενημερώνει το streamer για τις διαθέσιμες ταινίες και να του παρέχει όποια ταινία ζητά από αυτές που διαθέτει στο κατάλληλο format. O streamer διαθέτει μια εσωτερική βάση δεδομένων, στην οποία περιλαμβάνει πληροφορίες για κάθε ταινία που διαθέτει. Οι βασικές πληροφορίες που αποθηκεύει για κάθε ταινία είναι το όνομά της, η διάρκεια, μία σύντομη παρουσίαση, καθώς και κάποια σύνδεση με την εφαρμογή imdb από όπου ο χρήστης μπορεί να βρει περισσότερες πληροφορίες. Για κάθε νέα ταινία που εισάγεται, αποστέλλεται αυτόματα και μία αναφορά στο streamer με κάποια βασικά στοιχεία για αυτήν καθώς και την περίοδο μέσα στην οποία θα μπορεί να διαθέτει την ταινία αυτή. Τα στοιχεία αυτά αποστέλλονται μέσω χρησιμοποιώντας xml κωδικοποίηση στο σώμα του μηνύματος. Από εκεί ο streamer με κατάλληλη επεξεργασία ξεχωρίζει τις αναγκαίες πληροφορίες από το και τις αποθηκεύει. Ο streamer έχει επίσης τη δυνατότητα να ζητά κάποια από τις ταινίες του transcoder. Τα αρχεία αυτά μπορεί να είναι αποθηκευμένα στον transcoder σε διάφορες μορφές (DVD, λήψη DVB

53 προγράμματος, κασέτες VHS). Από τη συλλογή αυτή, ο streamer μπορεί να επιλέξει και να ζητήσει όποια ταινία επιθυμεί. Σε κάθε αίτηση ο transcoder οφείλει να κωδικοποιήσει την ταινία σε μορφή σύμφωνη με το πρωτόκολλο Η.264 και να τη μεταφέρει μέσω του δικτύου στο streamer. Η μεταφορά μπορεί να γίνεται και real time και απλά ο streamer να λαμβάνει το ρεύμα δεδομένων της ταινίας και να το μοιράζει στη συνέχεια στους χρήστες.

54 Εικόνα 1: Αρχιτεκτονική συστήματος CDN

55 Web Server Η οντότητα του web server αποτελεί την κύρια οντότητα διαχείρισης του συστήματος. Αναλαμβάνει την ενημέρωση των χρηστών για τις διαθέσιμες ταινίες και για το πρόγραμμα του σταθμού ενώ παράλληλα καθορίζει το πρόγραμμα του κάθε σταθμού προγραμματίζοντας στον streamer τις ταινίες που πρόκειται να διαμοιράσει. Επίσης, διαχειρίζεται τους πελάτες του συστήματος, καθώς και το σύστημα χρέωσής τους. Η οντότητα του web server αποτελείται από μία διαδικτυακή εφαρμογή γραμμένη σε php. Για τη φύλαξη των δεδομένων το πρόγραμμα χρησιμοποιεί μία βάση MySQL, στην οποία αποθηκεύει τα αναγκαία δεδομένα. Τα βασικά στοιχεία που διαχειρίζεται είναι τα στοιχεία των εγγεγραμμένων πελατών, καθώς και το ιστορικό σύνδεσης και χρήσης του CDN, ενώ διατηρεί και τα στοιχεία των διαθέσιμων ταινιών, όπως τα λαμβάνει από τον streamer. Η εφαρμογή νοητικά χωρίζεται σε δύο βασικά κομμάτια, τη διεπαφή των χρηστών και τη διεπαφή του διαχειριστή. Στη διεπαφή του χρήστη, οι χρήστες μπορούν να ενημερωθούν για το πρόγραμμα του σταθμού και τις ταινίες που πρόκειται να δουν. Σε κάθε τέτοια σελίδα το πρόγραμμα δίνει κατάλληλα url, με τα οποία ο χρήστης μπορεί να φορτώσει έναν ενσωματωμένο στην ιστοσελίδα αναπαραγωγέα μέσων και να παρακολουθήσει το κάθε κανάλι. Ειδικότερα, για video on demand ο χρήστης μπορεί να ελέγχει την αναπαραγωγή των μέσων μέσω της ιστοσελίδας. Η εφαρμογή, όπως είπαμε και στην εισαγωγή του κεφαλαίου, υποστηρίζει και μία νέα υπηρεσία, το near video on demand. Με την υπηρεσία αυτή κάθε χρήστης μπορεί να συμμετέχει στον καθορισμό του προγράμματος του σταθμού. Το τελικό πρόγραμμα διαμορφώνεται μέσω ψηφοφορίας μεταξύ των χρηστών του συστήματος. Οι διαθέσιμες ταινίες που μπορούν να επιλέξουν καθορίζονται από το διαχειριστή του συστήματος και οι χρήστες μπορούν επιλέξουν κάποια από αυτές. Η διεπαφή διαχείρισης του συστήματος δίνει τη δυνατότητα ελέγχου των παραμέτρων του συστήματος, ενώ παράλληλα επιτρέπει την παρακολούθηση της απόδοσης. Streamer Η οντότητα του streamer αναλαμβάνει τη μετάδοση ενός μέσου στους χρήστες. Η οντότητα αυτή στον πραγματικό κόσμο της εφαρμογή μας αντιστοιχεί στο τμήμα μετάδοσης του καναλιού και μπορεί να αντιστοιχεί σε κάποια εταιρία παροχής internet. Οι κυριότερες αλληλεπιδράσεις της οντότητας είναι με το web server, ο οποίος καθορίζει το πρόγραμμα του καναλιού που θα διαμοιραστεί, με τον transcoder, από τον οποίο λαμβάνει τα μέσα που πρόκειται να μοιραστούν, καθώς και με τους πελάτες, στους οποίους μεταδίδει τα ρεύματα δεδομένων. O streamer διαθέτει και αυτός εσωτερικά μια βάση δεδομένων με τα στοιχεία του προγράμματος του καναλιού. Συγκεκριμένα, η βάση περιλαμβάνει τα μέσα που πρόκειται να αναπαραχθούν, σε ποιες χρονικές ζώνες θα αναπαραχθούν, καθώς και το πού πρόκειται να βρει ο streamer την ταινία που πρόκειται να αναπαράγει. Για τις υπόλοιπες λειτουργίες της οντότητας χρησιμοποιούνται οι δυνατότητες του προγράμματος vlc. Για τη διαχείριση του vlc o streamer χρησιμοποιεί την telnet διεπαφή του προγράμματος. Με τη διεπαφή αυτή μπορούμε να δημιουργήσουμε νέα video on demand ή broadcast μέσα και να καθορίσουμε το χρόνο αναπαραγωγής τους. Για τη διαχείριση του vlc στα πλαίσια του project αναπτύσσεται την περίοδο αυτή ένας wrapper σε php, ο οποίος απλοποιεί τις αλληλεπιδράσεις με το telnet interface. Για το διαμοιρασμό μέσων ο streamer υλοποιεί ένα RTSP server, που υποστηρίζει ένα υποσύνολο από τις δυνατότητες του πρωτοκόλλου. Ο server αυτός καθορίζει στους χρήστες που συνδέονται τις λεπτομέρειες λήψης των διαφόρων ρευμάτων δεδομένων του κάθε μέσου. Επίσης, στην περίπτωση μίας video on demand μετάδοσης μέσω του server αυτού οι πελάτες μπορούν να ελέγχουν την αναπαραγωγή του μέσου. Για τη μετάδοση των δεδομένων ενός μέσου ο streamer χρησιμοποιεί το πρωτόκολλο RTP. Το πρωτόκολλο αυτό καθορίζει έναν τρόπο πακετοποίησης και μετάδοσης δεδομένων πραγματικού χρόνου μέσω udp συνδέσεων. Στη περίπτωση επίσης broadcast μέσων ο streamer χρησιμοποιεί τη δυνατότητα multicast των συγχρονων tcp / ip δικτύων. Η

56 δυνατότητα αυτή επιτρέπει την ταυτόχρονη μετάδοση ενός ρεύματος δεδομένων σε πολλούς χρήστες μέσω μίας μόνο μετάδοσης. Για την ασφαλή μετάδοση ενός μέσου ο streamer δανείζεται κάποιες τεχνικές από τις σύγχρονες πλατφόρμες ψηφιακής τηλεόρασης. Σε περίπτωση που θέλουμε κάποια προβολή να μην είναι διαθέσιμη ελεύθερα σε όλους τους χρήστες, επειδή πρέπει να χρεωθούν πρώτα, τότε ο web server μπορεί να καθορίσει ένα κλειδί κρυπτογράφησης για το ρεύμα δεδομένων του μέσου μέσω της διεπαφής telnet. Η μέθοδος που ακολουθείται χρησιμοποιεί το κλειδί που καθορίσαμε για να κρυπτογραφήσει, με τη βοήθεια του αλγορίθμου AES, τα κλειδιά που πραγματικά χρησιμοποιούμε, έτσι ώστε να αποστέλλονται ασφαλώς στους χρήστες μέσω του RTSP server σε κατάλληλο μήνυμα. Ο αλγόριθμος που χρησιμοποιείται ουσιαστικά για το ρεύμα δεδομένων ενός μέσου είναι ο DVB- CSA, ο οποίος χρησιμοποιείται σήμερα από πολλά αντίστοιχα συστήματα. Λεπτομέρειες για τον αλγόριθμο αυτό παρουσιάζονται στο 4ο κεφάλαιο του παρόντος κειμένου. Client Η οντότητα του client αντιπροσωπεύει τους χρήστες του συστήματος. Η βασική αλληλεπίδραση της οντότητας αυτής είναι με τον web server, από τον οποίο ενημερώνεται για τα διαθέσιμα κανάλια και ταινίες, καθώς και με τον streamer, από τον οποίο λαμβάνει τα ρεύματα δεδομένων του κάθε μέσου. Για τη σύνδεση ενός χρήστη στο σύστημα απαιτείται μόνο ένας περιηγητής ιστοσελίδων που να βασίζεται στη τεχνολογία διαχείρισης προεκτάσεων του mozilla (firefox, opera κ.α. ). Ο χρήστης θα πρέπει να εγγραφεί στο σύστημα για να λάβει το όνομα χρήστη και το κωδικό για να συνδέεται σε αυτό. Αφού κάποιος συνδεθεί στο web server θα πρέπει να επιλέξει κάποιο από τα διαθέσιμα κανάλια για να παρακολουθήσει. Με βάση το κανάλι ή την ταινία που θα επιλέξει ο χρήστης, ο εξυπηρετητής δημιουργεί δυναμικά μία σελίδα στην οποία καθορίζονται οι λεπτομέρειες της σύνδεσης, καθώς και οι κωδικοί κρυπτογράφησης και φορτώνεται το plugin του vlc. Το vlc, από εκεί και πέρα, συνδέεται στο RTSP server του streamer και ξεκινά την παραλαβή πακέτων του μέσου. Για τον έλεγχο των δικαιωμάτων του πελάτη, το πρόγραμμα ακολουθεί μια υλοποίηση παρόμοια με τις σύγχρονες πλατφόρμες ψηφιακής τηλεόρασης. Το σύστημα ακολουθεί μία τεχνική κρυπτογράφησης δύο επιπέδων. Χρησιμοποιεί τον αλγόριθμο DVB CSA για την κρυπτογράφηση των πακέτων του μέσου με κλειδιά που αλλάζουν ανά κάποιο συγκεκριμένο χρονικό διάστημα, ενώ χρησιμοποιεί και τον αλγόριθμο AES για την κρυπτογράφηση των κωδικών του DVB-CSA, όταν αυτοί αποστέλλονται στους χρήστες του συστήματος. Η αναγνώριση του πελάτη από το σύστημα γίνεται κατά την είσοδό του στη διεπαφή χρήστη του web server. Ο πελάτης, κατά την επιλογή κάποιου καναλιού ή ταινίας, λαμβάνει ένα κλειδί, με το οποίο θα μπορεί να αποκρυπτογραφήσει τα κλειδιά που θα λάβει από τον RTSP server. Αφού στη συνέχεια ο πελάτης συνδεθεί στον RTSP server και ξεκινήσει την παραλαβή της ταινίας, ανά τακτά χρονικά διαστήματα στέλνει κατάλληλες αιτήσεις και λαμβάνει τα κλειδιά του CSA κρυπτογραφημένα. 3.2 Η ασφάλεια στο CDN Στην περίπτωση της εφαρμογής μας, επιλέγουμε μια ελαφρώς διαφοροποιημένη προσέγγιση για το θέμα της ασφάλειας από τις υλοποιήσεις που παρουσιάσαμε στα σύγχρονα συστήματα ψηφιακής τηλεόρασης. Η λύση που επιλέξαμε υλοποιεί ένα σύστημα κρυπτογράφησης δύο επιπέδων. Στο πρώτο επίπεδο χρησιμοποιείται ο αλγόριθμος AES και τα κλειδιά κρυπτογράφησης καθορίζονται από το web-server. Στο επίπεδο αυτό το σύστημα χρησιμοποιεί τον αλγόριθμο κρυπτογράφησης για την ασφαλή μετάδοση των κλειδιών κρυπτογράφησης του δευτέρου επιπέδου. Η ενημέρωση του streamer από το web-server γίνεται μέσω του telnet interface. Ο web server καθορίζει στο sreamer μεταξύ των διαφόρων στοιχείων για τη παρουσίαση και το κλειδί κρυπτογράφησης που θα χρησιμοποιήσει για τη κρυπτογράφηση των κλειδιών του CSA, που χρησιμοποιείται στο δέυτερο επίπεδο. Για το κλειδί ενημερώνονται και οι πελάτες του συστήματος μέσω του web interface. Συγκεκριμένα αφού ο πελάτης δώσει τα στοιχεία του στη φόρμα εισόδου,

57 ξεκινά μια ssl συνεδρία για την ασφαλέστερη επικοινωνία μεταξύ του web server. Αφού λοιπόν επιλέξει το πρόγραμμα που θέλει να παρακολουθήσει, ο server του αποστέλλει μια html σελίδα μέσω της οποίας φορτώνει το vlc plugin. Στα στοιχεία που δίνονται στο Plugin είναι και το κλειδί αποκρυπτογράφησης το οποίο μπορεί στη συνέχεια να χρησιμοποιήσει ο πελάτης. Το δεύτερο επίπεδο ασφάλειας χρησιμοποιεί τον αλγόριθμο κρυπτογράφησης DVB-CSA. Εδώ, ο καθορισμός των κλειδιών κρυπτογράφησης γίνεται από το streamer. Τα κλειδιά παράγονται τυχαία μέσω κατάλληλων κλήσεων σε συναρτήσεις της βιβλιοθήκης gcrypt. Η ενημέρωση των πελατών του συστήματος για το κλειδιά κρυπτογράφησης του συστήματος γίνεται μέσω του RTSP server. Οι πελάτες αποστέλλουν ανά κάποια συγκεκριμένα χρονικά διαστήματα αιτήσεις GET_PARAMETER στο server και λαμβάνουν στο σώμα των απαντήσεων τα κλειδιά κρυπτογραφημένα με βάση τον αλγόριθμο AES. Ο λόγος για τον οποίο επιλέγουμε μία πιο περίπλοκη δομή για την ασφάλεια του συστήματός μας είναι διότι έτσι η διαδικασία σπασίματος της κρυπτογράφησης από τους επίδοξους πειρατές γίνεται αρκετά δύσκολη και περίπλοκη. H βασική διαφορά του CDN σε σχέση με ένα τυπικό σύστημα συνδρομητικής τηλεόρασης έγκειται στο ότι η επικοινωνία των χρηστών με τον εξυπηρετητή γίνεται μέσω του RTSP πρωτοκόλλου και όχι μέσω του DSM-CC. Η λύση αυτή επιλέχθηκε για δύο κυρίως λόγους. Αφενός με τη λύση αυτή μπορούμε να έχουμε περισσότερο έλεγχο στο ποιος είναι συνδεδεμένος στο σύστημά μας κάθε στιγμή. Ένας RTSP εξυπηρετητής λειτουργεί με παρόμοιο τρόπο με έναν απλό εξυπηρετητή διαδικτύου. Οι πελάτες, για να πάρουν κάποια πληροφορία, θα πρέπει να στείλουν κάποια RTSP αίτηση μέσω μίας tcp σύνδεσης. Έτσι, από τις αιτήσεις αυτές μπορούμε να λάβουμε πολύ εύκολα πληροφορίες για τον πελάτη και να ελέγξουμε αργότερα αν ο πελάτης αυτός έχει εγγραφεί στην υπηρεσία μας ή όχι. Αφετέρου μία τέτοια λύση μεταφέρει το σύστημα εγγραφής και αυθεντικοποίησης των πελατών από τον streamer στο web-server. Κάτι τέτοιο είναι αναγκαίο, καθώς οι δύο αυτές οντότητες είναι συνήθως διακριτές και μπορεί το κανάλι να μην επιθυμεί ο streamer να κατέχει πληροφορίες για τους εγγεγραμμένους χρήστες. Βέβαια, το σύστημά μας εμφανίζει και μία μεγάλη εγγενή αδυναμία, την οποία αντιμετωπίζουν και όλα τα συστήματα συνδρομητικής τηλεόρασης. Το πρόβλημα παρουσιάζεται στην περίπτωση που κάποιος χρήστης μοιράσει τα αποκρυπτογραφημένα κλειδιά που λαμβάνει σε άλλους χρήστες μη εγγεγραμμένους. Αυτή η περίπτωση, παραλλαγμένη, εμφανίζεται και στην περίπτωση των set to top boxes, όπου πολλοί χρήστες εισάγουν στο κουτί κυκλώματα τα οποία κατέχουν ήδη τα κλειδιά αποκρυπτογράφησης. Η περίπτωση αυτή, δυστυχώς, δε μπορεί να λυθεί στην παρούσα φάση του προγράμματος. Κατά τη σχεδίαση της λύσης μας βέβαια είχαν προταθεί κάποιες πολυπλοκότερες λύσεις για την υλοποίηση του συστήματος ασφαλείας, όπως η προώθηση των RTSP μηνυμάτων στο web server για την αυθεντικοποίηση των χρηστών. Κάτι τέτοιο δυστυχώς όμως δε λύνει το βασικό πρόβλημα, αλλά απλώς κάνει πολυπλοκότερη την υλοποίηση του συστήματος ασφαλείας.

58 Web-Server Αυθεντικοποίηση χρήστη - SSL Δημιουργία νέου μέσου Καθορισμός AES κλειδιού και διάρκeια κλειδιού στο CSA Αποστολή κλειδιού AES Αίτηση κρυπτογραφημένου κλειδιού Πελάτης Αποστολή κλειδιού Streamer