Arduino.ru

Ты вот тут примерно два абзаца описания потерял.

Что именно потеряно?

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

этапять!))))

Объясню еще раз.

Видео поток идет на сервер на ESP-CAM. Когда ESP-CAM и DEVKIT клиенты в ОДНОЙ сети, то на ESPAsyncWebServer видео крутится. Когда ESP-CAM подключается к точке доступа на DEVKIT, а DEVKIT подключается к роутеру в режиме STA (т.е. они получаются в разных сетях), то на ESPAsyncWebServer видеопоток становится недоступным.

На ESPAsyncWebServer организован просто редирект: server.on("/mjpeg/1", HTTP_GET, [](AsyncWebServerRequest *request){ request->redirect(camURI); });

Собственно вопрос в том, как организовать просмотр видеопотока, когда ESP-CAM и клиент в разных сетях.

Во-первых, я спрашиваю совета, а не жалуюсь.

Во-вторых, научись читать и адекватно излагать мысли, а не выстукивать наборы слов.

Кроме того, если нечего сказать по существу, то, сиди и помалкивай. Может и сочтут за умного.

Это http-переадресация. Передачи потока она не осуществляет, она говорит клиенту, чтобы обратился к другому ресурсу, который ему недоступен, потому что ты не открыл доступа. Тебе нужно делать именно передачу данных, либо L2-мост.

Вот теперь по существу.

То, что это просто тупо переадресация, я знаю. Собственно, суть моего вопроса как раз в том, как достучаться к ресурсу. Что лучше организовать, либо доступ, либо туннель. И как это сделать.

Я всегда разрабатывал только конечные устройства. Поэтому подобная задача, с общением устройств, для меня новая. Но, никогда не поздно учится.

Ответа "что лучше" дать невозможно, пока неизвестна цель.

Цель простая. Клиент, подключаясь к роутеру или (если настроено) через инет, может через DEVKIT просматривать видео с ESP-CAM либо на странице в браузере, либо в плеере, либо с помощью любой проги для IP камеры.

На роутере покинуть порт на систему, генерирующую видеопоток.

Это не вариант. Разрабатываемое устройство, это коммерческий проект, который затем будет в массовом производстве. Поэтому, исходим из того, что конечный пользователь, не должен ничего настраивать. Только воткнуть вилку в розетку и ввести логин с паролем от своего WiFi.

Роутер не видит ESP-CAM, подключенную к AP на DEVKIT, поскольку она в другой сети. Поэтому надо делать проброс портов на DEVKIT.

После мозгового штурма, пришли к выводу, что все таки, нужно организовывать туннель (мост). Сейчас пока к DEVKIT подключается только одна ESP-CAM, но в перспективе, возможно, будем делать пул из нескольких камер, подключенных к одной (ну там конечно не DEVKIT, а своя разработка на модуле ESP-32S), пока идет разработка, DEVKIT. 

А ты вообще базовые расчеты производительности проводил, коммерсант доморощенный?

Да уж.
Тогда скачивай mjpeg, храни в памяти и отдавай по запросу.

Если получится.

У производителей ip камер-то не всегда получается стабильная работа девайса на специализированном чипе, а тут ESP-шки.

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

А чем это это отличается от передачи данных? 

Сейчас, 3 ESP-CAM (пока столько в наличии) отлично ретраслирут видеопоток на ESPAsyncWebServer на DEVKIT, но, только если они с DEVKIT, в одной сети. Т.е., нужно организовывать туннель. А вот как это осуществить на ESP-шке, пока знаний нет.

Производители ip-камер, работающие на ширпотреб, используют слишком узкоспециализированные чипы, причем весьма невысокого качества и производительности. Их основная задача не что бы работало, а что бы больше покупали. У специализированных производителей, которые занимаются производством систем видеонаблюдения и безопасности, все отлично и стабильно работает. Уж за почти 20 лет работы с ними, я это усвоил. Однако, и они начали скатываться к ширпотребу.

Я сужу совсем не по себе, а по тому факту, что ты решил в режиме двойного интерфейса гнать несколько видеопотоков. Вполне очевидно, что не считал. Ну и факт, что задача примитивно поднять l2-мост поставила тебя в тупик, и потащила в какие-то тоннели (которые без функционала моста всё равно работать не будут, кстати), уверенности не добавляет. Обратись к специалистам, короче. Если, действительно, коммерция. а не цирк с конями.

Код HTML-страницы в студию.

%camNum% - название + номер камеры. %самURINum% - url камеры. Num - порядковый номер камеры.

Именно по себе!!!

Если ты, циркач, выучил прикольное название "L2-мост", это еще не значит, что нужно его везде пихать.

А раз ты не специалист, как ты написал, то сиди и помалкивай. Из-за таких "докторов околовсяческих наук", многие (а особенно новички) не хотят заходить на отечественные форумы. Если ты человек с определенными знаниями, так поделись ими, и будут к тебе люди нормально относиться. А пока от тебя только пустой треп и хамство.

На ESP-CAM

Но и на DEVKIT тоже работает. На сервере путь "/mjpeg/Num". VLP плеер берет поток с DEVKIT.

Ты по отдельности с трёх камер смотришь или сразу с трёх на трёх устройствах? Это, как бы, важный момент.

На данный момент я вижу, что devkit формирует html, через который браузеру скармливаются прямые ссылки на esp-cam, и на этом роль devkit завершена. Поэтому и работает только в одной подсети.

Никакого проксирования не наблюдаю.

На странице, все три. В плеере по одной на каждое окно плеера.

Специалист это тот, кому за его знания платят деньги, если великий "коммерсант" не в курсе.

А я поделился, только ты не хочешь слушать. Не ленивый чел уже бы имел решение, если бы элементарно погуглил мое "прикольное название", вместо того, чтобы в позу вставать. Работы тут часов на 15 максимум, даже если с полного нуля изучать тему.

А вот хамить первым начал ты, солнышко.

Так я и писал выше, что на DEVKIT тупо редирект. А вопрос в том, как организовать внутри DEVKIT проброс адресов между AP и STA.

Разберитесь с терминологией. То редирект, то ретрансляция, то проброс адресов.

Пока этого не сделано, не поймёте ни единой рекомендации.

Объясню еще раз.

Сейчас реализован тупо редирект. Он работает только если все esp-шки в одной сети.

Нужно реализовать, чтобы клиет, через STA DEVKIT, мог просмотреть видео с ESP-CAM, подключенной к AP DEVKIT. Т.е., нужно реализовать проброс адресов в DEVKIT, между AP и STA. Для начала хотя-бы для одной ESP-CAM. Это и есть одна из разновидностей ретрансляции.

Собственно в этом и есть мой вопрос. Как это можно реализовать?

Нанять грамотного инженера-сетевика.

Еще один остряк самоучка.

Прежде чем влезать в разговор, потрудись узнать о чем вообще он идет.

Отвечаю ещё раз: скачивай mjpeg [девкитом с esp-cam], храни в памяти [девкита] и отдавай по запросу [браузера].

Это самое простейшее проксирование.

Все остальное сложнее на порядок и наврядли имеет смысл в данной конфигурации.

"Проброс адресов" - совершенно бессмысленная фраза.

Где то было, что к точке доступа созданной ESP32, могут коннектиться не более 5 клиентов. Пробовал 3 устройствами получить IP адрес от точки, получил,  но тормоза в работе  самого устройства которое создало точку, были заметны сильно.

> Сейчас реализован тупо редирект. Он работает только если все esp-шки в одной сети.

Не совсем понятно чего Вы хотите. Если Вам надо нужно что-бы потоки каких-то данных запрашивались через сервер с разных IP адресов, то в качестве прокси, можете использовать nginx. Такую штуку он умеет делать не помню только в платной или бесплатной версии. По моему все-же в обоих, но не уверен.
Еще подобное можно сделать на linux`e с помощью iptable и нет маскаринга...

Чойта самоучка?  Я два года на клоунском отделении в цирковом училище снег на крыльце чистил.  А вот ты там, похоже, учился да прогуливал...

Неболее 4-х!

Коннектил 3 ESP-CAM. Никаких тормозов не наблюдалось.

И как nginx или linux запихнуть в esp-шку?

Никак не запихнуть.

Но это самый простой в реализации прокси-сервер.

И как ты предлагаешь скачивать стрим, работающий в режиме 24/7, и хранить в памяти?

То, что для тебя "фраза" проброс адресов (он же NAT) является бессмысленной, говорит о некомпетентности в данном вопросе.

Хахаха. Кто-то сильно компетентный не в курсе, что NAT работает только с таблицей маршрутизации. И ты застрелишься объяснять потребителю, как это настроить.

И это разные вещи, о светоч компетенции

вы бы в зеркало посмотрели. Некомпетентым в этом споре выглядите вы. Спорите, вообще не понимая сути обсуждаемых вопросов.

"Проброс портов" или адресов между двумя разными сетями означает, что нужно взять пакеты из одной сети и скопировать их в другую.  В вашем случае "проброс адресов" будет означать копирование всего видео потока с одного интерфейса Девкит на другой. Вам нужен функционал роутера, но написанный для ЕСП в среде ардуино.  Если найдете.

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

Ты читать умеешь?

Все что вне esp-шек уже двно реализовано и отлично работает. Основной затык, организовать связь между AP и STA внутри одной esp-шки.

"Скачивать стрим" я не предлагал. Посидите, подумайте над вышенаписанным. А за готовым решением - извольте обращаться "в ищу исполнителя".

NAT в данной задаче вообще не пришей кобыле хвост. Тем более, что никаким "пробросом адресов" он не занимается.

Это совсем не функционал роутера. Роутер работает на третьем уровне, требует кучи таблиц в памяти, реализации ICMP и прочего гемороя. Он тут не нужен.

> Вам нужен функционал роутера, но написанный для ЕСП в среде ардуино.

Ну вот, за пару дней пустого трепа и цирка, хоть один научился читать. Да, именно это я и ищу.

Второй момент, формулу расчета в студию!

Сейчас стоит задача реализовать переброс потока только с одной ESP-CAM. Потом, если будет задача расширения, уже будем думать об этом.

ок, пусть мост.

Мосту тоже нужна таблица для подмены адресов одной сети на адреса другой

Функционала роутера для данной задачи, в принципе, не нужно, т.к. задействуется только Application Layer (он же Layer 7). Роутинга всё равно не будет, так как внутри этой сеточки будут серые IP, которые порежутся на первом же нормальном гейте. Устраивать NAT (полный или по портам) тоже смысла нет, так как обмен идет не 1:1 , а 1:N. Т.е. "прокси" не прокидывает запрос к какой-то одной esp-cam, а должен уметь разобраться - входящий пакет на HTTP port - это для Cam #1, #2 или #3. 

Единственное напрашивающееся решение - url-based reverse proxy. Который достаточно легко реализуется на linux-системах, которые много на чем можно поднять. 

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

А за "пару дней пустого трепа и цирка" скажите спасибо самому себе.

Не не нужна. Он работает на втором (MAC) уровне, где у каждого устройства глобально уникальный адрес.

хм... то есть он логически обьединяет сети "роутер-девкит" и "девкит-камера" в одну?