Λόγω Ηλεκτρονικου Καπιταλ Control (Γερματνικού) ειναι Σχεδον Αδυνατο Στην Ελλαδα να Αγοράσει και να Διαβάσει βιβλία από Άλλες Χώρες

•January 31, 2016 • Leave a Comment

Σαν λάτρης των βιβλιων και της επιστημονικής φαντάσιας ή για κααδημαϊκη χρήση αγοράζω πολλά βιβλια από το εξωτερικύ στα αγγλικά original ή μετεφρεασμενα μεχρι κα τον ιουνη του 2015 που εγινε κλεισιμο των πιστωτικων καρτων για αγορρες απο το εξωτερικο.Οι αγορές από το εξωτερικό φυσικά δεν φορολογονται και ένα καθαρά θεμα ολιγοριας των ΕΛΤΑ να προσθέτει ένα κοστος Φόρου οπως ισχυει θεωρητικα τουλαχιστον. Εν ολιγης υποτιθεται οτι Γερμανοι νοικοκυρευουν στο Ελληνικο κρατος φορολογοντας ολες τις μορφες συναλαγων και επιβαλοντας τες αλλα παραλληλα κλειδωνουν τον Ελληνα απο ηλεκτρονικες αγορες από τον έξω κόσμο. Εν ολιγης ολη αυτη η κουβεντα με την κριση αρχιζει με κουραζει τελευταια και ολος ο κοσμος της δημοσιογραφικης ελιτ που προσπαθουν να μας πεισουν οτι δεν ειμαστε παραγωγικοι και οτι χρωσταμε χωρις λογο για λεφτα που κλεψαν ολη η αφροικρεμα της TV. Εν ολιγης ειναι σημαντικο θεωρω να καταλαβουμε πως μια αυτοκρατορια (ή ενα ονειρο της 3rd or 4th reich) εγινε το 1925 με 1945 μεσω προπαγανδας στον ιδιο το Γερμανικο Λάο, μέσω μιας πολτικης ελιτ ή που ακριβως η ιδια μορφη της μας προβαλεται σημερα κάθε μερα στην Τηλεοραση με δημοκρατικους αντιπροσωπους μας που υποτιθεται οτι μας αντιπροσωπευουν αλλά παρόλα αυτά απλά μιας διτάζουν σαν Διδακτορικό ΔεξιοΡατσιστικο Καθεστως. Μετα των πτωση του τοιχους του βερολινου πλεον ανεγερθηκε παλι στην εξουσια της Ευρωπαϊκης Πολιτικης Ελιτ αλλά παρολα αυτα δεν κατανοουμε πως εν τελη για μια λειτουργικη κοινωνια με εξελελιξη σε βαθος χρονο όπως η Ελληνικη καλό θα ηταν να κλεισουμε για λιγο της τηλεορασεις μας σαν Ενημερωση για τον κοσμο εκει έξω και να εξασκησουμε το μυαλο και σωμα μας στα προτυπα της αρχαις Ελλαδας. Από και πέρα όπως Όπως άλλωστε και ο Σωκρατης που ναι μεν ζουσε απλα και φτωχικα αλλα παρολα αυτα χαραξε την ηθικη εξελιξη του συχρονου πολιτισμου.

 

Παραθέτω ένα εξώφυλλο ενος βιβλιου ενός αγαπημενο ενός σύχρνου Γάλλου Συγγραφεα / Venture Capitalist / Αστρονομου και Επιστημονικου Ερευνητη που ισως μας διδάξει πολλά για το μέλλον $_35

Advertisements

Qt – 3 – Σχεδιασμός Γραφικής Διεπαφής GUI με χρήση του Qt Designer

•December 8, 2015 • Leave a Comment

3 – Σχεδιασμός Γραφικής Διεπαφής GUI με χρήση του Qt Designer

 

Ενώ απλές γραφικές διεπαφές, σαν αυτή του μετατροπέα που δημιουργήσαμε στο Κεφάλαιο 2, μπορούν να συνταχθούν “χειροκίνητα” χωρίς ιδιαίτερα προβλήματα, υπάρχει η ανάγκη για ένα γραφικό εργαλείο σχεδιασμού διεπαφής, ειδικά για τον σχεδιασμό παραθύρων διαλόγων με πολλά γραφικά στοιχεία. Η Qt παρέχει ακριβώς αυτό, με το Qt Designer.

 

3.1 Διαλόγοι “Με Κλικ Ποντικιού”

 

3.1 Dialogs “By Mouse Click”

 

Παρακάτω θα δημιουργήσουμε ένα παράθυρο διαλόγου ByteConverter του προηγούμενου κεφαλαίου με χρήση αυτού του εργαλείου σχεδίασης διεπαφών (GUI tool)

 

Το γεγονός ότι πολλά διαφορετικά παράθυρα ανοίγουν κατά την έναρξη του Designer, είναι κάτι που οι χρήστες των Windows δεν έχουν συνηθίσει.. Αν θέλετε να κάνετε χρήση της διάταξης παραθύρων dock mode, η οποία είναι εξορισμού στο Visual Studio, για παράδειγμα, μπορείτε να την αλλάξετε πηγαίνοντας στο Edit→User Interface Mode→Docked Window. Ένα από τα παράθυρα διαλόγου είναι το “New Form” με επιλογή προτύπου εμφάνισης. Τα πρότυπα αυτά είναι διαθέσιμα για κύρια παράθυρα, πλαίσια διαλόγων και widgets. Η Qt 4 κάνει διαχωρισμό μεταξύ των πλαισίων διαλόγων που τοποθετούν τα κουμπιά, ενεργείων του χρήστη, Επιβεβαίωσης (OK) και Ακύρωσης (Cancel), στο κάτω μέρος και αυτά που τα τοποθετούν στην κάτω δεξιά γωνία. Επιλέγουμε ένα από αυτά τα πρότυπα εμφάνισης για το πλαίσιο διαλόγου ByteConverter : Το σχήμα 3.1 δείχνει τον διάλογο με κουμπιά στο κάτω μέρος.

 

Δεν απαιτείται ο καθορισμός των κουμπιών. Για την διαγραφή τους  τα σχεδιάζουμε με χρήση του αριστερού πλήκτρου του πονιτκιού, επιλέγοντας ένα πλαίσιο επιλογής που να περικλείει τα κουμπιά και το πλαίσιο κενού (spacer). Πατώντας το κουμπί Del αφαιρούμε τα widgets που καλύπτουν τις απαιτήσεις στην περίπτωση μας.

 

Το επόμενο βήμα είναι να προσθέσουμε γραμμές εισόδου και ετικέτες στο πλαίσιο του παραθύρου διαλόγου. Μπορούμε να τα βρούμε μέσα στο Widget Box, που το πρόγραμμα συνήθως τοποθετεί στο αριστερό μέρος της οθόνης. Για να δημιουργήσουμε μια νέα ετικέτα, ψάχνουμε για την ομάδα Display Widgets (στο κάτω μέρος του κουτιού) και μέσω συρσίματος και εναπόθεσης (drag and drop) βάζουμε την ετικέτα εισόδου στο πλαίσιο διαλόγου .

 

Τώρα προσθέτουμε το widget της γραμμής επεξεργασίας. Ως στοιχείο εισόδου αυτό το στοιχείο της διεπαφής ανήκει στην κατηγορία των widgets εισόδου και τοποθετείται στην θέση του μέσω συρσίματος και εναπόθεσης (drag and drop). Επιπλέον για τις τρεις ετικέτες και γραμμές επεξεργασίας, χρειαζόμαστε ένα κουμπί  (Buttons→Push Button) και ένα οριζόντιο και κάθετο κενό (spacer). Αυτά τα πλαίσια στο πρόγραμμα Designer λειτουργούν σαν τεντωτές (stretches): προσαρμόζουν τις αποστάσεις μεταξύ των widgets του παραθύρου όταν αλλάζουμε το μέγεθος του.

 

Ένα στοιχείο της διεπαφής χρήστη (GUI) που έχει τοποθετηθεί, μπορεί να επανατοποθετηθεί σέρνοντας το με χρήση του αριστερού κουμπιού του ποντικιού. Στο σχήμα 3.2 δείχνει την φόρμα του παραθύρου διαλόγου ByteConverter μετά την τοποθέτηση όλων των Widget.

 

Οι χρήστες της Qt 4.2 ή νεότερων εκδόσεων πιθανόν να συναντήσουν διαφορές στην εμφάνιση του Designer όπως περιγράψαμε παραπάνω, καθώς η Trolltech έχει αλλάξει τη πρακαθορισμένη εμφάνιση του παραθύρου. Η σκοπιμότητα ήταν να ξεπεραστούν προβλήματα που αφορούσαν την διάταξη των κουμπιών σε διαφορετικές πλατφόρμες: Το τρέχον στυλ καθορίζει την διάταξη των κουμπιών. Στο Mac OS X και στο GNOME, η ενέργεια ακύρωσης (cancel) βρίσκεται στην αριστερή πλευρά, ενώ η ενέργεια επιβεβαιώσης (ΟΚ) βρίσκεται στην δεξιά πλευρά. Στα Windows και στο KDE, η διάταξη των κουμπιών είναι αντίστροφη.

 

Η λύση της Trolltech ήταν να εισάγει μια νέα κλάση με όνομα QButtonBox στην Qt 4.2, η οποία αυτομάτως παρείχε αυτά, που απαιτούνταν παλαιότερα να δημιουργήσει ο χρήστης χειροκίνητα: ένα σετ προκαθορισμένων κουμπιών και ένα πλαίσιο κενού (spacer). Με την χρήση του QButtonBox, η εφαρμογή θα επιλέξει αυτόματα την σωστή σειρά και την επιλεγμένη εμφάνιση. Το σχέδιο 3.3 δείχνει τον προκαθορισμένο πρότυπο εμφάνισης σε στυλ Cleanlooks (GNOME) και Plastique (KDE).

 

Αν το Qt Designer μπορεί να κάνει χρήση του QButtonBox, η καλύτερη λύση δεν είναι ούτε να το αφαιρέσουμε όπως συνίσταται για τα παραπάνω κουμπιά αλλά ούτε η προσθήκη ενός νέου κουμπιού. Αντ’αυτού, τροποποιούμε την ιδιότητα standardButtons στον Property Editor του Designer με τέτοιον τρόπο ώστε να κάνουμε χρήση μόνο του κουμπιού κλεισίματος. Αυτό γίνεται απενεργοποιώντας δύο ενεργές εγγραφές στο κουτί drop-down της ιδιότητας standardButtons και μετά επιλέγοντας QDialogButtonBox::Close.

 

Χρήστες που δεν είναι εξοικειωμένοι με την επεξεργασία ιδιοτήτων (property editors) π.χ. από άλλους γραφικούς σχεδιαστές διεπαφών χρήστη (GUI), θα πρέπει να διαβάσουν την ενότητα 5 για μια σύντομη εισαγωγή.

 

3.1.1 Δημιουργία Διατάξεων Εμφάνισης με χρήση του Designer

 

Τα widgets ακόμη δεν έχουν ξεκάθαρη διάταξη. Για την αποφυγή οριστικής τοποθέτησης στοιχείων διεπαφής μέχρι και το τελευταίο εικονοστοιχείο, ο Qt Designer παρέχει προκαθορισμένες διατάξεις εμφάνισης. Για την ομαδοποίηση ενός αιρθμού widgets μεταξύ τους και μετά για την επιλογή της επιθυμητής διάταξης, μπορούμε είτε να τα επιλέξουμε με χρήση ενός πλαισίου επιλογής, είτε από μενού επιλογών που εμφανίζεται κατά την επιλογή όταν κάνουμε δεξί κλικ ή από το μενού εργαλείων. Το τελευταίο συνίσταται ειδικά για τους χρήστες Mac με ποντίκι ενός πλήκτρου.

 

Στην περίπτωση των γραμμών επεξεργασίας και των ετικετών, η διάταξη πλέγματος είναι η καλύτερη επιλογή: αυτή επιλέγεται στο μενού στοιχείων διαμέσου του στοιχείου Lay out→Lay Out σε ένα πλέγμα. Η διάταξη μετά εμφανίζεται με κόκκινο περίγραμμα και τα αντικείμενα εμφανίζονται μαζί ομαδοποιημένα, όπως θα είναι στην τελική εφαρμογή.

 

Κατά την εφαρμογή μιας διάταξης, ο Designer προσπαθεί να δείχνει ανοχή στις ανακρίβειες εικονοστοιχείων τις οποίες μπορεί να προκάλεσε ο προγραματιστής κατά την τοποθέτηση των widgets. Εάν η επιλεγμένη διάταξη δεν τοποθετεί τα widgets όπως θέλαμε ή υπάρχει λάνθασμένος αριθμός στοιχείων για την διάταξη, η σειρά τοποθέτησης μπορεί να ακυρωθεί μέσω του στοιχείου μενού επιλογών Lay out→Break Layout.

 

Αν επιλέξαμε να μην κάνουμε χρήση του QButtonBox παραπάνω, επιλέγουμε μια οριζόντια διάταξη για το πλαίσιο κενού και τα κουμπιά, καθώς το QButtonBox ήδη περιλαμβάνει την ορίζοντια αυτή διάταξη με κενό (Lay out→Lay Out Horizontally).

 

Τέλος, φέρνουμε μαζί και τις δύο διατάξεις, μαζί με τα μέχρι τώρα μη ομαδοποιημένα κάθετα πλαίσια κενού, επιλέγοντας στο μενού επιλογών το στοιχείο Lay out→ Lay Out Vertically σε μια μοναδική κάθετη διάταξη. Αυτή η καθολική διάταξη δεν χρειάζεται να επιλεχθεί συγκεκριμένα: ο Designer δεν το επισημαίνει με ένα ξεχωριστό πλαίσιο και το μενού επιλογών ανοίγει εάν κλικάρουμε το κενό διάστημα στο παράθυρο διαλόγου. Επηρεάζει όλες τις προηγούμενες διατάξεις και τα μέχρι τώρα μη ομαδοποιημένα στοιχεία (π.χ. το κάθετο πλάισιο κενού)

 

Το αποτέλεσμα όπως φαίνεται στο σχήμα 3.4, πλησιάζει στην επιθυμητή μας γραφική διεπαφή χρήστη (GUI). Οι ετικέτες ωστόσο δεν είναι ακόμη σωστές. Αυτές μπορούν να αλλάξουν μέσω του στοιχείου μενού επιλογών Change text. . . ή μέσω της επεξεργασίας ιδιοτήτων στο δεξί μέρος της οθόνης. Για να κατανοήσουμε καλύτερα το τελευταίο, αξίζει να δούμε την έννοια των ιδιοτήτων της Qt.

 

3.1.2. Μενού επεξεργασίας ιδιοτήτων

 

Οι κλάσεις βασισμένες στο QObject έχουν ξεχωριστές ιδιότητες που μπορούν να οριστούν με χρήση της setProperty() και να ανακληθούν με χρήση της property(). Παραδείγματα πληροφοριών γραφικών διεπαφών χρήστη μπορούν να αναπαρασταθούν μέσω ιδιοτήτων συμπεριλαμβανομένου μεγέθους, ετικετών, στοιχείων μορφοποίησης, βοηθητικών κειμένων και πολλά αλλά στοιχεία.

 

Σχήμα 3.5: Το μενού επεξεργασίας ιδιοτήτων κατατάσει κάθε ιδότητα μιας κλάσης σύμφωνα με την κλάση που ορίστηκε αρχικά (είτε η κλάση αυτή καθευατή, είτε μια γονική)

 

Αυτό γίνεται στο Μενού Επεξεργασίας Ιδιοτήτων (Σχήμα 3.5). Απαριθμεί τις μεταβαλλόμενες ιδιότητες που παραθέτονται από την κλάση στην οποία κάθε ιδιότητα υλοποιήθηκε αρχικά—είτε την ίδια την κλάση ή έναν γονέα της. Για παράδειγμα, η QLabel κληρονομεί από την κλάση QFrame, που με την σειρά της είναι απόγονος του QWidget: Αντιστοίχως μπορούμε να καθορίσουμε όχι μόνο ιδιότητες ετικετών QLabel όπως το κείμενο της ετικέτας (ιδιότητα κειμένου) αλλά και τις ιδιότητες του QFrame όπως το frameShape1 και την ιδιότητα του QWidget όπως το μέγεθος του (γεωμετρία).

 

Εφόσον όλα τα widgets κληρονομούν από το QObject, μπορούμε πάντα να λαμβάνουμε και να ορίζουμε την ιδιότητα του QObject με όνομα objectName, η οποία παρέχει μια εσωτερική περιγραφή και δεν πρέπει να συγχέεται με την ετικέτα που θα εμφανίζεται στο widget μέσα στην διεπαφή χρήστη—για παράδειγμα, το κείμενο της ετικέτας ή το κουμπί (που καθορίζεται με την ιδιότητα κειμένου). Η μεταβλητή του ονόματος αντικειμένου καθώς και άλλες ιδιότητες προέρχονται από το objectName.

 

Επειδή δεν θέλουμε να αλλάξουμε τις ετικέτες μέσα στον κώδικα θα τα γράψουμε μετά, τα ονόματα των μεταβλητών δεν παίζουν κανέναν επιπλέον ρόλο. Αυτός είναι ο λόγος για τον οποίο συνεχίζουμε να κάνουμε χρήστη ονομάτων αντικειμένων που παράγονται από τον Designer.

 

1 Οι ετικέτες είναι συνήθως χωρίς πλαίσιο, γι’αυτό ορίζουμε το frameShape σε QFrame::None εξ’ ορισμού

 

Από την άλλη πλευρά, παρακάτω χρειάζεται να επέμβουμε χειροκίνητα στα widget γραμμής επεξεργασίας, γι’αυτό τους δίνουμε τα ίδια ονόματα με αυτά που είχαν στο κεφάλαιο 2 (αυτά είναι decEdit, hexEdit και binEdit) με χρήση του Property Editor. Αυτό διασφαλίζει ότι ο κώδικας θα παραχθεί από τον μεταγλωτιστή διεπαφής χρήστη και οι αντίστοιχοι δείκτες θα έχουν τα ίδια ονόματα. Ο τρόπος με τον οποίο μπορούμε να αποκτήσουμε πρόσβαση στα widgets γραμμών επεξεργασίας που δημιουργήθηκαν από τον Designer περιγράφεται στην σελίδα 92.

 

Για την αλλαγή των ιδιοτήτων στον Designer, επιλέγουμε το σχετικό widget κλικάροντας με το αριστερό πλήκτρο του ποντικιού. Τα περιεχόμενα του παραθύρου επεξεργασίας ιδιοτήτων (Property Editor) διαμορφώνονται αντιστοίχως και μπορούμε να αλλάξουμε τις ιδιότητες των επιλεγμένων widget. Οι ιδιότητες των οποίων οι τιμές είναι ήδη διαφορετικές από τις προεπιλεγμένες, εμφανίζονται με έντονους χαρακτήρες.

 

Αλλαγή Τίτλων Παραθύρων

 

Για την αλλαγή του τίτλου παραθύρου ολόκληρου του διαλόγου, κλικάρουμε σε οποιοδήποτε σημείο μέσα στο παράθυρο κατασκευής widget που δεν καλύπτεται από θυγατρικά widgets ή διατάξεις, όπως την περιοχή ανάμεσα στο πλαίσιο διάταξης και στο περιθώριο του παραθύρου διαλόγου. Τώρα το παράθυρο επεξεργασίας ιδιοτήτων (Property Editor) εμφανίζει την ιδιότητα windowTitle στην ενότητα QWidget. Κλικάροντας την αντίστοιχη γραμμή, μας επιτρέπει την αλλαγή της τιμής της ιδιότητας, για παράδειγμα την αλλαγή του παραθύρου διαλόγου σε μετατροπέα αριθμών. 2 Το κουμπί με το μικρό κόκκινο βελάκι  δίπλα στην τιμή της ιδιότητας, επιτρέπει την επαναφορά της στην προεπιλεγμένη τιμή.

 

Παρά το γεγονός ότι κάθε widget έχει την ιδιότητα windowTitle, γίνεται ορατό στην περίπτωση των widget ανωτέρου επιπέδου (top-level), δηλαδή σε παράθυρα ή πλαίσια διαλόγων.

 

Ρυθμίσεις Χαρακτήρων

 

Το παράθυρο διαλόγου μας δεν εμφανίζει τις σωστές συμβολοσειρές κειμένου στις ετικέτες και στα κουμπιά. Προκειμένου να γίνει αυτό απαιτείται η ιδιότητα κειμένου.

 

Σχήμα 3.6: Οι ετικέτες περιέχουν το σωστό κείμενο

 

2 Για νέες εργασίες, ο Designer εμφανίζει μόνο το αλλαγμένο τίτλο παραθύρου μετά την αποθήκευση του παραθύρου διαλόγου. Πριν ο διάλογος αποθηκευτεί για πρώτη φορά, η γραμμή τίτλου περιέχει μόνο την λέξη untitled.

 

Θέτουμε αυτήν την ιδιότητα στα τρία QLabels, με την σειρά τους, σε δεκαδική, δεκαεξαδική και δυαδική. Για το κουμπί θέτουμε την τιμή της ιδιότητας (στο τμήμα QAbstractButton της γονικής κλάσης) σε τερματισμό (Exit). Το σχήμα 3.6 μας δείχνει το αποτέλεσμα.

 

Ορισμός του προεπιλεγμένου κουμπιού

 

Εάν επιθυμούμε επίσης, μπορούμε να αλλάξουμε την προκαθορισμένη ιδιότητα για το QPushButton. Εάν αυτό οριστεί εώς αληθές, πατώντας το πλήκτρο [Enter] οπουδήποτε εντός του παραθύρου διαλόγου αυτό ενεργοποιεί το κουμπί. Ωστόσο αυτό δεν έχει ιδιαίτερο νόημα, καθώς όταν το κουμπί ενεργοποιείται, η εφαρμογή πραγματοποιεί μια ενέργεια τερματισμού, κάτι που θα ενοχλούσε τον χρήστη εάν το ενεργοποιούσε καταλάθος.

 

Παρόλο που ο Designer επιτρέπει την αλλαγή σε αληθής (true) των προκαθορισμένων ιδιοτήτων πολλών κουμπιών σε ένα widget, μόνο ένα από αυτά μπορεί να λειτουργήσει σαν το προεπιλεγμένο κουμπί. Η Qt μεταχειρίζεται το τελευταίο κουμπί του widget να έχει την προκαθορισμένη ιδιότητα σε τιμή αληθής (true) ως το προκαθορισμένο κουμπί του widget.

 

Σε περίπτωση που το widget που εμπλέκεται είναι παράθυρο διαλόγου, η Qt από την έκδοση 4.1 και μετά ενεργοποιεί αυτόματα την ιδιότητα  autoDefault για όλα τα κουμπιά που είναι τοποθετημένα σε αυτό. Η ιδιότητα αυτή έρχεται σε ισχύ εάν ο χρηστης μεταπηδήσει από ένα κομμάτι του widget στο επόμενο με χρήστη του [Tab] (Βλέπε σελίδα 89): Εάν φτάσει σε γραμμή επεξεργασίας κατά την ενέργεια αυτή, πατώντας το πλήκτρο [Enter] ενεργοποιεί το επόμενο κουμπί στην καρτέλα ακολουθίας, δεδομένου ότι η ιδιότητα  autoDefault έχει οριστεί.

 

Κατά την χρήση του QButtonBox, η προεπιλεγμένη ιδιότητα απόδιδεται αυτόματα στο κουμπί επιβεβαιώσης. Το κουμπί κλεισίματος είναι ενέργεια τερματισμού και έτσι δεν μπορεί να γίνει το προεπιλεγμένο κουμπί στην περίπτωση αυτή.

 

Αλλαγή Μεγέθους Παραθύρου

 

Μία μόνο λεπτομέρια χαλάει τώρα την την εικόνα: Ο διάλογος στο σύνολο είναι πολύ μεγάλος. Είναι δυνατό φυσικά να κλικάρουμε το σύμβολο συν μπροστά από την ιδιότητα γεωμετρίας και να καθορίσουμε το πλάτος και ύψος με ακρίβεια, μέχρι το εικονοστοιχείο.

 

Σχήμα 3.7: Καθορίζουμε το μέγεθος του παραθύρου διαλόγου στο σωστό μέγεθος

 

Εναλλακτικά, το παράθυρο διαλόγου μπορεί να διαμορφωθεί στο επιθυμητό μέγεθος με χρήση του ποντικιού. Σαν κανόνας όμως είναι πιο απλό να επιλέξουμε την λειτουργία καθορισμού μεγέθους (Adjust Size) από το μενού Form στην εργαλειοθήκη (μέσω του εικονιδίου με το διαγώνιο βέλος στο τέρμα δεξιά), δεδομένου ότι ενεργοποιήσαμε το παράθυρο διαλόγου χειροκίνητα. Αυτό θα μικρύνει το παράθυρο διαλόγου στο κατάλληλο μέγεθος που εκτιμάται από τον Designer (Σχήμα 3.7)

 

3.1.3 Η Προεπισκόπηση

 

Για τον έλεγχο του αποτελέσματος, μπορούμε να κάνουμε χρήση της λειτουργίας της προεπισκόπησης που παρέχεται στο μενού Form του Designer. Εάν θέλουμε μπορούμε να δούμε το παράθυρο διαλόγου σε widgets άλλου στυλ, μέσω του Preview στο υπομενού. Το σχήμα 3.8 δείχνει την προεπισκόπιση σε περιβάλλον Linux. Η Trolltech ορίζει το στυλ Plastique ώς το προκαθορισμένο, το οποίο μοιάζει με το προκαθορισμένο στυλ του KDE 3. Σε Mac OS X, ή Qt κάνει χρήση του Aqua Style, κάνοντας χρήση της ρουτίνας απεικόνισης Aqua Style. Παρομοίως σε Windows XP κάνει χρήση των Windows APIs για σχεδιασμό του στυλ εμφάνισης. Ως εκ τούτου, τα στυλ Aqua και XP είναι διαθέσιμα μόνο σε αυτά τα λειτουργικά συστήματα.

 

Σχήμα 3.8: Μια προεπισκόπηση ενός τελικού widget

 

3.1.4 Συνδέσεις Σημάτων/Υποδοχών

 

Εκτός από την λειτουργία του σχεδιασμού διεπαφής, ο Designer περιλαμβάνει ένα εργαλείο γραφικής σχεδίασης στο οποίο τα σήματα των widgets μπορούν να σχεδιαστούν γραφικά και να συσχετισθούν με τα slots. Πατώντας το πλήκτρο [F4] ή επιλέγοντας την λειτουργία Edit Signals/Slots στο μενού Edit για αλλαγή σε αυτήν την λειτουργία: μπορούμε να μεταβούμε εκεί με Edit→Edit Widgets ή πατώντας το πλήκτρο [F3]

 

Η σύνδεση των σημάτων και υποδοχέων στον Designer γίνεται σε δύο βήματα. Αρχικά, σχηματίζουμε μια σύνδεση από το widget του επιθυμητού σήματος με το επιθυμητή υποδοχή ενός widget. Το φόντο του widget ή του παραθύρου διαλόγου μπορούν να γίνουν περιοχές εναπόθεσης στοιχείων (drop target). Οι συνδέσεις που τοποθετούνται εκεί παρέχονται μέσω ενός εικονηδίου γείωσης από τον Designer: όλες οι υπόλοιπες συνδέσεις τερματίζονται με ένα βελάκι στο widget στόχου (Σχήμα 3.9 δείχνει και τις δύο περιπτώσεις)

 

Σχήμα 3.9: Σήματα/Υποδοχείς δημιουργούνται στον Designer μέσω drag and drop

 

Το δεύτερο βήμα περιλαμβάνει τον καθορισμό του επιθυμητού ζευγαριού σήματος και υποδοχέα για τα δύο widgets. Μόλις απελευθερώσουμε το πλήκτρο ποντικιού από το widget στόχο, ο Designer ανοίγει ένα παράθυρο διαλόγου, όπως φαίνεται στο σχήμα 3.10: Στα αριστερά εμφανίζεται ένα μενού με τα σήματα που χρησιμοποιήσαμε πιο συχνά. Εάν το σήμα που ψάχνουμε δεν είναι εκεί, κλικάρουμε το Show all signals and slots κουτάκι επιλογής για εμφάνιση όλων των πιθανών σημάτων του widget στόχου. Το δεξί κουτί επιλογής εμφανίζει όλους τους υποδοχείς του widget στόχου αντιστοιχώντας τα σήματα που επιλέγονται στα αριστερά. Εάν επιβεβαιώσουμε την επιλογή, η σύνδεση θα εγκαθιδρυθεί.

 

Σχήμα 3.10: Σήματα και υποδοχείς τών δύο επιλεγμένων widgets συνδέονται από τον προγραμματιστή σε αυτόν τον διάλογο.

 

Ένα κλικ στην γραμμή σύνδεσης ακολουθούμενη από το πάτημα του πλήκτρου [Del] αφαιρεί όλες τις συνδέσεις.

 

3.1.5 Η ακολουθία του Tab

 

Η λεγόμενη ακολουθία του tab είναι σημαντική για τους χρήστες πληκτρολογίων. Η λειτουργία αυτή επιτρέπει στην αλλαγή εστίασης μέσω του πλήκτρου [Tab] στο επόμενο widget που αναμένει κάποια είσοδο. Ο Designer καθορίζει την ακολουθία tab έτσι ώστε το πρώτο widget του διαλόγου να έχει την εστίαση του πληκτρολογίου. Η εστίαση αλλάζει στο επόμενο στοιχείο της γραφικής διεπαφής όταν πατηθεί το πλήκτρο [Tab]. Όταν σχεδιάζουμε την διεπαφή του χρήστη πρέπει να δώσουμε προσοχή στην προκαθορισμένη ακολουθία tab και να την αλλάξουμε έτσι ώστε να κάνουμε την εφαρμογή μας πιο φιλική προς τον χρήστη.

 

Σχήμα 3.11: Η αλλαγή εστίασης μετακυλίεται πατώντας το πλήκτρο [Tab] που καθορίζεται σειρά αλλαγής του tab.

 

3.1.6 Συντομεύσεις και Βοηθήματα

 

Αυτοί που προτιμούν έλεγχο μέσω πληκτρολογίου θα σας ευχαριστήσουν έαν μπορούν να μεταβούν απευθείας σε όσα περισσότερα widget που χρησιμοποιούνται συνήθως. Τα στοιχεία της γραφικής διεπαφής που εμφανίζουν κείμενο όπως κουμπιά, συσχετίζονται με ένα πλήκτρο συντόμευσης  τοποθετώντας το σύμβολο εμπορικού και (&) πριν τον χαρακτήρα που θα αποτελέσει το πλήκτρο συντόμευσης. Έαν το κείμενο εμπεριέχει ένα σύμβολο εμπορικού και (&) αντικαθίσταται από το διπλό &&.

 

Εάν ο χρήστης πατήσει τον συνδιασμό [Alt] + [Χαρακτήρα] από εδώ και στο εξής, το widget αποκτά την εστίαση και ενεργοποιείται. Στο σχήμα 3.12 κάνουμε χρήση της τεχνικής αυτής με το κουμπί εξόδου (Quit).

Αντικείμενα QLabel σχηματίζουν μια εξαίρεση ωστόσο. Εφόσον χρησιμοποιούνται σε διατάξεις με σκοπό την περιγραφή ενός παρακείμενου widget “εταίρο”, αυτά δεν επιδέχονται εστίασης. Ωστόσο η ιδιότητα Buddy μιας ετικέτας μπορεί να χρησιμοποιηθεί για τον καθορισμό της συντόμευσης πληκτρολογίου και τον συσχετισμό της με ένα widget “εταίρο”, όπως και εαν το κείμενο περιγραφής ήταν συσχετισμένο άμεσα στο γονικό στοιχείο αυτοκαθευτό.

 

Στην επιλογή έμφανισης Edit Buddies στον Designer, μπορούμε τώρα να συσχετίσουμε με ποιο widget η ετικέτα είναι έταιρος. Για να γίνει αυτό, κλικάρουμε την μελλοντική ετικέτα Buddy που θα επισημανθεί με κόκκινο χρώμα. Κρατώντας πατημένο το κουμπί ποντικιού, θα επισυνάψουμε μια σύνδεση στο widget που στην συνέχεια θα είναι συσχετισμένο με το label.

 

Σχήμα 3.12: Οι ετικέτες σχετίζονται με άλλα widgets: Οι κατανομές των Buddy μπορούν να βρεθούν στο Buddy mode του Qt Designer.

Figure 3.12: Labels are friends to other widgets: The Buddy allocations can be found in the Buddy mode of the Qt Designer.

 

Στο παράδειγμα από το Σχήμα 3.12 η αντίστοιχη γραμμή επεξεργασίας έχει την εστίαση εάν ο χρήστης πατήσει τα γράμματα που υπογραμίζονται στην περιγραφή της ετικέτας ενώ κρατάμε πατημένο το πλήκτρο [Alt].

 

Εναλλακτικά, ενώ βρισκόμαστε στη κανονική κατάσταση σχεδίασης, μπορούμε να ορίσουμε το όνομα του επιθυμητού Buddy widget στον Property Editor κάνοντας χρήση της ιδιότητας Buddy.3  Χρησιμοποιώντας αυτήν την προσέγγιση, θα ορίσουμε την τιμή της ιδιότητας Buddy του αντικειμένου QLabel, που εμφανίζει το δεκαδικό κείμενο στο παράθυρο διαλόγου μετατροπέα byte έτσι ώστε, να ταιριάζει στην τιμή της ιδιότητας objectName του αντίστοιχου αντικειμένου γραμμής επεξεργασίας, δηλλαδή την συμβολοσειρά decEdit.

 

Για την αναίρεση της συσχέτισης, το μόνο που χρειάζεται να κάνουμε είναι να κλικάρουμε στην γραμμή σύνδεσης στην λειτουργία Buddy πατώντας το πλήκτρο [Del].

 

3.2 Ενσωμάτωση αρχείων του Designer μέσα στο Qt Project.

 

Κατά την αποθήκευση με χρήση του στοιχείου του μενού File→Save Form ή Save Form As. .. ο Designer δημιουργεί αρχεία .ui από τις πληροφορίες που διαθέτει για κάθε widget στην φόρμα.4 Αυτό το αρχείο .ui καθορίζεται στο αρχείο qmake όπως φαίνεται στην παρακάτω γραμμή κώδικα:

 

FORMS = byteconverterdialog.ui

 

Στην περίπτωση μας, το qmake λαμβάνει υπόψιν το αρχείο διεπαφής χρήστη byteconverterdialog.ui : μπορούν να καθοριστούν πολλά αρχεία, διαχωριζόμενα με χαρακτήρα κενού ή να καθοριστούν άλλες γραμμές σύμφωνα με το πρότυπο FORMS +=file.ui.

 

3 Παρόλο που η ιδιότητα αυτή υπάρχει από την Qt 3.x, η Qt 4.0 δεν την εμφανίζει. Μόνο στην έκδοση 4.1 εμφανίζεται ξανά.

4 Κάνοντας χρήση του τρίτου στοιχείου το μενού Save Form As Template. .. μπορούμε να αποθηκεύσουμε την φόρμα μας εώς πρότυπο, που εμφανίζεται μετά στον διάλογο επιλογής new Forms.

 

Κατά την κατασκευή του έργου, το make βασίζεται στο μεταγλωτιστή διεπαφής χρήστη uic για την μετατροπή των αρχείων .ui που δημιουργεί ο Designer σε αρχεία κεφαλής C/C++. Υπάρχει μια σταθερή σύμβαση ονομασίας στο βήμα αυτό: για παράδειγμα η κλάση που αναπαρίσταται από το αρχείο .ui ,που δημιουργούνται από τον Designer, ονομάζονται ByteConverterDialog (η τιμή της ιδιότητας objectName μπορεί να ελενχθεί για την διαπίστωση του ονόματος κλάσς), τότε το αρχείο κεφαλής που προκτύπτει παίρνει το όνομα ui_byteconverterdialog.h από το uic.

 

Είναι σημαντικό έστω ένα ακόμη αρχείο στο project να περιλαμβάνει το παραγόμενο αρχείο κεφαλής. Πρέπει να προσθέσουμε τις κατάλληλες δηλώσεις #include πριν εκτελεσθεί το qmake. Διαφορετικά το make δεν θα καλέσει το uic με το κατάλληλο αρχείο περιγραφής της διεπαφής σαν όρισμα, στην επόμενη εκτέλεση.

 

Παρατηρούμε οτι το παραγόμενο αρχείο κεφαλής περιέχει μια βοηθητική κλάση με δύο μεθόδους: setupUi() που παράγει την γραφική διεπαφή (GUI) και  etranslateUi() η οποία μπορεί να κληθεί όταν το πρόγραμμα θέλει να επιτρέψει στον χρήστη την αλλαγή γλώσσας κατά την εκτέλεση.

 

Και οι δύο οι μεθόδοι αναμένουν (ως όρισμα) έναν δείκτη στο widget στο οποίο το αντικείμενο GUI που περιγράφεται στον Designer, είναι να δεσμευτεί. Ακόμη και εάν έχουμε επιλέξει το πρότυπο εμφάνισης στον Designer, μπορούμε να επιλέξουμε ελεύθερα στο σημείο αυτό την κλάση του widget για την οποία προορίζεται η διεπαφή. Το κυρίως πρότυπο MainWindow είναι το μόνο που μπορεί να χρησιμοποιηθεί μαζί με ένα QMainWindow.6

 

Η κλάση που δημιουργείται από το uic είναι τώρα διαθέσιμη εώς Ui::ByteConverterDialog ή Ui_ ByteConverterDialog γενικά ως Ui::classname ή Ui_class σύμφωνα με τον οποίο το όνομα της κλάσης αντοιστοιχεί στο γνώρισμα objectName της φόρμας που δημιουργείται από τον Designer.

 

Υπάρχουν τρεις τρόποι χρήσης και λειτουργικής ανάπτυξης του widget που δημιουργήσαμε. Το πιο είναι το καταλληλότερο εξαρτάται από την συγκεκριμένη περίπτωση.

 

3.2.1 Χρήση κλάσεων παραγόμενων από τον Designer σαν βοηθητικές κλάσεις.

 

Εάν το μόνο που επιθυμούμε είναι την εμφάνιση μιας διεπαφής φτιαγμένης με τον Designer μόνο μια φορά, χωρίς να επέμβουμε στο αντίστοιχο αντικείμενο ξανά εφόσον έχει τρέξει, είναι σκόπιμο εκκινήσοουμε κατευθείαν την παραγόμενη κλάση και δέσμευση του στιγμιοτύπου σε ένα widget που δημιουργήσαμε με χρήση της  setupUi(). Η μέθοδος αυτή διορθώνει τα γραφικά στοιχεία που περιγράφονται στο αρχείο .ui πάνω στο widget και τα εδραιώνει υπό τον όρο ότι αυτό ορίζεται μέσα στον Designer με πρότυπα εμφάνισης (layouts).

 

Θα παρουσιάσουμε την τεχνική αυτή με χρήση του ByteConverterDialog που δημιουργήσε ο Designer:

 

5 Σημείωση για χρήστες Qt 3: Το uic δεν συνεχίζει να παράγει ολόκληρες κλάσεις βασισμένες στο QObject στην Qt 4, απλώς ένα δομικό πλαίσιο (framework) που μπορεί να εφαρμοστεί στο widget του αντίστοιχου τύπου.

6 Το widget που δημιουργήθηκε στον Designer χρησιμοποιείται στην περίπτωση αυτή εώς κεντρικό widget του στιγμιοτύπου QMainWindow και τοποθετείται με setCentralWidget(), αντί της βοήθειας ενός προτύπου εμφάνισης (layout) όπως συνηθίζεται. Επιπλέον οι γραμμές εργαλείων του Designer αντιμετωπίζονται ξεχωριστά από την Qt 4.1 μια λειτουργία που είναι εξίσου διαθέσιμες μόνο στα στιγμιότυπα QMainWindow.

 

// simple/main.cpp

 

#include <QtGui>

 

#include “ui_byteconverterdialog.h”

 

int main(int argc, char*argv[])

{

QApplication app(argc, argv);

QDialog dlg;

Ui::ByteConverterDialog ui;

ui.setupUi(&dlg);

dlg.setAttribute(Qt::WA_QuitOnClose);

dlg.show();

return app.exec();

}

 

Εφόσον τα widgets διαλόγου του δημιουργήθηκαν από τον Designer είναι διαθέσιμα ως δημόσια πρσβάσιμα μέλη της κλάσης UI, μπορούν να τελειοποιηθούν στον κώδικα αργότερα με κλήση των μεθόδων των αντίστοιχων widgets. Τα σήματα και οι υποδοχείς τους, συμμετέχουν στις συνδέσεις σημάτων/υποδοχών. Είτε η κλάση Ui::ByteConverterDialog τεκμηριώθηκε στην συνάρτηση main(), είτε στον κατασκευαστή μιας κλάσης που κληρονομεί από την QDialog, δεν κάνει καμία διαφορά.

 

Στο παράδειγμα μας ωστόσο η προσέγγιση που φαίνεται στον παραπάνω κατάλογο δημιουργεί προβλήματα: Δεν μπορέσαμε να συνδέσουμε το σήμα του πατήματος του κουμπιού Quit στην υποδοχή accept() του παραθύρου διαλόγου και τότε θα είμασταν σε θέση να συνδέσουμε τις υποδοχές binChanged(), hexChanged() και binChanged() στα σήματα textChanged() των αντίστοιχων QTextEdit widgets. Τότε όμως δεν θα είμασταν σε θέση να αποκτήσουμε πρόσβαση σε οποιοδήποτε widget παραγόμενο από το uic στην ίδια την υποδοχή.

 

Για τον λόγο αυτό, η χρήση της άμεσης κλήσης της setupUi() είναι πολύ περιορισμένη: Εάν γίνει αυτό θα περιοριστούμε στην εφαρμογή στιγμιοτύπων της κλάσης που δημιουργεί το uic με στιγμιότυπα τυπικών κλάσεων όπως QWidget ή QDialog. Ωστόσο σε ορισμένες περιπτώσεις η διαδικασία αυτή μπορεί να είναι απολύτως αποδοτική, για παράδειγμα σε ένα τυπικό διαλόγο εισόδου που καλείται με την exec(). Η κλήση exec καλεί ένα ξεχωριστό βρόγχο ενεργειών και επιστρέφει μόνο έαν οι accept(), reject() ή εάν μια άλλη μέθοδος κλείσει το παράθυρο διαλόγου. Εφόσον το αντικείμενο του διαλόγου δεν παύει να υπάρχει όταν κλείσει ο διάλογος, ο κώδικας που ακολουθεί μπορεί να διαβάσει τις τιμές των widget που τοποθετήθηκαν μέσα στον διάλογο από την setupUi() χωρίς κίνδυνο, έτσι ώστε να μην χρειαζόμαστε την υποκλάση QDialog στις περιπτώσεις αυτές.

 

Είναι σημαντικό να καλούμε πάντα την μέθοδο setupUi() ενός στιγμιοτύπου μιας κλάσης που πρώτα παρήγαγε ο Designer, πριν επιχειρήσει να διαβάσει μεταβλητές μελών της διεπαφής αντικειμένου (στο τρέχων παράδειγμα, αυτά της γραφικής διεπαφής). Σε άλλη περίπτωση το πρόγραμμα θα χαλάσει τους μη αρχικοποιημένους δείκτες και θα τερματίσει ξαφνικά.

 

Ένα όρισμα που δεν δημιουργείται από στιγμιότυπο κλάσεων παραγόμενες μέσω Designer, προκύπτει άμεσα από το γεγονός ότι δημόσιες μεταβλητές μελών είναι εξωτερικά προσβάσιμες προκαλώντας παραβίαση του απορρήτου, μία από τις σημαντικότερες αρχές του αντικειμενοστραφούς προγραμαστιμού. Η ιδιώτικοτητα επιβάλλει αφαίρεση παρέχοντας μόνο στα μέλη των κλάσεων πρόσβαση στις μεθόδους τους.

 

Οι εσωτερικές λεπτομέριες της κλάσης απομονώνονται από τις άλλες κλάσεις και μπορούμε να αλλάξουμε τον εσωτερικό σχεδιασμό της κλάσης, χωρίς να χρειάζεται να προσαρμόσουμε το υπόλοιπο πρόγραμμα που κάνει χρήση της κλάσης αυτής. Εφόσον κάνουμε χρήση της κλάσης UI ως την βραχυπρόθεσμη κλάση εγκατάστασης, η παραβίαση της αρχής της ενθυλάκωσης δεν έχει κάποια συνέπεια.

 

3.2.2 Έχοντας πάντα διαθέσιμα τα Widget φτιαγμένα με τον Designer

 

Προκειμένου να αντιμετωπίσουμε των ελλείψεων που μόλις επιδείξαμε, είναι καλή ιδέα να περιλάβουμε την κλάση που παρήγαγε το uic ως μεταβλητή μέλους. Για να γίνει αυτό κληρονομούμε από την επιθυμτή κλάση που στην περίπτωση μας είναι QDialog.

 

Η σημαντική διαφορά είνα στην δήλωση της κλάσης. Δηλώνουμε την κλάση που δημιουργείται από το uic ως ιδιωτικό μέλος μιας υποκλάσης QDialog. Αυτό επιτρέπει στην επιλεκτική πρόσβαση στα widgets μέσα στις κλάσεις που δημιουργεί ο Designer μέσω αυτού του νέου μέλους μεταβλητής της γραφικής διεπαφής  (ui) της κλάσης ByteConverterDialog που κληρονομείται από το QWidget:

 

// member/byteconverterdialog.h

#include <QDialog>

#include “ui_byteconverterdialog.h”

 

class QLineEdit;

 

class ByteConverterDialog : public QDialog

{

private:

Ui::ByteConverterDialog ui;

};

 

Ο κατασκευαστής και όλες οι υποδοχές αποκτούν πλέον πρόσβαση στις παραγόμενες κλάσεις μέσω του μέλους μεταβλητής της γραφικής διεπαφής (ui):

 

The constructor and all slots now access the generated class via the ui member variable:

 

// member/byteconverterdialog.cpp

 

ByteConverterDialog::ByteConverterDialog(QWidget *parent)

: QDialog(parent)

{

ui.setupUi(this);

 

connect(ui.decEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(decChanged(const QString&)));

connect(ui.hexEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(hexChanged(const QString&)));

connect(ui.binEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(binChanged(const QString&)));

}

 

void ByteConverterDialog::decChanged(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok);

if (ok) {

ui.hexEdit->setText(QString::number(num, 16));

ui.binEdit->setText(QString::number(num, 2));

} else {

ui.hexEdit->setText(“”);

ui.binEdit->setText(“”);

}

}

 

Η υπερκείμενη αρχή ισχύει και εδώ: Είναι σημαντικό η συνάρτηση setupUi() να καλείται πρώτη πριν μπορούμε να κάνουμε χρήση της κλάσης γραφικής διεπαφής UI σε οποιοδήποτε τρόπο. Τα μειονεκτήματα της μεθόδου αυτής είναι η μή-αμεσότητα της, μέσω της μεταβλητής του μέλους. Το πλεονέκτημα της προσέγγισης αυτής είναι οτι διογκώνει το πρόβλημα ενθυλάκωσης, περιορίζοντας το πρόβλημα με το πεδίο εφαρμογής στην κλάση διαλόγου. Οποιαδήποτε εξωτερική πρόσβαση πρόσβαση εκτός του διαλόγου δεν είναι δυνατή σε οποιαδήποτε περίπτωση. Ένα έξτρα bonus: Είναι ξεκάθαρο από τον κώδικα ποιά widgets δημιουργήθηκαν από τον Designer. Επιπλέον, η προσέγγιση αυτή ταιριάζει περισσότερο σε widgets σε βιβλιοθήκες που έχου παραμείνει συμβατές ψηφιακά, καθώς μόνο ο δείκτης του στιγμιοτοτύπου των παραγόμενων κλάσεων αλλάζουν την δυαδική διάταξη στην έξοδο του μεταγλωτιστή.7

 

3.2.3 Πολλαπλή Κληρονομικότητα

 

Ως ιδανική λύση, η Trolltech προτείνει πολλαπλή κληρονομικότητα. Όπως και στην προηγούμενη λύση αυτή δουλεύει.

 

Στην μέθοδο αυτή το νέο widget κληρονομεί όχι μόνο από το QWidget αλλά και από την κλάση UI που παράγεται από την uic. Ένα ιδιαίτερο χαρακηριστικό είναι η χρήση μιας ιδιωτική λέξης κλειδί κατά την σύνθεση της κληρονομικότητας. Αυτό διασφαλίζει πως όλες σε όλες τις μεθόδους της κλάσεις UI δίνονται η κατάστασεις μεταβλητών των ιδιωτικών κλάσεων στις νέες κλάσεις, παρόλο που αυτές είναι δημοσίως προσβάσιμες στις προηγούμενες κλάσεις.

 

7 Περισσότερες πληροφοριές αναφορικά με την συμβατότητα C++ έχουν μεταγλωτιστεί από το KDE project στο http://developer.kde.org/documentation/other/binarycompatibility.html.

 

// inherit/byteconverterdialog.h

 

 

class ByteConverterDialog : public QDialog,

private Ui::ByteConverterDialog

 

 

Η μέθοδος αυτή επιλύει πολλά προβλήματα μονομιάς: Μπορούμε να κάνουμε χρήση των δεικτών των widgets που παράγονται από την uic ως κοινές μεταβλητές μελών, χωρίς πολύ κόπο μέσω ενός βοηθητικού αντικειμένου και παραμένουν ιδιωτικές έτσι ώστε να παραμένει η ενθυλάκωση του αντικειμενου προς τον εξωτερικό κόσμο.

 

Για το παράδειγμα μας αυτό σημαίνει ότι ο κατασκευαστής αλλάζει όπως ακολούθως:

 

// inherit/byteconverterdialog.cpp

 

ByteConverterDialog::ByteConverterDialog(QWidget *parent)

: QDialog(parent)

{

setupUi(this);

 

connect(decEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(decChanged(const QString&)));

connect(hexEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(hexChanged(const QString&)));

connect(binEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(binChanged(const QString&)));

}

 

void ByteConverterDialog::decChanged(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok);

if (ok) {

hexEdit->setText(QString::number(num, 16));

binEdit->setText(QString::number(num, 2));

} else {

hexEdit->setText(“”);

binEdit->setText(“”);

}

}

 

 

Όπως και πριν, χρειαζόμαστε μόνο να καλέσουμε την μέθοδο setupUi() στην πρώτη θέση σαν όρισμα που χρησιμοποιούμε ξανά σαν δείκτη στο widget που είναι στην τρέχουσα κλάση πεδίου.

 

Προσοχή: Η προσέγγιση της αλληλουχίας κληρονομικότητας είναι σημαντική. Η πρώτη κλάση πρέπει να κληρονομεί από την QDialog και μέτα από την κλάση του Designer. Σε άλλη περίπτωση ο μεταγλωτιστής θα βγάλει λάθος δυσνόητο, που οδηγεί τον  προγραματιστή σε απόγνωση.

 

moc_byteconverterdialog.cpp:43: error: ‘staticMetaObject’ is not a member of type ‘Ui::ByteConverterDialog’

moc_byteconverterdialog.cpp: In member function ‘virtual void* ByteConverterDialog::qt_metacast(const char*)’: moc_byteconverterdialog.cpp:60: error: ’class Ui::ByteConverterDialog’ has no member named ’qt_metacast’ moc_byteconverterdialog.cpp: In member function ‘virtual int ByteConverterDialog::qt_metacall(QMetaObject::Call, int, void**)’: moc_byteconverterdialog.cpp:66: error: ’class Ui::ByteConverterDialog’ has no member named ’qt_metacall’ make: *** [moc_byteconverterdialog.o] Error 1

 

Ο λόγος της συμπεριφοράς του μεταγλωτιστή μετά-αντικειμένου (meta-object) το οποίο ελέγχει εάν η πρώτη γονική κλάση της λίστας κληρονομικότητας, κληρονομεί από το QObject ή οχι. Αυτό επίσης σημαίνει ότι δεν μπορεί γενικά να κληρονομεί από πολλαπλές που έχουν όλες το QObject σαν κύρια κλάση.

 

3.3 Αυτόματες Συνδέσεις σημάτων/υποδοχών

 

Προγραματιστές εξικοιωμένοι με την Visual Basic ή Delphi που αρχίζουν την ανάπτυξη Qt/C++ βρίσκουν την λογική των σημάτων/υποδοχών ασυνίθηστη, παραβλέπουν την διαχειριστή ενεργειών (event handler). Η Qt 4 τους επιτρέπει να ακολουθούν την λογική που έχουν συνηθήσει, επιτρέποντας δηλώσεις υποδοχών στην φόρμα που μετατρέπονται σε εντολές connect() που αποθηκεύει uic στην setupUi() . Παρεμπιπτόντως η σύμβαση ονομασίας αυξάνει την αναγνωσιμότητα του κειμένου κώδικα.

 

void on objectname signalname();

 

Το όλο θέμα της λειτουργικότητας της στατικής μεθόδου QMetaObject::connectSlotsBy Name() : Αναμένει έναν δείκτη στο QObject και ψάχνει μέσα του για υποδοχείς που ταιριάζουν ονομαστικά. Μετά η QMetaObject::connectSlotsByName() συνδέει τους υποδοχείς που βρήκε με τα κατάλληλα σήματα. Για να γίνει αυτό χρησιμοποιεί πληροφορίες από το μετα-αντικείμενο που παράγεται από τον μεταγλωτιστή moc. Το αντικείμενο αυτό δίνει μια δυνατότητα στην C++ γνωστή ως ενδοσκόπηση (γνωστή στην Java ως reflection) σε όλες τις κλάσεις που κληρονομούν από το QObject. Κατά την εκτέλεση “γνωρίζει” τις μεθόδους της, τα σήματα και τους υποδοχείς της. Η connectSlotsByName() εξετάζει αναδρομικά τα ονόματα των υποδοχών του αντικειμένου πίσω από τους δείκτες και όλα τα παιδιά τους συνδέοντας τα αντίστοιχα σήματα σε αυτά.

 

Η Trolltech προτείνει την λογική που φαίνεται παραπάνω μόνο στις κλάσεις που δημιουργήθηκαν από τον Designer, δεδομένου ότι στην περίπτωση αυτή το όνομα αντικειμένου της κλάσης και του δείκτη που δημιούργησε η uic στην συσχέτηση widget, επειδή η setupUi() καλεί κατ ακολουθία την connectSlotsByName(). Όσοι βρίσκουν την σύμβαση ονοματολογίας δελεαστική, όλα τα σχετιζόμενα αντικείμενα πρέπει να ονομαστούν μέσω της setObjectName(), να κληθούν στον κατασκευαστή εκτός της QMetaObject::connectSlotsByName() και πρέπει να δίνουν έναν δείκτη στην τρέχουσα κλάση (this) στην κλήση αυτή.

 

Επειδή η παραπάνω λογική είναι επιρρεπής στα λάθη,8 πρέπει να κάνουμε αυτόματες συνδέσεις μόνο με τα widget που παράγει ο Designer με πολλαπλή κληρονομικότητα.

 

Θα τροποποιήσουμε τα παραπάνω παραδείγματα έτσι ώστε τα ονόματα των υποδοχέων να ακολουθούν στην σύμβαση για αυτόματες συνδέσεις. Την ίδια ώρα που η κλήσεις σύνδεσεις connect() παύουν να ισχύουν έτσι ώστε να παραμένουν μόνο οι εντολές setupUi().

 

// autoconnect/byteconverterdialog.h

 

private slots:

void on_decEdit_textChanged(const QString&);

void on_hexEdit_textChanged(const QString&);

void on_binEdit_textChanged(const QString&);

 

// autoconnect/byteconverterdialog.cpp

 

 

ByteConverterDialog::ByteConverterDialog(QWidget *parent)

: QDialog(parent)

{

setupUi(this);

}

 

void ByteConverterDialog::on_decEdit_textChanged(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok);

if (ok) {

hexEdit->setText(QString::number(num, 16));

binEdit->setText(QString::number(num, 2));

} else {

hexEdit->setText(“”);

binEdit->setText(“”);

}

}

 

 

8 Θυμόμαστε ότι μόνο τα ονόματα αντικειμένων σχετίζεται και ότι αυτή είναι η διαδικασία, ή Qt δεν μπορεί να εκδόσει προδειποιήσεις αναφορικά με συνδέσεις που αποτυγχάνουν κατά την εκτέλεση.

 

3.4 Συμπερίληψη των παραγόμενων κλάσεων στον Designer

 

Είναι σημαντικό σε ορισμένες περιπτώσεις να κάνουμε μικρές αλλαγές σε ένα συνηθισμένο Qt widget. Σε τέτοιες περιπτώσεις δεν μπορούμε τον Designer χωρίς να δηλώσουμε το νέο widget εκεί ως τροποποιημένο το οποίο περιλαμβάνει πολύ κόπο 9

 

Για να μπορούμε να συνεχίσουμε να κάνουμε χρήση του widget στον Designer, πρέπει να επιλέξουμε το βασικό Qt widget στον Designer και να το κλικάρουμε με το δεξί πλήκτρο του ποντικιού όταν έχει προσαρμοστεί. Από το μενού επιλέγουμε την λειτουργία Promote to Custom Widget. Στον διάλογο που εμφανίζει (βλέπε σχήμα 3.13) ορίζουμε το όνομα της νέας κλάσης του ονόματος και του αρχείου κεφαλής. Παρόλο που ο Designer συνεχίζει να δείχνει  το αρχικό Qt widget, το τελικό πρόγραμμα  κάνει χρήση του τροποποιημένου widget: ώστε στην υλοποίηση να παρέχουμε έναν δείκτη στο αντικείμενο τύπου του widget που κληρονομήθηκε.

 

Σχήμα 3.13: Χρησιμοποιώντας κλάσεις στον Designer ειναι πολύ απλό χάρη στην προώθηση widget. Συνήθως χρειαζόμαστε μόνο αυτό.

 

Για να αναιρέσουμε μια τέτοια προώθηση, η καταχώρηση Demote στην βασική κλάση μπορεί να βρεθεί στην ίδια θέση στο μενού επιλογών.

 

Αναφορικά με πολυπλοκότερες τροποοιήσεις όπως βασικές αλλαγές στην συμπεριφορά εμφάνισης ή προσθέτοντας ιδιότητες, η διαδικασία αυτή δεν είναι κατάλληλη, ωστόσο ο Designer δεν τα λαμβάνει αυτά υπόψιν.

 

3.5 Ο επεξεργαστής πόρων (Resource Editor)

 

Από την Qt 4 και μετά, ο Designer υποστηρίζει την παραμετροποίηση και διαχείριση όλων των πόρων που έχουν ήδη συζητθεί στην σελίδα 57. Ο συντάκτης που έχει ενσωματωθεί εδώ (Σχήμα 3.14) μπορεί να κληθεί από την επιλογή Tools → Resource Editor σε περίπτωση που δεν είναι ήδη ορατή. Η πλοήγηση σε αυτή απαιτεί εξοικείωση στην χρήση του. Το αναδυόμενο κουτί δίπλα στις επιλογές New και Open δείχνει μια λίστα με αρχεία πόρων που έχουν ήδη ανοιχτεί. Δεν περιλαμβάνει την ενέργεια αποθήκευσης καθώς αυτό γίνεται εμέσως από τον συντάκτη (editor).

 

Σχήμα3.14: Το παράδειγμα πόρων της σελίδας 57 στον Resource Editor του Designer

 

Επιπλέον ο κατάλογος των πόρων που εμφανίζονται στον Designer είναι ανεξάρτητος από αυτά στο αρχείο .pro . Για τον λόγο αυτό είναι σημαντικό να διασφαλίζουμε ότι όλοι οι πόροι εκχωρούνται εκεί με το όνομα RESOURCES.  Με την εκτέλεση της qmake οι πόροι γίνονται μέρος του project.

 

Για τον συσχετισμό μιας εικόνας από έναν πόρο σε ένα QLabel μέσα στον Designer, για παράδειγμα ψάχνουμε πρώτα στον Property Editor για την ιδιότητα pixmap και να κλικάρουμε πάνω στο εικονίδιο φακέλου. Στον επόμενο διάλογο βρίσκουμε τον Resource Editor επιλέγοντας Specify τον καθορισμό πηγής όπου επιλέγουμε μια από τις εικόνες. Για να εμφανιστούν τα επιθυμητά γραφικά στο παρόν μέγεθος widget, η ιδιότητα scaledContents στον  Property Editor πρέπει να οριστεί σε αληθές: αλλιώς θα παραμείνει στο αρχικό μέγεθος της εικόνας.

 

Qt – 2 – Απαιτούμενα εργαλεία για τη δημιουργία πλαισίων διαλόγων

•December 8, 2015 • Leave a Comment

2 – Απαιτούμενα εργαλεία για τη δημιουργία πλαισίων διαλόγων

 

Τώρα που έχουμε μια γενική εικόνα της Qt, θα επιστρέψουμε σε μια πρακτική εφαρμογή για να δουμε πως συνεργάζονται οι κλάσεις μεταξύ τους. Το πρώτο εκτενές πρόγραμμα θα μετατρέπει αριθμούς μεταξύ δεκαδικών, δεκαεξαδικών και δυαδικών μορφών, οπως φαίνεται στο σχεδιάγραμμα 2.1

 

Ο χρήστης του προγράμματος δύναται να εισάγει έναν αριθμό μονού byte (από 0 εώς 255) σε ένα από τα 3 πεδία εισόδου.  Το πρόγραμμα ανανεώνει τα άλλα δύο πεδία εισόδου με την τιμή μετατροπής

 

2.1 Ποιά είναι η διαφορά μεταξύ παραθύρων διαλόγων και Widgets;

 

Η κύρια συνάρτηση main() είναι σχεδόν ίδια με την συνάρτηση main() του προγράμματος “Hello World” που εξετάσαμε στην ενότητα 1.1:

 

// byteConverter/main.cpp

 

#include <QApplication>

#include “ByteConverterDialog.h”

 

int main(int argc, char *argv[])

{

QApplication a(argc, argv);

ByteConverterDialog bc;

bc.setAttribute(Qt::WA_QuitOnClose);

bc.show();

 

return a.exec();

}

 

Υπάρχει μόνο μία εξαίρεση: Η κλάση QLabel έχει αντικατασταθεί με την ByteConvertedDialog.

Αυτή η κλάση κληρονομείται από την QDialog και ο ορισμός της τοποθετείται στην κεφαλή του αρχείου ByteConverterDialog.h 1 H οδηγία #include η οποία ενσωματώνει το αρχείο κεφαλής στον κώδικα της εφαρμογής κάνει χρήση των εισαγωγικών (“) αντί των τριγωνικών υποστηριγμάτων (<>), εφόσον το αρχείο βρίσκεται στον ίδιο φάκελο με την main.cpp.

 

Έχουμε εισάγει επίσης, το χαρακτηριστικό WA_QuitOnClose στο πλαίσιο διαλόγου, ώστε να διασφαλίσουμε τον ομαλό τερματισμό του εφόσον κλείσει. Η προσθήκη αυτή δεν ήταν απαραίτητη στα προηγούμενα παραδείγματα, καθώς δεν κάναμε χρήση κλάσεων που κληρονομήθηκαν από την QDialog όπως στο κύριο παράθυρο. Εφόσον τα πλαίσια διαλόγων συνήθως παρέχουν δια-πληροφορίες, το χαρακτηριστικό αυτό δεν είναι ενεργοποιημένο εξ ορισμού για το QDialog. Ουτοσιάλως το κλείσιμο ενός πλαισίου διαλόγου, δεν πρέπει να προκαλεί τον τερματισμό του προγράματος, εκτός εάν υπάρχει ένα σοβαρό σφάλμα.

 

Περικλείουμε τα περιεχόμενα του αρχείου ByteConverterDialog.h με χαρακτήρες συμπερίληψης, αποτελούμενο απο τρεις εντολές προεπεξεργαστή #ifndef , #define και #endif:

 

1 Για τα αρχεία κεφαλής που δημιουργήσαμε εμείς, κάνουμε χρήση του προτύπου της C/C++ , την επέκταση .h, ώστε να είναι ξεκάθαρο το είδος του αρχείου.

 

// byteConverter/ByteConverterDialog.h

 

#ifndef BYTECONVERTERDIALOG_H

#define BYTECONVERTERDIALOG_H

 

#include <QDialog>

class QLineEdit;

 

class ByteConverterDialog : public QDialog

{

Q_OBJECT

 

public:

ByteConverterDialog();

 

private:

QLineEdit* decEdit;

QLineEdit* hexEdit;

QLineEdit* binEdit;

};

 

#endif

 

Η χρήση των χαρακτήρων συμπερίληψης είναι μια σύνηθες τεχνική στον προγραματισμό C/C++ για(την) αποφυγή προβλημάτων που προκύπτουν εάν πάνω από ένα αρχείο κώδικα επιχειρήσει την ενσωμάτωση ενός αρχείου κεφαλής με χρήση της #include, το οποίο συμβαίνει συνήθως σε μεγάλα προγράμματα με πολλές ανεξάρτητες υλοποιημένες ενότητες. Σε αυτή την περίπτωση, κατά την πρώτη εκτέλεση του ByteConverterDialog.h , ορίζεται η λέξη κλειδί BYTECONVERTERDIALOG_H. Εάν ένα μετέπειτα πηγαίο αρχείο προσπαθήσει να εκτελέσει την εντολή #include ByteConverterDialog.h ξανά, η οδηγία #ifndef …endif (“if not defined”) κάνει τον προεπεξεργαστή να παραλείψει τα περιεχόμενα των αρχείων κεφαλής. Χωρίς τους χαρακτήρες συμπερίληψης, ο μεταγλωττιστής θα είχε επισημάνε οτι οι λέξεις κλειδιά και οι κλάσεις έχουν οριστεί πολλές φορές και θα έβγαζε ένα μήνυμα λάθους.

Συμπεριλαμβάνουμε το αρχείο κεφαλής QDialog, εφόσον η κλάση ByteConverterDialog κληρονομεί από την QDialog. Προκειμένου να είναι διαθέσιμες οι λειτουργίες της QDialog εκτός της κλάσης ByteConverterDialog ,κάνουμε χρήση του ελέγχου πρόσβασης public.

 

Η δήλωση της κλάσης QLineEdit αποτελεί μια προχωρημένη δήλωση. Αντικείμενα της κλάσης ByteConverterDialog εμπεριέχουν τρεις ιδιωτικές μεταβλητές που δείχνουν αντικείμενα τύπου QLineEdit, έτσι ώστε ο μεταγλωτιστής C++ να γνωρίζει ότι η QLineEdit αποτελεί μια κλάση για να μπορέσει να εκτελέσει την δήλωση ByteConverterDialog, χωρίς να χρειάζεται να γνωρίζει τον ακριβή ορισμό της δήλωσης της κλάσης στο σημείο αυτό.

 

Ο συμβολισμός Q_OBJECT πρέπει να χρησιμοποιείται σε κάθε παράγωγο των κύριων κλάσεων QObject, συμπεριλαμβανομένου των έμμεσων, καθώς ορίζει συναρτήσεις πουμε την απουσία των οποίων η έννοια του σήματος / υποδοχής (signal/slot) δεν μπορεί να λειτουργήσει. (Περισότερα στην ενότητα 2.1.1.)

 

2 Εναλλακτικά, μπορούμε να συμπεριλάβουμε το αρχείο κεφαλής QLineEdit πριν την δήλωση του ByteConverterDialog, κάνοντας υποχρεωτική την ανάγνωση του, το οποίο θα καθυστερούσε αισθητά την μεταγλώττιση ειδικά σε παλαιούς υπολογιστές. Για τον λόγο αυτό, προσπαθούμε να βελτιστοποιούμε το αρχείο κεφαλής έτσι ώστε να ενσωμτατώνονται μόνο τα απολύτως απαραίτητα.

 

Ο κατασκευαστής (constructor) είναι η μόνη δημόσια συνάρτηση της κλάσης. Θα αποθηκεύσουμε δείκτες στα αντικείμενα QLineEdit, οι οποίοι θα προβάλλονται από τον μετατροπέα byte στις τρεις ενότητες μεταβλητών (decEdit, hexEdit, και binEdit) καθώς επιθυμούμε να ανανεώνονται τα πεδία εισόδου στα οποία ο χρήστης δεν εισάγει δεδομένα κατευθειαν, ώστε να διασφαλίζουμε ότι οι τρεις γραμμές εξόδου δείχουν το ίδιο κείμενο. Επειδή αυτό αποτελεί μια λεπτομέρεια υλοποίησης της κλάσης ByteConverterDialog, τις ορίζουμε σαν ιδιωτικές (private) μεταβλητές.

 

2.1.1 Κληρονομικότητα από QObject

 

Όπως προαναφέραμε, πρέπει πάντα να κάνουμε χρήση του συμβολισμού Q_OBJECT όταν μια κλάση κληρονομεί άμεσα ή έμμεσα από το QObject 3  .Ο συμβολισμός αυτός ορίζει το πλήθος συναρτήσεων που υλοποιούν τη λογική του σήματος / υποδοχής (signal/slot). Δυστυχώς, έαν απουσιάζει ο συμβολισμός αυτός στον ορισμό της κλάσης που κληρομεί (ται;)από το QObject, ούτε ο μεταγλωτιστής ούτε o διασυνδετής (linked) θα αναφέρουν σφάλμα. Αντιθέτως, τα σήματα και οι υποδοχείς της κλάσης θα παραμείνουν άγνωστα στο Qt, και κατά την εκτέλεση οι αντίστοιχες συνδέσεις δεν θα λειτουργούν.

 

Εφαρμογές που μεταγλωττίζονται με πληροφορίες αποσφαλμάτωσης θα επισημαίνουν κατά την εκτέλεση (σε παράθυρο γραμμής εντολών) ότι δεν υπάρχει σήμα ή υποδοχέας κάθε φορά που ένα κομμάτι κώδικα εκτελείται και προσπαθεί να αποκτήσει πρόσβαση σε ένα άγνωστο σήμα ή υποδοχέα. Το μήνυμα λάθους είναι το ακόλουθο:

Object::connect: No such slot QObject::decChanged(QString)

 

Ωστόσο, το παραπάνω μήνυμα λάθους είναι μη συγκεκριμένο. Επιπλέον, θα το συναντήσουμε έαν γράψουμε λάθος το όνομα ενός σήματος ή υποδοχέα ή την λίστα ορισμάτων λανθασμένα.

 

Κάθε αρχείο που κάνει χρήση του συμβολισμού Q_OBJECT υποχρεούται να εκχωρηθεί στο πρόγραμμα γραμμής-εντολών (βλ. σελίδα 56). Το εργαλείο αυτό παράγει αυτόματα τον κώδικα που μετατρέπεται σε καθαρή C++ από τον μηχανισμό σήματος / υποδοχέα 4

 

Σε περίπτωση χρήσης του qmake στην εφαρμογή μας, το εργαλείο qmake αναζητεί όλα τα αρχεία κεφαλής και πηγαίου κώδικα που αναφέρονται στο αρχείο .pro του συμβολισμού Q_OBJECT. Όταν βρίσκει ένα, το qmake παράγει αυτόματα τις απαιτούμενες εντολές κατασκεύης βασισμένες στην moc, μέσα στα περιεχόμενα των αρχείων αυτών 5

 

Για να λειτουργήσει σωστά, πρέπει να οριστεί το αρχείο κεφαλής στο αρχείο .pro . Πρέπει να γίνει χρήση των μεταβλητών κεφαλής της qmake (HEADERS), όπως αντιστοίχως θα γινόταν με την μεταβλητή SOURCES για τα αρχεία κώδικα:

 

3 Ορισμένοι μεταγλωττιστές παράγουν σφάλματα, όταν ο συμβολισμός Q_OBJECT τερματιστεί με άνω τελεία όπου, για λόγους φορητότητας, συνίσταται οπωσδήποτε η παράλειψη του.

 

4 Ο moc δεν τροποποιεί τα αρχεία μας αλλά παρέχει νέο κώδικα που διαχωρίζει τα αρχεία που πρέπει να προσέξουμε όταν γράφουμε τα αρχεία Makefiles με το χέρι. Σε περίπτωση χρήσης του qmake όπως συνιστούμε, δεν χρειάζεται να μας απασχολεί αυτό.

 

5 Η qmake δεν ανιχνεύει την μετέπειτα προσθήκη του συμβολισμού Q_OBJECT στα αρχεία.

 

#byteConverter/byteConverter.pro

 

TEMPLATE = app

 

SOURCES = main.cpp \

ByteConverterDialog.cpp

HEADERS = ByteConverterDialog.h

 

Σε περίπτωση που η moc δεν καλείται για αρχεία που εμπεριέχουν συμβολισμούς Q_OBJECT, ο διασυνδετής βγάζει μηνύματα λάθους για άγνωστα σύμβολα, και το GCC εξάγει τα παρακάτω μηνύματα λάθους:

 

ld: Undefined symbols:

vtable for ByteConverterDialog

ByteConverterDialog::staticMetaObject

 

Σε περίπτωση που συναντήσουμε αυτό το μήνυμα λάθους, ελέγχουμε τα παρακάτω:

 

  • Έχουν οριστεί σωστά οι μεταβλητές κεφαλής (HEADERS) της qmake;

 

  • Have the qmake variable HEADERS been properly defined?

 

  • Η εκ νέου παραγωγή των αρχείων Makefiles με χρήση της qmake διορθώνει το πρόβλημα;

 

  • Is the problem resolved if the Makefiles are regenerated with qmake?

 

2.1.2 Σύνθετες Μορφές Σχεδιάγραματων

 

Θα ασχοληθούμε με την υλοποίηση της κλάσης ByteConverterDialog. Κατά την δημιουργία των περιστάσεων (instances) της κλάσης, η συνάρτηση του κατασκευαστή παράγει όλα τα QLineEdit widgets που προβάλλονται απο το νέο αντικείμενο ByteConverterDialog και τα εισάγει στον νέο μας διάταξη. Ωστόσο, αυτό δεν είναι τόσο απλό όπως προηγουμένως: όταν ο χρήστης αλλάζει το μέγεθος του πλαισίου διαλόγου, για τη σωστή και διαισθητική λειτουργία της εφαρμογής μας, πρέπει να γίνει χρήση των εμφωλευμένων διατάξεων. Το σχέδιο 2.2 δίχνει πώς η Qt διασφαλίζει ότι τα πεδία εισόδου θα εμφανίζονται πάντα στο πάνω μέρος του παραθύρου και το κουμπί τερματισμού εμφανίζεται στην κάτω-δεξία γωνία του παραθύρου.

 

Δεν συντρέχει λόγος ανησυχίας: ακόμη και αν ο πηγαίος κώδικας του κατασκευαστή (constructor) γίνει μεγάλος, γίνεται χρήση απλών συναρτήσεων :

 

But don’t panic: Even though the source code for the constructor becomes quite long, it uses only simple functions:

 

// byteConverter/ByteConverterDialog.cpp

 

#include “ByteConverterDialog.h”

#include <<QLabel>

#include <QLineEdit>

#include <QPushButton>

#include <QVBoxLayout>

#include <QHBoxLayout>

#include <QGridLayout>

 

ByteConverterDialog::ByteConverterDialog()

{

// Generate the necessary layouts

QVBoxLayout* mainLayout = new QVBoxLayout(this);

QGridLayout* editLayout = new QGridLayout;

QHBoxLayout* buttonLayout = new QHBoxLayout;

 

mainLayout->addLayout(editLayout);

mainLayout->addStretch();

mainLayout->addLayout(buttonLayout);

 

// Generate the labels and line-edits and add them

// to the object pointed at by editLayout

QLabel* decLabel = new QLabel(tr(“Decimal”));

QLabel* hexLabel = new QLabel(tr(“Hex”));

QLabel* binLabel = new QLabel(tr(“Binary”));

decEdit = new QLineEdit;

hexEdit = new QLineEdit;

binEdit = new QLineEdit;

 

editLayout->addWidget(decLabel, 0, 0);

editLayout->addWidget(decEdit, 0, 1);

editLayout->addWidget(hexLabel, 1, 0);

editLayout->addWidget(hexEdit, 1, 1);

editLayout->addWidget(binLabel, 2, 0);

editLayout->addWidget(binEdit, 2, 1);

 

// Create the Quit button and add it to the object pointed

// at by buttonLayout

QPushButton* exitButton = new QPushButton(tr(“Quit”));

 

buttonLayout->addStretch();

buttonLayout->addWidget(exitButton);

 

Το σχέδιο 2.3 απεικονίζει ποιες διατάξεις εμπλέκονται με ποια widgets. Δώστε προσοχή σε αυτές καθώς εξετάζουμε βήμα-βήμα τον παραπάνω κώδικα.

 

Το αντικείμενο mainLayout, μια κάθετη διάταξη κουτιού, είναι υπέθυνο για την διάταξη ολόκληρου του πλαισίου διαλόγου. Έτσι, περνάμε έναν δείκτη στο αντικείμενο ByteConverterDialog όταν καλούμε τον κατασκευαστή του. Για να γίνει αυτό, κάνουμε χρήση του δείκτη this, εφόσον βρισκόμαστε στην συνάρτηση της ίδιας της κλάσης ByteConverterDialog.

 

Το αντικείμενο editLayout είναι υπεύθυνο για την διάταξη των ετικετών και των widget γραμμής επεξεργασίας. Για να γίνει οργανωμένη στοίβαξη των στοιχειων και να οργανωθούν τα widgets σε μια και μοναδική στήλη, κάνουμε χρήση της διάταξης πλέγματος.

 

Η διάταξη buttonLayout, την οποία κατασκευάζουμε με την τρίτη νέα κλήση, θα είναι υπεύθυνη για διαχείριση του κουμπιού τερματισμού (Quit). Ωστόσο, πριν μπορέσουμε να παράξουμε widgets όμοια του κουμπιού αυτού και την προσθήκη τους στις editLayout και buttonLayout, πρέπει να τις προσθέσουμε τις διατάξεις αυτές στη βασική mainLayout με χρήση της addLayout(), αντίστοιχο του addWidget(). Σε περίπτωση προσθήκης widgets σε μία διάταξη που δεν συσχετίζεται με ένα widget, θα μας εμφανίσει το ακόλουθο μήνυμα σφάλματος στο παράθυρο της γραμμής εντολών.

 

QLayout::addChildWidget: προσθήκη προτύπου εμφάνισης στο γονικό πριν προσθέσουμε θυγατρικά.

 

Τα widgets θα παραμείνουν ορατά. Ως εκ τούτου, πρέπει να παράγουμε την βασική διάταξη της κλάσης πρώτα, και στη συνέχεια να συνεχίσουμε στην επόμενη διάταξη “layer”, και ούτω καθεξής.

 

Για να διασφαλίσουμε οτι τα πεδία εισόδου βρίσκονται στο πάνω μέρος του παραθύρου διαλόγου ByteConverterDialog και το κουμπί τερματισμού κάτω-δεξιά, κάνουμε χρήση των τεντωμάτων (Stretches).

 

Τα τεντώματα (Stretches) καταλαμβάνουν το κενό που δεν χρειάζονται τα widgets με συνέπεια να δημιουργούν κενά τμήματα στο παράθυρο διαλόγου μας. Έαν παραλείπαμε τα τεντώματα στο παράδειγμα μας, τα widgets θα καταλάμβαναν ολόκληρο το χώρο. Στην περίπτωση που ο χρήστης αύξανε το μέγεθος του πλαισίου διαλόγου χωρίς τεντώματα, θα βλέπαμε κάτι αντίστοιχο με το σχήμα 2.4

 

Για την αποφυγή αυτής της συμπεριφοράς, προσθέτουμε ένα τέντωμα μεταξύ των συναρτήσεων editLayout και buttonLayout.

 

Τώρα μπορούμε να παράξουμε ετικέτες και γραμμές επεξεργασίας και να τις εμπιστευτούμε στην editLayout. Σώζουμε τα αντικείμενα γραμμών επεξεργασίας στις μεταβλητές decEdit, hexEdit, and binEdit της ιδιωτικής κλάσης, καθώς θέλουμε να μπορούμε να επεξεργαζόμαστε τα περιεχόμενα τους με χρήση κώδικα που εμπεριέχεται σε άλλες συναρτήσεις. Γιαόλα τα υπόλοιπα αντικείμενα τα διαχειριζόμαστε χωρίς τους αντίστοιχους δίκτες, επειδή δεν χρειάζεται να αποκτήσουμε πρόσβαση έξω απο τον κατασκευαστή.

 

Now we can generate the labels and line edits and entrust them to the editLayout. We save the line edit objects in the private class variables decEdit, hexEdit, and binEdit, because we want to change their contents through code stored in other functions. For all other objects, we can manage without corresponding pointers because we do not need to access them outside the constructor.

 

Για την διασφάλιση της εμφάνισης του κουμπιού τερματισμού στο κάτω δεξία άκρο του παραθύρου διαλόγου, γεμίζουμε την διάταξη buttonLayout με ένα τέντωμα (stretch) πριν ρυθμίσουμε το ίδιο το κουμπί.

 

Προσθέτοντας όλα τα widgets και τις υποδιατάξεις στο αντικείμενο mainLayout ή τα παράγωγά του με χρήση των QObject::addWidget() and QObject::addLayout(), διασφαλίζουμε ότι όλα τα αντικείμενα που παρήχθησαν από τον κατασκευαστή με νέα, που κληρονομήθηκαν από το αντικείμενο ByteConverterDialog. Καθώς τώρα σχηματίζουν μια ιεραρχία αντικειμένων κατανεμημένου σωρού, με χρήση της διαχείρηση μνήμης της Qt, δεν απαιτείται χειροκίνητη διαγραφή τους. Όταν το αντικείμενο ByteConverterDialog διαγραφεί, όλα τα παιδιά του θα εξαφανιστούν αυτόματα.

 

Μήπως απογοητευτήκατε από τον όγκο του κώδικα που απαιτήθηκε για την δημιουργία ενός απλού πλαισίου διαλόγου; Ακολουθεί βοήθεια στο Κεφάλαιο 3, όπου εξηγεί πώς δύναται να σχεδιάσουμε ένα πλαίσιο διαλόγου με χρήση του Qt Designer με αυτόματη παραγωγή κώδικα. Περισσότερες πληροφορίες αναφορικά με τις διατάξεις στο Κεφάλαιο 5.

 

2.1.3 Αύξηση Ευχρηστίας

 

Παρά τις βελτιώσεις στην διάταξη, το πλαίσιο διαλόγου δεν συμπεριφέρεται ιδανικά σε ορισμένα σημεία:

 

Ο τίτλος του παραθύρου εμφανίζει το όνομα του προγράμματος byteConverter. Θα ήταν προτιμότερο κάτι πιο περιγραφικό.

 

Το κουμπί τερματισμού πρέπει να γίνει το προεπιλεγμένο κουμπί του πλαισίου διαλόγου. Το προκαθορισμένο κουμπί ενεργοποιείται από το (Enter) ακόμη και εάν προς το παρόν δεν είναι εστιασμένο στο πληκτρολόγιο. Τα περισότερα σχέδια widgets δίνουν έμφαση στο προκαθορισμένο κουμπί με έναν συγκεκριμένο τρόπο.

 

Σε αυτό το στάδιο μπορούμε να εισάγουμε οποιουσδήποτε αριθμούς στα widgets γραμμών επεξεργασίας. Είναι αναγκαίο να περιορίσουμε αυτές σε έγκυρες τιμές, μεταξύ ολόκληρων δεκαδικών αριθμών απο 0 εώς 255, δεκαεξαδικούς αριθμούς με μέγιστο δύο ψηφίων, και δυαδικών αριθμών με μέγιστο οχτώ bits.

 

Η λύση των παραπάνω προβλημάτων γίνεται με την προσθήκη των παρακάτω γραμμών κώδικα στον κατασκευαστή:6

 

// byteConverter/ByteConverterDialog.cpp (continued)

 

exitButton->setDefault(true);

 

// Limit input to valid values

QIntValidator* decValidator =

new QIntValidator(0, 255, decEdit);

decEdit->setValidator(decValidator);

 

QRegExpValidator* hexValidator =

new QRegExpValidator(QRegExp(“[0-9A-Fa-f]{1,2}”), hexEdit);

hexEdit->setValidator(hexValidator);

 

QRegExpValidator* binValidator =

new QRegExpValidator(QRegExp(“[01]{1,8}”), binEdit);

binEdit->setValidator(binValidator);

 

setWindowTitle(tr(“Byte Converter”));

 

 

Ορισμός τίτλου Παραθύρου

 

Τα πρώτα δύο προβλήματα επιλύονται με μια επιπλέον γραμμή κώδικα. Για την επίλυση του πρώτου προβλήματος, κάνουμε χρήση της συνάρτησης setWindowTitle(), η οποία καθορίζει τον τίτλο του παραθύρου του widget εάν αυτό καταλαμβάνει ένα παράθυρο ανωτάτου επιπέδου (top-level). Η συνάρτηση αυτή αποτελεί μια μέθοδο της κλάσης QWidget. Εφόσον το ByteConverterDialog έχει το QWidget σαν βασική κλάση, αυτή κληρονομεί την συνάρτηση, και μπορούμε απλά να την καλέσουμε.

 

Ορισμός του προεπιλεγμένου Κουμπιού

Specifying the Default Button

 

Το προεπιλεγμένο κουμπί του πλαισίου διαλόγου ορίζεται μέσω της ενημέρωσης του (αντί του πλαισίου διαλόγου) ως το προεπιλεγμένο κουμπί. (Επισημαίνουμε ωστόσο, ότι η κλήση του setDefault(true) σε ένα αντικείμενο QPushButton έχει επίδραση μόνο εάν το κουμπί χρησιμοποιείται σε ένα πλαίσιο διαλόγου—στο κυρίως παράθυρο δεν υπάρχουν προεπιλεγμένα κουμπιά. Εάν προσπαθήσουμε να ορίσουμε ένα προεπιλεγμένο κουμπί για το κυριώς παράθυρο, η Qt θα εμφανίσει ένα, χωρίς όμως να το ενεργοποιεί όταν ο χρήστης πατήσει το πλήκτρο Enter).

 

6 Για την μεταγλώττιση του παραγόμενου κώδικα, προσθέστε τις γραμμές #include που λείπουν (παραλείπονται παραπάνω για λόγους σαφήνειας) για τις κλάσεις που χρησιμοποιήθηκαν για πρώτη φορά εδώ, QIntValidator και QRegExpValidator!

 

Έλεγχος Δεδομένων Εισόδου Χρήστη

Checking User Input

 

Το τρίτο πρόβλημα, που περιορίζει την εισαγωγή  έγκυρων τιμών στα widget γραμμών επεξεργασίας, απαιτεί περισσότερη δουλειά, αλλά μπορεί να επιλυθεί μέσω επικυρωτών (validators). Αυτοί κληρονομούν από την QValidator όπως η βασική κλάση. Ένας επικυρωτής συσχετίζεται με ένα γονικό αντικείμενο που δέχεται δεδομένα εισόδου και ενημερώνει έαν το αντικείμενο μπορεί ή όχι να δεχτεί την τρέχουσα τιμή εισόδου.

 

Για τον έλεγχο της εγκυρότητας του δεκαδικού αριθμού, κάνουμε χρήση ενός αντικειμένου QIntValidator. Αυτό δημιουργείται με την κλήση του κατασκευαστή και περνώντας σε αυτόν, ως το πρώτο και δεύτερο γνώρισμα, τις έλαχιστες και μέγιστες τιμές που επιτρέπονται. Το τρίτο γνώρισμα εδώ, το decEdit, αποτελεί δείκτη στο αντικείμενο γραμμής επεξεργασίας που θέλουμε να ορίσουμε εως το γονικό αντικείμενο του επικυρωτή (validator). Αυτή η κλήση, εκτός απο την δέσμευση του επικυρωτή στο widget εισόδου, επιτρέπει την αυτόματη διαχείριση μνήμης, έτσι ώστε ο επικυρωτής θα επαναδιατεθεί μάζι με το widget. Η κλήση της setValidator() προκαλεί τον επικυρωτή να ελέγχει τα δεδομένα εισόδου που δίνονται απο το αντικείμενο που δείχνει το decEdit. Τώρα ο χρήστης μπορεί να πληκτρολογήσει ολόκληρους αριθμούς μεταξύ του 0 και 255 στο πεδίο εισόδου.

 

Για τον έλεγχο της εγκυρότητας των δεκαεξαδικών αριθμών, πρέπει να κάνουμε χρήση μιας άλλου τύπου επικύρωσης: QRegExpValidator. Αυτή συγκρίνει την είσοδο, που διαβάζει σαν σειρά χαρακτήρων, με μια κανονική έκφραση η οποία είναι [0-9A-Fa-f]{1,2}. Η πρώτη υποέκφραση σε αγκύλες καθορίζει τους χαρακτήρες που επιτρέπονται στην είσοδο: τα ψηφία 0 εώς 9, και οι χαρακτήρες A εώς F (είτε εώς κεφαλαία ή μικρά). Η ακόλουθη υποέκφραση, {1,2} περιορίζει το μέγεθος της συμβολοσειράς εισόδου σε τουλάχιστον ένα ή το πολύ δύο χαρακτήρες.

 

Οι κανονικές εκφράσεις σε Qt σχετίζονται με αυτές στην Perl, αλλά υπάρχουν ορισμένες σημαντικές διαφορές. Για παράδειγμα, είναι αναγκαία η διαφυγή μιας ανάστροφης καθέτου (\) σε μια έκραση όπως στην Perl, μια κανονική έκφραση με μια επιπλέον ανάστροφη κάθετο για να έχουμε την αντίστοιχη έκφραση Qtstyle, καθώς η μονή λειτουργεί ήδη σαν χαρακτήρας διαφυγής στην C/C++. Τότε η QRegExp αναγνωρίζει την διπλή ανάστροφη κάθετο σαν απλή. Από αυτό προκύπτει ότι πρέπει να πληκτρολογήσουμε  τέσσερις ανάστροφες καθέτους έαν επιθυμούμε να ορίσουμε μια κανονική κάθετο μέσα σε μια έκφραση Qt-style.

 

Επιπλέον, κάνουμε χρήση ενός QRegExpValidator μαζί με την κανονική έκφραση [01]{1,8} σαν επικυρωτή για το πεδίο εισαγωγής που αφορά δυαδικούς αριθμούς. Η έκφραση αυτή επιτρέπει μόνο τους χαρακτήρες 0 και 1 στην συμβολοσειρά εισόδου, αλλά αυτή μπορεί να είναι οπουδήποτε απο ένα εώς οχτώ χαρακτήρες σε μήκος.

 

2.1.4 Υλοποίηση Υποδοχών (Slots)

 

Τέλος, είναι αναγκαίο να υλοποιήσουμε τις λειτουργικές διασυνδέσεις που καθιστούν το κουμπί Quit λειτουργικό και να συγχρονίσουμε τα τρία πεδία εισόδου μεταξύ τους.

 

Για να εξασφαλιστεί ότι κάνοντας κλικ στο κουμπί Quit θα κλείσει το παράθυρο διαλόγου μετατροπής byte, επεκτείνουμε τον κατασκευαστή ByteConverterDialog έτσι ώστε να συσχετίζει το σήμα clicked() του κουμπιού με τον υποδοχέα accept() του παραθύρου διαλόγου. Ο υποδοχέας αυτός που παρέχεται από το QDialog, τον οποίο η κλάση ByteConverterDialog κληρονομεί από:

 

// byteConverter/ByteConverterDialog.cpp (continued)

 

connect(exitButton, SIGNAL(clicked()),

this, SLOT(accept()));

 

Όταν καλείται η μέθοδος accept(), απλά κλείνει το παράθυρο του διαλόγου. Η χρήση της accept() εδώ ακολουθεί μια γενική σύμβαση: ένας μεγάλος αριθμός παραθύρων διαλόγων έχουν ένα κουμπί ΟΚ και ένα κουμπί Ακύρωσης στο κάτω μέρος: Το ΟΚ αντιστοιχεί στον υποδοχέα accept() και το Cancel στον υποδοχέα reject(). Και οι δύο κλείνουν το παράθυρο διαλόγου, το πρώτο με μια θετική τιμή επιστροφής και η δεύτερη με μια αρνητική τιμή (βλέπε Κεφάλαιο 6, σελίδα 161). Σε αυτό το παράδειγμα έχουμε ένα μόνο κουμπί και, εώς εκ τούτου, δεν μας απασχολεί η τιμή επιστροφής, παρά μόνο η ενέργεια.

 

Ωστόσο, η λογική κατά την εκτέλεση σε πραγματικό χρόνο της εφαρμογής μετατροπής byte, περιλαμβάνει την επαύξηση των σημάτων και υποδεχέων με αρκετές προσαρμοσμένες διασυνδέσεις που ειδικεύονται στην λειτουργία της κλάσης ByteConverterDialog. Αυτά τα σήματα/διασυνδέσεις πρέπει να έρχονται σε δράση όταν οποιοδήποτε από τα αντικείμενα QLineEdit εκπέμψει σήμα textChanged(), υποδηλώνοντας οτι το κείμενο στο συγκεκριμένο πεδίο εισόδου του εν λόγω αντικειμένου έχει αλλάξει. Για τον σκοπό αυτό, επεκτείνουμε τον ορισμό της κλάσης μας ως εξής:

 

// byteConverter/ByteConverterDialog.h (continued)

 

class ByteConverterDialog : public QDialog

{

 

private slots:

void decChanged(const QString&);

void hexChanged(const QString&);

void binChanged(const QString&);

};

 

Οι υποδοχές (slots) δηλώνονται με τον ίδιο τρόπο όπως οι κανονικές συναρτήσεις, με την διαφορά ότι για τον έλεγχο πρόσβασης κάνουμε χρήση των επισημασμένων δημόσιων υποδοχέων: προστατευμένες υποδοχές, τις ιδιωτικές υποδοχές, αντί των συνηθισμένων δημόσιων υποδοχών, προτατευμένους και ιδιωτικούς τρόπους προστασίας.

 

Κάθε μια από τις τρεις υποδοχές δέχεται ένα όρισμα τύπου const QString&. Με τον τρόπο αυτό το σήμα textChanged() της συνάρτησης μπορεί να περνά νέο κείμενο στην γραμμή επεξεργασίας.

 

Για τον καθορισμό του είδους ορισμάτων των σημάτων/υποδοχέων, δεν επιλέγουμε απλά το QString αλλά μια αναφορά στο const QString. Υπάρχουν δύο λόγοι για αυτό. Αρχικά, χρησιμοποιώντας την κλήση μέσω αναφοράς αντί της κλήσης μέσω τιμής, το αντικείμενο QString που εμπεριέχει την νέα είσοδο που θα περαστεί στα σήματα/υποδοχείς δεν θα αντιγραφεί όταν αυτά κληθούν, καθιστώντας τον κώδικα αποτελεσματικότερο. Ωστόσο, η κλήση μέσω αναφοράς επιτρέπει στη συνάρτηση να τροποποιεί την παράμετρο, κάτι που δεν  επιτρέπεται να κάνουν τα σήματα και υποδοχείς. Έτσι η παράμετρος δηλώνεται σαν αναφορά στο const data. Το δεύτερο βήμα συνίσταται σαν πρακτική “αμυντικού προγραματισμού” κάθε φορά που μια συνάρτηση δεν επιτρέπεται να αλλάξει μια υπάρχουσα παράμετρο που έχει περαστεί από αναφορά.

 

Ακόμη και αν η δήλωση του υποδοχέα διαφέρει ελαφρώς από άλλες συναρτήσεις, παραμένει μια καθορισμένη συνάρτηση, η οποία υλοποιείται και μπορεί να κληθεί με τον συνηθισμένο τρόπο. Εδώ βρίσκουμε τον ορισμό της υποδοχής decChanged() και του αρχείου ByteConverterDialog.cpp:

 

// byteConverter/ByteConverterDialog.cpp (continued)

 

void ByteConverterDialog::decChanged(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok);

if (ok) {

hexEdit->setText(QString::number(num, 16));

binEdit->setText(QString::number(num, 2));

} else {

hexEdit->setText(“”);

binEdit->setText(“”);

}

}

 

Η συνάρτηση δέχεται σαν όρισμα μια συμβολοσειρά που εμφανίζεται απο το δεκαδικό widget γραμμής επεξεργασίας ως την πραγματική τιμή για την παράμετρο newValue, και ανανεώνει τις συμβολοσειρές που εμφανίζονται από τα δεκαεξαδικά και δυαδικά widgets. Αρχικά πρέπει να καθορίσουμε την αριθμητική τιμή που αντιστοιχεί στην συμβολοσειρά εισόδου. Ως αντικείμενο της κλάσης QString, η newValue διαθέτει πολλές συναρτήσεις που μετατρέπουν τις συμβολοσειρές σε αριθμητικές τιμές. Θα κάνουνε χρήση της συνάρτησης toInt(), εφόσον η είσοδος ειναι συμβολοσειρά που αναπαριστά μια ακέραια τιμή.

 

Η συνάρτηση toInt() δέχεται έναν δυαδικό δείκτη σαν προαιρετικό όρισμα: αν το όρισμα έχει καθοριστεί, η συνάρτηση ορίζει αληθή τη μεταβλητή στην οποία δείχνει σε τιμή, αν η συμβολοσειρά μετατραπεί επιτυχώς σε αριθμητική τιμή, και σε αναληθή σε περίπτωση που αποτύχει η μετατροπή, λαμβάνοντας υπόψιν ότι η συμβολοσειρά δεν αναπαριστά ακέραια τιμή.

 

Εάν η μετατροπή είναι επιτυχής, θέτουμε τα κείμενα που εμφανίζονται από τις γραμμές επεξεργασίας (hexEdit και binEdit) στα δεκαεξαδικά και δυαδικά αντίστοιχα της νέας τιμής. Για να γίνει αυτό, μετατρέπουμε τον αριθμό σε συμβολοσειρά που αναπαριστά τη νέα τιμή σε δεκαεξαδική μορφή καθώς και σε συμβολοσειρά που αναπαριστά τη νέα τιμή σε δυαδική μορφή. Για τον σκοπό αυτό, η κλάση QString έχει τη στατική συνάρτηση number(), η οποία επιστρέφει την αναπαράσταση του αριθμού σαν συμβολοσειρά. Ο ίδιος ο αριθμός είναι το πρώτο όρισμά του. Σαν δεύτερο όρισμα, η συνάρτηση number() αναμένει τη βάση για τον αριθμό συστήματος που χρησιμοποιήθηκε, στην περίπτωση μας 16 για δεκαεξαδικό και 2 για δυαδικό. Το δεύτερο όρισμα είναι προαιρετικό, και σε περίπτωση που δεν καθοριστεί, η συνάρτηση number() υποθέτει βάση 10 (δεκαδικό σύστημα), που είναι η συνηθέστερη περίπτωση.

 

Σε περίπτωση που η συνάρτηση toInt() δε δύναται να μετατρέψει τη συμβολοσειρά που εισήχθη στην widget δεκαδικής γραμμής επεξεργασίας σε αριθμό, γράφουμε ένα κενό κείμενο στα άλλα δύο widgets γραμμής επεξεργασίας, με χρήση της setText(). Χάρη στον μηχανισμό επικύρωσης που χρησιμοποιήσαμε για το αντικείμενο decEdit, το οποίο διασφαλίζει ότι μόνο οι αριθμοί εύρους 0 εώς 255 επιτρέπονται να εισαχθούν, η μετατροπή θα αποτύχει σε μια μοναδική περίπτωση: αν ο χρήστης διαγράψει εντελώς τις τιμές εισόδου.

 

Υλοποιούμε τις δύο εναπομείνασες υποδοχές με το ίδιο τρόπο:

 

// byteConverter/ByteConverterDialog.cpp (continued)

 

void ByteConverterDialog::hexChanged(const QString& newValue)

{

if (ok) {

decEdit->setText(QString::number(num));

binEdit->setText(QString::number(num, 2));

} else {

}

}

 

void ByteConverterDialog::binChanged(const QString& newValue)

{

if (ok) {

decEdit->setText(QString::number(num));

hexEdit->setText(QString::number(num, 16));

} else {

}

}

 

Στις συναρτήσεις αυτές και κατά την μετατροπή της συμβολοσειράς σε ακέραια τιμή, καθορίζουμε την βάση σε ένα δεύτερο προαιρετικό όρισμα στο toInt(); όπως η QString::number(), toInt() κάνει χρήση της βάσης του 10 εξ ορισμού όταν το όρισμα αυτό παραλείπεται.

 

Προκειμένου τα τμήματα αυτά της εφαρμογής μας να λειτουργούν μαζί σύμφωνα με τον σχεδιασμό μας, πρέπει να διασυνδέσουμε τα σήματα textChanged() για κάθε ένα από τα αντικείμενα μας QLineEdit με τον αντίστοιχο υποδοχέα. Για να γίνει αυτό επεκτείνουμε τον κατασκευαστή για τελευταία φορά:

 

// byteConverter/ByteConverterDialog.cpp (continued)

 

connect(decEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(decChanged(const QString&)));

connect(hexEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(hexChanged(const QString&)));

connect(binEdit, SIGNAL(textChanged(const QString&)),

this, SLOT(binChanged(const QString&)));

}

 

Ο κώδικας του κατασκευαστή της κλάσης ByteConverterDialog έχει ολοκληρωθεί και εκτελεί τρείς διαφορετικές λειτουργίες:

 

  • Δημιουργεί όλα τα widgets ενός παραθύρου διαλόγου, τα ενσωματώνει μέσα στις αντίστοιχες διατάξεις και καθορίζει την ιεραρχία αντικειμένων του παραθύρου.

 

  • Περιορίζει τις τιμές εισόδου σε επιθυμητές τιμές

 

  • Δημιουργεί όλες τις απαραίτητες συνδέσεις σημάτων/υποδοχών

 

Ολόκληρη η λογική του κώδικα της εφαρμογής εμπεριέχεται στον κώδικα των υποδοχέων και στις συνδέσεις των αντίστοιχων σήματων.

 

2.2 Διαχωρισμός του Γραφικού Κελύφους και της Λογικής Επεξεργασίας

 

2.2.1 Εναλλακτικός Σχεδιασμός

 

Στο προηγούμενο παράδειγμα εφαρμογής,  ορίσαμε την μοναδική κλάση ByteConverterDialog η οποία υλοποιεί το γραφικό περιβάλλον και την λογική δομή του προγράμματος: όταν ο χρήστης αλλάξει την τιμή στο πεδίο γραμμής επεξεργασίας του widget, η κλάση ByteConverterDialog καλεί την αντίστοιχη υποδοχή, η οποία προσαρμόζει την τιμή των άλλων δύο γραμμών επεξεργασίας. Βλέπε σχήμα 2.5

 

Μια τέτοια διασύνδεση του γραφικού περιβάλλοντος και της λογικής δομής της εφαρμογής δημιουργεί τον κίνδυνο ο σχεδιασμός του προγράμματος να προκαλεί σύγχυση και να είναι δύσκολος στη συντήρηση. Για παράδειγμα, αν η κρίσιμη λογική της εφαρμογής έχει ενσωματωθεί σε μεθόδους υπεύθυνες για τη δημιουργία των διατάξεων και των widgets, και θελήσουμε να αλλάξουμε την εμφάνιση της διεπαφής, τότε ο κώδικας υπεύθυνος για την λειτουργικότητα θα πρέπει να αλλάξει με ιδιαίτερη προσοχή.

 

Το πρόβλημα αυτό δεν μπορεί να αποφευχθεί εντελώς, αλλά μπορεί τουλάχιστον να ελαχιστοποιηθεί μέσω του διαχωρισμού του κώδικα διεπαφής χρήστη και του κώδικα επεξεργασίας δεδομένων όπως στο σχήμα 2.6. Η δυνατότητα χρήσης σημάτων και υποδοχέων απλοποιεί την αφαιρετικότητα εδώ, επειδή περιττές εξαρτήσεις του παραθύρου διαλόγου της κλάσης επεξεργασίας (και αντίστροφα) μπορούν να αποφευχθούν.

 

Στο σχέδιο αυτό, η κλάση ByteConverterDialog είναι υπεύθυνη μόνο για την γραφική διεπαφή GUI: Η μετατροπή των αριθμών διεκπεραιώνεται από μια επιπλεόν κλάση, την ByteConverter. Η κλάση αυτή διαθέτει τους υποδοχείς setDec(), setHex() και setBin(). Αν καλέσουμε την υποδοχή setDec() με χρήση συμβολοσειράς, η κλάση εκπέμπει τα σήματα hexChanged() και binChanged() με τις αντίστοιχες τιμές σε δεκαεξαδική ή δυαδική μορφή, και ομοίως για τους άλλους δύο υποδοχείς.

 

Μπορούμε να διασυνδέσουμε τα σήματα και τους υποδοχείς του widget γραμμής επεξεργασίας από το ByteConverterDialog με τα σήματα και υποδοχείς της κλάσης ByteConverter, για παράδειγμα, το σήμα της hexChanged() του αντικειμένου decEdit σε ένα παράθυρο διαλόγου στον υποδοχέα setDec() στο συσχετιζόμενο ByteConverter. Αν ο χρήστης εισάγει μια νέα δεκαδική τιμή, το widget γραμμής επεξεργασίας εκπέμπει σήμα textChanged() και κάνει εφαρμογή του setDec(). Η υποδοχή αυτή εκπέμπει τα σήματα hexChanged() και binChanged(). Δεδομένου οτι τα έχουμε συνδέσει στον υποδοχέα setText() του αντικειμένου hexEdit ή binEdit, το πρόγραμμα ενημερώνει τις δεκαεξαδικές και δυαδικές τιμές της γραφικής διεπαφής του χρήστη.

 

Η κλάση ByteConverter δεν “γνωρίζει” κάτι όσον αναφορά στα γραφικά στοιχεία (GUI components). Έχει μια σαφώς καθορισμένη διεπαφή και μπορεί ακόμη να χρησιμοποιηθεί αν η όψη της εφαρμογής αλλάξει.

 

Ο διαχωρισμός της επεξεργασίας δεδομένων από την γραφική διεπαφή χρήστη (GUI) με αυτόν τον τρόπο πρέπει να λαμβάνεται πάντα υπόψιν, αν η λογική επεξεργασίας μπορεί να διαχωριστεί φυσικά από την διεπαφή χρήστη. Από την άλλη πλευρά, αν επιθυμούμε να συγχρονίσουμε ξεχωριστά στοιχεία GUI μεταξύ τους, πρέπει να αποφασίσουμε κατά ενός τέτοιου διαχωρισμού. Στην περίπτωση αυτή, δεν θα επιτευχθεί καμία τέτοια ανεξαρτησία, αλλά μόνο η μεταβίβαση της ευθύνης σε μια νέα κλάση.

 

Το πρόγραμμα του παραδείγματός μας αποτελεί μια ακραία περίπτωση της άποψης αυτής: ΤΗν διαδικασία επεξεργασίας δεδομένων που περιλαμβάνει την μετατροπή αριθμών από το ένα αιρθιτικό (?)σύστημα στο άλλο—μια λειτουργία που δεν αντιστοιχεί σε κάποια διεπαφή χρήστη. Έαν επιθυμούσαμε να συνθέσουμε ένα πρόγραμμα επεξεργασίας δεκαεξαδικών αριθμών, από την άλλη πλευρά των οποίων τα εξαγώμενα δεδομένα μπορούν να εναλλαχθούν μεταξύ δεκαδικής, δεκαεξαδικής και δυαδικής μορφής, δεν θα ήταν δικαιολογημένο να διαχωρίσουμε την γραφική διεπαφή χρήστη απο την υπολογιστική λογική για τον συγχρονισμό των αντίστοιχων γραμμών επεξεργασίας.

 

Figure 2.6: Διαχωρισμός των στοιχείων GUI από την λογική επεξεργασίας

 

Είναι ήδη φανερό ότι δεν υπάρχει εύκολη απάντηση στο τι πρέπει να διαχωριστεί και στο τι πρέπει να μείνει μαζί. Ως ένα βαθμό η απάντηση εξαρτάται από το στυλ προγραμματισμού και την οργάνωση του έργου. Η Qt παρέχει την αναγκαία ελευθερία και για τις δύο μεθόδους.

 

2.2.2 Δηλώνοντας και Αποστέλοντας τα Σήματα

 

Η νέα κλάση ByteConverter διαθέτει σήματα και υποδοχείς, τα οποία ως εκ τούτου πρέπει να κληρονομεί από το QObject. Επειδή δεν προβάλλει τίποτα στην οθόνη, δεν αποτελεί ένα widget και δεν απαιτεί καμία άλλη λειτουργικότητα που κάνει διαθέσιμη την Qt σε άλλες υποκλάσεις της QObject, μπορεί να κληρονομήσει κατευθείαν απο το QObject:

 

The new ByteConverter class has signals and slots, and must therefore ultimately inherit from QObject. Since it displays nothing on the screen, is not a widget, and requires no other functionality that Qt makes available in other subclasses of QObject, it can inherit directly from QObject:

 

// byteConverter2/ByteConverter.h

 

#ifndef BYTECONVERTER_H

#define BYTECONVERTER_H

 

#include <QObject>

 

class ByteConverter : public QObject

{

Q_OBJECT

 

public:

ByteConverter(QObject* = 0);

 

public slots:

void setDec(const QString&);

void setHex(const QString&);

void setBin(const QString&);

 

signals:

void decChanged(const QString&);

void hexChanged(const QString&);

void binChanged(const QString&);

};

 

#endif

 

Και πάλι είναι σημαντικό να μην ξεχνάμε τον συμβολισμό Q_OBJECT, αλλιώς η Qt δεν θα γνωρίζει αναφορικά με τα σήματα και τους υποδοχείς που δηλώθηκαν.

 

Ο κατασκευαστής δέχεται ένα δείκτη σαν όρισμα σε ένα αντικείμενο QObject. Αυτός μετατρέπεται στον “πατέρα” το νέου αντικειμένου στην ιεραρχεία αντικειμένων. Ως προκαθορισμένη τιμή (ακριβώς όπως στην υπογραφή του κατασκευαστή QObject), το 0 γίνεται χρήση του μηδενικού δείκτη—το αντίστοιχο αντικείμενο ByteConverter δεν έχει γονέα.

 

Η κλάση διαθέτει τρείς υποδοχείς: setDec(), setHex() και setBin(). Αυτή τη φορά θέλουμε να αποκτήσουμε πρόσβαση σε αυτά τα εξωτερικά της κλάσης, από την ByteConverterDialog, και το επιτρέπουμε αυτό με την λέξη κλειδί public.

 

Τα σήματα δηλώνονται με τις σημάνσεις σημάτων. Δεν έχει καθοριστεί τρόπος ελέγχου πρόσβασης—είναι πάντα δημόσια (public). Κάθε ιδιωτικό (private) ή προστατευμένο (protected) σήμα θα ήταν μη ορατό εκτός της κλάσης, και εώς εκ τούτου θα ήταν άσχηστο για εποικοινωνία μεταξύ διαφορετικών κλάσεων. Μέσα σε μία μοναδική κλάση (όπως στις προηγούμενες μας υλοποιήσεις) μπορούν να χρησιμποιηθούν απλές κλήσεις. Εκτός από τις σημάνσεις των σημάτων, οι δηλώσεις τους μοιάζουν ακριβώς σαν τις δηλώσεις συναρτήσεων.

 

Σε αντίθεση με τις συναρτήσεις και τις υποδοχές των μελών, η υλοποίηση των κλάσεων παραλείπει τον καθορισμό των σημάτων, δεδομένου ότι το μόνο που κάνουν είναι να καλούν τις υποδοχές που συνδέονται7.

 

Ο κατασκευαστής ByteConverter υλοποιείται άμεσα:

 

The ByteConverter constructor is quickly implemented:

 

// byteConverter2/ByteConverter.cpp

 

#include “ByteConverter.h”

 

ByteConverter::ByteConverter(QObject* parent) :

QObject(parent)

{

}

 

Περνάμε μόνο το γονικό όρισμα στον κατασκευαστή QObject (δηλάδη τον κατασκευαστή της βασικής κλάσης).

 

7 Φυσικά τα σήματα υλοποιούνται αυτόματα απο τον moc. Ο παραγόμενος κώδικας για κλήση ενός σήματος στην αντίστοιχη υποδοχή, αλλά δεν είναι δυνατή η σύνταξη ξεχωριστής υλοποίησης για κάθε σήμα.

 

Η υλοποίηση των υποδοχέων αντιστοιχεί κυρίως στο Κεφάλαιο 2.1.4 στην σελίδα 70:

 

// byteConverter2/ByteConverter.cpp (continued)

 

void ByteConverter::setDec(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok);

if (ok) {

emit hexChanged(QString::number(num, 16));

emit binChanged(QString::number(num, 2));

} else {

emit hexChanged(“”);

emit binChanged(“”);

}

}

 

void ByteConverter::setHex(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok, 16);

if (ok) {

emit decChanged(QString::number(num));

emit binChanged(QString::number(num, 2));

} else {

emit decChanged(“”);

emit binChanged(“”);

}

}

 

void ByteConverter::setBin(const QString& newValue)

{

bool ok;

int num = newValue.toInt(&ok, 2);

if (ok) {

emit decChanged(QString::number(num));

emit hexChanged(QString::number(num, 16));

} else {

emit decChanged(“”);

emit hexChanged(“”);

}

}

 

Μετατρέψαμε την αριθμητική τιμή κάθε ενός από τα τρία αριθμητικά συστήματα με συναρτήσεις της QString  toInt() και number(). Ωστόσο οι υποδοχές δεν αλλάζουν την τιμή των widget γραμμών επεξεργασίας, απλά στέλνουν τα αντίστοιχα σήματα. Για να γίνει αυτό, χρειάζεται να καλέσουμε το σήμα σαν συνάρτηση.

 

Προκειμένου να καταστεί σαφές ότι δεν προκείται για μια συνηθισμένη κλήση συνάρτησης, βάζουμε ένα πρόθεμα και το ονομάζουμε ένδειξη εκπομπής (emit designator). Αυτό δεν είναι απαραίτητο, αλλά αποτελεί βοήθημα για τον προγραματιστή, ο οποίος μπορεί να διακρίνει αμέσως αν το σήμα έχει σταλεί. Αποτελεί μια καλή προγραμματιστική πρακτική να σηματοδοτούμε εκπομπές σημάτων με την ένδειξη εκπομπής emit.

 

Το μόνο που απαιτείται τώρα είναι η προσθήκη των νέων αρχείων κεφαλής και πηγαίου κειμένου στο .pro αρχείο έτσι ώστε το qmake να παράγει τις απαραίτητες moc κλήσεις:

 

#byteConverter2/byteConverter2.pro

 

TEMPLATE = app

 

SOURCES = main.cpp \

ByteConverterDialog.cpp \

ByteConverter.cpp

HEADERS = ByteConverterDialog.h \

ByteConverter.h

 

Αν παραλείψουμε να επεξεργαστούμε ένα αρχείο που δηλώνει μια κλάση με σήματα χρησιμοποιώντας την moc, ο διασυνδετής (inker) θα βγάλει μήνυμα για απροσδιόριστα σύμβολα. Το GCC εκδίδει το ακόλουθο μύνημα λάθους, για παράδειγμα:

 

If you forget to process a file that declares a class with signals using moc, the linker will complain of undefined symbols; GCC issues the following error message, for example

 

ld: Undefined symbols:

ByteConverter::binChanged(QString const&)

ByteConverter::decChanged(QString const&)

ByteConverter::hexChanged(QString const&)

 

Αν η κλάση δηλώνει μόνο υποδοχείς και δεν τις επεξεργαστούμε με χρήση της moc, θα λάβουμε μόνο ένα μήνυμα λάθους κατά την εκτέλεση, ότι η σύνδεση σήμα/υποδεχέα δεν δύναται να δημιουργηθεί, εφόσον η υποδοχή δεν είναι γνωστή.

 

2.2.3 Κάνοντας χρήση δικών μας σημάτων

 

Με την κλάση ByteConverter, η κλάση ByteConverterDialog έχει απλουστευτεί— δεν απαιτούνται μεταβλητές κλάσεων ή υποδοχείς: ο κατασκευαστής είναι επαρκής.

 

// byteConverter2/ByteConverterDialog.h

#ifndef BYTECONVERTERDIALOG_H

#define BYTECONVERTERDIALOG_H

 

#include <<QDialog>

 

class ByteConverterDialog : public QDialog

{

Q_OBJECT

 

public:

ByteConverterDialog();

};

 

#endif

 

Έχουμε δημιουργήσει τα widgets όπως στο προηγούμενο παράδειγμα και τα περνάμε με τον ίδιο τρόπο στην επιμέλεια της διάταξης, χωρίς να υπάρχουν διαφορές στις προσαρμογές, συμπεριλαμβανομένου των επικυρωτών (validators). Εμείς απλώς απαιτούμε διαφορετικές συνδέσεις στα σήματα / υποδοχείς:

 

// byteConverter2/ByteConverterDialog.cpp

 

ByteConverterDialog::ByteConverterDialog()

{

// Signal/slot connections

connect(exitButton, SIGNAL(clicked()),

this, SLOT(accept()));

ByteConverter* bc=new ByteConverter(this);

connect(decEdit, SIGNAL(textChanged(const QString&)),

bc, SLOT(setDec(const QString&)));

connect(hexEdit, SIGNAL(textChanged(const QString&)),

bc, SLOT(setHex(const QString&)));

connect(binEdit, SIGNAL(textChanged(const QString&)),

bc, SLOT(setBin(const QString&)));

connect(bc, SIGNAL(decChanged(const QString&)),

decEdit, SLOT(setText(const QString&)));

connect(bc, SIGNAL(hexChanged(const QString&)),

hexEdit, SLOT(setText(const QString&)));

connect(bc, SIGNAL(binChanged(const QString&)),

binEdit, SLOT(setText(const QString&)));

}

 

Συνδέουμε το σήμα clicked() του κουμπιού εξόδου στην υποδοχή accept() του παραθύρου διαλόγου, το οποίο το κλείνει. Οι υπολοιπόμενα σήματα / υποδοχείς αντιστοιχούν σε αυτά που φαίνονται στο Σχήμα 2.6 της σελίδας 76.

 

Στον κατασκευαστή ByteConverter εισάγουμε έναν δείκτη σαν όρισμα έτσι ώστε το νέο αντικείμενο να γίνει το θυγατρικό του ByteConverterDialog. Αυτό προκαλεί την αυτόματη διαχείριση μνήμης να σβήσει το αντικείμενο ByteConverter μόλις διαγραφεί η γραφική διεπαφή χρήστη (GUI). Επιπροσθέτως, η σχέση γονένα/παιδιού εξασφαλίζει ότι το αντικείμενο ByteConverter είναι διαθέσιμο για ολόκληρη την διάρκεια ζωής του αντικειμένου ByteConverterDialog.

 

Το παράδειγμα δείχνει ότι η σύνδεση υποδοχέων με δικά μας σήματα ή σήματα των κλάσεων Qt, δεν κάνει καμία διαφορά αναφορικά με την σύνταξη.

H.264 – Κεφάλαιο 4 – Ποιοτική και Ποσοτική Αξιολόγηση των προτύπων του Web Video

•December 8, 2015 • Leave a Comment

4.1 – Γενική Επισκόπηση των τεχνολoγιών για αναπαραγωγή video στο web

 

Όπως εκτενώς αναλύσαμε στο κεφάλαιο 3 στο web εμφανήσθηκαν στο παρελθόν και χρησιμοποιούνται αυτή την στιγμή αρκετές τεχνολογίες για αναπαραγωγή video. Ιστορικά να αναφέρουμε ορισμένες απο αυτές όπως τον RealPlayer, Windows Media Player και Quicktime. Δεν θα εξετάσουμε αυτούς καθώς τεχνολογικά έχουν ξεπερθεί και συναντώνται σπάνια πλεόν στο web. Κυριαρχες τεχνολογίες σήμερα αποτελούν το Flash Player και τα 3 πρότυπα που χρησιμοποιούνται στην HMTL5. To Flash αποτελεί τον βασικό και ουσιαστικό λογισμικού που χρησιμοποιεί η πλειοψηφία των δημοφιλών υπηρεσίων παροχής web video.

 

Τα τελευταία 2 χρόνια έχει προκύψει αρκετή φιλολογία γύρω απο τον πιθανό αντικαταστάτη του flash ενονόματι HTML5. Απαρτίζεται απο πολλά νέα χαρακτηριστικά που περιλαμβάνουν δυνατότητα διανυσματικών animation, διαδραστικών εφαρμοφών, καθώς, 3d δυνατοτήτων καθώς και δυνατότητα αναπαραγωγής video εξ ορισμού σαν ενσωματωμένη προδιαγραφή. Δεν είναι σε θέση ακόμη να αντικαστήσει τον flash player όσο αναφορά το video είναι δε πολλά υποσχόμενο. Με αρκετά νομικά και θεσμικά εμπόδια να πρέπει να ξεπερασθούν δυστηχώς περιλαμβάνει τρία κυριάρχα ανταγωνιστικά πρότυπα: H.264, Ogg Theora και WebM.

 

Θα εξετάσουμε λοιπόν συνοπτικά την απόδηση αναπαραγωγής ενός video ανάλυσης 720p και 1080p κωδικοποιημλενο κάθε φορά απο την συγκεκριμένη τεχνολογία html5, μέσω flash player, μέσω των προεγγεστημένων players Windows Media Player (Windows 7) & Quicktime (Mac OSΧ Lion)  καθώς και μέσω του player υπεροχής VLC.

 

4.2 – Υπολογιστικό σύστημα αναπαραγωγής και διεξαγωγής μετρήσεων

 

Macbook Pro 13” Mid 2010

CPU: 2,66 GHz Intel Core 2 Duo

RAM: 8 GB 1066 MHz DDR3

GPU: NVIDIA GeForce 320M 256 MB

HD: 320 GB SATA 5,400 rpm.

Monitor: 1920 x 1080 LED Samsung through HDMI

 

Σύνδεση ADSL2+: Συγχρόνισμένη στα 5Mbit Down / 0,9Mbit Up, Θόρυβος: 11dB Up/Down, Απόσβεση: 19,7dB Up / 36,2dB Down

 

OS1: Windows 7 SP1

OS2: Mac OSΧ Lion

 

4.3 – Χαρακτηριστικά της συγκριτικής μεθόδου που θα ακολουθηθεί

 

To video προς αναπαραγωγή αποτελεί κομμάτι λήψης απο μια Full HD Panasonic Handycam 1080p με συμπίεση H.264 MPEG-4 AVC part 10, ανάλυσης 1920 x 1080, frames 50 / sec, decoded format: Planar 4:2:0 YUV. To video θα υποστεί μια στοιχειώδη επεξεργασία με χρήση του Adobe Premiere CS6 και θα εξαχθεί σε Η.264 βελτιστοποιημένο για web. Τα ogg και WebM θα μετασχηματισθούν με το εργαλείο firefogg διατηρώντας την ίδια ανάλυση και framerate. Το εξαγώγιμα αρχεία που θα συναντώται σε κάθε περίπτωση θα είναι ίδιας ανάλυσης, framerate και διάρκειας μεταξύ τους ώστε να υπάρχει κοινός παρονομαστής σύγκρισης. Η αναπαραγωγή θα γίνεται με τις προκαθορισμένες ρυθμίσεις στον εκάστωτε player.

 

Οι browsers που θα δοκιμασθούν θα βρίσκονται στις τελευταίες εκδόσεις τους χωρίς χρήση addons ώστε να εξετασθούν αντικειμενικά οι απαιτήσεις τους για μνήμη και επεξεργαστική ισχύ. Πέρα απο τα ποσοτικά χαρακτηριστικά απόδοσης κατά την αναπαραγωγή των video θα εξεταστασθεί η ποιότητα αναπαραγωγής σε κάθε μια απο τις περιπτώσεις που θα εξετασθούν. Οι ρυθμίσεις της οθόνης και του λειτουργικού συστήματος θα μείνουν αμετάβλητες κατα την εξέταση του κάθε επιμέρους player. Το λειτουργικό θα εκτελεί μόνο τον browser ή video player και task manager κατα την αναπαραγωγή ώστε να μην καταναλώνεται επιπλέον μνήμη και κύκλοι επεξεργαστή που θα μπορούσαν να αλλοιώσουν την ακρίβεια των μετρήσεων μας.

 

Όσο αναφορά την απόδηση σε επίπεδο μεταφοράς και μετάδοσης θα γίνει χρήση μια οικιακής γραμμής Adsl συγχρονισμένη στα 5Mbit και θα εξετασθεί ο χρόνος buffering, η ταχύτητα μετάβασης σε ένα σημείο του video που δεν έχει φορτωθεί κτλπ. Φυσικά κατά την τοπική αναπαραγωγή δεν θα εξετασθούν τα παραπάνω. Τα video θα φορτωθούν μέσω ftp στην προσωπική μου ιστοσελίδα www.nickounis.gr/video η οποία είναι hosted εκτός ελλάδας σε shared server με Apache Linux κατασκευασμένο με χρήση του WordPress. Για χάριν απλότητας θα εξετασθούν τα 3 πρότυπα HTML5 video ανεβασμένο στον προσωπικό μου hosting και σε youtube, vimeo με χρήση flash και html5 video. Στο επίπεδο μεταφοράς δεν θα ήταν σκόπιμο να συγκρίνουμε μεταξύ του youtube και του προσωπικού που hosting διότι προφανώς μιλάμε για κάτι διαφορετικό.

 

Ο τελικός πίνακας των μετρήσεων θα στοχεύει στην άμεση σύγκριση των τεχνικών και προτύπων αναπαραγωγής εξετάζοντας τουλάχιστον απο τεχνολογική σκοπιά την υπεροχή ή οχι του H.264 στην αναπαραγωγή είτε με χρήση του flash player ή html5. Το flash video έχει την φήμη να απαιτεί περισσότερη επεξεργαστική ισχύ και μνήμη σε σχέση με την αναπαραγωγή με χρήση της html5 ειδικά για video υψηλής ευκρίνιας (HD).

 

4.4 –  Μέτρηση απόδοσης αναπαραγωγής

 

Η δοκιμή θα γίνει μέσω της ιστοσελίδας www.nickounis.gr/video και θα περιλαμβάνει το ίδιο video ηψηλής ευκρίνιας ενσωμετωμένο στην σελίδα μας με συνολικά 7 τρόπους: YouTube Flash Player, YouTube HTML5 Player, Vimeo Flash Player, Vimeo HMTL5 Player, Hosted Ogg Theora, Hosted WebM / VP8, Hosted H.264 με δοκιμή της απόδοσης τους στους 5 browsers: Firefox, Chrome, Opera, Safari, Internet Explorer με δοκιμή των τριών πρώτων και σε Mac και Windows. Η καταγραφή των μετρήσεων θα γίνει μέσω των taskmanager / activity monitor. Η αξιολόγηση της ποιότητας αναπαραγωγής γίνεται όσο δυνατόν πιο αντικειμενικά σε μια οθόνη 27” LED FullHD. Χαρακτηριστικά αναπαραγωγής που θα ληφούν υπόψιν είναι η μη απώλεια frames κατά την προβολή, η σταθερή και μη διακοπτώμενο αναπαραγωγή, η συνεκτικότητα της αποκωδικοποίησης (να μην εμφανίζονται σφάλματα όπως μεγαλες περιοχές pixels),πιστότητα στην αναπαραγωγή καθώς και η συνολική συμπεριφορά του video σε πλήρη οθόνη. Το αναπαραγόμενο αρχείο σε κάθε μια απο τις περιπτώσεις διαφέρει δραστικά στο μέγεθος οπότε ενδέχεται να υπάρχουν σημαντικές διαφορές στην ταχύτητα εκφόρτωσης του video.

 

4.5 – Συνολικό συμπέρασμα ανάλυσης

 

Όπως θα έχουμε διαπιστώσει στην καθημερινή δραστηριότητα στο web το κομμάτι του video αποτελεί ένα αναπόσπαστο κομμάτι του περιεχομένου σε κάθε μορφής ιστοσελίδας. Ιστορικά μπορούμε να ανατρέξουμε πίσω στα τέλη 90’ όπου μέσω των media player τρίτων κατασκευαστών ήταν δυνατή η αναπαραγωγή video με φυσικά βασικό περιορισμό το έυρος ζώνης της σύνδεσης στο internet. Πλέον σήμερα που το ευρυζωνικό internet είναι κάτι κοινό σε οικιακό επίπεδο το online video αποτελεί κάτι πρακτικά προσβάσιμο στον καθένα. Ουσιαστικό ρόλο έπαιξε το πρότυπο Flash αρχικά της Macromedia και έπειτα της Adobe και κατάφερε να γεφυρώσει το κενό διασυμβατότητας και τεχνικών περιορισμών των παλαιότερων τεχνολογιών προβολής video στο web. Ακόμη και σήμερα κατέχει το μεγαλύτερο μερίδιο στην χρήση, όσο αναφορά το video και όχι μόνο, με πλήθος δυνατοτήτων που ακόμη το <video> tag δεν έχει ενσωματώσει πλήρως.

 

Φυσικά το flash παρόλα τα πλεονεκτήματα που προσφέρει δεν παύει πολλές φορές να έχει την τάση να καταλώνει αρκετούς πόρους, να μην υποστηρίζεται σε αρκετές φορητές συσκευές και γενικά να ακολουθεί μια κλειστή φιλοσοφία που γενικώς δυσαρεστεί την κοινότητα του ανοιχτού λογισμικού που οδηγεί τις εξελίξεις στο web κατα μεγάλο βαθμό. Λόγω των παραπάνω αναπτύχθηκε το <video> tag καλύπτωντας το κενό αυτό στην html. Αισιοδοξεί να υποκαταστήσει την ανάγκη της καθολικής εξάρτησης απο τo flash, προσφέροντας έναν ανοιχτό και καθαρό τρόπο να υλοποιήσει κάποιος κάτι που μέχρι πρότεινος γινόταν μόνο το κλειστό πρότυπο της Adobe.

 

Οι εξελίξεις σήμερα στο web οδηγούνται κατά βάση απο τις εταιρίες που κατασκευάζουν τους 5 πιο δημοφιλούς browsers της αγοράς: Firefox / Mozilla, Chrome / Google, Opera /Opera Software, Internet Explorer / Microsoft, Safari / Apple. Οι παραπάνω λοιπόν εταιρίες χωρίς αμφιβολία καθορίζουν το τοπίο δράσης. Όπως είδαμε και στο κεφάλαιο 3, οι πρώτες τρείς εταιρίες γενικά ακολουθούν πιστά το πλαίσιο ορισμού του web της W3C, ενώ οι 2 τελευταίες έχουν το κακό συνήθειο να δρούν οδηγούμενες απο την διασφάληση των πατεντών τους και ευλαυικής προσήλωσης σε αυτές, κατηγορώντας όσους τυχαίνει να τις παραβιάζουν. Συνήθως υστερούν σε καινοτομία και βασίζονται στο πλεονέκτημα του ότι είναι προεγγεστημένα εξ ορισμού στο λειτουργικό σύστημα.

 

Ιστορικά όμως ευτηχώς έχει φανεί, με κλασσικό παράδειγμα τον Internet Explorer, που ακόμη και η προνομιακή του θέση που κατείχε δεν ήταν αρκετή ώστε να κρατηθεί ψηλά το μερίδιο του, εφόσον δεν ακολουθούσε πιστά τις ανοιχτές προδιαγραφές της W3C. Ετσι λοιπόν ακόμη και με το web video, βλέπουμε ακριβώς το ίδιο επαναλαμβανόμενο μοτίβο. Από την μία μεριά οι εταιρίες που υποστηρίζουν το κλειστό μοντέλο (Microsoft, Apple) να ενσωματώνουν το <video> tag στις τελευταίες εκδόσεις αλλά μόνο το πρότυπο H.264 το οποίο κατέχουν πνευματικά δικαιώματα. Στην αντίπερα όχθη οι εταιρίες που υποστηρίζουν το ανοιχτό μοντέλο (Google, Mozilla) δεν ενσωματώνουν την υποστήριξη για το H.264 για να μην έχουν νομικούς κινδύνους απο τους κάτοχους των πατεντών του προτύπου αυτού. Επιλέγουν προς το παρόν να επιμένουν στην μη υποστηριξη του, αλλά ενσωματώνουν υποστήριξη μόνο για το WebM / VP8 και ogv theora. Έτσι λοιπόν βλέπουμε ότι το τοπίο ακόμη με το περίφημο <video> tag δεν έχει κατασταλάξει ακόμη όπου επίσημα να το αγκαλιάσουν πλήρως οι μεγάλες υπηρεσίες παροχής video. Το εμπόδιο είναι κάθε άλλο παρά τεχνολογικό, αλλά μάλλον θεσμικό και νομικό καθώς η αιώνια διαμάχη μεταξύ του ανοιχτού μοντέλου και αυτών που βασίζονται στην κατοχύρωση μια τεχνολογίας μέσω πατεντών δεν φαίνεται να υποχωρεί σύντομα.

 

Πρακτικά όμως θα διαπιστώσουμε απο τον πίνακα των μετρήσεων το H.264 υπερέχει τεχνολογικά και δεν παύουν πολλά εργαλεία και βιβλιοθήκες του να είναι ανοιχτές. Το νομικό πλαίσιο γύρω απο τις πατέντες το εμποδίζει ακόμη να ενσωματωθεί πλήρως στους δύο πιο βασικούς browsers στο web: Firefox & Chrome. Η Google, μια εταιρία με μεγάλη εμπειρία και ενόραση στον κόσμο του web, όπως έχει προαναφερθεί αγόρασε πρόσφατα την On2 με αποτέλεσμα να ανοίξει το πρότυπο WebM / VP8. Η κίνηση της αυτή δηλώνει μια προσήλωση στην ανοιχτή φιλοσοφία, όχι τυχαία δε, γιατί γνωρίζει καλά πως η δεσπόζουσα θέση της είναι απο μόνη της ικανή να το καθιερώσει σαν πρότυπο στο web. Το ogv πιθανόν απλά να ξεχαστεί σε βάθος χρόνου καθώς τεχνικά υστερεί σε σχέση με τα υπόλοιπα δύο κυρίαρχα πρότυπα. Η Adobe απο την άλλη μέσω του Flash Plugin υποστηρίζει πλήρως την αναπαραγωγή του H.264 και όπως είχε δηλώσει σχεδιάζει την μελλοντική υποστήριξη και του WebM. Μπορούμε να πούμε πλέον με ασφάλεια ότι η συνεχής εξέλιξη της html με την 5η έκδοση της, έχει ήδη και θα συνεχίσει να έχει τεράστια επίπτωση στον τρόπο που βιώνουμε το web. Το online video για πολλά χρόνια ακόμη θα συνεχίσει να αναπαράγεται με το flash plugin λειτουργώντας ευλπιστώ ανταγωγνιστικά με το <video> tag. Το κομμάτι της html5 που αφορά το video έχει ανάγκη για αρκετές βελτιώσεις ακόμη και ίσως να αργήσει να τελειοποηθεί και να παρουσιασθεί σαν τελικό πρότυπο.

 

Το κομμάτι των πατεντών στον κλάδο της πληροφορικής είναι ένα σημαντικό εργαλείο διασφάλισης των δικαιωμάτων σε μια τεχνολογία που χρειάστηκε τεράστιες επενδύσεις στην ανάπτυξη της. Είναι σημαντικό όμως ότι μέσα στην αγορά της πληροφορικής να λειτουργούν οι κανόνες του υγειούς ανταγωνισμού. Σαν επιστήμη οφείλει πολλά στην ανοιχτή φιλοσοφία και το λογισμικό που εμπείπτει στις ανοιχτές άδειες και θεσμικά πλέον πρέπει να διασφαλίζεται έναντι των νομικών κινδύνων που ορισμένες φορές προκαλεί η σύγχρονη καπιταλιστική αγορά. Ορισμένες τεχνολογίες οφείλουν να είναι αυστηρώς προτυτοποιημένες και ελεύθερες για μη εμπορική χρήση ώστε να διασφαλίζεται ο υγειής ανταγωγνισμός. Το παράδειγμα των web standars και όλως των τεχνολογίων το απαρτίζουν οφείλουν να είναι όσο το δυνατό ανοιχτές και σαφώς τεχνικά προσδιορισμένες ώστε να διασφαλίζεται η πλήρης διαλειτουργικότητα αυτού του μέσου που ονομάζεται web.

 

Κεφάλαιο 3 – Χρήση του VLC στο H.264 (Άκυρη Υλοποίηση)

•December 8, 2015 • Leave a Comment

3.1.1 – Εισαγωγή στο FFmpeg

 

Όπως προαναφέρθηκε στο σκέλος των υλοποιήσεων του συνόλου πρότυπων H.264, η εταιρία ή ομάδα υλοποίησης μιας τεχνολογίας χρησιμοποιεί κάθε φορά την δικιά της τεχνική όταν πρόκειται να σχεδιάσει μια τεχνολογία κινούμενης εικόνας. Το H.264 σε πληθώρα περιπτώσεων, υλοποιείται με την χρήση των εργαλείων που έχει υλοποιήσει και τεκμηριώσει η ομάδα λογισμικού FFMPEG. Πρόκειται περί ενός λογισμικού ανοιχτής και ελεύθερης φιλοσοφίας όπου αναπτύσει βιβλιοθήκες και προγράμματα για την προβολή και επεξεργασία πολυμεσικών δεδομένων. Οι δημοφιλέστερες υλοποιήσεις του FFMPEG είναι το libavcodec (συναντάται στο λειτουργικό linux σαν βιβλιοθήκη), ένας codec ήχου και εικόνας, ο οποίος χρησιμοποιείται σε πολλές άλλες υλοποιήσεις όπως το libavformat, (mux and demux library) καθώς και στο εργαλείο γραμμής εντολών ffmpeg που θα χρησιμοποιηθεί κατα βάση για την διεξαγωγή του πειραματικού μέρους της εργασίας αυτής. To FFmpeg έχει δημοσιοποιηθεί με την χρήση της άδειας πνευματικής ιδιοκτησίας GNU (General Public Licence 2.1+)

 

3.1.2 –  Ιστορική ανασκόπηση του FFmpeg

 

Η προσπάθεια ανάπτυξης του λογισμικού είχε αρχίσει από τον Fabrice Bellard και από το 2004 συντηρείται από τον Michael Niedermayer. Επιπλέον αρκετά άτομα που συμμετέχουν στο FFmpeg λαμβάνουν ενεργό δράση και στην ανάπτυξη του MPlayer. Το όνομα αποτελείται από το MPEG πρότυπο με την προσθήκη του FF (Fast Forward). Το λογότυπο αποτελείται από ένα σχέδιο ζικ-ζακ που συμβολίζει πως ο κωδικοποιητής video MPEG διαχειρίζεται την κωδικοποίηση εντροπίας Το FFmpeg αναπτύσσεται σε περιβάλλον GNU/Linux, αλλά παρόλα αυτά μπορεί να εκτελέστει ο πηγαίος κώδικας στα πιο πολλά γνωστά λειτουργικά συστήματα (Mac OS X, MS Windows, Amiga OS). Επιπλέον σχεδόν όλες οι αρχιτεκτονικές πλατφόρμες υπολογιστών υποστηρίζονται από το λογισμικό αυτό (x86, x86-64, PowerPC, ARM, DEC Alpha, SPARC & MIPS) . To FFmpeg βρίσκεται στην 0.5 έκδοση για αρκετό καιρό χωρίς επιπλέον νέες εκδόσεις.  Οι προγραμματιστές του προτείνουν την χρήση της τελευταία σταθερής έκδοσης από τους αποθήκες λογισμικού GIT.

 

Υπάρχουν δύο πρότυπα συμπίεσης (codecs) και ένα πρότυπο αποθήκευσης μετα-πληροφορίας (video container) τα οποία έχουν αναπτυχθεί απο την ομάδα ανάπτυξης FFMEG. Τα δύο αυτά πρότυπα (codecs) είναι το μη-απωλεστικό “FFV1” και το μη-απωλεστικό “Snow codec”, η ανάπτυξη των οποίων είχε ανακοπεί, καθώς η μορφή των δεδομένων ροής (bitstream format) δεν είχε τελειοποιηθεί ακόμη, καθιστώντας το ακόμη πειραματικό (Φεβρουάριος 2011). Επιπλέον, το “NUT” που αποτελεί ένα πολυμεσικό πρότυπα αποθήκευσης μετα-πληροφορίας (multimedia container) χωρίς να έχει τελειοποιηθεί ακόμη. Στις 17 Ιούνη 2010, η έκδοση 0.6 του FFMPEG υποστηρίζει επιπλέον το WebM και VP8. Στις 23 Ιούνη 2010 ο Jason Garrett-Glaser, Ronald Bultje, και David Conrad της ομάδας ανάπτυξης του FFmpeg ανακοίνωσε τον αποκωδικοποιητή ffvp8. Μέσω δοκιμών διαπιστώθηκε οτι ο ffvp8 ειναι ταχύτερος απο τον αποκωδικοποιητή libvpx της Google. Στις 12 Μαρτίου του 2011 η ομάδα του FFmpeg αποφάσισε να δημιουργήσει μια διακλάδωση (fork) του εν ονόματι Libav.  Από τότε οι διαχειριστές των διανομών Linux, Ubuntu & Debian άλλαξαν τα πακέτα λογισμικού τους σε αυτά της διακλάδωσης που προαναφέρθηκε

 

Εικόνα 1 – Γραφική διεπαφή του ffmpeg σε λειτουργικό MacOSX

 

3.1.3 – Συστατικά Μέρη του FFMPEG

 

Το λογισμικό  αποτελείται από τα παρακάτω μέρη:

 

  • ffmpeg αποτελεί ένα εργαλείο γραμμής εντολών για την μετατροπή eνος προτύπου video σε ένα άλλο. Μπορεί ακόμη να κωδικοποιήσει video σε πραγματικό χρόνο απο κάρτα τηλεόρασης.
  • ffserver αποτελεί έναν HTTP και RTSP διακομιστή πολυμεσικών ροών (mutlimedia streaming server) για ζωντανές μεταδόσεις. Δίνει επίσης την δυνατότητα κύλισης χρόνου της μετάδοσης ( time shift)
  • ffmplay είναι ένας πολύς απλό λογισμικό αναπαραγωγής video βασισμένο στις βιβλιοθήκες SDL και FFmpeg.
  • ffprobe είναι ένα εργάλειο γραμμής εντολών για προβολή πολυμεσικών πληροφοριών (media information)
  • Libav
    • avconv
    • avserver
    • avplay
    • avprobe

 

 

  • libavcodec αποτελεί μια βιβλιοθήκη που εμπεριέχει όλους τους απο/κωδικοποιητήτες ήχου και εικόνας του FFmpeg. Αναπτύχθηκαν απο το μηδέν για να διασφαλισθεί η μέγιστη αποδοση και βέλτιστη επαναχρησιμοποίηση.
  • libavformat αποτελεί μια βιβλιοθήκη που εμπεριέχει πολυπλέκτες (de/muxers) για αποθήκευση μετα-πληροφορίας (metadata)
  • libavutil αποελεί μια βοηθητική βιβλιοθήκη που εμπεριέχει ρουτίνες όμοιες με συστατικά μέρη του FFMPEG. Η βιβλιοθήκη αυτή αποτελείται απο adler32, crc, md5, sha1, lzo αποσυμπιεστή, Base64 απο/κωδικοποιητή καθώς και τις des, rc4, aes  τεχνικές απο/κρυπτογραφησης.
  • libpostproc αποτελεί μια βιβλιοθήκη που εμπεριέχει ρουτίνες μετα-επεξεργασίας video (post processing)
  • libpostroc αποτελεί μια βιβλιοθήκη που εμπεριέχει ρουτίνες κλιμάκωσης εικόνας και μετατροπής χρωματικής παλέτας ή φόρμας εικονοστοιχείων (colorspace/pixelformat)
  • libavfilter αποτελεί ένα υποκατάστατο του vhook το οποίο επιτρέπει στο video ή ήχο να επεξεργαστεί ή να εξετασθεί σε σύγκριση μεταξύ κωδικοποιητή και αποκωδικοποιητή

 

 

3.1.4 – Πρότυπα  κωδικοποίησης, φόρμες δεδομένων και υποστηριζόμενα πρωτόκολλα

 

Πρότυπα τα οποία προέρχονται άμεσα απο την ομάδα υλοποίησης FFmpeg: Snow, FF1

 

Η ομάδα ανάπτυξης του FFmpeg έχει υλοποιήσει μεταξύ άλλων:

 

  • Πρότυπα video ομάδας ITU-T : H.261 H.262/MPEG-2 Part 2, H.263, H.264/MPEG-4 AVC, G.711 µ-law, G.711 A-law, G.721 (G.726 32k), G.722, G.722.2 (AMR-WB), G.723 (G.726 24k and 40k) και G.726
  • Πρότυπα video ομάδας ISO/IEC MPEG  : MPEG-1 Part 2, H.262/MPEG-2 Part 2, MPEG-4 Part 2 και H.264/MPEG-4 AVC
  • Πρότυπα ήχου ομάδας ISO/IEC MPEG : MP1, MP2, MP3, AAC, HE-AAC και MPEG-4 ALS
  • Πρότυπα εικόνας ISO/IEC/ITU-T JPEG : JPEG και JPEG-LS
  • Πρότυπα video SMPTE : VC-1 ( WMV3), VC-3 (aka AVID DNxHD) και εικόνα DPX
  • MLP (aka TrueHD) & AC-3, AMR-NB, AMR-WB (aka G.722.2), Microsoft RLE, Microsoft Video 1, Cinepak, Indeo 2, 3 & 5, Motion JPEG, Microsoft MPEG-4 v1, v2 & v3, WMV1, WMV2 & WMV3 (aka VC-1), WMA1, WMA2 & WMA Pro, RealVideo 1, 2, 3 & 4, RealAudio 3, 6, 7, 8, 9 & 10, Xiph.Org: Theora, Speex (via libspeex), Vorbis & FLAC, Sony: ATRAC1 and ATRAC3, NTT: TwinVQ, On2: Duck TrueMotion 1, Duck TrueMotion 2, VP3, VP5, VP6 and VP8, RAD Game Tools: Smacker video & Bink video, Truespeech, RenderWare: TXD

 

3.1.5 – Φόρμες Aρχειων που διαχειρίζεται το FFmpeg (File Formats)

 

ASF, AVI, BFI, CAF, FLV, GXF, IFF, RL2, 3GP, MP4, Matroska (συμπεριλαμβανομένου WebM), Maxis XA, MPEG ροές προγράμματος (program stream), MPEG ροές δικτύων (transport stream) (συμπεριλαμβανομένου AVCHD), MXF, Material eXchange Format, SMPTE 377M, MSN Webcam stream, Ogg, OMA, TXD, WTV

 

3.1.6 – Προτώκολλα Επικοινωνίας

 

  • Πρότυπα IETF: TCP, UDP, Gopher, HTTP, RTP, RTSP και SDP
  • Apple: HTTP Live Streaming
  • RealMedia: RealMedia RTSP/RDT
  • Adobe: RTMP, RTMPT (με χρήση librtmp), RTMPE (με χρήση librtmp), RTMPTE (με χρήση librtmp) και RTMPS (με χρήση librtmp)
  • Microsoft: MMS over TCP and MMS over HTTP

 

3.2.1 – Video Lan Player (VLC)

 

Ο VLC είναι ελεύθερο λογισμικό αναπαραγωγής πολυμέσων ανοιχτού κώδικα και multimedia framework γραμμένο από το εγχείρημα VideoLAN (VideoLAN project). Ο VLC είναι ένας φορητός αναπαραγωγός πολυμέσων, κωδικοποιητής, και streamer υποστηρίζοντας πολλά codec ήχου και βίντεο καθώς και DVDs, VCDs, και διάφορα πρωτόκολλα streaming. Είναι ικανό να κάνει stream πάνω από δίκτυα και να επανακωδικοποιεί αρχεία πολυμέσων και να τα αποθηκεύει σε διάφορες μορφές. Τα αρχικά VLC σήμαιναν VideoLAN Client, αλλά επειδή ο VLC δεν είναι πια ένας απλός πελάτης, το αρκτικόλεξο δεν ισχύει πλέον. Είναι ένας αναπαραγωγός πολυμέσων πολλαπλής πλατφόρμας, με εκδόσεις για Microsoft Windows,Mac OS X,GNU, Linux,BeOS,MorphOS,BSD,Solaris,iOS και eComStation.

 

Η προεπιλεγμένη διανομή του VLC περιλαμβάνει ένα μεγάλο αριθμό από ελεύθερες βιβλιοθήκες κωδικοποίησης και αποκωδικοποίησης, αποφεύγοντας έτσι την ανάγκη για εύρεση κατάλληλων ιδιόκτητων πρόσθετων. Πολλά από τα codec του VLC προέρχονται από τη βιβλιοθήκη του FFmpeg προγράμματος, αλλά κυρίως χρησιμοποιεί τους δικούς του πολυπλέχτες και αποπολυπλέχτες. Ακόμη διακρίθηκε ως ο πρώτος αναπαραγωγός που υποστηρίζει αναπαραγωγή κρυπτογραφημένων DVDs σε Linux χρησιμοποιώντας τη βιβλιοθήκη αποκρυπτογράφησης DVD libdvdcss.

 

Σχ .1 – Εξαρτήσεις του VLC Player

 

3.2.2 – Χαρακτηριστικά VLC

 

Επειδή ο VLC είναι ένας αναπαραγωγός πολυμέσων βασισμένος σε πακέτα, μπορεί να αναπαράγει περιεχόμενο ακόμη και σε κατεστραμμένα, ατελή ή ημιτελής βίντεο. (Για παράδειγμα αρχεία που ακόμη ‘κατεβαίνουν’ μέσω ομότιμων δικτύων(P2P)). Επίσης μπορεί να αναπαράγει m2t MPEG transport streams(.TS) αρχεία την ώρα που τα αρχεία ακόμη ψηφιοποιούνται από μια HDV κάμερα διαμέσου εωός FireWire καλωδίου. Ακόμα μπορεί να χρησιμοποιήσει τη βιβλιοθήκη libcdio για να έχει πρόσβαση σε .iso αρχεία έτσι ώστε οι χρήστες να μπορούν να αναπαράγουν αρχεία σε μια εικόνα δίσκου, ακόμη και αν το λειτουργικό του χρήστη δεν μπορεί να δουλέψει απευθείας με αρχεία .iso.

 

Ο VLC υποστηρίζει όλες τις μορφές ήχου και βίντεο και όλες τις μορφές αρχείων που υποστηρίζονται από τις βιβλιοθήκες libavcodec και libavformat. Αυτό σημαίνει ότι ο VLC μπορεί να αναπαράγει H.264 ή MPEG-4 βίντεο καθώς και υποστηρίζει FLV ή MXF μορφές αρχείων από την αρχή χρησιμοποιώντας τις βιβλιοθήκες του FFmpeg. Εναλλακτικά, ο VLC έχει ενότητες για codecs που δεν είναι βασισμένες στις βιβλιοθήκες του FFmpeg. Ο VLC είναι ένας από τους DVD αναπαραγωγείς, ανοιχτού λογισμικού και ανοιχτού κώδικα, που αγνοεί την κωδικοποίηση περιοχής DVD σε συσκευές με υλικολογισμικό RPC-1, κάνοντας τον αναπαραγωγέα ανεξαρτήτου περιοχής. Όμως δεν κάνει το ίδιο σε συσκευές με υλικολογισμικό RPC-2. Ο VLC διαθέτει μερικά φίλτρα που μπορούν να στρεβλώσουν, να περιστρέψουν, να χωρίσουν, να καθρεφτίζουν βίντεο, ή να προσθέτουν ένα λογότυπο πάνω από το βίντεο. Ακόμη μπορεί να παράγει σαν βίντεο χαρακτήρες ASCII.

 

Χρησιμοποιώντας μια σύνδεση με καλώδια FireWire ανάμεσα σε έναν υπολογιστή και μια HDTV ο VLC μπορεί να κάνει stream τα αρχεία των χρηστών χωρίς κρυπτογράφηση. Ο VLC μπορεί παρουσιάσει το βίντεο που αναπαράγεται σαν ταπετσαρία στην επιφάνεια εργασίας, όπως το Windows DreamScene, χρησιμοποιώντας DirectX, διαθέσιμο μόνο σε λειτουργικά συστήματα Windows. Ο VLC μπορεί να καταγράψει την επιφάνεια εργασίας. Στις περισσότερες πλατφόρμες, ο VLC μπορεί να συντονιστεί και να δει DVB-C, DVB-T και DVB-S κανάλια. Στο Mac OS X χρειάζεται το ξεχωριστό πρόσθετο EyeTV, ενώ στο Windows χρειάζεται τους BDA οδηγούς κάρτας.

 

Ο VLC μπορεί να εγκατασταθεί ή να τρέξει απευθείας από usb stick ή άλλο εξωτερικό δίσκο. Ο VLC μπορεί να επεκταθεί μέσω της μεθόδου σεναρίου. Χρησιμοποιεί τη γλώσσα σεναρίου Lua. Ο VLC μπορεί να αναπαράγει βίντεο σε AVCHD μορφή, μια μορφή υψηλής συμπίεσης που χρησιμοποιείται στις πρόσφατες HD κάμερες. Ο VLC μπορεί να παράγει έναν αριθμό από μουσικές οπτικοποιήσεις.

 

3.3 – Πρακτική εξέταση των τεχνικών κωδικοποίησης του H.264 με χρήση ffmpeg & VLC

 

Μετά από εκτενή ανάλυση των τεχνολογιών και τεχνικών συμπίεσης δεδομένων, εικόνας, και video θα εξετάσουμε και θα εφαρμόσουμε πρακτικά τις τεχνικές συμπίεσης των προφίλ προτύπου H.264 που αναφέρθηκαν στο 2ο κεφάλαιο. Από τις αρχές της δεκαετίας του ‘90 είναι εμφανές ότι έαν κάτι έχει εξελιχθεί σε θεαματικό βαθμό θα λέγαμε ότι αναφέρονται στις τεχνολογίες συμπίεσης κινούμενος εικόνας. Για παράδειγμα ο ήχος και η εικόνα λόγω κυρίως της χρήσης τους σε μέσα όπως το internet ή η ανάγκη τους για μαζική αποθήκευση σε CD κτλπ ώθησε για παράδειγμα το wav σε mp3 ή ogg αρχεία και την εικόνα απο bmp σε jpeg. Φυσικά σήμερα υπάρχουν πάρα πολλά φορματ που εξειδικεύονται εώς προς την χρήση κάθε φορά (jpeg ή png) αλλά μπορούμε να δούμε πως δεν υπάρχει θεαματικά διαφορά εως προς το μέγεθος και ποιότητα του εξαγόμενου αρχείου όταν έχουμε να κάνουμε με αρχεία αρκετά χαμηλού μεγέθους.

Όσο αναφορά το video τα πράγματα διαφοροποιούνται εμφανώς. Από την ίδια του την φύση το ασυμπίεστο video καθίστανται αδύνατο να αποθηκευθεί και να μεταδοθεί. Την δεκαέτια του ‘90 άρχισε να εμφανίζεται η ανάγκη για συμπίεση του video.  Ψηφιακή δορφορική τηλεόραση, video cd’s και δειλά-δειλα αναπαραγωγή ψηφιακού video μέσω προσωπικών υπολογιστών. Το MPEG-2 και οι παραλαγές του καθιερώθηκαν σαν το πρότυπο για τις ανάγκες της εποχής. Σήμερα τα πράγματα σαφώς έχουν αλλάξει με την εμφάνιση υπηρεσίων δικτυακού video υψηλής ευκρίνιας, οπτικών δίσκων Blue-ray, 3D καμερών κτλπ. Έτσι λοιπόν όπως αναλύσαμε διεξοδικά στο 2ο κεφάλαιο το περίφημο σύνολο προτύπων και προδιαγραφών Η.264, στις αρχές του 2004 ήρθε να αποτελέσει το υπόβαθρο  για έναν ενιαίο και επιμερισμένο τρόπο για εφαρμογή τεχνικών συμπίεσης ανάλογα με την χρήση που απαιτείται κάθε φορά.

 

Η εξετάση των τεχνικών συμπίεσης θα γίνει οπτικά στο τελευταίο σκέλος της εργασίας αυτής με την χρήση ανοιχτών και δωρεάν εργαλείων λογισμικού (FFmpeg & VLC). Σκοπός είναι να πάρουμε δείγμα αρχείου ανάυσης 1280 x 720 pixels (720p) και να επανακωδικοποιήθεί ανά τμήματα με ή χωρίς χρήση ορισμένων έξυπνων τεχνικών συμπίεσης. Για παράδειγμα ένα  στατικό πλάνο με έναν κινούμενο χαρακτήρα  στο προσκήνιο να φανεί σε πραγματικό χρόνο η δυνατότητα ή μη της διανυσματικής απεικόνισης του μέσω της διανυσματικής του κίνησης στο σταθερό πλάνο. Επιπλέον θα δοκιμάσουμε να δούμε κατά πόσο μια πανοραμική λήψη ενός τοπίου με χρήση ιπτάμενου μέσου αποδίδεται με ή χωρίς χρήση ειδικευμένης τεχνικής για πλάνα της κατηγορίας αυτής.  To FFmpeg μας επιτρέπει την κωδικοποίηση ενός ασυμπίεστου video με χρήση παραμέτρων μέσω γραμμής εντολών. Το λειτουργικό σύστημα που έχει επιλεγεί είναι το Mac OS X Lion 10.7.1 (11B26 July 2011) στο Macbook Pro 2,66 GHz Core Duo, 4 GB RAM (μοντέλο 2010) με χρήση ανάλυσης 1280 x 800 pixels. Η επικόνηση του εξαγόμενου αρχείου θα γίνει μέσω της ψηφιακής έξοδου HDMI σε οθόνη ανάλυσης 1920 x 1080 pixels (FullHD). Το συγκεκριμένο σύστημα και η αναλύση της οθόνης του laptop δέν είναι αρκετό να απεικονίσει και να επεξεργαστεί σε πραγματικό χρόνο video ανάλυσης 1080p γιαυτό επιλέγουμε video 720p που εν έτη 2011 αποτλεί την πιο διαδεδομένη λύση σε παραγωγές υψηλές ευκρίνειας.

 

3.2.1 – Video Transcoding με χρήση FFmpeg & VLC

 

Ο όρος video transcoding αναφέρεται στην μετατροπή ένος συγκεκριμένου σήματος video σε ένα άλλο, με χρήση άλλης φόρμας δεδομένων (format), όπως διαφορετικό ρυθμό μετάδοσης δεδομένων, καρέ / δευτερόλπετο, μέγεθος καρέ ή ακόμη προτύπου συμπίεσης. Λόγω της ευρείας επέκτασης των πολυμεσικών εφαρμογών και υπάρχουσα υποδομή που αποτελείται απο πολλές διαφορετικές τεχνολογίες δικτύων και πρωτοκόλλων, παρουσιάσθηκε η ανάγκη για υιοθέτηση πολυμεσικών επικοινωνιακών τεχνικών που να είναι συμβάτα με διαφορετικές τεχνολογίες δικτύων. Για παράδειγμα, κατά την μετάδοση μια ροής video διαμέσου δικτύων διαφορετικής αρχιτεκτονικής, η σύνδεση από την πηγή video απο τον χρήστη μπορεί να διασφαλισθεί με συνδέσμους (links) επιμέρους χαρακτηριστικών και δυνατοτήτων. Στην περίπτωση αυτή το εύρος ζώνης που απαιτείται από τον συμπιεσμένο video προσαρμόζεται συνήθως από την πηγή για να ταιριάζει στο μικρότερο δυνατό εύρος ζώνης της ζεύξης. Κατά την χρήση video σε πραγματικό χρόνο αυτό μπορεί να εφαρμοστεί από τον κωδικοποιητή με τον καθορισμό των παραμέτρων κωδικοποίησης Ωστόσο η ποιότητα εικόνας πρέπει να θυσιαστεί καθώς το εύρος ζώνης πρέπει να είναι ίσο ή μικρότερο σε σχέση με τον πιο αργό σύνδεσμο του δικτύου που χρησιμοποιούμε Από την άλλη όταν θέλουμε να μεταδώσουμε κωδικοποιημένο video σε χρήστες με διαφορετικό εύρος ζώνης ο καθένας, η υλοποίηση καθίστανται δύσκολη καθώς απαιτήσεις εύρους ζώνης είναι άγνωστες κατά την αρχική κωδικοποίηση του video. Πέρα απο τους περιορισμούς των καναλιών μετάδοσης, οι συσκεύες αναπαραγωγής video παρουσιάζουν και αυτές πολλές δυσκολίες. Για παράδειγμα, η τάση για χρήση μικρών φορητών συσκευών όπως κινητά τηλέφωνα και ταμπλέτες π.χ. για επικοινωνία με video και πρόσβαση στο internet. Οι περισσότερες συσκευές σήμερα έχουν περιορισμένη επεξεργαστική ισχύ και ανάλυση οθόνης και καθίστανται αναποτελεσματικές για αποκωδικοποίηση και αναπαραγωγή υψηλής πιστότητας. Στις περιπτώσεις αυτές στο video υψηλής ποιότητας  είναι αναγκαίο να επανακωδικοποιηθεί σε χαμηλότερη ποιότητα κατάλληλη για αναπαραγωγή στις συσκευές αυτές. Καθώς ο αριθμός των προτύπων κωδικοποίησης video αυξάνει (π.χ. H.261, H.263, MPEG-1, MPEG-2, MPEG-4) παρουσιάζεται αυξημένη η ανάγκη μετατροπής video απο τον ένα πρότυπο στο άλλο. Επιπλέον στην περίπτωση που στην πηγή video υπάρχει ανάγκη μετάδοσης σε πολλούς διαφορετικούς πελάτες διαμέσου καναλιών με διαφορετικές δυνατότητες, το εξαγόμενο video πρέπει να μετατραπεί στο συγκεκριμένο εύρος ζώνης για κάθε επιμέρους κανάλι. Το πρόβλημα αυτό παρουσιάζεται σε τηλεσυνδιασκέψεις  με πολλούς χρήστες, όπου η πολύπλεξη διαφορετικών ροών κινούμενης εικόνας μπορεί να υπερβαίνει την δυνατότητα μετάδοσης του καναλιού και να απαιτεί μεταβολή του ρυθμού μετάδοσης.

 

Κεφάλαιο 3 – Αναπαραγωγή Η.264 Video με Flash και HTML5

•December 8, 2015 • Leave a Comment

3.1 Ιστορική επισκόπηση του video στο internet

 

Από τις πρώτα χρόνια της εμπορικής διάθεσης του internet η υποστηρίξη για video ήταν μηδαμινή εώς περιοσμένη. Ο όρος streaming media, πολυμέσα ροής, αναφέρετε στην διαδικάσία παροχής περιοχμένου απο τον πάροχο στον τελικό χρήστη. Το μοντέλο αυτό παροχής δεδομένων μπορεί να γενικευθεί, περιλαμβάνοντας τα κλασσικά μοντέλα διάθεσης video μέσω video clubs, τηλεόρασης, περιοδικών καθώς και ανταλαγής cd/dvd.

 

Στις αρχές του 1920 ο George O. Squier κατοχύρωσε πατέντες για ένα σύστημα μετάδοσης και διανομής σημάτων μέσω ηλεκτρικών καλωδίων το οποίο αποτέλεσε την βάση για μια τεχνολογία ενονόματι muzak. Η τεχνολογία αυτή έκανε δυνατή την εκπομπή συνεχούς ροής μουσικής σε εμπορικούς πελάτες χωρίς την χρήση ραδιοφώνου. Προσπάθειες για προβολή πολυμέσων σε υπολογιστές είχαν γίνει απο αρκετά νωρίς, οστώσο μόνο μέχρι τα τέλη της δεκαετίας του 1980 και 1990 εμπορικά συστήματα είχαν την απαιτούμενη επεξεργαστική ισχύ ώστε να είναι σε θέση να προβάλουν αποτελεσματικά πολυμεσικό περιεχόμενο. Οι κύριες τεχνικές προϋποθέσεις για αναπαραγωγή ροής video (streaming video) είναι:

  • Αρκετή επεξεργαστική ισχύς και αρκετή εύρος ζώνης διάυλου ώστε να είναι δυνατή η υποστήριξη των ρυθμών μετάδοσης
  • Δυνατότητα του λειτουργικού συστήματος να αντιμετωπίζει τις υπερχιλήσεις στην μνήμη (buffer underrun) μέσω ελέγχων χαμηλής απόκρισης.

 

Οστώσο τα δίκτυα υπολογιστών ήταν ακόμη περιορισμένα, και η μετάδοση του υλικού γινόταν ακόμη διαμέσου καναλιών χωρίς εκπομπή, όπως κατέβασμα αρχείων απο servers και αποθήκευση τους στον σκληρό δίσκο ή εγγραφή τους σε CD-ROMS.

 

Στα τέλη του 1990 και αρχές του 2000 παρατηρήθηκαν τα παρακάτω:

  • Άυξηση του εύρους ζώνης και σε ημιαστικές περιοχές
  • Άυξηση της δυνατότητας πρόσβασης σε δίκτυα, ιδιαίτερα στο internet
  • Χρήση καθιερωμένων προτώκολλων όπως TCP/IP, HTTP και HTML
  • Εμπορική διάθεση του internet

 

3.1.1 – Εμπορικές Υλοποιήσεις

 

Εταιρίες όπως η RealNetworkds προτοστάτησε στην αγορά του streaming media, όταν μετέδωσε πρώτη αγώνα basket μέσω internet. Επιπλέον η Microsoft ανέπτυξε έναν αναπαραγωγό πολυμέσων γνωστό εώς ActiveMovie το 1995 ο οποίος επέτρεπε την μετάδοση video μέσω ένος κλειστού προτύπου. Πάνω σε αυτό βασίστηκε η δυνατότητα του Windows Media Player 6.4 το 1999 να αναπαράγωγει ροές video απο το internet. Τον Ιούνη του 1999 η Apple παρουσίασε το δικό της πρότυπο που συμπεριλαμβανότανε στο QuickTime 4. Αργότερα υοθετήθηκε παράλληλα με τα πρότυπα ροών των RealPlayer και Windows Media Player. Τα ανταγωνιστικά αυτά πρότυπα απαιτούσαν την εγκατάσταση του κάθε επιμέρους προγράμματος ώστε να είναι δυνατή η αναπαραγωγή των video στις ιστοσελίδες. Το 2002 η ανάγκη υοθέτησης ενός ενιαίου προτύπου για streaming video και η ευρεία υοθέτηση του Adove Flash ώθησε στην ανάπτυξη της δυνατότητας αναπαραγωγής video σε ιστοσελίδες μέσω αυτού. Ακόμη και σήμερα το Flash χρησιμοποιείται ευρέως για την αναπαραγωγή video σε δημοφιλής υπηρεσίες διαδικτυακού video όπως YouTube.

 

Σχ.2 – Χρονική εξέλιξη των τεχνολογίων video στο web

 

3.1.2 – Η εμπορική διάθεση των υπηρεσίων ροής video

 

Οι εξελίξεις στα δίκτυα υπολογιστών σε συνδιασμό με την στιαδιακή άυξηση της επεξεργαστικής ισχύς των οικιακών υπολογιστών και λειτουργικών συστημάτων κατέστησε τις υπηρεσίες ροής video πρακτικά διαδέσιμες για τον κάθε χρήστη. Υπηρεσίες διαδικτυακού ραδιοφώνου επέτρεψαν την ακρόαση ακόμη και χωρίς υπλογιστή. Σε γενικές γραμμές, το πολυμεσικό περιεχόμενο όπως video και εικόνα απαιτούν μεγάλο όγκο δεδομένων με αποτέλεσμα να διανέμονται συμπιεσμένα είτε για αποθήκευση ή μετάδοση.

 

Ακόμη η ολοένα ανάγκη μετάδοσης video υψηλής ευκρίνας (HD) οδήγησε την βιομηχανία πληροφορικής να αναπτύξει τεχνολογίες όπως WirelessHD ή ΙΤU-T G.hn τα όποια ειδικεύονται στην μετάδοση περιεχομένου υψηλής ευκρίνιας χωρίς να απαιτείται η εγκατάσταση επιπλεόν καλωδίων. Σήμερα το video δύναται να μεταδοθεί είτε σε πραγματικό χρόνο (live) είτε κατ επιλογή (on demand). Οι μεταδόσεις πραγματικού χρόνου παρέχονται απο μέσα που ονομάζονται “true streaming”. Αυτά στέλνουν την πληροφορία κατευθείαν στον υπολογιστή ή συσκευή χωρίς την αναγκή αποθήκευσης της στον σκληρό δίσκο. Οι υπηρεσίες on demand παρέχονται απο μέσα προοδευτικής ροής “progressive streaming”. Η τεχνική αυτή αποθηκεύει το αρχείο προσωρινά στον σκληρό δίσκο και έπειρα αναπαράγεται απο εκεί.

 

3.1.3 – Έυρος ζώνης & αποθηκευτικές απαιτήσεις ροών video

 

Μια ευρυζωνική σύνδεση της τάξης των 2.5Mbit/s ή παραπάνω συνίσταται για την αναπαραγωγή online video, σε αντίθεση με τις υλοποιήσεις Apple TV, Google TV ή το Sony TV Blue-Ray Disk Player που απαιτείται τουλάχιστον 10Mbit για αναπαραγωγή περιεχομένου υψηλής ευκρίνειας. Το μέγεθος ένος αρχείου online video υπολογίζεται βάση του εύρος ζώνης  ροής και το μέγεθος του με χρήση της παρακάτω φόρμουλας (για ένα μόνο αρχείο ανα χρήστη): Μέγεθος αποθήκευσης (σε ΜΒ) = διάρκεια video (σε seconds) x ρυθμός δεδομένων (bitrate σε bit/s) / ( 8 x 1024 x 1024).

 

Παράδειγμα: Μια ώρα video κωδικοποιημένο σε 300 kbit/s (ένα τυπικό video εν έτη 2005 με ανάλυση 320 x 240) θα είναι: (3,600 s x 300,000 bit/s) / (8 x 1042 x 1024) απαιτεί  περίπου 128 MB για την αποθήκευση του. Εάν το αρχείο αποθηκευθεί σε έναν πάροχο για αναπαραγωγή κατα βούληση και αυτή η ροή προσπελασθεί απο 1000 χρήστες ταυτόχρονα με χρήση προτοκόλου εκπομπής unicast, οι απαιτήσεις είναι οι εξής: 300 kbit/s x 1,000 = 300,000 kbit/s = 300 Mbit/s εύρους ζώνης. Αυτό αντιστοιχεί σε 135 GB ανα ώρα. Με χρήση προτοκόλου multicast ο πάροχος στέλνει προς τα έξω μια μοναδική ροή δεδομένων κοινή σε όλους τους χρήστες. Επομένως στην περίπτωση αυτή θα απαιτείτω μόνο 300 kbit/s εύρος ζώνης απο μεριάς του παρόχου της υπηρεσίας.

 

Σχ.3 –  Οι τεχνικές μονής εκμπομής (Unicast) απαιτόύν πολλαπλές επιμέρους συνδέσεις απο τον ίδιο πάροχο εκπομπής ακόμη και όταν εκπέμπεται το ίδιο περιεχόμενο.

 

3.1.4 –  Codec, ροές δεδομένων, επίπεδο μεταφοράς, τεχνικές ελέγχου

 

Η ροή δεδομένων που αφορά τον ήχο συνήθως συμπιέζεταθ με χρήση αλγορίθμων συμπίεσης όπως Mp3, Vobris ή AAC. Για την ροή του video γίνεται συμπίεση με χρήση codec όπως το VP8 και το H.264 το οποίο θα επικεντρωθούμε στην συνέχεια. Το κωδικοποιημένο video και ήχος συνθέτονται σε μια ενιαία ροή δεδομένων όπως flv, WebM, ASF ή ISMA. Η ροή αυτή διανέμεται απο τον πάροχο στον χρήστη με χρήση προτοκόλων μεταφοράς όπως το MMS ή RTP. Αυτός μπορεί να αλληλεπιδρά με τον πάροχο με χρήση των προτοκόλων ελέγχου όπως το MMS ή RSTP

 

3.2 –  Το πρότυπο H.264, WebM στο internet με χρήση της HTML5

 

Το σύνολο προδιαγραφών που περιγράφονται με την HTML5 εισήγαγαν το στοιχείο του video μέσω το <video> tag με σκοπό την αναπαραγωγή video και ταινιών αντικαθιστώντας το object element. Η ανάπτυξη των προδιαγραφών του HTML5 video έγινε με στόχευση να αποτελέσει ένα νέο πρότυπο για αναπαραγωγή video χωρίς την ανάγκη χρήσης plugins, ή οποία δυστηχώς συναντά εμπόδια λόγω της μη συμφωνίας μεταξύ των formats τα οποία θα πρέπει να υποστηριχθούν απο τους browsers.

 

3.2.1 – Ιστορική ανασκόπηση του <video> tag

 

To html tag <video> αρχικά προτάθηκε απο την Opera Software τον Φεβρουάριο του 2007. Η Opera ακόμη δημοσιευσε μια δοκιμαστική έκδοση του browser της την ίδια μέρα καθώς και μια δήλωση που πρότεινε οτι το video έπρεπε να ενσωματωθεί ριζικά στο web.

 

Παραδείγματα HTML5 <video> tag με χρήση ενός video WebM:

 

<video src=”movie.webm” poster=”movie.jpg” controls>
</video>

 

HTML5 <video> tag με χρήση πολλαπλών πηγών

 

Η χρήση πολλαπλών πηγών video, όπως φαίνεται στον κώδικα παρακάτω, καθιστά ικανό τον broswer να επιλέγει αυτόματα πιο αρχείο να διαβάσει. Εναλλακτικά μέσω JavaScript η συνάρτηση canPlay() μπορεί να χρησιμοποιηθεί για ακριβώς τον ίδιο σκοπό. Η παράμετρος “type” προσδιορίζει το MIME type και το σύνολο των codecs βοηθώντας τον browser να προσδιορίσει εάν είναι σε θέση να αποκωδικοποιήσει το αρχείο. Ακόμη και με μόνο μια επιλογή, οι πληροφορία αυτή είναι σημαντική για έναν browser ώστε να ανατρέξει στην πολυμεσική βιβλιοθήκη ώστε να επιλέξει τον κατάλληλο codec για την αποκωδικοποίηση. Λόγω της μη ύπαρξης ενός κοινού format video, οι προσθήκη πολλαπλών πηγών είναι αναγκαία για την αποφυγή ανάγκης εντοπισμού του browser (sniffing) όπου συνήθως υπόκειται σε λάθη δεδομένου οτι η γνώση ενός προγραμματιστή ιστοσελίδων θα είναι πάντα ελλειπής. Έτσι λοιπόν είναι σκόπιμο να αφήνουμε στον broswer να κάνει μόνος του την επιλογή της πηγής.

 

Παράδειγμα HTML5 <video> tag με χρήση προλλαπλών πηγών:

 

<video poster=”movie.jpg” controls>
       <source src=”movie.webm” type=’video/webm; codecs=”vp8.0, vorbis”‘/>
       <source src=”movie.ogv” type=’video/ogg; codecs=”theora, vorbis”‘/>
       <source src=”movie.mp4″ type=’video/mp4; codecs=”avc1.4D401E, mp4a.40.2″‘/>
       <p>This is fallback content</p>
</video>

 

3.2.2 – Υποστηριζόμενα format video απο το HMTL5 <video> tag

 

Οι προδιαγραφές της HTML5 δεν προσδιορίζει ποια format video θα πρέπει οι browsers να υποστηρίζουν. Κάθε κατασκευαστής έχει την δυνατότητα να επιλέγει οποιδήποτε είδος video τον βολεύει, αλλά δεν πρέπει να υποθέτουν αυτοί που παράγουν υλικό προς δημοσιευση οτι θα μπορεί ο κάθε τελικός χρήστης να αναπαράγει ένα συγκεκριμένο format. Ο κάθε browser δεν υποχρεούνται να υποστηρίζει όλα τα διαθέσιμα είδη συμπιεσης/κωδικοποίησης video.

 

Η διαμάχη μεταξύ των διαφορετικών format video

 

Η ομάδα εργασίας της HTML5 θεωρεί ότι είναι σημαντικό να καθορίσει τουλάχιστον ένα format video το οποία πρέπει οι browsers να υποστηρίζουν. Το ιδανικό αυτό format θα πρέπει:

 

  • Να έχει καλό λόγο συμπίεσης, καλή ποιότητα εικόνας καθως και χαμηλές επεξεργαστικές απαιτήσεις κατα την αποκωδικοποίηση του video
  • Να μην έχει πνευματικά δικαιώματα
  • Πέρα απο τους αποκωδικοποιητές με χρήση λογισμικού θα πρέπει να υπάρχει ένας αποκωδικοποιητής βασισμένος σε υλικό (hardware) καθώς πολύ ενσωμετωμένοι επεξεργαστές δεν έχουν καλή απόδοση κατα την αποκωδικοποίηση ενός video.

 

Αρχικά το Ogg Theora προτάθηκε σαν το ιδανικό πρότυπο καθώς δεν επηρεαζόταν απο καμία γνωστή πατέντα λογισμικού. Το Δεκεμβριο του 2007 όμως, το πρότυπο HTML5 ανανεώθηκε, αντικαθιστώντας την αναφορά στα καθιερωμένα formats: Οι browsers πρέπει να υποστηρίζουν το Theora video και Vobris audio, καθώς και το Ogg.

 

Με χρήση κώδικα συμπεριληψης (placeholder) θα ήταν σκόπιμη η διαλειτουργικότητα μεταξύ των browsers ώστε να υποστηρίζουν τα ίδια codecs. Ωστόσο, δεν υπάρχει codec που να ικανοποιεί όλους τους κατασκευαστές. Υπάρχει ανάγκη χρήση ενός codec που να μην απαιτεί αδειοδότησε ανά χρήστη ή διανομέα, να είναι συμβατός με το μοντέλο ανάπτυξης ανοιχτού κώδικα, να έχει τα ποιοτικά χαρακτηριστικά ώστε να είναι αξιοποιήσημος καθώς και να μην αποτελεί κίνδυνο για μεγάλες εταιρίες η καθυστέρηση έκδοσης πατέντων λογισμικού.

 

Παρόλο που το Ogg Theora δεν επηρεάζεται απο καμία γνωστή πατέντα, εταιρίας όπως η Apple και Nokia απασχολούνται κατα πόσο άγνωστες πατέντες θα μπορούσαν να το επηρεάζουν, κάτοχοι των οποίων θα μπορούσαν να στοχεύουν την λήψη ασφαλιστικών μέτρων κατά μεγάλων εταιρίων με υψηλό αποθεματικό κεφαλαίο που ενδέχετω να κάνου χρήση τους. Πρότυπα όπως το H.264 ενδέχεται να υποκύπτουν σε άνγωστες πατέντες, αλλά εφόσον έχουν χρησιμοποιηθεί ευρέως υποθέτουμε οτι οι κάτοχοι τους έχουν γνωστοποιηθεί ευρέως. Η Apple αντιτάθηκε επίσης στην υοθέτηση του Ogg format στο πρότυπο HTML (ακόμη και σαν “απαραίτητη προϋποθεση”) με την δικαιολογία ότι οι συσκευές της υποστηρίζουν πιο εύκολα άλλα format και ιστορικά η HTML δεν απαιτούσε συγκεκριμένα format για οτιδήποτε.

Ορισμένοι web developers άσκησαν κριτική στην αφαίρεση του Ogg format απο το πρότυπο. Η διαμάχη συνεχίστηκε στο blog ερωτοαπαντήσεων της W3C. Το πρότυπο H.264/MPEG-4 AVC χρησιμοποιείται ευρέως, έχοντας καλή ταχύτητα, συμπίεσης, υποστηριζόμενο από κυκλώματα αποκωδικοποιησης καθώς και ικανοποιητική ποιότητα εικόνας αλλά υπόκεινται σε πατέντες λογισμικού. Εκτός από ορισμένες περιπτώσεις, αυτοί που υλοποιούν κάτι με το H.264 υποχρεώνται να πληρώνουν τέλη για αδειοδότηση στην MPEG-LA, μια ομάδα κατόχων πατεντών συμπεριλαμβανομένου την Microsoft και Apple. Αποτέλεσμα των παραπάνω είναι να μην θεωρείται σαν codec απαιτείται η συμπερίληψη του. Τον Ιούνη του 2009 η WHATWG κατέληξε ότι κανένα τρέχων format δεν είναι κατάλληλο για καθορισμό του εώς απαίτηση.

 

Η αγορά από την Google της On2

 

Η αγορά της On2 απο την Google το 2010 είχε σαν αποτέλεσμα το VP8 format video να αποτελεί ιδιοκτησία της. H Google παρέχει την δυνατότητα χρήσης του VP8 χωρίς δεσμεύσεις λόγω δικαιωμάτων πνευματικής ιδιοκτησίας. Η Google άρχισε επίσης το WebM, που περιλαμβάνει ένα μη προτυπομοιμένο, ανοιχτού λογισμικού, VP8 video codec με ήχο βασισμένο στο Vobris σε έναν Matroska υποδοχέα (container). Η μετάβαση του VP8 καλωσορήσθηκε απο την κοινότητα ανοιχτού λογισμικού.

 

Όταν η Google ανακοίνωσε τον Ιανουάριο του 2011 ότι θα παρείχε ενσωματωμένο υποστήριξη του H.264 στον Chrome, προέκυψε κριτική απο μέρους παραγόντων της Ars Technica και Microsoft, οι οποίοι σύγκριναν την κίνηση αυτή της Google όμοια με την δήλωση της Esperanto σαν επίσημη γλώσσα των Ηνωμένων Πολιτιών. Ωστόσο ο Haavard Moen της Opera Software άσκησε οξεία κριτική στο άρθρο της Ars Technica και η Google απάντησε τονίζοντας την πρόθεση της να προωθήσει το WebM σύμφωνα με την φιλοσοφία που διέπει το ανοιχτό λογισμικό. Μέτα την παρουσίαση του WebM η Mozilla και η Opera Software ζήτησαν την συμπερίληψη του VP8 στην HTML.

 

Σχ.2 – Η επίδραση των codec της on2 technologies σε καθιερωμένα πρότυπα

 

3.3 – Υποστήριξη απο browsers

 

Ο παρακάτω πίνακας μας δείχνει πια video formats είναι πιθανό να υποστηρίζονται απο κάθε επιμέρους browser. Κάθε ένας χρησιμοποιεί μια βιβλιοθήκη πολυμέσων (multimedia framework) για την αποκωδικοποίηση και προβολή ενός video, αντί να ενσωματώνει όλα αυτά τα στοιχεία λογισμικού. Δεν είναι δυνατή η γνώση των formats που υποστηρίζονται απο μια βιβλιοθήκη πολυμέσων χωρίς να ανατρέξουμε σε αυτήν, καθώς κάθε φορά εξαρτάται από το λειτουργικό σύστημα και codec τρίτων κατασκευαστών. Στις περιπτώσεις αυτές, η υποστήριξη ενός video codec είναι χαρακτηριστικό του framework και όχι του browser ή της μηχανής του, υποθέτωντας οτι αυτός ανατρέχει στην βιβλιοθήκη πολυμέσων πριν απορίψει άγνωστα format video. Σε ορισμένες περιπτώσεις η υποστήριξη που φαίνεται στον παρακάτω πίνακα δεν είναι αποτέλεσμα των codec που υπάρχουν ήδη διαθέσιμα απο τις βιβλιοθήκες πολυμέσων του λειτουργικού σύστηματος ή των ενσωματωμένων δυνατοτήτων αποκωδικοποίησης του browser αλλά ενός επιπρόσθετου του browser που δύναται να παρακάμψει την συνηθισμένη ανάγνωση του HTML <video> tag ώστε να εμφανίζει ενός plug-in video player.

 

Το format video μπορεί να καθοριστεί απο το MIME type στην HTML. Τα MIME types χρησιμεύουν ώστε να ανατρέχει ο browser κάθε φορά στην βιβλιοθήκη πολυμέσων για υποστηριζόμενα formats. Απο όλους τους browsers μόνο ο Firefox και ο Opera ενσωματώνουν βιβλιοθήκες για ενσωματωμένη αποκωδικοποίηση. Πρακτικά ο Internet Explorer και ο Safari διασφαλίζουν την υποστήριξη ορισμένων format, καθώς οι κατασκευαστές τους είναι οι ίδιοι που δημιουργούν τις βιβλιοθήκες πολυμέσων. Στην αντίπερα όχθη o Konqueror έχει πανοιμότυπη υποστήριξη με τον Internet Explorer όταν εκτελείται στα Windows ή ο Safari στον Mac, καθώς ο Konqueror συνήθως εκτελείται σε GNU/Linux. Γενικά η διαφοροποίηση της υποστήριξης σε format προσδιορίζεται από τα αντικρουόμενα συμφέροντα των κατασκευαστών, όπως π.χ. η Media Foundation και Quicktime υποστηρίζουν εμπορικά πρότυπα ενώ το Gstreamer και Phonon δεν μπορούν νομικά να υποστηρίξουν κάτι άλλο πέρα απο ανοιχτά formats εξ ορισμού στα ανοιχτά λειτουργικά για τα οποία κατασκευάζονται (Linux/BSD).

 

Σχ.4 Διαθεσιμότητα των format video σε αντιστοιχία με το ποσοστό χρήσης των browsers

 

3.4 –  Αποδοχή του HTML5 <video>

 

Τον απρίλιο του 2010 με την παρουσίαση του iPad, πλήθος δημοφιλών υπηρεσίων του internet άρχισαν να παρέχουν το H.264 HTML5 video αντί του Flash για χρήστες της συγκεκριμένης συσκευής. Τον Μάη του 2010 το HTML5 video δεν ήταν τόσο διαδεδομένο όπως το flash video αλλά παρόλα αυτά πειραματικές εκδόσεις html5 video players άρχισαν να εμφανίζοναι απο την Dailymotion (με χρήση του Ogg Theora Vorbis) Youtube (με χρήση του Η.264 και WebM) και Vimeo (με χρήση του H.264) υποδηλώνουν την ολοένα αυξητική τάση υοθέτησης του HTML5 video.

 

Ορισμένοι βασικοί παρόχοι video ανακοίνωσαν ότι αποφασίζουν να συνεχίζουν να χρησιμοποιούν τεχνολογίες πέρα από το HTML5 video. Σύμφωνα με ανάρτηση στο blog του Youtube τον Ιούνη του 2010, το <video> tag δεν καλύπτει τις ανάγκες μιας τέτοιας κλίμακας υπηρεσίας. Σαν κύριος λόγος προτάθηκε η απουσία ενός καθιερωμένου format, την απουσία ενός αξίοπιστου τρόπου μεταφοράς του video στον browser, η έλειψη δυνατότητας της Javascript να προβάλει σε πλήρης οθόνη καθώς και λόγους προστασίας του περιεχομένου. Το Hulu δεν έχει υοθετήσει το HTML5 video  λόγω της έλλειψης δυνατότητας παροχής περιεχομένου με προσαρμοσμένο έυρος ζώνης (adaptive bandwidth), έλλειψης προστασίας του περιεχομένου των παραγωγών και αδυναμίας παροχής στους διαφημιστές με πληροφορίες. To Netflix δήλωσε πως υπάρχουν αρκετοί λόγοι που τους αποτρέπουν στην υοθέτηση του HTML5 video: μη ύπαρξη A/V container ευρίας αποδοχής, codec video και ήχου, πρωτόκολο ροής, τρόπος για ώστε το πρωτόκολο να προσαρμόζεται σύμφωνα με το διαθέσιμο έυρος ζώνης, τρόπος ώστε να παρέχονται πληροφορίες για τις διαθέσιμες ροές δεδομένων και άλλως παραμέτρων στον αναπαραγωγέα video, τρόπος για την προστασία του περιεχομένου, και απουσία κάποιου ρεαλιστικού τρόπου ενσωμάτωσης των απαιτήσεων αυτών στην HTML5.

 

Το Ιανουάριο του 2011, το Chromium Project της Google ανακοίνωσε στο blog του η υποστήριξη εμπορικών codec θα αφαιρεθεί απο μελοντικές εκδόσεις του Chrome. Η ανακοίνωση του Chromium ανέφερε συγκεκριμένα ότι η κίνηση αυτή ήταν κομμάτι της προσπάθειας αύξησης χρήσης του άνευ-άδειας HTML5 <video> tag, οδηγώντας την προσπάθεια αποδοχής του ανοιχτού VP8 και Theora. Τον Φεβρουάριο του 2011 η Microsoft ανακοίνωσε την δημοσίευση της επέκτασης HTML5 Windows Media Player για τον Chrome σε Windows 7, η οποία παρείχε την δυνατότητα χρήσης του Η.264 που υπόκειται σε άδειες πνευματικής ιδιοκτησίας. Πλήθος εξελιγμένων HMTL5 players έχουν εμφανισθεί στο προσκήνιο. Ο SublimeVideo Player αποτέλεσε τον πρώτη προσπάθεια ανάδειξης ενός προσασμοσμένου player με καλύτερη εμπειρία αναπαραγωγής σε σχέση με τον ενσωματωμένο player του browser. Δυνατότητες όπως ενοποιημένη εμφάνιση του player σε κάθε συσκευή, μετακύληση σε flash player για μη υποστηρίζομενους browsers ή συσκευές και πραγματική αναπαραγωγή πλήρης οθόνης. Άλλες δημοφιλής επιλογές αποτελούν οι JW Player, Video JS και MediaElement.js

 

3.5 – Σύγκριση HTML5 <video> και Flash

 

Προφανώς το flash αποτελεί μια αναλακτική στο Adobe Flash για την αναπαραγωγή video στο web. Και τα δύο περιλαμβάνουν δυνατότητες αναπαραγωγής video και ήχου μέσα σε ιστοσελίδες καθώς και χρήση διανυσματικών γραφικών svg υποστηρίζονται και στο κάθε ένα απο αυτά. Μια κοινή παρανόηση αποτελεί ότι η HTML5 δύναται να παρέχει την δυνατότητα προβολής διαδραστικών animation. Απαιτείται η χρήση Javascript ή CSS 3 για τον παραπάνω σκοπό αυτό.

 

Διαθεσιμότητα του Flash

 

Το Adobe Flash δημιουργήθηκε το 1996 και λόγω αυτού χαίρει ευρείας αποδοχής απο χρήστες και προγραμματιστές διαδικτύου. Σύμφωνα με στατιστικά της Adobe, το Flash έφτασε στο 98% σε υοθέτηση τον Μάρτη του 2010. Η τελευταία έκδοση του flash τρέχει σε Microsoft Windows, Mac OS X, Linux, Android 2.2 εώς 4.0, Google TV, Playstation, PSP, Wii, Symbian, Meamo Linux, Windows Mobile κ.α. Η Apple δεν επιτρέπει τις συσκευές της να τρέχουν Flash στο iOS που συναντάται στο iPad, iPhone, iPod Touch & Apple TV καθώς όπως χαρακτηριστικά είχε δηλώσει υπονομεύουν την απόδοση των συσκευών αυτών.

 

Διαθεσιμότητα της HTML5

 

Η προεργασία για το πρότυπο HMTL5 είχει ήδη αρχίσει απο το 2003 και μόλις στις αρχές του 2011 ήταν σε λειτουργικό στάδιο ανάπτυξης. Η παρούσα έκδοση έχει αρκετά κενά υλοποίησης. Το 2006 υποστήριχθηκε από τον Ian Hickson ότι το πρότυπο αυτό δεν θα ήταν τελική έκδοση μέχρι το 2022. Τον Μάρτη του 2011 οι browsers όπως Internet Explorer, Firefox, Chrome, Safari και Opera ενσωμάτωσαν την HTML5 σε μεγάλο βαθμό. Ωστόσο, αρκετοί χρήστες του Internet συνεχίζουν να χρησιμοποιούν παλιούς browsers όπως Internet Explorer 8 (η τελευταία έκδοση που υποστηρίζεται στα Windows XP). Έτσι λοιπόν ενδέχεται μεγάλο κομμάτι του προτύπου HTML5 να μην υποστηρίζεται απο τους browsers που είναι σε χρήση στο web.

 

Υοθέτηση του flash από ιστοσελίδες σύμφωνα με την Adobe

 

  • 85% των δημοφηλέστερων ιστοσελίδων κάνουν χρήση του Flash
  • 75% του web video αναπαράγεται με χρήση του Flash Player
  • 98% των εταιρίων βασίζονται στον Flash Player
  • 70% των παιχνιδιών στο web φτιάχνονται με χρήση του Flash

 

Πολλές σελίδες όπως προαναφέρθηκε υποστηρίζουν ακόμη πειρματικά το HTML5 video όπως YouTube, Vimeo κ.α. Σύμφωνα με δήλωση του Steve Jobs τόνισε οτι το Flash δεν αποτελεί ανοιχτό πρότυπου άρα υπόκειται στον έλεγχο της Adobe Systems ενώ το πρότυπου HTML5 ελέγχεται νομικά απο την επιτροπή WHATWG που αποτελείται απο τρεις εταιρίες: Opera Software, Mozilla και Apple.

 

Απόδοση

Ορισμένοι χρήστες, ιδιαίτερα αυτού σε πλατφόρμες όπως Mac OS X και Linux έχουν αναφέρει υψηλό ποσοστό χρήσης του επεξεργαστή κατα την διάρκεια αναπαραγωγής video με flash. Αυτό οφείλεται εν μέρη στην έλλειψη υποστηρίξης της κάρτας γραφικών κατά την προβολή του video. Η Adobe απάντησε σε αυτούς τους ισχυρισμούς στις εκδόσεις 10.1 και 10.2 του flash plugin εκφορρώνοντας της αποκωδικοποίηση του H.264 video σε ειξιδικευμένο υλικό παρουσιάζοντας ένα νέο video API γνωστό εώς Stage Video. Επιπλέον η χρήση της νέας έκδοσης ActionScript 3.0 στο flash video σε σχέση με την παλαιότερη ActionScript 2.0 βελτιώνει περίπου 10 φορές την ταχύτητα εκτέλεσης του κώδικα. Ωστόσο παλαιότερες σελίδες γραμμένες σε ActionScript 2.0 δεν επωφλούνται απο τα παραπάνω. Ένας ακόμη λόγος χαμηλής απόδησης του flash και html5 αποτελεί τον γεγονός μη σωστής χρήσης κώδικα απο μεριάς του προηραμματιστή.

 

Δυνατότητες

Το πρότυπο flash έχει την δυνατότητα να κάνει υπολογισμούς σε τμήματα υπο-εικονοστοιχείων (sub-pixel increments). Αυτό το καθιστά ικανό να προβάλει video με μεγαλύτερη ευκρίνεια και γενικά να έχει πιο ευχάριστη εμφάνιση σε ιστοσελίδες βασισμένες σε flash. Σε σύγκριση με υπολογισμούς με CSS και HTML5 σε κλίμακα υπο-εικονοστοιχείων, θα παράγουν μεταβλητό αποτέλεσμα που εξαρτάται κάθε φορά απο τον browser, κάνοντας το τελικό εμφανησιακό αποτέλεσμα μη συνεκτικό στις σελίδς αυτές.

 

Το flash προσφέρει υποστηρίξη σε webcams και DRM, ενώ το HTML5 και αντίστοιχες τεχνολογίες δεν προσφέρουν αυτές τις δυνατότητες προς το παρόν. Υπάρχουν ομάδες ατόμων που αναπτύσουν την υποστήριξη για συσκευές (device API) στο HTML5 πρότυπο, οι οποίες μελλοντικά θα επιτρέψουν την τηλεσυνδιάσκεψη, πρόσφαση σε webcams καθώς και συσκευές USB.

 

Διασυμβατότητα μεταξύ λειτουργικών συστημάτων

Σε μια ομιλία στην ‘Adobe Max’ το 2011, o Itai Asseo υποστήριξε ότι, σε αντίθεση με το HTML5, το flash προσφέρει έναν καλό τρόπο για την ανάπτυξη εφαρμογών που δουλεύουν αποτλεσματικά σε όλες τις πλατφόρμες. To HMTL5 απο την άλλη υλοποιείται διαφορετικά σε κάθε επιμέρους browser. Παρόλο που το iOS δεν υποστηρίζει το flash, οι εφαρμογές μπορούν να εξαχθούν μέσω του Adobe AIR, το οποίο τρέχει στο λειτουργικό αυτό σαν εξορισμού εφαρμογή. Στην ίδια συζήτηση ο Asseo κινδυνολόγησε για έναν νέο πόλεμο μεταξύ των browsers όμοιο με αυτόν στα τέλη του 1990. Εάν το flash πάψει να είναι αρεστό, οι προγραμματιστές θα πρέπει είτε να υλοποιούν διαφορετικές εκδόσεις της ιστοσελίδας που αναπτύσουν ή εφαρμογών τους, λαμβάνοντας υπόψιν τις διαφορετικές υλοποιήσεις της HTML5, ή ακόμη να αρνούνται την πρόσβαση στις ιστοσελίδες τους σε browsers που δεν υποστηρίζουν την έκδοση αυτή της HTML και να μειώνουν την λειτουργικότητα της σελίδας τους σε μη εξελιγμένους browsers.

 

3.6 – Ενσωματωμένη αποκωδικοποίηση του H.264 video σε flash και HTML5

 

3.6.1 – Flash και H.264 video

 

Μετά απο 9 χρόνια ο Flash Player θα ενσωμετώσει έναν νεο video codec. Το 2002 ο Flash Player συμπεριέλαβε έναν video codec που παρείχε ο Sorenson. Το Spark Video Codec αποτελούσε μια προσασμοσμενή και απλή υλοποιήση του προτύπου H.263. Υποστήριζε απλές τεχνικές κωδικοποίησης από το H.263v1 (P-Frames με πρόβλεψη κίνησης, ακρίβεια μισού εικονοστοιχείου, 1 frame αναφοράς, +/- 16 εικονοστοιχεία μακράς αναφοράς, RLE και Huffman εντροπίες για κωδικοποίηση) με επιπλεόν ορισμένες εμπλουτισμένες δυνατότητες αποτμηματοποίησης (deblocking) στην μετα-επεξεργασία και το ειδικά D-Frames (Desposable Frames) τα οποία μοιάζουν με τα P-Frames αλλά δεν μπορούν να χρησιμοποιηθούν σαν αναφορές. Η τελευταία αυτή τεχνική υλοποιήθηκε ώστε να υποστηρίξει την κύρια στόχευση του Spark: να παρέχει έναν codec video χαμηλής απόκρισης για επικοινωνία στο internet.

 

O Flash Player 6 ηταν ικανότατος ώστε να παρέχει την δυνατότητα να παράγει και να συνθέτει ροές video αλλά μόνο απο το νέο προϊον της Macromedia για servers: Τον Flash Communication Server (FCS), ένα επαναστατικό προϊον σε σχέση με τα αντίστοιχα προϊοντα της εποχής. Η υψηλή τιμή του (4500$) εμπόδισε την ευρεία αποδοχή του. Με την επερχόμενη έκδοση Flash Player 7 η Macromedia αποφάσισε να ξεκλειδώσει την δυνατότητα χρήσης των video Sorenson για προοδευτικό κατέβασμα. Αυτό αποτέλεσε τον λόγο έναρξης μιας “επανάστασης” στo internet. Μετά απο 2 με 3 χρόνια το Spark video codec κατέστει αναρχονισμένος, καθώς η υλοποίηση το κωδικοποιητή στον Flash Player δεν ήταν βελτιστοποιημένη και χρησιμποιούσε πολύ λίγες προσεγγίσεις κατα τον έλεγχο της κωδικοποίησης. Η κοινότητα άρχισε να επιζητά βελτιώσεις χωρίς ιδιαίτερη ανταπόκριση μέχρι τα μέσα του 2011. Έτσι λοιπόν η Adobe παρουσίασε στον κωδικοποιητή flash έναν τύπου H.264. Καθώς το H.264 αποτελεί την αχμή ανάμεσα στις τεχνολογίες κωδικοποίησης video, η παρουσία των B-Frames και οι δυνατότητες που παρέχει ο codec αυτός ώστε ακόμη μια φτωχή υλοποίηση θα ήταν ικανή να οδηγήσει σε σημαντικές βελτιώσεις στο Spark codec.

 

Το flash video υποστηρίζει επεξεργασία βασισμένη στο υλικό, πολυ-πύρηνη αναπαραγωγή πλήρους οθόνης και είναι σε θέση να προβάλει οποιοδήποτε H.264 video συμπεριλαμβανομένου των mp4 και mov αρχείων. Το Η.264 έχει την βέλτιστη δυνατή ποιότητα εικόνας και η υποστήριξη του απο τον flash player σημαίνει ότι δια υπάρχει ένας άριστος συνδιασμός ενός δημοφιλούς λογισμικού όπως το flash με το πιο δημοφιλή πρότυπο video. Αυτό έχει σαν αποτέλεσμα, την έυκολη και άμεση αναπαραγωγή video ύψηλής ευκρίνιας (HD) για κάθε τελικό χρήστη στο web. Το τελικό αναπαραγόμενο video έχει την βέλτιστη απόδοση και εμφάνιση. Θα αποτελέσει έναν σημαντικό και καταλυτικό παράγοντα ώστε να ωθήσει το video στην εποχή της υψηλής ευκρίνιας (HD).

 

Όσο αναφορά τους παραγωγούς video έχει αρκετά νέα προτερήματα. Θα είμαστε να θέση να κωδικοποιούμε video σε έναν διαδεδομένο και ανοιχτό codec και θα δύναται να αναπαραχθεί σε κάθε συσκευή συνδεδεμένη με τον internet. Ο Flash Player 9 σε μερικούς μήνες άγγιξε το μερίδιο 84,3%. Η μετάβαση αυτή δίνει την δυνατότητα χρήσης πολών εργαλείων και βιβλιοθηκών βασισμένες στον H.264 codec. Εργαλεία όπως το Adobe Premiere Pro και Adobe After Effects υποστηρίζουν πλήρως τον codec αυτό. Αποτελεί ένα σημαντικό βήμα διευκόλυνσης για την δημιουργία υλικού για άμεση αναπαραγωγή στο web.

 

3.6.2 – HTML5 και Η.264 video

 

Όπως προαναφέρθηκε παραπάνω το πρότυπο html5 δεν έχει κατασταλάξει ακόμη όσο αναφορά τον κυρίαρχο codec που συνίσταται να χρησιμοποιείται στο <video> tag. Με λίγα λόγια το H.264, Ogg Theora και WebM αποτελούν τα τρία ανταγωνιστικά πρότυπα που ενδέχεται να κυριαρχήσουν στο μέλλον. Ορισμένες ομάδες ενδιαφόροντος είτε εμπορικές είτε απο την κοινότητα του ανοιχτού λογισμικού υποστηρίζουν το κάθε ένα παραπάνω πρότυπο. Συνοπτικά το H.264 υποστηρίζεται απο την WHATWG (Apple, Mozilla, Opera), το Οgg Theora το οποίο υποστηρίζεται απο την κοινότητα ανοιχτού λογισμικού και τέλος το WebM ή VP8 το οποίο αναπτύχθηκε απο την On2, πέρασε στα χέρια της Google το 2010 και πλέον αποτελεί κομμάτι ανοιχτού λογισμικού.

 

Κάθε απο τις παραπάνω τεχνολογίες έχει τα υπέρ και τα κατά του, με νομικούς περιορισμούς το καθένα για την υλοποιήση και ενσωμάτωση του στους browsers ή μη, καθώς και ζητήματα τεχνικής υπεροχής μεταξύ τους σε εξεικευμένες εφαρμογές. Στην περίπτωση μας θα επικεντρωθούμε στο H.264 και θα το συγκρίνουμε με τα άλλα 2 πρότυπα καθώς καθώς και με τον flash player. Όπως είπαμε το τοπίο στο HTML5 video δεν έχει κατασταλάξει πλήρως καθώς είναι σημαντικό να ξεπεραστούν ορισμένα τεχνολογικά εμπόδια με προσθήκη επιπλέον λειτουργειών στα τρία παραπάνω πρότυπα και θέματα καθαρά πολιτικής των ομάδων που τα υποστηρίζουν.

 

Στο επόμενο κεφάλαιο θα εξετάσουμε καθαρά ποσοτικά και ποιοτικά την απόδοση όσως εξετάσθηκαν στο κεφάλαιο αυτό, με δοκιμή τους σε όσο το δυνατόν περισσότερους browsers και λειτουργικών συστημάτων στο ίδια υπολογιστικό σύστημα και θα προσπαθήσουμε να δούμε πιο από όλα αποδίδει πιο σταθέρα σε υψηλά bitrates και αναλύσεις των 720p και 1080p

 

Κεφάλαιο 2 – Ανάλυση Προτύπων H.264

•December 8, 2015 • Leave a Comment

2.1 – Το H.264  Επισκόπηση

 

Το H.264/MPEG4 Part 10 ή αλλιώς AVC (Advanced Video Coding) αποτελεί ένα αρκετά διαδεδομένο πρότυπο συμπίεσης κινούμενης εικόνας. Ο τελικός σχεδιασμός του προτύπου αυτού ολοκληρώθηκε τον Μάη του 2003. Αποτελεί ένα πρότυπο κωδικοποίησης λαμβάνοντας υπόψιν την διανυσματική κίνηση των μπλοκ εικονοστοιχείων και αναπτύχθηκε από την ITU-T (VCEG) μαζί με την επιτροπή ISO/IEC (MPEG). Αποτελεί προϊόν συνεργασίας γνωστό σαν ομάδα Joint Video Team (JVT). Το ITU-T H.264 πρότυπο και το ISO/IEC  MPEG-4 AVC αναπτύσσονται και εξελίσσονται παράλληλα έτσι ώστε να διατηρούν μια συνεκτικότητα στην τεχνική τους τεκμηρίωση. Το H.264 χρησιμοποιείται σε εφαρμογές όπως οι οπτικοί δίσκοι Blue-ray, δικτυακό video Youtube, καθώς και σε χρήσεις όπως iTunes, DVB επίγειες ή δορυφορικές μεταδόσεις εικόνας, καλωδιακή τηλεόραση ή σε ζωντανές τηλεσυνδιασκέψεις εικόνας .

 

Ο αρχική σκοπιμότητα του προτύπου Η.264 ήταν να καταφέρει να δημιουργηθεί ένα πρότυπο ικανό να παρέχει καλή ποιότητα εικόνας σε σχετικά χαμηλούς ρυθμούς μετάδοσης δεδομένων σε σχέση με παλαιότερα πρότυπα, χωρίς την αύξηση της πολυπλοκότητας του σχεδιασμού, το οποίο θα  το καθηστούσε μη πρακτικό ή υπερβολικά ακριβό κατά την υλοποίηση του. Ένας επιπρόσθετος στόχος ήταν να παρέχει αρκετή ευελιξία ώστε να είναι πρακτικά εφαρμόσιμο σε πληθώρα εφαρμογών, κάθε φορά σε διαφορά δίκτυα ή συστήματα, συμπεριλαμβανομένου χαμηλών και υψηλών ρυθμών μετάδοσης ή ανάλυσης εικόνας, εκπομπές, αποθήκευση DVD, RTP/IP δικτυα καθώς και πολυμεσικά τηλεφωνικά συστήματα τύπου ITU-T. Το H.264 μπορεί να θεωρηθεί έως μια “οικογένεια προτύπων”, τα μέλη των οποίων είναι τα προφίλ που θα περιγραφούν παρακάτω. Ένας συγκεκριμένος αποκωδικοποιητής, αποκωδικοποιεί τουλάχιστον ένα, αλλά όχι απαραίτητα όλα από τα προφίλ. Τα επιμέρους χαρακτηριστικά ένος αποκωδικοποιητή περιγράφουν πια προφίλ μπορούν να αποκωδικοποιηθούν.

 

Το όνομα του H.264 ακολουθεί την σειρά ονομασίας της επιτροπής ITU-T, όπου το πρότυπο είναι μέλος της οικογένειας προτύπων H.26x VCEG κινούμενης εικόνας: το όνομα MPEG-4 AVC συσχετίζετε με την επιτροπή ISO/IEC MPEG, όπου αποτελεί το 10ο κομμάτι της. Το Η.264 αναπτύχθηκε σε συνεργασία με το VCEG και MPEG, μετά από πρώιμη ανάπτυξη στην επιτροπή ITU-T καθώς και στο VCEG project με ονομασία Η.26L. Έτσι λοιπόν συνηθίζεται να αναφέρεται σαν H.264/AVC, H.264/MPEG-4 AVC ή MPEG-4/H.264 AVC, ώστε να επισημάνει την κοινή τους αρχική τους ανάπτυξη. Το όνομα H.26L αναφέρεται στο ITU-T κομμάτι ανάπτυξης του αλλά παρόλα αυτά συναντιέται σπάνια.

 

Η προτυποποίηση του H.264/AV όπου ολοκληρώθηκε στον Μάη του 2003 όπως προαναφέραμε, το αρχικό πλάνο επέκτασης του προτύπου JVT ανέπτυξε τις Επεκτάσεις Μεταβαλλόμενης Πιστότητας (Fidelity Range Extensions (FRExt)). Αυτές οι επεκτάσεις επέτρεπαν υψηλότερη ποιότητα εικόνας υποστηρίζοντας λήψη ψηφιακών δειγμάτων αυξημένου βάθους (increased sample bit depth precision) καθώς και λήψη χρωματικών δειγμάτων υψηλότερης ανάλυσης (higher-resolution color information). Οι τεχνικές δειγματοληψίας αυτές είναι γνωστές σαν Y’CbCr 4:2:2 (=YUV 4:2:2) και Y’CbCr 4:4:4. Πολλά επιπλέον χαρακτηριστικά συμπεριλήφθηκαν στο Fidelity Range Extensions project όπως προσαρμοσμένη αλλαγή μεταξύ 4×4 και 8×8 μετασχητισμό ακαιρέων, πίνακες μεταβαλλόμενου βάρους κβαντοποίησης, βάση οπτικής αντίληψης του κωδικοποιητή (encoder-specified perceptual-based quantization weighting matrices), αποδοτική κωδικοποίηση εικόνας καθώς και υποστήριξη επιπλέον χρωματικών πεδίων. Η ολοκλήρωση του σχεδιασμού πάνω στις επεκτάσεις μεταβαλλόμενης πιστότητας ολοκληρώθηκε τον Ιούλη του 2004 και η τεκμηρίωση της τον Σεπτέμβρη του 2004. Οι επιπλέον επεκτάσεις του προτύπου που συμπεριλήφθηκαν αρχικά στόχευαν κυρίως σε επαγγελματικές εφαρμογές, υποστηρίζοντας επιπλέον παλέτες χρωμάτων και ορίζοντας επιπρόσθετες αναλογίες εικόνας με την χρήση δύο ακόμη είδη πληροφορίας μορφοποίησης εικόνας “supplemental enhancement information” (post-filter hint and tone mapping) και υποβαθμίζοντας τα αρχικά FRExt προφιλ στα οποία εκδηλώθηκε η ανάγκη στην αγορά να σχεδιαστούν διαφορετικά.

 

Ένα κύριο χαρακτηριστικό που συμπεριλήφθηκε ήταν η κλιμακούμενη κωδικοποίηση κινούμενης εικόνας (Scalable Video Coding). Περιλαμβάνεται στο Annex G του H.264/AVC, το SVC επιτρεπει την κατασκευή ροών δεδομένων που εμπεριέχουν υποροές που οποίες υπακούν στα χαρακτηριστικά του προτύπου Οι επεκτάσεις αυτές συμπεριηφηκαν μετέπειτα τον Νοεμβρη του 2007. Το αμεσως επομενο χαρακτηριστικο που συμπεριλήφθηκαν ήταν το πρότυπο της κωδικοποίησης πολλαπλής απεικονησης (Multiview Video Coding MVC). Περιληφθηκε στο Annex H και επιτρεπει στην κωδικοποιηση ροων δεδομενων που αναπαριστουν πανω απο μια ληψεις σε μια συγκεκριμενη σκηνη. Ένα σημαντικο παραδειγμα εφαρμογης της τεχνικης αυτης είναι η κωδικοποίηση μιας στερεοσκοπικής 3D απεικόνισης. Δυο προφιλ αναπτυχθηκαν στην αναπτυξη το MVC: το ένα υποστηριζει πολλαπλές γωνιες ληψης και το αλλο αναπτυχθηκε ειδικα για την προβολη στερεοσκοπικου video. Οι επεκτασεις αυτες ολοκληρωθηκαν τον Νοέμβρη του 2009.

 

Σχ.1 – Πίνακας σύγκρισης του H.264/AVC (MPEG-4) με άλλα δημοφιλή πρότυπα κωδικοποίησης video

 

2.2 – Εφαρμογές του H.264

 

Το πρότυπο κινουμενης εικόνας H.264, συνανταται σε πληθωρα εφαρμογων που καλυπτουν όλες τις κατηγοριες συμπιεσμενου video, απο πολυ χαμηλα bitrate σε μεταδωσεις μεσω Internet μεχρι και τηλεοπτικες προβολες υψηλης πιστοτητας (HDTV), σε εφαρμογες ψηφιακου οικιακου σινεμα με σχεδον μη απωλεστικες κωδικοποιησεις. Με την χρηση του H.264, τα οφελη στην μειωση του μεγεθους του τελικου αρχειου ειναι της ταξης του 50% και ανω. Για παραδειγμα έχει αναφερθει οτι με την χρηση του H.264 έχουμε την ιδια τελικη ποιοτητα εικονας σε δορυφορικες μεταδωσεις σε σχεση με υλοποιησεις σε MPEG-2 με τον μισο ογκο δεδομενων στην ζευξη. Οι παρουσες εφαρμογες MPEG-2 λειτουργουν περιπου στα 3.5Mbit/s καθως το H.264 μολις στα 1.5 Mbit/s. Για την διασφαληση της συμβατοτητας και της απροσκοπτης υοθετησης του H.264/AVC, πολλά πακετα προτυπων έχουν ενσωματωσει τα σχετικα χαρακτηριστικα ώστε οι χρηστες τους να μπορουν χρησιμοποιησουν το H.264/AVC.

 

Οι οπτικοί δίσκου Blue-ray καθώς και οι HD DVD που αποσυρθηκαν εν τελη κανουν χρηση του H.264/AVC High Profile, ένα απο τα 3 συνιστωμενα προτυπα συμπίεσης. Η Sony έχει κανει και αυτη χρηση του φορμα αυτου στο  Memory Stick Video format. Η επιτροπη που ανεπτυξε τo προτυπο για τις επιγιες ψηφιακες μεταδωσεις (DVB) ενεκρινε την χρηση του H.264/AVC για την εκμπομπη τηλεοπτικου σήματους στα τελη του 2004. Επιπλεον η αντιστοιχη επιτροπη επιγειας ψηφιακης τηλεορασης στις ΗΠΑ (ATSC) υοθετησε και αυτη την χρηση του παραπανω προτυπου τον Ιουλη το 2008 παρολο που το προτυπο δεν εχει γινει πληρως συμβατό με τις παρουσες μεταδωσεις της επιτροπης αυτης. Ακόμη έχει εγκριθεί για χρηση στο video μεσω δικτου κινητης τηλεφωνίας  ATSC-M/H (Mobile/Handheld) αξιοποιωντας το AVC και SVC κομμάτι του H.264.

 

To AVCHD αποτελεί ένα πρότυπο εγγραφής video υψηλής πιστότητας σχεδιασμένο απο την Sony και Panasonic καθώς κάνει χρήση του H.264 (ακολουθεί το πρότυπο αυτό κάνοντας χρήση

επιπλέον χαρακτηριστικών). Οι τεχνολογίες κλειστών κυκλωμάτων τηλεόρασης CCTV έχουν ενσωματώσει το πρότυπο σε πληθώρα προϊόντων. Πριν την εφαρμογή του παραπάνω προτύπου, οι τεχνολογίες συμπίεσης που χρησιμοποιώντας στην αγορά των φορητών βιντεοκαμερών DVR’s είχαν γενικά περιορισμένες δυνατότητες συμπίεσης. Με την υοθέτηση του προτύπου συμπίεσης H.264 στις εφαρμογές κλειστών κυκλωμάτων παρακολούθησης, η τελική ποιότητα του  video βελτιώθηκε αισθητά. Στις αρχές του 2008, ορισμένες εταιρίες του χώρου προωθούσαν τις τεχνολογίες που προσφέρει το πρότυπο H.264 εως εφαρμογές video υψηλής πιστότητας.

 

2.3 – Κατοχύρωση Αδειών Λογισμικού H.264

 

Σε χώρες όπου οι πατέντες λογισμικού είναι σε ισχύ, οι κατασκευαστές καθώς και οι εμπορικοί χρήστες που χρησιμοποιούν το H.264/AVC εξυπακούεται να πληρώνουν κάποιο χρηματικό ποσό για την χρήση των δικαιωμάτων πνευματικής ιδιοκτησίας που αναφέρεται στην συγκεκριμένη τεχνολογία. Αυτό αφορά επίσης και το Baseline Profile. Ένας ιδιωτικός οργανισμός εννονόματι MPEG LA, οποίος δεν συσχετίζεται με την επιτροπή προτυποποίησης του MPEG, χορηγεί τις άδειες λογισμικού που σχετίζονται με το πρότυπο αυτό καθώς και αυτές που αφορούν συστήματα  MPEG-2 Part 1, MPEG-2 Part 2 Video, MPEG-4 Part 2 Video καθώς και άλλες αντίστοιχες τεχνολογίες. Η τελευταία US MPEG LA πατέντα λογισμικού για το H.264 δεν προβλέπεται να λήξει πριν το 2028.

 

Στις 26 Αυγούστου, 2010 η επιτροπή MPEG LA ανακοίνωσε ότι το video κωδικοποιημένο με την χρήση του H.264 για χρήση στο διαδίκτυο δεν πρόσκειται σε χρεώσεις δικαιωμάτων πνευματικής ιδιοκτησίας όσο αναφορά τους τελικούς χρήστες. Όλα τα υπόλοιπα δικαιώματα ισχύουν κανονικά όπως εκείνα που αφορούν προϊόντα που κωδικοποιούν ή αποκωδικοποιούν το H.264 video. Οι όροι χρήσης ανανεώνονται ανά διαστήματα 5 χρόνων.

 

Το 2005 η Qualcomm, ή οποία κατοχύρωσε τις πατέντες U.S. Patent 5,452,104 και U.S. Patent 5,576,767 μήνυσε την Broadcom, κατηγορώντας την για παραβίαση τους, δημιουργώντας προϊόντα που ήταν συμβατά με το πρότυπο συμπίεσης video H.264. Το 2007 το περιφερικό δικαστήριο  διαπίστωσε οτι οι πατέντες δεν ήταν δυνατό να λάβουν ισχύ διότι η Qualcomm απέτυχε να τις δημοσιοποιήσει στο JVT πριν την έκδοση του προ

 

In 2005, Qualcomm, which was the assignee of U.S. Patent 5,452,104 and U.S. Patent 5,576,767 sued Broadcom in US District Court, alleging that Broadcom infringed the two patents by making products that were compliant with the H.264 video compression standard. In 2007, the District Court found that the patents were unenforceable because Qualcomm had failed to disclose them to the JVT prior to the release of the H.264 standard in May 2003. In December 2008, the US Court of Appeals for the Federal Circuit affirmed the District Court’s order that the patents be unenforceable but remanded to the District Court with instructions to limit the scope of unenforceability to H.264 compliant products.[

 

2.4 – Χαρακτηριστικά Προτύπου H.264

 

To H.264/AVC/MPEG-4 Part 10 εμπεριέχει πληθώρα νέων χαρακτηριστικών που επιτρέπουν στην αποτελεσματικότερη συμπίεση σε σχέση με παλαιότερα πρότυπα και παρέχουν ευελιξία στην εφαρμογή σε μια ευρεία γκάμα δικτυακών περιβαλλόντων.  Συγκεκριμένα, μερικά απο τα βασικά αυτά χαρακτηριστικά είναι τα ακόλουθα:

 

2.4.1 – Τεχνικές συσχέτισης πολλών διαδοχικών καρέ ενός video

 

  • Η χρήση εικόνων που έχουν κωδικοποιηθεί ήδη σαν αναφορές, με πολύ αποδοτικότερο τρόπο σε σχέση με τα παλαιότερα πρότυπα, επιτρέπουν μέχρι και 16 καρέ (frames) αναφοράς (ή 32 πεδία αναφοράς, στην περίπτωση προοδευτικής κωδικοποίησης). Η τεχνική αυτή επιτρέπει συνήθως μικρές βελτιώσεις του εξερχόμενου όγκου δεδομένων και στην ποιότητα στις πιο πολλές σκηνές. Σε συγκεκριμένα όμως ήδη σκηνών, όπως αυτές με επαναλαμβανόμενη κίνηση ή πλάνα μπρος-πίσω ή σε ακάλυπτους χώρους σκηνικών , επιτρέπει την σημαντική μείωση του όγκου δεδομένων διατηρώντας παράλληλα την ποιότητα εικόνας σε ικανοποιητικά επίπεδα.
  • Απόδοση κίνησης με χρήση μπλοκ κλιμακούμενου μεγέθους (Variable block-size motion compensation (VBSMC)). Τα μπλοκ αυτά μπορεί να έχουν μεγεθος 16×16 ή ακόμη και 4×4,  κάνοντας δυνατή την ακριβής κατάτμηση της κινούμενων τμημάτων. Τα μπλοκ φωτινότητας που υποστηρίζονται είναι τα μπλοκ 16×16, 16×8, 8×16, 8×8, 4×8 και 4×4, όπου συνδιαζόμενα μεταξύ τους μπορούν να αποτελέσουν ένα μακρομλοκ (macroblock). Το μέγεθος των μπλοκ χρωματικής πρόβλεψης είναι σε αντιστοιχία με την χρωματική δειγματοληψία που εφαρμόζεται κάθε φορά.
  • Η δυνατότητα χρήση πολλαπλών διανυσμάτων κίνησης ανά μακρομπλοκ (ένα ή δυο ανα τμήματα) με μέγιστο τα 32 σε περίπτωση που ένα Β απο αυτό δομείται με 16 τμήματα 4×4. Το διάνυσμα κίνησης για κάθε 8×8 ή μεγαλύτερης τμηματική περιοχής μπορεί να αντιστοιχίζεται σε διαφορετικές εικόνες κάθε φορά.
  • Η δυνατότητα χρήσης οποιουδήποτε είδους μακρομπλοκ στα B-frames, συμπεριλαμβανομένου Ι-macroblock, έχοντας σαν αποτέλεσμα την αποδοτικότερη κωδικοποίηση όταν γίνεται χρήση B-frames. Αυτό το χαρακτηριστικό δεν συμπεριλήφθηκε στο MPEG-4 ASP.
  • Η ακρίβεια 1/4 εικονοστοιχείου (quarter pixel) για ορισμό κίνησης, κάνοντας δυνατή την ακριβής περιγραφή της κίνησης συγκεκριμένων περιοχών. Όσο αναφορά την χρωματική πληροφορία η ανάλυση έχει κοπεί στο μισό οριζοντίως και καθέτως, έτσι λοιπόν ο χρωματικός ορισμός κίνησης κάνει χρήση μόνο το 1/8 των μονάδων πλέγματος χρωματικών εικονοστοιχείων (chroma pixel grid units)
  • Πρόβλεψη μεταβλητού βάρους, επιτρέποντας στον κωδικοποιητή να ορίζει την χρήση κλίμακας και αντιστοιχίας όταν εφαρμόζει τον ορισμό κίνησης, παρέχοντας σημαντική βελτίωση στην απόδοση σε ειδικές περιπτώσεις, όπως στην μετάβαση της εικόνας σε μαύρο φόντο ή αντίστροφα. Η τεχνική αυτή περιλαμβάνει την αυστηρή συσχέτιση βαρών για τα B-frames καθώς και για τα P-frames.

 

2.4.2 – Τμηματική πρόβλεψη από τις άκρες των γειτονικών μπλοκ για δια-κωδικοποίηση, αντι για πρόβλεψη “DC” που συναντιέται στο MPEG-2 Part 2 και στον μετασχηματισμό αποδοτικής πρόβλεψης του H.263v2 και MPEG-4 part 2. Αυτός περιλαμβάνει τμηματική πρόβλεψη φωτεινότητας με χρήση μπλοκ μεγέθους 16×16, 8×8, και 4×4 (όπου ένας είδος κάθε φορά μπορεί να χρησιμοποιηθεί σε κάθε macroblock).

 

2.4.3 – Τεχνικές μη-απωλεστικής κωδικοποίησης macroblock.

 

  • Λειτουργία μη-απωλεστικής απεικόνησης “PCM Macroblock” στην οποία τα δείγματα δεδομένων video αναπαρίστανται απευθείας, επιτρέποντας την τέλεια απεικόνηση συγκεκριμένων περιοχών και επιτρέποντας την θέσπιση ενός αυστηρού ορίου στην ποσότητα των κωδικοποιημένων δεδομένων του κάθε macroblock.
  • Λειτουργία προσαρμοσμένης αναπαράστασης μη-απωλεστικών macroblock, επιτρέποντας την βέλτιστη αναπαράσταση συγκεκριμένων περιοχών ενώ γίνεται φυσιολογικά με χρήση αρκετών λιγότερων δεδομένων σε σχέση με την λειτουργία PCM

 

2.4.4 – Ευέλικτες τεχνικές πεπλεγμένης σάρωσης (Flexible interlaced-scan video coding):

 

  • Προσαρμοσμένη κωδικοποιήση συνόλου μπλοκ (macroblcok) (MBAFF). Με την χρήση δομής ζευγών macroblock εώς εικόνες κωδοποιημένες σαν καρέ, επιτρέποντας τα 16×16 σε τομείς πεδίου (σε σύγκριση με το MPEG-2, όπου οι τομείς πεδίων κωδικοποιούνται σαν καρέ, καταλήγουν στην επεξργασία μισών macroblock 16×8)
  • Η τεχνική “Picture-adaptive frame-field coding” (PAFF or PicAFF) επιτρέπει στην ελεύθερη επιλογή διαφοερτικών εικόνων κωδικοποιημένες σαν ολόκληρα καρέ, όπου και τα δύο πεδία συνδιάζονται για να κωδικοποιηθούν μαζί ή σαν ξεχωριστά μοναδικά πεδία (fields).

 

2.4.5 – Νέες τεχνικές σχεδιαστικού μετασχηματισμού (transform design features):

 

 

  • Χρήση ενός απόλυτα αντιστοιχίσημου ακεραίου 4×4 τμηματικού μετασχηματισμού μπλοκ, που επιτρέπει την ακριβή τοποθέτηση σημάτων διαφοροποίησης (residual signals). Η τεχνική αυτή είναι ενοιολογικά παρόμοια με το γνωστό DCT design, απλουστευμένο μεν έτσι ώστε να παρέχει αποκωδικοποίηση ακριβίας.
  • Χρήση ενός απόλυτα αντιστοιχήσιμου ακεραίου 8×8 τμηματικού μετασχηματισμού block, επιτρέποντας την αποδοτικότερη συμπίεση συσχετισμένων περιοχών σε σύγκριση με τον μετασχηματισμό 4×4. Η τεχνική αυτή είναι επίσης όμοια με το DCT Design, σε πιο απλή μορφή έτσι ώστε να επιτυγχάνεται ακρίβια.
  • Προσαρμοσμένη επιλογή κωδικοποιητή ανάμεσα στον μετασχηματισμό 4×4 και 8×8 μεγέθους μπλοκ για την μετασχηματισμού ακεραίων.

 

  • Ένας δευτερεύον “Hadamard transform” που εκτελείται στους συντελεστές του “DC”, του  κυρίως τμηματικού μετασχηματισμού που εκτελούνται στους χρωματικούς συντελεστές DC (καθώς και φωτεινότητας σε ειδικές περιπτώσεις) έτσι ώστε να επιτυγχάνεται αποδοτικότερη συμπίεση σε λείες περιοχές

 

2.4.6 – Τεχνική κβαντισμένου σχεδιασμού (quantization design):

 

  • Λογαριθμικά βήματα ελέγχου μεγέθους για ευκολότερη διαχείριση ρυθμού δεδομένων απο τους κωδικοποιητές και κλιμάκωση αντίστροφου κβαντισμού (inverse-quantization scaling)
  • Κβαντισμός προσαρμοσμένης συχνότητας κλιμάκωσης πινάκων (Frequency-customized quantization scaling matrices) που επιλέγονται από τον κωδικοποιητή για βελτιστοποίηση κβαντισμού βασισμένου σε κριτήρια αντίληψης (perceptual-based quantization optimization)

 

Σχήμα 1 – Αναπαράσταση βημάτων αποκωδικοποίησης / κωδικοποίησης του H.264

 

2.5 – Προφίλ του Προτύπου H.264

 

Το πρότυπο H.264 ορίζει 17 σύνολα χαρακτηριστικών, τα οποία συνηθως συναντώνται εως προφιλ (profiles) και στοχεύουν κυριώς σε συγκεκριμένες κατηγορίες εφαρμογών:

 

Constrained Baseline Profile (CBP): Αρχικά αναυπτύχθηκε για εφαρμογές χαμηλού κόστους όπως τηλεσυνδιασκέψεις και χρήση σε κινητές επικοινωνίες. Αντιστοιχεί στο υποσύνολο των χαρακτηριστικών που είναι κοινά μεταξύ των προφιλ Baseline, Main, και High Profile που περιγράφονται παρακάτω.

 

Baseline Profile (BP): Το προφιλ αυτό στοχεύει επίσης σε εφαρμογές χαμηλού κόστους που απαιτούν επιπλέον ευρωστία απώλεια δεδομένων και γίνεται χρήση και αυτού σε κινητές εφαρμογές και τηλεσυνδιασκέψεις. Αυτό το προφίλ περιλαμβάνει όλα τα χαρακτηριστικά που υποστηρίζονται στο Constrained Baseline Profile, με επιπλέον 3 χαρακτηριστικά που μπορούν να μειώσουν την ευρωστία δεδομένων (robustness) (ή άλλες απαιτήσεις όπως εφαρμογές video με χαμηλό χρόνο καθυστέρησης και πλοήγηση πολλαπλών σημείων). Η σημαντηκότητα του προφιλ αυτού έχει μειωθεί μετά τον ορισμό του Constrained Baseline Profile το 2009. Όλες η ροές δεδομένων του Constrained Baseline Profile θεωρούνται και αυτές ροές του Baseline Profile καθώς μοιράζονται την ίδια τιμή κωδικού αναγνωρίσης

 

Main Profile (MP): Το προφιλ αυτό χρησιμοποιείται κυρίως σε εφαρμογές ψηφιακών τηλεοπτικών μεταδόσεων (DVB) με χρήση του φορμά MPEG-4 όπως αυτό ορίζεται στο πρύτυπο DVB. Ωστόσο δεν χρησιμοποιείται συνήθως σε μεταδόσεις τηλεόρασης υψηλής ευκρίνειας (HDTV), καθώς αναπτύχθηκε μετέπειτα το High Profile το 2004 για χρήση στις περιπτώσεις εφαρμογών σαν αυτή.

 

Extended Profile (XP): Προορίζεται για χρήση σε εφαρμογές δικτυακού video, καθώς το προφιλ αυτό έχει δυνατήτες υψηλής συμπίεσης και ορισμένα επιπλεόν χαρακτηριστικά για απώλεια δεδομένων, αναξιοπιστία καναλιού μετάδοσης καθώς και σε περίπτωση εναλλαγής των πηγών στους παροχείς video.  

 

High Profile (HiP): Το βασικό προφιλ για εφαρμογές μεταδόσεων και οπτικών δίσκων, συγκεκριμένα για τηλεοπτικά προγράματα υψηλής ευκρίνιας (HDTV) (π.χ. το πορφιλ αυτο υοθετήθηκε από to φορματ οπτικών δίσκων Blue-ray και το πρότυπο DVB για τηλεοπτικές μεταδόσεις υψηλής ευκρίνιας)

 

High 10 Profile (Hi10P): Το προφιλ αυτό υπερβαίνει τις δυνατότες των εμπορικών συσκευών αναπαραγωγής, χτίζοντας πάνω στο ήδη υπάρχον High Profile, δίνοντας επιπλέον υποστήριξη για χρήση δειγμάτων των 10bit που αναπαριστά την ακρίβεια αποκωδικοποίησης της εικόνας.

 

High 4:2:2 Profile (Hi422P): Αρχικά στόχευε στην χρήση για επαγγελματικές εφαρμογές που χρησιμοποιούσουν πεπλεγμένο video, χτίζοντας πάνω στο ήδη υπάρχον High 10 Profile, υποστηρίζοντας το φορμάτ χρωματικής δειγματοληψίας 4:2:2  ενώ παράλληλα κάνει επίσης χρήση 10bit δειγμάτων ακρίβιας αποκωδικοποιημένης εικόνας.

 

High 4:4:4 Predictive Profile (Hi444PP): Το προφίλ αυτό δομείται στο προαναφερθέν Hi422P προφιλ, υποστηρίζονυας 4:4:4 χρωματική δειγματοληψία, μεχρι και 14 bit ανα δείγμα, επιπλέον υποστηρίζοντας αρκετά αποδοτικές μη-απωλεστικές κωδικοποιήσεις περιοχής καθώς και κωδικοποίηση της εικόνας σαν 3 ξεχωριστές χρωματικούς πίνακες.

 

Για χρήση ψηφιακές φορητών καμερών, επεξεργασία, μονταζ καθώς και επαγγελματικές εφαρμογές, το πρότυπο H.264 εμπεριέχει τέσσερα επιπλέον υπο-προφιλ, οπου χαρακτηρζίονται σαν υποσύνολα των αντίστοιχων βασικών προφιλ:

 

High 10 Intra Profile: Το High 10 Profile περιορίζεται για εσωτερική χρήση (constrained to all-Intra use).

 

High 4:2:2 Intra Profile: Το High 4:2:2 Profile περιορίζεται για εσωτερική χρήση (constrained to all-Intra use).

 

High 4:4:4 Intra Profile: Το High 4:4:4 Profile περιορίζεται για εσωτερική χρήση (constrained to all-Intra use).

 

CAVLC 4:4:4 Intra Profile: Το High 4:4:4 Profile περιορίζεται για εσωτερική χρήση και την CAVLC κωδικοποίηση εντροπίας (π.χ. δεν υποστηρίζει CABAC).

 

Σαν αποτέλεσμα της κλιμακωτης κωδικοποίησης video (Scalable Video Decoding SVC), το πρότυπο εμπεριέχει τρία επιτπλέον προφιλ κλιμάκωσης, το ποία ορίζονται σαν συνδιασμό του H.264/AVC για το κυριώς επίπεδο (τα οποία αναγνωρίζονται μέσω του 2ου γράμματος στο όνομα του προφιλ) καθώς και το σύνολο το εργαλείων που επιτυγχάνουν την κλιμάκωση αυτη καθεαυτή όπως αναφέρονται παρακάτω:

 

Scalable Baseline Profile: Αρχικά στόχευε κυιρώς σε χρήση τηλεσυνδιασκέψεων, κινητών επικοινωνίων και συστήματα παρακολούθησης, το προφιλ αυτό χτίστηκε πάνω στην περιορισμένη έκδοση του H.264/AVC High Profile όπου το πρότυπο αυτό πρέπει να ακολουθεί.

 

Scalable High Intra Profile: Σχεδιάστηκε για χρήση κυρίως σε εμπορικές εφαρμογές προϊόντων και το προφίλ αυτό αποτελεί το προαναφερθέν  Scalable Baseline Profile για κάθε ειδική χρήση

 

Σαν άποτέλεσμα της ανάπτυξης του προτύπου κωδικοποίησης video πολλαπλών λήψεων (Multiview Video Coding MVC), αυτό εμπεριέχει δύο επιμέρους υπο-προφίλ:

 

Stereo High Profile: Το προφίλ αυτό στοχεύει κυρίως σε εφαρμογές στερεοσκοπικής τρισδιάστατης απεικόνισης (Stereoscopic 3D Video) και συνδυάζει τα εργαλεία που παρέχει το High Profile καθώς επίσης και την ικανότητα πρόβλεψης των επιμέρους λήψεων που παρέχει το πρότυπο MVC

 

Multiview High Profile: Το προφίλ αυτό υποστηρίζει δύο ή περισσοτέρων επιπλέον γωνιών λήψης κάνοντας χρήση της χρονικής πρόβλεψης εικόνας καθώς και την πρόβλεψης πλάνου λήψεως του MVC. Το μειονέκτημα της είναι ότι δεν υποστηρίζει εικόνες πεδίου και κωδικοποίηση macroblock-adaptive frame-field.

 

Πίνακας 2 – Τεχνικές που χρησιμοποιεί κάθε επιμέρους προφίλ του H.264

2.6 – Επίπεδα (Levels)

Σαν όρος που έχει χρησιμοποιηθεί κατά την ανάπτυξη του προτύπου, το “επίπεδο” (level) αποτελεί ένα σύνολο περιορισμών που περιγράφουν την ελάχιστη απαίτηση απόδοσης της αποκωδικοποίησης που εκτελεί ένα συγκεκριμένο προφίλ. Για παράδειγμα το επίπεδο υποστήριξης σε ένα προφίλ θα καθορίσει την μέγιστη ανάλυση εικόνας, ρυθμό καρέ (frame rate), και έναν ρυθμό μετάδοσης που δύναται να χρησιμοποιήσει ο αποκωδικοποιητής Όταν αυτός υπακούει σε ένα συγκεκριμένο επίπεδο των χαρακτηριστικών αυτών θεωρούμε ότι είναι επίσης σε θέση να αποκωδικοποιήσει ροές δεδομένων (bitstreams) του επιπέδου αυτού και όλων των χαμηλότερων επιπέδων.

 

2.7 – Προσωρινή Αποθήκευση Δεδομένων Εικόνας (Decoded Picture Buffering)

Εικόνες που έχουν αποκωδικοποιηθεί πρωτίστως από το πρότυπο H.264/AVC χρησιμοποιούνται για την πρόβλεψη δειγμάτων σε άλλες εικόνες. Αυτό επιτρέπει στον κωδικοποιητή να κάνει εύστοχες αποφάσεις όσο αναφορά τον καλύτερο τρόπο κωδικοποίησης μιας εικόνας. Στον αποκωδικοποιητή, οι εικόνες αυτές αποθηκεύονται σε μια εικονική προσωρνή μνήμη (virtual decoded picture buffer (DPB)). Η μέγιστη χωριτικότητα του DPB αποτελείται απο την μέγιστο αριθμό καρέ (ή ζευγάρια πεδίων), όπως φαίνονται στον παραπάνω πίνακα στην δεξία στήλη. Μπορούμε να τα υπολογίσσουμε με την παρακάτω σχέση:

 

Min(Floor(MaxDpbMbs / (PicWidthInMbs * FrameHeightInMbs)), 16)

 

Το μέγεθος MaxDpbMbs αποτελεί μια σταθερά που παρέχεται απο τον παρακάτω πίνακα συναρτήσει βαθμωτών τιμών. Τα PicWidthlnMbs και το FrameHeightlnMbs αντιπροσωπεύουν το πλάτος και μήκος του κάθε καρέ του ακοκωδικοποιημένου video, εκφρασμένο σε μονάδες macroblcok (με στρογγυλοποιήση σε ακέραιες τιμές, υπολόγισμός περικοπής εικόνας (cropping) καθώς και ταίριασμα macroblock όταν υπάρχει ανάγκη). Η παραπάνω σχέση περιγράφεται στα τμήματα A.3.1.h και Α.3.2.f της 2009 έκδοσης του προτύπου αυτού.

Επίπεδο 1 1b 1.1 1.2 1.3 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 5 5.1
MaxDpbMbs

 

Για παράδειγμα, για την τηλεόραση υψηλής ευκρίνιας (HDTV) αποτελείται απο 1920 δείγματα  οριζοντίως (PicWidthlnMbs = 120) και 1080 καθέτως (FrameHightilnMbs = 68), ένας κωδικοποιητής επιπέδου 4 έχει μέγιστη DPB  αποθηκευτική ικανότητα Floor (32768/(120*68)) = 4 καρέ (ή 8 πεδία) όταν γίνεται κωδικοποίηση με την μικρότερη παράμετρο περικοπής (cropping). Έτσι λοιπόν, η τιμή 4 στις παρενθέσεις στην δεξιά στήλη του πίνακα στο επίπεδο 4, αναφέρεται στην 1920×1080 ανάλυση εικόνας.

 

Είναι σημαντικό να υπογραμμίσουμε ότι η παρούσα εικόνας που αποκωδικοποιείται δεν συμπεριλαμβάνεται στον υπολογισμό πληρότητας DPB (εκτός και εάν ο κωδικοποιητής υποδεικνύει την αποθήκευση του σαν αναφορά για την αποκωδικοποίηση άλλων εικόνων ή για προβολή με καθυστέρηση).  Έτσι λοιπόν είναι αναγκαίο ο αποκωδικοποιητής να έχει αρκετή μνήμη έτσι ώστε να διαχειρίζεται τουλάχιστον ένα καρέ (τουλάχιστον) ή περισσότερα από την μέγιστη χωρητικότητα του DPB όπως υπολογίσθηκε παραπάνω.

 

2.8 – Εκδόσεις

 

Οι εκδόσεις του προτύπου H.264/AVC περιλαμβάνουν τις ακόλουθες ολοκληρωμένες αναθεωρήσεις, διορθώσεις και τροποποιήσεις (οι ημερομηνίες είναι τελικές για την ITU-T, καθώς οι ημερομηνίες της τελική επικύρωση εως “Διεθνές Προτύπου” σύμφωνα με την ISO/IEC διαφέρουν και συνήθως γίνονται λίγο καιρό μετά στις πιο πολλές περιπτώσεις). Κάθε έκδοση αναφέρεται στις αλλαγές που γίναν συναρτήσι της προηγούμενης έκδοσης. Οι γραμμοσκιασμένες εκδόσεις (versions) έχουν εκδοθεί ήδη (ή ενδέχεται να εκδοθούν):

 

  • Version 1: (Μάιος 2003) Η πρώτη έκδοση του H.264/AVC που εκδόθηκε εμπεριέχοντας τα προφιλ Baseline, Extended, και Main.
  • Version 2: (Μάιος 2004) Διορθωτική έκδοση που εμπεριέχει μικρές βελτιώσεις.
  • Version 3: (Μάιος 2005) Βασική προσθήκη στο H.264/AVC που αποτελείται απο βασικές βελτιώσεις παρέχοντας τα Fidelity Range Extensions (FRExt) τα οποία εμπεριέχουν τα προφιλ High, High 10, High 4:2:2, και High 4:4:4
  • Version 4: (Σεπτέμβριος 2005) Διορθωτική έκδοση που αποτελείται απο μικρές αλλαγές βάζοντας προσθέτοντας τρεις δείκτες αναλογίας εικόνας (aspect ratio indicators)
  • Version 5: (Ιούνιος 2006) Βελτιωτική έκδοση που περιλαμβάνει την αφαίρεση του προφιλ High 4:4:4
  • Version 6: (Ιούνιος 2006) Βελτιωτική έκδοση που περιλαμβάνει επεκτάσεις όπως υποστήριξη εκτεταμένης γκάμας κωδικοποίησης (extended-gamut color space support) μαζί με τα προαναφερθέν aspect ratio indicators κατα την ISO/IEC.
  • Version 7: (Απρίλιος 2007) Βελτιωτική έκδοση που αναφέρεται στην προσθήκη των προφιλ High 4:4:4 Predictive καθώς και τέσσερα επιπλέον Intra-only προφιλ (High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra και CAVLC 4:4:4 Intra).
  • Version 8: (Νοέμβρης 2007) Έκδοση βασικής προσθήκης στο H.264/AVC εμπεριέχοντας την  βελτιωτική έκδοση για το Scalable Video Coding (SVC) περιλαμβάνοντας τα προφιλ Scalable Baseline, Scalable High καθώς και το Scalable High Intra.
  • Version 9: (Ιανουάριος 2009) Διορθωτική έκδοση που περιλαμβάνει ορισμένες μικρές αλλαγές.
  • Version 10: (Μάρτιος 2009) Έκδοση βασικής προσθήκης που περιλμβάνει τον ορισμό ενός νέου προφιλ (το Constrained Baseline profile) με μόνο ένα υποσύνολο δυνατοτήτων που υποστηρίζονται σε προηγούμενα αντίστοιχα προφιλ.
  • Version 11: (Μάρτιος 2009) Έκδοση βασικής προσθήκης στο H.264/AVC που περιλαμβάνει την διορθωτική έκδοση όσο αναφορά το Multiview Video Coding (MVC) extension, με επιπλεόν το Multiview High προφιλ.
  • Version 12: (Μάρτιος 2010) Έκδοση βασικής προσθήκης που περιλμβάνει τον ορισμό ενός νέου MVC profile (το Stereo High profile) για κωδικοποίηση video με δύο γωνίες λήψης, με υποστήριξη εργαλείων για πεπλεγμένη κωδικοποίηση και ορίζοντας ένα επιπλεόν μύνημα SEI (η πληροφορία συσχέτισης των καρέ / frame packing arrangement SEI message).
  • Version 13: (Μάρτιος 2010) Διορθωτική έκδοση που περιλαμβάνει ορισμένες μικρές αλλαγές.

 

2.9 – Απο/κωδικοποιητές προτύπου H.264

 

Οι υλοποιήσεις του AVC/H.264  είναι ήδη διαθέσιμες όπως φαίνονται παρακάτω ονομαστικά: x264, Nero, Apple, Sorenson, Elecard, Moonlight, VSS, mpegable, Envivio, Hdot264 (binary), DSPR, JM (reference software) (binary), ffmpeg, Philips, FastVDO, Skal, Sony καθώς και αρκετές ακόμη.

 

Κωδικοποιητές:

 

  • x264: Ο πρώτος δημόσια διαθέσιμος που εμπεριείχε τον High Profile encoder, ανοιχτής φιλοσοφίας (GPL), διαθέσιμος για VFW: Το x264vfw, ffdshow (επέκταση .avi), σύνταξη εντολής: x264cli (επεκτάσεις .mp4, .mkv, raw), mencoder (επεκτάσεις raw, .avi) (Doom9’s MeGUI) ή ffmpeg x264 που υποστηρίζει 2pass, CABAC, Loop, πολλαπλά B-Frames, B-References, πολλαπλά Reference Frames, 4×4 P-Frame, 8×8 B-Frame Blocksizes, anamorphic signalling and High Profile: 8×8 dct and intra prediction, lossless and custom quant matrices
  • NeroDigital AVC: χρησιμοποιείται στο Nero Recode2 με επεκτάση .mp4 . Η υλοποίηση αυτή υποστηρίζει 2pass, CABAC, (adaptive) Loop, πολλαπλά B-Frames, πολλαπλά Reference Frames, σταθμισμένη πρόβλεψη (weighted prediction), 8×8 P-Frame Blocksizes, 16×16 B-Frame Blocksizes, Adaptive Quant. (Psy High)
  • Sorenson: χρησιμοποιείται στο Sorenson Squeeze 4 με επέκταση .mp4. Υποστηρίζει 2pass, max 2 B-Frames, B-References, Loop και multiple Slices
  • Apple: χρησιμοποιείται στο Quicktime 7 με επέκταση.mp4, .3gp και .mov. Υποστηρίζει 2pass, max 1 B-frame, Loop (0,0), P8x8,B8x8,I4x4, Adapt. Quant, 5 Slices, χωρίς CABAC, χωρίς Weighted Pred., χωρίς multi Ref.
  • JM: Το λογισμκό AVC Reference προσφέρει στην έκδοση v9.3 Main και High Profile. Υποστηρίζει  B/SP-Frames, CABAC, Loop Filter, 4×4 Blocksizes, πολλαπλά Reference Frames, Adaptive Quant, Error Resilience, RDO, Lossless Coding, Custom Quants, Rate Control.
  • Hdot264: ανοιχτού λογισμικού (GPL) της έκδοσης VFW του λογισμικού τεκμηρίωσης του doom9 μέλος charact3r, το οποίο βασίζεται στο ήδη παλιό reference (JM 4.0c)
  • VSS: δωρεάν δοκιμαστική έκδοση του κωδικοποιητής VFW (5 μέρες ελεύθερης χρήσης), βασισμένο στον κωδικοποιητή αναφοράς.
  • Elecard: Χρησιμοποιείται στον Elecard Mobile Converter, με επέκταση .mp4 και στον κωδικοποητή MainConcept’s v2, με επέκταση .264 και .mpg PS/TS

 

Δημόσια μη διαθέσιμοι πλέον:

 

 

  • Moonlight: Χρησιμοποιείται στον OneClick Compressor v1.1 και PowerEncoder της Cyberlink, επέκταση .mpg . Το Moonlight υποστηρίζει 1pass (VBR/CBR/Fixed Quants), CABAC, Loop, 2 B-Frames, 8×8 P-Frame Sizes, Adapt. Quant, PAR, Interlacing
  • MainConcept: Γινόνταν χρήση του στην v1 encoder (προσθέτει υδατογράφημα), επέκταση .264 και .mpg. Υποστηρίζει 1pass (CBR/VBR/fixed Quants), P-Frame Reorder, CABAC, Loop, Multiple B-Vops, Multiple Ref, 4×4 P-Frame Sizes, PAR, RDO
  • mpegable: Ήταν διαθέσιμος δημόσια στο παρελθόν με την επωνυμία VFW Encoder. Δεν μπορεί να χειριστεί όμως το YV12. Ο mpegable υποστηρίζει 1pass (fixed quants) κάνει χρήση των P-Frames μόνο, 8×8 P-Frame Blocksizes, CAVLC, Loop
  • Envivio: Χρησιμοποιείται στον 4Coder, επέκταση .mp4

 

 

Αποκωδικοποιητές:

 

 

  • ffmpeg: Ανοιχτού κώδικα (LGPL), χρησιμοποιήθηκε στο ffdshow (VFW και αποκωδικοποιητή DShow), mplayer και VideoLAN. Υποστηρίζει B-Frames, B-References, CABAC, Loop, Weighted Prediction and High Profile (8×8 dct and intra prediction, lossless)
  • CoreAVC
  • Apple: Αποκωδικοποίηση AVC με χρήση του Quicktime 7, υποστηρίζει .mp4/.mov . Συνήθως έχει αργές επιδόσεις. Υποστηρίζει μόνο ένα B-Frame, CABAC, Loop όχι όμως μικτές αναφορές (mixed references), όχι πολλαπλά B-frames και interlacing.
  • NeroDigital AVC: Ο αποκωδικποιητής DShow και .mp4 Parser συναντώνται στο Recode2 και υποστηρίζει τα Main and High Profile.
  • VSS: Η δοκιμαστική έκδοση του VFW Decoder (περιοσμό χρήσης 5 ημερών) και ο DShow Decoder (περιοσμό χρήσης 5 ημερών). Το VSS DShow υποστηρίζει επεκτάσεις .avi (with VSSH και H264 fourcc), CABAC, Loop, B-Frames.
  • Elecard: Διαθέσιμο στον Elecard’s MPEG Player και κωδικοποιητή MainConcept’s v2.
  • Envivio: Διαθέσιμο με περιορισμούς, ο αποκωδικοποιητής AVC DShow ονομάζεται EnvivioTV, χειρίζεται το AVC στο .mp4 (μετά την έκδοση 2.0).
  • Philips: DShow AVC αποκωδικοποιητές είναι ελεύθερα διαθέσιμοι στον AVC Alliance player (χειρίζεται μόνο αυτούσιο AVC).
  • FastVDO: Με περιορισμό χρόνου (5 δυετερολέπτων) ο αποκωδικοποιητής High Profile DShow δεν είναι πλέον δημοσίως διαθέσιμος.
  • Moonlight: DShow decoder/Parser χειρίζεται το AVC στο .mpg, .mp4 και .264 που είναι διαθέσιμο στον Moonlight’s MPEG Player v3.0 και υποστηρίζει τα Main and High Profile
  • MainConcept: Η αρχική v1 έκδοση διέθεται δωρεάν τον αποκωδικποιτή DShow AVC (εμφανίζει υδατογράφημα) και Parser handling AVC στο .mpg PS/TS.
  • mpegable: Διέθετε για περιορισμένο διάστημα έναν δωρεάν αποκωδικοποιτή VFW (με εφαρμοργή και στο DShow), υποστηρίζει και .avi (με DAVC fourcc).
  • Basic AVC Decoder: Στην C, για χρήση σε ακαδημαική εργασία
  • Pegasus: Όχι και τόσο συμβατός αποκωδικοποιητής DShow AVC

 

 

2.10 – Απο/Κωδικποίηση βασισμένο στο υλικό (Hardware-based)

Γενικά η απο/κωδικοποιήση του ένος video σε μορφή H.264 απαιτεί ένα σημαντικό πόσο επεξεργαστικής ισχύος, οι υλοποιήσεις λογισμικού οι οιποίες εκτελούνται σε επεξεργαστική γενικής χρήσης είναι γενικά αργές, ειδικά όταν έχουμε να κάνουμε με video υψηλής πιστότητας (HD). Για την μείωση δέσμευσης του επεξεργαστή ή για κωδικοποίηση πραγματικού χρόνου, υπάρχει ανάγκη χρήσης ειδικευμένου hardware, είτε για τον αποδοτική ολοκλήρωση της διαδικασίας τους απο/κωδικοποίησης είτε για την επιβοηθούμενη επιτάχυνση σε ένα περιβάλον ελεγχόμενο απο τον επεξεργαστή (CPU-controlled environment).

 

Για την κωδικοποίηση video H.264 μπορούμε να κάνουμε χρήση ένος κυκλώματος ASIC ή FPGA. Το FPGA αποτελεί ένα κύκλωμα γενικής χρήσης και για την χρήση του έως ειδικευμένου κωδικοποιητή H.264 ο κατασκευαστής πρέπει να το παραμετροποίησει για την εκάστοτε εφαρμογή. Ένας κωδικοποιητής πλήρους ανάλυσης (fullHD H.264 encoder) μπορεί κάλλιστα να υλοποιηθεί σε ένα χαμηλού κόστους κυκλώματος FPGA το 2009 (High profile, level 4.1, 1080p, 30fps). Οι κωδικοκποιητές με δυνατότητα χρήσης στο H.264 video είναι κυκλώματα  ASIC τα οποία είναι διαθέσμιμα απο πολλές εταιρίες, ενώ τα πνευματικά δικαιώματα του βασικού τους σχεδιασμού προσαρτώνται σε μονο ορισμένες απο αυτές. Σε αρκετές περιπτώσεις οι κατασκευαστές προσφέρουν προϊοντα με συνδυασμό κυκλωμάτων FPGA και ASIC