તમારો ખાનગી HLS સ્ટ્રીમ તમારા માટે લોડ થાય છે, તમારા દર્શકો માટે નહીં

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

આ હાલના ASP.NET પૃષ્ઠ વિશે છે જે HLS સ્રોત ચલાવે છે, જેમ કે http://10.5.5.9:8080/live/stream.m3u8, જે એક દૃષ્ટાંતરૂપ ખાનગી સરનામું છે. બે ગોઠવણો કામ કરે છે; તેમાંથી એક કદાચ તમે બનાવ્યું હોય તે નથી.

ભ્રમ: લોડ થતું પૃષ્ઠ મીડિયા માર્ગ સાબિત કરે છે

તે પૃષ્ઠનું 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 હોય છે.

ગોઠવણ જાણી જોઈને પસંદ કરાયા પછી તેને એક લીટીમાં લખો: મીડિયા કોણ લાવે છે, કયા માર્ગે, અને દર્શકને શું માંગવાની પરવાનગી છે. એ વાક્ય સ્ટ્રીમ ખરેખર કોના માટે છે તે અંગેની મોટાભાગની ભાવિ ચર્ચાઓ ઉકેલે છે.