Протокол rtsp, ніж відкрити. Як підключитися до IP-камери в клієнтській програмі TrueConf для Windows? Дізнаємось адресу RTSP камери відеоспостереження

Перетворює даний продуктпрактично універсальне рішеннядля перегляду відео незалежно від джерела. Примітною можливістю, яку надає програвач, є відтворення RTSP-потоку. Про те, як працює даний функціонал, піде мова нижче.

Програвання в плеєрі VLC RTSP, а також можливість захоплення потоку – дуже потрібні функції серед користувачів систем відеоспостереження, у складі яких є IP-камери.

Застосування

Більшість сучасних моделейкамер відеоспостереження, а також відеореєстраторів оснащені підтримкою протоколу, що описується. Додавши до цих апаратних складових такий надійний програмний інструмент, як VideoLAN Clientможна здійснити організацію системи для перегляду та збереження відеоінформації без залучення професіоналів у цій сфері.

Real Time Streaming Protocol– це прикладний потоковий протокол, який описує команди, які служать, щоб керувати відеопотоком. Команди можуть вказати IP-камері чи серверу здійснювати різні діїНаприклад, почати транслювати потік, або зупинити передачу відео.

У параметрах IP-камер може зустрічатися різне позначення потокового варіанта передачі. RTSPЯк було сказано вище, є по суті набором команд, за допомогою якого здійснюється управління потоком. Абревіатури UDP та RTPвказують на транспортний механізм, який застосовується при передачі відео.

Відкриття RTSP-потоку VLC.

Щоб потік з камери відображався у вікні програвача, потрібно попереднє налаштуванняВЛЦ. Виконуємо нижче наведені пункти інструкції.


Таким простим способомможе здійснюватись організація перегляду камер у системах відеоспостереження.

Протокол RTSP

RTSP (Real Time Streaming Protocol, або, російською, потоковий протокол реального часу) – це прикладний протокол, в якому описані команди для управління потоком відео. За допомогою цих команд ми можемо наказати камері або серверу, наприклад, почати трансляцію відеопотоку. Приклад запиту на початок відтворення має такий вигляд: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

Тобто RTSP – це просто набір команд управління відеопотоком. Проведемо експеримент. Для цього нам знадобиться IP-камера з підтримкою RTSP протоколу та її адресу RTSP. Ця адреса виглядає приблизно так rtsp:// / mpeg. Його можна дізнатися з посібника з експлуатації камери або опису API. Для зручності ми наведемо RTSP адреси для ряду популярних камерв таблиці. Після того, як ми дізналися RTSP-адресу камери, відкриваємо стандартний програвач, який підтримує RTSP. Це може бути одна з наступних програм: Windows Media Player, QuickTime, Media Player Classic, VLC media Player, RealPlayer, MPlayer. Ми обрали QuickTime. Відкриваємо меню «Файл > Відкрити URL» та вводимо нашу RTSP адресу. Після чого QuickTime підключиться до камери та відтворить «живе відео». Пристрої запису, що працюють в системах IP-відеоспостереження, отримують відео від камер або за допомогою протоколу HTTP - тобто, як ми завантажуємо JPEG-картинки з сайтів, або у вигляді потоку через RTSP - тобто як ми отримали його за допомогою стандартного плеєра в останньому прикладі. У настройках IP-камер потоковий варіант передачі може позначатися як RTSP over TCP, RTSP over UDP чи навіть RTP. Отже, RTSP – це набір команд управління потоком. Але що означають інші абревіатури: TCP, UDP, RTP? TCP, UDP та RTP – це транспортні механізми (протоколи), які власне і передають відео.

Протокол TCP

Допустимо, ми вибрали метод RSTP over TCP і хочемо розпочати передачу відеопотоку. Що відбуватиметься на рівні транспортних механізмів? Попередньо за допомогою кількох команд буде встановлено з'єднання між відправником та одержувачем. Після цього розпочнеться передача відео. При цьому механізми TCP

стежитимуть за тим, щоб усі дані дійшли до адресата без змін та у потрібній послідовності. Також TCP регулюватиме швидкість передачі, щоб передавач не посилав дані інтенсивніше, ніж їх може обробити приймач, наприклад,

UDP – це альтернатива транспортному протоколу TCP. На відміну від TCP, UDP не встановлює попереднього з'єднання, а натомість просто починає передавати дані. UDP не слідкує за тим, щоб дані були отримані та не дублює їх, якщо окремі частини зникли або прийшли з помилками. UDP менш

надійний, ніж TCP. Але з іншого боку, він забезпечує більш швидку передачупотоків завдяки відсутності механізму повторення передачі втрачених пакетів. Відмінність протоколів TCP і UTP можна ілюструвати наступним прикладом. Зустрічаються двоє друзів. Варіант TCP:

Іван: «Привіт! Побалакаємо?» (Встановлюється з'єднання)
Семен: «Привіт! Давай!» (Встановлюється з'єднання)
Іван: «Я вчора був у магазині. Ти зрозумів?" (передача даних)
Семен: «Так!» (Підтвердження)
Іван: Там розвантажували нове обладнання. Ти зрозумів?" (передача даних)
Семен: "Ні" (підтвердження)
Іван: Там розвантажували нове обладнання. Ти зрозумів?" (повторна передача)
Семен: «Так!» (Підтвердження)
Іван: «Завтра я там ще раз буду. Ти зрозумів?" (передача даних)
Семен: «Так!» (Підтвердження)
Варіант UDP
Іван: «Привіт! Я вчора був у магазині» (передача даних)
Іван: "Там розвантажували нове обладнання" (передача даних)
Іван: "Завтра я там ще раз буду" (передача даних)
Іван: «Можу дізнатися для тебе ціни» (передача даних)
Іван: «Вони обіцяли знижки при хороших обсягах" (передача даних)
Іван: «Якщо хочеш, подзвони – поїдемо разом» (передача даних)
Семен: «Так, подзвоню» (передача даних)

Ви також можете побачити різницю в протоколах, поставивши наступний експеримент: спробуйте перевести камеру в режим RTSP over TCP і помахати рукою перед об'єктивом - на екрані монітора ви побачите затримку. А тепер проведіть цей тест у режимі RTSP over UDP. Затримка буде меншою. На час затримки впливають кілька факторів: формат стиснення, потужність комп'ютера, протокол передачі та особливості програмного забезпечення, що бере участь у декодуванні відео.

RTP (Real-time Transport Protocol), або російською транспортний протоколреального часу Цей протокол спеціально створено передачі реалтайм трафіку. Він дозволяє стежити за синхронізацією даних, що передаються, коригувати послідовність доставки пакетів і тому більше інших підходить для передачі відео-і аудіоданих. В загальному випадку для передачі відеопотоку краще використовувати або RTP або UDP. Робота через TCP виправдана лише якщо нам доводиться працювати з проблемними мережами, оскільки протокол TCPзможе коригувати помилки та збої, що виникають під час передачі даних.

У посібнику, що постачається разом із камерою відеоспостереження, не завжди може бути інформація про протокол RTSP, згідно з яким пристрій функціонує. Однак існує велика кількістьвипадків, коли потрібно використовувати цей протокол, тому виникає потреба впізнавати його адресу.

Власнику системи відеоспостереження може знадобитися знання RTSP-потоку в різних ситуаціях:

  • щоб підключити відеокамеру до сервера хмар;
  • щоб настроїти передачу відеоінформації на інтернет-сайт;
  • щоб програвати відео в потоці плеєра на різних пристрояхмобільному телефоні, ноутбук або планшет.

Навіщо потрібен протокол RTSP?

Назва протоколу RTSP перекладається управління онлайн-режиме. Таким чином, Real Time Streaming Protocol допомагає налагодити керування потоковим відео онлайн. Цей протоколдуже часто використовується в IP-відеоспостереженні, оскільки там є опис необхідних команд.

RTSP-протокол дозволяє власнику камери стеження вирішувати кілька важливих функцій:

  • транслювати дані за допомогою VLC;
  • транслювати відео на свої ресурси та майданчики;
  • налаштовувати NVR-відеореєстратори;
  • з'єднувати камеру відеоспостереження з віртуальним сховищем;
  • додавати відеокамеру в мобільні додаткина базі Androidабо iOS.

При цьому відкрити RTSP-потік багатьом користувачам систем відеоспостереження не дуже просто і досить важко.

Дізнаємось адресу RTSP камери відеоспостереження

Є кілька варіантів, які дозволяють дізнатися RTSP потіквідеокамери, коли він не вказаний у відповідній інструкції.

Велика кількість IP-відеокамер, які продаються в Росії, мають китайські елементи XMEye. Дані комплектуючі можна побачити навіть у вітчизняних виробниківтаких камер, як Vesta, HiQ, SVplus та подібних. Камера подібних моделей матиме наступний формат RTSP-потоку:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

У даною адресоюприсутні такі складові, як:

  • 192.168.132.32 – безпосередньо IP-адреса пристрою;
  • 554 – порт протоколу (за замовчуванням він має номер 554, але цей параметр можна змінити у налаштуваннях пристрою);
  • admin – логін камери відеоспостереження;
  • 12355 – пароль від логіну користувача.

У тому випадку, коли в IP-відеокамері присутні інші комплектуючі, необхідно буде скористатися одним із двох наведених нижче варіантів.

Перший варіант – найспрощеніший. Щоб дізнатися RTSP-потік з камери відеоспостереження, необхідно зв'язатися з виробником або постачальником даного пристрою. На запит вони зможуть надати формат потрібного потоку, причому цю послугуможуть надати навіть китайські продавці – з фабрик із Китаю або сайту AliExpress.

Другий варіант – використовувати спеціалізоване програмне забезпечення. Цей спосіб зможе виручити в тому випадку, коли власник системи відеоспостереження не має можливостей або бажання запросити адресу RTSP-потоку у постачальника. Тоді можна буде зробити це власноруч за допомогою софту.

Для початку потрібно буде завантажити програму під назвою One Device Manager. Після встановлення даний софтдопоможе дізнатися RTSP-адресу.

Як правило, більшість відеокамер має підтримку onvif-протоколу, тому при експлуатації програмного забезпечення труднощів виникнути не повинно. Важливий нюанс– для правильної роботи необхідно підключити ноутбук або комп'ютер, куди буде встановлена ​​програма, а також сам IP-пристрій до однієї локальної мережі.

У мережі можна знайти цілі списки, де містяться адреси RTSP-потоків, оскільки ці дані залежать від того, який бренд випускає камеру відеоспостереження.

Як відкрити RTSP-потік у відеокамері?

Коли адреса RTSP-потоку стає відома власнику системи стеження, вона може отримувати відеоінформацію з IP-камери. Щоб відкрити трансляцію потокового відео, необхідно буде виконати наступний перелік кроків:

  • встановити для відеокамери постійна IP-адресата замовити його у постачальника інтернету;
  • перекинути на RTSP-порт локальні запити, що надходять із відеокамери;
  • пройти перевірку працездатності.

Статичну адресу можна налаштувати за допомогою програми IP Hunter або ж зв'язатися з провайдером і попросити її забезпечити як додаткової опціїпостійна адреса IP. Після цього потрібно налаштувати переадресацію та прокинути порти на RTSP-порт з локальних портів відеокамери. Потім можна переходити до перевірки потоку.

Щоб зрозуміти, чи має RTSP-посилання працездатність, можна відкрити VLC-плеєр і зробити там перевірку. Для цього в головному меню плеєра потрібно натиснути на категорію Медіа і вибрати пункт Відкрити URL. Далі потрібно перейти на вкладку «Мережа» віконця «Джерело» та вказати своє посилання.

Очевидно, що достатня кількість користувачів «потокових» мультимедійних послуг бажають або бажатимуть використовувати такі стандартні системи домашнього відеоі DVD функції, як "пауза", "перемотування вперед/назад" і т.п. Як було зазначено у п. 1.2.2 цього розділу, реалізація додаткових протоколів дозволить повністю задовольнити запити найвибагливішого користувача.

На момент написання книги найпоширенішим протоколом, що швидко розвивається, на основі якого реалізуються згадані вище функції, є «протокол для потокових даних реального часу» RTSP (Real-Time Streaming Protocol) визначений в .

Головною функцієюПротоколом RTSP є можливість управління «потоковим» додатком. Функції управління реалізовані в програмному продукті, Здійснює відтворення аудіо та/або відеоінформації, що надходить з боку сервера, тобто. медіаплеєру. Управління здійснюється шляхом обміну керуючими повідомленнями між сервером та клієнтом. Керуючі повідомлення протоколу RTSP не належать до інформаційних з'єднань та потоків між сервером та клієнтом - вони використовують окреме з'єднанняабо потік з номером порту 544, тому цей протокол називається виділеним (out-of-band). Аналогію для керуючих повідомлень RTSP можна провести з керуючим каналом протоколі FTP. Специфікація RTSP дозволяє використовувати на транспортному рівнідля своїх лакетів як протокол TCP, і UDP.

На рис. 1.27 наведено приклад взаємодії клієнта та сервера за допомогою протоколу RTSP. Розглянемо випадок, коли кінцевий користувач на стороні клієнта використовує стандартний браузер(browser) для перегляду гіпертекстової інформації з мережі та через нього ініціює перегляд «потокового» відео з звуковим супроводом. В результаті процедури ініціювання (фізично це може бути просто клацання мишею на відповідне гіперпосилання) браузер посилає веб-серверу запит про параметри об'єкта (презентації), що знаходиться за гіперпосиланням (у нашому випадку це – «потокове» відео зі звуковим супроводом), внаслідок чого веб-сервер надсилає файл опису презентації (presentation description), приклад якого наведено на рис. 1.26 , Взаємодія здійснюється через протокол HTTP, Цей файл може містити як посилання на кілька «потокових» файлів, так і директиви щодо їх синхронізації. Кожне посилання на «потоковий» файл має починатися з методу URL rtsp://.

Зазначимо, що фізично «потокові» файли можуть знаходитися на іншому сервері, який називається «медіа-сервером» ( media server). У прикладі аудіо і відеопотоки повинні відтворюватися паралельно на стороні клієнта в режимі lip sync (синхронізація між аудіо і відеопотоками), причому медіаплеєр має можливість вибору в якій якості має відтворюватися аудіосупровід - на стороні медіа-сервера доступно два аудіопотоку різної якості: високого ni fi та низького lofi. Зазначимо, що приклад передбачається використання відомого формату SMIL для файлів аудіопотоку. Цей формат використовується для синхронізації між різними потоками багатьма комерційними продуктами.

Мал. 1.26. Приклад метакоду "файл опису презентації"

Після прийняття від веб-сервера файлу опису презентації на стороні клієнта браузер повинен надіслати запит на завантаження в оперативну пам'ятьлокального медіаплеєра, здатного відтворювати аудіо та відеопотоки заданого формату. Далі, як показано на рис. 1.27, медіаплеєр на стороні клієнта та медіа-сервер обмінюються рядом повідомлень RTSP. Медіаплеєр надсилає медіа-серверу повідомлення запиту встановлення RTSP-з'єднання RTSP SETUP, відповідь на яке є повідомлення про підтримку цього з'єднання RTSP ОК.

Повідомлення RTSP SETUP містить інформацію про номер порту клієнта, куди мають бути адресовані пакети потокового файлу. Потім медіаплеєр надсилає запит RTSP PLAY на початок передачі «потокового» файлу, нехай, у нашому випадку, це аудіо низької якості lofi. Після отримання цього запиту медіа-сервер починає надсилати медіаплеєру, що знаходиться на стороні клієнта, пакети, що містять необхідну аудіоінформацію.

Далі на рис. 1.27 показаний приклад реалізації функції "пауза" - для припинення посилки пакетів "потокового" аудіо медіаплеєр повинен надіслати повідомлення RTSP PAUSE, а медіа-сервер повинен відповісти повідомленням RTSP ОК. Якщо користувач вирішує закінчити прослуховування/перегляд, має бути ініційовано руйнування RTSP-з'єднання, для чого медіаплеєр надсилає медіа-серверу повідомлення RTSP TEARDOWN, а медіа-сервер повинен відповісти повідомленням RTSP ОК.

Протокол RTSP не включає rs наступні функції:

Визначення схем та алгоритмів компресії для аудіо та відео;

Визначення яким чином аудіо та відеоінформація інкапсулюється в пакети для передачі через мережу; ця функція може бути реалізована в протоколі RTPабо у «корпоративному протоколі» виробника програмного забезпечення програми.

Наприклад, в програмних реалізаціяхяк медіа-сервера, так і клієнта фірми RealNetworks для обміну службовою інформацією використовується протокол RTSP, а аудіо та відеоінформація інкапсулюється через протокол RTP;

Визначення який транспортний протокол використовується для перенесення пакетів "з-кінця-на-кінець" - може використовуватися як UDP, так і TCP;

Обмеження яким чином здійснюється буферизація аудіо та відеопотоків на стороні клієнта - відтворення може бути розпочато як відразу після отримання першого пакета, через деякий час з метою здійснення буферизації для боротьби з дисперсією затримки пакетів, так і після того, як вся інформація буде збережена на стороні клієнта.

Найсвіжіша та повна інформаціяПро протокол RTSP можна знайти в Інтернеті за адресою

Матеріал з Вікіпедії – вільної енциклопедії

Потоковий протокол реального часу(англ. real time streaming protocol, скор. RTSP ) - прикладний протокол , призначений для використання в системах, що працюють з мультимедійними даними (мультимедійним вмістом, медімістмістом), і дозволяє віддалено управляти потоком даних з сервера, надаючи можливість виконання команд, таких як запуск (старт), призупинення (пауза) та зупинку (стоп) мовлення (програвання) мультимедійного вмісту, а також доступу часу до файлів, розташованих на сервері. Розроблений IETF у 1998 році та описаний у RFC 2326 .

RTSP не виконує стиснення, а також не визначає метод інкапсуляції мультимедійних даних та транспортні протоколи. Передача потокових даних як така перестав бути частиною протоколу RTSP. Більшість серверів RTSP використовують для цього стандартний транспортний протокол реального часу, що здійснює передачу аудіо- та відео.

Опис

За синтаксисом та операціями протокол схожий на HTTP. Однак між протоколами RTSP та HTTP є ряд суттєвих відмінностей. Одне з основних у тому, що у першому і сервер, і клієнт здатні генерувати запити. Наприклад, відеосервер може надіслати запит для встановлення параметрів відтворення певного відеопотоку. Також протоколом RTSP передбачається, що керування станом чи зв'язком має здійснювати сервер, тоді як HTTP взагалі ніякого відношення до цього не має. Нарешті, в RTSP дані можуть передаватися поза основною смугою (англ. out of band) іншими протоколами, наприклад RTP, що неможливо у разі HTTP.

RTSP-повідомлення надсилаються окремо від мультимедійного потоку. Для них використовується з'єднання за спеціальним портом, за замовчуванням з номером 554. Запит на сервер надсилається в текстовому виглядіу форматі: метод<абсолютный_адрес> <версия_протокола>. Разом із запитом можуть бути передані додаткові службові поля (на нових рядках запиту).

Методи протоколу:

  • describe - запит опису вмісту, наприклад, у форматі SDP;
  • options - запит підтримуваних методів;
  • play – запит початку мовлення вмісту;
  • pause – запит тимчасової зупинки мовлення;
  • record – запит на записування вмісту сервером;
  • redirect - перенаправлення на інший вміст;
  • setup – запит встановлення транспортного механізму для вмісту;
  • announce – оновлення даних опису вмісту;
  • get_parameter - запит вказаних параметріву сервера;
  • set_parameter – встановлення параметрів сервера;
  • teardown - зупинка потоку та звільнення ресурсів.

Приклад запиту: PLAY rtsp://example.com/video/test.mpg/streamid=0 RTSP/1.0