streaming hls. Kada koristiti HLS protokol

Pružanje usluga IP TV putem interneta i lokalnih računarskih mreža postaje sve rašireniji oblici. Na teritoriji zemalja ZND gotovo da nema velikih provajdera koji ne emituju video preko multicast njihovim lokalnim mrežama, odnosno onima koji pružaju uslugu IPTV. Ali pružanje TV usluga izvan lokalne mreže povezano je sa nekim hardverskim troškovima i složenošću obezbjeđivanja potrebnog kvaliteta emitovanja.

HTTP Live Streaming također poznat kao HLS, je komunikacijski protokol koji implementira Apple. Njegova posebnost je da je cjelokupni stream podijeljen u niz malih datoteka za preuzimanje, pri čemu svako preuzimanje preuzima jedan mali fragment transportnog toka. Kada se stream reproducira, klijent može birati između nekoliko različitih alternativnih tokova koji sadrže isti materijal, snimljen različitim brzinama prijenosa, što mu omogućava da se prilagodi dostupnoj brzini prijenosa. Na početku sesije striminga učitava se proširena M3U (m3u8) lista za reprodukciju koja sadrži metapodatke za različite dostupne podtokove. Budući da zahtjevi koriste samo standardne HTTP operacije, HTTP Live Streaming može zaobići bilo koji firewall ili proxy server koji dozvoljava standardni HTTP promet, za razliku od UDP protokola kao što je RTP.

HLS je baziran 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 sistem zaštite autorskih prava.

HLS princip rada

Sada ćemo saznati koje su prednosti i mane ove tehnologije. Prednosti su neosporne i očigledne. To je, prije svega, prilagodljivost brzine prijenosa podataka svojstvima linije i prijemnog uređaja, a drugo, ugrađeni mehanizmi zaštite autorskih prava. Treće, nije potreban ruter ograničen na širinu multicast stream preko WI_FI, što bi pomoglo da se izbjegne apsorpcija cijele širine kanala multicast streamovima, u slučaju emitiranja IP televizije korištenjem multicast. Također nije potreban dodatni uređaj sa funkcijom UDP proxy da konvertujete multicast stream u HTTP, što je često potrebno za mobilne uređaje, iako utiče na opterećenje hardvera na ruteru ili drugom uređaju koji obavlja UDP proxy funkciju u lokalnoj mreži pretplatnika. HLS standard je postao prilično uobičajen i podržavaju ga gotovo svi moderni video plejeri i set-top boxovi za IPTV.

IPTV set-top box

Značajan nedostatak je što pretplatnici imaju multimedijalne set-top boxove i smart-tv set-top boxove sa zastarjelim firmverom ili zastarjelim dizajnom koji ne podržavaju HLS standarde ili ih ne podržavaju ispravno. Takođe, jedan od problema je i nemogućnost odabira pravog kvaliteta za stabilno emitovanje u uslovima promene karakteristika linije u vremenskim intervalima kraćim od trajanja traženog video fragmenta.

Obrađujući, pohranjujući i prebacujući video zapise za svoj online projekat, umjesto da koristi web stranice kao što je YouTube, on neizbježno dolazi do pitanja koji protokol za prijenos koristiti za striming video zapisa na uređaje korisnika. Izbor je mali, jer Postoji niz industrijskih standarda koji podržavaju određene uređaje. Osim toga, izbor protokola u velikoj mjeri ovisi o "klasi" videa - prijenos uživo ili video na zahtjev. Izbor medijskog servera, koji će biti motor vaše medijske mašine, zavisi i od izbora protokola: hoćete li instalirati nekoliko heterogenih servera ili izgraditi mrežu isporuke na osnovu jednog rešenja? Stoga morate sve odvagnuti i donijeti odluku na osnovu kriterija vašeg poslovanja.

Generalno, dobija se jednačina sa mnogo nepoznanica. Ovdje je važna dinamika procesa – kuda ide industrija općenito? Šta ako uložim u podršku tehnologije, a ona će umrijeti za godinu dana, jer se to već dogodilo. Ili ću se kladiti na modernu tehnologiju, ali je niko ne podržava?

Odlučili smo da procijenimo kako se udio različitih protokola mijenjao tokom vremena – da sagledamo cijeli proces u dinamici. Podaci su preuzeti iz prošle godine.

Početni podaci

Za početak, ko smo mi da sudimo o tržišnim udjelima? Mi smo programeri web servisa za izvještavanje za medijske servere. Već četvrtu godinu radimo na tržištu i dolaze nam kompanije sa različitim infrastrukturama, različitim brojem servera i različitim potrebama. Ispostavilo se da je dobar prikaz stanja u industriji.

Napravili smo mali izvještaj u kojem možete odabrati raspon datuma i dobiti podatke sa grafikonom o broju pregleda videa kroz različite protokole.

Izvještaj daje podatke o serverima:

• Wowza Streaming Engine u svim verzijama od 2.2 do najnovije 4.x; najviše - 3.x.
• Nimble Streamer koji radi sa HLS, Smooth, HDS i progresivnim preuzimanjem je naš razvoj.
• Windows Media Services - ima ih bukvalno nekoliko desetina, ali postoje i moramo ih uzeti u obzir

Izveštaj se takođe periodično ažurira na našem blogu, dostupan je pod odgovarajućom oznakom.

Idi

Izvještaj za jun/jul 2014. izgleda otprilike ovako. Od 1,4 milijarde pregleda više od polovine su HLS. Na drugom mjestu je RTMP sa četvrtinom pregleda. RTSP je otprilike šestina. Ostalo je u području statističke greške.

Šta se dogodilo prije godinu dana za isti period? Situacija je gotovo zrcalna slika. RTMP - skoro dvije trećine, RTSP i HLS dijele drugo i treće mjesto. Istina, baza za mjerenja je bila skoro 3 puta manja - "samo" 500 miliona pregleda. Naravno, bilo je i manje servera u našem servisu.

Idemo između ove dvije tačke.

Dakle, jun - avgust 2014, 3 mjeseca ljeta. 800 miliona pregleda, ali dionice su iste, avgust nije donio promjene.

Septembar - Novembar 2013. Počela je nova sezona, HLS je počeo da jede udeo RTMP-a. Ukupno 1,1 milijardu pregleda, RTMP ima oko polovinu ukupnog, HLS ima četvrtinu.

Decembar 2013 - februar 2014. 1,4 milijarde pregleda, od čega HLS čini više od 40%. RTMP i RTMP su izjednačeni na drugom i trećem mjestu sa četvrtinom udjela. Olimpijske igre u Sočiju dale su porast broja pregleda i istovremeno naterale provajdere da pamte sve korisnike sa svim njihovim egzotičnim ili starim uređajima koji razumeju samo RTSP - otuda i skok u ovom protokolu.

Kao što je praksa pokazala, najbolji transport za video u odnosu na RTMP je HLS. Razlozi za to:

Vrlo jednostavno proxying, sa keširanjem preko nginxa. Prije svega, zato što kamera, kao uređaj, po pravilu ne može opsluživati ​​više od 10 priključaka istovremeno. U tom smislu, zagarantovano proxying RTMP streamova moguće je samo putem plaćenih rješenja i zahtijeva mnogo energije. Nije potreban poseban serverski softver.

Pojednostavljenje cjelokupne serverske infrastrukture. Na osnovu ideje, video se daje u komadima, preko porta 80 preko http. Sam Nginx može biti odgovoran za vraćanje statike. Vraćanje statike (video komada od 50 kB) je vrlo lak zadatak za nginx.

Pošto je broj komada konstantan, stari se uklanjaju, dodaju novi, tvrdi disk se nikada neće preliti.

Prevalencija je veća nego kod RTMP-a. HLS sa H.264 video kodiranjem je podržan od strane iOS-a i radi besprijekorno. Od 1. jula 2014. striming video veze sa HLS transportom su 55%, RTMP - 26%, RTSP - 15% i MPEG-DASH manje od 1%.

Podrška za većinu mobilnih uređaja, desktopa, tableta direktno iz pretraživača.

U principu, mnogo lakše nego emitovanje u RTSP-u. Budući da ne postoje procedure kao što su push (objavljivanje streama) ili pull (dobivanje 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 zvanično ne podržavaju H.264 kodek i transport, ali na Androidu, umjesto pretraživača, možete koristiti aplikaciju treće strane za gledanje - na primjer, MX Player

Sve zavisi od kamere. Ako kamera greši, na primjer Dlink DCS-3010, onda će cijeli sistem raditi jako loše (ffmpeg stalno pada). Na primjer, kamere AXIS M1011-W, HIKVISION DS-2CD2412F-IW dobro rade u takvom paketu (do mjesec dana bez ikakvih pritužbi (samo nisam duže testirao)). Provođenje kablova je takođe važno. U tom smislu ćemo razmotriti idealnu opciju.

Šta je HLS transport

Video stream kodiran u h.264 (Usput: osnovnu liniju profila razumiju Android uređaji), podijeljen je na dijelove sa *.ts ekstenzijom, na primjer, svaki po 5 sekundi, kreira se lista za reprodukciju u live.m3u8, sa sekvencijalni opis ovih komada. Dužina playliste je unaprijed određena, na primjer, 10 komada. Kada se pojavi 11. dio videozapisa, 1. dio videozapisa se briše, plejlista se ponovo kreira. Više detalja možete pronaći na web stranici programera.

Da bi sistem funkcionisao, sliku sa kamera ćemo postaviti onako kako želimo da je vidimo na sajtu, format slike i kvalitet slike. Nećemo prekodirati na serveru. Kamera je dizajnirana da pruži sliku koja vam je potrebna. Kamere obično imaju nekoliko profila. Možete konfigurisati jedan profil za H.264, za HLS, a drugi sa MPEG4 za MPEG-DASH. Također možete podesiti različite kvalitete za širok i uski internet kanal. Mislite sami - odlučite sami.

Bitan! Kamera bi trebala imati izlaznu sliku koju nije potrebno ponovno kodirati.

Strukturni dijagram za velika opterećenja

Kamera(rtsp) ----->

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

-----> jedna veza sa srednjim nginx proxyjem sa velikom keš memorijom =====>

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

Naš server se povezuje sa ffmpeg na kameru i registruje se sa nginx hls aplikacijom. nginx kreira komade i playlistu u određenom direktoriju. Zatim šalje ove dijelove na proxy server. Klijenti se povezuju na proxy server koristeći JWPlayer.

Postavljanje nginx aplikacije

Napravimo nginx sa nginx-rtmp-module. Ovaj postupak je detaljno opisan u članku.

Recimo da imamo nekoliko kamera, podijelit ćemo ih po serijskom broju. Opisaću nginx konfiguraciju za 2 kamere. Statične slike keširamo 5 minuta u lokalnom kešu, ako se slika ne učita unutar 5 sekundi, dajemo statički početni ekran.

# nano /etc/nginx/nginx.conf

Uredite nginx konfiguraciju

korisnik www-podaci; worker_processes auto ; pid/run/nginx. pid ; error_log / var / log / nginx / nginx_error . log debug ; env PATH ; događaji ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error. log ; uključuju mime . tipove ; default_type application / oktet - stream ; sendfile uključen ; keepalive_timeout 65 proxy_cache_path / var / www / cache / lokalni nivoi = 1 : 2 keys_zone = nginx_local_cache : 1 m neaktivan = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; stat; # listen 8 location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # možete premjestiti stat . xsl na drugu lokaciju root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 / 5050 5 50 x .html ;location = / 50 x .html ( root html ; ) uključuje cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( slušanje 1935 ; ping 30 s ; notify_method get ; uključiti cameras_rtmp_applications . conf ; ) )

Kreirajte putanju predmemorije # mkdir /var/www/cache/local Popravite dozvole 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 cameras_http_locations.conf

vrste ( aplikacija / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # daj sliku sa kamere 1 - /1/img/ # su različiti za sve kamere, jer IP adrese kamere su različite "http://192.168.0.2/GetImage.cgi?CH=1"# daj sliku sa kamere 2 - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; ističe 1 m ; # keširanje za 1 minutu add_header Cache - Kontrola javnog ; # za keširanje na proxy_ignore_headers Cache - Kontrola zaglavlja kamere iz proxyja ; # za uklanjanje proxy zaglavlja iz proxy zaglavlja ; "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Autorizacija "Osnovna" ; error_page 502 504 404 @ fallback_img ; ) # dajte playlistu - /1/hls/live.m3u8 ili /3/hls/live.m3u8 # plejlista se kešira 10 sekundi na proxy serveru lokacija ~* / hls / . * \ . m3u8 $ ( prepiši "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 prekid ; # zahtjev za ponovno pisanje / 1 / hls / to / 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 # keširanje na lokalnoj mašini nije potrebno # komad se kešira 3 minuta na proxy serveru lokacija ~* / hls / . * \ . ts $ ( prepisati "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; ističe 3 m ; add_header Cache - Kontrola javnog ; ) # imenovana lokacija ako nema slike lokacija @ fallback_img ( prepiši (. + ) / rezervni . jpg prekid ; root / etc / nginx / ; )

Kreirajmo hls konfiguracijsku datoteku za rtmp server sa aplikacijama za naše kamere:

# nano cameras_rtmp_applications.conf

chunk_size 4000 ; aplikacija hls_1 (uživo; sinhronizacija 10 ms; exec_static ffmpeg - i rtsp: //admin: [email protected]:554/live1.sdp -c kopija -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls on ; hls_path / tmp / hls - 1 / ; # staza za skladištenje komada na serveru hls_fragment_naming timestamp ; # koristite vremensku oznaku za imenovanje dijelova ) aplikacija hls_2 (živo na ; sinhronizacija 10 ms ; exec_static ffmpeg - i rtsp : //admin: [email protected]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls on ; hls_path / tmp / hls - 2 / ; hls_fragment_naming timestamp ; )

Sadržaj direktorija /tmp/hls-1/

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767360. ts live - 13767360. - 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 - 12820160. ts live - 12820160. ts live - 12820160.

Primjer live.m3u8 datoteke

#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. :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

Rješavanje problema sa kamerama koje padaju

Najispravnija odluka je da promijenite buggy kameru. Pomaže u 90% vremena. Ako nema načina i morate nekako živjeti, onda će vam pomoći sljedeće rješenje.

Ovo rješenje se sastoji od dva komplementarna:

Pokrenite poseban nginx proces za svaku kameru i zajednički proces za vraćanje statike. Odnosno, za dvije kamere napišite odvojene konfiguracije sa rtmp serverima i jednu zajedničku sa http. Tada kamera s greškom neće utjecati na cjelokupni proces.

Ako je tok iz kamere poremećen kao rezultat greške (pregrijavanje, loše ožičenje, nedovoljno napajanje preko PoE, itd.), tada će kamera pasti, ffmpeg dječji proces će odbiti pakete i nginx će prestati pisati video dijelove . A kada se ffmpeg proces završi, nginx će ukloniti sve datoteke iz direktorija chunks. Izračunavamo ovaj trenutak čišćenja foldera cron-om i ponovo 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 nginx skripte za pokretanje.

nano /etc/init. d/nginx

Promijenite varijablu DAEMON_OPTS. Glavni nginx demon će služiti svu statiku. Također će pokrenuti i zaustaviti demone odgovorne za kamere. / init . d /camera_1 stop fi ako [ - f "/etc/init.d/camera_2" ]; zatim /etc/init. d/camera_2 stop fi

Dodajte funkciji do_reload:

# ponovo učitaj kamere ako [ - f "/etc/init.d/camera_1" ]; zatim /etc/init. d / camera_1 ponovo učitaj fi ako [ - f "/etc/init.d/camera_2" ]; zatim /etc/init. d/camera_2 ponovo učitaj fi

Uređujemo nginx skriptu za pokretanje za kameru 1 camera_1 i za kameru 2 camera_2 prema primjeru.

# nano /etc/init.d/camera_1

Promjena varijabli DAEMON_OPTS i DESC

DESC = "camera_1 za CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Uređujemo nginx skriptu za pokretanje za kameru 2 camera_2 prema primjeru.

U /etc/nginx/nginx_0.conf sa http lokacijama pišem magične linije:

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

Oni označavaju riječ za pretragu DIR-PROCESS-NAME, odvojenu razmakom, direktorij i naziv procesa koji treba ponovo pokrenuti.

pregled:

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

Skripta koja ponovo učitava kamere. Prolazi kroz foldere u komadima, tražeći gdje nema *.m3u8 datoteka. Ako nema datoteka u folderu, on traži odgovarajućeg demona prema konfiguraciji glavnog demona, po redu DIR-PROCESS-NAME . Ponovno učitava.

# nano /script/cameras_reloader.sh

Poređenje HLS-a sa MPEG-DASH-om

MPEG-DASH je analog HLS-a koji je kreirao Google kao transport za MPEG-4. Ovaj transport nije široko rasprostranjen i praktički nije podržan. Njegova ideologija je ista, razbijte tok na komade, samo više komada, odvojeni komadi za video, odvojeni komadi za audio. U nginx-rtmp-module, ovaj format je konfigurisan slično HLS-u.

Probajte, kopirajte, krenite!

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

Flussonic Media Server podržava video distribuciju preko HLS protokola.

Mnoge dostupne funkcije su nestandardne za HLS, ali ih podržavamo radi vaše udobnosti.

Podržani kodeci: H264, H265, MPEG2 video, AAC, MP3, MPEG2 audio, AC-3.

Flussonic Media Server vam omogućava da primate TV uživo, video na zahtjev, video iz arhive (catchup i timeshift) putem HLS-a.

Jednostavna HLS reprodukcija

Ako imate jednostavan prijenos uživo ili fajl (jedan video, jedan zvuk), onda je URL za reprodukciju preko HLS-a vrlo jednostavan:

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

gdje je flussonic-ip primjer adrese + porta vašeg Flussonic Media Servera.

Flussonic Media Server takođe prihvata playlist.m3u8 na kraju URL-a radi kompatibilnosti sa drugim serverima.

Kada počnete raditi s višejezičnim ili višebitnim sadržajem, stvari postaju složenije.

Višejezični HLS

Ako želite reproducirati svoj višejezični prijenos na iPhoneu, trebate koristiti isti http://192.168.2.3:8080/STREAMNAME/index.m3u8

Ali ako želite da gledate višejezični stream koristeći VLC ili set-top box, morate uključiti video.m3u8.

URL za plejer: http://flussonic-ip/STREAMNAME/video.m3u8

To je zbog činjenice da se, prema zahtjevima Apple HLS-a, za svaki pojedinačni jezik mora navesti posebna lista za reprodukciju s opcijom samo audio. MPEG-TS ima drugačiji mehanizam: svi audio zapisi se postavljaju pored videa, a plejer sam bira šta će se reprodukovati. Da bi se video mogao gledati na iPhoneu, mora biti u skladu s Appleovim smjernicama. Ali VLC i set-top box uređaji, kršeći HLS standard, očekuju da se stara verzija MPEG-TS-a pretvori u HLS. Stoga morate uključiti video.m3u8 .

Dodavanje "Samo zvuk" za Apple

Apple zahtijeva da svi vaši streamovi imaju opciju bez videa, samo zvuka.

Vjeruju da ako korisnik gleda video preko 3G i, kada se nađe u zoni neizvjesnog prijema, imat će samo bolji zvuk od baferovanja.

Ovu opciju možete omogućiti u Flussonic Media Server:

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

Imajte na umu da ovo može učiniti vašu index.m3u8 adresu nemogućom za reprodukciju u VLC-u ili set-top box-u. U tom slučaju koristite video.m3u8.

Odvojene brzine prijenosa za set-top boxove

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

Ova lista za reprodukciju nije multi-bitrate, ona sadrži URL do segmenata u kojima je prvi video zapis i sve dostupne audio zapise.

Ako želite isporučiti višejezične, multibitrate streamove na set-top box uređaje koji ne razumiju Appleov višejezični standard, koristite video.m3u8:

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

Ovo je plejlista sa više bitrate-a koja vraća listu plejlista različitih kvaliteta: video1.m3u8, video2.m3u8, itd.

DVR dohvatna reprodukcija

Kada je vaš stream već snimljen na serveru od strane našeg DVR-a, možete reproducirati video putem HLS-a koristeći vrijeme početka i završetka prijenosa (na primjer, iz EPG-a).

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

Ova plejlista će biti tzv. varijanta ako će u streamu biti više od jednog audio zapisa ili više od jednog bitrate-a. Navodit će segmente počevši od UTC 1362504585 (2013. 5. mart 17:29:45 GMT) i sat unaprijed.

Mono URL će dati listu segmenata koji sadrže sve staze u mpeg-ts:

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

Konkretnija videoN lista za reprodukciju će dati listu segmenata sa N video zapisa i svih audio zapisa:

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

i varijantu video plejliste sa listom videoN plejlista:

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

Rewind playlist

Postoji posebna lista za reprodukciju "rewind-N.m3u8" sa velikim "kliznim" prozorom koji vam omogućava da premotavate i pauzirate HLS streamove na duge sate.

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

7200 - Dužina HLS liste za reprodukciju u sekundama. To znači da vaši korisnici mogu pauzirati prijenos na 2 sata ili premotati na početak nogometne utakmice bez pristupa posebnim arhivskim linkovima.