Задержка запуска RTP / RTSP: поможет ли этот метод уменьшить его, и если да, то почему у нас его нет - PullRequest
2 голосов
/ 26 января 2012

Возможно, это не лучший форум для такого специализированного вопроса, но на данный момент я не знаю лучшего (открытого для предложений / рекомендаций).

Я работаю над видеопродуктом, который последние 10+ лет использует собственный протокол связи (на основе DCOM) для отправки видео по сети. Некоторое время назад мы осознали необходимость стандартизации и в настоящее время почти готовы вырвать весь этот багаж DCOM и заменить его полностью совместимой клиент-серверной средой RTP / RTSP.

Одна вещь, которую мы заметили во время тестирования за последние несколько месяцев, - это то, что когда мы переключаем клиента на использование RTP / RTSP, происходит заметное увеличение задержки запуска. Проблема в том, что это не мы, а RTSP.

ДО (DCOM): мы отправили бы одну команду DCOM, и до того, как эта команда даже вернулась к клиенту, сервер уже отправлял видео. - общая задержка 1 RTT

NOW (RTSP): это последовательность команд, каждая из которых представляет собой отдельный сетевой запрос: DESCRIBE, SETUP, SETUP, PLAY (при условии, что в сеансе есть аудио и видео) - всего 4 RTT.

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

Можно ли это улучшить? Если вы придерживаетесь стандарта, короткий ответ - НЕТ. Однако моя команда полностью контролирует весь наш стек RTP / RTSP, и я подумал, что мы могли бы ввести новую команду RTSP (не затрагивая ни одну из существующих команд, поэтому мы все еще полностью совместимы) в качестве решения: DESCRIBE_SETUP_PLAY.

Мы могли бы отправить эту одну команду, передавая типы потоков, которые интересуют (как правило, есть только одно видео и 0..1 аудио). Ответ будет включать полный текст SDP, а также всю информацию о порте, и, как и прежде, сервер начнет потоковую передачу мгновенно, не ожидая чего-либо еще от клиента.

Будет ли это работать? Есть ли недостатки, которые я не вижу? Мне любопытно, почему это не было учтено (или было исключено) из официальной спецификации, поскольку задержка даже в локальной сети определенно заметна.

1 Ответ

1 голос
/ 05 июля 2012

К вашему сведению, это возможно в соответствии со спецификацией RTSP 1.0 :

9.1 Конвейер

Клиент, который поддерживает постоянные соединения или режим без установления соединения МОЖЕТmsgstr "свои запросы (то есть отправка нескольких запросов без ожидания каждого ответа).Сервер ДОЛЖЕН отправлять свои ответы на эти запросы в том же порядке, в котором они были получены.

Черновик RTSP 2.0 также содержит поддержку конвейерной обработки.

Однако ни один из клиентов / серверов, которые я использовал, не реализует это AFAIK.

...