કૅમેરા સ્ટ્રીમ પ્રકાશિત કરવું: RTSP અને HLS એક જ કિનારો નથી

તમે કૅમેરાનો એક પોર્ટ ખોલો છો, તેની તરફ એક પ્લેયરનું મુખ કરો છો અને ધારો છો કે ઇન્ટરનેટની સમસ્યા હલ થઈ ગઈ છે. પછી એક ફોન તેને ચલાવી શકતો નથી, એક બ્રાઉઝર તેને ચલાવી શકતું નથી, અને કૅમેરાનું વ્યવસ્થાપન પૃષ્ઠ જાહેર કિનારેથી ફક્ત એક ખોટી ટાઇપ કરેલા માર્ગના અંતરે હોય છે. તમે જે ડિલિવરી મોડેલ પસંદ કર્યું, RTSP અથવા HLS, તે કોઈ પણ ફાયરવોલ નિયમ લખાય તે પહેલાં આનો મોટો ભાગ નક્કી કરે છે. VPN ફક્ત ખાનગી ભાગ પૂરો પાડે છે.

VPN સ્રોતનો માર્ગ સુધારે છે, દર્શકનો નહીં

ટનલ દ્વારા કૅમેરાના લૅન સાથે જોડાયેલ VPS કૅમેરા સુધી તેના ખાનગી સરનામે પહોંચી શકે છે, અને આ ખરેખર ઉપયોગી છે. તેનો અર્થ છે કે કૅમેરાને પોતાનો કોઈ ઇનબાઉન્ડ પોર્ટ જોઈતો નથી અને ઘરનો રાઉટર બંધ રહે છે. તે તમને નથી કહેતું કે કોઈ દર્શક કઈ ભાષા બોલશે. ડેસ્કટોપ પ્લેયર, બ્રાઉઝર, ફોન અને સ્માર્ટ ટીવી જુદા જુદા પ્રોટોકોલ સમર્થન કરે છે, અને દરેકની TLS, પ્રમાણીકરણ અને કોડેક વિશે પોતાની અપેક્ષાઓ હોય છે.

અહીં એ ધારણા છે જે છોડવા જેવી છે: પ્રકાશન એટલે સ્રોતને પહોંચવા યોગ્ય બનાવવો. પ્રકાશનનો ખરેખર અર્થ નિશ્ચિત દર્શકવર્ગને મીડિયા વાપરવાની સમર્થિત રીત આપવી છે. પ્રકાશિત સ્ટ્રીમનું એક ફોર્મેટ, એક દર્શકવર્ગ અને એક ક્રેડેન્શિયલ હોય છે; પહોંચવા યોગ્ય કૅમેરા પાસે આમાંથી કંઈ જ હોતું નથી. પહોંચ એ જ ભાગ છે જે ટનલ હલ કરે છે, અને દર્શકનું પ્રવેશબિંદુ એ ભાગ છે જે તમારે હજી ડિઝાઇન કરવો છે.

RTSP એ વાટાઘાટ છે, એક પોર્ટ નહીં

RTSP સત્ર નિયંત્રણ લઈ જાય છે: ક્લાયન્ટ વર્ણન માગે છે, એક અથવા વધુ મીડિયા ટ્રૅક સેટ કરે છે અને પછી ચલાવે છે. મીડિયાની વહનવ્યવસ્થા પોતે તે જ સેટઅપ દરમિયાન નક્કી થાય છે, તેથી પ્રોટોકોલને એક ફોરવર્ડ કરેલા TCP પોર્ટથી સારી રીતે સમજાવી શકાતો નથી. તે જ વાટાઘાટ એ ભાગ છે જે લોકો ફાયરવોલ નિયમોની સરખામણી કરતી વખતે ચૂકી જાય છે.

એન્ડપોઇન્ટના આધારે 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

ખાનગી સ્રોતની સફળ ચકાસણી અને જાહેર કિનારે પ્લેલિસ્ટની સફળ પ્રાપ્તિ ડિઝાઇનના જુદા જુદા અડધા સાબિત કરે છે. તેમને અલગ તપાસો. તમારો દર્શકવર્ગ જે પ્રકારનું ક્લાયન્ટ વાપરે છે તેવા ક્લાયન્ટથી પ્લેબૅક એ એકમાત્ર કસોટી છે જે આખી શૃંખલાને આવરે છે.

અંતે તમારી પાસે દરેક કડીનો હેતુ ધરાવતી શૃંખલા હોય છે: ખાનગી સ્રોત, મર્યાદિત ઇનજેસ્ટ, પસંદ કરેલી પૅકેજિંગ, અધિકૃત દર્શક પ્રવેશ. આમાંથી કોઈ પણ કડી વૈકલ્પિક નથી, અને કોઈ પણ પોર્ટ ખોલવાથી બનતી નથી.