ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ಡಿಜಿಟಲ್ ಪ್ರಸಾರದ ಜಗತ್ತಿನಲ್ಲಿ ದೊಡ್ಡ ಬದಲಾವಣೆಗಳಾಗಿವೆ. ಅಡೋಬ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ವಿಷಯವನ್ನು ತಲುಪಿಸುವ ತಂತ್ರಜ್ಞಾನವಾದ ಫ್ಲ್ಯಾಶ್ ತನ್ನ ಅಸ್ತಿತ್ವವನ್ನು ವೇಗವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತಿದೆ. ಮತ್ತು ಅದರ ಸ್ಥಾನವನ್ನು HLS ನಂತಹ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.

HTML5 ಮತ್ತು HLS ಮುಕ್ತ ಮೂಲವಾಗಿದೆ, ನೀವು ಬಯಸಿದಂತೆ ಮಾರ್ಪಡಿಸಬಹುದು ಮತ್ತು ಬಳಸಲು ಉಚಿತವಾಗಿದೆ. ಅವುಗಳು ತಮ್ಮ ಪೂರ್ವವರ್ತಿಗಳಿಗಿಂತ ಸುರಕ್ಷಿತ, ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತವೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಆನ್‌ಲೈನ್ ಪ್ರಸಾರದ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ವಿವರಣೆಯನ್ನು ಮತ್ತು HLS ಅನ್ನು ಬಳಸುವ ಶಿಫಾರಸುಗಳನ್ನು ನೀಡುತ್ತೇವೆ.

HLS ಎಂದರೇನು

HLS ಎಂದರೆ HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್, ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಮಾಧ್ಯಮ ಡೇಟಾವನ್ನು ಸ್ಟ್ರೀಮಿಂಗ್ ಮಾಡುವ ಪ್ರೋಟೋಕಾಲ್. HLS MP4 ಸ್ವರೂಪದಲ್ಲಿ ವೀಡಿಯೊ ವಿಷಯವನ್ನು ಚಿಕ್ಕ 10-ಸೆಕೆಂಡ್ ಬ್ಲಾಕ್‌ಗಳಾಗಿ, ಭಾಗಗಳಾಗಿ ಕತ್ತರಿಸುತ್ತದೆ. ಈ ಚಿಕ್ಕ ತುಣುಕುಗಳನ್ನು HTTP ಮೂಲಕ ವಿತರಿಸಲಾಗುತ್ತದೆ, ಹೆಚ್ಚಿನ ಸಾಧನಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್‌ಗಳೊಂದಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತದೆ.

HLS ಪ್ರಾಥಮಿಕವಾಗಿ ಆನ್‌ಲೈನ್ ಪ್ರಸಾರಗಳ ಅತ್ಯುತ್ತಮ ಗುಣಮಟ್ಟವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ, ಆನ್‌ಲೈನ್ ಪ್ರಸಾರದ ಸಮಯದಲ್ಲಿ ವಿಳಂಬವು 15-30 ಸೆಕೆಂಡುಗಳು ಎಂದು ನೀವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, ಪ್ರಸಾರ ರಚನೆಕಾರರು ಸ್ಟ್ರೀಮ್ ಎನ್‌ಕೋಡಿಂಗ್ ಅನ್ನು ಹಲವಾರು ಗುಣಗಳಿಗೆ ನಿಯೋಜಿಸಬಹುದು. ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ ಇಂಟರ್ನೆಟ್ ಚಾನಲ್‌ನ ಅಗಲವನ್ನು ಆಧರಿಸಿ ಆಟಗಾರನು ನಂತರ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಅತ್ಯುತ್ತಮ ಗುಣಮಟ್ಟವನ್ನು ವಿನಂತಿಸುತ್ತಾನೆ. ಅಂತೆಯೇ, ತುಣುಕುಗಳ ಗುಣಮಟ್ಟವು ಬದಲಾಗಬಹುದು.

ಉದಾಹರಣೆಗೆ, ಒಂದು ಮೊಬೈಲ್ ಫೋನ್ HD ಗುಣಮಟ್ಟದಲ್ಲಿ ವೀಡಿಯೊವನ್ನು ಪ್ಲೇ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಂದು ನಿಮಿಷದ ನಂತರ ವೀಕ್ಷಕನು ಕಳಪೆ ಸ್ವಾಗತದ ಪ್ರದೇಶದಲ್ಲಿ ತನ್ನನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ. ಆಟಗಾರನು ಸಂಪರ್ಕದ ಗುಣಮಟ್ಟದಲ್ಲಿ ಇಳಿಕೆಯನ್ನು ಪತ್ತೆ ಮಾಡಿದಾಗ, ಅದು ಕಡಿಮೆ ಗುಣಮಟ್ಟದ ವೀಡಿಯೊ ಭಾಗಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಇದು ಬಫರಿಂಗ್, ಘನೀಕರಣ ಮತ್ತು ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಎಚ್ಎಲ್ಎಸ್ ರಚನೆಯ ಇತಿಹಾಸ

HLS ಅನ್ನು ಮೂಲತಃ Apple 2009 ರ ಬೇಸಿಗೆಯಲ್ಲಿ iPhone 3 ಜೊತೆಗೆ ಪ್ರಾರಂಭಿಸಿತು. ಹಿಂದಿನ iPhone ಮಾಡೆಲ್‌ಗಳು ಕೆಲವೊಮ್ಮೆ Wi-Fi ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಮೊಬೈಲ್ ಡೇಟಾ ವರ್ಗಾವಣೆಯ ನಡುವೆ ಬದಲಾಯಿಸಿದ ಕಾರಣ ಆನ್‌ಲೈನ್ ಪ್ರಸಾರದಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸಿದವು.

HLS ಬಿಡುಗಡೆಯಾಗುವ ಮೊದಲು, ಆಪಲ್‌ನ ಮುಖ್ಯ ಸ್ಟ್ರೀಮಿಂಗ್ ಮೀಡಿಯಾ ಪ್ರೋಟೋಕಾಲ್ ಕ್ವಿಕ್‌ಟೈಮ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಸರ್ವರ್ ಆಗಿತ್ತು. ಉತ್ತಮ ಸೇವೆ, ಆದರೆ ಇದು ಡೇಟಾ ಪ್ರಸರಣಕ್ಕಾಗಿ ಪ್ರಮಾಣಿತವಲ್ಲದ ಪೋರ್ಟ್‌ಗಳನ್ನು ಬಳಸಿದ್ದರಿಂದ, ಅದರ RTSP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಫೈರ್‌ವಾಲ್‌ಗಳಿಂದ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ನಿಧಾನಗತಿಯ ಇಂಟರ್ನೆಟ್‌ನೊಂದಿಗೆ ಸೇರಿಕೊಂಡು, ಇದು ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ತ್ಯಜಿಸಲು ಕಾರಣವಾಯಿತು. ಆದರೆ ಅದರ ಅನುಷ್ಠಾನದಿಂದ ಕಲಿತ ಪಾಠಗಳು ಎಚ್‌ಎಲ್‌ಎಸ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಬಹಳ ಉಪಯುಕ್ತವಾಗಿವೆ.

HLS ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಫ್ಲೈನಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು HTTP ಸರ್ವರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಮೇಲೆ ತಿಳಿಸಿದಂತೆ ವೀಡಿಯೊ ಫೈಲ್‌ಗಳನ್ನು .ts - MPEG2 ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಸ್ಟ್ರೀಮ್ ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಸಣ್ಣ ತುಣುಕುಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.

HTTP ಸರ್ವರ್ ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಪ್ಲೇಪಟ್ಟಿ ಫೈಲ್ ಅನ್ನು ಸಹ ರಚಿಸುತ್ತದೆ .M3U8 (ಇದನ್ನು ಮ್ಯಾನಿಫೆಸ್ಟ್ ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ), ಇದು ಎಲ್ಲಾ ವೀಡಿಯೊ ಭಾಗಗಳನ್ನು ಸೂಚಿಕೆ ಮಾಡಲು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಪ್ಲೇಪಟ್ಟಿ ಫೈಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಪ್ರಸಾರ ಗುಣಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ಸೂಚ್ಯಂಕ ಫೈಲ್‌ಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ನೀವು ಒಂದು ಗುಣಮಟ್ಟವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಸಾರ ಮಾಡಲು ನಿರ್ಧರಿಸಿದರೂ ಸಹ, "ಮ್ಯಾನಿಫೆಸ್ಟೋ" ಅನ್ನು ಇನ್ನೂ ರಚಿಸಲಾಗುತ್ತದೆ.

ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಡೇಟಾ ಪ್ರಸರಣ ವೇಗದ ಕ್ಷೀಣತೆ ಅಥವಾ ಸುಧಾರಣೆಯನ್ನು ಬಳಕೆದಾರರ ಆಟಗಾರನು ಗುರುತಿಸಬೇಕು. ಅಂತಹ ಈವೆಂಟ್ ಸಂಭವಿಸಿದಾಗ, ಯಾವ ವೀಡಿಯೊ ಗುಣಮಟ್ಟಕ್ಕೆ ಬದಲಾಯಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಆಟಗಾರನು ಮ್ಯಾನಿಫೆಸ್ಟ್ ಫೈಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತಾನೆ. ವೀಕ್ಷಕರು ನಿಲ್ಲಿಸಿದ ವೀಡಿಯೊದ ಭಾಗವನ್ನು ಲೋಡ್ ಮಾಡಲು ಆಟಗಾರನು ನಂತರ ಗುಣಮಟ್ಟ-ನಿರ್ದಿಷ್ಟ ಸೂಚ್ಯಂಕ ಫೈಲ್ ಅನ್ನು ವಿನಂತಿಸುತ್ತಾನೆ. ಈ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯು ಬಳಕೆದಾರರಿಗೆ ಅಗೋಚರವಾಗಿರುತ್ತದೆ. HLS ಪ್ರೋಟೋಕಾಲ್ ಮುಚ್ಚಿದ ಶೀರ್ಷಿಕೆಗಳನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ,

ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಅವಲೋಕನ

ಈ ಹಿಂದೆ ರಚಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮಾಧ್ಯಮ ಸ್ಟ್ರೀಮಿಂಗ್‌ನಲ್ಲಿ ಕೆಲವು ನಾವೀನ್ಯತೆಗಳ ಅನುಷ್ಠಾನವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. HD-DVD ವರ್ಸಸ್ ಬ್ಲೂ-ರೇ ಮತ್ತು Betamax ವರ್ಸಸ್ VHS ನಂತಹ "ಫಾರ್ಮ್ಯಾಟ್ ಯುದ್ಧಗಳು" ಸಹ ಇದ್ದವು. ಆನ್‌ಲೈನ್ ಪ್ರಸಾರದಲ್ಲಿ HLS ಮುಂಚೂಣಿಯಲ್ಲಿದೆ, ಆದರೆ ಇದು ಯಾವಾಗಲೂ ಅಲ್ಲ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಅದು ಉಳಿಯುತ್ತದೆ ಎಂಬುದು ಸತ್ಯವಲ್ಲ.

RTMP ಅಥವಾ ರಿಯಲ್-ಟೈಮ್ ಮೆಸೇಜಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್, ನೈಜ-ಸಮಯದ ಡೇಟಾ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್. ಆಡಿಯೋ ಮತ್ತು ವಿಡಿಯೋ ವಿಷಯವನ್ನು ತಲುಪಿಸಲು ಮ್ಯಾಕ್ರೋಮೀಡಿಯಾವನ್ನು 2000 ರ ಮಧ್ಯದಲ್ಲಿ ರಚಿಸಲಾಯಿತು. ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಫ್ಲ್ಯಾಶ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಮ್ಯಾಕ್ರೋಮೀಡಿಯಾ ನಂತರ ಅಡೋಬ್ ಇಂಕ್ ಜೊತೆಗೆ ವಿಲೀನಗೊಂಡಿತು, ಇದು RTMP ಅನ್ನು ಅರೆ-ಮುಕ್ತ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ.

ಕಳೆದ ದಶಕದಿಂದ, RTMP ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಪ್ರಸಾರ ಮಾಡುವ ಪ್ರಮುಖ ವಿಧಾನವಾಗಿದೆ. ಎಚ್‌ಎಲ್‌ಎಸ್ ಆಗಮನದೊಂದಿಗೆ ಮಾತ್ರ ಅದರ ಪಾಲು ಕಡಿಮೆಯಾಗಲು ಪ್ರಾರಂಭಿಸಿತು. ಇಂದು, ಹೆಚ್ಚಿನ ಆನ್‌ಲೈನ್ ವೀಡಿಯೊ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಒಳಬರುವ RTMP ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನೀವು RTMP ನಲ್ಲಿ ಪ್ರಸಾರ ಮಾಡುತ್ತೀರಿ, ಆನ್‌ಲೈನ್ ವೀಡಿಯೊ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಂತರ HLS ನಲ್ಲಿ ಎನ್‌ಕೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ ವೀಕ್ಷಕರಿಗೆ ತಲುಪಿಸುತ್ತದೆ. ನಿಜ, ಅನೇಕ CDN ಆಪರೇಟರ್‌ಗಳು RTMP ಬೆಂಬಲವನ್ನು ತ್ಯಜಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ - ಪುರಾವೆ

ಅಡೋಬ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಮುಂದಿನ ಪೀಳಿಗೆಯ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HDS - HTTP ಡೈನಾಮಿಕ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಫ್ಲ್ಯಾಶ್ ಪ್ಲೇಬ್ಯಾಕ್ ಪ್ಲಗಿನ್‌ನೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದರ ಬಳಕೆಯ ಆವರ್ತನವು ಸಾಮಾನ್ಯ HLS ಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ.

ಫ್ಲ್ಯಾಶ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ ಸಾಧನಗಳು ಮತ್ತು ಬ್ರೌಸರ್‌ಗಳಿಗೆ, HDS ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. ಇದು ಪ್ರಸಾರದ ಸಮಯದಲ್ಲಿ ಕನಿಷ್ಠ ವಿಳಂಬವನ್ನು ಒದಗಿಸುತ್ತದೆ, HLS ನಂತೆ, ಇದು ಮಾಧ್ಯಮ ಫೈಲ್‌ಗಳನ್ನು ಸಣ್ಣ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ, ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮತ್ತು DRM ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಮೈಕ್ರೋಸಾಫ್ಟ್ ಸ್ಮೂತ್ ಸ್ಟ್ರೀಮಿಂಗ್

ಮೈಕ್ರೋಸಾಫ್ಟ್ ತನ್ನದೇ ಆದ ಆನ್‌ಲೈನ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸಿದೆ, ಮೈಕ್ರೋಸಾಫ್ಟ್ ಸ್ಮೂತ್ ಸ್ಟ್ರೀಮಿಂಗ್. MSS ಉತ್ತಮ ಗುಣಮಟ್ಟದಲ್ಲಿ ವಿಷಯವನ್ನು ತಲುಪಿಸಲು ಹೊಂದಾಣಿಕೆಯ ಬಿಟ್ರೇಟ್ ಅನ್ನು ಸಹ ಬಳಸುತ್ತದೆ.

ಅಡಾಪ್ಟಿವ್ ಬಿಟ್ರೇಟ್ ಪ್ರಸಾರವನ್ನು 2008 ರಲ್ಲಿ ಪರಿಚಯಿಸಲಾಯಿತು. 2008 ರ ಬೇಸಿಗೆ ಒಲಿಂಪಿಕ್ಸ್ ಅನ್ನು ಪ್ರಸಾರ ಮಾಡಲು MSS ಅನ್ನು ಬಳಸಲಾಯಿತು. ಈ ರೀತಿಯ ಪ್ರಸಾರದ ಮುಖ್ಯ ಬಳಕೆದಾರ XBox One ವೇದಿಕೆಯಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, MSS ಇಂದು ಕಡಿಮೆ ಜನಪ್ರಿಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

MPEG-ಡ್ಯಾಶ್

ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇತ್ತೀಚಿನ ಮಹತ್ವದ ಪರಿಹಾರವೆಂದರೆ MPEG-DASH, ಇಲ್ಲಿ DASH ಎಂದರೆ HTTP ಮೂಲಕ ಡೈನಾಮಿಕ್ ಅಡಾಪ್ಟಿವ್ ಸ್ಟ್ರೀಮಿಂಗ್.

MPEG-DASH ನ ಪ್ರಯೋಜನವೆಂದರೆ ಅದು HTTP ಮೂಲಕ ಮಾಧ್ಯಮ ಪ್ರಸಾರಕ್ಕಾಗಿ ಏಕೀಕೃತ ಅಂತಾರಾಷ್ಟ್ರೀಯ ಮಾನದಂಡವಾಗಿ ಗುರುತಿಸಲ್ಪಟ್ಟಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಇದು ಇನ್ನೂ ವ್ಯಾಪಕವಾಗಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಪ್ರಸಾರಕರು ಅದನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಆದರೆ, ಎಲ್ಲಾ ಖಾತೆಗಳ ಪ್ರಕಾರ, ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ ಈ ನಿರ್ದಿಷ್ಟ ಮಾನದಂಡವು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಸಾರ ಪ್ರೋಟೋಕಾಲ್ ಆಗುತ್ತದೆ.

MPEG-DASH ಕೊಡೆಕ್ ಪ್ರಕಾರವನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ, ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮಾಧ್ಯಮವನ್ನು ಕಳುಹಿಸಲು ನೀವು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದು - H.264, HEVC/H.265, VP10

ಆನ್‌ಲೈನ್ ಪ್ರಸಾರಕ್ಕಾಗಿ HLS ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು

ಸಾರ್ವಕಾಲಿಕ HLS ಅನ್ನು ಬಳಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಇದು ಅತ್ಯಂತ ಆಧುನಿಕ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿ ಬೆಂಬಲಿತ ಮಾಧ್ಯಮ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ನೀವು ಮೊಬೈಲ್ ಸಾಧನಗಳಿಗೆ ಪ್ರಸಾರ ಮಾಡಲು ಬಯಸಿದರೆ ನೀವು ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸ್ಥಳೀಯ HTML5 ಪ್ಲೇಯರ್ ಬೆಂಬಲ ಮತ್ತು, ಸಹಜವಾಗಿ, ಹೊಂದಾಣಿಕೆಯ ಬಿಟ್ರೇಟ್ ಅತ್ಯುತ್ತಮ ವೀಕ್ಷಣೆ ಗುಣಮಟ್ಟವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, RTMP ಗೆ ಹೋಲಿಸಿದರೆ ವೀಡಿಯೊಗೆ ಉತ್ತಮ ಸಾರಿಗೆ HLS ಆಗಿದೆ. ಇದಕ್ಕೆ ಕಾರಣಗಳು:

nginx ಮೂಲಕ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದರೊಂದಿಗೆ ಅತ್ಯಂತ ಸರಳವಾದ ಪ್ರಾಕ್ಸಿಯಿಂಗ್. ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ, ಏಕೆಂದರೆ ಕ್ಯಾಮೆರಾ, ಸಾಧನವಾಗಿ, ನಿಯಮದಂತೆ, 10 ಕ್ಕೂ ಹೆಚ್ಚು ಸಂಪರ್ಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಅರ್ಥದಲ್ಲಿ, RTMP ಸ್ಟ್ರೀಮ್‌ಗಳ ಖಾತರಿ ಪ್ರಾಕ್ಸಿಯಿಂಗ್ ಪಾವತಿ ಪರಿಹಾರಗಳ ಮೂಲಕ ಮಾತ್ರ ಸಾಧ್ಯ ಮತ್ತು ದೊಡ್ಡ ಸಾಮರ್ಥ್ಯಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ವಿಶೇಷ ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅಗತ್ಯವಿಲ್ಲ.

ಸಂಪೂರ್ಣ ಸರ್ವರ್ ಮೂಲಸೌಕರ್ಯದ ಸರಳೀಕರಣ. ಕಲ್ಪನೆಯ ಕಾರಣದಿಂದ, ವೀಡಿಯೊವನ್ನು http ಮೂಲಕ ಪೋರ್ಟ್ 80 ಮೂಲಕ ತುಂಡುಗಳಾಗಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸ್ಥಿರ ಡೇಟಾವನ್ನು ತಲುಪಿಸಲು Nginx ಸ್ವತಃ ಜವಾಬ್ದಾರರಾಗಿರಬಹುದು. ಸ್ಥಿರ ಫೈಲ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವುದು (ಪ್ರತಿ 50 kB ಯ ವೀಡಿಯೊ ತುಣುಕುಗಳು) nginx ಗೆ ತುಂಬಾ ಸುಲಭವಾದ ಕೆಲಸವಾಗಿದೆ.

ಬ್ರೌಸರ್‌ನಿಂದ ನೇರವಾಗಿ ಹೆಚ್ಚಿನ ಮೊಬೈಲ್ ಸಾಧನಗಳು, ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಳು ಮತ್ತು ಟ್ಯಾಬ್ಲೆಟ್‌ಗಳಿಗೆ ಬೆಂಬಲ.

ತಾತ್ವಿಕವಾಗಿ RTSP ಮೂಲಕ ಪ್ರಸಾರ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸರಳವಾಗಿದೆ. ಪುಶ್ (ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ರಕಟಿಸುವುದು) ಅಥವಾ ಪುಲ್ (ಸ್ಟ್ರೀಮ್ ಸ್ವೀಕರಿಸುವುದು) ನಂತಹ ಯಾವುದೇ ಕಾರ್ಯವಿಧಾನಗಳಿಲ್ಲದ ಕಾರಣ.

ಹೆಚ್ಚು http ಸ್ನೇಹಿ ಸ್ವರೂಪ.

ಅನಾನುಕೂಲಗಳು ಈ ಕೆಳಗಿನಂತಿವೆ:

ಇನ್ನೂ, ಎಲ್ಲಾ ಸಾಧನಗಳು ಈ ಸ್ವರೂಪವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. 4.2 ಕ್ಕಿಂತ ಕಡಿಮೆ Android ಆವೃತ್ತಿಗಳು ಅಧಿಕೃತವಾಗಿ H.264 ಕೊಡೆಕ್ ಮತ್ತು ಸಾರಿಗೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದರೆ Android ನಲ್ಲಿ, ಬ್ರೌಸರ್ ಬದಲಿಗೆ, ನೀವು ವೀಕ್ಷಣೆಗಾಗಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸಬಹುದು - ಉದಾಹರಣೆಗೆ MX ಪ್ಲೇಯರ್

ಇದು ಎಲ್ಲಾ ಕ್ಯಾಮೆರಾವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಕ್ಯಾಮರಾ ದೋಷಯುಕ್ತವಾಗಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ Dlink DCS-3010, ನಂತರ ಇಡೀ ಸಿಸ್ಟಮ್ ತುಂಬಾ ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ffmpeg ನಿರಂತರವಾಗಿ ಬೀಳುತ್ತದೆ). ಉದಾಹರಣೆಗೆ, AXIS M1011-W, HIKVISION DS-2CD2412F-IW ಕ್ಯಾಮೆರಾಗಳು ಈ ಸಂಯೋಜನೆಯಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ (ದೂರುಗಳಿಲ್ಲದೆ ಒಂದು ತಿಂಗಳವರೆಗೆ (ನಾನು ಅದನ್ನು ಹೆಚ್ಚು ಕಾಲ ಪರೀಕ್ಷಿಸಲಿಲ್ಲ)). ಕೇಬಲ್ ರೂಟಿಂಗ್ ಕೂಡ ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ. ಈ ಅರ್ಥದಲ್ಲಿ, ನಾವು ಆದರ್ಶ ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ.

HLS ಸಾರಿಗೆ ಎಂದರೇನು

h.264 ಎನ್‌ಕೋಡಿಂಗ್‌ನಲ್ಲಿನ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್ (ಮೂಲಕ: ಪ್ರೊಫೈಲ್ ಬೇಸ್‌ಲೈನ್ ಅನ್ನು Android ಸಾಧನಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ), *.ts ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ತುಂಡುಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ 5 ಸೆಕೆಂಡುಗಳು, ಲೈವ್.m3u8 ನಲ್ಲಿ ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ. ಈ ತುಣುಕುಗಳ ಅನುಕ್ರಮ ವಿವರಣೆ. ಪ್ಲೇಪಟ್ಟಿಯ ಉದ್ದವು ಪೂರ್ವನಿರ್ಧರಿತವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ 10 ತುಣುಕುಗಳು. ವೀಡಿಯೊದ 11 ನೇ ತುಣುಕು ಕಾಣಿಸಿಕೊಂಡಾಗ, 1 ತುಣುಕು ವೀಡಿಯೊವನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ, ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ಡೆವಲಪರ್‌ಗಳ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು.

ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡಲು, ನಾವು ಸೈಟ್‌ನಲ್ಲಿ ನಾವು ನೋಡಲು ಬಯಸುವ ರೀತಿಯಲ್ಲಿ ಕ್ಯಾಮೆರಾಗಳಿಂದ ಚಿತ್ರವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ, ಇಮೇಜ್ ಫಾರ್ಮ್ಯಾಟ್ ಮತ್ತು ಚಿತ್ರದ ಗುಣಮಟ್ಟ. ನಾವು ಸರ್ವರ್‌ನಲ್ಲಿ ರೀಕೋಡ್ ಮಾಡುವುದಿಲ್ಲ. ಇದಕ್ಕಾಗಿಯೇ ಅಗತ್ಯವಿರುವ ಚಿತ್ರವನ್ನು ಉತ್ಪಾದಿಸಲು ಕ್ಯಾಮೆರಾವನ್ನು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಕ್ಯಾಮೆರಾಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹಲವಾರು ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ನೀವು H.264 ಗಾಗಿ ಒಂದು ಪ್ರೊಫೈಲ್ ಅನ್ನು, HLS ಗಾಗಿ ಮತ್ತು ಎರಡನೆಯದನ್ನು MPEG-DASH ಗಾಗಿ MPEG4 ಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ವಿಶಾಲ ಮತ್ತು ಕಿರಿದಾದ ಇಂಟರ್ನೆಟ್ ಚಾನಲ್‌ಗಾಗಿ ನೀವು ವಿಭಿನ್ನ ಗುಣಗಳನ್ನು ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ನಿಮಗಾಗಿ ಯೋಚಿಸಿ - ನಿಮಗಾಗಿ ನಿರ್ಧರಿಸಿ.

ಪ್ರಮುಖ!ಮರು-ಎನ್ಕೋಡ್ ಮಾಡಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲದ ಚಿತ್ರವನ್ನು ಕ್ಯಾಮರಾ ಔಟ್ಪುಟ್ ಮಾಡಬೇಕು.

ಹೆಚ್ಚಿನ ಹೊರೆಗಾಗಿ ಬ್ಲಾಕ್ ರೇಖಾಚಿತ್ರ

ಕ್ಯಾಮರಾ(rtsp) ----->

-----> ಒಂದು ಸಂಪರ್ಕ FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

----> ದೊಡ್ಡ ಸಂಗ್ರಹದೊಂದಿಗೆ ಮಧ್ಯಂತರ nginx ಪ್ರಾಕ್ಸಿಗೆ ಒಂದು ಸಂಪರ್ಕ =====>

=====> ಅನೇಕ JWPlayer(hls) ಕ್ಲೈಂಟ್‌ಗಳು

ನಮ್ಮ ಸರ್ವರ್ ffmpeg ಅನ್ನು ಕ್ಯಾಮರಾಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು nginx hls ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ನೋಂದಾಯಿಸುತ್ತದೆ. nginx ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ತುಣುಕುಗಳು ಮತ್ತು ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ರಚಿಸುತ್ತದೆ. ನಂತರ ಅದು ಈ ತುಣುಕುಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಗ್ರಾಹಕರು JWPlayer ಬಳಸಿಕೊಂಡು ಪ್ರಾಕ್ಸಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾರೆ.

nginx ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

nginx-rtmp-module ಜೊತೆಗೆ nginx ಅನ್ನು ನಿರ್ಮಿಸೋಣ. ಈ ವಿಧಾನವನ್ನು ಲೇಖನದಲ್ಲಿ ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ.

ನಾವು ಹಲವಾರು ಕ್ಯಾಮೆರಾಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ, ಅವುಗಳನ್ನು ಸರಣಿ ಸಂಖ್ಯೆಯಿಂದ ಭಾಗಿಸಿ. ನಾನು 2 ಕ್ಯಾಮೆರಾಗಳಿಗಾಗಿ nginx ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ವಿವರಿಸುತ್ತೇನೆ. ನಾವು ಸ್ಥಳೀಯ ಸಂಗ್ರಹದಲ್ಲಿ 5 ನಿಮಿಷಗಳ ಕಾಲ ಸ್ಥಿರ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಚಿತ್ರವು 5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಲೋಡ್ ಆಗದಿದ್ದರೆ, ನಾವು ಸ್ಥಿರ ಸ್ಕ್ರೀನ್ ಸೇವರ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ.

# nano /etc/nginx/nginx.conf

nginx ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಪಾದಿಸೋಣ

ಬಳಕೆದಾರ www - ಡೇಟಾ;

ಕೆಲಸಗಾರ_ಪ್ರಕ್ರಿಯೆಗಳು ಸ್ವಯಂ ;

pid/run/nginx. ಪಿಡ್ ; ದೋಷ_ಲಾಗ್ /var/log/nginx/nginx_error. ಲಾಗ್ ಡೀಬಗ್;

env PATH;

ಘಟನೆಗಳು (# multi_accept on ; ) http ( access_log / var / log / nginx / ಪ್ರವೇಶ . ಲಾಗ್ ; ದೋಷ_ಲಾಗ್ / var / log / nginx / ದೋಷ proxy_cache_path / var / www / cache / local level = 1 : 2 keys_zone = nginx_local_cache : 1 m inactive = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; stat (rtmp_stat all; rtmp_stat_stylesheet stat. xsl;) ಸ್ಥಳ / stat. xsl ಅನ್ನು ಬೇರೆ ಸ್ಥಳ ರೂಟ್ / ಇತ್ಯಾದಿ / nginx ಗೆ ಸರಿಸಬಹುದು html ;

cameras_rtmp_applications ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. conf ; )) ಸಂಗ್ರಹಕ್ಕಾಗಿ ಮಾರ್ಗವನ್ನು ರಚಿಸೋಣ # mkdir /var/www/cache/local ಸಂಗ್ರಹಕ್ಕಾಗಿ ಹಕ್ಕುಗಳನ್ನು ಸರಿಪಡಿಸೋಣ: # chmod -R 755 /var/www/cache/local# chown -R www-data:www-data /var/www/cache/local`ಕ್ಯಾಮರಾಗಳಿಗಾಗಿ http ಸ್ಥಳಗಳನ್ನು ರಚಿಸೋಣ: # ನ್ಯಾನೊ ಕ್ಯಾಮೆರಾಗಳು_http_locations.conf; proxy_set_header ಅಧಿಕಾರ "ಮೂಲ" ; ದೋಷ_ಪುಟ 502 504 404 @ fallback_img ;) # ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ನೀಡಿ - /1/hls/live.m3u8 ಅಥವಾ /3/hls/live.m3u8 # ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ 10 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಸ್ಥಳ ~* /hls/ . *\. m3u8 $ ( ಪುನಃ ಬರೆಯಿರಿ "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 ಬ್ರೇಕ್ ; # ಪುನಃ ಬರೆಯುವ ವಿನಂತಿ / 1 / hls / to / hls - 1 / root / tmp / ; ಅವಧಿ 10 ಆಡ್_ಹೆಡರ್ ಸಂಗ್ರಹ - ಸಾರ್ವಜನಿಕ ನಿಯಂತ್ರಣ;# ಕ್ಯಾಮರಾಗಳಿಂದ ವೀಡಿಯೊದ ತುಣುಕನ್ನು ನೀಡಿ - /1/hls/live-12345678.ts ಅಥವಾ /2/hls/live-12345678.ts ಸ್ಥಳೀಯ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ # ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ# ತುಂಡನ್ನು ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ 3 ನಿಮಿಷಗಳ ಕಾಲ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ

ಸ್ಥಳ ~* /hls/ . *\. ts $ ( ಪುನಃ ಬರೆಯಿರಿ "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 ಬ್ರೇಕ್ ; ರೂಟ್ / tmp / ; ಅವಧಿ 3 ಮೀ ; add_header Cache - ಕಂಟ್ರೋಲ್ ಸಾರ್ವಜನಿಕ ;)

ಯಾವುದೇ ಚಿತ್ರ ಇಲ್ಲದಿದ್ದರೆ # ಸ್ಥಳವನ್ನು ಹೆಸರಿಸಲಾಗಿದೆ

ಸ್ಥಳ @ fallback_img (ಮರುಬರೆಯಿರಿ (. +) / ಫಾಲ್ಬ್ಯಾಕ್. jpg ಬ್ರೇಕ್; ರೂಟ್ / ಇತ್ಯಾದಿ / nginx /; ನಮ್ಮ ಕ್ಯಾಮೆರಾಗಳಿಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ rtmp ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ hls ಫೈಲ್ ಅನ್ನು ರಚಿಸೋಣ: # ನ್ಯಾನೊ ಕ್ಯಾಮೆರಾಗಳು_rtmp_applications.confಚಂಕ್_ಗಾತ್ರ 4000 ;ಅಪ್ಲಿಕೇಶನ್ hls_1 ( ಲೈವ್ ಆನ್ ; ಸಿಂಕ್ 10 ms ; exec_static ffmpeg - i rtsp : ನಮ್ಮ ಕ್ಯಾಮೆರಾಗಳಿಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ rtmp ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ hls ಫೈಲ್ ಅನ್ನು ರಚಿಸೋಣ: # ನ್ಯಾನೊ ಕ್ಯಾಮೆರಾಗಳು_rtmp_applications.conf//ನಿರ್ವಾಹಕ:[ಇಮೇಲ್ ಸಂರಕ್ಷಿತ]

:554/live1.sdp -c ನಕಲು -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log;

hls ಆನ್;

hls_path /tmp/hls - 1/ ;

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, ಲೈವ್ - 16602660. ts #EXTINF:5.246, ಲೈವ್ - 17072820.INFts :5.280, ಲೈವ್ - 17544960. ts #EXTINF:5.251, ಲೈವ್ - 18020160. ts #EXTINF:5.228, ಲೈವ್ - 18492750. ts #EXTINF:5.242, ಲೈವ್ - 1896ts3270.

ಕ್ಯಾಮೆರಾಗಳು ಬೀಳುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು

ಗ್ಲಿಚಿ ಕ್ಯಾಮೆರಾವನ್ನು ಬದಲಾಯಿಸುವುದು ಉತ್ತಮ ಪರಿಹಾರವಾಗಿದೆ. ಇದು 90% ಪ್ರಕರಣಗಳಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ನೀವು ಹೇಗಾದರೂ ಮುಂದುವರಿಯಬೇಕಾದರೆ, ಈ ಕೆಳಗಿನ ಪರಿಹಾರವು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಈ ಪರಿಹಾರವು ಎರಡು ಪೂರಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

ಪ್ರತಿ ಕ್ಯಾಮರಾಕ್ಕೆ ಪ್ರತ್ಯೇಕ nginx ಪ್ರಕ್ರಿಯೆಯನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಸ್ಥಿರ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸಲು ಸಾಮಾನ್ಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರನ್ ಮಾಡಿ. ಅಂದರೆ, ಎರಡು ಕ್ಯಾಮೆರಾಗಳಿಗೆ rtmp ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಸಂರಚನೆಗಳನ್ನು ಬರೆಯಿರಿ ಮತ್ತು http ನೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ. ನಂತರ ಗ್ಲಿಚಿ ಕ್ಯಾಮೆರಾ ಒಟ್ಟಾರೆ ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ಕ್ಯಾಮರಾದಿಂದ ಸ್ಟ್ರೀಮ್ ಅದರ ದೋಷಗಳ ಪರಿಣಾಮವಾಗಿ ಅಡ್ಡಿಪಡಿಸಿದರೆ (ಅತಿಯಾಗಿ ಬಿಸಿಯಾಗುವುದು, ಕಳಪೆ ಕೇಸಿಂಗ್, ಸಾಕಷ್ಟು PoE ವಿದ್ಯುತ್ ಸರಬರಾಜು, ಇತ್ಯಾದಿ), ನಂತರ ಕ್ಯಾಮರಾ ಬೀಳುತ್ತದೆ, ffmpeg ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು nginx ವೀಡಿಯೊ ತುಣುಕುಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. . ಮತ್ತು ffmpeg ಪ್ರಕ್ರಿಯೆಯು ಕೊನೆಗೊಂಡಾಗ, nginx ಚಂಕ್ಸ್ ಡೈರೆಕ್ಟರಿಯಿಂದ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ. ಕ್ರಾನ್ ಬಳಸಿ ಫೋಲ್ಡರ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಈ ಕ್ಷಣವನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅಗತ್ಯ nginx ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.

ಪ್ರತಿ ಕ್ಯಾಮರಾಗೆ, /etc/init.d/ ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, nginx ನ ನಕಲು, ಕ್ಯಾಮರಾ_1 ಮತ್ತು ಕ್ಯಾಮರಾ_2 ಎಂದು ಹೆಸರಿಸಲಾಗಿದೆ

# cp /etc/init.d/nginx /etc/init.d/camera_1 # cp /etc/init.d/nginx /etc/init.d/camera_2 # chmod +x /etc/init.d/camera_1 # chmod +x /etc/init.d/camera_2

nginx ಆರಂಭಿಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಂಪಾದಿಸಲಾಗುತ್ತಿದೆ.

nano/etc/init. d/nginx

DAEMON_OPTS ವೇರಿಯೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸಿ. ಮುಖ್ಯ nginx ಡೀಮನ್ ಎಲ್ಲಾ ಸ್ಥಿರ ಡೇಟಾವನ್ನು ಪೂರೈಸುತ್ತದೆ. ಇದು ಕ್ಯಾಮೆರಾಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಡೀಮನ್‌ಗಳನ್ನು ಸಹ ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ನಿಲ್ಲಿಸುತ್ತದೆ./ init . d / camera_1 ಸ್ಟಾಪ್ fi ವೇಳೆ [ - f "/etc/init.d/camera_2" ];

ನಂತರ / ಇತ್ಯಾದಿ / init . d/camera_2 ಸ್ಟಾಪ್ fi

do_reload ಕಾರ್ಯಕ್ಕೆ ಸೇರಿಸಿ:

# ಕ್ಯಾಮರಾಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಿದರೆ [ - f "/etc/init.d/camera_1" ];

ನಂತರ / ಇತ್ಯಾದಿ / init . d / camera_1 fi ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ [ - f "/etc/init.d/camera_2" ];

ನಂತರ / ಇತ್ಯಾದಿ / init . d/camera_2 fi ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ

ನಾವು ಕ್ಯಾಮರಾ 1 ಕ್ಯಾಮರಾ_1 ಮತ್ತು ಕ್ಯಾಮರಾ 2 ಕ್ಯಾಮರಾ_2 ಗಾಗಿ nginx ಲಾಂಚ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡುತ್ತೇವೆ.

# nano /etc/init.d/camera_1

DAEMON_OPTS ಮತ್ತು DESC ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿ

DESC = "CAMERA-1 ಗಾಗಿ ಕ್ಯಾಮರಾ_1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf" ಉದಾಹರಣೆಯನ್ನು ಅನುಸರಿಸಿ ಕ್ಯಾಮರಾ 2 ಕ್ಯಾಮರಾ_2 ಗಾಗಿ nginx ಸ್ಟಾರ್ಟ್ಅಪ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಂಪಾದಿಸೋಣ.

ಅವರು ಸ್ಪೇಸ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ, ಹುಡುಕಲಾದ ಪದ DIR-PROCESS-NAME, ಡೈರೆಕ್ಟರಿ ಮತ್ತು ರೀಬೂಟ್ ಮಾಡಬೇಕಾದ ಪ್ರಕ್ರಿಯೆಯ ಹೆಸರನ್ನು ಸೂಚಿಸುತ್ತಾರೆ.

ಪರೀಕ್ಷೆ:

# ಸೇವಾ nginx ಪ್ರಾರಂಭ # ಸೇವಾ ಕ್ಯಾಮರಾ_1 ಮರುಪ್ರಾರಂಭಿಸಿ * CAMERA ಗಾಗಿ ಕ್ಯಾಮರಾ_1 ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ - 1 ಕಾನ್ಫಿಗರೇಶನ್ nginx # ಸೇವಾ ಕ್ಯಾಮರಾ_2 ಮರುಪ್ರಾರಂಭಿಸಿ * CAMERA ಗಾಗಿ ಕ್ಯಾಮರಾ_2 ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ - 2 ಕಾನ್ಫಿಗರೇಶನ್ nginx

ಕ್ಯಾಮೆರಾಗಳನ್ನು ರೀಬೂಟ್ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್. ಇದು ತುಣುಕುಗಳೊಂದಿಗೆ ಫೋಲ್ಡರ್‌ಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಯಾವುದೇ *.m3u8 ಫೈಲ್‌ಗಳಿಲ್ಲದವರನ್ನು ಹುಡುಕುತ್ತದೆ. ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಫೈಲ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, DIR-PROCESS-NAME ಸಾಲನ್ನು ಬಳಸಿಕೊಂಡು ಮುಖ್ಯ ಡೀಮನ್‌ನ ಸಂರಚನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅನುಗುಣವಾದ ಡೀಮನ್‌ಗಾಗಿ ಅದು ಹುಡುಕುತ್ತದೆ. ಅದನ್ನು ರೀಬೂಟ್ ಮಾಡುತ್ತದೆ.

# nano /script/cameras_reloader.sh

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#!/bin/bash PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin mask = "*.m3u8" dir = "/tmp/ hls-*" ಫಂಕ್ಷನ್ find_process())( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) ಗಾಗಿ $dir ನಲ್ಲಿ hls_dir; ಡು find_result = $(ಹುಡುಕಿ $hls_dir -ಹೆಸರು $ಮಾಸ್ಕ್ -ಟೈಪ್ ಎಫ್) ವೇಳೆ [ -z $find_result ] ; ನಂತರ ಪ್ರಕ್ರಿಯೆ = $(find_process $hls_dir) ಸೇವೆ $process ಮರುಪ್ರಾರಂಭಿಸಿ 15s ನಿದ್ದೆ ಮುಗಿದಿದೆ

MPEG-DASH ನೊಂದಿಗೆ HLS ನ ಹೋಲಿಕೆ

MPEG-DASH ಎನ್ನುವುದು MPEG-4 ಗಾಗಿ ಸಾರಿಗೆಯಾಗಿ Google ನಿಂದ ರಚಿಸಲ್ಪಟ್ಟ HLS ನ ಅನಲಾಗ್ ಆಗಿದೆ. ಈ ಸಾರಿಗೆಯು ವ್ಯಾಪಕವಾಗಿಲ್ಲ ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಅವರ ವಿಚಾರಧಾರೆ ಒಂದೇ, ಸ್ಟ್ರೀಮ್ ಅನ್ನು ತುಂಡುಗಳಾಗಿ ಒಡೆಯಿರಿ, ಅಲ್ಲಿ ಮಾತ್ರ ಹೆಚ್ಚು ತುಣುಕುಗಳು, ವೀಡಿಯೊಗೆ ಪ್ರತ್ಯೇಕ ತುಣುಕುಗಳು, ಆಡಿಯೊಗೆ ಪ್ರತ್ಯೇಕ. nginx-rtmp-module ನಲ್ಲಿ ಈ ಸ್ವರೂಪವನ್ನು HLS ನಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ಪ್ರಯತ್ನಿಸಿ, ನಕಲಿಸಿ, ಧೈರ್ಯ ಮಾಡಿ!

ಲೇಖನವು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿದ್ದರೆ, ದಯವಿಟ್ಟು ಜಾಹೀರಾತಿನ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿ. ಧನ್ಯವಾದಗಳು!

ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದು IP ದೂರದರ್ಶನಇಂಟರ್ನೆಟ್ ಮತ್ತು ಸ್ಥಳೀಯ ಕಂಪ್ಯೂಟರ್ ನೆಟ್ವರ್ಕ್ಗಳ ಮೂಲಕ ಹೆಚ್ಚು ವ್ಯಾಪಕವಾದ ರೂಪಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಿದೆ. ಸಿಐಎಸ್ ದೇಶಗಳಲ್ಲಿ ವೀಡಿಯೊವನ್ನು ಪ್ರಸಾರ ಮಾಡದ ಯಾವುದೇ ದೊಡ್ಡ ಪೂರೈಕೆದಾರರು ಉಳಿದಿಲ್ಲ ಬಹುಪ್ರಸಾರಅವರ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ, ಅಂದರೆ ಸೇವೆಯನ್ನು ಒದಗಿಸುವುದು IPTV. ಆದರೆ ನಿಮ್ಮ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನ ಹೊರಗೆ ಟಿವಿ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದು ಕೆಲವು ಹಾರ್ಡ್‌ವೇರ್ ವೆಚ್ಚಗಳು ಮತ್ತು ಅಗತ್ಯವಿರುವ ಪ್ರಸಾರದ ಗುಣಮಟ್ಟವನ್ನು ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳುವ ತೊಂದರೆಗೆ ಸಂಬಂಧಿಸಿದೆ.

HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ಎಂದೂ ಕರೆಯುತ್ತಾರೆ ಎಚ್.ಎಲ್.ಎಸ್., ಇದು ಆಪಲ್ನಿಂದ ಅಳವಡಿಸಲಾದ ಸಂವಹನ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಇದರ ವಿಶಿಷ್ಟತೆಯೆಂದರೆ ಒಟ್ಟಾರೆ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸಣ್ಣ ಡೌನ್‌ಲೋಡ್ ಫೈಲ್‌ಗಳ ಅನುಕ್ರಮವಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಪ್ರತಿ ಡೌನ್‌ಲೋಡ್ ಸಾರಿಗೆ ಸ್ಟ್ರೀಮ್‌ನ ಒಂದು ಸಣ್ಣ ತುಣುಕನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ಲೇ ಮಾಡಿದಾಗ, ಕ್ಲೈಂಟ್ ವಿಭಿನ್ನ ಬಿಟ್ ದರಗಳಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಲಾದ ಒಂದೇ ವಸ್ತುವನ್ನು ಹೊಂದಿರುವ ಹಲವಾರು ವಿಭಿನ್ನ ಪರ್ಯಾಯ ಸ್ಟ್ರೀಮ್‌ಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಇದು ಲಭ್ಯವಿರುವ ಬಿಟ್ ದರಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸ್ಟ್ರೀಮಿಂಗ್ ಸೆಶನ್‌ನ ಪ್ರಾರಂಭದಲ್ಲಿ, ಲಭ್ಯವಿರುವ ವಿವಿಧ ಸಬ್‌ಸ್ಟ್ರೀಮ್‌ಗಳಿಗಾಗಿ ಮೆಟಾಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ವರ್ಧಿತ M3U (m3u8) ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ಲೋಡ್ ಮಾಡಲಾಗಿದೆ. ವಿನಂತಿಗಳು ಪ್ರಮಾಣಿತ HTTP ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾತ್ರ ಬಳಸುವುದರಿಂದ, HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ RTP ಯಂತಹ UDP ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿ ಪ್ರಮಾಣಿತ HTTP ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅನುಮತಿಸುವ ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

HLS HTTP ಅನ್ನು ಆಧರಿಸಿದೆ. HLS AES ಬಳಸಿಕೊಂಡು ಪ್ರಮಾಣಿತ ಗೂಢಲಿಪೀಕರಣ ಕಾರ್ಯವಿಧಾನವನ್ನು ಮತ್ತು HTTPS ಅಥವಾ HTTP ಕುಕೀಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಭದ್ರತಾ ಕೀ ವಿತರಣಾ ವಿಧಾನವನ್ನು ಸಹ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಇದು ಒಟ್ಟಾಗಿ ಸರಳ ಹಕ್ಕುಸ್ವಾಮ್ಯ ರಕ್ಷಣೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

HLS ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

ಈ ತಂತ್ರಜ್ಞಾನದ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳು ಯಾವುವು ಎಂಬುದನ್ನು ಈಗ ಕಂಡುಹಿಡಿಯೋಣ. ಅನುಕೂಲಗಳು ನಿಸ್ಸಂದೇಹವಾಗಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಇದು ಮೊದಲನೆಯದಾಗಿ, ಲೈನ್ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಸಾಧನದ ಗುಣಲಕ್ಷಣಗಳಿಗೆ ಡೇಟಾ ಪ್ರಸರಣ ವೇಗದ ಹೊಂದಾಣಿಕೆ, ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಅಂತರ್ನಿರ್ಮಿತ ಹಕ್ಕುಸ್ವಾಮ್ಯ ರಕ್ಷಣೆ ಕಾರ್ಯವಿಧಾನಗಳು. ಮೂರನೆಯದಾಗಿ, ಅಗಲ ನಿರ್ಬಂಧಗಳೊಂದಿಗೆ ಯಾವುದೇ ರೂಟರ್ ಅಗತ್ಯವಿಲ್ಲ ಮಲ್ಟಿಕಾಸ್ಟ್ ಸ್ಟ್ರೀಮ್ WI_FI ಮೂಲಕ, ಇದು ಮಲ್ಟಿಕಾಸ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು IP ದೂರದರ್ಶನ ಪ್ರಸಾರದ ಸಂದರ್ಭದಲ್ಲಿ ಮಲ್ಟಿಕಾಸ್ಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳ ಮೂಲಕ ಸಂಪೂರ್ಣ ಚಾನಲ್ ಅಗಲವನ್ನು ಹೀರಿಕೊಳ್ಳುವುದನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕಾರ್ಯದೊಂದಿಗೆ ಹೆಚ್ಚುವರಿ ಸಾಧನದ ಅಗತ್ಯವಿಲ್ಲ UDP ಪ್ರಾಕ್ಸಿಮಲ್ಟಿಕಾಸ್ಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು HTTP ಗೆ ಪರಿವರ್ತಿಸಲು, ಇದು ಮೊಬೈಲ್ ಸಾಧನಗಳಿಗೆ ಹೆಚ್ಚಾಗಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ, ಆದರೂ ಇದು ರೂಟರ್ ಅಥವಾ ಚಂದಾದಾರರ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ UDP ಪ್ರಾಕ್ಸಿ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವ ಇತರ ಸಾಧನದಲ್ಲಿನ ಹಾರ್ಡ್‌ವೇರ್ ಲೋಡ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. HLS ಮಾನದಂಡವು ಸಾಕಷ್ಟು ವ್ಯಾಪಕವಾಗಿದೆ ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲಾ ಆಧುನಿಕ ವೀಡಿಯೊ ಪ್ಲೇಯರ್‌ಗಳು ಮತ್ತು IPTV ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ.

IPTV ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್

ಒಂದು ಗಮನಾರ್ಹ ಅನನುಕೂಲವೆಂದರೆ ಚಂದಾದಾರರು ಮಲ್ಟಿಮೀಡಿಯಾ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳು ಮತ್ತು ಸ್ಮಾರ್ಟ್-ಟಿವಿ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳನ್ನು ಹಳತಾದ ಫರ್ಮ್‌ವೇರ್ ಅಥವಾ ಹಳತಾದ ವಿನ್ಯಾಸಗಳೊಂದಿಗೆ HLS ಮಾನದಂಡಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಅಥವಾ ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಅಲ್ಲದೆ, ವಿನಂತಿಸಿದ ವೀಡಿಯೊ ತುಣುಕಿನ ಅವಧಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದ ಮಧ್ಯಂತರದಲ್ಲಿ ಸಾಲಿನ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬದಲಾಯಿಸುವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸ್ಥಿರ ಪ್ರಸಾರಕ್ಕಾಗಿ ಗುಣಮಟ್ಟವನ್ನು ಸರಿಯಾಗಿ ಆಯ್ಕೆ ಮಾಡಲು ಅಸಮರ್ಥತೆ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ನೈಜ ಸಮಯದಲ್ಲಿ ಆನ್‌ಲೈನ್ ಪ್ರಸಾರಗಳನ್ನು ಸಂಘಟಿಸಲು, ಬೇಡಿಕೆಯ ಮೇಲೆ ವೀಡಿಯೊ (vod), ಹಾಗೆಯೇ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು, ನೀವು nginx ಅನ್ನು nginx-rtmp-module ಮಾಡ್ಯೂಲ್ ಜೊತೆಗೆ ಬಳಸಬಹುದು.

ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳು

ಇಂದು ಹಲವಾರು ಜನಪ್ರಿಯ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳಿವೆ, ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ನೀವು ಹೆಚ್ಚು ಓದಬಹುದು. ನೈಜ ಸಮಯದಲ್ಲಿ ಆನ್‌ಲೈನ್ ಪ್ರಸಾರಗಳನ್ನು ರಚಿಸಲು ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳ ಅಗತ್ಯವಿದೆ.

ವಿವಿಧ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪಾವತಿಸಿದ ಮತ್ತು ಉಚಿತ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳು ಇವೆ. ಇಂದು ನಾವು ಒಂದು ಉಚಿತ ಮತ್ತು ಉತ್ತಮ ಪರಿಹಾರದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.

Ngnix-rtmp

ಮೀಡಿಯಾ ಸರ್ವರ್‌ನ ಮೂಲಭೂತ ಕಾರ್ಯವನ್ನು ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಬಳಸಿಕೊಂಡು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು - Ngnix-rtmp-ಮಾಡ್ಯೂಲ್ ಮಾಡ್ಯೂಲ್, ಇದು ಪ್ರಸ್ತುತ RTMP ಮತ್ತು HLS ನಂತಹ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಹೀಗಾಗಿ, Ngnix-rtmp (Ngnix ವೆಬ್ ಸರ್ವರ್ + Ngnix-rtmp- ಮಾಡ್ಯೂಲ್ ಮಾಡ್ಯೂಲ್) ಬಳಸಿ, ನೀವು ಬಳಕೆದಾರರ ಸಾಧನಗಳಿಗೆ RTMP ಮತ್ತು HLS ಮೂಲಕ ಪ್ರಸಾರವನ್ನು ಆಯೋಜಿಸಬಹುದು. ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಸಾಧನಗಳ ಸಾರಾಂಶ ಕೋಷ್ಟಕವನ್ನು ಲೇಖನದಲ್ಲಿ ಕಾಣಬಹುದು. ಅಲ್ಲದೆ, ನನ್ನ ಭವಿಷ್ಯದ ಲೇಖನಗಳಲ್ಲಿ, ನಾನು Ngnix-rtmp- ಮಾಡ್ಯೂಲ್ ಮತ್ತು ಇತರ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳ ಕ್ರಿಯಾತ್ಮಕತೆಯ ಹೋಲಿಕೆ ಕೋಷ್ಟಕವನ್ನು ಮಾಡಲು ಯೋಜಿಸುತ್ತೇನೆ.

HLS ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಆನ್‌ಲೈನ್ ಪ್ರಸಾರ

Nginx-rtmp-module ಅನ್ನು ಬಳಸಿಕೊಂಡು HLS ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಡಾಪ್ಟಿವ್ ಬಿಟ್ರೇಟ್‌ನೊಂದಿಗೆ ಸರಳ ಪ್ರಸಾರವನ್ನು ಹೇಗೆ ಆಯೋಜಿಸುವುದು ಎಂದು ಇಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಅಧಿಕೃತ ವೆಬ್‌ಸೈಟ್‌ನಿಂದ Nginx ವೆಬ್ ಸರ್ವರ್‌ನ ಮೂಲ ಕೋಡ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಕೆಳಗೆ ನೀಡಲಾದ ಎಲ್ಲಾ ಆಜ್ಞೆಗಳನ್ನು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ.

• wgethttp://nginx.org/download/nginx-1.4.1.tar.gz

ಆರ್ಕೈವ್‌ನಿಂದ ಫೈಲ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ.

• tar -zxvf nginx-1.4.1.tar.gz

nginx-rtmp-module ಮಾಡ್ಯೂಲ್‌ನ ಮೂಲ ಫೈಲ್‌ಗಳೊಂದಿಗೆ zip ಆರ್ಕೈವ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಆರ್ಕೈವ್‌ನಿಂದ ಫೈಲ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ.

• wget https://github.com/arut/nginx-rtmp-module/archive/master.zip

ಈಗ ನಾವು ಮಾಡ್ಯೂಲ್ನೊಂದಿಗೆ nginx ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಬೇಕಾಗಿದೆ nginx-rtmp-ಮಾಡ್ಯೂಲ್ , ಇದನ್ನು ಮಾಡಲು, nginx ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ, ನೀವು ಆಯ್ಕೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗಿದೆ --ಆಡ್-ಮಾಡ್ಯೂಲ್ ಮೂಲ ಫೈಲ್‌ಗಳ ಸ್ಥಳ nginx-rtmp-ಮಾಡ್ಯೂಲ್ , ಮತ್ತು ನೀವು ಹೆಚ್ಚುವರಿ ಆಯ್ಕೆಯನ್ನು ಸಹ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು ಜೊತೆಗೆ-http_ssl_module .

./configure --add-module=/home/nginx/nginx-rtmp-module-master --with-http_ssl_module

ಸ್ಥಾಪಿಸಲು ಮಾಡಿ

• ಎಲ್ಲವೂ ದೋಷಗಳಿಲ್ಲದೆ ಹೋದರೆ, ನೀವು ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಸರ್ವರ್ ಅನ್ನು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ/usr/local/nginx . nginx.conf ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿದೆ/usr/local/nginx/conf . ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನ rtmp:server ವಿಭಾಗವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ. ಆಲಿಸುವ ನಿಯತಾಂಕವು ಸರ್ವರ್ rtmp ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಪೋರ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• ಮುಂದೆ ನಾವು testlive ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿಸಲು ವಿಭಾಗವನ್ನು ತೆರೆಯುತ್ತೇವೆ. ಇಲ್ಲಿ ನಾವು ಲೈವ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಸೂಚಿಸುತ್ತೇವೆ - ಲೈವ್ ಆನ್ ಪ್ಯಾರಾಮೀಟರ್, ನಾವು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ hls ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ - ಪ್ಯಾರಾಮೀಟರ್‌ನಲ್ಲಿ hls.
• ನಿಯತಾಂಕವನ್ನು ಬಳಸುವುದು hls_path ಸ್ಟ್ರೀಮ್‌ನ ಭಾಗಗಳು (ತುಣುಕುಗಳು) ಇರುವ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಾವು ಹೊಂದಿಸಿದ್ದೇವೆ. ಪ್ರತಿ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್‌ಗೆ ಭಾಗಗಳು (ತುಣುಕುಗಳು) ಪ್ರತ್ಯೇಕ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನೆಲೆಗೊಳ್ಳಲು, ನೀವು ನಿರ್ದೇಶನವನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ hls_ನೆಸ್ಟೆಡ್ ಆನ್ .
• ಮುಂದೆ, ನಿಯತಾಂಕವನ್ನು ಬಳಸಿ ಪ್ರಕಟಿಸಲು ಅವಕಾಶ ನಿಮ್ಮ ಕಂಪ್ಯೂಟರ್‌ನಿಂದ ಮತ್ತು ಪ್ಯಾರಾಮೀಟರ್ ಬಳಸಿ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಪ್ರಕಟಿಸಲು ನಾವು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತೇವೆ ಎಲ್ಲವನ್ನೂ ಪ್ರಕಟಿಸಲು ನಿರಾಕರಿಸು ವೀಡಿಯೊಗಳನ್ನು ಪ್ರಕಟಿಸುವುದನ್ನು ನಾವು ಇತರರನ್ನು ನಿಷೇಧಿಸುತ್ತೇವೆ.
• ಈಗ ವಿಭಾಗವನ್ನು ನೋಡೋಣhttp:ಸರ್ವರ್ . ನಿಯತಾಂಕದಲ್ಲಿ ಕೇಳು ಸರ್ವರ್ ಯಾವ ಪೋರ್ಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುವುದು ಅವಶ್ಯಕhttp ವಿನಂತಿಗಳನ್ನು. ನಾವು ಪೋರ್ಟ್ 8080 ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ. ಮತ್ತು ಉದಾಹರಣೆ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಿಂದ ವಿಭಾಗವನ್ನು ಸರಿಸಿhttp:server:location/hls . ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನ ಎಲ್ಲಾ ನಿರ್ದೇಶನಗಳ ಕುರಿತು ನೀವು ಹೆಚ್ಚು ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಇಲ್ಲಿ ವೀಕ್ಷಿಸಬಹುದು:https://github.com/arut/nginx-rtmp-module/wiki/Directives.
• ಇದು ಸರ್ವರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಸಮಯ. ಇದನ್ನು ಮಾಡಲು ನೀವು ಡೈರೆಕ್ಟರಿಗೆ ಹೋಗಬೇಕು /usr/local/nginx/bin ಮತ್ತು ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ ./nginx .

ಈಗ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ನಾವು ಸರ್ವರ್‌ಗೆ ಮೂರು ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ:

• ಪರೀಕ್ಷೆ 1 256 kbit/s ಬಿಟ್‌ರೇಟ್‌ನೊಂದಿಗೆ,
• ಪರೀಕ್ಷೆ 2 512 kbit/s ಬಿಟ್‌ರೇಟ್‌ನೊಂದಿಗೆ,
• ಪರೀಕ್ಷೆ 3 1024 ಕೆಬಿಪಿಎಸ್ ಬಿಟ್ರೇಟ್‌ನೊಂದಿಗೆ.

HLS ಪ್ರೋಟೋಕಾಲ್ (ಸಾಧನಗಳು: Mac, iPad, iPhone) ಬಳಸುವ ಕ್ಲೈಂಟ್ ಇಂಟರ್ನೆಟ್ ಸಂಪರ್ಕದ ಗುಣಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿ ಸ್ಟ್ರೀಮ್‌ಗಳ ನಡುವೆ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಯಿಸಲು ನಮ್ಮ ಗುರಿಯಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು ನಮಗೆ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅಗತ್ಯವಿದೆ /usr/local/nginx/html ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ m3u8 , ಉದಾಹರಣೆಗೆ playlist.m3u8 , ಈ ಕೆಳಗಿನ ವಿಷಯದೊಂದಿಗೆ:

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-ಸ್ಟ್ರೀಮ್-INF:PROGRAM-ID=1,BANDWIDTH=256000,Resolution=640×480

hls/test1/index.m3u8

#EXT-X-ಸ್ಟ್ರೀಮ್-INF:PROGRAM-ID=1,BANDWIDTH=512000,Resolution=640×480

hls/test2/index.m3u8

#EXT-X-ಸ್ಟ್ರೀಮ್-INF:PROGRAM-ID=1,BANDWIDTH=1024000,Resolution=640×480

hls/test3/index.m3u8

ಪ್ರಸಾರವನ್ನು ವೀಕ್ಷಿಸಿ

ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು, ನೀವು ಈ ಕೆಳಗಿನ ಕೋಡ್ ಅನ್ನು ಸೈಟ್‌ನ ವೆಬ್ ಪುಟದಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

- ನಿಮ್ಮ nginx ಸರ್ವರ್‌ನ IP ವಿಳಾಸ.

[ಪ್ಲೇಪಟ್ಟಿ ಹೆಸರು]- ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ರಚಿಸಲಾದ ಫೈಲ್‌ನ ಹೆಸರು (playlist.m3u8).

ಕೆಳಗೆ ಸರಳ nginx.conf ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನ ಉದಾಹರಣೆಯಾಗಿದೆ.

ಕೆಲಸಗಾರ_ಪ್ರಕ್ರಿಯೆಗಳು 1;

ಸರ್ವರ್ (

ಆಲಿಸಿ 1935;

ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷೆ ಲೈವ್ (

ಬದುಕು;

hls ಆನ್;

hls_path /tmp/hls;

hls_ನೆಸ್ಟೆಡ್ ಆನ್;

10.10.146.148 ಅನ್ನು ಪ್ರಕಟಿಸಲು ಅನುಮತಿಸಿ;

ಎಲ್ಲವನ್ನೂ ಪ್ರಕಟಿಸಲು ನಿರಾಕರಿಸು;

ಸರ್ವರ್ (

ಆಲಿಸಿ 8080;

ಸರ್ವರ್_ಹೆಸರು rtmp_test;

ಅಕ್ಷರ ಸೆಟ್ utf-8;

ಸ್ಥಳ/(

ಮೂಲ html;

ಸೂಚ್ಯಂಕ index.html index.htm;

ಸ್ಥಳ / ಎಚ್ಎಲ್ಎಸ್ (

ವಿಧಗಳು (

ಅಪ್ಲಿಕೇಶನ್/vnd.apple.mpegurl m3u8;

ಅಲಿಯಾಸ್ /tmp/hls;

ತೀರ್ಮಾನ

ಈ ಲೇಖನವನ್ನು ನನ್ನ ಸಹೋದ್ಯೋಗಿ ಎವ್ಗೆನಿ ಪೆಟ್ರೋವ್ ಅವರೊಂದಿಗೆ ಜಂಟಿಯಾಗಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಪ್ರಕಟಿಸಲಾಗಿದೆ. ನಾವು ಈ ಮಾಡ್ಯೂಲ್ (Ngnix-rtmp) ಅನ್ನು ವಿವಿಧ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸುತ್ತೇವೆ. ಯಾರಾದರೂ Ngnix-rtmp, Wowza ಸರ್ವರ್ ಕುರಿತು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಬರೆಯಿರಿ. ನೀವು ಏನನ್ನಾದರೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾದರೆ ಅಥವಾ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಮಲ್ಟಿಮೀಡಿಯಾ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಸಲಹೆಯನ್ನು ಪಡೆಯಬೇಕಾದರೆ, ನೀವು ನನ್ನನ್ನು ಮತ್ತು ನಮ್ಮ ತಂಡವನ್ನು ಸಹ ಸಂಪರ್ಕಿಸಬಹುದು.

ತಾಂತ್ರಿಕವಾಗಿ ಪರಿಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಕಷ್ಟಕರ ಮತ್ತು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಕೆಲಸವಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಉಪಯುಕ್ತ ಮಾಹಿತಿಯು ಅನೇಕ ಮೂಲಗಳಲ್ಲಿ ಹರಡಿರುತ್ತದೆ. ಇದು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, iOS ಗಾಗಿ ವೀಡಿಯೊ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಈ ಲೇಖನವು HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳ ಪೂರ್ಣ ಶ್ರೇಣಿಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಅತ್ಯಂತ ಪ್ರಮುಖ ಮತ್ತು ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಜೊತೆಗೆ ಪ್ರಾಥಮಿಕ ಮೂಲಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದೆ. ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಮತ್ತು ಬಳಕೆದಾರ ಸ್ನೇಹಿ ವೀಡಿಯೊ ಸೇವೆಗಳನ್ನು ರಚಿಸಲು ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಎಲ್ಲಾ ಓದುಗರಿಗೆ ಈ ವಸ್ತುಗಳು ಉಪಯುಕ್ತವಾಗುತ್ತವೆ.

ವೀಡಿಯೊ ಸೇವೆಗಳ ಅನುಕೂಲತೆ ಮತ್ತು ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ವೇಗದ ಉಡಾವಣೆ ಮತ್ತು ರಿವೈಂಡ್ ಮೂಲಕ ಸಾಧಿಸಲಾಗುತ್ತದೆ, ಹಾಗೆಯೇ ಬಫರಿಂಗ್ ಇಲ್ಲದಿರುವುದು. ಉತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು, ಈ ಕೆಳಗಿನ ಕ್ರಿಯೆಗಳ ಸೆಟ್ ಅನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ.

• ಕಡಿಮೆ ಗುಣಮಟ್ಟದ ವೀಡಿಯೊದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ.ವೀಡಿಯೊವನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಕನಿಷ್ಠ ಒಂದು ಭಾಗದ ಅಗತ್ಯವಿದೆ. ಅಂತೆಯೇ, ಒಂದು ಭಾಗದ ಗಾತ್ರವು ಚಿಕ್ಕದಾಗಿದೆ, ವೀಡಿಯೊ ವೇಗವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಪ್ರಾರಂಭದ ಸ್ಟ್ರೀಮ್‌ನ ಬಿಟ್ರೇಟ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮತ್ತು ಭಾಗದ ಅವಧಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ವೇಗವಾದ ವೀಡಿಯೊ ಬಿಡುಗಡೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. 4-8 ಸೆಕೆಂಡುಗಳ ಚಂಕ್ ಅವಧಿಯನ್ನು ಮತ್ತು 200-300 Kbps ನ ಆರಂಭಿಕ ಬಿಟ್ರೇಟ್ ಅನ್ನು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಹೀಗಾಗಿ, ವೀಡಿಯೊವನ್ನು ಪ್ಲೇ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಲು, ಬಳಕೆದಾರರು ಗರಿಷ್ಠ 300 KB ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
• ಪ್ಲೇಪಟ್ಟಿ ಆಪ್ಟಿಮೈಸೇಶನ್.ಪ್ಲೇಪಟ್ಟಿಗಳು ಒಟ್ಟಾರೆ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನ ಗಮನಾರ್ಹ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ವಿಶೇಷವಾಗಿ ಸಣ್ಣ ಭಾಗದ ಗಾತ್ರಗಳು ಮತ್ತು ದೀರ್ಘಕಾಲೀನ ವಿಷಯದೊಂದಿಗೆ (ಹಲವಾರು ಗಂಟೆಗಳು). ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪ್ಲೇಪಟ್ಟಿಗಳನ್ನು ವೀಡಿಯೊ ಪ್ಲೇಯರ್ಗೆ ವರ್ಗಾಯಿಸುವಾಗ, ಅವುಗಳನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲು ಸೂಚಿಸಲಾಗುತ್ತದೆ.
• ಪ್ರಮುಖ ಚೌಕಟ್ಟುಗಳು.ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಕನಿಷ್ಠ ಒಂದು IDR ಫ್ರೇಮ್ ಅನ್ನು ಹೊಂದಲು ಇದು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ, ಮೇಲಾಗಿ ವಿಭಾಗದ ಪ್ರಾರಂಭದಲ್ಲಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಮೂಲಕ ವೀಡಿಯೊವನ್ನು ರವಾನಿಸುವಾಗ, ಪ್ರತಿ 3 ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆಯಾದರೂ ಪ್ರಮುಖ ಚೌಕಟ್ಟುಗಳನ್ನು ರಚಿಸಲು ಸೂಚಿಸಲಾಗುತ್ತದೆ.
• ಟಿಎಸ್ ಓವರ್ಹೆಡ್. HTTP LS MPEG TS ಅನ್ನು ಕಂಟೇನರ್ ಆಗಿ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ TS ಓವರ್ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಬಹಳ ಮುಖ್ಯ (ಕಡಿಮೆ ವೀಡಿಯೊ ಗುಣಮಟ್ಟದೊಂದಿಗೆ 10% ಕ್ಕಿಂತ ಕಡಿಮೆ ಇರಬೇಕು). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಟ್ರಾಫಿಕ್ ಡಂಪ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೈಜ ಬಿಟ್ರೇಟ್‌ಗಳನ್ನು ಅಳೆಯುವುದು ಮತ್ತು ಬಳಸಿದ ಪ್ಯಾಕರ್‌ಗಳನ್ನು (ವಿಭಾಗಗಳು) ಉತ್ತಮಗೊಳಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
• ಪ್ಲೇಪಟ್ಟಿಯಲ್ಲಿ ಟಾರ್ಗೆಟ್ ಅವಧಿಯ ಪ್ಯಾರಾಮೀಟರ್.ಈ ಸೆಟ್ಟಿಂಗ್ ಪ್ರಾರಂಭದ ಸಮಯದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಆದರೆ ಆಪಲ್ ಅದನ್ನು 10 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೊಂದಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಕಡಿಮೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಬಫರಿಂಗ್‌ನ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ ಹೊಂದಿರುವ ಸೆಲ್ಯುಲಾರ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ. 20 ಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಉದ್ದವಾದ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಲು ಸಹ ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ.
• ಡೈನಾಮಿಕ್ ಬಿಟ್ರೇಟ್.ಐಒಎಸ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಅಡಾಪ್ಟಿವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಕಾರ್ಯವಿಧಾನವು ವಿಭಿನ್ನ ಪ್ಲೇಪಟ್ಟಿಯಲ್ಲಿ ನಿಖರವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಬಿಟ್‌ರೇಟ್‌ಗಳಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಪ್ಲೇಲಿಸ್ಟ್‌ನ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಭಿನ್ನ ಬಿಟ್ರೇಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸ್ಟ್ರೀಮ್‌ಗಳಿಗಾಗಿ, ನೀವು ಗರಿಷ್ಠ ಮೌಲ್ಯಕ್ಕೆ ಹತ್ತಿರವಿರುವ ಮೌಲ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರಸ್ತುತ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಬಗ್ಗೆ ತಪ್ಪು ನಿರ್ಧಾರಗಳು ಸಾಧ್ಯ. ನೆರೆಯ ಬಿಟ್ರೇಟ್‌ಗಳು ವೇಗದಲ್ಲಿ 1.5 - 2 ಪಟ್ಟು ಭಿನ್ನವಾಗಿರಬೇಕು.
• ಆಡಿಯೋ ಮಾತ್ರ ಸ್ಟ್ರೀಮ್‌ಗಳು. HE-AAC ಆಡಿಯೊ ಕೊಡೆಕ್ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಾಧನಗಳಿಂದ ಬೆಂಬಲಿತವಾಗಿದೆ. MPEG ಎಲಿಮೆಂಟರಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಆಡಿಯೊ ಮಾತ್ರ ಚಾನಲ್‌ಗಳ ವಿತರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ ಮತ್ತು MPEG ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಸ್ಟ್ರೀಮ್ ಅಲ್ಲ (ಗಮನಾರ್ಹವಾಗಿ ಚಿಕ್ಕದಾದ ಓವರ್‌ಹೆಡ್).

ನಿಮ್ಮ ವೀಡಿಯೊ ಪ್ಲೇಯರ್ ಅನ್ನು ನೀವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದಂತೆ, ನೀವು HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಲಾಗ್ (accessLog) ನಿಂದ ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಬಹುದು. ಇದು ಸ್ವಯಂಚಾಲಿತ ಸ್ವಿಚಿಂಗ್ ಹೇಗೆ ಸಂಭವಿಸಿತು, ಯಾವ ಬಿಟ್ರೇಟ್‌ಗಳನ್ನು ಬಳಸಲಾಗಿದೆ, ಇತ್ಯಾದಿಗಳ ಕುರಿತು ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿದೆ. ಲಾಗ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಮಾಹಿತಿಯ ಕುರಿತು ವಿವರಗಳು. ಈ ಡೇಟಾವನ್ನು ಆಧರಿಸಿ, ನಿಮ್ಮ ಬಳಕೆದಾರರಲ್ಲಿ ನೀವು ವೀಡಿಯೊ ವಿಶ್ಲೇಷಣೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.

ಹೆಚ್ಚುವರಿ ಶಿಫಾರಸುಗಳು
ಆನ್‌ಲೈನ್ ವೀಡಿಯೊ ಪ್ರಸಾರಗಳ ಸಂದರ್ಭದಲ್ಲಿ, CDN ನಲ್ಲಿನ ವಿಳಂಬದಿಂದಾಗಿ ಬಫರಿಂಗ್ ಸಹ ಸಾಧ್ಯವಿದೆ, ಹಾಗೆಯೇ ಪ್ಲೇಪಟ್ಟಿ ನವೀಕರಣ ಸಮಯವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಸಮಯಕ್ಕೆ ವಿಭಾಗಗಳನ್ನು ರಚಿಸಲು ಸರ್ವರ್‌ಗೆ ಸಮಯವಿಲ್ಲ. ರಿವೈಂಡ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು, ಪೂರ್ಣಾಂಕವಲ್ಲದ (ನಿಜವಾದ) ವಿಭಾಗದ ಅವಧಿಯ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ: ಇಲ್ಲದಿದ್ದರೆ ದೋಷವು ಸಂಗ್ರಹವಾಗಬಹುದು.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ವಿಭಿನ್ನ ಸಾಧನಗಳಲ್ಲಿ ಬಳಸಲು ಉದ್ದೇಶಿಸಿದ್ದರೆ, ನೀವು ವಿವಿಧ ಸ್ಕ್ರೀನ್ ರೆಸಲ್ಯೂಶನ್‌ಗಳಲ್ಲಿ ಪಟ್ಟಿಯಲ್ಲಿ ವಿಭಿನ್ನ ವೀಡಿಯೊ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಈ ರೀತಿಯಾಗಿ, ನೀವು ರೆಟಿನಾ ಪ್ರದರ್ಶನದೊಂದಿಗೆ ಐಪ್ಯಾಡ್‌ನಲ್ಲಿ ಮತ್ತು ತುಲನಾತ್ಮಕವಾಗಿ ಹಳೆಯ ಐಫೋನ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ವೀಡಿಯೊಗಳನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡಬಹುದು.

HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ (ಬ್ಯಾಕಪ್ ವೀಡಿಯೊ ಮೂಲಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು). ನಿಮ್ಮ ಸೇವೆಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸಲು ಈ ವೈಶಿಷ್ಟ್ಯವು ಉಪಯುಕ್ತವಾಗಿದೆ.

ಜ್ಞಾನದ ಮೂಲಗಳು
ವೀಡಿಯೊ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಬಳಸುವ ವಸ್ತುಗಳ ಕಿರು ಪಟ್ಟಿ:
HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಡ್ರಾಫ್ಟ್
HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು
HLS ಗಾಗಿ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ಅಂತಿಮವಾಗಿ, WWDC 2012 ರಿಂದ ಉಚಿತ ತಾಂತ್ರಿಕ ವೀಡಿಯೊ ಸೆಷನ್‌ಗಳು ನೋಂದಾಯಿತ Mac/iOS/Safari ಡೆವಲಪರ್‌ಗಳಿಗೆ ಲಭ್ಯವಿವೆ ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ, ಇದು ವೀಡಿಯೊದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಮತ್ತು HTTP ಲೈವ್ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಳಸುವ ಕುರಿತು ಸಾಕಷ್ಟು ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ.