Публикуване на поток от камера: RTSP и HLS не са един и същ ръб

Отваряте един порт на камерата, насочвате плейър към него и приемате, че проблемът с интернет е решен. После телефон не може да го възпроизведе, браузър не може да го възпроизведе, а административната страница на камерата е на една грешно въведена пътека от публичния ръб. Избраният модел на доставка, RTSP или HLS, решава голяма част от това, преди да е написано и едно правило на защитната стена. VPN осигурява само частния участък.

VPN поправя пътя на източника, а не пътя на зрителя

VPS, свързан с локалната мрежа на камерата чрез тунел, може да достигне камерата на нейния частен адрес, и това е наистина полезно. Това означава, че камерата не се нуждае от собствен входящ порт и домашният рутер остава затворен. Това не ви казва на какъв език ще говори зрителят. Настолен плейър, браузър, телефон и интелигентен телевизор поддържат различни протоколи и всеки има свои очаквания за TLS, удостоверяване и кодеци.

Ето допускането, което си струва да отхвърлите: публикуването уж означава да направите източника достъпен. Публикуването всъщност означава да дадете на определена аудитория поддържан начин да консумира медията. Публикуваният поток има формат, аудитория и идентификационни данни; достъпната камера няма нищо от това. Достъпността е частта, която тунелът решава, а входната точка на зрителя е частта, която тепърва трябва да проектирате.

RTSP е преговори, а не един порт

RTSP носи управление на сесията: клиентът иска описание, настройва една или повече медийни пътеки и след това възпроизвежда. Транспортът на самата медия се договаря по време на тази настройка, поради което протоколът не се описва добре с един пренасочен TCP порт. Тези преговори са частта, която хората пропускат, когато сравняват правила на защитната стена.

В зависимост от крайните точки RTP може да пристига на отделни UDP портове или да бъде вплетен в контролната връзка. Релей, който препраща само 554 и приема, че останалото ще работи, обикновено създава сесия, която се свързва, съобщава пътека и след това не показва нищо. Проверете транспорта, за който вашата камера действително се договаря, преди да напишете правила за него. Заснемане от частната страна отговаря на това за минута, а отгатването струва една вечер.

За малка, известна аудитория със съвместими плейъри умишлено конфигуриран RTSP релей може да е правилният отговор. Ограничете от кой източник може да дърпа и изисквайте удостоверяване на релея. Запишете плейърите, които сте тествали, защото поток RTSP, който работи във VLC, все още може да се провали в браузър.

HLS е плейлист плюс ресурси

Зрителят на HLS извлича плейлист и след това извлича медийните сегменти, които този плейлист именува. Спецификацията на HLS дефинира този модел на ресурси и важната оперативна подробност е, че плейлистите препращат към други URL адреси. Относителните препратки се разрешават спрямо местоположението на плейлиста, така че прокси, което пренаписва пътеки, трябва да ги пренаписва последователно.

Ако камерата вече сервира използваем HLS, публичен фронтенд може да препраща тези заявки за плейлист и сегменти през тунела. Следете за ключове, пренасочвания и URL адреси, генерирани от приложението. Всеки абсолютен URL адрес, сочещ към частен хост, се чупи в момента, в който зрител извън локалната мрежа го последва. Относителните пътеки са тези, които оцеляват при пренаписване от прокси, затова им давайте предимство навсякъде, където контролирате генерирания изход.

Ако камерата говори само RTSP, нещо трябва да преобразува източника във формата на зрителя. Препакетирането и транскодирането са различни задачи: препакетирането запазва кодека, докато транскодирането го прекодира за съвместимост, и само второто струва сериозен процесорен ресурс. Нито едно от двете не става необходимо само защото на пътя има VPN.

Планирайте изходящата връзка според това къде се случва разпределението. Едно частно приемане, което захранва публична медийна услуга, се държи съвсем различно от всеки зрител, който дърпа собствения си поток през тунела. Вторият модел обикновено завършва със наситена домашна връзка и камера, която изглежда да отказва случайно.

Поставете удостоверяването на ръба, който публикувате

TLS, удостоверяването на зрителите и журналирането на достъпа принадлежат на публичната входна точка, а не на камерата. Това държи идентификационните данни на камерата отделно от данните на потока. Това също ви дава едно място за отнемане на достъп, когато член на аудиторията си тръгне. Поставянето на тези контроли върху камерата вместо това означава, че всяка промяна на аудиторията става административна промяна на устройство, което никога не би трябвало да бъде публично достъпно.

Дръжте VPN и административните права на камерата отделно от пътя на публикуване. VPS, който може да достигне уеб интерфейса на камерата, за да дърпа поток, не трябва да бъде и машината, която излага този интерфейс. Аудиторията никога не трябва да научава адреса на камерата.

След това проверете двата края, които действително сте изградили, вместо да приемате, че веригата работи:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

Успешната проверка на частния източник и успешното извличане на плейлиста на публичния ръб доказват различни половини от проекта. Тествайте ги поотделно. Възпроизвеждането от същия тип клиент, който използва вашата аудитория, е единственият тест, който покрива цялата верига.

Това, което в крайна сметка имате, е верига с предназначение във всяко звено: частен източник, ограничено приемане, избрано пакетиране, оторизиран вход на зрителя. Нито едно от тези звена не е незадължително и нито едно не се създава чрез отваряне на порт.