In kamera-stream publisearje: RTSP en HLS binne net deselde râne

Jo iepenje ien poarte fan 'e kamera, rjochtsje in spiler derop en nimme oan dat it internetprobleem oplost is. Dan kin in telefoan it net ôfspylje, kin in browser it net ôfspylje, en de behearderside fan 'e kamera is mar ien ferkeard typte paad fan 'e iepenbiere râne ôf. It leveringsmodel dat jo keazen hawwe, RTSP of HLS, bepaalt it measte dêrfan foardat der ek mar ien firewallregel skreaun wurdt. De VPN leveret allinnich it partikuliere skonk.

De VPN reparearret it boarnepaad, net it paad fan 'e sjogger

In VPS dy't fia in tunnel oan 'e LAN fan 'e kamera ferbûn is, kin de kamera op har partikuliere adres berikke, en dat is echt nuttich. It betsjut dat de kamera gjin eigen ynkommende poarte nedich hat en dat de hûsrûter ticht bliuwt. It fertelt jo net hokker taal in sjogger prate sil. In buroblêdspiler, in browser, in telefoan en in tillefyzje mei ferstân stypje ferskate protokollen, en elk hat syn eigen ferwachtingen oer TLS, ferifikaasje en kodeks.

Hjir is de oanname dy't it wurdich is om los te litten: publisearjen soe betsjutte dat de boarne berikber makke wurdt. Publisearjen betsjut eins dat in definiearre publyk in stipe manier krijt om it medium te konsumearjen. In publisearre stream hat in formaat, in publyk en in referinsje; in berikbere kamera hat gjin fan dy trije. Berikberens is it diel dat de tunnel oplost, en it yngongspunt fan 'e sjogger is it diel dat jo noch ûntwerpe moatte.

RTSP is in ûnderhanneling, net ien poarte

RTSP draacht sesjebehear: in klant freget in beskriuwing, set ien of mear mediabaannen op en spilet dan ôf. It ferfier fan 'e media sels wurdt yn dy opset ûnderhannele, dêrom wurdt it protokol net goed beskreaun troch ien trochstjoerde TCP-poarte. Dy ûnderhanneling is it diel dat minsken misse as se firewallregels fergelykje.

Ofhinklik fan 'e einpunten kin RTP op aparte UDP-poarten oankomme of op 'e kontrôleferbining ferweve wurde. In relais dat allinnich 554 trochstjoert en oannimt dat de rest wurkje sil, leveret meastentiids in sesje op dy't ferbynt, in baarn rapportearret en dan neat sjen lit. Kontrolearje it ferfier dat jo kamera echt ûnderhannelt foardat jo regels dêrfoar skriuwe. In opname oan 'e partikuliere kant beantwirdet dat yn in minút, en rieden kostet in jûn.

Foar in lyts, bekend publyk mei kompatibele spilers kin in doelbewust konfigurearre RTSP-relais it goede antwurd wêze. Behein fan hokker boarne it lûke mei en freegje ferifikaasje by it relais. Skriuw de spilers op dy't jo test hawwe, want in RTSP-stream dy't yn VLC wurket, kin noch altyd mislearje yn in browser.

HLS is in spyllist plus boarnen

In HLS-sjogger hellet in spyllist en hellet dan de mediasegmenten dy't dy list neamt. De HLS-spesifikaasje definiearret dat boarnemodel, en it wichtige operasjonele detail is dat spyllisten nei oare URL's ferwize. Relative ferwizings wurde tsjin de lokaasje fan 'e list oplost, dus in proxy dy't paden oerskriuwt, moat se konsekwint oerskriuwe.

As de kamera al brûkbere HLS leveret, kin in iepenbier frontend dy spyllist- en segmintfersiken troch de tunnel stjoere. Let op kaaien, trochferwizings en URL's dy't de applikaasje genereart. Eltse absolute URL dy't nei in partikuliere host wiist, brekt op it momint dat in sjogger bûten de LAN it folget. Relative paden binne dejingen dy't in oerskriuwing troch de proxy oerlibje, dus foarkarje se oeral wêr't jo de generearre útfier beheare.

As de kamera allinnich RTSP praat, moat der wat de boarne nei it formaat fan 'e sjogger omsette. Ferpakking en transkodearring binne ferskate taken: ferpakking behâldt de kodek, wylst transkodearring him foar kompatibiliteit weromkodearret, en allinnich it twadde kostet serieuze CPU. Gjint fan beide wurdt needsaaklik allinnich om't der in VPN op it paad is.

Plan de opgeande ferbining neffens it plak dêr't de fersprieding bart. Ien partikuliere yngong dy't in iepenbiere mediatsjinst fiedt, gedraacht him hiel oars as elke sjogger dy't syn eigen stream troch de tunnel lûkt. It twadde patroan einiget meastentiids yn in fersêde hûsferbining en in kamera dy't skynt samar te mislearjen.

Set ferifikaasje op 'e râne dy't jo publisearje

TLS, ferifikaasje fan sjoggers en tagongslogging hearre by it iepenbiere yngongspunt, net by de kamera. Dat hâldt de referinsjes fan 'e kamera apart fan 'e referinsjes fan 'e stream. It jout jo ek ien plak om tagong yn te lûken as in lid fan it publyk fuortgiet. Dy kontrôles op 'e kamera sette betsjut ynstee dat elke publykferoaring in administrative feroaring wurdt op in apparaat dat nea iepenbier berikber wêze moat.

Hâld de VPN en de behearrjochten fan 'e kamera apart fan it publikaasjepaad. In VPS dy't de webynterface fan 'e kamera berikke kin om in stream te lûken, moat net ek de masine wêze dy't dy ynterface bleatstelt. It publyk moat nea it adres fan 'e kamera leare.

Ferifiearje dan de beide einen dy't jo wier boud hawwe ynstee fan oan te nimmen dat de keten wurket:

$ 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

In suksesfolle ûndersyk fan 'e partikuliere boarne en in suksesfolle spyllistôfflaai oan 'e iepenbiere râne bewize ferskate helten fan it ûntwerp. Test se apart. Werjaan fan itselde soarte klant as jo publyk brûkt, is de iennichste test dy't de hiele keten dekt.

Wat jo úteinlik hawwe, is in keten mei in doel by elke skeakel: partikuliere boarne, beheind yngong, keazen ferpakking, autorisearre sjoggersyngong. Gjint fan dy skeakels is opsjoneel, en gjint wurdt makke troch in poarte te iepenjen.