ffmpeg lifestream from Embided linux

https://github.com/mpc-hc/FFmpeg/blob/master/libavformat/rtspdec.c#L444

через нат не будет кеп

Порт 10323 проброшен напрямую, есть предположение, что RTSP пользуется еще какими то портам, после того как «договорится» по 10323. На следующей неделе появится возможность проверить. Плюс сообщение которое вы мне пометили в гите в лог падает после запуска видоса на макетке, и не раньше, значит что то между ними летает.

причем здесь порт? когда варнинг ясно говорит о том что айпи за натом

Вот на хабр пишут об особенностях при пробросе через nat https://habr.com/ru/post/324294/ Судя по всему мое соединение и использует non-interleaved которое не попадает в диапазон открытых портов, возможно в ffmpeg есть настройка для хардкодинга порта non-interleaved либо на переход в режим interleaved. Пока рыскаю по инету в поиске ответа.

Хорошо, и как можно пофиксить это? Я могу на макетке получить ip но макетка тоже наверняка закрыта натом( в моем случае билайна). Я сейчас действительно слушаю локальный порт, но ffplay не дает мне слушать внешний порт, так как роутер мне не дает выйти из моей сети и зайти обратно. Не помню точно что пишет, как попробую отпишусь.

Вот полная картина: Макетка (заранее ip не известен) <->провайдеры<->5.6.7.8 адрес моего wifi роутера(ip статичен)<-wifi->компьютер на которые проброшены заранее известный порт(пока что один пусть будет с 8888 проброшен на 8888) и на котором запущен слушатель(в будущем какой нить сервак сохраняющий всю прелесть в хард). Таким образом ip макетки не может быть известен заранее => он клиент. IP и порт слушателя (читай сервер) известен. Таким образом есть всего два варианта настроить слушателя: ffplay -rtsp_flags listen -i rtsp://5.6.7.8:8888/live.sdp или ffplay -rtsp_flags listen -i rtsp://192.168.1.34:8888/live.sdp (адрес сервака в локалке тоже захардкожен на роутере) Я использую второй вариант и он выдает этот варнинг. Первый вариант вроде тоже пробовал и он вообще не запустился, но точно не помню, надо пробовать еще раз.

или на роутере ставите rtsp прокси

или переключаетесь в интерливед что бы все в одной тсп сессии шло

или настраиваете тунель между вашими двумя точками теста

Сейчас ищу как переключиться в интерливед, не подскажете?

прочитайте наконец то мануал к ffmpeg

Вроде нашел как - установить в AVOptions or in avformat_open_input rtsp_transport=tcp, судя по сорсам и документации.

Дело не в том что я не читаю документацию, а в том что я вчера прочитал этот кусок два раза и только сегодня на третий раз увидел то что искал (но еще не точно, надо проверять), разница в том, что вчера у меня было меньше входных данных, и я не сразу вкурил что по дефолту rtsp долбит минимум в два порта, вчера нашел это на хабре и седня стало проще, так и проходит любое обучение. А вторая причина по которой я стучусь на форум, что бы не поймать камни которые уже ловились до меня и на сколько я понял, коррекнее все же запилить rtsp и rtp на разных портах (что то связанное с производительностью), так что после того как получится все поднять на одном tcp я буду изучать именно два разных порта и их влияние на количество камер, которые могут одновременно вещать через мой роутер. Так как ffmpeg мощный и довольна не новый инструмент, я надеялся что на форуме люди подскажут куда смотреть.

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

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

тогда да, «вот тут не понимаю,а там уже хочу»,так в программировании и ИТ не работает

все вопли на форумах, именно из за таких

Получилось решить проблему) Для тех кто пришел в интернет за помощью а не унижением, рецепт: 1)Открываем ссылочку avformat_alloc_output_context2(&obj->output_format_context, NULL, «rtsp», «rtsp://1.1.1.1:1111/live.sdp»); где 1.1.1.1 внешний адрес 2)Выставляем rtsp_transport av_opt_set(obj->output_format_context->priv_data, «rtsp_transport», «tcp», AV_OPT_SEARCH_CHILDREN); 3)Обходим камень которого нет, но видно только из сорсов, что rtsp_transport мало av_opt_set(obj->output_format_context->priv_data, «rtsp_flags», «prefer_tcp», AV_OPT_SEARCH_CHILDREN); 4)Делаем запрос(к этому моменту сервак должен уже слушать): AVDictionary* opts = NULL;//пользуюсь av_opt_set avformat_write_header(obj->output_format_context, &opts);

На серваке, который находится за NAT: ffplay -rtsp_flags listen -i rtsp://192.168.1.134:1111/live.sdp где 192.168.1.134 - ваш локальный адрес, 1111 - проброшеный порт

Теперь вы льете поток по ОДНОМУ порту, но TCP.