FMUSER Wirless Transmituj wideo i audio łatwiejsze!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
System transmisji audio i wideo na żywo to złożony system inżynieryjny. Aby uzyskać transmisję na żywo z bardzo niskimi opóźnieniami, konieczna jest kompleksowa optymalizacja inżynierii systemu i znajomość różnych komponentów. Oto kilka typowych wskazówek dotyczących strojenia:
Optymalizacja kodowania
1. Upewnij się, że kodek włącza ustawienie minimalnego opóźnienia. Kodek zazwyczaj ma przełącznik optymalizacji małych opóźnień, szczególnie dla H.264. Wiele osób może nie wiedzieć, że dekoder H.264 buforuje określoną liczbę klatek wideo przed wyświetleniem. W przypadku wideo o rozdzielczości QCIF (176 × 144) buforuje 16 klatek, a w przypadku wideo 720p buforuje 5 klatek. W przypadku pierwszego odczytu ramki jest to duże opóźnienie. Jeśli nie używasz H.264 do kodowania i kompresji wideo, upewnij się, że nie używasz klatek B, będzie to miało również większy wpływ na opóźnienie, ponieważ dekodowanie klatek B w wideo zależy od klatki wideo przed i po, co zwiększy opóźnienie.
2. Koder zwykle ma opóźnienie spowodowane kontrolą kodu, które jest również nazywane opóźnieniem inicjalizacji lub rozmiarem bufora VBV. Jest uważany za bufor między strumieniem bitów kodera i dekodera, który można ustawić tak mały, jak to możliwe lub zmniejszyć opóźnienie bez wpływu na jakość wideo.
3. Jeśli tylko pierwsze opóźnienie jest zoptymalizowane, między klatkami wideo można wstawić więcej klatek kluczowych, tak aby klient mógł dekodować strumień wideo jak najszybciej po jego odebraniu. Jeśli jednak musimy zoptymalizować skumulowane opóźnienie w procesie transmisji, powinniśmy użyć jak najmniejszej liczby klatek kluczowych, czyli I-ramek (GOP staje się większy). W przypadku zapewnienia tej samej jakości wideo, im więcej I-ramek, tym większa przepływność i większa przepustowość sieci potrzebna do transmisji, co oznacza, że skumulowane opóźnienie może być większe. Ten efekt optymalizacji może nie być oczywisty w systemie z drugim opóźnieniem, ale będzie oczywisty w systemie z opóźnieniem 100 ms lub nawet niższym. Jednocześnie spróbuj użyć kodeka acc-lc do kodowania dźwięku. Chociaż he-acc lub he-acc 2 ma wysoką wydajność kodowania, kodowanie trwa dłużej, a opóźnienie transmisji spowodowane większą głośnością dźwięku ma mniejszy wpływ na transmisję strumienia wideo.
4. Nie używaj formatu kompresji wideo MJPEG, przynajmniej używaj formatu kompresji wideo MPEG4 bez ramki B (prosty profil), a jeszcze lepiej użyj profilu bazowego H.264 (x264 ma również przełącznik optymalizacji „tune zerolatency”). Taka prosta optymalizacja może zmniejszyć opóźnienia, ponieważ może kodować wideo z pełną liczbą klatek na sekundę przy niższej przepływności.
5. Jeśli używany jest ffmpeg, zmniejsz wartości "- probesize" i "-analy duration", które są używane do monitorowania informacji o klatce wideo i czasu monitorowania. Im większe są te dwie wartości, tym większy wpływ na opóźnienie kodowania. W scenie na żywo nie jest nawet konieczne ustawianie parametru czasu trwania analizy dla strumienia wideo.
6. Kodowanie o stałej szybkości CBR może do pewnego stopnia wyeliminować wpływ jittera sieciowego. Jeśli można zastosować kodowanie o zmiennej szybkości VBR, może to zaoszczędzić trochę niepotrzebnej przepustowości sieci i zmniejszyć pewne opóźnienia. Dlatego sugeruje się, aby VBR był używany do kodowania w jak największym stopniu.
Optymalizacja protokołów transportowych
1. Spróbuj użyć RTMP zamiast protokołu HLS opartego na HTTP do transmisji między węzłami serwera, co może zmniejszyć ogólne opóźnienie transmisji. Jest to skierowane głównie do użytkowników końcowych używających HLS do grania.
2. Jeśli użytkownik końcowy używa RTMP do odtwarzania, transkodowanie powinno zostać przeprowadzone w węźle odbiorczym w pobliżu końca strumieniowego, tak aby przesyłany strumień wideo był mniejszy niż oryginalny strumień wideo.
3. Jeśli to konieczne, dostosowany protokół UDP może zostać użyty do zastąpienia protokołu TCP, a retransmisja utraty pakietów pod słabym łączem sieciowym może zostać wyeliminowana, co może zmniejszyć opóźnienie. Jego główną wadą jest to, że transmisja i dystrybucja niestandardowego strumienia wideo w oparciu o protokół UDP nie jest wystarczająco uniwersalna, a producenci CDN obsługują standardowy protokół transmisji. Inną wadą jest to, że mogą występować rozpryski lub rozmycia spowodowane utratą pakietów (brak odniesienia do dekodowania klatek kluczowych), co wymaga od strony dostosowywania protokołu wykonania dobrej pracy w zakresie kontroli utraty pakietów na podstawie UDP.
Optymalizacja sieci przesyłowej
1. Wprowadziliśmy sieć streamingu czasu rzeczywistego, która jest nowym typem sieci transmisyjnej z samoorganizującymi się węzłami. Nadaje się nie tylko do optymalizacji transmisji w krajowej sieci wielu operatorów, ale także nadaje się do potrzeb wielu zagranicznych transmisji na żywo.
2. Buforuj bieżący GOP w węźle serwera i współpracuj z odtwarzaczem, aby zoptymalizować czas otwarcia wideo.
3. Serwer rejestruje liczbę klatek na sekundę drugiego poziomu i szybkość kodowania, gdy każdy strumień wideo przepływa do każdego łącza w czasie rzeczywistym, i monitoruje wahania szybkości kodowania i liczby klatek na sekundę w czasie rzeczywistym.
4. Klient (push stream and play) uzyskuje bieżący optymalny węzeł w czasie quasi-rzeczywistym, wysyłając zapytanie do serwera (raz na 5 sekund), a bieżący węzeł i linia awarii są offline w czasie quasi-rzeczywistym.
Optymalizacja przesyłania strumieniowego i odtwarzania
1. System może buforować dane przed wysłaniem danych. Strojenie tego parametru również musi znaleźć równowagę.
2. Kontrola bufora odtwarzacza ma również duży wpływ na pierwsze opóźnienie wideo. Jeśli tylko pierwsze opóźnienie jest zoptymalizowane, dane mogą być dekodowane natychmiast po ich nadejściu w przypadku bufora 0. Ale w słabym środowisku sieciowym, aby wyeliminować wpływ jittera sieciowego, konieczne jest ustawienie określonej pamięci podręcznej, dlatego musimy znaleźć równowagę między stabilnością transmisji na żywo a optymalizacją pierwszego otwartego opóźnienia i dostosować zoptymalizowany rozmiar bufora.
3. Strategia bufora dynamicznego gracza, która jest ulepszoną wersją powyższej kontroli pamięci podręcznej gracza. Jeśli po prostu wybierzemy między pamięcią podręczną 0 a pamięcią o stałym rozmiarze, aby znaleźć równowagę, ostatecznie wybierzemy pamięć podręczną o stałym rozmiarze, co nie jest sprawiedliwe w stosunku do 100 milionów użytkowników mobilnych terminali internetowych. Ich różne warunki sieciowe powodują, że pamięć podręczna o stałym rozmiarze nie jest całkowicie odpowiednia. Dlatego możemy rozważyć „strategię dynamicznego bufora”. Gdy odtwarzacz jest włączony, stosujemy strategię bardzo małego lub nawet zerowego bufora. Rozmiar bufora następnego przedziału czasu jest określany na podstawie czasu potrzebnego na pobranie pierwszego wideo. Jednocześnie bieżąca sieć jest monitorowana w czasie rzeczywistym podczas procesu odtwarzania, a rozmiar bufora jest dostosowywany w czasie rzeczywistym podczas procesu odtwarzania. W ten sposób pierwszy czas otwarcia może być bardzo krótki, a wpływ jittera sieci może zostać wyeliminowany w miarę możliwości.
4. Strategia gry w dynamiczną stawkę. Oprócz strategii dynamicznego dostosowywania rozmiaru bufora, możemy również wykorzystać informacje sieciowe monitorujące w czasie rzeczywistym do dynamicznego dostosowywania przepływności w trakcie odtwarzania. W przypadku niewystarczającej przepustowości sieci możemy zmniejszyć przepływność do grania i zmniejszyć opóźnienie.
Powyższe jest częścią technik optymalizacji małych opóźnień. W rzeczywistości, kiedy optymalizujemy niskie opóźnienia, nie skupiamy się tylko na „niskich opóźnieniach”, ale staramy się osiągnąć niskie opóźnienia pod warunkiem, że inne warunki nie wpływają na wrażenia użytkownika. Dlatego jego zawartość obejmuje szeroki zakres tematów.
|
Wpisz e-mail, aby otrzymać niespodziankę
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
FMUSER Wirless Transmituj wideo i audio łatwiejsze!
Kontakt
Adres:
Nr 305 Pokój HuiLan Budynek nr 273 Huanpu Road Guangzhou Chiny 510620
Kategorie
Newsletter