Există cel puțin două motive pentru aceasta:
1. Pe măsură ce crește numărul spectatorilor difuzării Ethernet, lipsa grosimii canalului, și apoi resursele camerei în sine, vor fi simțite din ce în ce mai mult.
În primul rând, vom capta camera IP pentru a afla ce trimite exact acest dispozitiv la browser. Ca test, camera D-Link DCS 7010L va fi:
Imaginea se deschide în toate browserele și se rotește uniform, cam o dată pe secundă. Considerând că atât camera cât și laptopul pe care privim fluxul sunt conectate la un router, totul ar trebui să fie neted și frumos, dar nu este. Se pare ca HTTP. Lansăm Wireshark pentru a confirma presupunerile noastre:
Aici vedem secvența de fragmente TCP cu o lungime de 1514 octeți
și HTTP final 200 OK cu cel mai lung JPEG primit:
Apoi mergeți la Chrome / Developer Tools / Network și vedeți în timp real modul în care GET intermitent Interogări și imagini transmise prin HTTP:
Nu avem nevoie de această streaming. Nu este netedă, ci deranjează cererile HTTP. Câte astfel de solicitări pe secundă va supraviețui camerei? Există motive să credem că pe 10 spectatori și înainte ca aparatul foto să se îndoaie în siguranță sau să înceapă să se bâlbâie teribil și să dea diapozitive.
Dacă vă uitați în paginile HTML din zona de administrare a camerei, vom vedea aici un cod interesant:
Aici puteți menționa și Flash Player, care, printr-un server de tip Wowza potrivit, poate primi un flux RTMP, convertit din RTSP, RTP, H.264. Dar Flash Player este, de asemenea, cunoscut ca un plug-in de browser, deși incomparabil mai popular decât VLC sau QuickTime.
În acest caz, vom testa aceeași raportare RTSP / RTP, dar ca dispozitiv de redare vom folosi un browser compatibil WebRTC fără alte plug-inuri de browser și alte cârje. Vom configura un server de transmitere care va prelua fluxul de la camera IP și îl va da la Internet unui număr arbitrar de utilizatori folosind browsere care suportă WebRTC.
Conectarea camerei IP
Setarea camerei
Mai întâi, în setările camerei, dezactivăm autentificarea - în cadrul testelor vom da fluxul tuturor celor care solicită. Pentru aceasta, mergeți la setările Setare - Rețea din interfața web a camerei și setați valoarea opțiunii Autentificare la Dezactivare.
Apropo, fluxul este reprodus destul de lin și fără artefacte. Asteptam la fel din WebRTC.
Instalarea serverului
Am ciocanit setările corespunzătoare în router ...
telnet 178.51.142.223 554
După ce verificăm că acest port răspunde, continuăm să instalăm serverul WebRTC.
Pentru găzduire va fi responsabil pentru un server virtual pe Centos 64 biți pe Amazon EC2.
Pentru a nu avea probleme de performanță, am ales instanța m3.medium cu un VCPU:
Da, da, există încă Linode și DigitalOcean, dar în acest caz, am vrut să păstrez pamazonit.
Privind înainte, o voi scrie în panoul de control Amazon EC2, trebuie să adăugați mai multe reguli (aruncă porturi), fără de care exemplul nu va funcționa. Aceste porturi sunt pentru traficul WebRTC (SRTP, RTCP, ICE) și porturile pentru traficul RTSP / RTP. Dacă încercați, regulile Amazonului ar trebui să aibă ceva similar cu traficul de intrare:
Ca software de tip server care transmite releul RTSP / RTP către WebRTC, vom folosi WebRTC Media # 038; Broadcasting Server de la Flashphoner. Serverul de streaming este foarte asemănător cu Wowza. care poate furniza fluxul RTSP / RTP la Flash. Singura diferență este că acest thread va fi dat WebRTC, nu Flash. Ie între browser și server va trece un DTLS onest, o sesiune SRTP va fi stabilită și fluxul codat în VP8 va merge la vizualizator.
Pentru a instala, avem nevoie de acces SSH.
Sub spoiler - descrierea detaliată a comenzilor executate
Teoretic, în loc de punctul 10, ar fi corect să specificăm toate porturile necesare și regulile de firewall, dar pentru scopuri de testare am decis să dezactivați paravanul de protecție.
Configurarea serverului
Reamintim că structura traducerii WebRTC este următoarea:
Am stabilit deja elementele de bază ale acestei diagrame, rămâne să stabilim "săgețile" interacțiunilor.
Conexiunea dintre browser și serverul WebRTC este furnizată de clientul web, care este pe githaba. Un set de fișiere JS, CSS și HTML este pur și simplu aruncat în / var / www / html în timpul fazei de instalare (vezi mai sus sub elementul spoiler 9).
Configurația serverului se termină aici, puteți testa funcționarea acestuia:
Deschideți pagina index.html a clientului web în browser (pentru aceasta apache a fost instalat pe același server Amazon cu comanda yum -y install httpd):
Și astfel suportul DDNS arată ca și router-ul în sine:
Acum puteți începe testarea și evaluarea rezultatelor.
testarea
În acest moment, browserul este conectat la server prin webcaste, apoi serverul solicită camera IP prin RTSP, primește fluxul H.264 peste RTP și îl codifică în VP8 / SRTP - care reda în cele din urmă browserul WebRTC.
După o scurtă așteptare, este afișată o imagine familiară.
Suntem convinși că acest lucru este într-adevăr un WebRTC.
De data aceasta nu clipește nimic și nu poți vedea imagini transmise prin HTTP. Tot ceea ce vedem de data aceasta este frame-urile Websocket și majoritatea sunt tipuri de ping / pong pentru menținerea unei sesiuni Websocket. Rame interesante: conectați, prepareRtspSession și onReadyToPlay - în această ordine este stabilită conexiunea la server: mai întâi o conexiune prin Websocket și apoi o solicitare de fir pentru redare.
Și asta arată cromul: // webrtc-internals
Conform graficelor, avem un bitrate de la camera IP 1Mbps. Traficul de ieșire este și acolo, cel mai probabil este pachetele RTCP și ICE. RTT la serverul Amazon este de aproximativ 300 de milisecunde.
Următorul test este conectarea altor spectatori. Am reușit să deschid 10 ferestre Chrome și fiecare dintre ele a arătat o imagine. În acest caz, Chrome a început să se îndoaie puțin. Când deschideți fereastra 11 pe un alt computer, redarea a rămas netedă.
Despre WebRTC pe dispozitivele mobile
După cum știți, WebRTC acceptă browserele Chrome și Firefox pe platforma Android.
Să verificăm dacă traducerea noastră va fi afișată acolo:
concluzie
Ca rezultat, am reușit să lansăm traducerea online WebRTC de la camera IP la mai multe browsere, cu un efort minim. Nu a luat nici un dans cu o tamburină, nici știința rachetelor - doar cunoștințe de bază despre consolele Linux și SSH.
Calitatea difuzării a fost la un nivel acceptabil, iar întârzierea redării a fost imperceptibilă de ochi.
De ce nu vedem introducerea pe scară largă a WebRTC?
Principala frână, poate, este lipsa codecurilor. Comunitatea WebRTC și furnizorii ar trebui să depună eforturi și să introducă codecul H.264 în WebRTC. Împotriva VP8, nu este nimic de spus, dar de ce să renunțe la milioane de dispozitive compatibile și software care funcționează cu H.264? Brevete, astfel de brevete ...
În al doilea rând, nu suport complet în browsere. C IE și Safari, de exemplu, întrebarea rămâne deschisă și acolo va fi necesar să treceți la un alt tip de streaming sau să utilizați un plugin de tip webrtc4all.
Așadar, în viitor, sperăm să vedem soluții mai interesante care nu necesită transcodare și streaming și majoritatea browserelor vor putea să transmită direct fluxuri de la diferite dispozitive.