Објавување на стрим од камера: RTSP и HLS не се иста ивица

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

VPN го поправа патот на изворот, не патот на гледачот

VPS поврзан со LAN-от на камерата преку тунел може да ја достигне камерата на нејзината приватна адреса, и тоа е навистина корисно. Тоа значи дека камерата не и е потребен сопствен влезен порт и дека рутерот во домот останува затворен. Тоа не ви кажува на кој јазик ќе зборува гледачот. Десктоп плеер, прелистувач, телефон и паметен телевизор поддржуваат различни протоколи, и секој има свои очекувања за TLS, автентикација и кодеци.

Еве претпоставка што вреди да се отфрли: објавувањето би значело да се направи изворот достапен. Објавувањето всушност значи да се даде на дефинирана публика поддржан начин да го консумира медиумот. Објавен тек има формат, публика и пристапни податоци; достапна камера нема ниту едно од тоа. Достапноста е делот што го решава тунелот, а влезната точка на гледачот е делот што допрва треба да го дизајнирате.

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

RTSP носи контрола на сесијата: клиентот бара опис, поставува една или повеќе медиумски патеки и потоа репродуцира. Преносот на самиот медиум се преговара за време на тоа поставување, поради што протоколот не е добро опишан со еден проследен TCP порт. Тоа преговарање е делот што луѓето го пропуштаат кога ги споредуваат правилата за огнен ѕид.

Во зависност од крајните точки, RTP може да пристигне на одделни UDP порти или да биде испреплетен на контролната врска. Реле што проследува само 554 и претпоставува дека остатокот ќе работи обично создава сесија што се поврзува, пријавува патека и потоа не прикажува ништо. Проверете го преносот за кој вашата камера навистина преговара пред да напишете правила за него. Снимање на приватната страна го одговара тоа за една минута, а погодувањето чини вечер.

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

HLS е плејлиста плус ресурси

Гледач на HLS презема плејлиста, а потоа ги презема медиумските сегменти што таа плејлиста ги именува. Спецификацијата HLS го дефинира тој модел на ресурси, а важниот оперативен детаљ е дека плејлистите упатуваат на други URL-а. Релативните референци се разрешуваат во однос на локацијата на плејлистата, па проксито што препишува патеки мора да ги препишува доследно.

Ако камерата веќе служи употреблив HLS, јавниот фронтенд може да ги проследува тие барања за плејлиста и сегменти низ тунелот. Внимавајте на клучеви, пренасочувања и URL-а што ги генерира апликацијата. Секој апсолутен URL што упатува на приватен домаќин се крши во моментот кога гледач надвор од LAN-от ќе го следи. Релативните патеки се тие што преживуваат препишување од проксито, па дајте им предност каде и да го контролирате генерираниот излез.

Ако камерата зборува само 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

Успешната проверка на приватниот извор и успешното преземање на плејлистата на јавниот раб докажуваат различни половини од дизајнот. Тестирајте ги одделно. Репродукцијата од ист вид клиент што го користи вашата публика е единствениот тест што го покрива целиот синџир.

Она што на крајот го имате е синџир со цел во секоја алка: приватен извор, ограничен внес, избрано пакување, овластен влез за гледачот. Ниту една од тие алки не е опционална и ниту една не настанува со отворање порт.