Kameros transliacijos publikavimas: RTSP ir HLS nėra ta pati briauna

Jūs atidarote vieną kameros prievadą, nukreipiate į jį grotuvą ir manote, kad interneto problema išspręsta. Tada telefonas negali jo atkurti, naršyklė negali jo atkurti, o kameros administravimo puslapis nuo viešojo krašto yra tik vieno neteisingai įrašyto kelio atstumu. Pasirinktas pristatymo modelis, RTSP arba HLS, nusprendžia didžiąją dalį to, dar neparašius nė vienos ugniasienės taisyklės. VPN tepristato tik privatų ruožą.

VPN sutvarko šaltinio kelią, o ne žiūrovo kelią

VPS, tuneliu prijungtas prie kameros LAN tinklo, gali pasiekti kamerą jos privačiu adresu, ir tai tikrai naudinga. Tai reiškia, kad kamerai nereikia savo įeinančio prievado, o namų maršrutizatorius lieka uždarytas. Tai nepasako, kokia kalba kalbės žiūrovas. Darbalaukio grotuvas, naršyklė, telefonas ir išmanusis televizorius palaiko skirtingus protokolus, ir kiekvienas turi savo lūkesčius dėl TLS, autentifikavimo ir kodekų.

Štai prielaida, kurios verta atsisakyti: publikavimas neva reiškia šaltinio pasiekiamumą. Publikavimas iš tikrųjų reiškia, kad apibrėžtai auditorijai suteikiamas palaikomas būdas vartoti mediją. Paskelbta transliacija turi formatą, auditoriją ir prisijungimo duomenis; pasiekiama kamera neturi nė vieno iš jų. Pasiekiamumas yra ta dalis, kurią išsprendžia tunelis, o žiūrovo įėjimo taškas yra ta dalis, kurią dar turite suprojektuoti.

RTSP yra derybos, o ne vienas prievadas

RTSP perduoda sesijos valdymą: klientas paprašo aprašymo, nustato vieną ar daugiau medijos takelių ir tada atkuria. Pačios medijos transportavimas derinamas to nustatymo metu, todėl protokolo nelabai apibūdina vienas persiunčiamas TCP prievadas. Tos derybos yra ta dalis, kurią žmonės praleidžia lygindami ugniasienės taisykles.

Priklausomai nuo galinių taškų, RTP gali atkeliauti atskirais UDP prievadais arba būti supintas į valdymo ryšį. Relė, kuri persiunčia tik 554 ir mano, kad likusi dalis veiks, dažniausiai sukuria sesiją, kuri prisijungia, praneša takelį ir tada nieko nerodo. Patikrinkite transportavimą, dėl kurio jūsų kamera iš tikrųjų derasi, prieš rašydami jam taisykles. Įrašas privačioje pusėje atsako į tai per minutę, o spėliojimas kainuoja vakarą.

Mažai, žinomai auditorijai su suderinamais grotuvais sąmoningai sukonfigūruota RTSP relė gali būti teisingas atsakymas. Apribokite, iš kokio šaltinio ji gali traukti, ir reikalaukite autentifikavimo relėje. Užsirašykite grotuvus, kuriuos išbandėte, nes RTSP transliacija, veikianti VLC, naršyklėje vis tiek gali nepavykti.

HLS yra grojaraštis ir ištekliai

HLS žiūrovas gauna grojaraštį, o paskui gauna medijos segmentus, kuriuos tas grojaraštis įvardija. HLS specifikacija apibrėžia tą išteklių modelį, o svarbi operacinė detalė yra ta, kad grojaraščiai nurodo kitus URL. Santykinės nuorodos sprendžiamos grojaraščio vietos atžvilgiu, todėl tarpinė programa, perrašanti kelius, turi juos perrašyti nuosekliai.

Jei kamera jau teikia tinkamą HLS, viešoji priekinė dalis gali persiųsti tuos grojaraščio ir segmentų prašymus per tunelį. Stebėkite raktus, peradresavimus ir URL, kuriuos generuoja programa. Bet kuris absoliutus URL, nurodantis į privatų mazgą, sugenda tą akimirką, kai žiūrovas už LAN ribų juo seka. Santykiniai keliai yra tie, kurie išgyvena tarpinės programos perrašymą, todėl teikite jiems pirmenybę ten, kur valdote generuojamą išvestį.

Jei kamera kalba tik RTSP, kažkas turi konvertuoti šaltinį į žiūrovo formatą. Perpakavimas ir perkodavimas yra skirtingi darbai: perpakavimas išsaugo kodeką, o perkodavimas jį perkoduoja dėl suderinamumo, ir tik antrasis kainuoja rimtai procesoriaus laiko. Nė vienas netampa būtinas vien todėl, kad kelyje yra VPN.

Planuokite išsiuntimo liniją pagal tai, kur vyksta platinimas. Vienas privatus srautas, maitinantis viešą medijos paslaugą, elgiasi visai kitaip nei kiekvienas žiūrovas, traukiantis savo transliaciją per tunelį. Antrasis modelis dažniausiai baigiasi perkrauta namų jungtimi ir kamera, kuri atrodo atsitiktinai sugenda.

Dėkite autentifikavimą į tą kraštą, kurį publikuojate

TLS, žiūrovų autentifikavimas ir prieigos registravimas priklauso viešajam įėjimo taškui, o ne kamerai. Tai atskiria kameros prisijungimo duomenis nuo transliacijos prisijungimo duomenų. Tai taip pat suteikia vieną vietą, kur atšaukti prieigą, kai auditorijos narys išeina. Tų kontrolių dėjimas į kamerą reiškia, kad kiekvienas auditorijos pakeitimas tampa administraciniu pakeitimu įrenginyje, kuris niekada neturėtų būti viešai pasiekiamas.

Laikykite VPN ir kameros administravimo teises atskirai nuo publikavimo kelio. VPS, kuris gali pasiekti kameros žiniatinklio sąsają transliacijai traukti, neturėtų būti ir mašina, kuri atveria tą sąsają. Auditorija niekada neturėtų sužinoti kameros adreso.

Tada patikrinkite abu galus, kuriuos iš tikrųjų sukūrėte, o ne manykite, kad grandinė veikia:

$ 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

Sėkmingas privataus šaltinio patikrinimas ir sėkmingas grojaraščio gavimas viešajame krašte įrodo skirtingas projekto puses. Išbandykite juos atskirai. Atkūrimas iš tokio paties tipo kliento, kokį naudoja jūsų auditorija, yra vienintelis bandymas, apimantis visą grandinę.

Galų gale turite grandinę, kurios kiekviena grandis turi tikslą: privatus šaltinis, apribotas srautas, pasirinktas pakavimas, įgaliotas žiūrovo įėjimas. Nė viena iš tų grandžių nėra pasirenkama, ir nė viena neatsiranda atidarius prievadą.