Il download HTTP progressivo è un'alternativa valida a HLS / DASH / RTMP per fornire video dal vivo?

16

Sto lavorando su un sito web che ha bisogno di trasmettere video in diretta agli utenti, e come tale ho dovuto fare i conti con lo stato spiacevole dell'attuale tecnologia di streaming video basata su browser. Le soluzioni più popolari per lo streaming live al momento hanno tutti problemi di compatibilità; RTMP richiede Flash, HLS è supportato solo nativamente su Safari e Chrome per Android, DASH non è nativamente supportato ovunque e utilizzando dash.js richiede Media Source Extensions , che non sono ancora ampiamente supportate.

Questo mi porta a una domanda che a me sembra ovvia: è possibile utilizzare il semplice download progressivo in alternativa a protocolli come HLS, RTMP e DASH che richiedono supporto browser o plug-in?

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

Non ho visto nessuna istanza di questa tecnica utilizzata in natura per video , tuttavia, e non so dirti perché. Sembra che rimuoverà uno strato di problemi di compatibilità lato browser disordinati e difficili per un compromesso relativamente limitato. (E la compatibilità è ancora un enorme problema per lo streaming live, anche quando i professionisti lo fanno, se provo a guardare video in diretta 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 nemmeno menzionare l'idea oltre a me.

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

    
posta Mark Amery 15.07.2015 - 21:38
fonte

1 risposta

3

La tua domanda è valida e, teoricamente, penso che possibile utilizzare Download progressivi per lo streaming di video live. In realtà un sacco di 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 i casi d'uso del Live Streaming, però! Che altrimenti i protocolli di streaming (RTMP, ecc.) Fanno da soli. Ecco alcuni motivi per preferire questi protocolli e questa architettura:

1. Bit Rate variabile

La maggior parte dei video in streaming live è codificata in VBR e il tuo video dovrà adattarsi rapidamente alla variazione della congestione della rete del tuo cliente. In questo modo il tuo video può passare più risoluzioni in un tempo molto breve a seconda della velocità o della lentezza della connessione client.

Secondo Wikipedia

It works by detecting a user's bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly

2. Contenuti dal vivo

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

3. Disabilita Ricerca

Un problema minore, ma il protocollo non dovrebbe consentire specificamente all'utente di cercare 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 non affidabile

Sono un po 'poco chiaro su questo punto, ma so che una volta disconnesso un download HTTP in arrivo, potrebbe volerci del tempo per stabilire un altro handshake (anche con keep-alive ). I protocolli live sono molto più veloci da connettere e disconnettere a causa del prossimo punto - >

5. Latenza

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

Per ulteriori informazioni, vedere qui - > link

6. Copia dei contenuti

La maggior parte dei server live streaming rispondono solo al contenuto dell'ora corrente. Sebbene sia ancora possibile copiare il contenuto dei live streaming, è necessario ricorrere alla cattura dello schermo ecc. Fornire un download progressivo HTTP semplifica l'operazione di copia dei contenuti (quindi tanti downloader di YouTube là fuori).

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

Il HTTP Live Streaming (HLS) di Apple, hai menzionato, si avvicina di più a quello che stai cercando di ottenere.

E c'è una ricerca attiva in corso in questo campo come indicato qui - > link

Sto cercando altre informazioni e aggiornerò questa risposta.

    
risposta data 06.10.2015 - 16:21
fonte

Leggi altre domande sui tag