RTSP — протокол, которым программа просмотра управляет видеопотоком с IP-камеры или медиасервера: просит описание потока, запускает показ, ставит на паузу и закрывает сеанс. Само видео RTSP не везёт, его доставляет протокол RTP. Стандартный порт RTSP — 554, а ссылка на камеру выглядит так: rtsp://логин:пароль@IP-адрес:554/путь_к_потоку.
Ниже разберём, что клиент и камера говорят друг другу, из чего состоит RTSP-ссылка, как проверить поток одной командой и что значат ошибки 401, 404 и «Connection refused». Обмен сообщениями мы сняли на тестовом стенде с ffmpeg 8.1.2, поэтому все примеры в статье настоящие.
CheckroiПодборка курсов по сетевым технологиям29 курсов • 16 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Что такое RTSP простыми словами
RTSP расшифровывается как Real Time Streaming Protocol, «протокол потоковой передачи в реальном времени». Первую версию описали в RFC 2326 в апреле 1998 года. По синтаксису он нарочно похож на HTTP: те же текстовые строки запроса, заголовки и коды ответа вроде 200 и 404.
Главное отличие от HTTP в том, что RTSP управляет передачей, но сам поток обычно не передаёт. В тексте стандарта это сказано прямо: «It does not typically deliver the continuous streams itself». Удобнее всего представить пульт от телевизора: кнопки нажимаются по RTSP, а картинка идёт по отдельному каналу.
В одном сеансе с камерой работают сразу четыре протокола:
| Протокол | Что делает | Транспорт |
|---|---|---|
| RTSP | команды: описать поток, запустить, поставить на паузу, закрыть | TCP, порт 554 |
| SDP | описание потока внутри ответа RTSP: кодек, частота, номер дорожки | едет внутри RTSP |
| RTP | сами кадры видео и звука с номерами и метками времени | UDP или внутри TCP-соединения RTSP |
| RTCP | статистика доставки: потери, задержка | соседний с RTP порт |
В декабре 2016 года вышла вторая версия, RFC 7826. Она заменила первую версию, но с ней не совместима, кроме механизма согласования версии. На практике камеры, регистраторы и ffmpeg до сих пор говорят на RTSP/1.0, это видно в каждой строке обмена ниже. Если сетевые протоколы для вас пока сливаются в одно, начните с обзора TCP, UDP и HTTP.
Как проходит сеанс между камерой и клиентом
Мы подняли тестовую камеру и подключили к ней ffprobe, утилиту из пакета ffmpeg. Клиент отправил четыре запроса. Вот этот обмен с сокращениями, ответы камеры отмечены стрелкой:
OPTIONS rtsp://127.0.0.1:8556/Streaming/Channels/101 RTSP/1.0
CSeq: 1
→ RTSP/1.0 200 OK
→ Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN
DESCRIBE rtsp://127.0.0.1:8556/Streaming/Channels/101 RTSP/1.0
Accept: application/sdp
CSeq: 2
→ RTSP/1.0 200 OK
→ Content-Type: application/sdp
→ m=video 0 RTP/AVP 96
→ a=rtpmap:96 H264/90000
→ a=control:trackID=1
SETUP rtsp://127.0.0.1:8556/Streaming/Channels/101/trackID=1 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
CSeq: 3
→ RTSP/1.0 200 OK
→ Session: 47112344;timeout=60
PLAY rtsp://127.0.0.1:8556/Streaming/Channels/101/ RTSP/1.0
Range: npt=0.000-
CSeq: 4
Session: 47112344
→ RTSP/1.0 200 OKПорядок такой:
- OPTIONS: клиент спрашивает, какие команды понимает сервер.
- DESCRIBE: камера отвечает описанием в формате SDP. Здесь видно, что видео сжато кодеком H.264, а дорожка называется
trackID=1. - SETUP: клиент договаривается, как доставлять RTP. Камера выдаёт номер сеанса
Session, который дальше идёт в каждом запросе. - PLAY: поток пошёл. Чтобы закончить, клиент шлёт TEARDOWN.
Заголовок CSeq хранит порядковый номер запроса, ответ приходит с тем же номером. По нему клиент понимает, на какой запрос ответила камера.
Какие методы обязательны
Первая версия стандарта делит методы на обязательные, рекомендуемые и необязательные. Обязательных для сервера четыре: OPTIONS, SETUP, PLAY и TEARDOWN. DESCRIBE и PAUSE отнесены к рекомендуемым. Без DESCRIBE клиент не узнает кодек и номер дорожки, поэтому камеры его поддерживают. ANNOUNCE, RECORD, GET_PARAMETER, SET_PARAMETER и REDIRECT необязательны.
Методы ANNOUNCE и RECORD нужны для обратного направления, когда видео отправляют на сервер. Так ffmpeg публикует поток на медиасервер, похожим образом программы для стриминга отправляют трансляцию. Этот обмен мы тоже сняли: OPTIONS, ANNOUNCE с описанием SDP, SETUP с mode=record и RECORD.
RTSP-ссылка на камеру: из чего состоит
Чтобы подключить камеру к регистратору, облачному сервису или программе просмотра, нужна её RTSP-ссылка. Она собирается из пяти частей:
rtsp://admin:12345@192.168.1.64:554/Streaming/Channels/101
│ │ │ │ │ └ путь к потоку, у каждого производителя свой
│ │ │ │ └ порт, по умолчанию 554
│ │ │ └ IP-адрес камеры в сети
│ │ └ пароль
│ └ логин
└ схема протоколаIP-адрес камеры видно в списке устройств роутера, а если камер много, их находят сканером Nmap по открытому порту 554. Логин, пароль и порт можно опустить: тогда клиент подставит порт 554 и спросит пароль, если камера его потребует. Сложнее всего с путём. Стандарта на него нет, и у каждого производителя свой формат.
Два примера от разных производителей:
- Hikvision и HiWatch:
rtsp://admin:12345@192.168.200.11:554/Streaming/Channels/101, такой адрес приведён в базе знаний «Росдомофона». - Beward, серии B и TFR:
rtsp://admin:password@<IP адрес>:<порт>/av<номер канала>_<номер_потока>. Номер потока, по ответам поддержки производителя, равен 0 для основного и 1 для дополнительного.
Почти у каждой камеры два потока. Основной поток идёт в высоком качестве, его пишут в архив регистратора. Дополнительный легче, его удобно отдавать в облако или открывать в сетке из многих камер. «Росдомофон» советует именно такое разделение: основной на архив, дополнительный на трансляцию.
Как узнать RTSP-ссылку своей камеры
- Инструкция и сайт производителя. Ищите раздел про RTSP или про подключение к сторонним регистраторам.
- Веб-интерфейс камеры. Порт RTSP и включение протокола обычно лежат в сетевых настройках.
- ONVIF. Если камера поддерживает этот стандарт, программа сама спросит у неё адрес. Для этого в спецификации ONVIF Media есть команда GetStreamUri, которая, по тексту спецификации, запрашивает адрес для запуска живого потока с RTSP в роли управляющего протокола.
Про сам стандарт: профиль ONVIF Profile S описывает камеры и кодеры, которые отдают видео по IP-сети, и программы, которые этим видео управляют. Камера с Profile S подключается к регистратору другого производителя без ручного подбора пути. Профиль постепенно выводят из обращения: на той же странице сказано, что заявки на сертификацию новых устройств по нему принимают до 31 марта 2027 года.
Как проверить RTSP-поток одной командой
Быстрее всего проверить ссылку утилитой ffprobe. Она подключается к камере, читает описание потока и выходит, ничего не показывая:
ffprobe -rtsp_transport tcp "rtsp://admin:12345@192.168.1.64:554/Streaming/Channels/101"Если всё в порядке, в конце вывода будет строка с видеодорожкой, например Stream #0:0: Video: h264. Ошибка подскажет, что не так, разбор кодов ниже. Ссылку в кавычках лучше брать всегда: символы & и ? в путях некоторых камер командная строка иначе поймёт по-своему.
Флаг -rtsp_transport tcp просит возить видео внутри того же TCP-соединения, что и команды. Без него ffprobe в нашем тесте предложил камере UDP: в запросе SETUP стояло RTP/AVP/UDP;unicast;client_port=30558-30559. Варианты транспорта перечислены в документации ffmpeg: udp, tcp, udp_multicast, http и https. Если указать несколько, ffmpeg пробует их по очереди.
Посмотреть картинку глазами можно в VLC: программа открывает RTSP-адрес как сетевой поток. Для регистратора или облачного сервиса ссылку вставляют в поле добавления камеры.
Какие порты использует RTSP
У одного сеанса бывает до трёх групп портов, и из-за путаницы между ними поток часто не доходит.
| Порт | Для чего | Источник |
|---|---|---|
| 554 TCP и UDP | команды RTSP по умолчанию | RFC 2326, раздел 9.2 |
| 322 TCP | защищённая схема rtsps | RFC 7826 |
| пара UDP-портов клиента | RTP и RTCP, номера согласуются в SETUP | заголовок Transport |
В режиме UDP камера шлёт видео на порты, которые клиент назвал в SETUP. Если клиент за NAT или межсетевым экраном, эти пакеты до него не доходят: команды проходят, сеанс открыт, а картинки нет. Режим TCP с interleaved=0-1 решает это, потому что всё идёт через одно соединение на порт 554. Подробнее про устройство портов написано в статье о сетевых портах TCP и UDP.
Открывать порт 554 камеры в интернет пробросом на роутере рискованно. Команды обычного RTSP идут открытым текстом, это видно в обмене выше, а камера с заводским паролем становится доступна всем, кто найдёт порт. Для просмотра извне безопаснее облачный сервис производителя или ретрансляция через медиасервер. Если камеру всё же выносят наружу, её ставят в отдельный сегмент сети, как в схеме с DMZ.
Частые ошибки RTSP и что с ними делать
Все сообщения ниже ffprobe выдал на нашем стенде, каждое мы вызвали намеренно.
401 Unauthorized
method DESCRIBE failed: 401 (Unauthorized)
Server returned 401 Unauthorized (authorization failed)Камера требует пароль, а его нет в ссылке или он неверный. Сообщение одинаковое в обоих случаях.
Решение: проверьте логин и пароль в веб-интерфейсе камеры. Если в пароле есть символ @ или /, замените его на код: @ пишется как %40, / как %2F. По RFC 3986 в части адреса с логином и паролем эти символы без кодирования стоять не могут.
404 Not Found
method DESCRIBE failed: 404 (Not Found)
Server returned 404 Not FoundКамера на связи и пароль приняла, но такого пути у неё нет. Обычно это путь от другого производителя или неверный номер канала.
Решение: возьмите путь из инструкции именно к вашей модели или спросите адрес через ONVIF.
Connection refused
Connection to tcp://127.0.0.1:8599?timeout=0 failed: Connection refusedНа этом порту никто не слушает. RTSP выключен в настройках камеры, порт изменён или в ссылке опечатка в IP-адресе.
Решение: откройте сетевые настройки камеры и сверьте порт RTSP. Если ссылка ведёт на роутер, проверьте правило проброса.
Команды проходят, а видео нет
Сеанс открывается, PLAY получает 200 OK, но кадров нет. Чаще всего UDP-пакеты RTP режет NAT или межсетевой экран.
Решение: переключите клиент на TCP. В ffmpeg и ffprobe это -rtsp_transport tcp, в регистраторах есть пункт выбора транспорта в настройках канала.
Канал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 800 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в каналRTSP, RTMP, HLS и WebRTC: что выбрать
RTSP хорош там, где камера и клиент в одной сети и нужна минимальная задержка: регистратор, видеоаналитика, пульт охраны. Для сайта и массовых зрителей поток обычно переупаковывают в другой протокол.
| Задача | Протокол |
|---|---|
| забрать видео с IP-камеры в регистратор или аналитику | RTSP |
| отправить стрим на видеоплатформу из OBS | RTMP |
| показать трансляцию тысячам зрителей в браузере | HLS |
| видеосвязь и просмотр в браузере с минимальной задержкой | WebRTC |
Переупаковкой занимаются медиасерверы. Например, у открытого MediaMTX в описании прямо сказано, что потоки автоматически конвертируются из одного протокола в другой: камера отдаёт RTSP, а зритель получает HLS или WebRTC. Как WebRTC и RTSP делят работу с RTP, мы разбирали в статье про RTP.
Как поднять RTSP-поток для теста
Своя камера для экспериментов не нужна. ffmpeg умеет и отправлять поток, и принимать его. Сначала запустите приёмник, он будет ждать подключения 20 секунд:
ffmpeg -listen_timeout 20 -i rtsp://127.0.0.1:8554/live -t 3 -c copy recv.mp4Во втором окне терминала отправьте на него тестовую таблицу:
ffmpeg -re -f lavfi -i testsrc=size=640x360:rate=25 -t 4 -c:v libx264 -preset ultrafast -f rtsp rtsp://127.0.0.1:8554/liveЧерез несколько секунд рядом появится файл recv.mp4 с видео H.264 640×360. В ffmpeg 8.1.2 приёмник с одним флагом -rtsp_flags listen у нас не запустился и упал с ошибкой «Result too large», а с -listen_timeout заработал сразу.
ffmpeg-приёмник принимает один поток и раздавать его не умеет. Для стенда на несколько клиентов ставят полноценный медиасервер, тот же MediaMTX.
Где освоить сети и видеонаблюдение системно
Чтобы подключить одну камеру, хватит этой статьи. Чтобы проектировать сеть под десятки камер, разбираться с NAT, сегментами и нагрузкой на канал, нужна системная база по сетям. С неё начинается путь сетевого инженера и работа системного администратора. Курсы по этой теме собраны в каталоге «Сетевые технологии»:
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Профессия «Сетевой инженер» Перейти на сайт курса |  Нетология | 85 800 ₽ | 3575 ₽/мес. | 12 месяцев | Обзор курса |
| Сетевые технологии Перейти на сайт курса |  Merion | 21 840 ₽ | 1578 ₽/мес. | 2 месяца | Обзор курса |
| Сетевые технологии Huawei Перейти на сайт курса | Merion | 11 830 ₽ | 938 ₽/мес. | 2 месяца | Обзор курса |
| Управление и администрирование сетевых устройств информационно-коммуникационных систем Перейти на сайт курса |  Дипломикс | 10 900 ₽ | 818 ₽/мес. | Обзор курса | |
| Учебная программа “Кибербезопасность и Сетевые технологии” Перейти на сайт курса |  Академия ТОП | Бесплатно | - | 2 года | Обзор курса |
Больше программ — в полном каталоге курсов по сетевым технологиям
