Παρουσιάζουμε το σχεδιασμό, την υλοποίηση και την ενσωμάτωση ενός πολυνηματικού
μηχανισμού συνδιάσκεψης πολλαπλών χρηστών με χρήση SSRC πολυπλεξίας, καθώς και
ενός μηχανισμού αναμετάδοσης RTP πακέτων βίντεο, στο λογισμικό ανοιχτού κώ-δικα
BareSIP. Επειδή η αρχική σχεδίαση του BareSIP δεν υποστηρίζει την ταυτόχρονη
συμμετοχή πολλαπλών χρηστών, για τη δημιουργία του μηχανισμού συνδιάσκεψης
χρησιμοποιούμε αρχικά έναν εξυπηρετητή. Ο εξυπηρετητής αυτός, πολυπλέκει τις
ροές μέσων των διαφόρων χρηστών με βάση το πεδίο SSRC της επικεφαλίδας των RTP
πακέτων και στέλνει μια ροή για κάθε τύπο μέσου στον BareSIP πελάτη. Στον
BareSIP πελάτη, προκειμένου να πραγματοποιείται συνδιάσκεψη με υψηλή απόδοση,
αναπτύ-ξαμε έναν πολυνηματικό μηχανισμό ο οποίος αποπολυπλέκει την εισερχόμενη
ροή μέ-σων βάσει του πεδίου SSRC του κάθε συμμετέχοντα και αναθέτει την
εξυπηρέτηση του καθενός σε αντίστοιχα νήματα που τρέχουν παράλληλα. Ο
μηχανισμός αυτός σχεδιά-στηκε με τρόπο τέτοιο ώστε να απαιτούνται μόνο δύο
θύρες για τις εισερχόμενες ροές μέσων, ενώ για μια ταυτόχρονη συνύπαρξη Ν
χρηστών να απαιτείται μόνο ένα στιγμι-ότυπο του κωδικοποιητή και Ν-1
στιγμιότυπα του αποκωδικοποιητή. Επιπλέον, χρησι-μοποιώντας την επέκταση
κλιμακωτής κωδικοποίησης βίντεο (Scalable Video Coding – SVC) του προτύπου
συμπίεσης H.264/AVC, η οποία προσφέρει πολλαπλά επίπεδα πιστότητας μέσω μιας
πυραμιδικής ιεραρχίας (ροές δεδομένων επιπέδου βάσης – ροές δεδομένων
βελτιωτικών επιπέδων), παρουσιάζουμε ένα μοντέλο επικοινωνίας υψηλής
ανθεκτικότητας ανάμεσα στον πομπό και το δέκτη, χρησιμοποιώντας αναμετάδοση των
RTP πακέτων βίντεο. Το μοντέλο αυτό φροντίζει για την άμεση αποκατάσταση απολε-
σθέντων RTP πακέτων βίντεο επιπέδου βάσης, ώστε η ρουτίνα αποκωδικοποίησης των
πακέτων βίντεο επιπέδου βάσης να πραγματοποιείται χωρίς διακοπές και καθυστε-
ρήσεις. Δημιουργούμε έναν πομπό ο οποίος διατηρεί διπλότυπα RTP πακέτων βίντεο
επιπέδου βάσης, προκειμένου να μπορεί να αναμεταδώσει εκείνα τα οποία ζητάει ο
δέκτης. Στην πλευρά του δέκτη, υλοποιούμε έναν αλγόριθμο ο οποίος εντοπίζει τα
απο-λεσθέντα πακέτα βάσης και στέλνει αιτήματα αναμετάδοσης μέσω RTCP NACK πακέ-
των, προκειμένου να ανακτήσει άμεσα όλη την πληροφορία του βασικού επιπέδου και
να διατηρήσει την ακεραιότητα της ροής δεδομένων του. Ο
αλγόριθμος αυτός, τέλος, φροντίζει να λάβει τις κατάλληλες αποφάσεις ανάλογα με
τις επιπτώσεις που θα είχαν οι απώλειες στο σύστημα. Ως προς τις μετρήσεις που
πραγματοποιήσαμε, για το μηχα-νισμό συνδιάσκεψης μελετήσαμε την καθυστέρηση που
προκύπτει σε επίπεδο μετά-δοσης, κωδικοποίησης και αποκωδικοποίησης ήχου και
βίντεο, καθώς αυξάνει ο αριθ-μός των συμμετεχόντων, αλλά και τις διαφορές που
παρουσιάζονται αν τροποποι-ήσουμε το packet time και την καθυστέρηση στους
jitter buffers. Από τις μετρήσεις αυτές δείξαμε ότι η συνολική καθυστέρηση του
ήχου παραμένει σχεδόν σταθερή, ανεξάρτητα από την αύξηση των συμμετεχόντων, ενώ
αντίστοιχα για το βίντεο παρατηρούμε μια μικρή αύξηση της τάξης των 2-4 msec.
Τέλος, για το μηχανισμό αναμετάδοσης πακέτων βίντεο, παρουσιάζουμε και
συγκρίνουμε το ποσοστό των ωφέλιμων frames (effective frame rate) και των
ωφέλιμων bytes στην έξοδο, τόσο με τη χρήση του μηχανισμού όσο και χωρίς αυτόν
και παρατηρούμε ότι η απόδοση με το μηχανισμό αναμετάδοσης είναι σαφώς
καλύτερη, ειδικά σε περιπτώσεις υψηλών απωλειών, όπου φαίνεται να είναι 265%
καλύτερη από αυτή χωρίς το μηχανισμό.
(EL)
We present the design, the implementation and the integration of a
multi-threaded mechanism for multi-user conference using SRC multiplexing and
an RTP video packet retransmission mechanism, in open source software BareSIP.
Due to the fact that the default design of BareSIP does not support the
simultaneous participation of multiple users, in order to set up the conference
mechanism, we initially use a server. This server multiplexes the media streams
of the different users based on the SSRC field of the RTP header of the packets
and sends one stream for each media type to every BareSIP client. In BareSIP
client, in order the conference to take place with high efficiency, we
developed a multi-threaded mechanism that demultiplexes the incoming media
stream based on the SSRC field of each participant and assigns the service of
each one to corresponding threads that are running in parallel. This mechanism
was designed in such a way as to require only two ports for the incoming media
streams and, for the simultaneous coexistence of N users, to require only one
encoding and N-1 decoding instances. Additionally, using the Scalable Video
Coding extension of H.264/AVC video compression standard, which offers multiple
levels of fidelity through a pyramidal hierarchy (base layer data streams –
enhancement layer data streams), we present a communication model of high
robustness between the transmitter and the receiver, using RTP video packet
retransmission. This model ensures for the immediate restoration of lost base
layer RTP video packets, so that the decoding routine of base layer video
packets will take place without interruptions and delays. We create a
transmitter that maintains duplicates of base layer RTP video packets, in order
to be able to retransmit those that are requested by the receiver. At the
receiver’s side, we implement an algorithm that detects the base layer packets
that were lost and requests for their retransmission, using RTCP NACK packets,
in order to instantly retrieve all the information of the base layer and to
maintain the integrity of its data flow. This algorithm, finally, ensures to
take the appropriate decisions depending on the impact that the losses will
have in the system. As for the results obtained by the measurements we made,
for the conference mechanism we present the delay that results in audio/video
relaying, coding and decoding level, as the number of participants is
increasing, but also the differences that appear by modifying the packet time
and the jitter buffer delay. From these measurements we showed that the total
sound delay remains almost constant, regardless of the increase of the number
of the participants, while for the total video delay there is a small increase
of 2-4 msec. Finally, for the video packet retransmission mechanism, we present
and compare the percentage of the useful frames (effective frame rate) and
bytes (effective byte rate) that appear in the output, when using and when not
using the mechanism, and we show that the performance in the case we are using
the retransmission mechanism is clearly better, especially in cases of high
losses, which seems to be 265% better than the performance in the case we are
not using the retransmission mechanism.
(EN)
