2016-04-18 12 views
0

Ich muss den webRTC "capture of medias" Part verwenden und den Video/Audio Stream an einen Server senden. Zuerst dachte ich über websockets nach, um diesen Stream zu senden, aber es sah kompliziert aus, ich fand nur einige Beispiele, die das Video in eine Leinwand zeichneten und das generierte Bild dank WebSockets schickten; schwer. Also denke ich, die beste Lösung ist, die RTCPeerConnection API zu verwenden, um eine 1: 1-Peer-Verbindung zu erstellen und dann den Rest dieser API zu verwenden, um den Stream zu übertragen. Ist das möglich und nicht dumm? Wenn es nicht ist, würde ich gerne wissen, ob es möglich ist, einen einfachen ICE-Server zu erstellen, um nur zwei Peers mit einer bekannten IP zu verbinden (oder gibt es eine Möglichkeit, diese ICE-Server zu vermeiden?)WebRTC, gefälschter ICE Server für 1: 1 (Client-Server) Verbindung

Vielen Dank für Ihre Antworten! :)

+0

haben Sie sich MCU/SFU angesehen? – mido

+0

Keine Notwendigkeit, in eine Leinwand zu zeichnen. Verwenden Sie MediaRecorder. Siehe [meine Antwort auf eine andere Frage] (http://stackoverflow.com/a/34997248/918910). – jib

+0

Nun, ich habe mich wirklich darum gekümmert. Ich nehme an, dass ich aufgenommene Teile (als Binärdaten) senden kann, während ich Video/Audio einnehme? (Ich kann es gerade jetzt nicht testen) – Ernest

Antwort

0

Es gibt keinen ICE-Server. ICE ist ein Protokoll (https://tools.ietf.org/html/rfc5245) zum Aufbau von Netzwerkverbindungen.

Abgesehen davon, wenn ich Ihre Frage richtig verstehe, möchten Sie WebRTC verwenden, um einen Medienstream zwischen zwei Peers herzustellen. Wenn ja, ist die Antwort ja, genau dafür ist WebRTC da. Die WebRTC-Peers kümmern sich um den ICE-Teil selbst. Wenn sie sich jedoch in verschiedenen privaten Netzwerken befinden, müssen Sie möglicherweise einen STUN- und TURN-Server einbeziehen.

+0

Hallo, ich möchte eine "Client-Server" Verbindung machen. Also habe ich über die Verwendung der webrtc peer2peer Funktionalität nachgedacht und betrachte meinen Server als Standard Peer. Aber ich möchte (wenn möglich) diesen STUN/TURN-Teil vermeiden, weil ich offensichtlich meine Server-IP kenne und mein Server meinen Klienten IP leicht kennen kann. Danke :) – Ernest

+0

@Ernest Nö, Server würde nur Client öffentlich kennen, wird nicht helfen, wenn der Client hinter einem NAT ist – mido

+0

In Ordnung. Also muss ich zumindest einen STUN-Server benutzen oder? Weißt du, ob es noch eine andere Möglichkeit gibt, meinen Stream an den Server zu senden? – Ernest

0

Sie verwechseln P2P mit Client/Server - das sind zwei verschiedene Dinge. WebRTC verwendet beides - die Erkennung ist Client/Server (Stun) und das Streaming ist P2P (ICE).

Discovery ist wichtig, um P2P zu initiieren. Die Peers müssen die IP-Adressen der anderen kennen. Hier kommt Stun ins Spiel - es ist eine zentrale Registry (Server) von Peers, auf die mit einem Stun-Client zugegriffen wird.

Sobald zwei Peers die gegenseitigen Adressen über Stun entdecken, trennen sie sich vom Stun-Server und beginnen direkt über das ICE-P2P-Protokoll miteinander zu streamen.

+0

Danke, aber ich verstehe die Grundlagen von webRTC. Was ich tun wollte, ist: eine One-to-One Peer-Verbindung gefälscht, um Daten von einem Client zu einem Server zu übertragen. OK, das hat mit ICE-Servern nichts zu tun. Momentan sende ich nur Video-Chunks als binäre Daten über Websockets. – Ernest