Как RTP соединение после RTSP ???

ничо не понял.

RTP это тупо специально завернутые в UDP пакеты.

с сервера ты их шлешь, с клиента читаешь, всё

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

ну у тебя ещё и недоделанный rtsp. DESCRIBE, SETUP, PLAY должен быть.

OPTIONS вообще не нужен, но все упарываются

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

1. отправить/опубликовать стрим на сторонний сервер в качестве «клиента»
2. поднять слушающий порт для чтения пакетов (например, из п.1), писать во входной поток очевидно нельзя

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

Нат то обойти мне уже понятно как в теории и пару вариантов я протестил, но вопрос не в этом.

SETUP тоже есть, но ffplay его не шлет, не знаю почему, однако rtps-simple-server без проблем это отрабатывает, поэтому пока просто в PLAY для такого случая сделал частично общий код с SETUP

пасути вопрос как все таки ffserver стримил из ffmpeg ? если он подготавливал SDP из своего конфига, то RTP поток он полюбому как то брал снаружи

если ffplay не шлет SETUP, значит на DESCRIBE ты выдал что-то плохое, что недостойно проигрывания ффмпегом

вполне возможно, не делал еще нормального sdp в ответе видимо на DESCRIBE, однако это не мешает ему отравить мне PLAY, а потом еще и ждать пакетов, с другой стороны VLC и после кривого DESCRIBE шлет SETUP

но вопрос конеш не в этом…

если ты не делал нормальный SDP, то всё дальнейшее не имеет смысла.

Тебе надо сначала его сформировать, потом сформировать правильные ответы на SETUP.

У тебя будет выбор между interleaved и нет и кажется, что тебе проще с него начать.

но вопрос конеш не в этом…

вопрос «конеш» именно в этом, потому что ты пытаешься перепрыгнуть этапы хендшейка.

хотелось бы сначала проверить возможность направить «снаружи» rtp поток через этот rtsp север, поэтому что это первоочередная задача, не важно что он не будет корректно проигрываться, важно лишь наличие пакетов rtp, может это вообще тупиковый путь.

еще раз sdp какой то высылается, это я вижу в tcpdump, этого достаточно чтобы ffplay послал команду PLAY, на которую мне нужно ответить уже rtp потоком.

а ты упертый =)

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

вопщим решил еще раз зайти с начала, как я понимаю - связка ffserver + ffmpeg работает следующим образом - ффмпег пишет в файл, который они называют feed, затем ffserver берет из этого файла и делает уже stream

вся херабора по открытию потока у ффсервера выполняется в функции

int open_input_stream(HTTPContext *c, const char *info)

здесь то у меня и происходит тупик, т.к. не понимаю как подсунуть свой rtp поток БЕЗ тупой реализации через файл.

как я понимаю, все что я могу, это открывать в open_input_stream входной поток ффмпегом avformat_open_input с rtsp_flags listen иба rtp_flags listen нет, либо врукопашную создавать еще одни слушающий читающий сокет для rtp потока и читать буферы из одного сокета и писать в другие…

вопщим сделал все таки через avformat_open_input с rtsp_flags listen, в который пишу ффмпегом, допиливаемый мной ffserver что то там читает из такого сетевого стека, позволив отказаться от записи в файл

так же стало понятно почему ffplay после DESCRIBE шлет сразу PLAY иба на дескрайб я не слал SDP описание, после допиливания сего момента (берущийся тупо из avformat_open_input) и пришел SETUP

рано я обрадовался началу теста RTP потока.

ФСЁ!!! ВИДЕО ПОЕХАЛО!!!

rtsp/rtp сервер из ffserver от версии 3.4 с библиотеками 5.1 поднялся, видео через него получилось в VLC отдать без всяких временных файлов, крутится как детачный поток, в который передаю кадры через сетевой стек