\u00e8 molto comodo ed efficace organizzare vari eventi per un grande pubblico grazie al fatto che si possono caricare segmenti una sola volta su CDN.<\/li>\n<\/ul>\n\nNonostante la semplicit\u00e0 del motore, non tutto \u00e8 cos\u00ec fluido come sembra. Il principale problema \u00e8 che gli sviluppatori di lettori di terze parti si sono discostati dalle raccomandazioni di Apple, ad esempio per quanto riguarda i formati audio supportati. In particolare, molti sviluppatori hanno iniziato ad aggiungere la possibilit\u00e0 di lavorare con flussi audio popolari: mpeg2 video, mpeg2 audio, ecc. Di conseguenza, \u00e8 stato necessario creare diversi formati di playlist per lettori diversi.<\/p>\n
Ma uno dei maggiori problemi del motore HLS \u00e8 l'alto ritardo nella trasmissione dei dati.<\/p>\n
Le origini dei \"lag\"<\/h2>\n \nLa principale causa dell'alto ritardo in HLS risiede nel fatto che i programmatori hanno creato il motore per ottenere la massima qualit\u00e0 dell'immagine. Pertanto, i parametri dell'intervallo di frame e il volume del buffer di riproduzione non sono adatti per le trasmissioni video in diretta. Questo porta a un ritardo piuttosto elevato nella trasmissione video, che pu\u00f2 raggiungere i 5-7 secondi.<\/p>\n
Da un lato, questo \u00e8 poco, ad esempio, per chi guarda un film da un server di video hosting. Ma per i sistemi di videosorveglianza il ritardo nella trasmissione video pu\u00f2 essere molto rilevante.<\/p>\n
Se stai monitorando un ufficio dove i dipendenti si allontanano dallo schermo ogni ora, allora un ritardo di 5 secondi non ha alcun valore. Ma le persone hanno iniziato a lamentarsi che, ad esempio, durante la trasmissione di una partita di calcio, nel chat hanno gi\u00e0 scritto GOOOOOL, mentre nel video questo non \u00e8 ancora apparso :). Abbiamo gi\u00e0 diversi casi d'uso in cui Ivideon deve praticamente sostituire Skype.<\/p>\n
Si pu\u00f2 eliminare il ritardo in HLS? La risposta a questa domanda suona come un discorso di un esperto cacciatore di ratti in una lezione per nuovi derattizzatori: \"Non si possono estirpare i ratti, ma la loro popolazione pu\u00f2 essere ridotta a un minimo ragionevole.\" Cos\u00ec \u00e8 con il ritardo in HLS, non sar\u00e0 possibile ridurlo a zero, ma sul mercato ci sono soluzioni che consentono di ridurre notevolmente il ritardo.<\/p>\n
Segmentazione fine<\/h2>\n \nUn altro svantaggio del motore \u00e8 l'uso di file di dimensioni ridotte per la trasmissione dei dati. Sembra che non ci sia nulla di male in questo?<\/p>\n
Chiunque abbia cercato di copiare un gran numero di piccoli file da un'unit\u00e0 a un'altra avr\u00e0 sicuramente notato che la velocit\u00e0 di scrittura di un insieme del genere \u00e8 notevolmente inferiore a quella di un singolo grande file di pari dimensioni. Inoltre, l'intensit\u00e0 delle operazioni sul disco rigido aumenta notevolmente, il che influisce negativamente sulle prestazioni complessive del computer. Pertanto, la trasmissione di dati video sotto forma di piccoli frammenti di 10 secondi contribuisce anche ad aumentare la latenza del motore.<\/p>\n
Riassumiamo brevemente tutti i pro e contro della tecnologia HLS.<\/p>\n
Vantaggi dell'HLS:<\/b><\/p>\n\nPossibilit\u00e0 di lavorare con qualsiasi dispositivo. Puoi guardare video su qualsiasi dispositivo moderno, sia esso uno smartphone, un tablet, un laptop o un PC desktop. L'importante \u00e8 che il browser web sia di una versione recente e compatibile con HTML5 e Media Source Extensions.<\/li>\n Ottima qualit\u00e0 delle immagini. La funzione di streaming adattivo consente di modificare dinamicamente la qualit\u00e0 del video trasmesso in base alla larghezza di banda della connessione Internet, cercando di mantenere la massima qualit\u00e0.<\/li>\n Nessuna necessit\u00e0 di una configurazione complessa dell'hardware da parte dell'utente.<\/li>\n<\/ol>\n\nSvantaggi:<\/b><\/p>\n\nSupporto limitato per il funzionamento del motore su alcuni dispositivi.<\/li>\n Alte latenze nella trasmissione delle immagini.<\/li>\n Aumento significativo delle inefficienze e complessit\u00e0 di ottimizzazione a causa dell'uso di file di piccole dimensioni. A causa delle caratteristiche del contenitore, non saremo mai in grado di ottenere una latenza inferiore alla dimensione del segmento.<\/li>\n<\/ol>\n\nGli svantaggi dell'HLS hanno superato i suoi vantaggi e ci hanno costretti a cercare alternative.<\/p>\n
Cos'\u00e8 WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nLa piattaforma WebRTC \u00e8 stata sviluppata da Google nel 2011 per la trasmissione di dati video e audio in streaming tra browser e app mobili con latenza minima. Per questo viene utilizzato il protocollo standard UDP e algoritmi speciali di gestione del flusso. Oggi \u00e8 un progetto open source, attivamente supportato e sviluppato da Google.<\/p>\n
WebRTC \u00e8 un insieme di tecnologie per la trasmissione peer-to-peer di video e audio. Ci\u00f2 significa che, ad esempio, i browser degli utenti possono utilizzare WebRTC per inviare dati direttamente l'uno all'altro, senza bisogno di server remoti per l'archiviazione e l'elaborazione dei dati. Tutte le informazioni vengono gestite dai browser e dalle applicazioni mobili degli utenti finali.<\/p>\n
Le comodit\u00e0 e le grandi potenzialit\u00e0 di questa tecnologia sono state apprezzate dagli sviluppatori di tutti i browser popolari. Oggi, il supporto per WebRTC \u00e8 implementato in Mozilla Firefox, Opera, Google Chrome (e in tutti i browser basati su Chromium), oltre che nelle applicazioni mobili per Android e iOS.<\/p>\n
Nonostante i suoi indiscutibili vantaggi, WebRTC presenta alcuni svantaggi significativi. <\/p>\n
Difficolt\u00e0 di scelta<\/h2>\n \nLa tecnologia WebRTC \u00e8 molto pi\u00f9 complessa in termini di interazioni di rete poich\u00e9 si basa sul P2P. \u00c8 difficile da debug, da testare, e pu\u00f2 comportarsi in modo imprevedibile. Inoltre, dobbiamo superare NAT e firewall, e garantire il funzionamento in reti dove l'UDP \u00e8 bloccato.<\/p>\n
L'implementazione di WebRTC da parte di Google \u00e8 molto difficile da utilizzare. Esiste persino un'intera azienda che offre servizi di assemblaggio SDK. Inoltre, \u00e8 stato molto complesso integrare l'implementazione di Google con il nostro sistema senza dover ricodificare tutto il video.<\/p>\n
Tuttavia, volevamo da tempo offrire agli utenti la possibilit\u00e0 di lavorare con un video \u2018live\u2019 completo e minimizzare il ritardo dell'immagine sullo schermo rispetto agli eventi stessi. Inoltre, avevamo la volont\u00e0 di rendere pi\u00f9 confortevole l'uso di telecamere PTZ, dove i ritardi hanno un\u2019importanza critica.<\/p>\n
Considerando che altre implementazioni per combattere il lag hanno ancora funzionalit\u00e0 limitate e funzionano visibilmente peggio, abbiamo deciso di utilizzare WebRTC. <\/p>\n
Cosa abbiamo fatto<\/h2>\n \n
Per il corretto funzionamento di WebRTC, \u00e8 fondamentale effettuare un ammodernamento tecnologico dello stack per la gestione video web. E questo \u00e8 esattamente ci\u00f2 che abbiamo fatto.<\/p>\n
Inizialmente abbiamo implementato un server di segnalazione del protocollo WebRTC sopra Websocket e abbiamo anche distribuito un server peer WebRTC nel cloud basato su SDK webrtc.org. Il suo compito \u00e8 quello di distribuire flussi video ai peer WebRTC client in formato H.264 + Opus\/G.711 senza riconversione video.<\/p>\n
Abbiamo scelto Websocket come protocollo di segnalazione perch\u00e9 offre gi\u00e0 un supporto di qualit\u00e0 in tutti i browser web pi\u00f9 diffusi. Questo ci consente di ridurre notevolmente sia i costi di sviluppo che il tempo e le risorse spesi per ripetere handshake TCP e TLS rispetto ad AJAX.<\/p>\n
Il fatto \u00e8 che, per impostazione predefinita, WebRTC non fornisce un protocollo di segnalazione necessario per configurare, mantenere e interrompere correttamente le videochiamate in tempo reale tra le applicazioni sorgenti e client.<\/p>\n
E per implementare autonomamente la tecnologia di segnalazione, era necessario sviluppare il nostro server di segnalazione con supporto per pi\u00f9 protocolli web (Websocet, WebRTC). Inoltre, con la capacit\u00e0 di gestire in modo sicuro le sessioni e le notifiche in tempo reale, la gestione video e molti altri parametri.<\/p>\n
Abbiamo superato le limitazioni P2P riducendo la latenza non a causa del P2P, ma attraverso UDP e gestione del flusso, mirata a ridurre la latenza. Questo \u00e8 anche integrato in WebRTC, poich\u00e9 il caso d'uso principale sono le conversazioni p2p attraverso il browser.<\/p>\n
Nel client mobile abbiamo implementato un lettore utilizzando l'SDK webrtc.org, poich\u00e9 solo in esso \u00e8 gestita correttamente la gestione del flusso, sono presenti tutti i noti schemi di Forward Error Correction (FEC) e il meccanismo di ritrasmissione dei pacchetti \u00e8 ben implementato per tutti i browser. Non \u00e8 trascurabile il fatto che l'SDK webrtc.org \u00e8 attivamente sviluppato da Google.<\/p>\n
Qual \u00e8 il risultato dell'implementazione di WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")