Flussonico server multimediale supporta la distribuzione video tramite protocollo HLS.

Molti di opportunità disponibili non sono standard per HLS, ma li supportiamo per tua comodità.

Codec supportati: H264, H265, video MPEG2, AAC, MP3, audio MPEG2, AC-3.

Flussonic Media Server ti consente di ricevere TV in diretta, video on demand, video dall'archivio (catchup e timeshift) tramite HLS.

Facile riproduzione HLS

Se disponi di un semplice live streaming o di un file (un video, un audio), l'URL da riprodurre tramite HLS è molto semplice:

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

dove flussonic-ip è un esempio dell'indirizzo + porta del tuo Flussonic Media Server.

Flussonic Media Server accetta anche playlist.m3u8 alla fine dell'URL per retrocompatibilità con altri server.

Quando inizi a lavorare con contenuti multilingue o multibitrate, le cose si complicano.

HLS multilingue

Se vuoi riprodurre il tuo stream multilingue su iPhone, devi utilizzare lo stesso http://192.168.2.3:8080/STREAMNAME/index.m3u8

Ma se vuoi guardare uno streaming multilingue usando VLC o un set-top box, devi includere video.m3u8.

URL per il lettore: http://flussonic-ip/STREAMNAME/video.m3u8

Ciò è dovuto al fatto che, in base ai requisiti di Apple HLS, è necessario specificare una playlist separata con un'opzione solo audio per ogni singola lingua. MPEG-TS ha un meccanismo diverso: tutte le tracce audio vengono posizionate accanto al video e il giocatore stesso sceglie cosa verrà riprodotto. Affinché un video possa essere visualizzato su un iPhone, deve soddisfare le linee guida di Apple. Ma VLC e set-top box, in violazione dello standard HLS, aspettano la vecchia versione di MPEG-TS convertita in HLS. Pertanto, è necessario includere video.m3u8 .

Aggiunta di "solo audio" per Apple

Apple richiede che tutti i tuoi stream abbiano un'opzione senza video, solo audio.

Ritengono che se l'utente sta guardando video su 3G e, una volta nella zona di ricezione incerta, sarà meglio per lui avere solo il suono piuttosto che il buffering.

Puoi abilitare questa opzione in Flussonic Media Server:

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

Tieni presente che ciò potrebbe rendere il tuo indirizzo index.m3u8 non riproducibile in VLC o set-top box. In tal caso, usa video.m3u8 .

Bitrate separati per set-top box

Quando disponi di contenuti multilingue multi-bitrate e desideri riprodurli su un set-top box che non supporta le playlist HLS multi-bitrate, puoi richiedere singole playlist con un video e tutte le tracce audio da Flussonic Media Server, come con il mono opzione:

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

Questa playlist non è multi-bitrate, contiene l'URL dei segmenti, in cui la prima traccia video e tutte le tracce audio disponibili.

Se desideri fornire flussi multilingua multibitrate a set-top box che non supportano lo standard multilingue di Apple, utilizza video.m3u8:

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

Questa è una playlist multi-bitrate che fornisce un elenco di playlist con diverse qualità: video1.m3u8, video2.m3u8 ecc.

Riproduzione recupero DVR

Quando il tuo stream è già registrato sul server dal nostro DVR, puoi riprodurre il video tramite HLS utilizzando gli orari di inizio e fine della trasmissione (ad esempio, da EPG).

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

Questa playlist sarà la cosiddetta. variante se ce ne sarà più di una nello stream traccia sonora o più di un bitrate. Elencherà i segmenti a partire da UTC 1362504585 (2013 Mar 5 17:29:45 GMT) e un'ora avanti.

Mono URL fornirà un elenco di segmenti contenenti tutte le tracce in mpeg-ts:

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

Una playlist videoN più specifica fornirà un elenco di segmenti con N traccia video e tutte le tracce audio:

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

e una playlist video variante con un elenco di playlist videoN:

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

Riavvolgi la playlist

C'è una playlist speciale "rewind-N.m3u8" con un'ampia finestra "scorrevole" che consente di riavvolgere e mettere in pausa i flussi HLS per lunghe ore.

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

7200 - Lunghezza della playlist HLS in secondi. Ciò significa che i tuoi clienti possono mettere in pausa la trasmissione per 2 ore o tornare all'inizio di una partita di calcio senza accedere a speciali collegamenti di archivio.

Elaborando, archiviando e trasmettendo video per il suo progetto online, piuttosto che utilizzare siti come YouTube, si pone inevitabilmente la questione di quale protocollo di trasferimento utilizzare per trasmettere video ai dispositivi degli utenti. La scelta è piccola, perché Esistono numerosi standard di settore che supportano determinati dispositivi. Inoltre, la scelta del protocollo dipende in gran parte dalla "classe" del video: trasmissione in diretta o video su richiesta. La scelta di un media server, che sarà il motore della tua macchina multimediale, dipende anche dalla scelta del protocollo: installerai diversi server eterogenei o costruirai una rete di distribuzione basata su un'unica soluzione? Pertanto, devi soppesare tutto e prendere una decisione in base ai criteri della tua attività.

In generale si ottiene un'equazione con molte incognite. La dinamica del processo è importante qui: dove sta andando l'industria in generale? E se investo nella tecnologia di supporto e morirà tra un anno, perché è già successo. O scommetterò su una tecnologia alla moda, ma nessuno la supporta?

Abbiamo deciso di valutare in che modo la quota di diversi protocolli è cambiata nel tempo, per esaminare l'intero processo in modo dinamico. I dati sono stati presi dall'anno scorso.

Dati iniziali

Per cominciare, chi siamo noi per giudicare le quote di mercato? Siamo gli sviluppatori di un servizio web di reportistica per media server. È il quarto anno che lavoriamo sul mercato e le aziende si rivolgono a noi con infrastrutture diverse, diversi numeri di server ed esigenze diverse. Si scopre un buon cast dello stato del settore.

Abbiamo realizzato un piccolo report in cui è possibile selezionare un intervallo di date e ottenere dati con un grafico sul numero di visualizzazioni video attraverso diversi protocolli.

Il report fornisce dati sui server:

• Wowza Streaming Engine in tutte le versioni dalla 2.2 all'ultima 4.x; più - 3.x.
• Nimble Streamer che funziona con HLS, Smooth, HDS e download progressivo è il nostro sviluppo.
• Servizi Windows Media: ce ne sono letteralmente un paio di dozzine, ma esistono e dobbiamo tenerne conto

Al momento della stesura di questo documento, il servizio serve circa 1000 server da 60 paesi.

Il rapporto viene aggiornato periodicamente anche sul nostro blog, è disponibile sotto il tag corrispondente.

andare

Il rapporto per giugno/luglio 2014 è simile a questo. Da 1,4 miliardi di visualizzazioni più della metà sono HLS. Al secondo posto c'è RTMP con un quarto delle visualizzazioni. RTSP è circa un sesto. Il resto è nella regione dell'errore statistico.

Cos'è successo un anno fa per lo stesso periodo? La situazione è quasi speculare. RTMP - quasi due terzi, RTSP e HLS condividono il secondo e il terzo posto. È vero, la base per le misurazioni era quasi 3 volte inferiore - "solo" 500 milioni di visualizzazioni. C'erano anche meno server nel nostro servizio, ovviamente.

Andiamo tra questi due punti.

Quindi, giugno - agosto 2014, 3 mesi d'estate. 800 milioni di visualizzazioni, ma le quote sono le stesse, agosto non ha apportato modifiche.

Settembre - novembre 2013. È iniziata una nuova stagione, HLS ha iniziato a divorare la quota di RTMP. Totale 1,1 miliardi di visualizzazioni, RTMP ha circa la metà del totale, HLS ha un quarto.

dicembre 2013 - febbraio 2014. 1,4 miliardi di visualizzazioni, di cui HLS rappresenta oltre il 40%. RTMP e RTMP sono al secondo e terzo posto con un quarto di quota. Le Olimpiadi di Sochi hanno aumentato il numero di visualizzazioni e allo stesso tempo hanno costretto i provider a ricordare tutti i clienti con tutti i loro dispositivi esotici o vecchi che capiscono solo RTSP, da qui il salto in questo protocollo.

Come ha dimostrato la pratica, il miglior trasporto per video rispetto a RTMP è HLS. Motivi per questo:

Proxy molto semplice, con memorizzazione nella cache tramite nginx. In primo luogo perché la telecamera, in quanto dispositivo, non può servire, di norma, più di 10 connessioni contemporaneamente. In questo senso, il proxy garantito dei flussi RTMP è possibile solo tramite soluzioni a pagamento e richiede molta potenza. Non è necessario alcun software server speciale.

Semplificazione dell'intera infrastruttura server. In virtù dell'idea, il video è dato a pezzi, attraverso la porta 80 via http. Lo stesso Nginx può essere responsabile della restituzione della statica. La restituzione della statica (pezzi video di 50kB) è un compito molto semplice per nginx.

Poiché il numero di pezzi è costante, quelli vecchi vengono rimossi, ne vengono aggiunti di nuovi, disco fisso non traboccherà mai.

La prevalenza è maggiore di quella di RTMP. HLS con codifica video H.264 è supportato da iOS e funziona perfettamente. A partire dal 1 luglio 2014, le connessioni video in streaming con trasporto HLS sono del 55%, RTMP - 26%, RTSP - 15% e MPEG-DASH inferiore all'1%.

Supporto di maggioranza dispositivi mobili, desktop, computer tablet direttamente dal browser.

Molto più semplice della trasmissione in RTSP in linea di principio. Poiché non esistono procedure come push (pubblicazione di un flusso) o pull (ottenimento di un flusso).

Formato molto più amichevole http.

Gli svantaggi sono i seguenti:

Tuttavia, non tutti i dispositivi supportano questo formato. Versioni Android meno di 4.2 non supporta ufficialmente il codec e il trasporto H.264, ma su Android, invece di un browser, puoi usare applicazione di terze parti- ad esempio MX Player

Tutto dipende dalla fotocamera. Se la fotocamera è difettosa, ad esempio Dlink DCS-3010, l'intero sistema funzionerà molto male (ffmpeg cade costantemente). Ad esempio, le telecamere AXIS M1011-W, HIKVISION DS-2CD2412F-IW funzionano bene in un pacchetto del genere (fino a un mese senza lamentele (non l'ho testato più a lungo)). Stessa strada Grande importanza ha il passaggio dei cavi. In questo senso, considereremo l'opzione ideale.

Cos'è il trasporto HLS

Flusso video codificato h.264 (a proposito: la linea di base del profilo è comprensibile Dispositivi Android), è suddiviso in pezzi con estensione *.ts, ad esempio, 5 secondi ciascuno, viene creata una playlist in live.m3u8 , con una descrizione sequenziale di questi pezzi. La lunghezza della playlist è predeterminata, ad esempio 10 pezzi. Quando viene visualizzato l'undicesimo pezzo di video, il primo pezzo di video viene eliminato e la playlist viene ricreata. Maggiori dettagli possono essere trovati sul sito Web dello sviluppatore.

Affinché il sistema funzioni, imposteremo l'immagine dalle telecamere nel modo in cui vogliamo vederla sul sito, il formato dell'immagine e la qualità dell'immagine. Non ricodificheremo sul server. La fotocamera è progettata per fornire l'immagine di cui hai bisogno. Le fotocamere di solito hanno diversi profili. È possibile configurare un profilo per H.264, per HLS e il secondo con MPEG4 per MPEG-DASH. È inoltre possibile impostare una qualità diversa per un canale Internet ampio e stretto. Pensa per te stesso - decidi per te stesso.

Importante! La fotocamera dovrebbe avere un'immagine di output che non necessita di essere ricodificata.

Schema strutturale per carico elevato

Fotocamera (rtsp) ----->

-----> una connessione FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> una connessione a un proxy nginx intermedio con una cache di grandi dimensioni =====>

=====> molti client JWPlayer(hls).

Il nostro server si connette con ffmpeg alla telecamera e si registra con l'applicazione nginx hls. nginx crea i pezzi e la playlist in una directory specifica. Quindi invia questi pezzi al server proxy. I client si connettono al server proxy utilizzando JWPlayer .

Configurazione dell'applicazione nginx

Costruiamo nginx con nginx-rtmp-module. Questa procedura è descritta in dettaglio nell'articolo.

Supponiamo di avere diverse fotocamere, le divideremo per numero di serie. Descriverò la configurazione nginx per 2 telecamere. Mettiamo nella cache le immagini statiche per 5 minuti nella cache locale, se l'immagine non si carica entro 5 secondi, diamo una schermata iniziale statica.

# nano /etc/nginx/nginx.conf

Modifica la configurazione di nginx

dati www dell'utente; worker_processes auto ; pid/run/nginx. pid ; log_errore/var/log/nginx/nginx_error. eseguire il debug del registro ; env PERCORSO ; events ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error . log ; include mime . types ; default_type application / octet - stream ; sendfile on ; keepalive_timeout 65 ; proxy_cache_path / var / www / cache / livelli locali = 1 : 2 keys_zone = nginx_local_cache : 1 m inattivo = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; server ( listen 80 ; # rtmp stat location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # puoi spostare stat . xsl in una posizione diversa root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html ;location = / 50 x .html ( root html ; ) include cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( listen 1935 ; ping 30 s ; notify_method get ; includere cameras_rtmp_applications . conf ; ) )

Crea un percorso cache # mkdir /var/www/cache/local Correggi i permessi della cache:

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

Creiamo posizioni http per le telecamere:

# nano cameras_http_locations.conf

tipi ( applicazione / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # dà l'immagine dalla telecamera 1 - /1/img/ # sono diversi per tutte le fotocamere, perché gli indirizzi IP della fotocamera sono diversi "http://192.168.0.2/GetImage.cgi?CH=1"# dà l'immagine dalla telecamera 2 - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; scade 1 m ; # cache per 1 minuto add_header Cache - Control public ; # per memorizzare nella cache sul proxy proxy_ignore_headers Cache - Control ; # per rimuovere le intestazioni dalla telecamera proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Autorizzazione "Base" ; errore_pagina 502 504 404 @ fallback_img ; ) # assegna la playlist - /1/hls/live.m3u8 o /3/hls/live.m3u8 # playlist viene memorizzata nella cache per 10 secondi sul proxy posizione ~* / hls / . * \ . m3u8 $ ( riscrittura "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; # richiesta di riscrittura / 1 / hls / to / hls - 1 / root / tmp / ; scadenza 10 s ; add_header Cache - Controllo public ; ) # dare un pezzo di video dalle telecamere - /1/hls/live-12345678.ts o /2/hls/live-12345678.ts # memorizzazione nella cache attivata computer locale non richiesto # il pezzo viene memorizzato nella cache per 3 minuti sul proxy posizione ~* / hls / . * \ . ts $ ( riscrittura "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; scadenza 3 m ; add_header Cache - Control public ; ) # posizione denominata se non è presente alcuna immagine location @ fallback_img ( rewrite (. + ) / fallback . jpg break ; root / etc / nginx / ; )

Creiamo un file di configurazione hls per il server rtmp con le applicazioni per le nostre telecamere:

# nano cameras_rtmp_applications.conf

chunk_size 4000 ; application hls_1 ( live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //amministratore: [e-mail protetta]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hl su ; percorso_hls / tmp / hls - 1 / ; # percorso per la memorizzazione dei pezzi sul server hls_fragment_naming timestamp ; # usa il timestamp per denominare i blocchi ) application hls_2 ( live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //amministratore: [e-mail protetta]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hl su ; percorso_hls / tmp / hls - 2 / ; hls_fragment_naming timestamp ; )

Contenuto della directory /tmp/hls-1/

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767390. ts live - 16602660. ts live - 19435050. ts live - 11405250. ts live - 14239260. ts live - 17072820. ts live . m3u8 live - 11878560. ts live - 14710860. ts live - 17544960. ts live - 12348630. ts live - 15182550. ts live - 18020160. ts live - 12821760. ts live - 15658740. ts live - 180 ts275

Esempio di file 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, dal vivo - 17544960. ts #EXTINF:5.251, dal vivo - 18020160. ts #EXTINF:5.228, dal vivo - 18492750. ts #EXTINF:5.242, dal vivo - 18963270. ts

Risolvere il problema con la caduta delle telecamere

Più la decisione giusta, cambia la fotocamera buggy. Aiuta il 90% delle volte. Se non c'è modo e devi in ​​\u200b\u200bqualche modo vivere, la seguente soluzione ti aiuterà.

Questa soluzione è composta da due - complementari:

Esegui un processo nginx separato per ogni telecamera e processo generale al ritorno della staticità. Cioè, per due telecamere, scrivi configurazioni separate con server rtmp e una comune con http. Quindi la fotocamera buggy non influirà sul processo generale.

Se il flusso dalla videocamera viene interrotto a causa del suo bug (surriscaldamento, cablaggio scadente, alimentazione insufficiente su PoE, ecc.), la videocamera si interromperà, il processo figlio ffmpeg rifiuterà i pacchetti e nginx smetterà di scrivere parti video . E quando il processo ffmpeg termina, nginx rimuoverà tutti i file dalla directory dei blocchi. Calcoliamo questo momento di pulizia della cartella tramite cron e riavviamo il processo nginx necessario.

Per ogni telecamera, viene creato uno script eseguibile in /etc/init.d/, una copia di nginx , denominato camera_1 e 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

Modifica dello script di avvio nginx.

nano /etc/init. d/nginx

Modifica la variabile DAEMON_OPTS. Il demone nginx principale servirà tutto lo statico. Avvierà e arresterà anche i demoni responsabili delle telecamere. / init . d /camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; quindi /etc/init. d/camera_2 stop fi

Aggiungi alla funzione do_reload:

# ricarica le telecamere if [ - f "/etc/init.d/camera_1" ]; poi /etc/init. d / camera_1 ricarica fi if [ - f "/etc/init.d/camera_2" ]; poi /etc/init. d/camera_2 ricarica fi

Modifichiamo lo script di avvio nginx per la telecamera 1 camera_1 e per la telecamera 2 camera_2 secondo l'esempio.

# nano /etc/init.d/camera_1

Modifica delle variabili DAEMON_OPTS e DESC

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

Modifichiamo lo script di avvio nginx per la telecamera 2 camera_2 secondo l'esempio.

In /etc/nginx/nginx_0.conf con posizioni http scrivo righe magiche:

# NOME-PROCESSO-DIR /tmp/hls-1/camera_1 # NOME-PROCESSO-DIR /tmp/hls-2/camera_2

Indicano la parola di ricerca DIR-PROCESS-NAME, separata da uno spazio, la directory e il nome del processo da riavviare.

Visita medica:

# service nginx start # service camera_1 restart * Riavvio di camera_1 per CAMERA - 1 configurazione nginx # service camera_2 restart * Riavvio di camera_2 per CAMERA - 2 configurazione nginx

Script che ricarica le telecamere. Passa attraverso le cartelle dei blocchi, cercando dove non ci sono file *.m3u8. Se non ci sono file nella cartella, cerca il demone corrispondente in base alla configurazione del demone principale, tramite la riga DIR-PROCESS-NAME . Lo ricarica.

# 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 PERCORSO = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin mask = "*.m3u8" dir = "/tmp/ hls-*" funzione find_process()( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# NOME-PROCESSO-DIR" | grep $1 | cut -d" " -f4) echo $process_str ) per hls_dir in $dir ; do find_result = $(find $hls_dir -name $mask -type f) if [ -z $find_result ] ; then process = $(find_process $hls_dir ) service $processo riavvio fi done sleep 15s

Confronto tra HLS e MPEG-DASH

MPEG-DASH è un analogo di HLS creato da Google, come trasporto per MPEG-4. Questo trasporto non è diffuso e praticamente non è supportato. La sua ideologia è la stessa, spezzare il flusso in pezzi, solo più pezzi, pezzi separati per il video, pezzi separati per l'audio. In nginx-rtmp-module, questo formato è configurato in modo simile a HLS.

Prova, copia, fallo!

Se l'articolo ti è stato utile, clicca sull'annuncio. Grazie!

La creazione di applicazioni tecnicamente ideali è solitamente un compito estremamente complesso e dispendioso in termini di tempo. Allo stesso tempo, le informazioni utili sono spesso sparse su più fonti. Questo vale, tra l'altro, per lo sviluppo di applicazioni video per iOS. Questo articolo contiene le informazioni più importanti e utili che consentono di utilizzare qualitativamente l'intera gamma di funzionalità HTTP Live Streaming, nonché un elenco di fonti primarie. Questi materiali saranno utili a tutti i lettori interessati a creare servizi video di alta qualità e di facile utilizzo.

Rafforzare la convenienza e l'interattività dei servizi video si ottiene attraverso avvio veloce e riavvolgimento, così come la mancanza di buffering. Per ottenere il miglior risultato, si suggerisce la seguente serie di azioni.

• A partire dalla bassa qualità video. Per avviare un video è necessario almeno un blocco. Di conseguenza, minore è la dimensione di un blocco, più veloce inizierà il video. Riducendo il bitrate del flusso iniziale e riducendo la durata del blocco si ottiene un avvio video più veloce. Consigliamo una durata del blocco di 4-8 secondi e un bitrate iniziale di 200-300 Kbps. Pertanto, per avviare la riproduzione del video, l'utente dovrà scaricare un massimo di 300 kb.
• Ottimizzazione della playlist. Le playlist possono occupare una parte significativa del flusso di dati complessivo, in particolare con blocchi di piccole dimensioni e contenuti lunghi (diverse ore). Nella maggior parte dei casi, quando si trasferiscono le playlist su un lettore video, si consiglia di archiviarle.
• fotogrammi chiave.È desiderabile avere almeno un frame IDR per segmento, preferibilmente proprio all'inizio del segmento. Inoltre, durante il trasferimento di video in reti cellulari si consiglia di eseguire i fotogrammi chiave almeno una volta ogni 3 secondi.
• TS in alto. HTTP LS utilizza MPEG TS come contenitore, quindi è molto importante ridurre al minimo l'overhead di TS (dovrebbe essere inferiore al 10% anche a bassa qualità video). In questo caso, vale la pena misurare i bitrate reali utilizzando i dump del traffico e ottimizzando i packer (segmentatori) utilizzati.
• Il parametro Durata target nella playlist. Questo parametro influisce sul tempo di avvio, ma Apple consiglia di impostarlo su 10 secondi perché valori più bassi aumentano la possibilità di buffering, soprattutto su reti cellulari ad alta latenza. Inoltre, non è consigliabile creare segmenti più lunghi di 20 secondi.
• bitrate dinamico. Il meccanismo di streaming adattivo integrato in iOS funziona in modo ottimale a bitrate specificati con precisione in una playlist variante (tenendo conto del traffico della playlist stessa). In questo caso, per i flussi con bitrate variabile, è necessario specificare un valore più vicino al massimo. In caso contrario, sono possibili decisioni errate sulla modifica del flusso video corrente. I bitrate vicini dovrebbero differire in velocità di 1,5 - 2 volte.
• Streaming "solo audio". Il codec audio HE-AAC è significativamente più efficiente ed è supportato dalla maggior parte dei dispositivi. Si consiglia di implementare la distribuzione di canali solo audio utilizzando MPEG Elementary Stream e non MPEG Transport Stream (un overhead molto più piccolo).

Man mano che sviluppi il tuo lettore video, puoi ottenere informazioni utili dal registro HTTP Live Streaming (accessLog). Contiene dati su come è avvenuta la commutazione automatica, quali bitrate sono stati utilizzati, ecc. Dettagli delle informazioni disponibili nel registro. Sulla base di questi dati, sarai in grado di raccogliere dati di analisi video sui tuoi utenti.

Raccomandazioni aggiuntive
Nel caso di trasmissioni online, il buffering video è possibile anche a causa di ritardi nel CDN, nonché nei casi in cui il tempo di aggiornamento della playlist è troppo breve e il server non ha il tempo di generare segmenti in tempo. Per ottimizzare il meccanismo di riavvolgimento, si consiglia di utilizzare valori di durata del segmento non interi (effettivi), altrimenti potrebbe accumularsi un errore.

Se la tua applicazione è destinata ad essere utilizzata su diversi dispositivi, è possibile specificare una qualità video diversa a diverse risoluzioni dello schermo nell'elenco. In questo modo sarai in grado di visualizzare diversi video su un iPad con display Retina e su un iPhone relativamente vecchio.

Il protocollo HTTP Live Streaming fornisce anche meccanismi di failover (che indicano sorgenti video ridondanti). Questa funzione può essere utile per migliorare l'affidabilità dei tuoi servizi.

Fonti di conoscenza
Un breve elenco di risorse sull'utilizzo di HTTP Live Streaming nelle applicazioni video:
Bozza di streaming live HTTP
Domande frequenti sullo streaming live HTTP
Best practice per HLS

Infine, vale la pena notare che per gli sviluppatori Mac/iOS/Safari registrati, gratuito video tecnici sessioni con WWDC 2012, dove ce ne sono anche molte informazioni utili, in particolare, sul lavoro con i video e sull'utilizzo di HTTP Live Streaming.

Fornitura di servizi TV IP via Internet e locale reti di computer sta diventando sempre più diffuso. Sul territorio dei paesi della CSI non ci sono quasi grandi fornitori che non trasmettono video multicast alle loro reti locali, cioè quelle che forniscono il servizio ITV. Ma la fornitura di servizi TV al di fuori del suo rete locale associato ad alcuni costi hardware e alla complessità di fornire la qualità di trasmissione richiesta.

Streaming live HTTP conosciuto anche come HLS, è un protocollo di comunicazione implementato da Mela. La sua particolarità è che il flusso complessivo è suddiviso in una sequenza di piccoli file di download, ogni download scarica un piccolo frammento del flusso di trasporto. Quando viene riprodotto un flusso, il cliente può scegliere tra diversi flussi alternativi contenenti lo stesso materiale, registrato a diversi bit rate, permettendogli di adattarsi al bit rate disponibile. All'inizio di una sessione di streaming, viene caricata una playlist M3U (m3u8) estesa contenente metadati per i vari substream disponibili. Poiché le richieste utilizzano solo operazioni HTTP standard, HTTP Live Streaming è in grado di bypassare qualsiasi firewall o server proxy che consenta il traffico HTTP standard, a differenza dei protocolli UDP come RTP.

HLS è basato su HTTP. HLS definisce anche un meccanismo di crittografia standard utilizzando AES e un modo per distribuire una chiave di sicurezza utilizzando HTTPS o cookie HTTP, che insieme forniscono sistema semplice protezione del diritto d'autore.

Principio di funzionamento HLS

Scopriamo ora quali sono i vantaggi e gli svantaggi di questa tecnologia. I vantaggi sono innegabili ed evidenti. Questa è, prima di tutto, l'adattabilità della velocità di trasferimento dei dati alle proprietà della linea e del dispositivo ricevente e, in secondo luogo, i meccanismi di protezione del copyright integrati. In terzo luogo, non è richiesto alcun router con larghezza limitata flusso multicast su WI_FI, che aiuterebbe ad evitare l'assorbimento dell'intera larghezza del canale da parte dei flussi multicast, nel caso di trasmissione televisiva IP utilizzando il multicast. Inoltre non richiede un dispositivo aggiuntivo con la funzione Proxy UDP per convertire un flusso multicast in HTTP, che è spesso richiesto per i dispositivi mobili, sebbene influisca sul carico hardware sul router o su un altro dispositivo che esegue la funzione proxy UDP nella rete locale dell'abbonato. Lo standard HLS è diventato abbastanza comune ed è supportato da quasi tutti i moderni lettori video e set-top box per IPTV.

Set-top box IPTV

Uno svantaggio significativo è che gli abbonati dispongono di set-top box multimediali e set-top box per smart TV con firmware obsoleto o design obsoleto che non supportano gli standard HLS o non li supportano correttamente. Inoltre, uno dei problemi è l'impossibilità di scegliere la giusta qualità per una trasmissione stabile in condizioni di cambiamento delle caratteristiche della linea in intervalli di tempo inferiori alla durata del frammento video richiesto.