Публікацыя патоку з камеры: 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

Паспяховая праверка прыватнай крыніцы і паспяховае атрыманне плэйліста на публічным краі даказваюць розныя паловы праекта. Правярайце іх асобна. Прайграванне з таго самага тыпу кліента, які выкарыстоўвае ваша аўдыторыя, — адзіная праверка, што ахоплівае ўвесь ланцуг.

У выніку вы маеце ланцуг з прызначэннем у кожным звяне: прыватная крыніца, абмежаваны прыём, абраная ўпакоўка, аўтарызаваны ўваход гледача. Ні адно з гэтых звянняў не з'яўляецца неабавязковым, і ні адно не ствараецца адкрыццём порта.