ക്യാമറ സ്ട്രീം പ്രസിദ്ധീകരിക്കൽ: 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

സ്വകാര്യ ഉറവിടത്തിന്റെ വിജയകരമായ പരിശോധനയും പൊതു അരികിൽ പ്ലേലിസ്റ്റിന്റെ വിജയകരമായ ശേഖരണവും രൂപകൽപ്പനയുടെ വ്യത്യസ്ത പകുതികൾ തെളിയിക്കുന്നു. അവ വെവ്വേറെ പരിശോധിക്കുക. നിങ്ങളുടെ പ്രേക്ഷകർ ഉപയോഗിക്കുന്ന അതേ തരം ക്ലയന്റിൽ നിന്നുള്ള പ്ലേബാക്ക് മാത്രമാണ് മുഴുവൻ ശൃംഖലയും ഉൾക്കൊള്ളുന്ന ഏക പരിശോധന.

അവസാനം ഓരോ കണ്ണിക്കും ഒരു ലക്ഷ്യമുള്ള ഒരു ശൃംഖല നിങ്ങൾക്കുണ്ടാകും: സ്വകാര്യ ഉറവിടം, പരിമിത ഇൻജെസ്റ്റ്, തിരഞ്ഞെടുത്ത പാക്കേജിംഗ്, അനുവദിക്കപ്പെട്ട കാഴ്ചക്കാരൻ പ്രവേശനം. ആ കണ്ണികളിൽ ഒന്നും ഐച്ഛികമല്ല, ഒന്നും ഒരു പോർട്ട് തുറക്കുന്നതിലൂടെ ഉണ്ടാകുന്നുമില്ല.