Streaming video / audio basato su browser (non download progressivo)

Question

Sto cercando di capire concettualmente il modo migliore per fornire contenuti audio e video in streaming reali. Vorrei che fosse consumato con un browser Web, utilizzando la minima quantità di tecnologia proprietaria. Non servirei file statici e utilizzerei il download progressivo, questi sarebbero veri e propri flussi audio catturati dal vivo. Come si fa a trasmettere un flusso che sarà ragionevolmente sincronizzato con la fonte? Che tipo di protocollo è adatto?

Modifica

Nella ricerca ho scoperto che ci sono alcuni protocolli: RTSP, HTTP Streaming, RTMP e RTP.

Streaming HTTP è alquanto inadatto se si esegue lo streaming di una performance / comunicazione dal vivo di qualche tipo perché si basa su TCP (come basato su HTTP) e non si perdono i pacchetti. In una situazione di larghezza di banda ridotta, il client può essere notevolmente indietro nella riproduzione. ref

RTMP è una tecnologia proprietaria che richiede un server multimediale flash. Merda. Il motivo per cui ho visto il flash è perché sono estremamente flessibili per quanto riguarda l'esperienza dell'utente. SoundManager2 offre un'eccellente interfaccia javascript per la riproduzione di file multimediali con flash. Questo è ciò che vorrei cercare in un'applicazione client.

RTSP / RTP è ciò che Microsoft ha passato usando, deprecando il loro protocollo MMS. RTSP è il protocollo di controllo. È simile a HTTP con alcune distinte differenze: il server può anche parlare con il client e ci sono comandi aggiuntivi, come PAUSE. È anche un protocollo con stato, che viene mantenuto con un ID di sessione. RTP è il protocollo per la consegna del payload (codificato audio o video). Ci sono alcuni progetti open source, uno dei quali è supportato da Apple qui . Sembra che questo potrebbe fare quello che voglio, e sembra che parecchi giocatori lo supportano . Sembra che sarebbe adatto per un "live" trasmesso da questa pagina qui .

Grazie, Josh

Answer 1

Prima di tutto, lasciami eliminare rapidamente due punti errati. Di seguito i dettagli:

• RTMP può essere eseguito su server diversi da Flash Media Server
• TCP va bene per il live. C'è troppo F.U.D. dalle persone amanti dell'UDP là fuori. Apple ha appena rilasciato una bozza di specifiche per lo streaming semplice e in diretta su HTTP (e quindi TCP) per iPhone. Mi aspetto che finirà anche nei browser. Inoltre, TCP ha il vantaggio di superare i firewall aziendali molto più frequentemente e facilmente.

La mia lettura è che lo streaming complesso e basato su UDP si sta affievolendo. Non prevedo la morte, ma solo una quota sempre minore del mercato. I server di streaming basati su UDP consumano enormi risorse, rispetto alle soluzioni basate su TCP (come 10x o più), e i vantaggi non sono così tangibili.

Dici di non volere la tecnologia proprietaria e " merda su [Flash] " ;, ma vuoi comunque fare streaming reale? Odio infrangerlo, ma sia RealAudio che RealVideo sono entrambi proprietari.

Se andare all'Open Source è davvero così importante per te, che posso capire, allora dovrai ignorare la stragrande maggioranza del mercato dei media streaming. Dai un'occhiata a

• Theora : un video gratuito e senza diritti d'autore > tecnologia di compressione
• Vorbis : un software gratuito / progetto open source che produce un audio specifica del formato e implementazione del software per la compressione audio con perdita di dati.
• Ogg : un formato contenitore standard aperto e gratuito

Se il pragmatismo ottiene il meglio da te, riconsidera la tua avversione per i prodotti Adobe. Ricorda, Flash è distribuito più ampiamente di qualsiasi altro lettore basato su browser (vale a dire Windows Media Player, Quick Time e Real Player.)

Puoi comunque utilizzare RTMP con open source: Red5 è probabilmente di grande interesse: può trasmettere in streaming su Flash browser abilitati.

Consiglierei di pensare alle tue priorità. Spiegali per noi nella tua domanda.

Answer 2

Aggiungerei alla risposta di Stu che i protocolli di streaming basati su UDP hanno spesso complessità aggiuntiva per funzionare dietro firewall o NAT. Ad esempio, se si prevede di utilizzare i punti di accesso WIFI al di fuori della propria abitazione, molti di questi non supporteranno RTP utilizzando la consegna UDP. Molti client hanno un meccanismo di failback in cui se non vengono ricevuti pacchetti prima di un timeout, il client tenterà la consegna TCP.