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 буде кешувати певні відеокадри перед нормальним відображенням, 16 кадрів буде кешовано для відео з роздільною здатністю QCIF (176 × 144) та 5 кадрів для відео 720p. Це велика затримка для прочитання першого кадру. Якщо ваше відео не кодується та не стискається за допомогою H.264, переконайтеся, що кадр B не використовується, це також матиме більший вплив на затримку, оскільки декодування B-кадру у відео залежить від переднього та заднього відеокадрів, які збільшить затримку.
2. кодер, як правило, має затримку, спричинену управлінням кодом, яка також називається затримкою ініціалізації або розміром кешу VBV, що розглядається як кеш між кодером та потоком бітів декодера. Його можна встановити як можна менше і зменшити затримку, не впливаючи на якість відео.
3. якщо оптимізовано лише першу затримку, між відеокадрами можна вставити більше ключових кадрів, щоб клієнт міг декодувати відеопотік якомога швидше після отримання відеопотоку. Однак, якщо сукупну затримку передачі потрібно оптимізувати, ключовий кадр (I кадр стає більшим) використовується якомога менше. У разі забезпечення однакової якості відео, чим більше кадрів I, тим більша швидкість коду та більша пропускна здатність мережі, необхідна для передачі, це означає, що тим більша сукупна затримка. Цей ефект оптимізації може бути не очевидним у системах з другою затримкою, але він буде дуже очевидним у системах із затримкою 100 мс або менше. Тим часом кодек ACC LC використовується якомога більше для кодування звуку. Незважаючи на те, що він acc або he-acc 2 має високу ефективність кодування, кодування займає більше часу, а затримка передачі, спричинена більшим обсягом звуку, менше впливає на передачу відеопотоку.
4. не використовуйте формат стиснення відео для відео MJPEG, принаймні використовуйте формат стиснення відео MPEG 4 без кадру B (простий профіль) або навіть не використовуйте базовий профіль H.264 (x264 також має перемикач оптимізації -Нутальність). Така проста оптимізація може зменшити затримку, оскільки може кодувати відео з повною частотою кадрів із меншою швидкістю передачі даних.
5. якщо використовується ffmpeg, значення параметрів "-probesize" та "аналіз тривалості" зменшується. Ці два значення використовуються для моніторингу інформації про відеокадр і тривалості моніторингу. Чим більший вплив цих двох значень на затримку кодування, тим більше необхідно встановлювати параметр тривалості аналізу для відеопотоку в реальній відео сцені.
6. кодування CBR з фіксованою швидкістю може певною мірою усунути мерехтіння мережі. Якщо можна використовувати VBR, можна зберегти деяку непотрібну пропускну здатність мережі та зменшити певну затримку. Тому пропонується використовувати VBR якомога більше для кодування.
Оптимізація протоколу передачі
1. спробуйте використовувати RTMP замість протоколу HLS на основі HTTP для передачі між вузлами та вузлами сервера, що може зменшити загальну затримку передачі. Це головним чином для кінцевого користувача, який використовує HLS для відтворення.
2. якщо кінцевий користувач використовує RTMP для відтворення, перекодування виконується на приймальному вузлі поблизу кінця потокової передачі, наскільки це можливо, так що переданий відеопотік менше, ніж вихідний відеопотік.
3. при необхідності ви можете замінити TCP на спеціальний протокол UDP та зменшити затримку, усунувши повторну передачу втрат пакетів у слабкій мережі. Основним недоліком цього протоколу є те, що передача та розподіл відеопотоку на основі протоколу UDP недостатньо універсальні, і виробники CDN підтримують стандартний протокол передачі. Іншим недоліком є те, що екран або розмиття, спричинені втратою пакетів (відсутність посилання на декодування ключового кадру), що вимагає від сторони налаштування протоколу контролю втрати пакетів на основі UDP.
Оптимізація мережі передачі
1. ми запровадили потокову мережу передачі в режимі реального часу, яка є новою мережею передачі з вузлами самоорганізації, яка підходить для оптимізації передачі в мережевих умовах вітчизняних мульти операторів та попиту багатьох трансляцій за кордоном.
2. кешувати поточний GOP у вузлі сервера та оптимізувати час відкриття відео за допомогою програвача.
3. сервер записує другу частоту кадрів і швидкість коду кожного відеопотоку, що надходить до кожної лінії в режимі реального часу, і відстежує коливання швидкості коду та частоти кадрів у реальному часі.
4. клієнт (push and play) отримує поточний оптимальний вузол (раз на 5 секунд) шляхом запиту сервера в квазіреальному часі та квазі реального часу в режимі офлайн поточних вузлів і ліній помилок.
Оптимізація потоку та відтворення
1. дослідити розмір мережевого буфера системи відправника, і система може кешувати дані перед відправкою даних. Налаштування цього параметра також потрібно знайти точку балансу.
2. управління буфером на стороні відтворення також має великий вплив на затримку відкриття відео. Якщо оптимізовано лише першу затримку, її можна негайно декодувати, коли дані надходять у випадку 0 кеш-пам’яті. Але якщо для того, щоб усунути вплив мережевого тремтіння в слабкому мережевому середовищі, необхідно встановити певний кеш. Отже, необхідно знайти баланс між стабільністю прямого ефіру та оптимізацією першої затримки, і відрегулювати значення оптимізації розміру буфера.
3. політика динамічного буфера сторони відтворення є вдосконаленою версією кешу керованого кінця відтворення вище. Якщо для пошуку балансу вибрано лише кеш 0 та кеш фіксованого розміру, остаточно буде вибрано кеш фіксованого розміру. Це несправедливо щодо кінцевих користувачів мобільного Інтернету на мільярдному рівні. Різні умови мережі вирішують, що буфер фіксованого розміру не є повністю доречним. Тому ми можемо розглянути динамічну політику буфера, яка використовує дуже малу або навіть 0 політику кешування, коли програвач увімкнено. Розмір кешу наступного часового фрагмента визначається часом, який вимагає завантаження першого відео, і в той же час поточна мережа контролюється в режимі реального часу під час процесу відтворення, а розмір кешу під час процесу відтворення регулюється в реальний час. Це дозволяє досягти дуже низького часу відкриття та максимально усунути вплив мерехтіння мережі.
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 Будівля No273 Huanpu Road Гуанчжоу Китай 510620
Категорії
Інформаційний бюлетень