Streaming hls. Kada koristiti HLS protokol

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, a svako preuzimanje preuzima 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, što bi pomoglo u izbjegavanju apsorpcije cijele širine kanala od strane multicast tokova u slučaju emitiranja IP televizije korištenjem multicasta. Također, nije potreban dodatni uređaj 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.

Obrada, pohranjivanje i prijenos videa za njegov online projekt, umjesto korištenja stranica poput YouTubea, neizbježno dovodi do pitanja koji prijenosni protokol koristiti za emitiranje videa na uređaje korisnika. Izbor je mali, jer... Postoji niz industrijskih standarda koji podržavaju određene uređaje. Osim toga, izbor protokola uvelike ovisi o “klasi” videa - prijenos uživo ili video na zahtjev. Izbor medijskog poslužitelja koji će biti pokretač vašeg medijskog stroja također ovisi o izboru protokola: hoćete li instalirati nekoliko heterogenih poslužitelja ili izgraditi mrežu isporuke na jednom rješenju? Stoga morate sve odvagnuti i donijeti odluku prema kriterijima vašeg poslovanja.

Općenito, dobivamo jednadžbu s mnogo nepoznanica. Ovdje je bitna dinamika procesa – kamo industrija uopće ide? Što ako uložim u podršku tehnologije, ali ona propadne za godinu dana, jer se to već dogodilo. Ili ću se kladiti na modernu tehnologiju, ali je nitko ne podržava?

Odlučili smo procijeniti kako se udio različitih protokola mijenjao tijekom vremena – kako bismo sagledali dinamiku cijelog procesa. Podaci su uzeti za prošlu godinu.

Početni podaci

Za početak, tko smo mi da sudimo o tržišnim udjelima? Mi smo programeri usluge web izvješćivanja za medijske poslužitelje. Radimo na tržištu već četiri godine i dolaze nam tvrtke s različitim infrastrukturama, različitim brojem servera i različitim potrebama. Ispostavilo se da je to dobar snimak stanja industrije.

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

Izvješće daje podatke o poslužiteljima:

• Wowza Streaming Engine u svim verzijama, od 2.2 do najnovije 4.x; većina ih je 3.x.
• Nimble Streamer, koji radi s HLS, Smooth, HDS i progresivnim preuzimanjem, naš je razvoj.
• Windows Media Services - ima ih doslovno nekoliko desetaka, ali postoje i moramo ih uzeti u obzir

Izvješće se također povremeno ažurira na našem blogu; dostupno je pod odgovarajućom oznakom.

Idemo

Izvještaj za lipanj/srpanj 2014. izgleda otprilike ovako. Iz 1,4 milijarde pregleda više od polovice su HLS. Na drugom mjestu je RTMP s četvrtinom pregleda. RTSP je otprilike šestina. Ostali su u području statističke pogreške.

Što se dogodilo prije godinu dana u istom razdoblju? Situacija je gotovo zrcalna slika. RTMP - skoro dvije trećine, RTSP i HLS dijele drugo i treće mjesto. Istina, mjerna baza bila je gotovo 3 puta manja - "samo" 500 milijuna pregleda. Bilo je i manje poslužitelja u našoj službi, naravno.

Prošetajmo između ove dvije točke.

Dakle, lipanj - kolovoz 2014., 3 mjeseca ljeta. 800 milijuna pregleda, no dionice su iste, kolovoz nije donio nikakve promjene.

Rujan - studeni 2013. Počela je nova sezona, HLS je počeo gutati RTMP-ov udio. Ukupno 1,1 milijarda pregleda, RTMP ima oko polovicu ukupnog broja, HLS ima četvrtinu.

prosinac 2013. - veljača 2014. 1,4 milijarde pregleda, od čega HLS već sada čini više od 40%. RTMP i RTMP dijele drugo i treće mjesto s četvrtinom udjela. Olimpijske igre u Sočiju dale su povećanje broja pregleda i istovremeno natjerale pružatelje da zapamte sve klijente sa svim svojim egzotičnim ili starim uređajima koji razumiju samo RTSP - otuda skok u ovom protokolu.

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 proxyvanje 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, kroz port 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.

Budući da je broj komada konstantan, stari se uklanjaju, novi se dodaju, tvrdi disk nikada neće biti pun.

Prevalencija je veća nego kod RTMP-a. HLS s H.264 video kodiranjem podržava iOS i radi bez dodatnih koraka. Prema podacima od 1. srpnja 2014. iz čvorišta, streaming video veze s HLS transportom - 55%, RTMP - 26%, RTSP - 15% i MPEG-DASH manje od 1%.

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. video zapis, 1 video zapis 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` lokacija / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; istječe 1 m ; # predmemorija za 1 minutu add_header Cache - Control public ; # za predmemoriju na proxyju proxy_ignore_headers Cache - Control ; # za uklanjanje zaglavlja iz kamere proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1"; 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 lokacija ~* /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

lokacija ~* /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 @ zamjena_img (prepisati (. +) / zamjena. jpg prekid; korijen / 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;

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 18963270. ts live - 10930050. ts live - 13767390. ts live - 16602660. ts live - 1943505 0 .ts uživo - 11405250. ts uživo - 14239260. ts uživo - 17072820. ts uživo . m3u8 uživo - 11878560. ts uživo - 14710860. ts uživo - 12348630. ts uživo - 15182550. ts uživo - 18020160. ts uživo - 15658740. ts uživo - 184 9 2750.ts

Primjer datoteke live.m3u8

#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

# 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. U /etc/nginx/nginx_0.conf s http lokacijama pišem čarobne retke:

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

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

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

# nano /script/cameras_reloader.sh

#!/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 ) usluga $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!

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

Flussonic Media Server omogućuje vam primanje prijenosa uživo, video na zahtjev i video iz arhive (catchup i timeshift) putem HLS-a.

Jednostavna HLS reprodukcija

Ako imate jednostavan live stream ili datoteku (jedan video, jedan audio), tada je URL za reprodukciju putem HLS-a vrlo jednostavan:

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

gdje je flussonic-ip primjer adresa + port vašeg Flussonic Media Servera.

Flussonic Media Server također prihvaća playlist.m3u8 na kraju URL-a radi kompatibilnosti s drugim poslužiteljima.

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

Višejezični HLS

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

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

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

To je zbog činjenice da, prema zahtjevima Apple HLS-a, za svaki pojedinačni jezik trebate navesti zasebni popis za reprodukciju s opcijom samo za zvuk. MPEG-TS ima drugačiji mehanizam: svi zvučni zapisi smješteni su uz video, a player sam bira što će reproducirati. Da bi video bio vidljiv na iPhoneu, mora ispunjavati Appleove zahtjeve. Ali VLC i set-top boxovi, kršeći HLS standard, očekuju staru verziju MPEG-TS-a pretvorenu u HLS. Stoga morate uključiti video.m3u8.

Dodavanje "Samo audio" za Apple

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

Smatraju da ako korisnik gleda video preko 3G mreže i nađe se u području nesigurnog prijema, za njega je bolje da ima samo zvuk nego buffering.

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

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

Imajte na umu da ovo može učiniti vašu adresu index.m3u8 nemogućnom za reprodukciju u VLC ili STB. U ovom slučaju koristite video.m3u8 .

Odvojene brzine prijenosa za set-top box uređaje

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

Ovaj popis za reprodukciju nije multibitrate, on sadrži URL-ove do segmenata, u kojima je prvi video zapis i svi dostupni audio zapisi.

Ako želite isporučiti višejezične, višebitne 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 višebitni popis za reprodukciju koji nudi popis popisa za reprodukciju različitih kvaliteta: video1.m3u8, video2.m3u8 itd.

DVR nadoknađena reprodukcija

Kada je vaš stream već snimljen na poslužitelju putem 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 playlista će biti tzv. varijanta, ako stream sadrži više od jednog audio zapisa ili više od jedne brzine prijenosa. Dat će popis segmenata počevši od UTC 1362504585 (2013. 5. ožujka 17:29:45 GMT) i jedan sat unaprijed.

Mono URL će dati popis segmenata koji sadrže sve pjesme u mpeg-ts:

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

Specifičniji videoN popis za reprodukciju dat će popis segmenata s N video zapisa i svih audio zapisa:

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

i varijanta popisa za reprodukciju videozapisa s popisom popisa za reprodukciju videoN:

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

Premotaj popis za reprodukciju

Postoji posebna lista za reprodukciju "premotavanje-N.m3u8" s velikim "kliznim" prozorom, koji vam omogućuje premotavanje i pauziranje HLS streamova na više sati.

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

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