Botimi i një transmetimi nga kamera: RTSP dhe HLS nuk janë i njëjti kufi

Hapni një port të kamerës, drejtoni një luajtës drejt tij dhe supozoni se problemi i internetit është zgjidhur. Më pas një telefon nuk mund ta luajë atë, një shfletues nuk mund ta luajë atë, dhe faqja e administrimit të kamerës ndodhet vetëm një shteg të shtypur gabim nga kufiri publik. Modeli i dërgimit që zgjodhët, RTSP ose HLS, vendos pjesën më të madhe të kësaj përpara se të shkruhet ndonjë rregull muri zjarri. VPN-ja siguron vetëm segmentin privat.

VPN-ja rregullon shtegun e burimit, jo shtegun e shikuesit

Një VPS i lidhur me rrjetin LAN të kamerës përmes një tuneli mund ta arrijë kamerën në adresën e saj private, dhe kjo është vërtet e dobishme. Kjo do të thotë se kamera nuk ka nevojë për një port hyrës të vetin dhe ruteri i shtëpisë mbetet i mbyllur. Kjo nuk ju tregon se çfarë gjuhe do të flasë një shikues. Një luajtës desktopi, një shfletues, një telefon dhe një televizor inteligjent mbështesin protokolle të ndryshme, dhe secili ka pritshmëritë e veta për TLS, vërtetimin dhe kodekët.

Këtu është supozimi që ia vlen të hidhet poshtë: botimi do të thoshte ta bësh burimin të arritshëm. Botimi në të vërtetë do të thotë t'i japësh një publiku të përcaktuar një mënyrë të mbështetur për të konsumuar mediat. Një transmetim i botuar ka një format, një publik dhe një kredencial; një kamera e arritshme nuk ka asnjë prej tyre. Arritshmëria është pjesa që zgjidh tuneli, dhe pika e hyrjes së shikuesit është pjesa që ju duhet ende të projektosh.

RTSP është një negociim, jo një port i vetëm

RTSP mbart kontrollin e sesionit: një klient kërkon një përshkrim, konfiguron një ose më shumë gjurmë mediash dhe më pas luan. Transporti për vetë mediat negociohet gjatë asaj konfigurimi, prandaj protokolli nuk përshkruhet mirë nga një port i vetëm TCP i përcjellë. Ky negociim është pjesa që njerëzit e humbasin kur krahasojnë rregullat e murit të zjarrit.

Në varësi të pikave fundore, RTP mund të mbërrijë në porte të veçanta UDP ose të jetë i ndërthurur në lidhjen e kontrollit. Një rele që përcjell vetëm 554 dhe supozon se pjesa tjetër do të funksionojë zakonisht prodhon një sesion që lidhet, raporton një gjurmë dhe më pas nuk shfaq asgjë. Kontrolloni transportin që kamera juaj negocion vërtet përpara se të shkruani rregulla për të. Një regjistrim në anën private e përgjigj këtë në një minutë, dhe hamendja kushton një mbrëmje.

Për një publik të vogël dhe të njohur me luajtës të pajtueshëm, një rele RTSP e konfiguruar qëllimisht mund të jetë përgjigja e duhur. Kufizoni se nga cili burim mund të tërheqë dhe kërkoni vërtetim në rele. Shkruani luajtësit që testuat, sepse një transmetim RTSP që funksionon në VLC mund të dështojë gjithsesi në një shfletues.

HLS është një listë luajtjeje plus burime

Një shikues HLS merr një listë luajtjeje, pastaj merr segmentet e mediave që kjo listë i emërton. Specifikimi HLS përcakton atë model burimesh, dhe detaji i rëndësishëm operacional është se listat e luajtjes referojnë URL të tjera. Referencat relative zgjidhen në lidhje me vendndodhjen e listës, kështu që një proxy që rishkruan shtigjet duhet t'i rishkruajë ato në mënyrë konsekuente.

Nëse kamera tashmë ofron HLS të përdorshëm, një frontend publik mund t'i përcjellë ato kërkesa për listë dhe segmente përmes tunelit. Kushtojini vëmendje çelësave, ridrejtimeve dhe URL-ve që gjeneron aplikacioni. Çdo URL absolute që tregon një host privat prishet në momentin që një shikues jashtë LAN-it e ndjek. Shtigjet relative janë ato që i mbijetojnë rishkrimit nga proxy, prandaj preferojini ato kudo ku ju kontrolloni daljen e gjeneruar.

Nëse kamera flet vetëm RTSP, diçka duhet ta konvertojë burimin në formatin e shikuesit. Ripaketimi dhe transkodimi janë punë të ndryshme: ripaketimi e ruan kodekun, ndërsa transkodimi e rikodifikon atë për pajtueshmëri, dhe vetëm i dyti kushton CPU serioze. Asnjëra nuk bëhet e nevojshme vetëm sepse një VPN është në shteg.

Planifikoni lidhjen e sipërme sipas vendit ku ndodh shpërndarja. Një marrje e vetme private që ushqen një shërbim mediatik publik sillet shumë ndryshe nga çdo shikues që tërheq transmetimin e vet përmes tunelit. Modeli i dytë zakonisht përfundon në një lidhje shtëpiake të ngopur dhe një kamera që duket se dështon rastësisht.

Vendosni vërtetimin në kufirin që ju botoni

TLS, vërtetimi i shikuesve dhe regjistrimi i aksesit i përkasin pikës publike të hyrjes, jo kamerës. Kjo i mban kredencialet e kamerës të ndara nga kredencialet e transmetimit. Kjo ju jep gjithashtu një vend të vetëm për të revokuar aksesin kur një anëtar i publikut largohet. Vendosja e atyre kontrolleve në kamera në vend të kësaj do të thotë që çdo ndryshim i publikut bëhet një ndryshim administrativ në një pajisje që nuk duhet të jetë kurrë i arritshëm publikisht.

Mbani VPN-në dhe lejet administrative të kamerës të ndara nga shtegu i botimit. Një VPS që mund të arrijë ndërfaqen web të kamerës për të tërhequr një transmetim nuk duhet të jetë gjithashtu makina që ekspozon atë ndërfaqe. Publiku nuk duhet ta mësojë kurrë adresën e kamerës.

Më pas verifikoni dy skajet që keni ndërtuar vërtet, në vend që të supozoni se zinxhiri funksionon:

$ 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

Një sondim i suksesshëm i burimit privat dhe një marrje e suksesshme e listës në kufirin publik dëshmojnë gjysma të ndryshme të projektit. Testojini ato veçmas. Riprodhimi nga i njëjti lloj klienti që përdor publiku juaj është i vetmi test që mbulon të gjithë zinxhirin.

Ajo që përfundoni me të është një zinxhir me një qëllim në çdo hallkë: burim privat, marrje e kufizuar, paketim i zgjedhur, hyrje e autorizuar e shikuesit. Asnjë prej këtyre hallkave nuk është opsionale, dhe asnjëra nuk krijohet duke hapur një port.