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

Question

Sto cercando di capire concettualmente il modo migliore per fornire contenuti audio e video streaming reali. Vorrei che fosse consumato con un browser web, utilizzando la minima quantità di tecnologia proprietaria. Non servirò file statici e utilizzando il download progressivo, si tratterebbe di veri e propri stream audio acquisiti dal vivo. Come si trasmette uno stream che sarà ragionevolmente sincronizzato con la fonte? Che tipo di protocollo è adatto?

Edit:

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

Lo streaming HTTP è un po 'inadatto se si esegue lo streaming di una performance/comunicazione dal vivo in quanto si basa su TCP (come basato su HTTP) e non si perdono pacchetti. In una situazione di bassa larghezza di banda, il client può ottenere molto indietro nella riproduzione. ref

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

RTSP/RTP è ciò che Microsoft ha adottato utilizzando, deprecando il loro protocollo MMS. RTSP è il protocollo di controllo. È simile a HTTP con alcune differenze distinte: il server può anche comunicare con il client e ci sono altri comandi, come PAUSE. È anche un protocollo stateful, che viene mantenuto con un id di sessione. RTP è il protocollo per la consegna del payload (audio o video codificato). Ci sono alcuni progetti open source, uno dei quali è supportato dalla mela here. Sembra che questo potrebbe fare ciò che voglio, e sembra quite a few players support it. Sembra che sia adatto per una trasmissione "live" da questa pagina here.

Grazie, Josh

Answer 1

In primo luogo, mi permetta di staccare due punti non corretti in fretta. Dettagli da seguire qui sotto:

• RTMP può essere fatto su altri server di Flash Media Server
• TCP va bene per vivere. C'è troppa F.U.D. dalla gente che ama UDP là fuori. Apple has just released a draft specification di fare semplice, live streaming su HTTP (e quindi TCP) per l'iPhone. Mi aspetto che finirà anche nei browser. Inoltre, TCP ha il vantaggio di passare attraverso i firewall aziendali molto più frequentemente e facilmente.

La mia lettura è che lo streaming complesso e basato su UDP si assottiglia. Non sto prevedendo la morte, solo una quota minore e minore del mercato. I server di streaming basati su UDP consumano enormi risorse, relative a soluzioni basate su TCP (come 10x o più), ei vantaggi non sono così tangibili.

Si dice che non si desidera la tecnologia proprietaria e "crap su [Flash]", ma si desidera comunque eseguire lo streaming reale? Odio dirlo a te, ma entrambi RealAudio e RealVideo sono entrambi di proprietà.

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

• Theora: una standard royalty-free aperto, con perdita di dati tecnologia video compressione
• Vorbis: un progetto sorgente del software libero/open che produce una specifica e software in formato implementazione audio per compressione audio con perdita.
• Ogg: un libero, standard aperto formato contenitore

Se pragmatismo ottiene il meglio di te, allora riconsiderare la vostra avversione per i prodotti Adobe. Ricorda, Flash è più ampiamente distribuito di qualsiasi altro player basato su browser (Windows Media Player, Quick Time e Real Player)

È ancora possibile utilizzare RTMP con open source: Red5 è probabilmente di maggiore interesse - può streaming live ai browser abilitati per Flash.

Consiglierei di pensare alle vostre priorità. Spiegaci per noi nella tua domanda.

Answer 2

Aggiungo alla risposta di Stu che i protocolli di streaming basati su UDP spesso hanno una complessità aggiuntiva da utilizzare dietro firewall o NAT. Ad esempio, se si prevede di utilizzare i punti di accesso Wi-Fi all'esterno della casa, molti di questi non supporteranno l'RTP utilizzando la consegna UDP. Molti client hanno un meccanismo di failback in cui se nessun pacchetto viene ricevuto prima di un timeout, il client tenterà di eseguire il TCP.