Flusonic mediálny server podporuje distribúciu videa cez protokol HLS.

Veľa z dostupné príležitosti nie sú štandardom pre HLS, ale pre vaše pohodlie ich podporujeme.

Podporované kodeky: H264, H265, MPEG2 video, AAC, MP3, MPEG2 audio, AC-3.

Flussonic Media Server vám umožňuje prijímať živé televízne vysielanie, video na požiadanie, video z archívu (catchup a timeshift) cez HLS.

Jednoduché prehrávanie HLS

Ak máte jednoduchý živý prenos alebo súbor (jedno video, jeden zvuk), potom je adresa URL na prehrávanie prostredníctvom HLS veľmi jednoduchá:

http://flussonic-ip/STREAMNAME/index.m3u8

kde flussonic-ip je príklad adresy + portu vášho servera Flussonic Media Server.

Flussonic Media Server tiež akceptuje playlist.m3u8 na konci URL pre spätnú kompatibilitu s inými servermi.

Keď začnete pracovať s viacjazyčným alebo viacbitovým obsahom, veci sa skomplikujú.

Viacjazyčné HLS

Ak chcete prehrávať viacjazyčný stream na iPhone, musíte použiť rovnaký http://192.168.2.3:8080/STREAMNAME/index.m3u8

Ale ak chcete sledovať viacjazyčný stream pomocou VLC alebo set-top boxu, musíte zahrnúť video.m3u8.

Adresa URL prehrávača: http://flussonic-ip/STREAMNAME/video.m3u8

Dôvodom je skutočnosť, že podľa požiadaviek Apple HLS musí byť pre každý jednotlivý jazyk určený samostatný zoznam skladieb s možnosťou len zvuku. MPEG-TS má iný mechanizmus: všetky zvukové stopy sú umiestnené vedľa videa a hráč si sám vyberie, čo sa bude prehrávať. Aby bolo možné video prezerať na iPhone, musí spĺňať smernice spoločnosti Apple. Ale VLC a set-top boxy v rozpore so štandardom HLS očakávajú starú verziu MPEG-TS konvertovanú na HLS. Preto musíte zahrnúť video.m3u8 .

Pridanie „Iba zvuk“ pre Apple

Apple vyžaduje, aby všetky vaše streamy mali možnosť bez videa, iba zvuku.

Veria, že ak používateľ sleduje video cez 3G a keď sa ocitne v zóne neistého príjmu, bude pre neho lepšie mať iba zvuk ako ukladať do vyrovnávacej pamäte.

Túto možnosť môžete povoliť na serveri Flussonic Media Server:

stream ort (url udp:// 239.0.0.1: 1234; add_audio_only;)

Uvedomte si, že to môže spôsobiť, že vašu adresu index.m3u8 nebude možné prehrať vo VLC alebo v set-top boxe. V takom prípade použite video.m3u8 .

Samostatné bitové rýchlosti pre set-top boxy

Ak máte multi-bitový viacjazyčný obsah a chcete ho prehrávať na set-top boxe, ktorý nepodporuje multi-bitové HLS zoznamy skladieb, môžete si vyžiadať jednotlivé zoznamy skladieb s jedným videom a všetkými zvukovými stopami zo servera Flussonic Media Server, ako v prípade mono možnosť:

http://flussonic-ip/STREAMNAME/video1. m3u8

Tento zoznam skladieb nie je multibitový, obsahuje URL na segmenty, v ktorých je prvá stopa videa a všetky dostupné zvukové stopy.

Ak chcete dodávať viacjazyčné toky s viacerými bitovými rýchlosťami do set-top boxov, ktoré nerozumejú viacjazyčnému štandardu spoločnosti Apple, použite video.m3u8:

http://flussonic-ip/STREAMNAME/video. m3u8

Toto je zoznam skladieb s viacerými bitovými rýchlosťami, ktorý poskytuje zoznam zoznamov skladieb s rôzne kvality: video1.m3u8, video2.m3u8 atď.

DVR catchup prehrávanie

Keď je váš stream už zaznamenaný na serveri pomocou nášho DVR, môžete video prehrať cez HLS s použitím času začiatku a konca prenosu (napríklad z EPG).

http://flussonic-ip/STREAMNAME/archive-1508403742-3600. m3u8

Tento zoznam skladieb bude tzv. variant, ak ich bude v streame viac zvuková stopa alebo viac ako jedna bitová rýchlosť. Uvedie segmenty začínajúce od UTC 1362504585 (5. marec 2013 17:29:45 GMT) a jednu hodinu dopredu.

Mono URL poskytne zoznam segmentov obsahujúcich všetky stopy v mpeg-ts:

http://flussonic-ip/STREAMNAME/mono-1362504585-3600. m3u8

Konkrétnejší zoznam videí N poskytne zoznam segmentov s N video stopou a všetkými zvukovými stopami:

http://flussonic-ip/STREAMNAME/video1-1362504585-3600. m3u8

a variantný zoznam videí so zoznamom zoznamov videí N:

http://flussonic-ip/STREAMNAME/video-1362504585-3600. m3u8

Pretočiť späť zoznam skladieb

K dispozícii je špeciálny zoznam skladieb "rewind-N.m3u8" s veľkým „posuvným“ oknom, ktoré umožňuje pretáčanie a pozastavenie streamov HLS na dlhé hodiny.

http://flussonic-ip/STREAMNAME/rewind-7200. m3u8

7200 - Dĺžka zoznamu skladieb HLS v sekundách. To znamená, že vaši zákazníci si môžu pozastaviť vysielanie na 2 hodiny alebo sa vrátiť na začiatok futbalového zápasu bez toho, aby sa dostali k špeciálnym archívnym odkazom.

Spracovaním, ukladaním a prenosom videa pre svoj online projekt namiesto používania stránok ako YouTube nevyhnutne prichádza k otázke, ktorý prenosový protokol použiť na vysielanie videa do zariadení používateľov. Výber je malý, pretože Existuje množstvo priemyselných štandardov, ktoré podporujú určité zariadenia. Okrem toho výber protokolu do značnej miery závisí od „triedy“ videa – živé vysielanie alebo video-on-demand. Výber mediálneho servera, ktorý bude motorom vášho mediálneho stroja, závisí aj od výberu protokolu: nainštalujete niekoľko heterogénnych serverov alebo vybudujete doručovaciu sieť založenú na jednom riešení? Preto musíte všetko zvážiť a rozhodnúť sa na základe kritérií vášho podnikania.

Vo všeobecnosti sa získa rovnica s mnohými neznámymi. Dynamika procesu je tu dôležitá – kam sa priemysel vo všeobecnosti uberá? Čo ak investujem do podpory technológie a tá o rok zomrie, lebo toto sa už stalo. Alebo vsadím na trendovú technológiu, ktorú však nikto nepodporuje?

Rozhodli sme sa zhodnotiť, ako sa v priebehu času menil podiel rôznych protokolov – pozrieť sa na celý proces v dynamike. Údaje boli prevzaté z minulého roka.

Počiatočné údaje

Pre začiatok, kto sme, aby sme posudzovali podiely na trhu? Sme vývojári webovej služby na podávanie správ pre mediálne servery. Na trhu pôsobíme už štvrtý rok a firmy k nám prichádzajú s rôznou infraštruktúrou, rôznym počtom serverov a rôznymi potrebami. Ukazuje sa dobré obsadenie stavu priemyslu.

Vytvorili sme malý prehľad, v ktorom si môžete vybrať rozsah dátumov a získať údaje s grafom o počte zhliadnutí videa prostredníctvom rôznych protokolov.

Správa poskytuje údaje o serveroch:

• Wowza Streaming Engine vo všetkých verziách od 2.2 po najnovšiu 4.x; najviac - 3.x.
• Naším vývojom je Nimble Streamer, ktorý pracuje s HLS, Smooth, HDS a progresívnym sťahovaním.
• Windows Media Services - je ich doslova niekoľko desiatok, ale existujú a musíme ich vziať do úvahy

V čase písania tohto článku služba obsluhuje približne 1 000 serverov zo 60 krajín.

Správa je tiež pravidelne aktualizovaná na našom blogu, je dostupná pod príslušnou značkou.

Choď

Správa za jún/júl 2014 vyzerá asi takto. Od 1,4 miliardy zobrazení viac ako polovica sú HLS. Na druhom mieste je RTMP so štvrtinovým počtom zobrazení. RTSP je asi šestina. Zvyšok je v oblasti štatistickej chyby.

Čo sa stalo pred rokom za rovnaké obdobie? Situácia je takmer zrkadlovým obrazom. RTMP - takmer dve tretiny, o druhé a tretie miesto sa delia RTSP a HLS. Je pravda, že základ pre merania bol takmer 3-krát menší - "len" 500 miliónov videní. V našej službe bolo samozrejme aj menej serverov.

Poďme medzi tieto dva body.

Takže jún - august 2014, 3 mesiace leta. 800 miliónov videní, no podiely sú rovnaké, august nepriniesol žiadne zmeny.

September - november 2013. Začala sa nová sezóna, HLS začala zožrať podiel RTMP. Celkom 1,1 miliardy zobrazení, RTMP má asi polovicu z celkového počtu, HLS štvrtinu.

December 2013 – Február 2014. 1,4 miliardy zobrazení, z čoho HLS tvorí viac ako 40 %. RTMP a RTMP sú na druhom a treťom mieste so štvrtinovým podielom. Olympiáda v Soči priniesla nárast počtu zobrazení a zároveň prinútila poskytovateľov, aby si spomenuli na všetkých zákazníkov so všetkými ich exotickými alebo starými zariadeniami, ktoré rozumejú iba RTSP - preto skok v tomto protokole.

Ako ukázala prax, najlepší prenos videa v porovnaní s RTMP je HLS. Dôvody:

Veľmi jednoduché proxy, s cachovaním cez nginx. V prvom rade preto, že kamera ako zariadenie spravidla nedokáže obslúžiť viac ako 10 spojení súčasne. V tomto zmysle je zaručené proxy streamovanie RTMP možné iba prostredníctvom platených riešení a vyžaduje si veľa energie. Nie je potrebný žiadny špeciálny serverový softvér.

Zjednodušenie celej serverovej infraštruktúry. Na základe nápadu sa video poskytuje po častiach cez port 80 cez http. Za vrátenie statiky môže samotný Nginx. Vrátenie statiky (kúsky videa 50 kB) je pre nginx veľmi jednoduchá úloha.

Keďže počet kusov je konštantný, staré sa odstraňujú, pridávajú sa nové, HDD nikdy nepretečie.

Prevalencia je väčšia ako prevalencia RTMP. HLS s kódovaním videa H.264 je podporované systémom iOS a funguje bez problémov. Od 1. júla 2014 sú streamingové video pripojenia s transportom HLS 55 %, RTMP – 26 %, RTSP – 15 % a MPEG-DASH menej ako 1 %.

Väčšinovú podporu mobilné zariadenia, desktopy, tabletové počítače priamo z prehliadača.

Oveľa jednoduchšie ako vysielanie v RTSP v princípe. Keďže neexistujú žiadne postupy ako push (zverejnenie streamu) alebo pull (získanie streamu).

Oveľa viac priateľský formát http.

Nevýhody sú nasledovné:

Napriek tomu nie všetky zariadenia podporujú tento formát. Verzie Androidu menej ako 4.2 oficiálne nepodporuje kodek a transport H.264, ale v systéme Android namiesto prehliadača môžete použiť aplikácie tretej strany- napríklad MX Player

Všetko závisí od fotoaparátu. Ak je kamera zabugovaná, napríklad Dlink DCS-3010, celý systém bude fungovať veľmi zle (ffmpeg neustále vypadáva). Napríklad kamery AXIS M1011-W, HIKVISION DS-2CD2412F-IW fungujú dobre v takomto balíku (až mesiac bez akýchkoľvek sťažností (len som to dlhšie netestoval)). Tiež veľký význam má vedenie káblov. V tomto zmysle zvážime ideálnu možnosť.

Čo je to doprava HLS

Video stream kódovaný h.264 (Mimochodom: základný profil profilu rozumie zariadenia so systémom Android), je rozdelený na časti s príponou *.ts, napríklad po 5 sekundách, v live.m3u8 sa vytvorí zoznam skladieb s postupným popisom týchto častí. Dĺžka playlistu je vopred určená, napríklad 10 kusov. Keď sa zobrazí 11. časť videa, 1. časť videa sa odstráni a zoznam videí sa vytvorí znova. Viac podrobností nájdete na stránke vývojára.

Aby systém fungoval, nastavíme obraz z kamier tak, ako ho chceme vidieť na stránke, formát obrazu a kvalitu obrazu. Na serveri nebudeme prekódovať. Fotoaparát je navrhnutý tak, aby poskytoval obraz, ktorý potrebujete. Fotoaparáty majú zvyčajne niekoľko profilov. Jeden profil môžete nakonfigurovať pre H.264 pre HLS a druhý s MPEG4 pre MPEG-DASH. Môžete tiež nastaviť rôznu kvalitu pre široký a úzky internetový kanál. Myslite na seba - rozhodnite sa sami.

Dôležité! Kamera by mala mať výstupný obraz, ktorý nie je potrebné prekódovať.

Konštrukčný diagram pre vysoké zaťaženie

Fotoaparát (rtsp) ----->

-----> jedno pripojenie FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> jedno pripojenie k strednému proxy nginx s veľkou vyrovnávacou pamäťou =====>

=====> veľa klientov JWPlayer(hls).

Náš server sa pripojí pomocou ffmpeg ku kamere a zaregistruje sa v aplikácii nginx hls. nginx vytvorí skladby a zoznam skladieb v konkrétnom adresári. Potom tieto kusy odošle na proxy server. Klienti sa pripájajú k proxy serveru pomocou JWPlayer.

Nastavenie aplikácie nginx

Poďme zostaviť nginx pomocou modulu nginx-rtmp. Tento postup je podrobne popísaný v článku.

Povedzme, že máme niekoľko fotoaparátov, rozdelíme ich podľa sériového čísla. Popíšem konfiguráciu nginx pre 2 kamery. Statické obrázky ukladáme na 5 minút do lokálnej vyrovnávacej pamäte, ak sa obrázok nenačíta do 5 sekúnd, dáme statickú úvodnú obrazovku.

# nano /etc/nginx/nginx.conf

Upravte konfiguráciu nginx

užívateľské www-údaje; worker_processes auto ; pid/run/nginx. pid ; error_log / var / log / nginx / nginx_error . ladenie denníka; env PATH; udalosti ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error. log ; include mime . types ; default_type application / octet - stream ; sendfile on ; keepalive_timeout 65 proxy_cache_path / var / www / cache / miestne úrovne = 1 : 2 keys_zone = nginx_local_cache : 1 m neaktívny = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; server (počúvanie 80; # rt mp stat location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # stat. xsl môžete presunúť na iné miesto root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 50 x .html ;location = / 50 x .html ( root html ; ) include cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( listen 1935 ; ping 30 s ; notify_method ) vrátane cameras_rtmp_applications . conf ; ))

Vytvorte cestu k vyrovnávacej pamäti # mkdir /var/www/cache/local Opravte povolenia vyrovnávacej pamäte:

# chmod -R 755 /var/www/cache/local # chown -R www-data:www-data /var/www/cache/local`

Vytvorme http miesta pre kamery:

# nano kamery_http_locations.conf

typy ( application / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # dať obrázok z kamery 1 - /1/img/ # sú odlišné pre všetky fotoaparáty, pretože IP adresy fotoaparátu sú rôzne "http://192.168.0.2/GetImage.cgi?CH=1"# dať obrázok z kamery 2 - /2/img/ umiestnenie / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; vyprší 1 m ; # cache na 1 minútu add_header Cache - Control public ; # do cache na proxy proxy_ignore_headers Cache - Control ; # na odstránenie hlavičiek z kamery proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Autorizácia "Základné" ; error_page 502 504 404 @ fallback_img ; ) # dajte zoznam skladieb - /1/hls/live.m3u8 alebo /3/hls/live.m3u8 # zoznam skladieb sa uloží do vyrovnávacej pamäte na 10 sekúnd na serveri proxy umiestnenie ~* / hls / . * \ . m3u8 $ ( prepíšte "/(.*)/hls/(.*)$" / hls - 1 $ / 2 $ prestávka ; # žiadosť o prepísanie / 1 / hls / do / hls - 1 / root / tmp / ; platnosť vyprší 10 s ; add_header Cache - Control public ;) # daj kúsok videa z kamier - /1/hls/live-12345678.ts alebo /2/hls/live-12345678.ts # ukladanie do vyrovnávacej pamäte lokálny počítač nevyžaduje sa # diel sa uloží do vyrovnávacej pamäte na 3 minúty na serveri proxy umiestnenie ~* / hls / . * \ . ts $ ( prepíšte "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; expiruje 3 m ; add_header Cache - Control public; ) # pomenované miesto, ak neexistuje žiadny obrázok umiestnenie @ fallback_img ( prepísať (. + ) / fallback . jpg break ; root / etc / nginx / ; )

Vytvorme konfiguračný súbor hls pre server rtmp s aplikáciami pre naše kamery:

# nano cameras_rtmp_applications.conf

chunk_size 4000 ; aplikácia hls_1 ( zapnutá ; synchronizácia 10 ms ; exec_static ffmpeg - i rtsp : //admin: [e-mail chránený]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls na ; hls_path / tmp / hls - 1 / ; # cesta pre ukladanie kusov na serveri hls_fragment_naming timestamp ; # use timestamp to name chunks ) application hls_2 ( live on ; synchronizácia 10 ms ; exec_static ffmpeg - i rtsp : //admin: [e-mail chránený]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls na ; hls_path / tmp / hls - 2 / ; hls_fragment_nameming timestamp ; )

Obsah adresára /tmp/hls-1/

$ ls / tmp / hls - 1 / naživo - 10458360. ts naživo - 13292010. ts naživo - 16129440. ts naživo - 18963270. ts naživo - 10930050. ts naživo - 13616733 -50. 0 50. ts live - 11405250. ts live - 14239260. ts live - 17072820. ts live . m3u8 live - 11878560. ts live - 14710860. ts live - 17544960. ts live - 12348630. ts live - 15182550. ts live - 18020160. ts live - 68 -12821 ts live - 68 41821 6 4 92750.ts

Príklad súboru live.m3u8

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, live - 16602660. ts #EXTINF:5.246, live - 17072820. ts #EXTINF :5,280, naživo - 17544960. ts #EXTINF:5,251, naživo - 18020160. ts #EXTINF:5,228, naživo - 18492750. ts #EXTINF:5,242, naživo - 18963270. ts

Riešenie problému s padajúcimi kamerami

Väčšina správne riešenie, vymeňte buggy fotoaparát. Pomáha to 90% času. Ak nie je cesta a potrebujete nejako žiť ďalej, potom pomôže nasledujúce riešenie.

Toto riešenie pozostáva z dvoch – doplnkových:

Spustite samostatný proces nginx pre každú kameru a všeobecný proces o návrate statickej. To znamená, že pre dve kamery napíšte samostatné konfigurácie so servermi rtmp a jednu spoločnú s http. Potom buggy kamera neovplyvní celkový proces.

Ak je stream z kamery prerušený v dôsledku jej buggy (prehriatie, zlé zapojenie, nedostatočné napájanie cez PoE atď.), kamera spadne, detský proces ffmpeg odmietne pakety a nginx prestane zapisovať časti videa . A keď sa proces ffmpeg skončí, nginx odstráni všetky súbory z adresára chunks. Vypočítame tento moment čistenia priečinka cron a reštartujeme potrebný proces nginx.

Pre každú kameru sa vytvorí spustiteľný skript v /etc/init.d/, kópia nginx s názvom camera_1 a camera_2

# cp /etc/init.d/nginx /etc/init.d/camera_1 # cp /etc/init.d/nginx /etc/init.d/camera_2 # chmod +x /etc/init.d/camera_1 # chmod +x /etc/init.d/camera_2

Úprava spúšťacieho skriptu nginx.

nano /etc/init. d/nginx

Zmeňte premennú DAEMON_OPTS. Hlavný démon nginx bude slúžiť všetkým statickým. Taktiež spustí a zastaví démonov zodpovedných za kamery. / init . d /camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; potom /etc/init. d/camera_2 stop fi

Pridajte do funkcie do_reload:

# znovu načítať kamery, ak [ - f "/etc/init.d/camera_1" ]; potom /etc/init. d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ]; potom /etc/init. d/camera_2 znovu načítať fi

Upravujeme spúšťací skript nginx pre kameru 1 camera_1 a pre kameru 2 camera_2 podľa príkladu.

# nano /etc/init.d/camera_1

Zmena premenných DAEMON_OPTS a DESC

DESC = "kamera_1 pre CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Upravujeme spúšťací skript nginx pre kameru 2 camera_2 podľa príkladu.

V /etc/nginx/nginx_0.conf s http umiestneniami píšem magické čiary:

# DIR-PROCESS-NAME /tmp/hls-1/camera_1 # DIR-PROCESS-NAME /tmp/hls-2/camera_2

Označujú hľadané slovo DIR-PROCESS-NAME oddelené medzerou, adresár a názov procesu, ktorý sa má reštartovať.

Vyšetrenie:

# spustenie služby nginx # reštart služby camera_1 * Reštartovanie kamery_1 pre KAMERU - 1 konfigurácia nginx # reštart služby kamera_2 * Reštartovanie kamery_2 pre KAMERU - 2 konfigurácia nginx

Skript, ktorý znova načíta kamery. Prechádza cez priečinky chunk a hľadá, kde nie sú súbory *.m3u8. Ak sa v priečinku nenachádzajú žiadne súbory, vyhľadá zodpovedajúceho démona podľa konfigurácie hlavného démona podľa riadku DIR-PROCESS-NAME . Znova to načíta.

# nano /script/cameras_reloader.sh

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#!/bin/bash PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin mask = "*.m3u8" dir = "/tmp/ hls-*" funkcia find_process()( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) pre hls_dir v $dir ; do find_result = $(find $hls_dir -name $mask -type f) if [ -z $find_result ] ; potom proces = $(find_process $hls_dir ) služba $proces reštart fi hotovo spánok 15s

Porovnanie HLS s MPEG-DASH

MPEG-DASH je analóg HLS vytvorený spoločnosťou Google, ako prenos pre MPEG-4. Táto preprava nie je rozšírená a prakticky nie je podporovaná. Jeho ideológia je rovnaká, rozdeľte prúd na kúsky, len viac kusov, oddelené kusy pre video, samostatné kusy pre zvuk. V nginx-rtmp-module je tento formát nakonfigurovaný podobne ako HLS.

Skúšajte, kopírujte, choďte do toho!

Ak bol pre vás článok užitočný, kliknite na inzerát. Ďakujem!

Vytváranie technicky ideálnych aplikácií je zvyčajne mimoriadne zložitá a časovo náročná úloha. Zároveň sú užitočné informácie často rozptýlené vo viacerých zdrojoch. Týka sa to okrem iného aj vývoja videoaplikácií pre iOS. Tento článok obsahuje najdôležitejšie a najužitočnejšie informácie, ktoré vám umožňujú kvalitatívne využívať celý rad funkcií HTTP Live Streaming, ako aj zoznam primárnych zdrojov. Tieto materiály budú užitočné pre všetkých čitateľov, ktorí sa zaujímajú o vytváranie kvalitných a užívateľsky prívetivých video služieb.

Posilnenie pohodlia a interaktivity video služieb sa dosahuje prostredníctvom rýchly štart a prevíjanie dozadu, ako aj nedostatok vyrovnávacej pamäte. Na dosiahnutie najlepšieho výsledku sa odporúča nasledujúci súbor akcií.

• Počnúc nízkou kvalitou videa. Na spustenie videa je potrebný aspoň jeden blok. V súlade s tým, čím menšia je veľkosť jedného kusu, tým rýchlejšie sa video spustí. Zníženie bitovej rýchlosti úvodného streamu a skrátenie trvania časti vedie k rýchlejšiemu spusteniu videa. Odporúčame trvanie bloku 4 – 8 sekúnd a počiatočnú bitovú rýchlosť 200 – 300 kb/s. Na spustenie prehrávania videa si teda používateľ bude musieť stiahnuť maximálne 300 kb.
• Optimalizácia zoznamu skladieb. Zoznamy skladieb môžu zaberať významnú časť celkového toku údajov, najmä pri malých veľkostiach a dlhom obsahu (niekoľko hodín). Vo väčšine prípadov sa pri prenose zoznamov skladieb do prehrávača videa odporúča archivovať ich.
• kľúčové rámy. Je žiaduce mať aspoň jeden IDR rámec na segment, výhodne na samom začiatku segmentu. Navyše pri prenose videa do celulárne siete odporúča sa vytvoriť kľúčovú snímku aspoň raz za 3 sekundy.
• Réžia TS. HTTP LS používa MPEG TS ako kontajner, takže je veľmi dôležité minimalizovať réžiu TS (mala by byť menšia ako 10 % aj pri nízkej kvalite videa). V tomto prípade sa oplatí merať reálne bitové rýchlosti pomocou dopravných výpisov a optimalizovať použité packery (segmenty).
• Parameter cieľového trvania v zozname skladieb. Tento parameter ovplyvňuje čas spustenia, ale spoločnosť Apple odporúča nastaviť ho na 10 sekúnd, pretože nižšie hodnoty zvyšujú možnosť ukladania do vyrovnávacej pamäte, najmä v mobilných sieťach s vysokou latenciou. Neodporúča sa vytvárať ani segmenty, ktoré sú dlhšie ako 20 sekúnd.
• dynamická bitová rýchlosť. Mechanizmus adaptívneho streamovania zabudovaný do iOS funguje optimálne pri presne špecifikovaných bitových rýchlostiach vo variantnom playliste (berúc do úvahy návštevnosť samotného playlistu). V tomto prípade pre toky s meniacou sa bitovou rýchlosťou musíte zadať hodnotu bližšie k maximu. V opačnom prípade sú možné nesprávne rozhodnutia o zmene aktuálneho toku videa. Susedné bitové rýchlosti by sa mali líšiť rýchlosťou 1,5 - 2 krát.
• Streamuje „iba zvuk“. Zvukový kodek HE-AAC je výrazne efektívnejší a podporuje ho väčšina zariadení. Doručovanie iba zvukových kanálov sa odporúča implementovať pomocou elementárneho toku MPEG a nie prenosového toku MPEG (oveľa menšia réžia).

Pri vývoji prehrávača videa môžete získať užitočné informácie z denníka HTTP Live Streaming (accessLog). Obsahuje údaje o tom, ako prebiehalo automatické prepínanie, aké boli použité bitrate atď. Podrobnosti o informáciách dostupných v denníku. Na základe týchto údajov budete môcť zhromažďovať analytické údaje o vašich používateľoch.

Ďalšie odporúčania
V prípade online vysielania je ukladanie videa do vyrovnávacej pamäte možné aj kvôli oneskoreniam v CDN, ako aj v prípadoch, keď je čas aktualizácie zoznamu skladieb príliš krátky a server nestihne generovať segmenty včas. Na optimalizáciu mechanizmu prevíjania sa odporúča použiť neceločíselné (skutočné) hodnoty trvania segmentu, inak sa môže nahromadiť chyba.

Ak je vaša aplikácia určená na použitie na rôzne zariadenia, v zozname môžete určiť rôznu kvalitu videa pri rôznych rozlíšeniach obrazovky. Takto si budete môcť zobraziť rôzne videá na iPade s Retina displejom a na pomerne starom iPhone.

Protokol HTTP Live Streaming tiež poskytuje mechanizmy prepnutia (označenie redundantných zdrojov videa). Táto funkcia môže byť užitočná na zlepšenie spoľahlivosti vašich služieb.

Zdroje poznania
Krátky zoznam zdrojov o používaní HTTP Live Streaming vo video aplikáciách:
Koncept HTTP Live Streaming
HTTP Live Streaming – často kladené otázky
Osvedčené postupy pre HLS

Nakoniec stojí za zmienku, že pre registrovaných vývojárov Mac/iOS/Safari zadarmo technické videá sedení s WWDC 2012, kde je tiež veľa užitočná informácia, najmä - o práci s videom a používaní HTTP Live Streaming.

Poskytovanie služieb IP TV cez internet a lokálne počítačové siete je čoraz rozšírenejšia. Na území krajín SNŠ takmer neexistujú veľkí poskytovatelia, ktorí nevysielajú video cez multicast do svojich lokálnych sietí, teda tých, ktorí službu poskytujú IPTV. Ale poskytovanie TV služby mimo jej lokálna sieť spojené s niektorými nákladmi na hardvér a zložitosťou poskytovania požadovanej kvality vysielania.

HTTP Live Streaming taktiež známy ako HLS, je implementovaný komunikačný protokol spoločnosťou Apple. Jeho zvláštnosťou je, že celkový tok je rozdelený do postupnosti malých sťahovaných súborov, pričom každé sťahovanie stiahne jeden malý fragment transportného toku. Keď sa stream prehráva, klient si môže vybrať z niekoľkých rôznych alternatívnych tokov obsahujúcich rovnaký materiál, zaznamenaných pri rôznych bitových rýchlostiach, čo mu umožňuje prispôsobiť sa dostupnej bitovej rýchlosti. Na začiatku relácie streamovania sa načíta rozšírený zoznam skladieb M3U (m3u8) obsahujúci metadáta pre rôzne dostupné podstreamy. Keďže požiadavky používajú iba štandardné operácie HTTP, HTTP Live Streaming dokáže obísť akúkoľvek bránu firewall alebo proxy server, ktorý umožňuje štandardnú komunikáciu HTTP, na rozdiel od protokolov UDP, ako je napríklad RTP.

HLS je založený na HTTP. HLS tiež definuje štandardný mechanizmus šifrovania pomocou AES a spôsob distribúcie bezpečnostného kľúča pomocou HTTPS alebo HTTP cookies, ktoré spoločne poskytujú jednoduchý systém ochranu autorských práv.

Princíp činnosti HLS

Teraz poďme zistiť, aké sú výhody a nevýhody tejto technológie. Výhody sú nepopierateľné a zrejmé. Ide v prvom rade o prispôsobivosť rýchlosti prenosu dát vlastnostiam linky a prijímacieho zariadenia a v druhom rade o zabudované mechanizmy ochrany autorských práv. Po tretie, nie je potrebný smerovač s obmedzenou šírkou multicast stream cez WI_FI, čo by pomohlo vyhnúť sa absorpcii celej šírky kanála multicastovými tokmi v prípade vysielania IP televízie pomocou multicastu. Nevyžaduje ani prídavné zariadenie s funkciou UDP proxy na konverziu multicastového toku na HTTP, čo sa často vyžaduje pre mobilné zariadenia, hoci to ovplyvňuje hardvérové ​​zaťaženie smerovača alebo iného zariadenia, ktoré vykonáva funkciu UDP proxy v lokálnej sieti predplatiteľa. Štandard HLS sa stal pomerne bežným a podporujú ho takmer všetky moderné videoprehrávače a set-top boxy pre IPTV.

IPTV set-top box

Významnou nevýhodou je, že predplatitelia majú multimediálne set-top boxy a smart-tv set-top boxy so zastaraným firmvérom alebo zastaraným dizajnom, ktoré nepodporujú štandardy HLS alebo ich nepodporujú správne. Jedným z problémov je tiež neschopnosť zvoliť správnu kvalitu pre stabilné vysielanie v podmienkach meniacich sa charakteristík linky v časových intervaloch kratších ako je trvanie požadovaného video fragmentu.