FMUSER Wirless Μετάδοση βίντεο και ήχου πιο εύκολα!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Αφρικανικά
sq.fmuser.org -> Αλβανικά
ar.fmuser.org -> Αραβικά
hy.fmuser.org -> Αρμενίων
az.fmuser.org -> Αζερμπαϊτζάν
eu.fmuser.org -> Βάσκων
be.fmuser.org -> Λευκορωσικά
bg.fmuser.org -> Βουλγαρικά
ca.fmuser.org -> Καταλανικά
zh-CN.fmuser.org -> Κινέζικα (απλοποιημένα)
zh-TW.fmuser.org -> Κινέζικα (Παραδοσιακά)
hr.fmuser.org -> Κροατικά
cs.fmuser.org -> Τσέχικα
da.fmuser.org -> Δανικά
nl.fmuser.org -> Ολλανδικά
et.fmuser.org -> Εσθονικά
tl.fmuser.org -> Φιλιππινέζικα
fi.fmuser.org -> Φινλανδικά
fr.fmuser.org -> Γαλλικά
gl.fmuser.org -> Γαλικιανά
ka.fmuser.org -> Γεωργιανά
de.fmuser.org -> Γερμανικά
el.fmuser.org -> Ελληνική
ht.fmuser.org -> Κρεόλ της Αϊτής
iw.fmuser.org -> Εβραϊκά
hi.fmuser.org -> Χίντι
hu.fmuser.org -> Ουγγρική
is.fmuser.org -> Ισλανδικά
id.fmuser.org -> Ινδονησιακά
ga.fmuser.org -> Ιρλανδικά
it.fmuser.org -> Ιταλικά
ja.fmuser.org -> Ιαπωνικά
ko.fmuser.org -> Κορεάτικα
lv.fmuser.org -> Λετονικά
lt.fmuser.org -> Λιθουανικά
mk.fmuser.org -> Μακεδόνας
ms.fmuser.org -> Μαλαισιανά
mt.fmuser.org -> Μαλτέζικα
no.fmuser.org -> Νορβηγική
fa.fmuser.org -> Περσικά
pl.fmuser.org -> Πολωνικά
pt.fmuser.org -> Πορτογαλικά
ro.fmuser.org -> Ρουμανικά
ru.fmuser.org -> Ρωσικά
sr.fmuser.org -> Σέρβικα
sk.fmuser.org -> Σλοβακικά
sl.fmuser.org -> Σλοβένικα
es.fmuser.org -> Ισπανικά
sw.fmuser.org -> Σουαχίλι
sv.fmuser.org -> Σουηδικά
th.fmuser.org -> Ταϊλάνδης
tr.fmuser.org -> Τουρκικά
uk.fmuser.org -> Ουκρανικά
ur.fmuser.org -> Ουρντού
vi.fmuser.org -> Βιετνάμ
cy.fmuser.org -> Ουαλικά
yi.fmuser.org -> Γίντις
κοινά σημεία:
1: Το RTSP RTMP HTTP βρίσκεται στο επίπεδο εφαρμογής.
2: Θεωρητικά, το RTSP rtmphttp μπορεί να χρησιμοποιηθεί για ζωντανή μετάδοση και κατ 'απαίτηση, αλλά το RTSP RTMP χρησιμοποιείται γενικά για ζωντανή μετάδοση και HTTP για κατ' απαίτηση. Το πρωτόκολλο SIP χρησιμοποιήθηκε στη διάσκεψη βίντεο και τώρα αντικαθίσταται βασικά από το RTMP.
διαφορά:
Αντιγράψτε τον κωδικό
1: Http: δηλαδή, πρωτόκολλο μεταφοράς υπερκειμένου (το FTP είναι πρωτόκολλο μεταφοράς αρχείων).
Http: (πρωτόκολλο ροής σε πραγματικό χρόνο), πρωτόκολλο ροής σε πραγματικό χρόνο.
Πρωτόκολλο συντήρησης πινάκων δρομολόγησης πλήρους ονόματος HTTP.
2: Το HTTP επεξεργάζεται όλα τα δεδομένα ως αρχεία. Το πρωτόκολλο HTTP δεν είναι πρωτόκολλο ροής.
Τα RTMP και RTSP είναι πρωτόκολλα μέσων ροής.
3: Το πρωτόκολλο RTMP είναι μια ιδιωτική συμφωνία του adobe, η οποία δεν αποκαλύπτεται πλήρως. Το πρωτόκολλο RTSP και το πρωτόκολλο HTTP είναι κοινές συμφωνίες και έχουν ειδικούς οργανισμούς για τη διατήρησή τους.
4: Το πρωτόκολλο RTMP μεταδίδει γενικά ροή μορφής flv, f4v, το πρωτόκολλο RTSP μεταδίδει γενικά ροή ροής φορμά MP4. Το HTTP δεν έχει συγκεκριμένη ροή.
5: Η μετάδοση RTSP απαιτεί γενικά 2-3 κανάλια, διαχωρισμό εντολών και καναλιών δεδομένων, HTTP και RTMP γενικά μεταφέρουν εντολές και δεδομένα σε ένα κανάλι TCP.
Αντιγράψτε τον κωδικό
Διαφορές μεταξύ RTSP, RTCP και RTP
Αντιγράψτε τον κωδικό
1: Πρωτόκολλο ροής πραγματικού χρόνου RTSP
Ως πρωτόκολλο επιπέδου εφαρμογής, το RTSP παρέχει ένα επεκτάσιμο πλαίσιο, το οποίο επιτρέπει τον έλεγχο και τη συνεχή ροή δεδομένων σε πραγματικό χρόνο. Γενικά, το RTSP είναι ένα πρωτόκολλο αναπαραγωγής μέσων ροής, το οποίο χρησιμοποιείται κυρίως για τον έλεγχο της μετάδοσης δεδομένων με χαρακτηριστικά σε πραγματικό χρόνο, αλλά δεν μεταδίδει τα ίδια τα δεδομένα, αλλά πρέπει να βασίζεται σε ορισμένες υπηρεσίες που παρέχονται από το πρωτόκολλο μεταφοράς χαμηλότερου επιπέδου. Το RTSP μπορεί να παρέχει λειτουργίες όπως αναπαραγωγή, παύση, γρήγορη προώθηση και ούτω καθεξής για ροή πολυμέσων. Είναι υπεύθυνη για τον ορισμό συγκεκριμένων μηνυμάτων ελέγχου, μεθόδων λειτουργίας, κωδικών κατάστασης κ.λπ., και περιγράφει επίσης την αλληλεπίδραση με το RTP (rfc2326).
2: Πρωτόκολλο ελέγχου RTCP
Το πρωτόκολλο ελέγχου RTCP πρέπει να χρησιμοποιείται με το πρωτόκολλο δεδομένων RTP. Όταν μια εφαρμογή ξεκινά μια περίοδο λειτουργίας RTP, θα καταλαμβάνει ταυτόχρονα δύο θύρες, οι οποίες χρησιμοποιούνται από RTP και RTCP αντίστοιχα. Το ίδιο το RTP δεν μπορεί να παρέχει αξιόπιστη εγγύηση για τη διαδοχική μετάδοση πακέτων δεδομένων, ούτε να παρέχει έλεγχο κυκλοφορίας και έλεγχο συμφόρησης, τα οποία όλα συμπληρώνονται από το RTCP. Γενικά, το RTCP θα χρησιμοποιεί τον ίδιο μηχανισμό διανομής με το RTP, θα στέλνει περιοδικά πληροφορίες ελέγχου σε όλα τα μέλη της συνεδρίας. Η εφαρμογή μπορεί να ελέγξει την ποιότητα της υπηρεσίας ή να διαγνώσει την κατάσταση του δικτύου λαμβάνοντας τα δεδομένα, λαμβάνοντας τις σχετικές πληροφορίες των συμμετεχόντων της συνεδρίας, καθώς και την κατάσταση του δικτύου, την πιθανότητα απώλειας πακέτου και άλλες πληροφορίες ανατροφοδότησης.
Η λειτουργία του πρωτοκόλλου RTCP πραγματοποιείται με διαφορετικά διαγράμματα δεδομένων RTCP, τα οποία είναι κυρίως των ακόλουθων τύπων:
SR: η αναφορά αποστολέα αναφέρεται στην εφαρμογή ή το τερματικό που στέλνει αναφορά δεδομένων RTP και ο αποστολέας μπορεί επίσης να είναι ο παραλήπτης. (σταθερός χρόνος διακομιστή που αποστέλλεται στον πελάτη).
RR: οι αναφορές λήψης λήψης. Το λεγόμενο άκρο λήψης αναφέρεται στην εφαρμογή ή το τερματικό που λαμβάνει μόνο αλλά δεν αποστέλλει αναφορές δεδομένων RTP. (ο διακομιστής λαμβάνει την απάντηση που αποστέλλεται από την πλευρά του πελάτη).
SDEs: περιγραφή πηγής, η κύρια λειτουργία είναι να χρησιμεύσει ως φορέας των πληροφοριών αναγνώρισης των μελών συνεδρίας, όπως όνομα χρήστη, διεύθυνση email, αριθμός τηλεφώνου κ.λπ., και επίσης έχει τη λειτουργία της μεταφοράς πληροφοριών ελέγχου συνεδρίας σε μέλη συνεδρίας.
Αντίο: η ειδοποίηση φεύγει. Η κύρια λειτουργία είναι να υποδείξει ότι μία ή περισσότερες πηγές δεν είναι πλέον έγκυρες, δηλαδή, άλλα μέλη στη συνεδρία ειδοποίησης θα αποχωρήσουν από τη συνεδρία.
Εφαρμογή: καθορίζεται από την ίδια την εφαρμογή, επιλύει το πρόβλημα της επεκτασιμότητας RTCP και παρέχει μεγάλη ευελιξία για τους υλοποιητές του πρωτοκόλλου.
3: Πρωτόκολλο δεδομένων RTP
Το πρωτόκολλο δεδομένων RTP είναι υπεύθυνο για τη ροή δεδομένων μέσων πακέτων και τη μετάδοση ροής πολυμέσων σε πραγματικό χρόνο. Κάθε πακέτο δεδομένων RTP αποτελείται από δύο μέρη: κεφαλή και φορτίο. Τα πρώτα 12 bytes της κεφαλής είναι σταθερά, ενώ το φορτίο μπορεί να είναι δεδομένα ήχου ή βίντεο.
Το μέρος που χρησιμοποιείται από το RTP είναι το παιχνίδι. Ο διακομιστής χρησιμοποιεί πρωτόκολλο UDP για τη μετάδοση δεδομένων στον πελάτη. Το RTP προσθέτει μια κεφαλίδα 12 byte (πληροφορίες περιγραφής) στο μπροστινό μέρος της μετάδοσης δεδομένων.
Το RTP πακέτο φόρτωσης σχεδιάζει η μετάδοση δικτύου σε αυτό το χαρτί να βασίζεται σε πρωτόκολλο IP, επομένως η μέγιστη μονάδα μετάδοσης (MTU) είναι 1500 byte. Όταν χρησιμοποιείτε την ιεραρχία πρωτοκόλλου IP / UDP / RTP, αυτό περιλαμβάνει τουλάχιστον 20 byte κεφαλίδας IP, κεφαλίδα UDP 8 byte και κεφαλίδα RTP 12 byte. Έτσι, οι πληροφορίες κεφαλίδας χρειάζονται τουλάχιστον 40 byte και το μέγιστο μέγεθος φορτίου RTP είναι 1460 byte. Για παράδειγμα, πάρτε το H264, εάν τα δεδομένα πλαισίου είναι μεγαλύτερα από 1460, πρέπει να συσκευάζονται σε τεμάχια, στη συνέχεια να αποσυσκευάζονται στον δέκτη και, στη συνέχεια, να συνδυάζονται σε πλαίσιο δεδομένων για αποκωδικοποίηση και αναπαραγωγή.
Αντιγράψτε τον κωδικό
Σε ζωντανή εφαρμογή, τα RTMP και HLS μπορούν βασικά να καλύπτουν όλη την παρακολούθηση πελατών,
Το HLS είναι κυρίως με μεγάλη καθυστέρηση και το RTMP έχει το κύριο πλεονέκτημα σε χαμηλή καθυστέρηση.
1 sc Σενάρια εφαρμογής
Τα σενάρια εφαρμογής με χαμηλή καθυστέρηση περιλαμβάνουν:
Αντιγράψτε τον κωδικό
Διαδραστική ζωντανή μετάδοση: για παράδειγμα, η δημοφιλής άγκυρα ομορφιάς το 2013, το ζωντανό παιχνίδι κ.λπ.
Διάφοροι κεντρικοί υπολογιστές, μέσα ροής διανέμονται στους χρήστες για προβολή. Οι χρήστες μπορούν να συνομιλήσουν με κείμενο και να αλληλεπιδράσουν με τον κεντρικό υπολογιστή.
Βιντεοδιάσκεψη: εάν έχουμε συναδέλφους που ταξιδεύουν στο πεδίο, θα χρησιμοποιήσουμε βιντεοδιάσκεψη για να πραγματοποιήσουμε εσωτερικές συναντήσεις.
Στην πραγματικότητα, δεν έχει σημασία αν η συνάντηση καθυστερήσει για ένα δευτερόλεπτο, γιατί αφού κάποιος άλλος έχει τελειώσει να μιλάει, άλλοι πρέπει να το σκεφτούν,
Η χρονική καθυστέρηση της σκέψης θα είναι επίσης περίπου 1 δευτερόλεπτο. Φυσικά, εάν διαφωνείτε με μια τηλεδιάσκεψη, δεν μπορείτε.
. Άλλο: η παρακολούθηση και η ζωντανή μετάδοση απαιτούν επίσης καθυστέρηση σε ορισμένα μέρη,
Η καθυστέρηση του πρωτοκόλλου RTMP στο Διαδίκτυο μπορεί βασικά να πληροί τις απαιτήσεις.
Αντιγράψτε τον κωδικό
2 、 RTMP και καθυστέρηση
1. Τα χαρακτηριστικά του RTMP είναι τα εξής:
Αντιγράψτε τον κωδικό
1) Η Adobe υποστηρίζει καλά:
Το RTMP είναι στην πραγματικότητα το βιομηχανικό πρότυπο πρωτόκολλο για την παραγωγή κωδικοποιητή, βασικά όλοι οι κωδικοποιητές (κάμερες και ούτω καθεξής) υποστηρίζουν έξοδο RTMP.
Ο λόγος είναι ότι η αγορά υπολογιστών είναι τεράστια, ο υπολογιστής είναι κυρίως παράθυρα και τα προγράμματα περιήγησης παραθύρων υποστηρίζουν βασικά το φλας,
Το Flash υποστηρίζει επίσης πολύ καλά το RTMP.
2) Κατάλληλο για μεγάλο παιχνίδι:
Επειδή το RTMP υποστηρίζει πολύ καλά, μπορεί να επιτύχει ροή αναπαραγωγής RTMP για μεγάλο χρονικό διάστημα και συνεχώς,
Η δοκιμή ήταν ένα εκατομμύριο δευτερόλεπτα ή περισσότερες από 10 ημέρες συνεχούς αναπαραγωγής.
Για εφαρμογές εμπορικών μέσων ροής, η σταθερότητα του πελάτη είναι σίγουρα απαραίτητη, διαφορετικά, οι τελικοί χρήστες δεν μπορούν να δουν πώς να παίξουν;
Ήξερα ότι υπήρχε ένας πελάτης εκπαίδευσης που αρχικά έπαιζε ροές HTTP με παίκτες και έπρεπε να παίξει διαφορετικά αρχεία και πάντα υπήρχε πρόβλημα,
Εάν ο διακομιστής μετατρέπει διαφορετικά αρχεία σε ροή RTMP, ο πελάτης μπορεί να παίζει συνεχώς.
Αφού ο πελάτης πήγε στο πρόγραμμα RTMP, δεν άκουσε ότι ο πελάτης είχε πρόβλημα μετά τη διανομή του από το CDN.
3) Χαμηλή καθυστέρηση:
Το RTMP είναι πολύ καθυστερημένο (1-3 δευτερόλεπτα) από το ιδιωτικό πρωτόκολλο τύπου YY,
Το RTMP είναι χαμηλότερο από την καθυστέρηση ροής HTTP (γενικά περισσότερο από 10 δευτερόλεπτα).
Εφόσον η γενική εφαρμογή ζωντανής μετάδοσης δεν είναι το είδος της τηλεφωνικής συνομιλίας, η καθυστέρηση RTMP είναι αποδεκτή.
Σε γενικές εφαρμογές βιντεοδιάσκεψης, η καθυστέρηση RTMP είναι αποδεκτή επειδή ακούμε άλλους όταν μιλάνε,
Στην πραγματικότητα, η καθυστέρηση ενός δευτερολέπτου δεν έχει σημασία, και πρέπει να το σκεφτούμε (μερικοί άνθρωποι δεν έχουν ακόμη την ταχύτητα επεξεργασίας της CPU τόσο γρήγορα).
4) Αθροιστική καθυστέρηση:
Η τεχνολογία πρέπει να γνωρίζει την αδυναμία. Η αδυναμία του RTMP είναι αθροιστικό σφάλμα, επειδή το RTMP δεν χάνει πακέτα με βάση το TCP.
Έτσι, όταν η κατάσταση του δικτύου είναι κακή, ο διακομιστής θα αποθηκεύει προσωρινά τα πακέτα, γεγονός που οδηγεί στη σωρευτική καθυστέρηση.
Όταν το δίκτυο είναι σε καλή κατάσταση, στείλτε το στον πελάτη μαζί.
Η λύση είναι να αποσυνδέσετε την επανασύνδεση όταν το buffer πελάτη είναι μεγάλο.
Αντιγράψτε τον κωδικό
2. Χαμηλή καθυστέρηση HLS
Μερικοί άνθρωποι ρωτούν πάντα αυτήν την ερώτηση, πώς να μειώσουν την καθυστέρηση HLS.
Το HLS επιλύει την καθυστέρηση, όπως το να ανεβείτε στο δέντρο σφενδάμνου για να πιάσετε ψάρια. Περιέργως, υπάρχουν ακόμα άνθρωποι που φωνάζουν, κοίτα, υπάρχουν ψάρια.
Τι λες?
Μπορώ να πω μόνο ότι συμμετέχετε στο μαγικό σόου της σεμνότητας, της ψευδαίσθησης.
Εάν είστε πραγματικά σίγουροι, δείξτε το με την πραγματική εικόνα μέτρησης, ανατρέξτε στην παρακάτω μέτρηση.
3. μέτρηση της καθυστέρησης RTMP
Ο τρόπος μέτρησης της καθυστέρησης είναι ένα δύσκολο πρόβλημα,
Υπάρχει όμως ένας αποτελεσματικός τρόπος χρήσης του χρονόμετρου του κινητού τηλεφώνου, ο οποίος μπορεί να συγκρίνει την καθυστέρηση με μεγαλύτερη ακρίβεια.
Διαπιστώνεται ότι όταν το δίκτυο είναι σε καλή κατάσταση, εντοπίζονται τα ακόλουθα μέτρα:
Αντιγράψτε τον κωδικό
. Η καθυστέρηση RTMP μπορεί να είναι περίπου 0.8 δευτερόλεπτα.
. ο κόμβος άκρου πολλαπλών επιπέδων δεν επηρεάζει την καθυστέρηση (ο διακομιστής άκρων ενός CDN ομόλογου με SRS μπορεί να το κάνει)
. Η καθυστέρηση nginx RTMP είναι λίγο μεγάλη. Εκτιμάται ότι η επεξεργασία της προσωρινής μνήμης προκαλείται από την επικοινωνία πολλαπλών διεργασιών;
. Το GOP είναι ένας σκληρός δείκτης, αλλά το SRS μπορεί να απενεργοποιήσει την προσωρινή μνήμη του GOP για να αποφύγει αυτό το αποτέλεσμα
. η απόδοση του διακομιστή είναι πολύ χαμηλή, γεγονός που θα προκαλέσει επίσης μεγαλύτερη καθυστέρηση και ο διακομιστής δεν μπορεί να στείλει δεδομένα.
. το buffer μήκος του πελάτη επηρεάζει επίσης την καθυστέρηση.
Για παράδειγμα, ο πελάτης flash NetStream.bufferTime Ορίστηκε σε 10 δευτερόλεπτα και μετά καθυστερήστε για τουλάχιστον 10 δευτερόλεπτα.
Αντιγράψτε τον κωδικό
4. GOP-Cache
Τι είναι το GOP; Είναι η χρονική απόσταση μεταξύ των δύο πλαισίων I στη ροή βίντεο.
Ποιος είναι ο αντίκτυπος του GOP;
Το Flash (αποκωδικοποιητής) μπορεί να αρχίσει να αποκωδικοποιεί και να παίζει μόνο μέχρι να πάρει GOP.
Δηλαδή, ο διακομιστής συνήθως δίνει στο flash ένα πλαίσιο I πρώτα.
Δυστυχώς, το πρόβλημα είναι, ας υποθέσουμε ότι το GOP είναι 10 δευτερόλεπτα, δηλαδή, κάθε 10 δευτερόλεπτα υπάρχουν βασικά καρέ,
Τι γίνεται αν ο χρήστης αρχίσει να παίζει στο πέμπτο δευτερόλεπτο;
Η πρώτη λύση: περιμένετε το επόμενο πλαίσιο I,
Δηλαδή, περιμένετε άλλα 5 δευτερόλεπτα για να αρχίσετε να δίνετε τα δεδομένα του πελάτη.
Αυτή η καθυστέρηση είναι πολύ χαμηλή, πάντα ροή σε πραγματικό χρόνο.
Το πρόβλημα είναι: τα 5 δευτερόλεπτα που περιμένουν θα είναι μαύρα. Το φαινόμενο είναι ότι ο παίκτης έχει κολλήσει εκεί, τίποτα,
Ορισμένοι χρήστες μπορεί να πιστεύουν ότι είναι νεκροί και ανανεώνουν τη σελίδα.
Εν ολίγοις, ορισμένοι πελάτες θα πιστεύουν ότι η αναμονή για βασικά καρέ είναι ένα ασυγχώρητο σφάλμα. Ποια είναι η σχέση μεταξύ καθυστέρησης;
Θέλω απλώς να ξεκινήσω και να παίξω βίντεο γρήγορα και καλύτερα να το ανοίξω και να το παίξω!
Η δεύτερη λύση: ξεκινήστε τώρα,
Τι βάζεις;
Πρέπει να ξερεις. Βάλτε το προηγούμενο πλαίσιο I.
Δηλαδή, ο διακομιστής πρέπει να αποθηκεύει πάντα ένα GOP,
Έτσι ο πελάτης θα παίξει το προηγούμενο καρέ και θα ξεκινήσει γρήγορα.
Το πρόβλημα είναι: οι καθυστερήσεις είναι φυσικά μεγάλες.
Υπάρχει καλό σχέδιο;
Ναί! Υπάρχουν τουλάχιστον δύο τύποι:
Ο κωδικοποιητής μειώνει το GOP, όπως 0.5 δευτερόλεπτα, ένα GOP, οπότε η καθυστέρηση είναι χαμηλή και δεν χρειάζεται να περιμένετε.
Το μειονέκτημα είναι ότι ο ρυθμός συμπίεσης του κωδικοποιητή θα μειωθεί και η ποιότητα της εικόνας δεν είναι τόσο καλή.
5. σωρευτική καθυστέρηση
Εκτός από την προσωρινή μνήμη GOP, υπάρχει μια σχέση, αθροιστική καθυστέρηση.
Ο διακομιστής μπορεί να διαμορφώσει τη διάρκεια της ζωντανής ουράς και ο διακομιστής θα βάλει τα δεδομένα στη ζωντανή ουρά,
Εάν υπερβείτε αυτό το μήκος, διαγράψτε το τελευταίο πλαίσιο I:
Φυσικά, αυτό δεν μπορεί να διαμορφωθεί πολύ μικρό,
Το GOP, για παράδειγμα, είναι ένα δευτερόλεπτο, η ουρά_ Το μήκος είναι ένα δευτερόλεπτο, το οποίο θα προκαλέσει την εκκαθάριση των δεδομένων σε 1 δευτερόλεπτο και το άλμα.
Υπάρχει καλύτερος τρόπος; ναι, έχουμε.
Η καθυστέρηση είναι βασικά ίση με το μήκος της προσωρινής μνήμης του πελάτη. Επειδή η καθυστέρηση οφείλεται κυρίως στο χαμηλό εύρος ζώνης δικτύου, ο διακομιστής θα το στείλει στον πελάτη μαζί μετά την προσωρινή αποθήκευση. Το φαινόμενο είναι ότι το buffer του πελάτη είναι μεγαλύτερο,
για παράδειγμα NetStream.BufferLength = 5 Second, τότε υπάρχουν τουλάχιστον 5 δευτερόλεπτα δεδομένων στο buffer.
Ο καλύτερος τρόπος αντιμετώπισης του αθροιστικού λανθάνοντος χρόνου είναι ότι ο πελάτης εντοπίζει ότι το buffer έχει πολλά δεδομένα και, αν μπορεί, επανασυνδέστε το διακομιστή.
Φυσικά, εάν το δίκτυο ήταν κακό, δεν υπάρχει τρόπος.
|
Εισαγάγετε email για να εκπλήξετε
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Αφρικανικά
sq.fmuser.org -> Αλβανικά
ar.fmuser.org -> Αραβικά
hy.fmuser.org -> Αρμενίων
az.fmuser.org -> Αζερμπαϊτζάν
eu.fmuser.org -> Βάσκων
be.fmuser.org -> Λευκορωσικά
bg.fmuser.org -> Βουλγαρικά
ca.fmuser.org -> Καταλανικά
zh-CN.fmuser.org -> Κινέζικα (απλοποιημένα)
zh-TW.fmuser.org -> Κινέζικα (Παραδοσιακά)
hr.fmuser.org -> Κροατικά
cs.fmuser.org -> Τσέχικα
da.fmuser.org -> Δανικά
nl.fmuser.org -> Ολλανδικά
et.fmuser.org -> Εσθονικά
tl.fmuser.org -> Φιλιππινέζικα
fi.fmuser.org -> Φινλανδικά
fr.fmuser.org -> Γαλλικά
gl.fmuser.org -> Γαλικιανά
ka.fmuser.org -> Γεωργιανά
de.fmuser.org -> Γερμανικά
el.fmuser.org -> Ελληνική
ht.fmuser.org -> Κρεόλ της Αϊτής
iw.fmuser.org -> Εβραϊκά
hi.fmuser.org -> Χίντι
hu.fmuser.org -> Ουγγρική
is.fmuser.org -> Ισλανδικά
id.fmuser.org -> Ινδονησιακά
ga.fmuser.org -> Ιρλανδικά
it.fmuser.org -> Ιταλικά
ja.fmuser.org -> Ιαπωνικά
ko.fmuser.org -> Κορεάτικα
lv.fmuser.org -> Λετονικά
lt.fmuser.org -> Λιθουανικά
mk.fmuser.org -> Μακεδόνας
ms.fmuser.org -> Μαλαισιανά
mt.fmuser.org -> Μαλτέζικα
no.fmuser.org -> Νορβηγική
fa.fmuser.org -> Περσικά
pl.fmuser.org -> Πολωνικά
pt.fmuser.org -> Πορτογαλικά
ro.fmuser.org -> Ρουμανικά
ru.fmuser.org -> Ρωσικά
sr.fmuser.org -> Σέρβικα
sk.fmuser.org -> Σλοβακικά
sl.fmuser.org -> Σλοβένικα
es.fmuser.org -> Ισπανικά
sw.fmuser.org -> Σουαχίλι
sv.fmuser.org -> Σουηδικά
th.fmuser.org -> Ταϊλάνδης
tr.fmuser.org -> Τουρκικά
uk.fmuser.org -> Ουκρανικά
ur.fmuser.org -> Ουρντού
vi.fmuser.org -> Βιετνάμ
cy.fmuser.org -> Ουαλικά
yi.fmuser.org -> Γίντις
FMUSER Wirless Μετάδοση βίντεο και ήχου πιο εύκολα!
Επικοινωνία
Διεύθυνση:
No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou Κίνα 510620
Κατηγορίες
Newsletter