FMUSER Бесправадная перадача відэа і аўдыё лягчэй!
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. Пераканайцеся, што кодэк уключае ўстаноўку мінімальнай затрымкі. Кодэк звычайна мае пераключальнік для аптымізацыі з нізкай затрымкай, асабліва для H.264. Шмат хто можа не ведаць, што дэкодэр H.264 будзе кэшаваць пэўную колькасць відэакадраў перад адлюстраваннем. Для відэа з дазволам QCIF (176 × 144) яно кэшуе 16 кадраў, а для відэа 720p - 5 кадраў. Для першага прачытанага кадра гэта вялікая затрымка. Калі вы не выкарыстоўваеце H.264 для кадавання і сціскання відэа, пераканайцеся, што вы не выкарыстоўваеце кадры B, гэта таксама будзе мець большы ўплыў на затрымку, таму што дэкадаванне кадраў групы B у відэа залежыць ад відэакадры да і пасля, што павялічыць затрымку.
2. У кадавальніку звычайна ёсць затрымка, выкліканая кіраваннем кодам, якая таксама называецца затрымкай ініцыялізацыі альбо памерам буфера VBV. Ён разглядаецца як буфер паміж бітавым патокам кадавальніка і дэкодэра, які можна ўсталяваць як мага меншым альбо паменшыць затрымку, не ўплываючы на якасць відэа.
3. Калі першая затрымка толькі аптымізавана, паміж відэакадрамі можна ўставіць больш ключавых кадраў, каб кліент мог як мага хутчэй расшыфраваць відэапаток пасля яго атрымання. Аднак, калі нам трэба аптымізаваць сукупную затрымку ў працэсе перадачы, мы павінны выкарыстоўваць як мага менш ключавых кадраў, гэта значыць I-кадраў (GOP становіцца больш). У выпадку забеспячэння аднолькавай якасці відэа, чым больш I-кадраў, тым большая хуткасць перадачы дадзеных і большая прапускная здольнасць сеткі, неабходная для перадачы, а значыць, сукупная затрымка можа быць большай. Гэты эфект аптымізацыі можа быць не відавочны ў сістэме з другой затрымкай, але ён будзе відавочны ў сістэме з затрымкай 100 мс ці нават меншай. У той жа час паспрабуйце выкарыстоўваць кадэк acc-lc для кадавання аўдыя. Нягледзячы на тое, што he-acc або he-acc 2 мае высокую эфектыўнасць кадавання, кадаванне займае больш часу, а затрымка перадачы, выкліканая вялікім аб'ёмам гуку, менш уплывае на перадачу відэа патоку.
4. Не выкарыстоўвайце фармат сціску відэа MJPEG, па меншай меры выкарыстоўвайце фармат сціску відэа MPEG4 без кадра B (просты профіль), а яшчэ лепш выкарыстоўвайце зыходны профіль H.264 (x264 таксама мае перамыкач аптымізацыі "настройка нулявой латэнтнасці"). Такая простая аптымізацыя можа паменшыць час затрымкі, паколькі можа кадаваць відэа з поўнай частатой кадраў з меншай бітавай хуткасцю.
5. Калі выкарыстоўваецца ffmpeg, паменшыце значэнні "- probesize" і "- аналіз працягласці", якія выкарыстоўваюцца для маніторынгу інфармацыі пра час кадра і маніторынгу. Чым больш гэтыя два значэнні, тым большы ўплыў на затрымку кадавання. У жывой сцэне нават не трэба ўсталёўваць параметр працягласці аналізу для відэа патоку.
6. Кадаванне CBR з фіксаванай хуткасцю можа ў пэўнай ступені ліквідаваць уплыў сеткавага дрыгацення. Калі VBR можна кадаваць з зменнай хуткасцю, гэта можа зэканоміць непатрэбную прапускную здольнасць сеткі і паменшыць пэўную затрымку. Такім чынам, прапануецца выкарыстоўваць VBR як мага больш для кадавання.
Аптымізацыя транспартнага пратакола
1. Паспрабуйце выкарыстоўваць RTMP замест пратакола HLS на аснове HTTP для перадачы паміж вузламі сервера, што можа паменшыць агульную затрымку перадачы. У асноўным гэта накіравана на канчатковых карыстальнікаў, якія выкарыстоўваюць HLS для прайгравання.
2. Калі канчатковы карыстальнік выкарыстоўвае RTMP для прайгравання, перакадзіроўка павінна ажыццяўляцца на прыёмным вузле побач з канцом струменевай перадачы, каб перададзены відэапаток быў меншым за зыходны відэапаток.
3. Пры неабходнасці індывідуальны пратакол UDP можа быць выкарыстаны для замены пратакола TCP, а паўторная перадача страты пакета пры слабой сеткавай сувязі можа быць ліквідавана, што можа паменшыць затрымку. Яго галоўны недахоп заключаецца ў тым, што перадача і распаўсюджванне наладжанага відэа патоку на аснове пратаколу UDP недастаткова універсальная, і вытворцы CDN падтрымліваюць стандартны пратакол перадачы. Іншым недахопам з'яўляецца тое, што можа ўзнікнуць ўсплёск альбо размытасць, выкліканыя стратай пакетаў (адсутнасць спасылкі на дэкадаванне ключавога кадра), што патрабуе ад удзельніка налады пратакола добрай працы ў кантролі страты пакета на аснове UDP.
Аптымізацыя сеткі перадачы
1. Мы прадставілі струменевую сетку ў рэжыме рэальнага часу, якая з'яўляецца новым тыпам сеткі перадачы з самаарганізаванымі вузламі. Гэта падыходзіць не толькі для аптымізацыі перадачы айчыннай сеткі некалькіх аператараў, але і для патрэб шмат якіх трансляцый за мяжой.
2. Кэшуйце бягучы GOP у вузле сервера і супрацоўнічайце з плэерам для аптымізацыі часу адкрыцця відэа.
3. Сервер запісвае частату кадраў і хуткасць кода другога ўзроўню, калі кожны відэаток цячэ да кожнай спасылкі ў рэжыме рэальнага часу, і адсочвае ваганні хуткасці кода і частоты кадраў у рэжыме рэальнага часу.
4. Кліент (націсканне патоку і прайграванне) атрымлівае бягучы аптымальны вузел у квазірэальным часе, запытваючы сервер (раз у 5 секунд), а бягучы вузел і лінія няспраўнасці знаходзяцца ў пазасеткавым рэжыме ў квазі рэальным часе.
Аптымізацыя струменевай перадачы і прайгравання
1. Сістэма можа кэшаваць дадзеныя перад адпраўкай дадзеных. Наладка гэтага параметру таксама павінна знайсці баланс.
2. Кіраванне буферам плэера таксама аказвае вялікі ўплыў на першую затрымку відэа. Калі аптымізавана толькі першая затрымка, дадзеныя могуць быць неадкладна расшыфраваны, калі яны паступяць, у выпадку 0 буфера. Але ў слабым сеткавым асяроддзі для таго, каб ліквідаваць уздзеянне дрыжання сеткі, неабходна ўсталяваць пэўны кэш, таму нам трэба знайсці баланс паміж стабільнасцю жывой трансляцыі і аптымізацыяй першай адкрытай затрымкі, і наладзіць аптымізаваны памер буфера.
3. Стратэгія дынамічнага буфера гульца, якая з'яўляецца палепшанай версіяй вышэйзгаданага кантролю кэша гульца. Калі мы проста выбіраем паміж кэшам 0 і кэшам фіксаванага памеру, каб знайсці баланс, мы ў рэшце рэшт абярэм кэш фіксаванага памеру, што несправядліва для 100 мільёнаў карыстальнікаў мабільнага Інтэрнэт-тэрмінала. Іх розныя ўмовы сеткі вызначаюць, што кэш фіксаванага памеру не цалкам падыходзіць. Такім чынам, мы можам разгледзець "дынамічную стратэгію буфера". Калі плэер уключаны, мы выкарыстоўваем вельмі маленькую ці нават нулявую стратэгію буфера. Памер буфера наступнага зрэзу часу вызначаецца часам, загружаным першым відэа. У той жа час бягучая сетка кантралюецца ў рэжыме рэальнага часу ў працэсе прайгравання, а памер буфера рэгулюецца ў рэжыме рэальнага часу ў працэсе прайгравання. Такім чынам, час першага адкрыцця можа быць вельмі нізкім, і ўплыў сеткавага дрыгацення можа быць ліквідаваны наколькі гэта магчыма.
4. Дынамічная стратэгія хуткасці гульні. У дадатак да стратэгіі дынамічнага рэгулявання памеру буфера, мы таксама можам выкарыстоўваць інфармацыю пра сетку маніторынгу ў рэжыме рэальнага часу, каб дынамічна рэгуляваць бітрэйт у працэсе прайгравання. У выпадку недастатковай прапускной здольнасці сеткі мы можам паменшыць бітрэйт для прайгравання і паменшыць затрымку.
Вышэйсказанае з'яўляецца часткай метадаў аптымізацыі з нізкай затрымкай. На самай справе, калі мы аптымізуем нізкую затрымку, мы засяроджваемся не толькі на "нізкай затрымцы", але спрабуем дасягнуць нізкай затрымкі пры ўмове, што іншыя ўмовы не ўплываюць на карыстацкі досвед. Таму яго змест уключае шырокі спектр тэм.
|
Увядзіце адрас электроннай пошты, каб атрымаць сюрпрыз
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 Бесправадная перадача відэа і аўдыё лягчэй!
Кантакт
Адрас:
No.305 Нумар HuiLan Будынак No.273 Huanpu Road Гуанчжоу Кітай 510620
катэгорыі
бюлетэнь