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 -> Ідыш
Нядаўна я пачаў звязвацца з праектам відэа ў жывым эфіры, я таксама абагульніў некаторыя канцэпцыі, тэхналогіі і рашэнні, звязаныя з відэа.
Перш за ўсё, зразумець паняцце відэа ў прамым эфіры. Некалькі распаўсюджаных відэапратаколаў: RTMP, http-flv, HLS, RTP / RTCP.
Тады мы растлумачым увесь працэс жывога вяшчання і звязаныя з ім тэхналогіі.
1, пратакол відэа ў прамым эфіры
У сферы жывога вяшчання існуе два віды жывога вяшчання: інтэрактыўнае жывое вяшчанне і неінтэрактыўнае жывое вяшчанне.
Неінтэрактыўнае жывое вяшчанне (напрыклад, "Жывы парад", "Прамая трансляцыя НБА", "Жывая трансляцыя Лігі чэмпіёнаў" і г.д.) не з'яўляецца вельмі інтэрактыўным, што дазваляе затрымліваць 10 секунд і больш. Ён характарызуецца адносна невялікай колькасцю крыніц і падыходзіць для шматканальнага перакадавання (карыстальнікі могуць глядзець яго ў адпаведнасці з умовамі сеткі).
Тыповыя сцэны інтэрактыўнага жывога эфіру ўключаюць жывыя трансляцыі шоу, жывыя трансляцыі гульняў і г. д. З-за высокіх патрабаванняў да ўзаемадзеяння якара і аўдыторыі гэтыя жывыя трансляцыі павінны быць адкладзены ў межах 5S. Характарыстыкі інтэрактыўнага жывога вяшчання такія: больш крыніц, не прыдатных для шматканальнага перакадавання, прамежкавы сервер толькі як транзітная роля.
Носьбітамі жывой перадачы кантэнту з'яўляецца сетка, і адпаведныя пратаколы неабходныя для перадачы відэа ці аўдыё ў сетцы. У цяперашні час агульныя пратаколы, прыдатныя для жывых сцэн, наступныя.
1. Пратакол RTMP (не падтрымліваецца HTML 5, падтрымліваецца ўспышкай)
RTMP - гэта пратакол мультымедыйнай перадачы, які з'яўляецца патэнтам пратакола Adobe. На аснове TCP ён вельмі папулярны ў Кітаі.
Папулярная прычына: падтрымка праграмнага забеспячэння з адкрытым зыходным кодам і бібліятэкі з адкрытым зыходным кодам з'яўляецца стабільнай і поўнай, і найбольш часта выкарыстоўваюцца рашэнні для струменевага і струменевага кіравання могуць працаваць стабільна. Напрыклад: бібліятэка push-патокаў librtmp з адкрытым зыходным кодам, на баку службы ёсць убудова nginx RTMP, цячэнне патоку мае бібліятэку прайгравання ijkplayer.
2. Пратакол Http-flv (не падтрымліваецца HTML 5, падтрымліваецца ўспышкай)
Гэта значыць выкарыстоўваць пратакол HTTP для перадачы мультымедыйнага кантэнту. HTTP прасцей і больш вядомы, чым RTMP. Затрымка змесціва таксама можа складаць 2-5 секунд, а хуткасць адкрыцця хутчэй, таму што сам HTTP не мае складанага ўзаемадзеяння. Такім чынам, з пункту гледжання латэнтнасці, http-flv лепш, чым RTMP.
3. Пратакол HLS (падтрымка HTML, падтрымка Flash)
Прамая трансляцыя HTTP - гэта пратакол транспартнага мультымедыя, заснаваны на HTTP, прапанаваны Apple. HLS мае вельмі вялікую перавагу: HTML5 можна непасрэдна адкрываць і прайграваць; гэта азначае, што жывую спасылку можна распаўсюджваць праз wechat і іншыя перасылкі без неабходнасці ўсталёўваць незалежнае прыкладанне з браўзэрам, таму яна вельмі папулярная. Сацыяльнае жывое прыкладанне, HLS проста неабходна. URL-адрас жывой трансляцыі, заснаваны на HLS, уяўляе сабой файл m3u8, які змяшчае некалькі нядаўніх невялікіх відэа TS-файлаў. Затрымка гэтага рэжыму прайгравання адносна вялікая (што звязана з памерам файла TS), і ў той жа гарадской сетцы можа быць дасягнута 5-7-секундная затрымка.
4. Пратакол RTP / RTCP
Транспартны пратакол рэальнага часу - гэта пратакол транспартнага ўзроўню для мультымедыйнага патоку дадзеных у Інтэрнэце. RTCP перадае сігналізацыю інтэрактыўнага кіравання, а RTP - рэальныя дадзеныя носьбіта.
RTP шырока выкарыстоўваецца ў сістэмах відэаназірання, відэаканферэнцый і IP-тэлефонаў, таму што адным з важных досведаў відэаканферэнцый і IP-тэлефона з'яўляецца моцны кантэнт у рэжыме рэальнага часу.
У параўнанні з вышэйзгаданымі трыма пратаколамі, адным з важных адрозненняў паміж RTP і іх з'яўляецца тое, што пратакол UDP выкарыстоўваецца для перадачы дадзеных па змаўчанні, у той час як RTMP і HTTP заснаваны на пратаколе TCP.
Выкарыстоўвайце аналіз сцэнарыяў: сцэна аўдыя і відэа ў рэжыме рэальнага часу не патрабуе надзейнай гарантыі, таму няма неабходнасці мець механізм рэтрансляцыі. Не важна бачыць выяву і гук у рэжыме рэальнага часу, губляць частку змесціва, калі сетка дрыжыць, размывае малюнак і застаўку. Для паўторнай перадачы TCP выкліча затрымку і асінхроннасць. Калі пэўны раздзел зместу паступае праз адну секунду з-за рэтрансляцыі, уся размова зацягнецца на адну секунду. Пры дрыгаценні сеткі затрымка павялічыцца да дзвюх секунд ці трох секунд. Калі кліент не справіцца з прайграваннем, вопыт прамой трансляцыі будзе сур'ёзна закрануты. Як аптымізаваць, будзе расказана ў наступным артыкуле.
Выснова: пры выбары пратакола прамой трансляцыі, калі абраны RTMP альбо http-flv, гэта азначае, што затрымка змесціва складае 2-5 секунд, але, што тычыцца адкрытай затрымкі, http-flv лепш, чым RTMP . HLS мае затрымку змесціва 5-7 секунд. Выбар RTP для жывой трансляцыі можа адкласці жывую трансляцыю на працягу 1 секунды. Аднак, наколькі нам вядома, асноўныя вытворцы CDN не падтрымліваюць жывую трансляцыю на аснове RTP, таму ў цяперашні час асноўны айчынны канал - RTMP альбо http-flv.
2, Працэс відэатрансляцыі
Тэхнічны працэс, звязаны з жывым відэа, заключаецца ў: набыцці відэа патоку ў рэжыме рэальнага часу --- кадаванне відэа патоку --- перадача відэа патоку --- дэкадаванне відэа патоку --- прайграванне відэа.
1. Ідэя захопу відэа ў рэжыме рэальнага часу
а) Усталёўваючы setpreviewcallback у папярэднім праглядзе здымкі з камеры Android, рэалізаваны інтэрфейс onpreviewframe для захопу дадзеных кожнага відэа патоку ў рэжыме рэальнага часу.
б) З дапамогай медыярэгістратара Android прывяжыце localocket да функцыі setoutputfile.
в) рэжым трансляцыі медыя-сервера, выкарыстоўваючы ffmpeg або getstreamer для атрымання відэа з камеры.
2. Рэалізацыя кадавання відэакампрэсіі
а) Без кадзіравання зыходны відэакадр yuv420sp перадаецца непасрэдна праз сокет.
б) JEPG сціскае зыходны відэакадр yuv420sp у H.264, а затым перадае яго.
в) H.264 / аўт. Зыходны відэакадр yuv420sp сціскаецца ў H.264 і затым перадаецца. Агульныя кодэры з адкрытым зыходным кодам на аснове H264 ўключаюць JM, x264, t264, hdot264 і г.д.
г). mpeg4. Сцісніце зыходны відэакадр yuv420sp у MPEG4, а затым перадайце
3. Ідэя перадачы відэа
а). перадача разеткі
б). Транспарт HTTP
в). Перадача RTP / RTSP
г). рэжым струменевага мультымедыйнага сервера, напрыклад, live555 і г.д.
4. Рэалізацыя дэкадавання відэа
а). дэкодэр, адпаведны кадаванню
5. Ідэя прайгравання відэа
а). праз Android videoview
б). праз Android Mediaplay
в). ўставіць малюнак кадра непасрэдна праз палатно
|
Увядзіце адрас электроннай пошты, каб атрымаць сюрпрыз
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
катэгорыі
бюлетэнь