Come per lo streaming audio semi-live su internet

Question

Voglio scrivere qualcosa di simile a Skype, ad esempio ho un flusso audio costante su un computer e poi recompress in un formato che è adatto per una connessione internet latente, riceverlo su l'altra estremità e riprodurlo.

Supponiamo anche che la connessione internet è abbastanza moderno e veloce, vale a dire DSL o simili, senza connessioni lente sopra il telefono e così via. I computer coinvolti saranno anche piuttosto moderni (CPU Dual Core Intel a 2GHz o superiore).

So come gestire l'audio sulle macchine. Quello che non so è come trasmettere l'audio in modo efficiente.

Le sfide sono:

1. Mi piacerebbe ottenere una buona qualità audio in tutta la linea.

2. Il flusso dovrebbe essere ricevuto senza gocce. Il flusso può, tuttavia, essere ricevuto con un piccolo ritardo (un secondo ritardo è accettabile). Immagino che il software di trasporto potrebbe in primo luogo determinare la latenza media (e max), quindi avviare il flusso e dire al ricevitore ad aspettare che la latenza massima prima di iniziare a riprodurre l'audio. Con ciò, se la latenza non ottiene più in alto, l'intero flusso sarà riproducibile sull'altro lato senza balbuzie o gocce.

3. Se, a causa di latenze IP inaspettati o blocchi, il flusso di fa vengono tagliati, voglio essere in grado di notare questo in modo che posso prendere azioni (ad esempio, interrompere il flusso) e, infine, iniziare una nuova trasmissione.

Quali sono le opzioni se voglio faccio uso di software già pronti per la compressione e tranmission? Non ho alcuna intenzione di scrivere il mio motore di compressione audio, davvero. OTOH, ho intenzione di vendere la soluzione in un mercato verticale, il che significa che posso permettermi un paio di dollari di costi di licenza per copia, ma non $ 100s.

Credo che la soluzione più semplice sarebbe quella di aprire solo un flusso TCP, inviare alcuni pacchetti avanti e indietro per determinare il loro tempo di esecuzione (o anche utilizzare UDP per quello), quindi utilizzare i risultati come la guida per il mio valore massimo di latenza , poi semplicemente sparare i dati audio nella sua forma grezza (non compresso bit stereo 16), insieme a un codice di sincronizzazione tramite la connessione TCP. Il ricevitore legge i dati e lo riproduce con il ritardo pre-determinato. Che potrebbe anche lavorare con il tipo di connessione veloce mi aspetto.

Mi chiedo solo se ci sono soluzioni migliori per raggiungere questo obiettivo, con prestazioni migliori (latenza inferiore) e meno dati (compressi).

A proposito, ho cerco di implementare questo su OS X, ma potrebbe desiderare di farlo su Windows, anche se avrà successo.

Answer 1

Per la trasmissione audio su Internet probabilmente si dovrebbe guardare con RTP. E 'utilizzato per la SIP, H.323, e molti altri utilizzare questo per lo streaming di contenuti audio. Si potrebbe anche voler guardare solo utilizzando un lirbary SIP. E 'già molto di quello che suona come si desidera. SIP può avere qualità piuttosto buona se si dispone di un buon codec, e larghezza di banda sufficiente.

• http://tools.ietf.org/html/rfc3550
• http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

Answer 2

VLC supporta vari tipi di audio e video transcoding. Potrebbe essere qualcosa che si desidera controllare .

Answer 3

Lo so che è una specie filo-un vecchio, tuttavia, un intuizione che voglio condividere con voi è questo: non è possibile utilizzare il protocollo TCP per questo che si sta cercando di fare a causa della latenza si richiede - hai detto secondo 1 è accettabile, e da quel considera che oltre 1sec non è.

Il tuo latenza con il protocollo TCP non è determinato con PING di ospitare. Il problema con il protocollo TCP è che quando ci si connette e si accetta di vivere con una certa latenza, qualche problema con una connessione si ridurrà della finestra TCP, tutti i dati inviati saranno caduto e protocollo sottostante dovranno gestirlo. In questo momento, si perde il vantaggio 1sec corso in tempo reale e il flusso verrà abbandonato.

TCP è un bene per la situazione in cui grandi ritardi sono accettabili (diciamo 10 secondi o più) che vi permetterà di avere sempre dati sufficienti per mangiare e giocare prima connessione viene ristabilita.

Se fossi al tuo posto, cercherò il seguente:

• UDP per il trasporto
• qualche basso-delay codifica - AAC-LD per esempio, ma mp3 sarebbe anche OK
• avere un po 'matematica in testa set-up sopra l'UDP così se un pacchetto viene perso, il flusso audio può recuperare.

A proposito, fotogrammi a mp3 sono 40msec lungo. Con un po 'magico' si potrebbe mascherare qualche perdita di frame.

Answer 4

SHOUTcast + SAM Broadcaster o Winamp. Farà il trucco facilmente.

Answer 5

Se stai cercando di iniziare la propria stazione radio Internet utilizzando icecast2 è possibile:

• installare icecast sul vostro VPS

    #sudo apt-get install icecast

• installare ezstream anche su di voi VPS

    #sudo apt-get install ezstream

• creare un file di playlist con i file

playlist.m3u (si può leggere di più forma wikipedia )

    #EXTM3U

    #EXTINF:123, Sample artist - Sample title
    Sample.mp3

    #EXTINF:321,Example Artist - Example title
    Example.ogg

• Crea un file di configurazione XML ezstream

config.xml

<ezstream>
    <url>http://localhost:8000/stream</url>
    <!--
      If a different user name than "source" should be used, set it in
      <sourceuser/>:
     -->
    <!-- <sourceuser>mr_stream</sourceuser> -->
    <sourcepassword>hackme</sourcepassword>
    <format>MP3</format>
    <filename>playlist.m3u</filename>
    <stream_once>1</stream_once>
    <svrinfoname>My Stream</svrinfoname>
    <svrinfourl>http://www.oddsock.org</svrinfourl>
    <svrinfogenre>RockNRoll</svrinfogenre>
    <svrinfodescription>This is a stream description</svrinfodescription>
    <svrinfobitrate>128</svrinfobitrate>
    <svrinfochannels>2</svrinfochannels>
    <svrinfosamplerate>44100</svrinfosamplerate>
    <svrinfopublic>0</svrinfopublic>
</ezstream>

In alternativa si può provare questo: nodejs applicazione