Տեսախցիկի հոսքի հրապարակում. RTSP-ն ու HLS-ը նույն եզրը չեն

Դուք բացում եք տեսախցիկի մեկ պորտ, ուղղում եք դրան նվագարկիչ և ենթադրում, որ ինտերնետի խնդիրը լուծված է։ Հետո հեռախոսը չի կարող այն նվագարկել, դիտարկիչը չի կարող այն նվագարկել, և տեսախցիկի կառավարման էջը հանրային եզրից ընդամենը մեկ սխալ մուտքագրված ուղի հեռավորության վրա է։ Ձեր ընտրած առաքման մոդելը՝ RTSP թե HLS, որոշում է դրա մեծ մասը նախքան որևէ firewall կանոն գրվելը։ VPN-ը տրամադրում է միայն մասնավոր հատվածը։

VPN-ը ուղղում է աղբյուրի ուղին, ոչ թե դիտողի ուղին

VPS-ը, որը թունելով միացված է տեսախցիկի տեղական ցանցին, կարող է հասնել տեսախցիկին իր մասնավոր հասցեով, և դա իսկապես օգտակար է։ Դա նշանակում է, որ տեսախցիկին պետք չէ սեփական մուտքային պորտ, և տնային երթուղիչը մնում է փակ։ Դա ձեզ չի ասում, թե ինչ լեզվով կխոսի դիտողը։ Սեղանադիր նվագարկիչը, դիտարկիչը, հեռախոսը և խելացի հեռուստացույցը աջակցում են տարբեր արձանագրությունների, և յուրաքանչյուրն ունի իր սպասելիքները TLS-ի, նույնականացման և կոդեկների վերաբերյալ։

Ահա ենթադրությունը, որն արժե մերժել՝ հրապարակելը իբր նշանակում է աղբյուրը հասանելի դարձնել։ Հրապարակելը իրականում նշանակում է որոշակի լսարանի տալ մեդիան սպառելու աջակցվող եղանակ։ Հրապարակված հոսքն ունի ձևաչափ, լսարան և մուտքի տվյալներ. հասանելի տեսախցիկը դրանցից ոչ մեկը չունի։ Հասանելիությունը այն մասն է, որը լուծում է թունելը, իսկ դիտողի մուտքի կետը այն մասն է, որը դեռ պետք է նախագծեք։

RTSP-ը բանակցություն է, ոչ թե մեկ պորտ

RTSP-ը կրում է նստաշրջանի կառավարումը. հաճախորդը նկարագրություն է խնդրում, կարգավորում է մեկ կամ մի քանի մեդիա հետքեր, ապա նվագարկում։ Մեդիայի տեղափոխությունն ինքնին համաձայնեցվում է այդ կարգավորման ընթացքում, ինչի պատճառով արձանագրությունը լավ չի նկարագրվում մեկ վերահասցեավորված TCP պորտով։ Այդ բանակցությունը այն մասն է, որը մարդիկ բաց են թողնում firewall-ի կանոնները համեմատելիս։

Կախված վերջնակետերից՝ RTP-ն կարող է գալ առանձին UDP պորտերով կամ հյուսվել կառավարման կապի մեջ։ Ռելեն, որը փոխանցում է միայն 554-ը և ենթադրում, որ մնացածը կաշխատի, սովորաբար ստեղծում է նստաշրջան, որը միանում է, հաղորդում է հետքի մասին և հետո ոչինչ չի ցուցադրում։ Նախքան դրա համար կանոններ գրելը՝ ստուգեք, թե տեսախցիկը իրականում ինչ տեղափոխություն է համաձայնեցնում։ Մասնավոր կողմում գրառումը դրան պատասխանում է մեկ րոպեում, իսկ գուշակելը արժենում է մի երեկո։

Փոքր, հայտնի լսարանի համար՝ համատեղելի նվագարկիչներով, դիտավորյալ կարգավորված RTSP ռելեն կարող է ճիշտ պատասխան լինել։ Սահմանափակեք, թե որ աղբյուրից կարող է քաշել, և պահանջեք նույնականացում ռելեում։ Գրեք ձեր փորձարկած նվագարկիչները, որովհետև VLC-ում աշխատող RTSP հոսքը կարող է դիտարկիչում այնուամենայնիվ ձախողվել։

HLS-ը նվագացանկ է գումարած ռեսուրսներ

HLS դիտողը ստանում է նվագացանկ, ապա ստանում է այն մեդիա հատվածները, որոնք այդ ցանկը նշում է։ HLS ճշգրտումը սահմանում է այդ ռեսուրսների մոդելը, և կարևոր գործառնական մանրամասն այն է, որ նվագացանկերը հղում են անում այլ URL-ների։ Հարաբերական հղումները լուծվում են նվագացանկի գտնվելու վայրի նկատմամբ, ուստի ուղիները վերաշարադրող պրոքսին պետք է դրանք վերաշարադրի հետևողականորեն։

Եթե տեսախցիկն արդեն մատուցում է օգտագործելի HLS, հանրային ֆրոնտենդը կարող է այդ նվագացանկի և հատվածների հարցումները փոխանցել թունելով։ Ուշադրություն դարձրեք հավելվածի ստեղծած բանալիներին, վերահասցեավորումներին և URL-ներին։ Ցանկացած բացարձակ URL, որը մատնանշում է մասնավոր հոսթ, կոտրվում է այն պահին, երբ տեղական ցանցից դուրս գտնվող դիտողը հետևում է դրան։ Հարաբերական ուղիներն են նրանք, որոնք դիմանում են պրոքսի վերաշարադրմանը, ուստի նախընտրեք դրանք ամենուր, որտեղ վերահսկում եք ստեղծվող ելքը։

Եթե տեսախցիկը խոսում է միայն RTSP, ինչ-որ բան պետք է աղբյուրը վերածի դիտողի ձևաչափի։ Վերափաթեթավորումը և տրանսկոդավորումը տարբեր աշխատանքներ են. վերափաթեթավորումը պահպանում է կոդեկը, մինչդեռ տրանսկոդավորումը վերակոդավորում է այն համատեղելիության համար, և միայն երկրորդն է լուրջ CPU ծախսում։ Նրանցից ոչ մեկը պարտադիր չի դառնում միայն այն պատճառով, որ ուղու վրա 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

Մասնավոր աղբյուրի հաջող ստուգումը և հանրային եզրում նվագացանկի հաջող ստացումը ապացուցում են նախագծի տարբեր կեսերը։ Փորձարկեք դրանք առանձին։ Նվագարկումը նույն տեսակի հաճախորդից, որն օգտագործում է ձեր լսարանը, միակ թեստն է, որն ընդգրկում է ամբողջ շղթան։

Ի վերջո դուք ունեք շղթա, որի յուրաքանչյուր օղակ ունի նպատակ՝ մասնավոր աղբյուր, սահմանափակ ընդունում, ընտրված փաթեթավորում, լիազորված դիտողի մուտք։ Այդ օղակներից ոչ մեկը ըստ ցանկության չէ, և ոչ մեկը չի ստեղծվում պորտ բացելով։