C'est plus conceptuel question plutôt qu'un "comment faire".
Est-il possible de mettre en œuvre un flash-comme solution pour diffuser de l'audio (indépendant de l'endroit où nous obtenons le flux de données, par exemple, de webRTC ou autres) en HTML5 et nodeJS/binaryJS. Si oui, comment voulez-vous aller à ce sujet?
Il n'y a eu qu'un seul renseigner sur stackoverflow trouvé ici et de son à partir de 2010. NodeJS et HTML5 ont grandi et mûri depuis.
Ce que les gens font d'habitude: Lors de l'utilisation de la diffusion multimédia (vidéo ou audio) à un serveur, il n'y a certainement rien qui bat Flash au point courant dans le temps jusqu'à la pleine arrivée de getUserMedia() - qui, très honnêtement, pourrait prendre un certain temps jusqu'à 99% du navigateur, les utilisateurs pourront obtenir de l'utiliser du tout.
De manière générale, les flux de données vers le serveur en utilisant un client Flash ou Flex application qui est ensuite la connexion à un protocole RTMP alimenté media server comme RED5, FMS ou Wowza. Par exemple, l'application client de l'envoi de l'entrée microphone sur RTMP pourrait ressembler (version simplifiée)
import flash.net.NetStream;
private var myMic:Microphone;
private var nc:NetConnection;
private var ns:NetStream
nc = new NetConnection();
ns = new NetStream(nc);
nc.connect(rtmp://localhost/serverApp);
myMic = Microphone.getMicrophone();
ns.attachAudio(myMic);
Avec un serveur d'application est easibly en mesure de flux de données pour le serveur.
Ce que je voudrais faire: Avoir un serveur d'application en cours d'exécution sur nodeJS (éventuellement la mise en œuvre de socketIO et binaryJS) qui attire l'entrants flux RTMP. Quelque chose comme
//require
var rtmp = require('node-rtmp'),
var fs = require('fs');
//rtmp server address
var rtmpServer = 'rtmp://localhost';
//create a binary server listening that receives stream data
var RTMPServer = rtmp.RTMPServer();
var server = RTMPServer ({port: 1935});
server.on('connection', function(client){
//check if user is allowed to do so
rtmp.newStream(client.stream);
});
Éventuellement, il pourrait être préférable d'utiliser socketIO de différencier les interactions de l'utilisateur via eventEmitters.
Quels pourraient être les avantages:d' une manière générale, il semble comme un peu de surcharge de faire ce genre d'approche, mais pour moi, il pourrait y avoir des avantages et j'aimerais aussi vous faire des commentaires sur cette.
- facile de validation de l'interaction de l'utilisateur en exécutant par exemple, exprimer et socketIO
- hybride de la mise en œuvre d'un flash (via RTMP) et getUserMedia() (via binaire mécanismes de transport par l'ajout de binaryJS et Mozilla AudioAPI)
- si getUserMedia() est entièrement pris en charge, flash implémentations peuvent être supprimés facilement
- plus de contrôle sur le protocole de suivi et d'interaction de l'utilisateur en général
- facilité de mise en œuvre dans le serveur de cadres
Mise à JOUR: J'ai parlé à M. Malcontenti-Wilson, qui est responsable pour le seul nœud-rtmp paquet qui a été écrit, mais abandonnées il y a 8 mois comme il a été mal écrit et il a frappé un barrage routier. Toute personne qui a utilisé ce ou a été en mesure de vérifier le code?
Mise à JOUR 2: M. Malcontenti-Wilson, il suffit de m'envoyer un mail pour obtenir mon attention à nœud-mtrude (drôle de nom), qui est en train de faire un peu ce que nous n'aurions probablement le souhaitez. Quelqu'un a travailler avec ce type de forfait?
