С++ vs RTSP proxy/server

GStreamer ?

Чувак, я нихера не понял что ты сказал, но ты задел меня за самое сердце. (с)

pjsip?

так это вроде для телефонии? протокол над протоколами…

у меня просто по ламповому предполагается создание UDP тунелей между 2мя узлами за NAT

SIP не просто так называется как называется:) Посмотри список реализуемых в этой либе протоколов, возможно, ты изобретаешь велосипед.

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

Простейшие приложения в браузере как-то обходятся без астериска.

Я кста распарсил кажется чего ты сделать хочешь, тебе по идее сойдёт и ffmpeg. Даже либа то особо не нужна для прототипа. Но, что-то мне сдаётся решения типа ninja и построенные на основе, находятся где-то прям близко к готовому из области того, чего ты хочешь.

например?

всем нужно через что то договориться о маршрутах, MQTT требует минимального трафика, тем более он у меня уже используется для работы с распределенным оборудованием

спасибо, изучаю ninja

Например, используя WebRTC.

Я конечно не настоящий водопроводчик, но точно есть какие-то движения и в сторону webrtc over mqtt.

WebRTC

но он тоже использует STUN с одним белым адресом или что то через что проксировать трафик (TURN), но последнее мне не походит, тк трафик должен ходить ТОЛЬКО с устройства за НАТ на браузер за НАТ

Плюс ко всему нет времени на построение сети (ICE) - т.е. условно кидаешь свой адрес-порт на нате через мктт, тебе ответ куда подключаться и погнали смотреть видео.

грубо говоря в тестовом варианте мне нужно сделать просто «перенаправления порта» на ip или usb камеру со своей железки

Плюс ко всему нет времени на построение сети (ICE) - т.е. условно кидаешь свой адрес-порт на нате через мктт, тебе ответ куда подключаться и погнали смотреть видео.

нет времени разбираться, просто стримануть видео между двумя адресами за нат

нет, это невозможно без приседаний как webrtc

hizel

почему? «частично» (нат с одной стороны был) в тупую файл получилось через netcat отправить.

ну теперь повтори для двух nat, прямо следует из механизма работы nat, не чувакам делать было нечего они нахуевертили STUN, ICE, TURN

hizel

на хабре люди openvpn поднимают между 2 узлами за нат пользуясь яндекс.диском https://habr.com/ru/post/481034/

В прошлой статье описывался процесс организации соединения с помощью третьей стороны — посредника (арендованный VPS выполняющий роль, что-то типа STUN-сервера и передатчика данных узлов для соединения). В этой статье я расскажу как обошелся без VPS, но посредники остались и ими были STUN-сервер и Яндекс.Диск…

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

ты хочешь дать кому-то сервис, брать за него деньги, а сам через себя трафик не гонять?

)) в целом да

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

по видео потоку я так понимаю надо выбрать что то из GStreamer или ffmpeg, по проходу через нат это еще «исследовать» надо разных провайдеров, проход через симметричный нат я только через свой сервер пробовал пока что )

если ты хочешь в браузер, то у тебя только webrtc, с поддержкой STUN, TURN серверов.

Удачи =)

hizel

ну теперь повтори для двух nat

повторил, через 2 ната, правда «клиентский» нат, через который пулял с помощью ncat находился на моем шлюзе, но на «серверной»-принимающей стороне попробовал проводного провайдера и сотового - на маленьких задачах четка, на больших файлах некоторая мешанина и пропуски… видимо надо делать паузы, слать короткими пакетами, выполнять какую то проверку и повторы отправки… не суть, важно что как то оно работает )

max_lapshin

у тебя только webrtc, с поддержкой STUN, TURN серверов

бегло пролистав вопрос я так понял стандарт технологии требует использовать только определенные кодеки, а все остальное зависит от используемого сервера/библиотеки webrtc… если я правильно все понимаю…

нда… оказывается мешанина создается отправкой netcat пакетами по 8192 байта, которые приходят почему то в разное время… если ставить задержку при отправке в нем, то визуально файл приходит целым.

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

пока чта удалось запилить свою приблуду, которая УСПЕШНО обменивается в ОБЕ стороны файлами МЕЖДУ ДВУМЯ УЗЛАМИ ЗА НАТ, получение списка файлов в любой папке, скачивание и загрузка в любую мамку на удаленном узле - почти чта вирусяка, создающая дыру ))

мелочь, а приятно ))

теперь самое сложное - надо копать webrtc, как его собрать и послать в этом UDP «туннеле»…

еду дальше )

faq2

webrtc over mqtt

пример СИГНАЛЬНОГО обмена webrtc через mqtt сервер нашел такой, пример староват, поэтому ссылка на устаревшую библиотеку Paho не действительна и некоторые JavaScript команды уже не поддерживаются хромом… но в целом завернуть OFFER webrtc запрос жаваскриптом с получением адреса на НАТ со STUN сервера через mqtt удалось… надо теперь как то послать ANSWER webrtc сначала жаваскриптом, а потом своей приблудой…

https://gist.github.com/mganeko/160a298bcc9f5c237dd4

я подобное делал, для транскодинга использовал libav*

вместо RTSP итп сигнальных протоколов, запилил свой текстовый

а, и да - начал изначально на C++, потом забил хер, потому как заколебался с ним бороться, и переписал на .net, из которого дергал libav*

C++ для чего-либо более менее сложного - это натурально есть говно

lovesan

железяка простая, аля расбери или того проще, может даже какой-нибудь нанопи, городить на него монструозные дотнеты некомильфо, т.к. помимо ограничений в вычислительных ресурсах при этом есть требование высокой производительности. RTSP отдает обычная ip камера или с какой то USB аля UVC придется брать, естественно весь этот зоопарк нужно отдать в чем то одном, из всего общеизвестного как я понял только webrtc даст простое использование на фронтенде (бразер или мобильное приложение) с минимальной задержкой.

ну а С++ да несколько сложноват и больше кода приходится писать, но в целом и проект то не шибко большой.

па сути сейчас мне надо на С++ отпарсить SDP текст OFFER запроса пришедший через mqtt, сформировать на его основе ANSWER ответ и отправить его, из последнего я покамесь знаю как послать через mqtt, как для ANSWER получить ICE кандидата просто взяв его со STUN сервера

остальное - какие еще поля этого ANSWER обязательны и главное как сконвертировать и послать webrtc SRTP медиапоток на клиента находящегося за 2 натами - пока мрак.

для SRTP видимо придется копать эту библиотеку

https://github.com/cisco/libsrtp

а для ANSWER какой то rfc, т.к. ту здоровенную срань, что шлет бразер через mqtt в OFFER запросе обратно слать не хочется.

покамесь получилось передать видеопоток из бразера в тот же самый бразер жаваскриптом общаясь через mqtt… думаю разницы нет разнести бразеры на разные машины в локальной сети… поедет ли такое колесо через 2 ната БЕЗ TURN сервера, только с использованием STUN - не знаю, да мне это и не нужно, иба отдавать поток мне надо не из бразера.

тупое глядение на здоровенную портянку SDP запросов-ответов потянуло меня в гугл, который сказал что единственная мегастарая либа называется https://github.com/EricssonResearch/openwebrtc

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

эээхехе….

вариант посвежее… вроде не мертвый как предыдущий

https://github.com/paullouisageneau/libdatachannel

https://janus.conf.meetecho.com/

тут еще посмотри.

conalex

ну в принципе для тестирования качества видео-звука надо попробовать развернуть этот сервер, спасибо

conalex

крайне интересная штука этот Janus - легкий и модульный с подключением своих сишных «плагинов», подключил к нему IP камеру через RTSP, пишет New video stream, какие то команды удалось послать ему в MQTT топик, с получением ответа на них… НО как с него SDP webrtc через mqtt ответ хотя бы получить!?… не само конечно получение, а чтоб отправил янус этот.

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

видимо надо смотреть то, что шлется через Plain HTTP REST Interface…

вопщим последовательность с великим Янусом такая при отправке в mqtt

{"janus": "create", "transaction": "123"}

{"janus" : "attach", "session_id" : , "plugin" : "janus.plugin.streaming", "transaction" : "123"}

{"janus" : "message", "session_id" : , "handle_id" : , "transaction" : "123", "body" : {"request" : "watch", "id" : 0}}

очевидно нужно отправить answer вида

{"janus" : "message", "session_id" : , "handle_id" : , "transaction" : "123", "body" : {"request" : "start"}, "jsep": {"type": "answer", "sdp": "наш ансвер"}

поправочка, ансвер вида

{"janus" : "message", "session_id" : ' + session_id + ', "transaction" : "' + transaction + '", "handle_id" : ' + handle_id + ', "body" : {"request" : "start"}, "jsep": {"type": "answer", "sdp": "' + sdp.replace(/\r\n/g,'\\r\\n') + '"}}

так же касаемо Януса нужно слать в мктт для поддержание сессии, иначе отваливается по таймауту

{"janus" : "keepalive", "session_id" : ' + session_id + ', "transaction": "' + transaction + '"}

в целом тест на узком канале ЧЕРЕЗ ДВА НАТА в 2 мбит/cек показал, что H264 в 7 кадров/сек с низким качеством в разрешении 1024х768 с аудио кодеком G711 - дает нагрузку на канал около 500 кбит/сек и вполне смотрибельное качество с приемлемым временем получения потока порядка до 5 секунд

по Янусу осталась проблема, что он через какое то время перестает получать с RTSP камеры поток и на узком канале переодически отваливается MQTT соединение в браузере

Буду теперь пробовать на НаноПи поднять Янус с UVC камерой...