ನೀವು ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪುಟವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತೀರಿ, ಪ್ಲೇಯರ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್ ಮುಚ್ಚಲ್ಪಡುತ್ತದೆ. ಆಚೆ ತುದಿಯಲ್ಲಿರುವ ವೀಕ್ಷಕ ಅದೇ ಪುಟವನ್ನು ತೆರೆದು ಎಂದೂ ಮುಗಿಯದ ತಿರುಗುವ ಸೂಚಕವನ್ನು ಪಡೆಯುತ್ತಾನೆ. ಸಾಮಾನ್ಯ ವಿವರಣೆ ಎಂದರೆ VPN ಸರ್ವರ್ನಲ್ಲಿದೆ, ಹಾಗಾಗಿ ಪ್ಲೇಬ್ಯಾಕ್ ಕೆಲಸ ಮಾಡಬೇಕು — ಆದರೆ ಪ್ಲೇಲಿಸ್ಟ್ ಕೇಳುವ ಘಟಕ ಬ್ರೌಸರ್, ಮತ್ತು ಅದಕ್ಕೆ ತನ್ನದೇ ಆದ ಜಾಲ ಮಾರ್ಗವಿದೆ. ಖಾಸಗಿ ಪ್ರವೇಶವಿರುವ ಸರ್ವರ್ನಲ್ಲಿ ಎಂಬೆಡ್ ಆದ ಪುಟ ಆ ಪ್ರವೇಶವನ್ನು ಅದನ್ನು ಲೋಡ್ ಮಾಡುವವರಿಗೆ ಸಾಲವಾಗಿ ಕೊಡುವುದಿಲ್ಲ.

ಇದು HLS ಮೂಲವನ್ನು, ಉದಾಹರಣೆಗೆ http://10.5.5.9:8080/live/stream.m3u8, ಪ್ಲೇ ಮಾಡುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ 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.

ವ್ಯವಸ್ಥೆ ಉದ್ದೇಶಪೂರ್ವಕವಾದ ಮೇಲೆ ಅದನ್ನು ಒಂದು ಸಾಲಿನಲ್ಲಿ ಬರೆಯಿರಿ: ಮಾಧ್ಯಮವನ್ನು ಯಾರು ತರುತ್ತಾರೆ, ಯಾವ ಮಾರ್ಗದಿಂದ, ಮತ್ತು ವೀಕ್ಷಕರು ಏನನ್ನು ಕೇಳಲು ಅನುಮತಿ ಇದೆ. ಆ ವಾಕ್ಯ ಸ್ಟ್ರೀಮ್ ನಿಜವಾಗಿ ಯಾರಿಗಾಗಿ ಎಂಬ ಭವಿಷ್ಯದ ಚರ್ಚೆಗಳ ಬಹುಪಾಲನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು