Posso utilizzare una sorta di memoria locale come luogo di attesa temporaneo per getUserMedia per near-RTC?

Question

Possiedo un caso d'uso che non richiede esattamente comunicazioni in tempo reale, ma il più vicino possibile per assicurarmi che i miei utenti non debbano attendere per sempre il caricamento di un file dopo il fatto. Il nostro sito consente agli utenti di registrare video e audio che poi memorizziamo sul nostro server.

Sono passato dal flash, perché flash, a un'implementazione WebRTC con un server multimediale Kurento. Funziona molto bene con connessioni Internet di alta qualità ma è relativamente carente per gli utenti con scarsa connettività.

Stavo pensando se potrei un po 'come implementare un po' di buffer prima di alimentare il server in modo che possa compensare i tuffi nella connettività che sarebbe l'ideale. Capisco che questo non è ciò che era inteso per WebRTC, il che porta alla domanda se ci sia o meno un'altra soluzione che dovrei esaminare?

Qualsiasi e tutti i suggerimenti sono benvenuti e apprezzati! Grazie!

Answer 1

Un buffer non modifica le caratteristiche realtime di WebRTC di fronte a una larghezza di banda ridotta. Con il video, ad esempio, WebRTC potrebbe degradare la frequenza dei fotogrammi o la risoluzione per tenere il passo, ma nessuno ha proposto un tempo di consegna degradante (calo di realtime-ness). Il tuo è comunque un caso d'uso interessante.

È possibile utilizzare MediaRecorder. Permetterebbe di registrare localmente e quindi inviare i dati come BLOB al server con websocket o canali di dati.

Ecco un violino che funziona in Chrome (che fa solo video purtroppo) e Firefox:

https://jsfiddle.net/tmwLxjLy

Essa mostra la registrazione semplice e quindi la riproduzione del video 5 secondi più tardi. Lo lascerò come esercizio per modificarlo per causare un ritardo continuo di 5 secondi.