А как у нас нонче с webRTC?

Кстати, сейчас вот гоняю тест на текучесть: в отличие от mjpeg'ов, вызывающих утечку памяти (не умеют браузеры мусор подчищать нормально), видео через вебсокеты прелестно работает. Средний поток 1МБ/с, начал в 11:46, было:

 2702 eddy      20   0 1563m 699m  50m R  10.3 38.0   5:42.54 firefox 

 2702 eddy      20   0 1607m 658m  49m S  19.3 35.8   7:19.00 firefox

Но 200%, это, конечно, ржака:

 5016 eddy      20   0 98244 2412 1596 R 200.0  0.1  22:06.93 websocktest 

Вебсокеты не нужны. Крайне вредное изобретение костылестроителей

http://www.webrtc.org/native-code/native-apis

Да что ты говоришь!

У меня система управления железкой отлично через вебсокеты рулится и педалируется! Как только сделаю более-менее похожее на бета-релиз, выложу на гитхабе и сосфорже.

А других вариантов реального асинхронного взаимодействия клиента и сервера не существует! Не засыпать же сервер 10-20 XHR в секунду!!!

Спасибо! Вот еще что нарыл. Буду изучать.

Да уж, документации с гулькин нос. А еще оно на плюсах, т.е. придется обертку делать (но это еще полбеды).

Не могу примеров найти готовых, чтобы /dev/video0 стримить.

могу рассказать, как транслировать через ffmpeg до сервера с последующей раздачей клиентам через веб-сокеты без звука. скорость сносная - с тухлой вебки через домру до амазона и обратно задержка меньше секунды, сколько кадров в секунду не знаю, может как раз 7 и есть.

Если ты про кодирование в base64, то я так уже почти закончил

в теории, если я правильно понимаю суть webrtc, если ты запилишь в какой-нибудь стриминг-сервер, где уже есть rtsp, поддержку dtls и vp8, то тебе останется только запихать sdp-описание нужного потока в webrtc-клиент в браузере.

Такое впечатление, что мне по-китайски что-то сказали...

Это чересчур дофига для такой простой задачи. По-хорошему, я вообще хотел микроконтроллер для этой задачи использовать. Но, учитывая то, что "малинка" дешевле, почему бы не взять ее? Тем паче, там полноценный линукс и не надо самому веб-сервер писать. Сильно много времени сохраняется.

Не знаю, есть ли там кодирование в base64, но я про эту инструкцию: http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets

Локальный ретранслятор через ffmpeg (комп из одной локалки с ip-камерой, с /dev/video думаю будет еще лучше):

ffmpeg -f mjpeg -i http://admin:xxx@192.168.1.10/video.cgi?resolution=640x480 -f mpeg1video http://yyyy.zz:8082/robotled/640/480/

шлет поток на сервер, где его уже принимает сервачок на node.js (исходники: https://github.com/phoboslab/jsmpeg) и перенаправляет в веб-сокет, который раздаёт поток в html-странички (см по ссылке). Всё работает, задержка доля секунды.

мои мучения с vlc: Потоковое видео из локалки в интернет через промежуточный сервер (комментарий)

Там еще хуже: декодирование mpeg'ов средствами жабоскрипта.

Сомневаюсь, что получится быстрей, чем base64 на jpeg'и. В такой горе жабоскрипта мне совершенно неохота разбираться. Хотя, конечно, проверять надо.

И ffmpeg мне уж точно не нужен: мне надо видео обработать перед тем, как отсылать!

node.js

Ни в коем разе! Еще мне жабоскрипта на сервере не хватало. Только сишный демон или CGI.

Всё работает, задержка доля секунды

А какая скорость получается? Если реально шустро, то можно поковыряться в клиентском жабоскрипте, попробовать для себя переделать.

И ffmpeg мне уж точно не нужен: мне надо видео обработать перед тем, как отсылать!

В смысле собственным алгоритмом? В ffmpeg'е вроде были какие-то фильтры, может можно плагин запилить.

А какая скорость получается? Если реально шустро, то можно поковыряться в клиентском жабоскрипте, попробовать для себя переделать.

Сложно сказать, я не замерял особо, но картинка с демкой по первой ссылке выглядит правдоподобно. Задержка от махания рукой перед камерой и появлением руки в браузере насколько помню была меньше секунды (по сравнению с 4мя секундами с VLC вообще реалтайм), при том, что камера сначала слала видео на комп-ретранслятор по локалке, а уже потом оно уходило в облако (на противоположный конец шарика) и возвращалось обратно.

Да, собственным алгоритмом. Как минимум — вычленить наиболее яркую звезду и вычислить центроид. По-хорошему — выявить несколько звезд и посчитать не только смещение, но и угол поворота.

Задержка от махания рукой перед камерой и появлением руки в браузере насколько помню была меньше секунды

Дык, с base64 тоже несколько миллисекунд задержка — на кодирование-пересылку-декодирование.

камера сначала слала видео на комп-ретранслятор по локалке, а уже потом оно уходило в облако (на противоположный конец шарика) и возвращалось обратно.

Это ты так эмулировал большие расстояния между клиентом и сервером?

Это ты так эмулировал большие расстояния между клиентом и сервером?

Да просто озадачился сделать трансляцию с копеешной ип-камеры из дома через веб с минимальным количеством заморочек. Под рукой всегда есть бесплатная амазоновская vpsка.

Ой, а что это вы здесь все делаете? MCU - не то, что надо? https://duckduckgo.com/?q=MCU webrtc&t=lm

Короче, ОП, зацени идею.

Если тебя не смущает задержка порядка 10 сек и мелкие косяки в звуке - берешь основную идею из https://github.com/RReverser/mpegts, воспроизведение в браузере последовательных фрагментов mp4 путем ротации <video/> в <canvas/>.

Запиливаешь предельно тупой сервер, который пишет /dev/video в mp4-файлы по 5-10 секунд и обновляет плейлист - простой список ссылок на имеющиеся фрагменты. Ну, и зачищает старые фрагменты, понятное дело.

Получается дешево и сердито, имхо, и не настолько дерьмово, как mjpeg over ws. Выигрыш по соотношению качество/ширина канала очевиден.

кстати, в ffmpeg уже есть готовый муксер. для сервера нужно только зачистку сегментов и обновление плейлистов прикрутить.

Дерьмовая идея. ты, похоже, не прочитал оп-пост.

Задержка больше 100мс неприемлема! Только realtime!

Короче. Я поставил libwebsockets и скомпилял под него свой лисапед. Как будет время, проверю, сколько кадров в секунду сможет «малинка» выдать. Если не меньше пяти будет, то и остановлюсь на этом. Если же сильно меньше, то опять буду дурацкими жопегами.

Ну, дело хозяйское. А зачем вообще в браузере low-latency видео? В смысле, что там требует моментального фидбека?

Ручная корректировка автогида для перемещения объекта на щель спектрографа.

мда.

короче, в браузере из стандартных средств для low-latency действительно только webrtc. с ним все сложно и печально.

Да, жаль. Я так надеялся пару лет назад, что webrtc сделает ненужным скайп, а оно как было в альфа-стадии, так и осталось.

Хорошо хоть, вебсокеты с вебглем не похоронили, а довели до логического завершения. Использую. Нравится.

Да почему в альфе? Оно вполне себе работает, замены скайпу когда-нибудь появятся.

IMO, у webrtc только две серьезных проблемы: оно p2p by design(сервер реализовывать можно задолбаться) и зоопарк аудио-кодеков, как всегда в вебе.

Звук мне не нужен, нужна лишь нормальная поддержка видео в реальном времени. Идеалом была бы такая схема: тег <realtimevideo src=...> соединяется с сервером и окткрывает сокет; отправляет сигнал "жду картинку", сервер отсылает последний актуальный жопег; клиент отображает этот жопег и опять отсылает сигнал "жду картинку".

Такого я еще не встречал. И вообще не понимаю, какого хрена веб-разработчики эту элементарщину до сих пор не реализовали!!!

Ну хотя бы сделали возможность принимать бинарный блоб и сразу отображать его, я б тогда жопеги слал через вебсокеты. Ведь сейчас у меня главный затык — декодирование base64 жабоскриптом!

сервер отсылает последний актуальный жопег; клиент отображает этот жопег и опять отсылает сигнал «жду картинку».

к видео это имеет примерно никакое отношение, это очень частный случай. потому и не реализовали.

декодирование base64 жабоскриптом!

ты так говоришь, будто это что-то сложное. хочешь я тебе base64.js подарю? и вообще, ты уверен, что оно надо? новая идея - ты кидаешь через вебсокет блобы jpeg-а в base64, держишь в памяти один <img/> с data-url в src, обновляешь этот data-url пришедшим через ws, и рендеришь его в <canvas/>. То есть, развитие идеи с mp4-сегментами на картинки, а base64 декодит браузер.

алсо, у тебя есть тестовый сервер поиграться? ну или опиши в двух словах, как сделать тестовый бэкэнд.

к видео это имеет примерно никакое отношение

Очень даже прямое! Потому что в режиме реального времени ты видео сможешь отсылать лишь жопегами: 1 кадр == 1 жопег.

и вообще, ты уверен, что оно надо?

Конечно: бинарный блоб браузеры казать не могут.

новая идея - ты кидаешь через вебсокет блобы jpeg-а в base64, держишь в памяти один <img/> с data-url в src, обновляешь этот data-url пришедшим через ws, и рендеришь его в <canvas/>.

Так и делаю, только без костыля в виде canvas: сервер кодирует жопег в base64 и шлет клиенту через вебсокет, клиент декодирует и меняет src картинки.

ну или опиши в двух словах, как сделать тестовый бэкэнд.

У меня еще не готово. Глядишь, через годик появится время и сделаю.

в режиме реального времени ты видео сможешь отсылать лишь жопегами: 1 кадр == 1 жопег.

слушай, ты несешь какую-то чушь. во всем живом видео используются вполне обычные кодеки - h264, vp8, еще что-нибудь. У них на требуемой latency будут значительно более низкие требования к каналу.

твоя проблема в надуманных ограничениях клиента. тот же самый скайп выдает прекрасную низкую latency на нормальном канале. да и webrtc в аналогичных условиях, по идее, должен справляться лучше всех извращений.

бинарный блоб браузеры казать не могут.

дарю, можешь не благодарить. вся тяжелая работа на нативном коде браузера.

только без костыля в виде canvas

есть непроверенное пока подозрение, что это не костыль, а может сделать обновление более приятным глазу и эффективным - canvas типа как hardware-accelerated. надо проверять.

через годик появится время и сделаю.

погоди, я не понял - ты что, из диванных? я думал, ты малость двинутый, но что-то делаешь и тестишь.

во всем живом видео используются вполне обычные кодеки - h264, vp8, еще что-нибудь

Это невозможно: «обычные» кодеки используют кодирование с ключевыми кадрами! Если что, посмотри какую-нибудь «живую» трансляцию. И обрати внимание на задержку между реальным временем и временем трансляции. Меньше секунды я еще не встречал, а обычно бывает и больше (когда работал 1tv.ru задержка бывала и по полминуты!). Ну и еще: эти кодеки не поддерживают изменения сжатия на лету (в зависимости от пропускной способности сети) и вставления realtime-маркеров. Т.е. в итоге полезет такая рассинхронизация, что твое «живое» видео превратится в мертвое (это тоже наблюдалось на «первом» в те далекие времена, когда у них на сайте работала трансляция).

тот же самый скайп выдает прекрасную низкую latency на нормальном канале

Скайп в браузере работает? Хренушки! И, кстати, обрати внимание: скайп тупо жопеги через канал шлет!!!

дарю

Я видел этот код. Он не работает в firefox.

погоди, я не понял - ты что, из диванных?

нет, я одновременно тяну где-то полтора-два десятка проектов. На этот периодически 2-3 часа в неделю нахожу, но скоро опять нагрузка по основному проекту возрастет, и придется отложить это в долгий ящик. Тем более, что повылезала куча багов — чтобы все до ума довести, наверняка с неделю придется напряжно работать. А времени нет.

«обычные» кодеки используют кодирование с ключевыми кадрами!

И что? Причем тут кейфреймы? Задержка растет засчет совсем других механизмов - типа, lookahead buffer энкодера, разного рода буферизации в других местах и т.п. Разделение фреймов на I и P - оптимизация bandwidth, в идеале не влияющая на latency.

эти кодеки не поддерживают изменения сжатия на лету (в зависимости от пропускной способности сети) и вставления realtime-маркеров.

Это совсем отдельная тема. Изменение сжатия на лету требует не каких-то фич от кодека, там везде уже есть ограничение либо по качеству, либо по битрейту, а обратной связи между сетевой частью и энкодером, что просто мало где реализовано. Если что, в том же x264 есть оба упомянутых ограничения. Я думаю, на лету их менять вполне можно - просто рукоятки для этого нет.

Т.е. в итоге полезет такая рассинхронизация, что твое «живое» видео превратится в мертвое

Вообще, даже для HTTP-based протоколов HLS/HDS/DASH, что-то уже придумали. HLS выдает на лайвах выдает довольно стабильную задержку - в смысле, она не меняется от лагов сети. Ну и да, в таких протоколах проблема ширины канала решается мультибитрейтом - типа, если HD не пролазит в канал, качать SD.

Кстати, для DASH вообще умудрились сделать 240ms latency.

посмотри какую-нибудь «живую» трансляцию.

У меня работа - делать движок трансляций так, чтобы люди в них могли разговаривать. Херово, но получается, причем пока что даже на флеше. На нормальном WebRTC позже попробуем, должно быть лучше.

Скайп в браузере работает?

Это отдельная тема. Ты учитывай, что <video/>, статическое до предела, появилось относительно недавно по меркам w3c. До этого вообще был один только флеш с его тупым и глючным сетевым стеком.

То, что w3c тормоза - печально, конечно, но ничего не поделать. Не устраивает - пиши native-клиент или NaCl-модуль, скажем.

скайп тупо жопеги через канал шлет

вот, что об этом официально говорят.

As we searched for how to make Skype truly multiplatform, we determined the H.264 codec as a common denominator with the compression efficiencies and ubiquity that we required. We built our own optimized implementation of the H.264 codec and utilized partner versions where H.264 was fully integrated in specific platforms.

То есть, им H264 нормально. Опять же, в стандарт WebRTC заложен H264, то есть, W3C тоже нормально для видео разговорного типа.

И да, я хз, как ты ломал скайповское шифрование, чтобы убедиться, что там jpg - оно, конечно, сдало с апдейтами от м$, но остается на уровне.

Он не работает в firefox.

Тебе шашечки или ехать? Если у тебя такой файрфокс, что в нем не работают годные вещи - выкини его.

тяну где-то полтора-два десятка проектов.

Хреновая идея.

Разделение фреймов на I и P - оптимизация bandwidth, в идеале не влияющая на latency.

Для этого придется жать по-отдельности для кажого клиента. Неудобно.

Я думаю, на лету их менять вполне можно - просто рукоятки для этого нет.

Во-во.

240ms latency.

Ого! Это ж почти четверть секунды! Тебе приятно было бы, если бы ты жамкнул кнопочку, а отклик лишь через четверть секунды получил? И как попасть куда надо?

native-клиент

Тогда весь смысл веб-морды теряется! Я не собираюсь писать клиенты для мастдаек, а еще хуже — гей-фончиков и ондроедов!

То есть, им H264 нормально

Когда ты общаешься по телефону, тебе и полсекунды задержки — фигня. Там главное — синхронизовать видео с аудио, а то вообще жопа будет.

Тебе шашечки или ехать?

Мне ехать, но чтобы можно было ехать и на жопорожце.

Хреновая идея

Ну, а по-другому не получается.

Для этого придется жать по-отдельности для кажого клиента.

Зависит. Если у тебя кейфрейм раз в секунду - клиент ждет меньше секунды, чтобы начать рендеринг.

можно было ехать и на жопорожце.

Мгм. Самое свежее в примере - Blob(), который в Gecko поддерживается с June 5, 2012(Firefox 13). Что не работает-то?

Это ж почти четверть секунды!

Это ВСЕГО четверть секунды на сегментированном, если что, формате. Тут я считаю нужным добавить что-то в духе «сперва добейся» - это не так-то просто. Мне кажется, даже такой результат сделать стабильно воспроизводимым сложно.