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. RTP: (Транспортний протокол у реальному часі)
Це протокол транспортного рівня для передачі мультимедійних даних в Інтернеті. Протокол RTP і протокол управління RTP RTCP використовуються разом,
І він побудований на протоколі UDP.
RTP не схожий на http і ftp, які можуть повністю завантажити весь файл фільму. Він передає дані в мережу з фіксованою швидкістю передачі даних. Клієнт також переглядає файл фільму з такою швидкістю.
Після відтворення екрана фільму його неможливо відтворити повторно, якщо дані знову не запитуються з сервера.
2. RTCP: Протокол керування транспортом у режимі реального часу або RTP Control Protocol або коротко RTCP)
Протокол управління передачею в режимі реального часу є спільним протоколом протоколу передачі в реальному часі (RTP).
Примітка: -: Протокол RTP і протокол управління RTP (RTCP) використовуються разом, і він базується на протоколі UDP (зазвичай використовується для відеоконференцій)
3. RTSP: (Протокол потокового передавання в реальному часі)
Протокол сеансу медіа-передачі в режимі реального часу, SDP (протокол опису сеансу), RTP (транспортний протокол у реальному часі).
Це протокол мультимедійного потокового передавання, який використовується для управління звуком або відео. RTSP забезпечує розширювану структуру, яка дає можливість контролювати дані в режимі реального часу та такі, як аудіо та відео.
Медіа-дані використовують протоколи rtp та rtcp. Зазвичай використовують udp як транспортний шар. Підходить для сцен IPTV. Джерела даних включають дані в реальному часі та дані, що зберігаються у кліпах. Призначення цього протоколу полягає в управлінні кількома з'єднаннями передачі даних, забезпеченні способу вибору каналів передачі, таких як UDP, багатоадресне передавання UDP і TCP, а також наданні методів вибору механізму передачі на основі RTP. Протокол мережевого зв'язку, що використовується під час передачі, не входить у сферу його визначення. Сервер може вибрати використання TCP або UDP для передачі потокового вмісту, що більш терпимо до мережевих затримок.
--->: Найбільша різниця між RTSP та RTP полягає в тому, що: RTSP - це двосторонній протокол передачі даних у режимі реального часу, який дозволяє клієнтові надсилати запити на сервер, такі як операції відтворення, перемотування вперед та назад. коли
Звичайно, RTSP може передавати дані на основі RTP, а також може вибрати TCP, UDP, багатоадресну UDP та інші канали для передачі даних, що має гарну масштабованість. Це схоже на протокол http
Протокол рівня мережевого додатка.
4. WebRTC:
Веб-сторінка реалізує протокол потокового мультимедіа. Коли Google вперше запустив WebRTC, гіганти або сиділи збоку, або чинили опір цьому. Використовуйте передачу протоколу RTP.
5. RTMP (Протокол обміну повідомленнями в режимі реального часу)
Набір протоколів відео в прямому ефірі, розроблений Macromedia, зараз належить Adobe. Як і HLS, його можна застосувати до відео в реальному часі, і він не буде втрачений на основі TCP.
// Різниця полягає в тому, що RTMP не можна відтворювати в браузері iOS на основі флеш-пам'яті, але продуктивність у реальному часі краща, ніж HLS.
Протокол обміну повідомленнями в режимі реального часу - це відкритий протокол, розроблений Adobe Systems для передачі аудіо, відео та даних між програвачами Flash та серверами.
// У коді iOS RTMP зазвичай використовується для підштовхування потоку. Ви можете використовувати сторонню бібліотеку librtmp-iOS для просування потоку. librtmp інкапсулює деякі базові API для виклику користувачів
Протокол RTMP також вимагає від клієнта та сервера встановлення з'єднання RTMP за допомогою "рукостискання", а потім передачі інформації про керування підключенням. Протокол RTMP буде форматувати дані під час передачі. Під час фактичної передачі, для кращого досягнення мультиплексування, підпакування та справедливості інформації, відправник розділить Повідомлення на Шматки з Ідентифікатором Повідомлення, кожен Чанок може бути одним повідомленням,
Це також може бути частиною Повідомлення. Кінець, що отримує, відновить фрагмент до повного повідомлення відповідно до довжини даних, що містяться в фрагменті, довжини ідентифікатора повідомлення та довжини повідомлення, щоб реалізувати надсилання та отримання інформації.
6. HLS: пряма трансляція HTTP (HLS)
Це протокол передачі потокового мультимедіа на основі HTTP, реалізований Apple Inc., який може реалізовувати потокові медіа та трансляції в режимі реального часу. Він в основному використовується в системі iOS і забезпечує аудіо- та відеозв'язок у прямому ефірі та рішення на замовлення для пристроїв iOS (таких як iPhone та iPad). HLS на вимогу - це в основному звичайний сегментований HTTP на вимогу. Різниця полягає в тому, що його сегменти дуже малі. Порівняно із загальноприйнятими потоковими мультимедійними протоколами прямого мовлення, такими як RTMP, RTSP, MMS тощо, найбільша різниця в прямому ефірі HLS полягає в тому, що те, що отримує клієнт прямого ефіру, не є повним потоком даних.
Протокол HLS зберігає прямий потік даних як безперервні короткочасні медіа-файли (формат MPEG-TS) на стороні сервера, і клієнт постійно завантажує та відтворює ці невеликі файли, оскільки серверна сторона завжди буде оновлювати останню пряму трансляцію. дані генерують нові маленькі файли, тому, доки клієнт безперервно відтворює файли, отримані з сервера, послідовно, пряма трансляція реалізується. Можна бачити, що, в основному, можна вважати, що HLS - це технічний спосіб >> на замовлення реалізувати пряму трансляцію <<. Оскільки дані передаються через протокол HTTP, немає необхідності розглядати брандмауери або проксі-сервери взагалі.
Крім того, тривалість сегментованого файлу дуже коротка, і клієнт може швидко вибрати та змінити швидкість передачі даних, щоб адаптуватися до відтворення за різних умов пропускної здатності. Однак ця технічна характеристика ЗСЖ визначає її
Затримка завжди буде вищою, ніж звичайний протокол прямої трансляції.
// І iOS, і Android, природно, підтримують цей протокол, конфігурація проста, просто використовуйте відеотег безпосередньо
*** VLS: Це свого роду сервер потокового передавання, який спеціально використовується для вирішення різних проблем потокового передавання. Він також має деякі характеристики VLC. Як сервер, відеолан може виводити потоки http, rtp, rtsp.
В принципі, RTSP, RTMP і HTTP можуть бути використані для прямого ефіру та мовлення за запитом, але, як правило, RTSP і RTMP використовуються для прямого мовлення, а HTTP використовується для мовлення на вимогу. Ми вибрали протокол RTMP.
Різний затримки протоколу та їх причини
rtmp та httpflv: Дані цих двох протоколів приблизно однакові, тому причини затримки однакові. Зрозуміло, що потокові прямі трансляції tcp повинні мати надзвичайно низьку затримку. Чому rtmp і httpflv все ще мають латентність? Причина полягає в тому, що на h264, rtmp і httpflv - це теги flv, які передаються. Даними відеотегу зазвичай є дані h264. Розшифровка H264 має IBP. Я - ключовий кадр, який є завершеним образом. Ви повинні мати I перед декодуванням. Останніх кадрів BP, BP може бути скільки завгодно, але I кадрів не може бути менше, тому I кадри повинні передаватися другими при передачі тегів flv (перший - h264spspps), але I кадри не часто присутні в потоках h264, Через певний проміжок часу є кадр I. Цей період часу широко відомий як GOP. При кодуванні GOP встановлюється дуже коротко. Коли клієнт підключається, сервер знаходить найближчий I кадр у потоці з найшвидшою швидкістю і відправляє його з I кадру. Дані в реальному часі, але коли GOP дуже довгий, інтервал I кадру дуже довгий, або дочекайтеся наступного I кадру, щоб почати надсилати дані до нового підключення, або знайти найближчий I кадр у буфері, щоб почати надсилати, ось затримка протоколу rtmp та hls Ключовим моментом є те, що на основних платформах CDN це називається "технологією другого відкриття rtmp". Принцип полягає в тому, щоб двічі декодувати дані push і встановити невеликий проміжок. Загалом для gop встановлено значення 1s. Незалежно від затримки лінії передачі мережі, максимальна затримка даних становить 1 с. На щастя, кадр I - 0 затримка!
|
Введіть електронну адресу, щоб отримати сюрприз
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
Категорії
Інформаційний бюлетень