LINUX.ORG.RU

С++ vs RTSP proxy/server

 , ,


0

1

Приветствую!

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

Вообще суть идеи - аля «регистратор» с доступом через NAT (если точнее через NAT с обеих сторон) - пока удалось сделать получение адреса и порта NAT на STUN сервере и передача их через MQTT сервер - тоже хотелось бы услышать советы или просто поругайте идею )

★★★

Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от faq2

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

wolverin ★★★
() автор топика
Ответ на: комментарий от wolverin

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

faq2
()
Ответ на: комментарий от faq2

например?

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

wolverin ★★★
() автор топика
Ответ на: комментарий от faq2

WebRTC

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

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 3)
Ответ на: комментарий от faq2

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

wolverin ★★★
() автор топика
Ответ на: комментарий от wolverin

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

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

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

hizel ★★★★★
()
Ответ на: комментарий от wolverin

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

hizel ★★★★★
()
Ответ на: комментарий от wolverin

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

hizel ★★★★★
()
Ответ на: комментарий от hizel

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от hizel

hizel

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

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

max_lapshin

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

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Ответ на: комментарий от wolverin

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

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от wolverin

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

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

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Ответ на: комментарий от faq2

еду дальше )

faq2

webrtc over mqtt

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

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

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.