На него има най-малко две причини:

1. Тъй като броят на зрителите излъчва Ethernet-голям недостиг ще се усети първо дебелина канал, а след това на ресурсите на самата камера.

За да започнете да posnifaem IP камера, за да видим какво това устройство изпраща към страна на браузъра. Като експериментална камера е D-Link DCS 7010L:

Снимката се отваря във всички браузъри и равномерно podlagivaet, веднъж на секунда. Като се има предвид, че и камерата и лаптопа, на който ние виждаме поток свързани към същата рутера, той трябва да е гладка и красива, но това не е така. Подобно на HTTP. Изпълнете Wireshark, за да потвърдите своите предположения:

Тук ние виждаме поредица от TCP фрагменти от 1514 байта дължина

и попълване на HTTP 200 ОК с дълъг прие JPEG:

След това отидете на Chrome / Developer Tools / Network, и да видим в реално време как да мига искане за GET и изображения предава по HTTP:

Такава стрийминг ние не се нуждаем. Не е гладък, дърпа искания HTTP. Колко заявки в секунда камерата стои? Има основание да се смята, че 10-те зрители пред камерата започва да безопасно огънат или страх да се провали и да произвежда пързалки.

Ако се вгледате в HTML страница администратор камерата, което виждаме тук интересен код:

Тук можем да споменем още един Flash Player, който може да бъде на подходящ тип Wowza сървъра получи RTMP поток от преобразуваната RTSP, RTP, H.264. Въпреки това, Flash Player, тъй като е известно, също браузър плъг-ин, въпреки че много по-популярен от VLC или QuickTime.

В този случай, ние ще тества по същия RTSP / RTP повторно стрийминг, а като игра устройство ще се използва от WebRTC-съвместим браузър без никакви допълнителни плъгини на браузъра, както и други патерици. Ние ще конфигурира релето на сървъра, който ще отнеме от потока на мрежова камера и да го дам на произволен брой интернет потребители, използващи браузъри с поддръжка на WebRTC.

Свързване на IP-камера

Създаване на фотоапарата

На първо място, в камерата настройки са удостоверяване с увреждания - като част от изследването ще даде поток към всички, които питате. За да направите това в уеб интерфейса на камерата отиде в Настройка - мрежа и задайте стойността на опцията за удостоверяване да деактивирате.

Между другото, на потока на играта съвсем гладко и без артефакти. Очакваме същото и от WebRTC.

Инсталиране на сървър

Ковани подходящите настройки на рутера ...

телнет 178.51.142.223 554

Уверете се, че този порт е отговорът, продължете да инсталирате WebRTC на сървъра.

Хостинг ще бъде отговорна за виртуалния сървър на Цент малко 64 на Amazon EC2.
Не да има проблеми с производителността, за да изберете един от случаите m3.medium VCPU:

Да, да, все още е налице Linode и DigitalOcean, но в този случай исках да poamazonit.
Гледайки напред, ще го напиша на Amazon EC2 контролния панел, трябва да добавите някои правила (Port Forwarding), без които няма да работи. Той пристанища WebRTC (SRTP, RTCP, ICE) трафик и пристанища за RTSP / RTP трафик. Ако ще да се опита, в правилата на Amazon трябва да бъде нещо подобно за входящ трафик:

Както сървърния софтуер, реле RTSP / RTP поток в WebRTC ще използвате WebRTC Media # 038; Излъчване на сървър от Flashphoner. Streaming сървър е много подобен на Wowza. който е в състояние да даде RTSP / RTP поток в Flash. Единствената разлика е, че този поток ще бъде даден на WebRTC, отколкото Flash. Т.е. между браузъра и сървъра ще се честен DTLS, SRTP сесия е установен и потока кодирана в VP8 ще публиката.

При монтажа се нуждаем SSH достъп.

Под спойлер - подробно описание на извършените команди

Идеята е, че вместо да параграф 10, че би било разумно да се поиска всички необходими портове и правилата на защитната стена, но за тестови цели, реши просто да изключите защитната стена.

Създаване на сървъра

Спомнете си, че в структурата на нашата WebRTC превод е както следва:

Монтаж на основните елементи на тази схема, ние вече направи, е необходимо да се установи "стрели" взаимодействия.

Връзката между браузъра и сървъра WebRTC осигурява уеб-клиент, който е на githabe. Задайте JS, CSS, HTML и файлове просто хвърля в / Var / WWW / HTML за фазата на монтаж (вж. Над точка 9 при спойлер).

Създаване на сървъра свършва тук, можете да проверите работата си:

Отворете страницата index.html уеб-клиент в браузъра (за тази цел на една и съща Amazon сървърът е инсталиран Apache команда Yum -Y инсталира уеб-):

И DDNS подкрепа в рутера изглежда:

Вече сте готови да тестват и оценка на резултатите.

тестване

По това време, се установи връзка с vebsoketam сървърния браузър, тогава сървъра поиска IP камера на RTSP, H.264 приема поток RTP и го прекодира в VP8 / SRTP - което в крайна сметка играе WebRTC- браузър.

На следващо място, след кратко изчакване, показва познатата картина.

Ние се уверете, че това е наистина WebRTC.

По това време, той не трепти и не виждате никакви изображения, предавани по HTTP. Всичко, което виждаме в този момент - това WebSocket рамки, и повечето от тях принадлежат на пинг / понг видове да се поддържа WebSocket сесия. Интересни рамки: свързване, prepareRtspSession и onReadyToPlay - в този ред се инсталират, за да се свържете със сървъра: първата връзка на WebSocket, а след това се стичат искане репродукция.

Но това показва Chrome: // WebRTC-Вътрешни

Според показанията на графики, ние имаме битова скорост 1Mbps на IP камерата. Изходящ трафик също най-вероятно ще го RTCP пакети и лед. RTT до сървъра Amazon е на около 300 милисекунди.

Следващият тест - връзката на други зрители. не може да се отвори Chrome прозорци 10, и всеки от тях показва снимка. В същото време той започва да Chrome малко тъп. Когато откриването на 11-ти прозорец на друг компютър, възпроизвеждане е гладка.

За WebRTC мобилен

Както е известно, WebRTC подкрепят браузъри Chrome и Firefox на платформата Android.
Проверяваме ще има да се покаже нашето предаване:

заключение

В резултат на това ние бяхме в състояние да управлява WebRTC онлайн излъчване с мрежова камера за няколко браузъра с минимални усилия. Това не отнема никакви танци с дайре, без ракета-наука - само основни познания за Linux и SSH-конзола.

Излъчване на качеството е на приемливо ниво, както и забавянето на възпроизвеждане е незабележимо за окото.

Защо не виждаме широкото въвеждане WebRTC?

Основната спирачка е може би липсата на кодеци. WebRTC общност и продавачите трябва да направят усилие и вложени в H.264 кодек WebRTC. Срещу VP8 няма какво да се каже, но защо се откаже от милиони съвместими устройства и софтуер, които работят с H.264? Патентите са патенти ...

На второ място, не се поддържа напълно браузъри. С IE и Safari, например, въпросът остава отворен, и там ще трябва да се премине към друг тип стрийминг или използвайте щепсел тип webrtc4all а.

Така, че в бъдеще, ние се надяваме да се види по-интересни решения, които не се нуждаят от преобразуване и транскодиране потоци и повечето браузъри може otygrivat потоци от няколко устройства вече директно.