നിങ്ങളുടെ സ്വകാര്യ HLS സ്ട്രീം നിങ്ങളുടെ കാഴ്ചക്കാർക്കല്ല, നിങ്ങൾക്കുവേണ്ടിയാണ് ലോഡ് ചെയ്യുന്നത്

നിങ്ങൾ ലാപ്ടോപ്പിൽ പേജ് പരിശോധിക്കുന്നു, പ്ലേയർ പ്രവർത്തിക്കുന്നു, ടിക്കറ്റ് അടയ്ക്കുന്നു. മറുവശത്തുള്ള കാഴ്ചക്കാരൻ അതേ പേജ് തുറക്കുമ്പോൾ ഒരിക്കലും തീരാത്ത ഒരു കറങ്ങുന്ന സൂചകം ലഭിക്കുന്നു. സാധാരണ നൽകുന്ന വിശദീകരണം VPN സെർവറിലാണ് എന്നാണ്, അതിനാൽ പ്ലേബാക്ക് പ്രവർത്തിക്കേണ്ടതാണ് — എന്നാൽ പ്ലേലിസ്റ്റ് ആവശ്യപ്പെടുന്ന ഘടകം ബ്രൗസർ ആണ്, അതിന് അതിന്റേതായ നെറ്റ്വർക്ക് പാതയുണ്ട്. സ്വകാര്യ ആക്സസ് ഉള്ള സെർവറിൽ ഉൾച്ചേർത്ത പേജ് ആ ആക്സസ് അത് ലോഡ് ചെയ്യുന്നവർക്ക് കടം കൊടുക്കുന്നില്ല.

ഇത് http://10.5.5.9:8080/live/stream.m3u8 പോലുള്ള ഒരു HLS ഉറവിടം പ്ലേ ചെയ്യുന്ന നിലവിലുള്ള ASP.NET പേജിനെക്കുറിച്ചാണ്; ഇത് ഉദാഹരണാർത്ഥമുള്ള ഒരു സ്വകാര്യ വിലാസമാണ്. രണ്ട് ക്രമീകരണങ്ങൾ പ്രവർത്തിക്കുന്നു; അവയിലൊന്ന് ഒരുപക്ഷേ നിങ്ങൾ നിർമ്മിച്ചതല്ല.

മിഥ്യ: ലോഡ് ചെയ്യുന്ന പേജ് മീഡിയ പാത തെളിയിക്കുന്നു

ആ പേജിന്റെ HTML നിങ്ങളുടെ വെബ് സെർവറിൽ നിന്ന്, നിങ്ങളുടെ വെബ് സെർവറിനുള്ള ഏത് റൂട്ടിലൂടെയും വരുന്നു. പ്ലേലിസ്റ്റും സെഗ്മെന്റുകളും മീഡിയ ഉറവിടത്തിൽ നിന്ന്, അഭ്യർത്ഥിക്കുന്ന ഘടകത്തിനുള്ള ഏത് റൂട്ടിലൂടെയും വരുന്നു. പ്ലേയർ കാഴ്ചക്കാരന്റെ ബ്രൗസറിൽ പ്രവർത്തിക്കുമ്പോൾ ഇവ രണ്ട് വ്യത്യസ്ത ക്ലയന്റുകളും രണ്ട് വ്യത്യസ്ത ഉറവിട വിലാസങ്ങളും പലപ്പോഴും രണ്ട് വ്യത്യസ്ത പരാജയ മേഖലകളുമാണ്. ആദ്യത്തേത് വിജയിക്കുന്നത് കാണുന്നത് രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

നിങ്ങളുടെ പരിശോധന യഥാർത്ഥത്തിൽ തെളിയിച്ചത് കാണുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്: നിങ്ങളുടെ യന്ത്രത്തിന് പൊതു പേജിലും സ്വകാര്യ മീഡിയ ഹോസ്റ്റിലും ഒരേ സമയം എത്താനാകും. കാഴ്ചക്കാരന്റെ യന്ത്രം ഒരിക്കലും പരീക്ഷണത്തിന്റെ ഭാഗമായിരുന്നില്ല.

പ്ലേലിസ്റ്റ് അടുത്തതായി ആവശ്യപ്പെടുന്നത്

RFC 8216 സെഗ്മെന്റുകൾ പട്ടികപ്പെടുത്തുന്ന മീഡിയ പ്ലേലിസ്റ്റുകളെ, മറ്റ് പ്ലേലിസ്റ്റുകൾ പട്ടികപ്പെടുത്തുന്ന മാസ്റ്റർ പ്ലേലിസ്റ്റുകളിൽ നിന്ന് വേർതിരിക്കുന്നു, കൂടാതെ ആപേക്ഷിക URI-കളെ അവ ഉൾക്കൊള്ളുന്ന പ്ലേലിസ്റ്റിന്റെ URI-യുമായി താരതമ്യം ചെയ്ത് പരിഹരിക്കുന്നു. ആളുകൾ ഒഴിവാക്കുന്ന ഭാഗം ആ നിയമമാണ്. ഒരു .m3u8 ഫയൽ വിജയകരമായി എടുക്കുന്നത് പ്ലേബാക്ക് പരിശോധനയല്ല, കാരണം എടുത്ത ഫയൽ സൂചികയാണ്, മീഡിയയല്ല.

പ്ലേയർ ചെയ്യുന്നതുപോലെ ശൃംഖല പിന്തുടരുക: തിരഞ്ഞെടുത്ത പ്ലേലിസ്റ്റ് തുറക്കുക, പിന്നീട് അത് പേരിടുന്ന വിഭവങ്ങൾ ആവശ്യപ്പെടുക, പിന്നീട് ഏതെങ്കിലും റീഡയറക്ട് പിന്തുടരുക. എത്തിച്ചേരാവുന്ന ഒരു വെബ് സെർവർ വഴി നൽകുന്ന പ്ലേലിസ്റ്റിന് കാഴ്ചക്കാരനെ എത്തിച്ചേരാനാകാത്ത സ്വകാര്യ വിലാസത്തിലേക്ക് അയക്കാനാകും. അതുപോലെ, ഒരു ആപേക്ഷിക പ്ലേലിസ്റ്റ് മറ്റൊരു URL-ലേക്ക് മാറ്റുന്നത് അതിന്റെ എൻട്രികൾ പരിഹരിക്കുന്ന അടിത്തറയെ മാറ്റുന്നു, അതുകൊണ്ടാണ് ആദ്യത്തെ ദൃശ്യമായ URL പുനരെഴുതി അവിടെ നിർത്തുന്നത് സാധുവായി തോന്നുന്നതും എന്നാൽ പ്ലേ ചെയ്യാനാകാത്തതുമായ ഒരു പ്ലേലിസ്റ്റ് സൃഷ്ടിക്കുന്നത്.

നേരിട്ടുള്ള കാഴ്ച: കാഴ്ചക്കാരന് പാത ആവശ്യമാണ്

കാഴ്ചക്കാർ മീഡിയ ഹോസ്റ്റിൽ നേരിട്ട് എത്തേണ്ടതാണെങ്കിൽ, അവരുടെ ഉപകരണങ്ങൾക്ക് അംഗീകരിച്ച VPN അല്ലെങ്കിൽ മറ്റൊരു സ്വകാര്യ പാത, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിച്ച പേരുകൾ പരിഹരിക്കുന്ന DNS, ആ ലക്ഷ്യസ്ഥാനങ്ങളിൽ എത്താനുള്ള അനുമതി, മീഡിയ സേവനം ആവശ്യപ്പെടുന്ന ഏത് പ്രാമാണീകരണവും ആവശ്യമാണ്. ഓരോന്നും സെർവറിലല്ല, കാഴ്ചക്കാരന്റെ ഉപകരണത്തിൽ പരിശോധിക്കുക. VPN പ്രൊഫൈൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിലും ബന്ധിപ്പിച്ചിട്ടില്ലാത്ത ഫോണിലെ ബ്രൗസർ സാധാരണവും പൂർണ്ണമായി പുനരുൽപ്പാദിപ്പിക്കാവുന്നതുമായ ഒരു പരാജയമാണ്.

ഈ ക്രമീകരണം ഉറവിടം സ്വകാര്യമായി നിലനിർത്തുകയും ആക്സസ് ആവശ്യകത പ്രേക്ഷകരിലേക്ക് തള്ളുകയും ചെയ്യുന്നു. ഇത് സാങ്കേതികമെന്നതുപോലെ തന്നെ ഒരു നയപരമായ തീരുമാനവുമാണ്, അതിനാൽ അതിനെ ചുറ്റിപ്പറ്റി രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഓരോ ഉദ്ദേശിത കാഴ്ചക്കാരനും ആ പാത പിടിക്കാൻ അനുമതിയുണ്ടെന്ന് ഉറപ്പാക്കുക.

സെർവർ വശത്തുനിന്നുള്ള വിതരണം: ഒരു നിയന്ത്രിത പ്രവേശന കേന്ദ്രം

ബദൽ, ഉറവിടം അതിന്റെ സ്വകാര്യ പാതയിലൂടെ എടുത്ത് കാഴ്ചക്കാരനെ അഭിമുഖീകരിക്കുന്ന വിഭവങ്ങൾ മാത്രം പുനഃപ്രസിദ്ധീകരിക്കുന്ന ഒരു അധികാരപ്പെടുത്തിയ മീഡിയ ഫ്രണ്ട്എൻഡാണ്. പ്ലേലിസ്റ്റും സെഗ്മെന്റുകളും ഏതെങ്കിലും കീ വിഭവങ്ങളും ആ ഒരു പ്രവേശന കേന്ദ്രവുമായി പൊരുത്തപ്പെട്ട് നിലനിർത്തുക, അല്ലാത്തപക്ഷം പ്ലേയർ പുനരെഴുതിയ പ്ലേലിസ്റ്റ് ഫ്രണ്ട്എൻഡിലൂടെയും സെഗ്മെന്റുകൾ കാഴ്ചക്കാരന് എത്താനാകാത്ത ഒരു വിലാസത്തിൽ നിന്ന് നേരിട്ടും എടുക്കും.

ആ ഫ്രണ്ട്എൻഡിൽ ഉറവിടവും അനുവദനീയമായ പാതകളും പരിമിതപ്പെടുത്തുക. ഉപയോക്താവ് നൽകുന്ന ഏകപക്ഷീയമായ URL ഉപകാരപ്രദമായ ഒരു പ്രോക്സിയെ നിങ്ങളുടെ ആന്തരിക നെറ്റ്വർക്കിന്റെ പരിധിയില്ലാത്ത എടുക്കൽ ഉപകരണമാക്കി മാറ്റുന്നു, ഇത് പ്ലേ ചെയ്യാത്ത ഒരു സ്ട്രീമിനേക്കാൾ വളരെ മോശം പ്രശ്നമാണ്. സ്ട്രിംഗ് പിന്നീട് സാധൂകരിക്കുന്നതിന് പകരം ഉറവിടവും പാതയുടെ പൂർവ്വപദവും അനുവദനീയ പട്ടികയിൽ ചേർക്കുക.

നിലവിലുള്ള HLS ഉറവിടത്തിന്, ആദ്യം നിയന്ത്രിത ഫോർവേഡിംഗ് മതിയോ എന്ന് പരിശോധിക്കുക; ഇടയിൽ VPN ഉണ്ടെന്നത് ട്രാൻസ്കോഡിംഗ് ആവശ്യമാണെന്ന് അർത്ഥമാക്കുന്നില്ല. പിന്നീട് യഥാർത്ഥ ബ്രൗസർ-കോഡെക് സംയോജനം സാധൂകരിക്കുക, കാരണം എത്തിച്ചേരാവുന്ന പ്രതികരണവും പിന്തുണയ്ക്കുന്ന ഫോർമാറ്റും രണ്ട് വേർതിരിച്ച വ്യവസ്ഥകളാണ്. ഉറവിടത്തിന്റെ TLS, പ്രാമാണീകരണം, ബ്രൗസർ സുരക്ഷാ ആവശ്യകതകൾ അതേപടി നിലനിർത്തുക — ഉൾച്ചേർത്ത പ്ലേയർ അവയിൽ നിന്ന് ഒഴിവല്ല.

URL അല്ല, ശൃംഖല പരിശോധിക്കുക

ഓരോ അഭ്യർത്ഥനയും യഥാർത്ഥത്തിൽ നടത്തുന്ന ഘടകത്തിൽ നിന്ന് പരിശോധനകൾ നടത്തുക, ഓരോ ഘട്ടത്തെയും അതിന്റേതായ ഫലമായി കാണുക:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

പിന്നീട് അത് കാഴ്ചക്കാരന്റെ സ്വന്തം ബ്രൗസറിൽ ഉദ്ദേശിച്ച സ്ട്രീമിനൊപ്പം ആവർത്തിക്കുക, നിങ്ങളുടെ മേശയിലെ പരീക്ഷണ മാതൃകയല്ല. പേജ് ലോഡ്, പ്ലേലിസ്റ്റ് ലോഡ്, സെഗ്മെന്റ് എടുക്കൽ, അനുമതി പരാജയം എന്നിവ നാല് വേറിട്ട ഫലങ്ങളാണ്, അവ നാലും കണ്ടതിന് ശേഷമേ ഇത് ശരിയാക്കിയെന്ന് പറയാവൂ. പഴയ ഒരു ഉദാഹരണം ഒരു സ്ട്രീം അങ്ങനെ പ്ലേ ചെയ്തതുകൊണ്ട് പഴയ ബ്രൗസർ പ്ലഗിൻ ഇൻസ്റ്റാൾ ചെയ്യരുത്; കാണാത്ത ഭാഗം സാധാരണയായി കാഴ്ചക്കാരന്റെ പാത അല്ലെങ്കിൽ ഒപ്പിടാത്ത സെഗ്മെന്റ് URL ആണ്.

ക്രമീകരണം ഉദ്ദേശപൂർവ്വമായിക്കഴിഞ്ഞാൽ അത് ഒരു വരിയിൽ എഴുതിവയ്ക്കുക: മീഡിയ ആരാണ് എടുക്കുന്നത്, ഏത് പാതയിലൂടെ, കാഴ്ചക്കാരന് എന്ത് ആവശ്യപ്പെടാൻ അനുമതിയുണ്ട്. ആ വാക്യം സ്ട്രീം യഥാർത്ഥത്തിൽ ആർക്കുവേണ്ടിയാണ് എന്നതിനെക്കുറിച്ചുള്ള ഭാവി തർക്കങ്ങളിൽ മിക്കതും തീർപ്പാക്കുന്നു.