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. Клієнт (push-потік і відтворення) отримує поточний оптимальний вузол у квазі-реальному часі, запитуючи сервер (один раз на 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 Будівля No273 Huanpu Road Гуанчжоу Китай 510620
Категорії
Інформаційний бюлетень