Приветствую.
Дошли руки для продолжения темы (RTSP публикация надежна?), но пока классический вариант освоить требуется.
Все это «ноу-хау» )) делаю на основе кода на С умершего ffserver от ffmpeg, в котором и реализован только сам RTSP (+html) сервер, а RTP протокол обернут в библиотеки ffmpeg-a - собсна что мне и нужно с одной стороны, но не дает понимание как там работает RTP.
С RTSP понятно - слушающий сокет, через который по входящим событиям (poll) парсится текст. После rtsp согласования открывается еще один (хотя в netstat вижу 2 для rtp и rtcp) слушающий сокет, в который начинают писаться кадры, обернутые в rtp и разбитые на udp/tcp пакеты (в первую очередь рассматриваю udp соединение).
Собсна из за непонимания как происходит RTP обмен вопросы
- rtp клиент запрашивает каждый раз новые данные или rtsp сервер просто пишет в сокет, пока в сокет rtsp не придет закрыть соединение?
- несколько причин есть очередного рефакторинга, но одна из них это в том, что rtsp клиент может отваливаться и не прислать teardown - с помощью чего подобное лучше отслеживать, исходить из того, что каждый rtsp клиент обязан периодически слать options и по таймауту закрывать сокеты?
- вся эта кухня делается на одноплатнике, который уже занят на 75% по процессору, а хочется не только отдавать больше одного видео потока как это сделано в ffserver, но еще и разные (последние создадут нагрузку только на чтение с флешки помимо сети для случая однотипных) - однопоточный RTSP/RTP сервер потянет такие задачи для случая до 10 соединений или лучше сразу разделять 2 протокола на 2 потока?
Пы.Сы. звиняйте за многа букав )
