HLS tehnologija. HTTP Live Streaming: najbolji recepti. Kada koristiti HLS za online emitiranje

U posljednjih nekoliko godina došlo je do velikih promjena u svijetu digitalnog emitiranja. Flash, tehnologija za isporuku sadržaja putem interneta koju je razvio Adobe, ubrzano smanjuje svoju prisutnost. A njegovo mjesto zauzimaju protokoli poput HLS-a.

HTML5 i HLS su otvorenog koda, mogu se mijenjati po želji i besplatni su za korištenje. Također su sigurniji, pouzdaniji i brži od svojih prethodnika. U ovom ćemo članku pokušati objasniti koncepte online emitiranja, dati opis protokola za strujanje i preporuke za korištenje HLS-a.

Što je HLS

HLS je kratica za HTTP Live Streaming, protokol za strujanje medijskih podataka putem Interneta. HLS reže video sadržaj u MP4 formatu u kratke blokove od 10 sekundi, dijelove. Ovi kratki fragmenti isporučuju se preko HTTP-a, čineći protokol kompatibilnim s većinom uređaja i vatrozida.

HLS prvenstveno osigurava izvrsnu kvalitetu online prijenosa. No, morate uzeti u obzir da je kašnjenje tijekom online emitiranja 15-30 sekundi. Na strani poslužitelja, kreator emitiranja može dodijeliti kodiranje streama u nekoliko kvaliteta. Igrač tada dinamički zahtijeva optimalnu kvalitetu na temelju širine internetskog kanala u određenom trenutku. Sukladno tome, kvaliteta fragmenata može varirati.

Na primjer, mobilni telefon reproducira video u HD kvaliteti, a minutu kasnije gledatelj se nađe u području lošeg prijema. Kada uređaj za reprodukciju otkrije smanjenje kvalitete veze, zahtijeva video dijelove niže kvalitete. To smanjuje međuspremnik, zamrzavanje i druge probleme.

Povijest stvaranja HLS-a

Apple je izvorno pokrenuo HLS u ljeto 2009. zajedno s iPhoneom 3. Prethodni modeli iPhonea imali su problema s online emitiranjem zbog činjenice da su ponekad prelazili s Wi-Fi mreže na mobilni prijenos podataka i obratno.

Prije izlaska HLS-a, Appleov glavni protokol za strujanje medija bio je Quicktime Streaming Server. Dobra usluga, ali budući da je koristio nestandardne priključke za prijenos podataka, njegov RTSP protokol povremeno su blokirali vatrozidi. Zajedno sa sporim internetom, to je dovelo do napuštanja ovog protokola. Ali lekcije naučene iz njegove primjene bile su vrlo korisne u razvoju HLS-a.

HLS stream se kreira u hodu i pohranjuje na HTTP poslužitelju. Video datoteke, kao što je gore spomenuto, podijeljene su u kratke fragmente s ekstenzijom .ts - MPEG2 Transport Stream.

HTTP poslužitelj također stvara datoteku popisa za reprodukciju s ekstenzijom .M3U8 (također se naziva manifest), koja služi za indeksiranje svih dijelova videozapisa. Ova datoteka popisa za reprodukciju ukazuje na dodatne datoteke indeksa za svaku od postojećih kvaliteta emitiranja. Čak i ako odlučite emitirati koristeći jednu kvalitetu, "manifest" će se svejedno stvoriti.

Korisnikov igrač mora prepoznati pogoršanje ili poboljšanje brzine prijenosa podataka na internetu. Kada se takav događaj dogodi, igrač pristupa datoteci manifesta kako bi odredio na koju će kvalitetu videozapisa prijeći. Player zatim zahtijeva indeksnu datoteku specifičnu za kvalitetu za učitavanje dijela videa na kojem se gledatelj zaustavio. Cijeli ovaj proces korisniku je nevidljiv. HLS protokol također podržava zatvorene titlove,

Pregled protokola za strujanje

Svaki od prethodno kreiranih protokola predstavljao je implementaciju neke inovacije u strujanju medija. Bilo je i "ratova formata", poput HD-DVD protiv Blu-Raya i Betamaxa protiv VHS-a. HLS je lider u online emitiranju, no nije uvijek bilo tako i nije činjenica da će tako ostati iu budućnosti.

RTMP ili Real-Time Messaging Protocol, protokol za strujanje podataka u stvarnom vremenu. Macromedia je stvorena sredinom 2000. godine za isporuku audio i video sadržaja. Često se naziva jednostavno Flash. Macromedia se kasnije spojila s tvrtkom Adobe Inc, koja nastavlja razvijati RTMP kao poluotvoreni protokol.

U posljednjem desetljeću RTMP je bio dominantna metoda emitiranja putem Interneta. Tek s dolaskom HLS-a njegov se udio počeo smanjivati. Danas većina online video platformi radi s dolaznim RTMP streamom. Drugim riječima, emitirate u RTMP-u, koji online video platforma zatim kodira u HLS i isporučuje krajnjim gledateljima. Istina, mnogi CDN operateri počinju napuštati RTMP podršku - dokaz

Protokol strujanja sljedeće generacije koji je razvio Adobe zove se HDS - HTTP Dynamic Streaming. Kompatibilan je s dodatkom za reprodukciju Flasha, ali je učestalost njegove upotrebe mnogo niža od uobičajenog HLS-a.

Za uređaje i preglednike koji podržavaju Flash, HDS je najbolji izbor. Omogućuje minimalno kašnjenje tijekom emitiranja, baš kao i HLS, dijeli medijske datoteke u male fragmente, podržava šifriranje i DRM.

Microsoft Smooth Streaming

Microsoft je stvorio vlastiti mrežni protokol za strujanje, Microsoft Smooth Streaming. MSS također koristi prilagodljivu brzinu prijenosa za isporuku sadržaja u najboljoj mogućoj kvaliteti.

Emitiranje s prilagodljivom brzinom prijenosa uvedeno je 2008. MSS je korišten za prijenos Ljetnih olimpijskih igara 2008. Glavni korisnik ove vrste emitiranja je platforma XBox One. Istovremeno, MSS je danas jedan od najmanje popularnih protokola.

MPEG-DASH

Jedno od najnovijih značajnih rješenja u području streaming protokola je MPEG-DASH, gdje DASH označava Dynamic Adaptive Streaming over HTTP.

Prednost MPEG-DASH-a je u tome što je prepoznat kao jedinstveni međunarodni standard za emitiranje medija putem HTTP-a. Trenutno još nije široko rasprostranjen i ne podržavaju ga svi emiteri. No, po svemu sudeći, za nekoliko godina upravo će ovaj standard postati najpopularniji protokol za emitiranje.

MPEG-DASH ne ovisi o vrsti kodeka, možete koristiti bilo koji od njih za slanje medija pomoću ovog protokola - H.264, HEVC/H.265, VP10

Kada koristiti HLS za online emitiranje

    Preporučujemo korištenje HLS-a cijelo vrijeme. To je najmoderniji i najšire podržan protokol za strujanje medija. Bez toga ne možete ako želite emitirati na mobilne uređaje. Izvorna podrška za HTML5 player i, naravno, prilagodljiva brzina prijenosa jamče optimalnu kvalitetu gledanja.

    Kao što je praksa pokazala, najbolji prijenos za video u usporedbi s RTMP-om je HLS. Razlozi za to:

    Vrlo jednostavan proxy, s predmemoriranjem putem nginxa. Prije svega zato što kamera kao uređaj u pravilu ne može nositi više od 10 veza istovremeno. U tom smislu, zajamčeno proxy RTMP streamova moguće je samo putem plaćenih rješenja i zahtijeva velike kapacitete. Nije potreban poseban poslužiteljski softver.

    Pojednostavljenje cjelokupne poslužiteljske infrastrukture. Po ideji, video se šalje u komadima, preko porta 80 preko http-a. Sam Nginx može biti odgovoran za isporuku statičkih podataka. Vraćanje statičkih datoteka (videokomada od po 50 kB) vrlo je lak zadatak za nginx.

    Podrška za većinu mobilnih uređaja, stolnih računala i tableta izravno iz preglednika.

    Načelno puno jednostavnije od emitiranja putem RTSP-a. Budući da ne postoje takve procedure kao što su push (objavljivanje streama) ili pull (primanje streama).

    Mnogo više http friendly format.

Nedostaci su sljedeći:

    Ipak, ne podržavaju svi uređaji ovaj format. Android verzije manje od 4.2 službeno ne podržavaju H.264 kodek i transport, ali na Androidu umjesto preglednika možete koristiti aplikaciju treće strane za gledanje - na primjer MX Player

    Sve ovisi o kameri. Ako je kamera buggy, na primjer Dlink DCS-3010, tada će cijeli sustav raditi vrlo loše (ffmpeg stalno pada). Na primjer, kamere AXIS M1011-W, HIKVISION DS-2CD2412F-IW rade dobro u ovoj kombinaciji (do mjesec dana bez pritužbi (samo nisam testirao duže)). Usmjeravanje kabela također je od velike važnosti. U tom smislu, razmotrit ćemo idealnu opciju.

Što je HLS transport

Video stream u h.264 kodiranju (Usput: osnovnu liniju profila razumiju Android uređaji), podijeljen je na dijelove s ekstenzijom *.ts, na primjer, svaki po 5 sekundi, popis za reprodukciju stvoren je u live.m3u8, s sekvencijalni opis tih komada. Duljina playliste je unaprijed određena, na primjer 10 komada. Kada se pojavi 11. dio videozapisa, 1 dio videozapisa se briše, a popis za reprodukciju ponovno se stvara. Više detalja možete pronaći na web stranici programera.

Da bi sustav radio, sliku s kamera ćemo konfigurirati onako kako želimo da se vidi na stranici, format slike i kvalitetu slike. Nećemo rekodirati na poslužitelju. To je razlog zašto je kamera izumljena da proizvede sliku koja je potrebna. Kamere obično imaju nekoliko profila. Možete konfigurirati jedan profil za H.264, za HLS, a drugi s MPEG4 za MPEG-DASH. Također možete konfigurirati različite kvalitete za široki i uski internetski kanal. Razmislite sami - odlučite sami.

Važno! Kamera bi trebala ispisati sliku koju nije potrebno ponovno kodirati.

Blok dijagram za velika opterećenja

Kamera (rtsp) ----->

-----> jedna veza FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> jedna veza na srednji nginx proxy s velikom predmemorijom =====>

=====> mnogo JWPlayer(hls) klijenata

Naš poslužitelj se pomoću ffmpeg povezuje s kamerom i prijavljuje se na nginx hls aplikaciju. nginx stvara komade i popis pjesama u određenom direktoriju. Zatim šalje te dijelove proxy poslužitelju. Klijenti se povezuju na proxy koristeći JWPlayer.

Postavljanje nginx aplikacije

Izgradimo nginx s nginx-rtmp-modulom. Ovaj postupak je detaljno opisan u članku.

Recimo da imamo nekoliko kamera, podijelimo ih po serijskom broju. Opisat ću nginx konfiguraciju za 2 kamere. Statične slike spremamo u lokalnu predmemoriju na 5 minuta; ako se slika ne učita unutar 5 sekundi, šaljemo statički čuvar zaslona.

# nano /etc/nginx/nginx.conf

Uredimo nginx konfiguraciju

korisnički www-podaci;

radni_procesi automatski;

pid/run/nginx. pid; error_log /var/log/nginx/nginx_error. zapisnik otklanjanja pogrešaka;

env PUT;

događaji ( # multi_accept on ; ) http ( access_log / var / log / nginx / access. log ; error_log / var / log / nginx / error . log ; uključi mime . tipove ; default_type aplikacija / oktet - stream ; sendfile uključen ; keepalive_timeout 65 ; proxy_cache_path / var / www / cache / local levels = 1 : 2 keys_zone = nginx_local_cache : 1 m inactive = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ( listen 80 ; # rtmp stat location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # možete premjestiti stat . xsl na drugu root lokaciju / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html;location=/50x.html(root html;) include cameras_http_locations) rtmp(access_log/var/log/nginx/rtmp_access.log;poslužitelj (slušaj 1935; ping 30 s; notify_method);

uključite cameras_rtmp_applications. konf; ) ) Kreirajmo put za predmemoriju # mkdir /var/www/cache/local Ispravimo prava za predmemoriju: # chmod -R 755 /var/www/cache/local# chown -R www-data:www-data /var/www/cache/local` Kreirajmo http lokacije za kamere: # nano kamere_http_locations.conf; proxy_set_header Autorizacija "Osnovno" ; error_page 502 504 404 @ rezervna_img;) # dajte playlistu - /1/hls/live.m3u8 ili /3/hls/live.m3u8 # popis za reprodukciju je predmemoriran 10 sekundi na proxyju mjesto ~* /hls/ . *\. m3u8 $ ( prepiši "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; # zahtjev za prepisivanjem / 1 / hls / u / hls - 1 / root / tmp / ; ističe 10 s ; add_header Cache - Kontrola javnosti ;# dajte dio videa s kamera - /1/hls/live-12345678.ts ili /2/hls/live-12345678.ts # predmemoriranje na lokalnom računalu nije potrebno# dio je predmemoriran 3 minute na proxyju

mjesto ~* /hls/ . *\. ts $ ( rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; ističe 3 m ; add_header Cache - Control public ; )

# imenovana lokacija ako nema slike

lokacija @fallback_img (rewrite(.+)/fallback.jpg break; root/etc/nginx/;) Kreirajmo hls datoteku za konfiguraciju rtmp poslužitelja s aplikacijama za naše kamere: # nano kamere_rtmp_applications.conf chunk_size 4000 ; aplikacija hls_1 (uživo; sinkronizacija 10 ms; exec_static ffmpeg - i rtsp: Kreirajmo hls datoteku za konfiguraciju rtmp poslužitelja s aplikacijama za naše kamere: # nano kamere_rtmp_applications.conf//admin:[e-mail zaštićen]

:554/live1.sdp -c kopija -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log;

hls uključen;

hls_staza /tmp/hls - 1/;

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, uživo - 16602660. ts #EXTINF:5.246, uživo - 17072820. ts #EXTINF :5.280, uživo - 17544960. ts #EXTINF:5.251, uživo - 18020160. ts #EXTINF:5.228, uživo - 18492750. ts #EXTINF:5.242, uživo - 18963270. ts

Rješavanje problema s otpadanjem kamera

Najbolje rješenje je promijeniti glitchy kameru. Ovo pomaže u 90% slučajeva. Ako nema načina i morate nekako krenuti dalje, onda će sljedeće rješenje pomoći.

Ovo rješenje se sastoji od dva komplementarna:

    Pokrenite zaseban nginx proces za svaku kameru i zajednički proces za vraćanje statičkih podataka. To jest, za dvije kamere napišite zasebne konfiguracije s rtmp poslužiteljima i jednu zajedničku s http. Tada pokvarena kamera neće utjecati na cjelokupni proces.

    Ako je stream s kamere prekinut kao rezultat njezinih problema (pregrijavanje, loše kućište, nedovoljno PoE napajanje itd.), tada će kamera otpasti, ffmpeg podređeni proces će odbiti pakete i nginx će prestati snimati dijelove video. A kada ffmpeg proces završi, nginx će izbrisati sve datoteke iz direktorija komada. Izračunavamo ovaj trenutak čišćenja mape pomoću crona i ponovno pokrećemo potreban nginx proces.

Za svaku kameru kreira se izvršna skripta u /etc/init.d/, kopija nginxa, pod nazivom camera_1 i 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

Uređivanje skripte za pokretanje nginxa.

nano/etc/init. d/nginx

Promijenite varijablu DAEMON_OPTS. Glavni nginx demon će dostaviti sve statičke podatke. Također će pokrenuti i zaustaviti demone odgovorne za kamere./ init . d / camera_1 stop fi if [ - f "/etc/init.d/camera_2" ];

zatim / etc / init. d/kamera_2 zaustavljanje fi

Dodajte funkciji do_reload:

# ponovno učitaj kamere if [ - f "/etc/init.d/camera_1" ];

zatim / etc / init. d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ];

zatim / etc / init. d/camera_2 reload fi

Uređujemo skriptu za pokretanje nginxa za kameru 1 camera_1 i za kameru 2 camera_2 slijedeći primjer.

# nano /etc/init.d/camera_1

Promijenite varijable DAEMON_OPTS i DESC

DESC = "kamera_1 za KAMERU-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf" Uredimo skriptu za pokretanje nginxa za kameru 2 camera_2 slijedeći primjer.

Oni označavaju, odvojene razmakom, traženu riječ DIR-PROCESS-NAME, direktorij i naziv procesa koji treba ponovno pokrenuti.

Ispitivanje:

# service nginx start # service camera_1 restart * Ponovno pokretanje camera_1 za CAMERA - 1 konfiguracija nginx # service camera_2 restart * Ponovno pokretanje camera_2 za CAMERA - 2 konfiguracija nginx

Skripta koja ponovno pokreće kamere. Prolazi kroz mape s komadima, tražeći one u kojima nema *.m3u8 datoteka. Ako nema datoteka u mapi, traži odgovarajući demon koristeći konfiguraciju glavnog demona, koristeći liniju DIR-PROCESS-NAME. Ponovno ga pokreće.

# 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 maska ​​= "*.m3u8" dir = "/tmp/ hls-*" funkcija find_process())( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) za hls_dir u $dir; do find_result = $(find $hls_dir -name $mask -type f) if [ -z $find_result ] ; zatim proces = $(find_process $hls_dir ) servis $proces ponovno pokreni fi gotovo spavanje 15s

Usporedba HLS-a s MPEG-DASH-om

MPEG-DASH je analog HLS-a koji je stvorio Google kao prijenos za MPEG-4. Ovaj prijevoz nije široko rasprostranjen i praktički nije podržan. Njegova ideologija je ista, razbiti stream na dijelove, samo ima više dijelova, posebno za video, odvojeno za audio. U nginx-rtmp-modulu ovaj format je konfiguriran slično HLS-u.

Pokušajte, kopirajte, usudite se!

Ako vam je članak bio koristan, kliknite na oglas. Hvala!

Pružanje usluga IPTV putem interneta i lokalnih računalnih mreža poprima sve raširenije oblike. Gotovo da više nema velikih pružatelja usluga u zemljama ZND-a koji ne emitiraju video putem multicast u svoje lokalne mreže, odnosno pružanja usluge IPTV. Ali pružanje TV usluga izvan vaše lokalne mreže povezano je s određenim troškovima hardvera i poteškoćama u osiguravanju potrebne kvalitete emitiranja.

HTTP prijenos uživo također poznat kao H.L.S., komunikacijski je protokol koji implementira Apple. Njegova je posebnost da je cjelokupni tok podijeljen na niz malih datoteka za preuzimanje, pri čemu svako preuzimanje učitava jedan mali fragment prijenosnog toka. Kada se stream reproducira, klijent može odabrati između nekoliko različitih alternativnih streamova koji sadrže isti materijal, snimljen na različitim brzinama prijenosa, što mu omogućuje prilagodbu dostupnoj brzini prijenosa. Na početku sesije strujanja učitava se poboljšani M3U (m3u8) popis za reprodukciju koji sadrži metapodatke za različite dostupne substreamove. Budući da zahtjevi koriste samo standardne HTTP operacije, HTTP Live Streaming može zaobići svaki vatrozid ili proxy koji dopušta standardni HTTP promet za razliku od UDP protokola kao što je RTP.

HLS se temelji na HTTP-u. HLS također definira standardni mehanizam šifriranja pomoću AES-a i način distribucije sigurnosnog ključa pomoću HTTPS ili HTTP kolačića, koji zajedno pružaju jednostavan sustav zaštite autorskih prava.

Kako djeluje HLS?

Sada saznajmo koje su prednosti i nedostaci ove tehnologije. Prednosti su nedvojbene i očite. To je, prije svega, prilagodljivost brzine prijenosa podataka svojstvima linije i prijamnog uređaja, a drugo, ugrađeni mehanizmi zaštite autorskih prava. Treće, nije potreban usmjerivač s ograničenjem širine multicast tok putem WI_FI-ja, što bi pomoglo u izbjegavanju apsorpcije cijele širine kanala multicast tokovima u slučaju IP televizijskog emitiranja korištenjem multicasta. Također nema potrebe za dodatnim uređajem s funkcijom UDP proxy za pretvorbu multicast streama u HTTP, što je često potrebno za mobilne uređaje, iako utječe na hardversko opterećenje usmjerivača ili drugog uređaja koji obavlja UDP proxy funkciju u lokalnoj mreži pretplatnika. HLS standard postao je prilično raširen i podržavaju ga gotovo svi moderni video playeri i IPTV set-top box uređaji.

IPTV set-top box

Značajan nedostatak je to što pretplatnici imaju multimedijske set-top box uređaje i smart-TV set-top box uređaje sa zastarjelim firmware-om ili zastarjelim dizajnom koji ne podržavaju HLS standarde ili ih ne podržavaju ispravno. Također, jedan od problema je nemogućnost pravilnog odabira kvalitete za stabilno emitiranje u uvjetima promjene karakteristika linije u vremenskim intervalima kraćim od trajanja traženog video fragmenta.

Za organiziranje online emitiranja u stvarnom vremenu, video na zahtjev (vod), kao i za snimanje video streamova, možete koristiti nginx zajedno s modulom nginx-rtmp-module.

Medijski poslužitelji

Danas postoji nekoliko popularnih medijskih poslužitelja, o kojima možete više pročitati na jednom od njih. Medijski poslužitelji su potrebni za kreiranje online emitiranja u stvarnom vremenu.

Postoje i plaćeni i besplatni medijski poslužitelji koji uključuju različite funkcije. Danas ćemo govoriti o jednom besplatnom i prilično dobrom rješenju.

Ngnix-rtmp

Osnovna funkcionalnost medijskog poslužitelja također se može implementirati pomoću besplatnog softvera - modula Ngnix-rtmp-module, koji trenutno podržava protokole za strujanje kao što su RTMP i HLS.

Dakle, koristeći Ngnix-rtmp (Ngnix web server + Ngnix-rtmp-module modul), možete organizirati RTMP i HLS emitiranje na korisničke uređaje. Zbirnu tablicu protokola i uređaja koji ih podržavaju možete pronaći u članku. Također, u jednom od svojih budućih članaka planiram napraviti usporednu tablicu funkcionalnosti modula Ngnix-rtmp-modula i ostalih medijskih poslužitelja.

Online prijenos putem HLS protokola

Danas ćemo pogledati kako koristiti Nginx-rtmp-modul za organiziranje jednostavnog emitiranja s prilagodljivom brzinom prijenosa pomoću HLS protokola. Prije svega, moramo preuzeti izvorne kodove Nginx web poslužitelja sa službene web stranice. Sve dolje navedene naredbe izvršene su u Linuxu.

  • wgethttp://nginx.org/download/nginx-1.4.1.tar.gz

Izdvojite datoteke iz arhive.

  • tar -zxvf nginx-1.4.1.tar.gz

Preuzmite zip arhivu s izvornim datotekama modula nginx-rtmp-module i izvucite datoteke iz arhive.

  • wget https://github.com/arut/nginx-rtmp-module/archive/master.zip

Sada moramo kompajlirati nginx s modulom nginx-rtmp-modul , da biste to učinili, kada konfigurirate nginx, trebate navesti opciju --dodaj-modul mjesto izvornih datoteka nginx-rtmp-modul , a morate navesti i dodatnu opciju s-http_ssl_modulom .

./configure --add-module=/home/nginx/nginx-rtmp-module-master --with-http_ssl_module

napraviti instalaciju

  • Ako je sve prošlo bez grešaka, možete započeti s postavljanjem poslužitelja. Prema zadanim postavkama, poslužitelj je instaliran u direktoriju/usr/local/nginx . Konfiguracijska datoteka poslužitelja nginx.conf nalazi se u direktoriju/usr/local/nginx/conf . Pogledajmo pobliže odjeljak rtmp:server konfiguracijske datoteke. Parametar slušanja specificira port na kojem će poslužitelj prihvatiti rtmp zahtjeve.
  • Zatim otvaramo odjeljak za postavljanje testlive aplikacije. Ovdje označavamo da imamo live stream - live on parametar, omogućujemo podršku za hls protokol za ovu aplikaciju - hls on parametar.
  • Pomoću parametra hls_staza postavljamo direktorij u kojem će se nalaziti chunkovi (dijelovi) toka. Kako bi se dijelovi (dijelovi) za svaki video stream nalazili u posebnom direktoriju, morate uključiti direktivu hls_ugniježđen .
  • Dalje, pomoću parametra dopustiti objavu dopuštamo vam objavljivanje streamova s ​​vašeg računala i pomoću parametra zabrani objaviti sve Svima ostalima zabranjujemo objavljivanje videa.
  • Sada pogledajmo odjeljakhttp:poslužitelj . U parametru slušati potrebno je naznačiti na kojem portu će poslužitelj primatihttp zahtjevi. Specificiramo port 8080. I iz primjera konfiguracijske datoteke premjestite odjeljakhttp:server:location/hls . Detaljnije informacije o svim direktivama konfiguracijske datoteke možete vidjeti na:https://github.com/arut/nginx-rtmp-module/wiki/Directives.
  • Vrijeme je za pokretanje poslužitelja. Da biste to učinili, morate otići u imenik /usr/local/nginx/bin i pokrenite naredbu ./nginx .

Sada pogledajmo jedan primjer. Poslužitelju šaljemo tri video streama:

  • test1 s brzinom prijenosa od 256 kbit/s,
  • test2 s brzinom prijenosa od 512 kbit/s,
  • test3 uz bitrate od 1024 kbps.

Cilj nam je da klijent koji koristi HLS protokol (uređaji: Mac, iPad, iPhone) ima mogućnost dinamičkog prebacivanja između streamova, ovisno o kvaliteti internetske veze. Da bismo to učinili trebamo u imeniku /usr/local/nginx/html stvoriti datoteku s ekstenzijom m3u8 , Na primjer popis za reprodukciju.m3u8 , sa sljedećim sadržajem:

#EXTM3U

#EXT-X-VERZIJA:3

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=256000,RESOLUTION=640×480

hls/test1/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=512000,RESOLUTION=640×480

hls/test2/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1024000,REZOLUCIJA=640×480

hls/test3/index.m3u8

Pogledajte prijenos

Da biste gledali video streamove, trebate ugraditi sljedeći kod na web-stranicu web-mjesta.

- IP adresa vašeg nginx poslužitelja.

[naziv popisa za reprodukciju]- naziv datoteke stvorene u prethodnom paragrafu (playlist.m3u8).

Ispod je primjer jednostavne konfiguracijske datoteke nginx.conf.

radnički_procesi 1;

poslužitelj (

slušaj 1935;

testiranje aplikacije uživo (

živjeti dalje;

hls uključen;

hls_staza /tmp/hls;

hls_ugniježđen na;

dopusti objavu 10.10.146.148;

zabraniti objavljivanje svih;

poslužitelj (

slušaj 8080;

server_name rtmp_test;

skup znakova utf-8;

mjesto/(

korijenski html;

indeks indeks.html indeks.htm;

lokacija /hls (

vrste (

aplikacija/vnd.apple.mpegurl m3u8;

alias /tmp/hls;

Zaključak

Ovaj članak je napisan i objavljen zajedno s mojim kolegom Evgenijem Petrovim. Koristimo ovaj modul (Ngnix-rtmp) u različitim projektima. Ako netko ima pitanja o Ngnix-rtmp, Wowza serveru, neka piše. Ako trebate nešto konfigurirati ili dobiti savjet o medijskim poslužiteljima i multimedijskim sustavima, također možete kontaktirati mene i naš tim putem.

Izrada tehnički savršenih aplikacija obično je iznimno težak i dugotrajan zadatak. Istodobno, korisne informacije često su razbacane po mnogim izvorima. To se između ostalog odnosi i na razvoj video aplikacija za iOS. Ovaj članak sadrži najvažnije i najkorisnije informacije koje vam omogućuju učinkovito korištenje punog raspona mogućnosti HTTP Streaminga uživo, kao i popis primarnih izvora. Ovi materijali bit će korisni svim čitateljima koji su zainteresirani za stvaranje visokokvalitetnih i korisniku pristupačnih video usluga.

Povećanje pogodnosti i interaktivnosti video usluga postiže se brzim pokretanjem i premotavanjem unatrag, kao i odsutnošću međuspremnika. Za postizanje najboljeg rezultata predlaže se sljedeći skup radnji.

  • Počnite s niskom kvalitetom videa. Za pokretanje videozapisa potreban je barem jedan dio. U skladu s tim, što je manja veličina jednog dijela, to će se video brže pokrenuti. Smanjenje brzine prijenosa u bitovima početnog toka i smanjenje trajanja dijela dovodi do bržeg pokretanja videozapisa. Preporučujemo trajanje odsječka od 4-8 sekundi i početnu brzinu prijenosa od 200-300 Kbps. Dakle, za početak reprodukcije videa korisnik će morati preuzeti najviše 300 KB.
  • Optimizacija popisa za reprodukciju. Popisi za reprodukciju mogu zauzeti značajan dio ukupnog toka podataka, posebno s malim veličinama dijelova i dugotrajnim sadržajem (nekoliko sati). U većini slučajeva, prilikom prijenosa popisa za reprodukciju na video player, preporučuje se njihovo arhiviranje.
  • Ključni okviri. Poželjno je imati barem jedan IDR okvir po segmentu, po mogućnosti na samom početku segmenta. Osim toga, pri prijenosu videa putem mobilnih mreža, preporučuje se stvaranje ključnih sličica barem jednom svake 3 sekunde.
  • TS režijski troškovi. HTTP LS koristi MPEG TS kao spremnik, stoga je vrlo važno minimizirati TS opterećenje (trebalo bi biti manje od 10% čak i uz nisku kvalitetu videa). U ovom slučaju vrijedi izmjeriti stvarne brzine prijenosa pomoću ispisa prometa i optimizirati korištene pakere (segmentatore).
  • Parametar ciljanog trajanja na popisu za reprodukciju. Ova postavka utječe na vrijeme pokretanja, ali Apple preporučuje da je postavite na 10 sekundi jer niže postavke povećavaju vjerojatnost međuspremnika, posebno na mobilnim mrežama s velikom latencijom. Također se ne preporučuje izrada segmenata duljih od 20 sekundi.
  • Dinamička brzina prijenosa. Prilagodljivi mehanizam strujanja ugrađen u iOS radi optimalno na točno određenim bitrate-ima u varijanti playliste (uzimajući u obzir promet same playliste). U ovom slučaju, za streamove s različitim brzinama prijenosa, trebate navesti vrijednost bližu maksimumu. U protivnom su moguće netočne odluke o promjeni trenutnog video streama. Susjedne bitrate trebale bi se razlikovati u brzini 1,5 - 2 puta.
  • Samo audio strujanje. HE-AAC audio kodek znatno je učinkovitiji i podržava ga većina uređaja. Preporuča se da se isporuka samo audio kanala implementira korištenjem MPEG Elementary Stream-a, a ne MPEG Transport Stream-a (značajno manji teret).

Dok razvijate svoj videoplayer, možete dobiti korisne informacije iz dnevnika HTTP Live Streaming (accessLog). Sadrži podatke o tome kako je došlo do automatskog prebacivanja, koje su brzine prijenosa korištene itd. Pojedinosti o informacijama dostupne u dnevniku. Na temelju tih podataka možete prikupiti video analitičke podatke o svojim korisnicima.

Dodatne preporuke
U slučaju online video emitiranja, buffering je također moguć zbog kašnjenja u CDN-u, kao i u slučajevima kada je vrijeme ažuriranja playliste prekratko i poslužitelj nema vremena za generiranje segmenata na vrijeme. Za optimizaciju mehanizma premotavanja unatrag, preporuča se koristiti necijele (stvarne) vrijednosti trajanja segmenta: inače se može nakupiti pogreška.

Ako je vaša aplikacija namijenjena za korištenje na različitim uređajima, možete odrediti različitu kvalitetu videa na popisu za različite razlučivosti zaslona. Na ovaj način možete ispisati različite videozapise na iPadu s Retina zaslonom i na relativno starom iPhoneu.

HTTP Live Streaming protokol također pruža mehanizme za osiguranje tolerancije na pogreške (određivanje rezervnih video izvora). Ova značajka može biti korisna za poboljšanje pouzdanosti vaših usluga.

Izvori znanja
Kratak popis materijala o korištenju HTTP Live Streaminga u video aplikacijama:
Skica HTTP Streaminga uživo
Često postavljana pitanja o HTTP prijenosu uživo
Najbolji primjeri iz prakse za HLS

Na kraju, vrijedno je napomenuti da su besplatne tehničke video sesije s WWDC 2012 dostupne registriranim Mac/iOS/Safari programerima, koje također sadrže puno korisnih informacija, posebno o radu s videom i korištenju HTTP Live Streaminga.



POVEZANI ČLANCI