Когда начинаешь стриминг тестировать, не знаешь сразу, что там вылезет. Бывает надо ассемблерную оптимизацию снять (yasm) или флаг добавить, если что-то пошло не так. Или последнюю ревизию собрать, потому что только в ней есть такая-то фича. Потому, только заклинания, только хардкор.
Нет, в статье речь не идет про scalable video, если вы про SVC. Насколько нам известно, WebRTC в данный момент не поддерживает SVC, по крайней мере для кодека H.264.
Ну и SVC имеет слабое отношение к записи стримов и воспроизведению VOD в данном контексте.
WebRTC обычно еще преполагаеться SDP — Session Description protocol, в котором и можно указать какие потоки клиент готов принимать
Да, в SDP, разумеется указываются потоки. В нашем случае указывается 1 видео поток.
если клиент сообщяет что готов к 2м потокам, как в вашем случае
Нет. В нашем случае клиент принимает 1 видеопоток. На графике разрешений показаны высота и ширина этого одного потока во время записи.
подрозумеваеться
что клиент будет скейлить на весь экран сам, если сервер решит переслать меньшую резолюцию
Да, клиент будет скейлить, то, что ему прислали.
Или же клиент сообщает что готов принимать только одну, в вашем случае 640х480, то сервер пришлет только ее!
А вот не факт. В WebRTC, Sender динамически меняет разрешение потока, основываясь на RTCP фидбеках. См. график. Сначала разрешение, при стриминге с iOS приложения, было 640x480, потом упало до 320x240.
Scalable Video родилось что бы сэкономить транскодинг на сервере
Это так, но не актуально для данного конкретного случая.
function several_lines_of_js_code_to_make_a_call(){
var sipOptions = {
login: "10001",
authenticationName: "10001",
password: "12345",
domain: "192.168.1.3",
outboundProxy: "192.168.1.3",
port: "5060",
registerRequired: false
};
var connectionOptions = {
urlServer: "wss://wcs5-eu.flashphoner.com:8443",
sipOptions: sipOptions
};
Flashphoner.createSession(connectionOptions).on(Flashphoner.constants.SESSION_STATUS.ESTABLISHED, function (session) {
session.createCall({callee: number}).call();
})
}
Вот так вполне похоже на несколько строк JS — кода. Полные листинги с комментариями приведены для законченности примера. Чтобы не только позвонить можно было, но и сбросить звонок, и статусы показать.
Что касается зависимостей, без них не обойтись. Да. Мало чего можно сделать на JavaScript без зависимостей. Обычно подразумевается, что есть какое-то API, библиотека.
Что касается заголовка, это всего лишь заголовок. Если бы заголовок был «Как дрессировать котят», то да, пожалуй вводил бы кого-то в заблуждение.
WebRTC по нагрузке в любом случае будет выше чем по Websockets. Дело в том, что там не просто льется видео, а работает много сервисов поверх потока, таких как RTCP feedback, ICE, шифрование. А основное отличие в том, что WebRTC идет по UDP с динамическим битрейтом и контролем сети и задержек, а Websockets идет по TCP и как получится. Т.е. если важно снизить нагрузку на сервер и некритична задержка, лучше использовать Websockets, если конечно получается его нормально отобразить на стороне браузера.
На сегодняшний день технология WebRTC сырая, как мокрые плавки.
Лет 5 назад это было так. А сегодня технология уже достаточно зрелая и работает в продакшенах. При этом P2P технология не ограничивается, можно и VOD по WebRTC раздавать при желании. И кстати да, проблемы с подключением P2P — обратная сторона децентрализации. При подключении напрямую к серверу таких проблем не возникает. Подключение проходит быстро. Все потому, что не нужно долго сканировать сеть в поисках пригодных внешних IP для приема трафика.
Ок. Node.js может работать с native кодом и биндить порты в частности. PHP или JSP тоже умеют работать с C-кодом, но это не означает автоматической поддержки WebRTC. Есть реализация Node.js+Websockets. Там можно сделать похожий сигналинг между браузерами, но это уже P2P — немного другое, там стрим будет кодироваться отдельно для каждого зрителя, и браузер-транслятор скоро повиснет.
Расчеты некорректны. Ежемесячная подписка стоит 75 usd. В месяце в среднем 720 часов, т.е. 43200 минут. Получается 0.17 центов в минуту. Тогда правильно писать так:
На браузерах флэш, можно сказать, умер. В Android Chrome его нет, в Mac Safari выключен, в Edge выключен.
Играть Live-видео можно этим:
Нет, в статье речь не идет про scalable video, если вы про SVC. Насколько нам известно, WebRTC в данный момент не поддерживает SVC, по крайней мере для кодека H.264.
Ну и SVC имеет слабое отношение к записи стримов и воспроизведению VOD в данном контексте.
Да, в SDP, разумеется указываются потоки. В нашем случае указывается 1 видео поток.
Нет. В нашем случае клиент принимает 1 видеопоток. На графике разрешений показаны высота и ширина этого одного потока во время записи.
Да, клиент будет скейлить, то, что ему прислали.
А вот не факт. В WebRTC, Sender динамически меняет разрешение потока, основываясь на RTCP фидбеках. См. график. Сначала разрешение, при стриминге с iOS приложения, было 640x480, потом упало до 320x240.
Это так, но не актуально для данного конкретного случая.
Big Buck Bunny
Как обычно, потому что снапшоты надо было еще вчера. А под рукой уже были инструменты для сжатия в PNG.
А по хорошему, да. Придется и JPEG превью сделать.
Вот так вполне похоже на несколько строк JS — кода. Полные листинги с комментариями приведены для законченности примера. Чтобы не только позвонить можно было, но и сбросить звонок, и статусы показать.
Что касается зависимостей, без них не обойтись. Да. Мало чего можно сделать на JavaScript без зависимостей. Обычно подразумевается, что есть какое-то API, библиотека.
Что касается заголовка, это всего лишь заголовок. Если бы заголовок был «Как дрессировать котят», то да, пожалуй вводил бы кого-то в заблуждение.
Но камера там конечно странная Azurewave. Не похожа на обычную вебкамеру.
Спасибо за то, что уделили время и провели тест.
Да. iOS просто не влез в статью. В следующей попробуем расписать видеочат на троих: Android, iOS и Web.
Лет 5 назад это было так. А сегодня технология уже достаточно зрелая и работает в продакшенах. При этом P2P технология не ограничивается, можно и VOD по WebRTC раздавать при желании. И кстати да, проблемы с подключением P2P — обратная сторона децентрализации. При подключении напрямую к серверу таких проблем не возникает. Подключение проходит быстро. Все потому, что не нужно долго сканировать сеть в поисках пригодных внешних IP для приема трафика.
За 3 минуты и 0.51 цента.
или так
За 3 минуты и 30 копеек.