Zum Inhalt springen

WebRTC

WebRTC Digest – Week of 6/3 – IE, Hype, and Security

WebRTC im Internet Explorer?

A Blogbeitrag und einige Tweets Aussagen einer Microsoft-Entwicklerkonferenz schienen darauf hinzudeuten, dass Microsoft Fortschritte bei WebRTC im Internet Explorer macht (zumindest im Kontext von …). Lync ohne Plugin ausführenEs scheinen keine Angaben darüber vorzuliegen, ob es sich um CU-WebRTC oder um Standard-WebRTC handelt. WebRTC, oder etwas ganz anderes.

Hype-Check

Cisco teilte weiterhin den Artikel der letzten Woche mit dem Titel “Die Realität von WebRTC… Nur Hype?”. mehrere Tsahi Levent-Levi veröffentlichte daraufhin eine Gegendarstellung, in der er Folgendes erklärte:

WebRTC ist die bisher bahnbrechendste Technologie im Bereich VoIP. Nicht etwa, weil sie neue Technologien beinhaltet, sondern weil sie die Implementierung neuer Anwendungsfälle ermöglicht.

Sicherheit und WebRTC

Aktuelle Nachrichten Dies löste eine Diskussion über die Sicherheit und den Datenschutz von WebRTC aus. Justin Uberti, Leiter des Chrome WebRTC-Teams. hat einen Beitrag geteilt, verfasst vom Mozilla-Mitarbeiter Adam Roach, bietet einen guten Überblick über die Problematik: “WebRTC: Sicherheit und Vertraulichkeit”Cullen Jennings, Cisco-Mitarbeiter und Co-Vorsitzender von RTCWeb war einer der vielen Mitwirkenden an einem kürzlich verfassten Bericht, der die Gefahren des Hinzufügens aufzeigt. Abhör-Endpunkte zu Internetdiensten.

Tunneling WebRTC over TCP (and why it matters)

Vor einigen Wochen haben wir stillschweigend die Unterstützung für bidirektionales TCP-Tunneling in der vLine Cloud aktiviert und sind damit der erste Anbieter geworden, der dies ermöglicht. WebRTC-Infrastrukturanbieter Um Verbindungen durch Firewalls zu ermöglichen, die UDP blockieren. Das mag zunächst uninteressant oder unwichtig klingen, macht aber tatsächlich den Unterschied zwischen einem Dienst, der “meistens eine Verbindung herstellt”, und einem, der “einfach funktioniert”. Wir erklären es Ihnen:

Einer der vielen Vorteile von WebRTC ist der relativ einfache Einstieg. Starten Sie eine Instanz von apprtc Sie benötigen ein Backend für die Signalisierung, müssen nur etwas JavaScript kopieren und einfügen, und schon können Sie Videoanrufe in Ihrer App tätigen (eigentlich ist es etwas schwieriger, aber ein guter Webentwickler kann innerhalb von ein bis zwei Tagen eine vorführbare Video-Chat-Funktion bereitstellen).

Leider kann der Weg von der Demoversion zum produktionsreifen Service schwieriger (und teurer!) sein als erwartet. So läuft es üblicherweise ab: 

Stufe 1: BELASTUNG

Sie beginnen mit Ihren ersten Anrufen über ein lokales Netzwerk, und alles funktioniert einwandfrei. Hurra! Dann versuchen Sie, jemanden außerhalb Ihrer Firewall anzurufen, und eines von zwei Dingen wird passieren.

1) Falls Sie die Adresse des Google STUN-Servers aus dem apprtc-Quellcode kopiert haben, wird Ihr Anruf erfolgreich durchgeführt und Sie werden zufrieden sein (obwohl Sie möglicherweise Zweifel haben, ob die Nutzung eines undokumentierten Dienstes, für den Google Drittanbietern keine ausdrückliche Genehmigung erteilt hat, zulässig ist). Beachten Sie das Schweigen von Google zu diesem Thema. dieser Thread).

2) Wenn kein STUN-Server konfiguriert ist, schlägt Ihr Anruf fehl. Eine kurze Recherche wird zeigen, dass STUN ist ein Protokoll Der Browser verwendet STUN, um seine öffentliche IP-Adresse zu ermitteln und die Firewall zu umgehen. Um also eine Verbindung durch eine Firewall herzustellen, benötigen Sie einen STUN-Server. Wenige Stunden später ist Ihr Open-Source-Server auf EC2 betriebsbereit. Eine kleine Instanz reicht in der Regel aus (1.420 £ 43,92 pro Monat), aber für eine höhere Verfügbarkeit empfiehlt es sich, mindestens zwei Instanzen zu betreiben, idealerweise in verschiedenen Regionen (dafür 1.420 £ 87,84 pro Monat).

Level 2: RUNDE

Sie führen einige weitere Testanrufe durch, und alle funktionieren. Alles sieht gut aus. Dann versuchen Sie, einen Anruf zwischen zwei Firmennetzwerken zu tätigen, und er schlägt fehl. Ärgerlich! Bei Ihrer Recherche zu STUN haben Sie Folgendes gelesen: ein weiteres Protokoll namens TURN Das dient der Datenübertragung, wenn der Browser keine Peer-to-Peer-Verbindung herstellen kann. Sie waren sich nicht sicher, ob das unbedingt nötig ist, aber weitere Recherchen zeigen, dass STUN nur für etwa 80% Anrufe ausreicht. Falls Ihnen das nicht genügt (und das tut es wahrscheinlich), benötigen Sie einen TURN-Server.

Ein paar Threads in der Mailingliste Später haben Sie einen TURN-Server auf Ihrer EC2-Instanz eingerichtet und in Betrieb. Tatsächlich kann der Netzwerkdurchsatz einer kleinen Instanz ziemlich unvorhersehbar sein, wenn jemand anderes Ihre gemeinsam genutzte Netzwerkschnittstelle verwendet. Daher sollten Sie über eine größere Instanz nachdenken. Eine mittlere Instanz ($87,84 pro Monat) funktioniert recht gut, aber für maximale Vorhersagbarkeit und geringsten Jitter benötigen Sie eine extra große Instanz ($351,36 pro Monat), die Ihnen …“hohe Netzwerkleistung”Tatsächlich sollten es zwei sein ($703.52 pro Monat), um die Verfügbarkeit zu gewährleisten.

Da Sie Videos übertragen, müssen Sie natürlich auch die Bandbreitenkosten berücksichtigen. Die Basispreise für EC2 betragen $0,12 pro GB. Während Sie die Zahlen durchrechnen, fragen Sie sich vielleicht, was jemand anderen daran hindert, den gerade eingerichteten öffentlichen Server zu nutzen und Ihre Bandbreitenkosten in die Höhe zu treiben. Hier ist ein guter Mailinglistenthread Zum Thema: Zusammenfassend lässt sich sagen, dass es aufgrund der Funktionsweise des TURN-Protokolls und der Tatsache, dass die TURN-Zugangsdaten in Ihrem JavaScript-Code vorhanden sein müssen und somit für jeden zugänglich sind, keine optimale Möglichkeit gibt, dies zu verhindern.

Aber lassen wir die Kosten mal beiseite. Man kann jetzt Freunde bei anderen Tech-Firmen anrufen. Super! Dann versucht man, jemanden bei einem großen Konzern außerhalb der Tech-Branche anzurufen, und es klappt nicht. Mist! Man dachte, TURN hätte alles abgedeckt.

20 Minuten später, nach weiterer Recherche, stellen Sie fest, dass die TURN-Zuweisung in Chrome nur die Weiterleitung von UDP-Paketen unterstützt. Chrome 28 wird diese Unterstützung hinzufügen. Zuteilung Ein TURN-Server über TCP, aber die Pakete werden trotzdem über UDP weitergeleitet. Ups, das löst Ihr Problem leider noch nicht, wenn die Firewall den UDP-Verkehr blockiert. 

Stufe 3: vLine Cloud

Hier kommt unsere neue TCP-Tunneling-Unterstützung ins Spiel. Sie benötigt nicht die TURN-Implementierung von Chrome und funktioniert daher bereits jetzt in Chrome. Außerdem funktioniert sie selbst dann, wenn sich beide Parteien hinter Firewalls befinden, die UDP blockieren. Alles, was erforderlich ist, ist ein Internetzugang über Port 443 (den HTTPS-Port), den die allermeisten Firewalls zulassen.

Sie müssen nichts Besonderes tun, um TCP-Tunneling in Ihrem vLine-Dienst zu aktivieren. Verwenden Sie einfach vline.js zum Erstellen Ihrer Anwendung, und wir stellen die Verbindung über die jeweils beste verfügbare Methode her. Wir führen einen hochverfügbares globales Servernetzwerk, Wir bieten Ihren Nutzern weltweit die bestmögliche Gesprächsqualität, selbst hinter Firewalls, die ausschließlich TCP-Verkehr über den HTTPS-Port blockieren. Und falls Sie sich fragen: Ja, wir verwenden weiterhin Ende-zu-Ende-DTLS, sodass unsere Server Ihre unverschlüsselten Mediendatenströme niemals einsehen können.

Unser Ziel ist eine Verbindungsrate von 1001 TP41T. Falls in Ihrem Netzwerk keine Anrufe zustande kommen, wenden Sie sich bitte an uns. Lassen Sie es uns wissen.

Hinweis 1: Wenn Sie dies selbst testen möchten, indem Sie UDP auf Ihrer Firewall blockieren, denken Sie daran, den DNS-Port (53) offen zu lassen.

Hinweis 2: Einige sehr restriktive Firewalls, die eine zustandsbehaftete Paketprüfung durchführen, können Verbindungen weiterhin blockieren, da der Browser zwar den HTTPS-Port verwendet, aber tatsächlich kein SSL/TLS nutzt (wir sind zwar noch nie auf eine solche Firewall gestoßen, aber sie existieren). Chrome wird in Kürze WebRTC-Verbindungen über TLS unterstützen; ab diesem Zeitpunkt werden wir auch diese Firewalls umgehen können.

WebRTC + Chromebox = $400 HD Telepräsenzsystem

WebRTC Digest – Week of 5/27 – Flow Charts, FUD, and T-Shirts

Gute, detaillierte Erklärungen zu WebRTC sind nach wie vor selten. Glücklicherweise, Anant Narayanan von Firebase (und zuvor das WebRTC-Team bei Mozilla) hat letzte Woche mit seinem Vortrag „A Practical Introduction to WebRTC“ auf der Fluent Conference einen wichtigen Beitrag zum Präsentationspool geleistet.

Schauen Sie unbedingt mal vorbei die Folien Für die vollständigste Sammlung von WebRTC-Signalisierungsablaufdiagrammen im Web (verwenden Sie den Abwärtspfeil auf Folie 7Im Ernst: Wenn Sie verstehen wollen, was genau im Hintergrund passiert, wenn Sie in einer WebRTC-Anwendung auf “Anruf starten” klicken, müssen Sie sich die Ablaufdiagramme ansehen. Wir warten.

FUDdy-duddy

WebRTC war letzte Woche das Hauptthema bei No Jitter, es gab nicht weniger als drei Beiträge zu diesem Thema. Irwin Lazar Nemertes Research begann mit einem positiven Artikel mit dem Titel WebRTC: Warum ist das für Unternehmen relevant?

Noch spannender ist vielleicht die Möglichkeit, CRM- oder ERP-Anwendungen mit eigenen Sprach-/Videoanwendungen auszustatten, die direkt in ihre Web-Oberflächen integriert sind. […] Stellen Sie sich ein Team vor, das den ganzen Tag mit einer Geschäftsprozessanwendung arbeitet und miteinander chatten, sprechen oder per Videoanruf kommunizieren kann. […] Auch hier sind die Möglichkeiten für Anwendungsentwickler, umfassende Kommunikations- und Kollaborationsmöglichkeiten überall zu erweitern, schier unendlich.

Dann dämpfte Laurent Philonenko, Vizepräsident/Geschäftsführer der Clients and Mobility Business Unit von Cisco, die Begeisterung für WebRTC mit dem Artikel „Die Realität von WebRTC…Nur ein Hype?“.

[…] WebRTC ist noch nicht marktreif. Die Standards sind schlichtweg noch nicht fertiggestellt. Gehen wir davon aus, dass die WebRTC-Standards erst in einem Jahr finalisiert sein werden und Chrome und Firefox sechs Monate benötigen, um einen Browser mit den finalen Standards auszuliefern; hinzu kommt noch die Zeit für Browser-Updates. Erste Implementierungen wird es zwar schon vorher geben, aber ich schätze, es dauert noch mindestens zwei Jahre, bis diese Technologie weit verbreitet ist.

Dave Michels schloss mit einem WebRTC-Hype-Check ab und erklärte freundlich, dass es hier nichts zu sehen gäbe und man besser weitergehen solle.

WebRTC ist nicht disruptiv. […] WebRTC bietet weder neue Funktionen noch signifikante Kosteneinsparungen gegenüber anderen Peer-to-Peer-Technologien. WebRTC lässt sich treffender als evolutionäre Technologie beschreiben – es bringt Echtzeitfunktionen direkt in den Browser, anstatt auf Ad-hoc-Plugins und Downloads angewiesen zu sein.

Wir halten uns vorerst noch bedeckt, aber ihr könnt davon ausgehen, dass ihr hier im vLine-Blog bald mehr zu diesem Thema lesen werdet. In der Zwischenzeit arbeiten wir an der finalen Gestaltung unserer neuen “WebRTC Is Ready”-T-Shirt-Kollektion.

Ernsthaft. Schreib uns eine Nachricht Falls Sie eins möchten.

GitTogether: Video Chat for GitHub (powered by WebRTC)

Zusammenfassung

  1. Gehe zu gittogether und melde dich mit GitHub an.
  2. Sieh dir Personen an, denen du auf GitHub folgst, sowie Mitglieder deiner Teams und Organisationen als Kontakte.
  3. Wenn die Personen, mit denen Sie sprechen möchten, nicht online sind oder nicht in Ihrer Kontaktliste stehen, senden Sie ihnen Ihre GitTogether-URL (gittogether GitHub).
  4. Chattet drauf los!

Hintergrund

Man kann die Qualität einer Plattform erst beurteilen, wenn man damit eine echte App entwickelt hat, idealerweise eine, die man selbst täglich nutzt. Deshalb haben wir bei der Entwicklung der Plattform… vLine-Plattform Und da wir vor zwei Jahren eine API hatten, haben wir auch damit begonnen, eine App darauf aufzubauen.

Da sich unser Leben im Grunde um GitHub dreht, haben wir beschlossen, ein Kommunikationstool zu entwickeln, das das auch tut. Wir nannten es GitTogether, gaben ihm einen GitHub-Login und füllten die Kontaktliste mit den Personen, denen man auf GitHub folgt oder mit denen man zusammenarbeitet.

Heute verfügen wir über eine ausgereifte App, die wir seit über einem Jahr intern als primäres Kommunikationsmittel nutzen. Da unser Hauptziel darin bestand, aus den Erfahrungen bei der Entwicklung und Nutzung zu lernen, haben wir sie nie öffentlich geteilt. Doch mittlerweile haben genügend Nutzer sie entdeckt und als nützlich empfunden, sodass wir beschlossen haben, uns nun etwas mehr Zeit für die Kommunikation darüber zu nehmen.

In den nächsten Wochen veröffentlichen wir eine Reihe von Blogbeiträgen, die die Funktionsweise im Detail erläutern, unsere Erkenntnisse aus der Entwicklungsprozess schildern und zeigen, wie Sie Apps mit denselben Funktionen erstellen können. Bis dahin wünschen wir Ihnen viel Spaß!

WebRTC Digest – Week of 5/20 – Chrome 27, Temporal Scalability & Hardware Acceleration

Chrome 27

Chrome 27 war offiziell veröffentlicht. A Liste der WebRTC-bezogenen Änderungen ist auf der Mailingliste discuss-webrtc verfügbar. Eine der sichtbarsten Änderungen für Endnutzer ist die Möglichkeit, Kamera und Mikrofon auswählen Anstatt in den Chrome-Einstellungen zu suchen, kann man direkt über die “Omnibox” vorgehen.

Zeitliche Skalierbarkeit

Es gab ein interessante Diskussion Auf der Mailingliste wurde über zeitliche Skalierbarkeit diskutiert und darüber, ob entsprechende Steuerelemente in WebRTC über SDP zugänglich gemacht werden könnten, insbesondere für die Verwendung mit Konferenzen/Mixing. Zeitliche Skalierbarkeit ist eine Methode zur Kodierung eines Videostreams in einem Format, das die Dekodierung mit mehreren Bildraten (z. B. 30 FPS oder 15 FPS) ermöglicht, allerdings auf Kosten eines erhöhten Kodierungsaufwands. LifeSize-Blog bietet eine gute Beschreibung im Kontext des H264-Codecs, und die WebM-Mailingliste enthält eine detailliertere technische Beschreibung von wie es in VP8 funktioniert.

Hardwarebeschleunigung

Die Hardwarebeschleunigung für VP8 wird von immer mehr Plattformen unterstützt, wie nVidia mit dieser Tegra-4-Demo von 1080p-Videokonferenzen mit 30 FPS zeigt. Der Tegra 4 wird über integrierte Hardwareunterstützung für VP8-Codierung und -Decodierung verfügen, mit dem erklärten Ziel,

Wir bieten das beste WebRTC-Erlebnis auf Android, Chrome OS und Google TV.

WebRTC Digest – Week of 5/13 – BB10, Firefox 22 & Google IO

WebRTC auf Blackberry 10

Unsere Freunde bei Hookflash Die Woche begann mit der Ankündigung der Unterstützung von WebRTC auf Blackberry 10. Erik Lagerway schloss sich dem an. auf webrtc-discuss:

Ich wollte euch nur kurz mitteilen, dass wir die Portierung des gesamten WebRTC-Medienstacks von Google auf QNX/Blackberry 10 abgeschlossen haben. Er befindet sich aktuell in unserem Open Peer GitHub-Repository und wir planen, ihn wieder in den Hauptzweig aufzunehmen, sofern Google ihn akzeptiert.

WebRTC-Technikchef Justin Uberti begrüßte die Nachricht und legte die Grundregeln für beigesteuerte Ports fest:

Erik, danke für die Info. Es ist immer schön zu sehen, wenn jemand das WebRTC-Ökosystem erweitert!

Sofern die Portierung unseren Styleguides und unseren Vorgehensweisen für plattformspezifischen Code entspricht, können wir Sie dabei unterstützen. Allerdings können wir die Portierung nicht vollständig über unsere Testplattformen und Tests absichern. Sollte der Build fehlschlagen, müssen Sie das Problem selbst beheben.

Firefox 22 Hits Beta

Am Dienstag, Firefox 21 wurde veröffentlicht, Damit bleibt nur noch eine Version übrig, bevor WebRTC standardmäßig aktiviert ist. Firefox 22 soll voraussichtlich am [Datum einfügen] erscheinen. 24. Juni.Wer es eilig hat, kann eine Vorschau in der Firefox Beta-Version erhalten., Aurora, Oder, wenn Sie wirklich mutig sind, Nacht.

Jon Fingas schreibt für Engadget, enthält mehr Informationen zu Firefox 22:

Obwohl Mozilla sich schon lange für WebRTC für Video- und Sprachchats ohne Plugins einsetzt, war das Unternehmen bisher nicht bereit, das vollständige Protokoll standardmäßig in Firefox zu aktivieren. Seit dieser Woche ist man diesbezüglich jedoch zuversichtlicher…

Google IO

Justin Uberti und Sam Dutton schlossen die Woche mit einer Präsentation über WebRTC auf der Google I/O ab. Sowohl die Folien als auch die Video sind nun für Sie zum Ansehen verfügbar.

Janko Roetgers behandelten die Highlights der Sitzung für GigaOm:

WebRTC, die neue Technologie, die pluginfreie Sprach- und Videochats im Browser ermöglicht, soll laut Justin Uberti, dem technischen Leiter von Googles WebRTC-Entwicklung, “innerhalb einer Woche” auf mehr als einer Milliarde einzigartiger Endpunkte (z. B. Desktop-Browser und Mobilgeräte) verfügbar sein.

Endpunkte++

Zu guter Letzt hat Tsahi Levent-Levi einige Vorschläge für UC-Anbieter und -Kunden in unserem Lieblingsbeitrag der Woche:

Alle von Ihnen installierten Raumsysteme und Endgeräte sollten vollständig WebRTC-fähig sein – sie sollten einen HTML5-Browser ausführen und JavaScript die restliche Funktionalität bereitstellen. Nutzen Sie diese Bereitstellungsart auch für Ihre eigene Lösung. Für alle Ihre älteren Produkte benötigen Sie ein Gateway, um auf das System zugreifen zu können.

Dem stimme ich zu.

WebRTC Digest – Week of May 6

Hier im Hauptquartier von vLine haben wir eine interne Mailingliste, über die wir Links zu Artikeln, Mailinglistenbeiträgen, Code-Check-ins und anderen interessanten Informationen zum Thema WebRTC austauschen.

Jetzt, wo wir endlich einen Blog haben, dachten wir, es wäre nett, diese Links mit euch, liebe Leser (Hallo Mama!), zu teilen. Schaut also jeden Montag hier vorbei für eine neue, sorgfältig zusammengestellte Auswahl der WebRTC-News der letzten Woche (echt aktuell, oder?). Und ohne weitere Umschweife, hier ist unsere erste Ausgabe:

Explodierende Endpunkte und Spinnen

Kelly Teal fragt in einem Artikel für Channel Partners: „Was zum Teufel ist WebRTC?“ und befragt dazu einige Analysten.

Wenn es um Videokollaboration geht, spricht jeder über WebRTC. Doch was ist WebRTC und was bedeutet es für Partner?

 …

“WebRTC schafft das Potenzial für eine Explosion browserbasierter Video-Endpunkte, die sich nur mit anderen Endpunkten verbinden, die denselben Standard verwenden”, sagte Bill Haskins, Analyst bei Wainhouse Research, gegenüber Channel Partners.

Wir sind uns absolut einig, was die explosionsartige Zunahme browserbasierter Endpunkte betrifft. Genband, Sie widersprachen jedoch der Aussage, dass sie nur mit anderen Nutzern desselben Standards kommunizieren würden, indem sie SPiDR, ein neues Gateway für Legacy-Systeme zu WebRTC, ankündigten. Gary Audin berichtet in NoJitter darüber:

SPiDR befindet sich am Rand des Netzes des Betreibers. Es bietet offene, webzentrierte APIs, die es Anwendungsentwicklern ermöglichen, umfangreiche Kommunikationsdienste über das Netzwerk bereitzustellen, darunter Sprach-, Video-, Präsenz-, gemeinsames Adressbuch, Anrufliste, Instant Messaging und Kollaboration. 

Google IO 411

Googles jährliche Entwicklertreffen kommt Ende dieser Woche in die Stadt, und WebRTC Tech Lead Justin Uberti wird mit einer weiteren Session auf die Bühne zurückkehren, die mit Sicherheit bis auf den letzten Platz gefüllt sein wird, und zwar über unseren Lieblings-Echtzeit-Stack (falls Sie seine Session letztes Jahr verpasst haben, können Sie sich das Video hier ansehen).

Dieses Jahr wird er gemeinsam mit Chrome Developer Advocate präsentieren und HTML5 Rocks-Mitwirkender Sam Dutton. Die beiden werden außerdem ein praktisches Code-Labor leiten, um glücklichen Ticketinhabern dabei zu helfen, den Buchstabensalat der WebRTC-APIs und -Protokolle in ansprechende Webanwendungen zu übersetzen.

In diesem Codelab helfen wir Ihnen, die wichtigsten APIs und Technologien von WebRTC zu verstehen: – MediaStream (auch bekannt als getUserMedia): Was ist das und wie verwende ich es? – RTCPeerConnection: Was ist das Besondere an der leistungsstärksten API von WebRTC? – RTCDataChannel: Wie richte ich die Echtzeitkommunikation beliebiger Daten ein? – Signalisierung: Was ist das und wie richte ich sie ein? – Server: Was benötige ich für Signalisierung, STUN und TURN?

Vogelfutter

Apropos Leckerbissen: Justin stimmte sich für IO ein, indem er drei lang erwartete Köstlichkeiten präsentierte, die für … bestimmt waren. Chrome Canary auf discuss-webrtc Mailingliste. Am Mittwoch, er angedeutet dass zuverlässige Datenkanäle bald verfügbar sein werden (wenn Sie als Erster erfahren möchten, wann sie verfügbar sind, können Sie einen Stern setzen). Ausgabe 1493).

Und dann, am Freitag, hat er unsere Woche gerettet durch Ankündigung Sie können bald die getStats()-API nutzen, um herauszufinden, welche ICE-Kandidaten der Browser ausgewählt hat. Schluss mit tcpdump oder ausführlichen Protokollierungen, um zu ermitteln, ob Sie einen Relay-Server verwenden! Sind Sie genauso begeistert wie wir?

Und zu guter Letzt bestätigte er, dass Canary nun die Fähigkeit besitzt, die Last auf mehrere TURN-Server zu verteilen. Vollständiger Thread Hier.

Richard Mentor Johnson?

Zum Schluss noch ein paar interessante Details zum Thema Codecs. Matt Frost, Produktmanager von WebM und ehemaliger Interims-CEO von On2, postete Folgendes: VP9 steht kurz vor der Fertigstellung. Wir wissen nicht, worüber wir uns mehr freuen: die Unterstützung für Tiefenkanäle (3D-Webcams + Tiefenkarten + WebGL = ???) oder die Codec-Kriege zwischen VP9 und H.265.

Da es unwahrscheinlich erscheint, dass sich die Browserhersteller in diesem Jahrzehnt auf einen gemeinsamen, integrierten Codec einigen werden, wirkt Mozillas Vorstoß für einen reinen JavaScript-Codec immer vernünftiger. (Anknüpfend an Brendan Eichs Artikel) Heute habe ich die Zukunft gesehen In einem Beitrag über ORBX.js schrieb Peter Bright einen Schönes Stück für Ars Technica mit weiteren technischen Details:

Bei Browsern wie Internet Explorer 10 und Safari unter iOS wird ORBX ausschließlich im I-Frame-Modus verwendet. Andere Browser, darunter Firefox und Chrome, nutzen einen konventionelleren Mischmodus. Dieser Mischmodus benötigt WebGL für einen Teil der Dekodierung. I-Frames lassen sich vollständig in JavaScript kodieren, P-Frames hingegen erfordern aufgrund ihrer höheren Komplexität Shader-Programme. Da Internet Explorer 10 und Safari unter iOS WebGL nicht unterstützen, können keine Shader-Programme ausgeführt werden. Folglich benötigen sie für dieselbe Videoqualität etwa doppelt so viel Bandbreite.

Leider gibt es noch keine öffentliche Demo. Aber wir können es kaum erwarten, es auf unseren iPhone 12s auszuprobieren.

Free vLine/WebRTC Consulting and Training

Eine unserer wichtigsten Prioritäten ist es, den Einstieg in WebRTC und die vLine-Plattform so einfach wie möglich zu gestalten. Daher bieten wir fünf kostenlose ganztägige Beratungs- und Schulungssitzungen für Entwickler an, die an Projekten mit WebRTC und vLine arbeiten, die bis zum 30. Juni live gehen.

Für Entwickler in den kontinentalen USA kommen wir in Ihr Büro, setzen uns neben Sie und tun alles, um Ihr Projekt zum Erfolg zu führen. Für Entwickler in anderen Teilen der Welt bieten wir die gleiche Unterstützung per Videochat und Bildschirmfreigabe an.

Bei Interesse senden Sie bitte eine E-Mail an [email protected] Erzählen Sie uns, was Sie entwickeln und wie Sie die Beratungszeit nutzen würden.

Am 10. Mai werden wir die Anträge prüfen und die fünf Entwickler auswählen. Projekte, für die bereits Entwicklungsressourcen bereitgestellt wurden und die in Kürze starten, werden bevorzugt.

Wir freuen uns darauf, von Ihnen zu hören!

vLine Just Got Easier

Wir freuen uns, einen wichtigen Meilenstein für die vLine-Plattform bekanntzugeben: Sie können jetzt in etwa einer Minute einen Video-Chat-Dienst unter Ihrer eigenen Marke erstellen, ohne eine einzige Zeile Code schreiben zu müssen.

Um Ihnen den nächsten Schritt und die Integration in Ihre Website noch einfacher zu machen, verlosen wir fünf kostenlose, ganztägige Beratungs- und Schulungssitzungen vor Ort für qualifizierte Projekte (alle Details siehe unten). Hier).

Um Ihren Video-Chat-Dienst zu erstellen, gehen Sie zu vline.com Klicken Sie auf den großen Button ‘Los geht’s’. Oder sehen Sie sich dieses Video an, um zu erfahren, wie es funktioniert: