Streaming hls. Când să utilizați protocolul HLS

Asigurarea de servicii IPTV prin Internet și rețelele locale de calculatoare capătă forme din ce în ce mai răspândite. Aproape că nu există furnizori mari în țările CSI care să nu transmită video prin intermediul multicastîn rețelele lor locale, adică furnizarea serviciului IPTV. Dar furnizarea de servicii TV în afara rețelei dvs. locale este asociată cu unele costuri hardware și cu dificultatea de a asigura calitatea de transmisie necesară.

Streaming live HTTP de asemenea cunoscut ca si H.L.S., este un protocol de comunicare implementat de Apple. Particularitatea sa este că fluxul general este împărțit într-o secvență de fișiere de descărcare mici, fiecare descărcare descarcă un mic fragment din fluxul de transport. Când este redat un flux, clientul poate selecta dintre mai multe fluxuri alternative diferite care conțin același material, înregistrate la rate de biți diferite, permițându-i să se adapteze la rata de biți disponibilă. La începutul unei sesiuni de streaming, este încărcată o listă de redare M3U (m3u8) îmbunătățită care conține metadate pentru diferitele substreamuri disponibile. Deoarece cererile folosesc numai operațiuni HTTP standard, HTTP Live Streaming poate ocoli orice firewall sau proxy care permite trafic HTTP standard, spre deosebire de protocoalele UDP, cum ar fi RTP.

HLS se bazează pe HTTP. HLS definește, de asemenea, un mecanism de criptare standard folosind AES și o metodă de distribuire a cheilor de securitate folosind cookie-uri HTTPS sau HTTP, care împreună oferă un sistem simplu de protecție a drepturilor de autor.

Cum funcționează HLS?

Acum să aflăm care sunt avantajele și dezavantajele acestei tehnologii. Avantajele sunt neîndoielnice și evidente. Aceasta este, în primul rând, adaptabilitatea vitezei de transmisie a datelor la proprietățile liniei și ale dispozitivului de recepție și, în al doilea rând, mecanismele de protecție a drepturilor de autor încorporate. În al treilea rând, nu este necesar niciun router cu limitare de lățime flux multicast prin WI_FI, ceea ce ar ajuta la evitarea absorbției întregii lățimi a canalului de către fluxurile multicast în cazul difuzării de televiziune IP folosind multicast. De asemenea, nu este necesar niciun dispozitiv suplimentar cu funcție Proxy UDP pentru a converti un flux multicast în HTTP, care este adesea necesar pentru dispozitivele mobile, deși afectează sarcina hardware de pe router sau alt dispozitiv care îndeplinește funcția proxy UDP în rețeaua locală a abonatului. Standardul HLS a devenit destul de răspândit și este susținut de aproape toate playerele video moderne și set-top box-urile IPTV.

Set-top box IPTV

Un dezavantaj semnificativ este că abonații au set-top box-uri multimedia și set-top box-uri smart-TV cu firmware învechit sau design învechit care nu acceptă standardele HLS sau nu le acceptă corect. De asemenea, una dintre probleme este incapacitatea de a selecta corect calitatea pentru o difuzare stabilă în condiții de schimbare a caracteristicilor liniei în intervale de timp mai scurte decât durata fragmentului video solicitat.

Procesarea, stocarea și transmiterea video pentru proiectul său online, mai degrabă decât utilizarea site-urilor precum YouTube, vine inevitabil la întrebarea ce protocol de transmisie să folosească pentru a difuza video pe dispozitivele utilizatorilor. Alegerea este mică, pentru că... Există o serie de standarde industriale care acceptă anumite dispozitive. În plus, alegerea protocolului depinde în mare măsură de „clasa” video - transmisie în direct sau video la cerere. Alegerea serverului media care va fi motorul mașinii dvs. media depinde și de alegerea protocolului: veți instala mai multe servere eterogene sau veți construi o rețea de livrare pe o singură soluție? Prin urmare, trebuie să cântăriți totul și să luați o decizie pe baza criteriilor afacerii dvs.

În general, obținem o ecuație cu multe necunoscute. Dinamica procesului este importantă aici - unde se îndreaptă oricum industria? Ce se întâmplă dacă investesc în sprijinirea tehnologiei, dar epuizează într-un an, pentru că acest lucru s-a întâmplat deja. Sau voi paria pe o tehnologie la modă, dar nimeni nu o susține?

Am decis să evaluăm modul în care s-a schimbat ponderea diferitelor protocoale de-a lungul timpului - să ne uităm la dinamica întregului proces. Datele au fost luate pentru ultimul an.

Datele inițiale

Pentru început, cine suntem noi pentru a judeca cotele de piață? Suntem dezvoltatori ai unui serviciu de raportare web pentru servere media. Lucrăm pe piață de patru ani și companiile vin la noi cu infrastructuri diferite, număr diferit de servere și nevoi diferite. Se dovedește a fi un bun instantaneu al stării industriei.

Am realizat un mic raport în care puteți selecta un interval de date și puteți primi date cu un grafic despre numărul de vizionări ale videoclipurilor prin diferite protocoale.

Raportul oferă date pe servere:

• Wowza Streaming Engine în toate versiunile, de la 2.2 la cel mai recent 4.x; majoritatea sunt 3.x.
• Nimble Streamer, care lucrează cu HLS, Smooth, HDS și descărcare progresivă, este dezvoltarea noastră.
• Servicii Windows Media - există literalmente câteva zeci de ele, dar există și trebuie să le luăm în considerare

Raportul este, de asemenea, actualizat periodic pe blogul nostru, este disponibil sub eticheta corespunzătoare.

Merge

Raportul pentru iunie/iulie 2014 arată cam așa. Din 1,4 miliarde de vizualizări mai mult de jumătate sunt HLS. Pe locul doi se află RTMP cu un sfert de vizualizări. RTSP este aproximativ al șaselea. Restul sunt în zona erorii statistice.

Ce s-a întâmplat acum un an în aceeași perioadă? Situația este aproape o imagine în oglindă. RTMP - aproape două treimi, RTSP și HLS împart locurile doi și trei. Adevărat, baza de măsurare a fost de aproape 3 ori mai mică - „doar” 500 de milioane de vizualizări. De asemenea, erau mai puține servere în serviciul nostru, desigur.

Să mergem între aceste două puncte.

Deci, iunie - august 2014, 3 luni de vară. 800 de milioane de vizualizări, dar acțiunile sunt aceleași, august nu a adus nicio modificare.

Septembrie - noiembrie 2013. Un nou sezon a început, HLS a început să mănânce cota RTMP. Total 1,1 miliarde de vizualizări, RTMP are aproximativ jumătate din total, HLS are un sfert.

decembrie 2013 - februarie 2014. 1,4 miliarde de vizualizări, din care HLS reprezintă deja mai mult de 40%. RTMP și RTMP împart locul doi și al treilea cu un sfert de cotă. Jocurile Olimpice de la Soci au dat o creștere a numărului de vizualizări și, în același timp, au forțat furnizorii să-și amintească pe toți clienții cu toate dispozitivele lor exotice sau vechi care înțeleg doar RTSP - de aici și saltul în acest protocol.

După cum a arătat practica, cel mai bun transport pentru video în comparație cu RTMP este HLS. Motive pentru aceasta:

Proxy foarte simplu, cu stocare în cache prin nginx. În primul rând, deoarece camera, ca dispozitiv, nu poate gestiona, de regulă, mai mult de 10 conexiuni simultan. În acest sens, proxy-ul garantat al fluxurilor RTMP este posibilă doar prin soluții plătite și necesită capacități mari. Nu este necesar un software de server special.

Simplificarea întregii infrastructuri de server. În virtutea ideii, videoclipul este trimis pe bucăți, prin portul 80 prin http. Nginx însuși poate fi responsabil pentru furnizarea de date statice. Returnarea fișierelor statice (bucăți video de 50 kB fiecare) este o sarcină foarte ușoară pentru nginx.

Deoarece numărul de bucăți este constant, cele vechi sunt eliminate, sunt adăugate altele noi, hard disk-ul nu se va umple niciodată.

Prevalența este mai mare decât cea a RTMP. HLS cu codificare video H.264 este acceptat de iOS și funcționează fără pași suplimentari. Conform datelor de la 1 iulie 2014 de la hub, conexiunile video de streaming cu transport HLS - 55%, RTMP - 26%, RTSP - 15% și MPEG-DASH mai puțin de 1%.

Suport pentru majoritatea dispozitivelor mobile, desktop-urilor și tabletelor direct din browser.

În principiu, mult mai simplu decât difuzarea prin RTSP. Deoarece nu există proceduri precum push (publicarea unui flux) sau pull (primirea unui flux).

Format mult mai prietenos cu http.

Dezavantajele sunt următoarele:

Cu toate acestea, nu toate dispozitivele acceptă acest format. Versiunile Android mai mici de 4.2 nu acceptă oficial codecul și transportul H.264, dar pe Android, în loc de browser, puteți folosi o aplicație terță parte pentru vizualizare - de exemplu MX Player

Totul depinde de cameră. Dacă camera are probleme, de exemplu Dlink DCS-3010, atunci întregul sistem va funcționa foarte prost (ffmpeg cade constant). De exemplu, camerele AXIS M1011-W, HIKVISION DS-2CD2412F-IW funcționează bine în această combinație (până la o lună fără reclamații (doar că nu l-am testat mai mult timp)). De asemenea, rutarea cablurilor este de mare importanță. În acest sens, vom lua în considerare varianta ideală.

Ce este transportul HLS

Fluxul video în codificare h.264 (Apropo: linia de bază a profilului este înțeleasă de dispozitivele Android), este împărțit în bucăți cu extensia *.ts, de exemplu, câte 5 secunde fiecare, este creată o listă de redare în live.m3u8, cu o descriere secvențială a acestor piese. Lungimea listei de redare este predeterminată, de exemplu 10 bucăți. Când apare a 11-a bucată de videoclip, 1 bucată de videoclip este ștearsă, lista de redare este recreată. Mai multe detalii pot fi găsite pe site-ul dezvoltatorului.

Pentru ca sistemul să funcționeze, vom configura imaginea de la camere așa cum dorim să o vedem pe site, formatul imaginii și calitatea imaginii. Nu vom recoda pe server. Acesta este motivul pentru care camera a fost inventată pentru a produce imaginea de care este nevoie. Camerele foto au de obicei mai multe profiluri. Puteți configura un profil pentru H.264, pentru HLS și al doilea cu MPEG4 pentru MPEG-DASH. De asemenea, puteți configura diferite calități pentru un canal de internet larg și îngust. Gândește-te singur - decide-te singur.

Important! Camera ar trebui să scoată o imagine care nu trebuie să fie re-codificată.

Schema bloc pentru sarcină mare

Camera (rtsp) ----->

-----> o conexiune FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> o conexiune la un proxy intermediar nginx cu un cache mare =====>

=====> mulți clienți JWPlayer(hls).

Serverul nostru se conectează folosind ffmpeg la cameră și se înregistrează cu aplicația nginx hls. nginx creează piese și liste de redare într-un anumit director. Apoi trimite aceste piese către serverul proxy. Clienții se conectează la proxy folosind JWPlayer.

Configurarea aplicației nginx

Să construim nginx cu nginx-rtmp-module. Această procedură este descrisă în detaliu în articol.

Să presupunem că avem mai multe camere, împărțiți-le la numărul de serie. Voi descrie configurația nginx pentru 2 camere. Memorăm în cache imaginile statice timp de 5 minute în cache-ul local dacă imaginea nu se încarcă în 5 secunde, trimitem un screensaver static.

# nano /etc/nginx/nginx.conf

Să edităm configurația nginx

utilizator www - date ; worker_proceses auto ; pid/run/nginx. pid; error_log /var/log/nginx/nginx_error. depanare jurnal; env PATH ; evenimente ( # 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 activat ; keepalive_timeout 65 ; proxy_cache_path / var / www / cache / local levels = 1 : 2 keys_zone = nginx_local_cache : 1 m inactiv = 30 m max_size = 512 M proxy_temp_path / var / www / cache / local / tmp ( ascultare 80 ; # rtmp locație ; stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) locație / stat xsl ( # puteți muta stat . xsl într-o altă locație rădăcină / etc / nginx ; ) locație / ( rtmp_control all ; ) error_page 500 502 503 504 html ; locație = / 50 x html ( root html ; ) include cameras_http_locations ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( listen 1935 ; ping 30 s ; notify_method ); include cameras_rtmp_applications . conf ; ) )

Să creăm o cale pentru cache # mkdir /var/www/cache/local Să corectăm drepturile pentru cache:

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

Să creăm locații http pentru camere:

# nano camere_http_locations.conf

tipuri ( aplicație / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # trimite imaginea de la camera 1 - /1/img/ # sunt diferite pentru toate camerele, deoarece Adresele IP ale camerelor sunt diferite „http://192.168.0.2/GetImage.cgi?CH=1”# trimite imaginea de la camera 2 - /2/img/ locație / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; expiră 1 m ; # cache pentru 1 minut add_header Cache - Control public ; # pentru stocarea în cache pe proxy proxy_ignore_headers Cache - Control ; # pentru a elimina anteturile din camera proxy_pass „http://192.168.0.3/GetImage.cgi?CH=1”; proxy_set_header Autorizare „De bază” ; error_page 502 504 404 @ fallback_img ; ) # dați lista de redare - /1/hls/live.m3u8 sau /3/hls/live.m3u8 # playlist este memorat în cache timp de 10 secunde pe proxy locație ~* /hls/ . *\. m3u8 $ ( rescrie "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 pauză ; # cerere de rescriere / 1 / hls / la / hls - 1 / root / tmp / ; expiră 10 s ; add_header Cache - Control public ; # oferiți o bucată de videoclip de pe camere - /1/hls/live-12345678.ts sau /2/hls/live-12345678.ts # stocarea în cache pe computerul local nu este necesară # piesa este stocată în cache timp de 3 minute pe proxy locație ~* /hls/ . *\. ts $ ( rescrie "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; expiră 3 m ; add_header Cache - Control public ; ) # locație denumită dacă nu există nicio imagine locație @ fallback_img ( rescrie (. + ) / fallback . jpg break ; root / etc / nginx / ; )

Să creăm un fișier hls pentru configurația serverului rtmp cu aplicații pentru camerele noastre:

# nano cameras_rtmp_applications.conf

chunk_size 4000; aplicația hls_1 (în direct; sincronizare 10 ms; exec_static ffmpeg - i rtsp: //admin: [email protected]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls pe ; calea_hls /tmp/hls - 1/ ; # cale pentru stocarea pieselor pe server hls_fragment_naming timestamp ; # utilizați marca temporală pentru a denumi bucăți) aplicația hls_2 (în direct; sincronizare 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 pe ; calea_hls /tmp/hls - 2/ ; hls_fragment_naming timestamp ; )

Conținutul directorului /tmp/hls-1/

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767390 - 13767390 .e trăiesc - 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 - 128218 4 12821 2750.ts

Exemplu de fișier 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, live - 17544960. ts #EXTINF:5.251, live - 18020160. ts #EXTINF:5.228, live - 18492750. ts #EXTINF:5.242, live - 18963270. ts

Rezolvarea problemei cu căderea camerelor

Cea mai bună soluție este să schimbați camera glitchy. Acest lucru ajută în 90% din cazuri. Dacă nu există nicio modalitate și trebuie să treceți cumva mai departe, atunci următoarea soluție vă va ajuta.

Această soluție constă din două soluții complementare:

Rulați un proces nginx separat pentru fiecare cameră și un proces comun pentru returnarea datelor statice. Adică, pentru două camere scrieți configurații separate cu servere rtmp și una comună cu http. Atunci camera cu probleme nu va afecta procesul general.

Dacă fluxul de la cameră este întrerupt ca urmare a erorilor sale (supraîncălzire, carcasă slabă, putere PoE insuficientă etc.), atunci camera se va desprinde, procesul ffmpeg child va respinge pachetele și nginx va opri înregistrarea pieselor video. Și când procesul ffmpeg se termină, nginx va șterge toate fișierele din directorul chunks. Calculăm acest moment de curățare a folderului folosind cron și repornim procesul nginx necesar.

Pentru fiecare cameră, un script executabil este creat în /etc/init.d/, o copie a nginx, numită 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

Editarea scriptului de pornire nginx.

nano/etc/init. d/nginx

Modificați variabila DAEMON_OPTS. Daemonul principal nginx va furniza toate datele statice. De asemenea, va porni și va opri demonii responsabili pentru camere./ init . d / camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; apoi / etc / init . d/camera_2 stop fi

Adăugați la funcția do_reload:

# reîncărcați camerele dacă [ - f "/etc/init.d/camera_1" ]; apoi / etc / init . d / camera_1 reîncărcați fi if [ - f "/etc/init.d/camera_2" ]; apoi / etc / init . d/camera_2 reload fi

Edităm scriptul de lansare nginx pentru camera 1 camera_1 și pentru camera 2 camera_2 urmând exemplul.

# nano /etc/init.d/camera_1

Modificați variabilele DAEMON_OPTS și DESC

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

Să edităm scriptul de pornire nginx pentru camera 2 camera_2 urmând exemplul.

În /etc/nginx/nginx_0.conf cu locații http scriu liniile magice:

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

Acestea indică, separate printr-un spațiu, cuvântul de căutare DIR-PROCESS-NAME, directorul și numele procesului care trebuie repornit.

Examinare:

# service nginx start # service camera_1 restart * Repornirea camerei_1 pentru CAMERA - 1 configurație nginx # service camera_2 restart * Repornirea camerei_2 pentru CAMERA - 2 configurații nginx

Un script care repornește camerele. Se parcurge folderele cu piese, cautandu-le pe cele in care nu exista fisiere *.m3u8. Dacă nu există fișiere în folder, acesta caută demonul corespunzător în configurația demonului principal, folosind linia DIR-PROCESS-NAME. Îl repornește.

# nano /script/cameras_reloader.sh

Comparația HLS cu MPEG-DASH

MPEG-DASH este un analog al HLS creat de Google ca transport pentru MPEG-4. Acest transport nu este larg răspândit și practic nu este suportat. Ideologia lui este aceeași, rupe fluxul în bucăți, doar că sunt mai multe bucăți, bucăți separate pentru video, separate pentru audio. În nginx-rtmp-module, acest format este configurat în mod similar cu HLS.

Încearcă, copiază, îndrăznește!

Dacă articolul v-a fost util, vă rugăm să faceți clic pe reclamă. Mulțumesc!

Flussonic Media Server acceptă distribuția video prin protocolul HLS.

Multe dintre funcțiile disponibile nu sunt standard pentru HLS, dar le susținem pentru confortul dvs.

Codecuri acceptate: H264, H265, video MPEG2, AAC, MP3, audio MPEG2, AC-3.

Flussonic Media Server vă permite să primiți transmisiuni live, video la cerere și video din arhivă (catchup și timeshift) prin HLS.

Redare HLS simplă

Dacă aveți un flux live sau un fișier simplu (un videoclip, un audio), atunci URL-ul de redat prin HLS este foarte simplu:

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

unde flussonic-ip este un exemplu de adresă + portul Flussonic Media Server.

Flussonic Media Server acceptă, de asemenea, playlist.m3u8 la sfârșitul adresei URL pentru compatibilitate cu alte servere.

Când începeți să lucrați cu conținut multilingv sau cu rate de biți multiple, lucrurile devin mai complicate.

HLS multilingv

Dacă doriți să redați fluxul multilingv pe iPhone, trebuie să utilizați același http://192.168.2.3:8080/STREAMNAME/index.m3u8

Dar dacă doriți să vizionați un flux multilingv folosind VLC sau un set-top box, trebuie să activați video.m3u8.

URL pentru player: http://flussonic-ip/STREAMNAME/video.m3u8

Acest lucru se datorează faptului că, conform cerințelor Apple HLS, pentru fiecare limbă individuală trebuie să specificați o listă de redare separată cu o opțiune numai audio. MPEG-TS are un mecanism diferit: toate piesele audio sunt plasate lângă videoclip, iar playerul însuși alege ce va reda. Pentru ca un videoclip să poată fi vizionat pe iPhone, acesta trebuie să îndeplinească cerințele Apple. Dar VLC și set-top box-urile, încălcând standardul HLS, se așteaptă la versiunea veche a MPEG-TS convertită în HLS. Prin urmare, trebuie să includeți video.m3u8.

Adăugarea „Numai audio” pentru Apple

Apple cere ca toate fluxurile dvs. să aibă o opțiune fără video, doar audio.

Ei cred că, dacă un utilizator urmărește un videoclip prin 3G și se găsește într-o zonă de recepție incertă, este mai bine pentru el să aibă doar sunet decât tamponare.

Puteți activa această opțiune în Flussonic Media Server:

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

Vă rugăm să rețineți că acest lucru poate face ca adresa dvs. index.m3u8 să nu fie redată în VLC sau STB. În acest caz, utilizați video.m3u8 .

Rate de biți separate pentru set-top box-uri

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

Această listă de redare nu este multibitrate, conține adrese URL până la segmente, în care se află prima melodie video și toate melodiile audio disponibile.

Dacă doriți să furnizați fluxuri multilingve, cu rate de biți multiple, către set-top box-uri care nu înțeleg standardul multilingv Apple, utilizați video.m3u8:

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

Acesta este un playlist multibitrate care oferă o listă de liste de redare cu diferite calități: video1.m3u8, video2.m3u8 etc.

Redare catchup DVR

Când fluxul dvs. este deja înregistrat pe server de DVR-ul nostru, puteți reda videoclipul prin HLS utilizând orele de început și de sfârșit ale transmisiei (de exemplu, din EPG).

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

Această listă de redare va fi așa-numita. variantă, dacă fluxul conține mai mult de o pistă audio sau mai multe rate de biți. Va oferi o listă de segmente începând de la UTC 1362504585 (5 martie 2013 17:29:45 GMT) și înainte cu o oră.

Mono URL va oferi o listă de segmente care conțin toate melodiile în mpeg-ts:

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

O listă de redare videoN mai specifică va oferi o listă de segmente cu N piese video și toate piesele audio:

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

și o variantă de playlist video cu o listă de playlisturi videoN:

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

Rebobinați lista de redare

Există o listă de redare specială "rewind-N.m3u8" cu o fereastră mare „glisantă”, permițându-vă să derulați înapoi și să întrerupeți fluxurile HLS timp de mai multe ore.

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

7200 - Lungimea listei de redare HLS în secunde. Aceasta înseamnă că clienții tăi pot întrerupe emisiunea timp de 2 ore sau pot reveni la începutul unui meci de fotbal fără a accesa link-uri speciale de arhivă.