Il download HTTP progressivo è una valida alternativa a HLS / DASH / RTMP per fornire video live?

Sto lavorando su un sito Web che deve trasmettere in streaming video in diretta agli utenti e, come tale, ho dovuto concentrarmi sul triste stato dell'attuale tecnologia di streaming video basata su browser. Le soluzioni più popolari per lo streaming live al momento hanno tutte problemi di compatibilità; RTMP richiede Flash, HLS è supportato solo in modo nativo su Safari e Chrome per Android, DASH non è supportato in modo nativo da nessuna parte e l'utilizzo di dash.js richiede l' estensione di sorgenti multimediali , che non sono ancora ampiamente supportate.

Questo porta a una domanda che per me sembra ovvia: è possibile utilizzare un semplice download progressivo come alternativa a protocolli come HLS, RTMP e DASH che richiedono il supporto del browser o plugin?

L'idea di utilizzare il download progressivo per lo streaming di contenuti multimediali in diretta non ha precedenti; le persone lo fanno già per l'audio. Strumenti come liveCaster ti consentono di trasmettere in streaming audio MP3 live attraverso una singola risposta HTTP progressiva senza la necessità di un file MP3 preregistrato e librerie come AmplitudeJS hanno fatto di tutto per aggiungere funzionalità relative a questo tipo di streaming audio live .

Non ho visto nessun caso di questa tecnica utilizzata in natura per i video , e non so dire perché. Sembra che eliminerebbe uno strato di problemi di compatibilità lato browser disordinati e difficili per un compromesso relativamente piccolo. (E la compatibilità è ancora un grosso problema per lo streaming live, anche quando i professionisti lo fanno; se provo a guardare video live su iPlayer della BBC in Firefox, mi dà solo un messaggio di errore che mi dice di installare Flash.) Eppure nessuno sta usando questa tecnica, e non ho mai visto nessuno menzionare l'idea oltre a me.

Perché? C'è una limitazione fondamentale che non vedo che renderebbe impossibile lo streaming di un file video come un MP4 tramite download progressivo mentre viene generato e riprodurlo in un <video>elemento durante il download?

— Mark Amery
fonte

Non potresti utilizzare una libreria javascript HLS (ad esempio, hls.js qui: github.com/video-dev/hls.js/tree/master ) per aggiungere il supporto HLS tra browser per la tua pagina? Immagino che questo forse non esistesse quando hai posto questa domanda originariamente ... ma adesso lo è. :)

— stuckj,

La tua domanda è valida e teoricamente penso che tu possa utilizzare Download progressivi per lo streaming video live. In realtà molti video in streaming online come YouTube ecc. Già utilizzano HTTP. Presumo che tu stia parlando strettamente dello streaming LIVE e non solo dello streaming.

Dovrai implementare tu stesso i casi d'uso di Live Streaming! Che altrimenti i protocolli di streaming (RTMP ecc.) Fanno da soli. Ecco alcuni motivi per preferire questi protocolli e architettura:

1. Bit rate variabile

La maggior parte dei video in streaming live è codificata in VBR e il tuo video dovrà adattarsi rapidamente alle mutevoli congestioni di rete del tuo client. Quindi il tuo video può passare a risoluzioni multiple in pochissimo tempo a seconda di quanto è veloce o lenta la connessione client.

Secondo Wikipedia

Funziona rilevando la larghezza di banda di un utente e la capacità della CPU in tempo reale e regolando la qualità di un flusso video di conseguenza

2. Contenuti live

Il punto più importante è che lo streaming live significa contenuto live . A differenza del download progressivo HTTP, non è possibile eseguire il buffer in qualsiasi momento. L'utente deve vedere l'ultimo frame destinato a tutto il mondo e non può rimanere indietro.

3. Disabilitare la ricerca

Un problema minore, ma il protocollo non dovrebbe specificamente consentire all'utente di cercare all'indietro (e ovviamente in avanti). Questo non dovrebbe essere controllato solo a livello di Video Player ma anche a livello di rete.

4. Disconnessioni frequenti / rete inaffidabile

Non sono abbastanza chiaro su questo punto, ma so che una volta disconnesso un download HTTP in entrata, può essere necessario del tempo per stabilire un'altra stretta di mano (anche con keep-alive). I protocolli live sono molto più veloci per connettersi e disconnettersi a causa del punto successivo ->

5. Latenza

HTTP viene eseguito intrinsecamente su TCP, che garantisce la consegna garantita dei pacchetti. Confronta questo con UDP utilizzato in molti protocolli (in particolare i giochi multiplayer live) in cui la priorità è la priorità rispetto alle garanzie.

Per ulteriori informazioni, vedere qui -> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6. Copia del contenuto

La maggior parte dei server di streaming live risponderà solo al contenuto dell'ora corrente. Anche se è ancora possibile copiare il contenuto di streaming live, è necessario ricorrere alla cattura dello schermo, ecc. Dare un download progressivo HTTP rende il compito di copiare il contenuto abbastanza banale (quindi molti downloader di YouTube là fuori).

Ora, HTTP può essere modellato per fornire la maggior parte di quanto sopra.

HTTP Live Streaming (HLS) di Apple , che hai citato, si avvicina di più a ciò che stai cercando di ottenere.

E c'è una ricerca attiva in corso in questo campo come indicato qui -> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

Sono alla ricerca di maggiori informazioni e aggiornerò questa risposta.

— Gaurav Ramanan
fonte

Sembra errato menzionare la latenza come uno svantaggio dell'utilizzo del download progressivo HTTP dato che i principali concorrenti includono DASH e HLS che forniscono segmenti di video tramite più richieste HTTP sequenziali. Non conosco tutti i dettagli dei protocolli, ma suppongo che quest'ultimo approccio richieda una latenza minima almeno della lunghezza del segmento utilizzata, mentre con l'approccio del download progressivo non esiste una latenza minima teorica - la latenza inferiore dovrebbe essere un annuncio vantaggio dell'approccio download progressivo, giusto?

— Mark Amery,

Inoltre, alcune delle altre preoccupazioni qui - come la ricerca e il ripristino da disconnessioni - sono problemi che si applicano ugualmente a un'implementazione JavaScript di DASH, ma presumibilmente dash.js le supera. Immagino che potrebbero essere superati per un lettore di download progressivo semplicemente rubando qualsiasi soluzione gli sviluppatori dash.js hanno escogitato.

— Mark Amery,

@MarkAmery Se si confronta con DASH e HLS, sì, credo che sia comparabile. Ma se lo confronti con alcuni dei protocolli più vecchi su UDP, allora HTTP perde a mani basse! Anche se vedi molti sistemi in tempo reale oggi sono creati utilizzando Websocket e evitano HTTP a causa dei suoi problemi di latenza.

— Gaurav Ramanan,

La facilità di copia dei contenuti è un vero svantaggio rispetto a dash.js e HLS. E non sono sicuro di come i flussi di bit rate variabili possano essere implementati utilizzando il download progressivo, anche se mi aspetto che sarebbe possibile con un po 'di astuzia.

— Mark Amery,

@MarkAmery Quando si tratta di streaming in tempo reale e live, dobbiamo considerare le prestazioni e non solo le possibilità. Esaminerò DASH ma mi chiedo se ci sono benchmark che mostrano confronti di prestazioni tra i protocolli di streaming e il recupero HTTP da una disconnessione.

— Gaurav Ramanan,