На це є як мінімум дві причини:
1. У міру збільшення числа глядачів Ethernet-трансляції все більше буде відчуватися спершу брак товщини каналу, а потім і ресурсів самої камери.
Для початку посніфаем IP камеру щоб дізнатися що саме відправляє цей девайс в сторону браузера. В якості піддослідного буде камера D-Link DCS 7010L:
Картинка відкривається у всіх браузерах і рівномірно подлагівает, приблизно раз в секунду. З огляду на що і камера і лептоп, на якому ми дивимося потік підключені до одного маршрутизатора, все повинно бути плавно і красиво, але це не так. Схоже на HTTP. Запускаємо Wireshark щоб підтвердити свої здогадки:
Тут бачимо послідовність TCP фрагментів довжиною 1514 байт
і завершальний HTTP 200 OK з довгою прийнятого JPEG:
Далі заходимо в Chrome / Developer Tools / Network і бачимо в реальному часі як миготять GET Запити і картинки, передані по HTTP:
Такий стрімінг нам не потрібен. Чи не плавний, смикає HTTP запити. Скільки таких запитів в секунду витримає камера? Є підстави вважати що на 10 глядачах і раніше камера благополучно загнеться або почне страшно глючить і видавати слайди.
Якщо заглянути в HTML сторінки адмінки камери, побачимо ось такий цікавий код:
Тут можна згадати ще Flash Player, який може через відповідний сервер типу Wowza отримувати RTMP потік, сконвертовані з RTSP, RTP, H.264. Але Flash Player, як відомо теж браузерні плагін, хоча незрівнянно більш популярний ніж VLC або QuickTime.
В даному випадку, ми протестуємо той же RTSP / RTP re-streaming, але в якості програє пристрою буде використовуватися WebRTC-сумісний браузер без всяких додаткових браузерних плагінів і інших милиць. Ми налаштуємо сервер-ретранслятор, який забере потік у IP-камери і віддасть його в Інтернет довільному числу користувачів, що використовують браузери з підтримкою WebRTC.
Підключення IP-камери
Налаштування камери
Спочатку в настройках камери ми відключаємо аутентифікацію - в рамках тестування будемо віддавати потік всім, хто попросить. Для цього в веб-інтерфейсі камери заходимо в налаштування Setup - Network і виставляємо значення опції Authentication в Disable.
До речі, потік відтворюється досить плавно і без артефактів. Чекаємо того ж і від WebRTC.
установка сервера
Забиваємо відповідні налаштування в маршрутизатор ...
telnet 178.51.142.223 554
Переконавшись, що з даного порту йде відповідь, приступаємо до установки WebRTC сервера.
За хостинг буде відповідати віртуальний сервер на Centos 64 bit на Amazon EC2.
Щоб не мати проблем з продуктивністю, вибрали m3.medium інстанси з одним VCPU:
Так, так, є ще Linode і DigitalOcean, але в даному випадку захотілося поамазоніть.
Забігаючи вперед, напишу що в панелі управління Amazon EC2 потрібно додати кілька правил (прокинути порти), без яких приклад не буде працювати. Це порти для WebRTC (SRTP, RTCP, ICE) трафіку і порти для RTSP / RTP трафіку. Якщо будете пробувати, в правилах Amazon має бути щось схоже для вхідного трафіку:
Як серверного ПО, ретранслює RTSP / RTP потік в WebRTC будемо використовувати WebRTC Media # 038; Broadcasting Server від Flashphoner. Стрімінг сервер дуже схожий на Wowza. яка вміє віддавати RTSP / RTP потік на Flash. Єдина відмінність в тому, що цей потік буде відданий на WebRTC, а не на Flash. Тобто між браузером і сервером пройде чесний DTLS, встановиться SRTP сесія і потік, закодований в VP8 піде глядачеві.
Для установки нам буде потрібно SSH-доступ.
Під спойлером - детальний опис виконаних команд
За ідеєю, замість пункту 10 правильно було б поставити всі необхідні порти і правила firewall, але для цілей тестування вирішили просто відключити брендмауер.
Налаштування сервера
Нагадаємо, що структура нашої WebRTC трансляції така:
Установку основних елементів цієї діаграми ми вже зробили, залишилося налагодити «стрілочки» взаємодій.
Зв'язок між браузером і WebRTC сервером забезпечує web-клієнт, який є на гітхабе. Набір JS, CSS і HTML файлів просто закидається в / var / www / html на етапі установки (див. Вище під спойлером пункт 9).
Налаштування сервера на цьому закінчується, можна перевірити його роботу:
Відкриваємо сторінку web-клієнта index.html в браузері (для цього на той же сервер Амазон був встановлений апач командою yum -y install httpd):
А так підтримка DDNS виглядає в самому роутері:
Тепер можна приступити до тестування і оцінити результати.
тестування
У цей час встановлюється з'єднання браузера з сервером по вебсокетам, далі сервер запитує IP камеру по RTSP, отримує потік H.264 по RTP і транскодірует його в VP8 / SRTP - який в підсумку відтворює WebRTC- браузер.
Далі після невеликого очікування, відображається вже знайома картинка.
Переконуємося що це дійсно WebRTC.
На цей раз нічого не мелькає і не видно ніяких картинок, що передаються по HTTP. Все що ми бачимо на цей раз - це Websocket фрейми і більшість з них відносяться до типів ping / pong для підтримки Websocket-сесії. Цікаві фрейми: connect, prepareRtspSession і onReadyToPlay - саме в такому порядку здійснюється установка з'єднання з сервером: спочатку коннект по Websocket, а потім запит потоку на відтворення.
А ось що показує chrome: // webrtc-internals
За свідченнями графіків, ми маємо бітрейт з IP камери 1Mbps. Вихідний трафік теж є, швидше за все це RTCP і ICE пакети. RTT до Amazon сервера становить близько 300 мілісекунд.
Наступний тест - підключення інших глядачів. Вдалося відкрити 10 вікон Chrome, і кожне з них показувало картинку. При цьому сам Chrome почав трохи тупити. При відкритті 11-го вікна на іншому комп'ютері, відтворення залишалося плавним.
Про WebRTC на мобільних пристроях
Як відомо, WebRTC підтримують Chrome і Firefox браузери на платформі Android.
Перевіримо, чи буде там відображатися наша трансляція:
висновок
В результаті нам вдалося запустити WebRTC онлайн-трансляцію з IP-камери на кілька браузерів з мінімальними зусиллями. Чи не треба було ні танців з бубном, ні rocket-science - тільки базові знання Linux і SSH-консолі.
Якість трансляції було на прийнятному рівні, а затримка відтворення була непомітна на око.
Чому ж ми не бачимо повсюдного впровадження WebRTC?
Головне гальмо, мабуть, недолік кодеків. WebRTC спільноті і вендорам варто було б зробити зусилля і ввести в WebRTC кодек H.264. Проти VP8 сказати нічого, але навіщо відмовлятися від мільйонів сумісних девайсів і ПО, які працюють з H.264? Патенти, такі патенти ...
На другому місці, не повна підтримка в браузерах. C IE і Safari, наприклад питання залишається відкритим і там доведеться переходити на інший тип стрімінга або використовувати плагін типу webrtc4all.
Так що в майбутньому, сподіваємося побачити більш цікаві рішення, в яких не потрібен буде транскодинг і конвертація потоків і більшість браузерів зможуть отигрівать потоки з різних пристроїв вже безпосередньо.