ಸ್ಟ್ರೀಮಿಂಗ್ ಎಚ್ಎಲ್ಎಸ್. HLS ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕು

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

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

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

ಎಚ್ಎಲ್ಎಸ್ ಕೆಲಸದ ತತ್ವ

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

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

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

YouTube ನಂತಹ ಸೈಟ್‌ಗಳನ್ನು ಬಳಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ತನ್ನ ಆನ್‌ಲೈನ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ ವೀಡಿಯೊಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು, ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ವರ್ಗಾಯಿಸುವುದು, ಬಳಕೆದಾರರ ಸಾಧನಗಳಿಗೆ ವೀಡಿಯೊಗಳನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಲು ಯಾವ ವರ್ಗಾವಣೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಅನಿವಾರ್ಯವಾಗಿ ಬರುತ್ತದೆ. ಆಯ್ಕೆಯು ಚಿಕ್ಕದಾಗಿದೆ, ಏಕೆಂದರೆ ಕೆಲವು ಸಾಧನಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಹಲವಾರು ಉದ್ಯಮ ಮಾನದಂಡಗಳಿವೆ. ಇದರ ಜೊತೆಗೆ, ಪ್ರೋಟೋಕಾಲ್ನ ಆಯ್ಕೆಯು ಹೆಚ್ಚಾಗಿ ವೀಡಿಯೊದ "ವರ್ಗ" - ನೇರ ಪ್ರಸಾರ ಅಥವಾ ವೀಡಿಯೊ-ಆನ್-ಡಿಮಾಂಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನಿಮ್ಮ ಮಾಧ್ಯಮ ಯಂತ್ರದ ಎಂಜಿನ್ ಆಗಿರುವ ಮಾಧ್ಯಮ ಸರ್ವರ್‌ನ ಆಯ್ಕೆಯು ಪ್ರೋಟೋಕಾಲ್‌ನ ಆಯ್ಕೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ: ನೀವು ಹಲವಾರು ವೈವಿಧ್ಯಮಯ ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತೀರಾ ಅಥವಾ ಒಂದು ಪರಿಹಾರದ ಆಧಾರದ ಮೇಲೆ ವಿತರಣಾ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಾ? ಆದ್ದರಿಂದ, ನೀವು ಎಲ್ಲವನ್ನೂ ಅಳೆಯಬೇಕು ಮತ್ತು ನಿಮ್ಮ ವ್ಯವಹಾರದ ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

ಸಾಮಾನ್ಯವಾಗಿ, ಅನೇಕ ಅಜ್ಞಾತಗಳೊಂದಿಗೆ ಸಮೀಕರಣವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಯ ಡೈನಾಮಿಕ್ಸ್ ಇಲ್ಲಿ ಮುಖ್ಯವಾಗಿದೆ - ಉದ್ಯಮವು ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿದೆ? ನಾನು ತಂತ್ರಜ್ಞಾನವನ್ನು ಬೆಂಬಲಿಸುವಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿದರೆ ಮತ್ತು ಅದು ಒಂದು ವರ್ಷದಲ್ಲಿ ಸಾಯುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಈಗಾಗಲೇ ಸಂಭವಿಸಿದೆ. ಅಥವಾ ನಾನು ಟ್ರೆಂಡಿ ತಂತ್ರಜ್ಞಾನದ ಮೇಲೆ ಬಾಜಿ ಕಟ್ಟುತ್ತೇನೆ, ಆದರೆ ಯಾರೂ ಅದನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲವೇ?

ಡೈನಾಮಿಕ್ಸ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೋಡಲು - ಕಾಲಾನಂತರದಲ್ಲಿ ವಿಭಿನ್ನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಪಾಲು ಹೇಗೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಕಳೆದ ವರ್ಷದಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ.

ಆರಂಭಿಕ ಡೇಟಾ

ಆರಂಭಿಕರಿಗಾಗಿ, ಮಾರುಕಟ್ಟೆ ಷೇರುಗಳನ್ನು ನಿರ್ಣಯಿಸಲು ನಾವು ಯಾರು? ನಾವು ಮಾಧ್ಯಮ ಸರ್ವರ್‌ಗಳಿಗಾಗಿ ವರದಿ ಮಾಡುವ ವೆಬ್ ಸೇವೆಯ ಡೆವಲಪರ್‌ಗಳು. ನಾವು ನಾಲ್ಕನೇ ವರ್ಷದಿಂದ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಕಂಪನಿಗಳು ವಿಭಿನ್ನ ಮೂಲಸೌಕರ್ಯಗಳು, ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಅಗತ್ಯಗಳೊಂದಿಗೆ ನಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತವೆ. ಇದು ಉದ್ಯಮದ ರಾಜ್ಯದ ಉತ್ತಮ ಪಾತ್ರವನ್ನು ತಿರುಗಿಸುತ್ತದೆ.

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

ವರದಿಯು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಒದಗಿಸುತ್ತದೆ:

2.2 ರಿಂದ ಇತ್ತೀಚಿನ 4.x ವರೆಗಿನ ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳಲ್ಲಿ Wowza ಸ್ಟ್ರೀಮಿಂಗ್ ಎಂಜಿನ್; ಹೆಚ್ಚು - 3.x.
HLS, ಸ್ಮೂತ್, HDS ಮತ್ತು ಪ್ರಗತಿಶೀಲ ಡೌನ್‌ಲೋಡ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವೇಗವುಳ್ಳ ಸ್ಟ್ರೀಮರ್ ನಮ್ಮ ಅಭಿವೃದ್ಧಿಯಾಗಿದೆ.
ವಿಂಡೋಸ್ ಮೀಡಿಯಾ ಸೇವೆಗಳು - ಅವುಗಳಲ್ಲಿ ಅಕ್ಷರಶಃ ಒಂದೆರಡು ಡಜನ್ ಇವೆ, ಆದರೆ ಅವು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು

ಈ ಬರವಣಿಗೆಯ ಸಮಯದಲ್ಲಿ, ಸೇವೆಯು 60 ದೇಶಗಳಿಂದ ಸುಮಾರು 1000 ಸರ್ವರ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ.

ವರದಿಯನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ, ಇದು ಅನುಗುಣವಾದ ಟ್ಯಾಗ್ ಅಡಿಯಲ್ಲಿ ಲಭ್ಯವಿದೆ.

ಹೋಗು

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

ಇದೇ ಅವಧಿಯಲ್ಲಿ ಒಂದು ವರ್ಷದ ಹಿಂದೆ ಏನಾಯಿತು? ಪರಿಸ್ಥಿತಿ ಬಹುತೇಕ ಕನ್ನಡಿ ಚಿತ್ರಣವಾಗಿದೆ. RTMP - ಸುಮಾರು ಮೂರನೇ ಎರಡರಷ್ಟು, RTSP ಮತ್ತು HLS ಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಸ್ಥಾನಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ನಿಜ, ಮಾಪನಗಳ ಆಧಾರವು ಸುಮಾರು 3 ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ - "ಮಾತ್ರ" 500 ಮಿಲಿಯನ್ ವೀಕ್ಷಣೆಗಳು. ನಮ್ಮ ಸೇವೆಯಲ್ಲಿ ಕಡಿಮೆ ಸರ್ವರ್‌ಗಳು ಸಹ ಇದ್ದವು.

ಈ ಎರಡು ಬಿಂದುಗಳ ನಡುವೆ ಹೋಗೋಣ.

ಆದ್ದರಿಂದ, ಜೂನ್ - ಆಗಸ್ಟ್ 2014, ಬೇಸಿಗೆಯ 3 ತಿಂಗಳುಗಳು. 800 ಮಿಲಿಯನ್ ವೀಕ್ಷಣೆಗಳು, ಆದರೆ ಷೇರುಗಳು ಒಂದೇ ಆಗಿವೆ, ಆಗಸ್ಟ್ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ತಂದಿಲ್ಲ.

ಸೆಪ್ಟೆಂಬರ್ - ನವೆಂಬರ್ 2013. ಹೊಸ ಸೀಸನ್ ಪ್ರಾರಂಭವಾಗಿದೆ, HLS RTMP ಯ ಪಾಲನ್ನು ತಿನ್ನಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಒಟ್ಟು 1.1 ಬಿಲಿಯನ್ ವೀಕ್ಷಣೆಗಳು, RTMP ಒಟ್ಟು ಅರ್ಧದಷ್ಟು, HLS ಕಾಲು ಹೊಂದಿದೆ.

ಡಿಸೆಂಬರ್ 2013 - ಫೆಬ್ರವರಿ 2014. 1.4 ಬಿಲಿಯನ್ ವೀಕ್ಷಣೆಗಳು, ಅದರಲ್ಲಿ HLS 40% ಕ್ಕಿಂತ ಹೆಚ್ಚು. ಆರ್‌ಟಿಎಂಪಿ ಮತ್ತು ಆರ್‌ಟಿಎಂಪಿ ಕಾಲು ಷೇರಿಗೆ ಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಸ್ಥಾನವನ್ನು ಹೊಂದಿವೆ. ಸೋಚಿಯಲ್ಲಿನ ಒಲಿಂಪಿಕ್ಸ್ ವೀಕ್ಷಣೆಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ನೀಡಿತು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಪೂರೈಕೆದಾರರು ಎಲ್ಲಾ ಗ್ರಾಹಕರನ್ನು RTSP ಅನ್ನು ಮಾತ್ರ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಎಲ್ಲಾ ವಿಲಕ್ಷಣ ಅಥವಾ ಹಳೆಯ ಸಾಧನಗಳೊಂದಿಗೆ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಒತ್ತಾಯಿಸಿದರು - ಆದ್ದರಿಂದ ಈ ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಜಂಪ್.

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

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

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

ತುಣುಕುಗಳ ಸಂಖ್ಯೆಯು ಸ್ಥಿರವಾಗಿರುವುದರಿಂದ, ಹಳೆಯದನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ, ಹೊಸದನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ, ಹಾರ್ಡ್ ಡ್ರೈವ್ ಎಂದಿಗೂ ಉಕ್ಕಿ ಹರಿಯುವುದಿಲ್ಲ.

ಹರಡುವಿಕೆಯು RTMP ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆ. H.264 ವೀಡಿಯೊ ಎನ್‌ಕೋಡಿಂಗ್‌ನೊಂದಿಗೆ HLS ಅನ್ನು iOS ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ಮನಬಂದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಜುಲೈ 1, 2014 ರಂತೆ, HLS ಸಾರಿಗೆಯೊಂದಿಗೆ ಸ್ಟ್ರೀಮಿಂಗ್ ವೀಡಿಯೊ ಸಂಪರ್ಕಗಳು 55%, RTMP - 26%, RTSP - 15% ಮತ್ತು MPEG-DASH 1% ಕ್ಕಿಂತ ಕಡಿಮೆ.

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

ತಾತ್ವಿಕವಾಗಿ 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. ಪಿಡ್ ; error_log / 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 / ಸ್ಥಳೀಯ ಮಟ್ಟಗಳು = 1: 2 keys_zone = nginx_local_cache: 1 m ನಿಷ್ಕ್ರಿಯ = 30 m max_size = 512 M ; proxy_temp_path / var / www / ಸಂಗ್ರಹ / ಸ್ಥಳೀಯ / # tmp ; stat ಸರ್ವರ್; ಸ್ಥಳ / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat. xsl 50 x .html ;ಸ್ಥಳ = / 50 x .html (ರೂಟ್ html ;) ಕ್ಯಾಮೆರಾಗಳು_http_locations .conf ;)) rtmp ( access_log / var / log / nginx / rtmp_access ಸೂಚನೆ_ವಿಧಾನ ಪಡೆಯಿರಿ ; ಕ್ಯಾಮೆರಾಗಳು_rtmp_ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. 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

ವಿಧಗಳು (ಅಪ್ಲಿಕೇಶನ್ / vnd. apple. mpegurl m3u8; ವೀಡಿಯೊ / mp2t ts;) # ಕ್ಯಾಮರಾದಿಂದ ಚಿತ್ರವನ್ನು ನೀಡಿ 1 - /1/img/ # ಎಲ್ಲಾ ಕ್ಯಾಮೆರಾಗಳಿಗೆ ವಿಭಿನ್ನವಾಗಿದೆ, ಏಕೆಂದರೆ ಕ್ಯಾಮೆರಾ ಐಪಿ ವಿಳಾಸಗಳು ವಿಭಿನ್ನವಾಗಿವೆ "http://192.168.0.2/GetImage.cgi?CH=1"# ಕ್ಯಾಮರಾ 2 ರಿಂದ ಚಿತ್ರವನ್ನು ನೀಡಿ - /2/img/ಸ್ಥಳ / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; ಅವಧಿ 1 ಮೀ ; # 1 ನಿಮಿಷಕ್ಕೆ ಸಂಗ್ರಹ ಆಡ್_ಹೆಡರ್ ಕ್ಯಾಶ್ - ಕಂಟ್ರೋಲ್ ಸಾರ್ವಜನಿಕ "http://192.168.0.3/GetImage.cgi?CH=1"; 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 s ; add_header Cache - ನಿಯಂತ್ರಣ ಸಾರ್ವಜನಿಕ ;) # ಕ್ಯಾಮರಾಗಳಿಂದ ವೀಡಿಯೊದ ತುಣುಕನ್ನು ನೀಡಿ - /1/hls/live-12345678.ts ಅಥವಾ /2/hls/live-12345678.ts ಸ್ಥಳೀಯ ಗಣಕದಲ್ಲಿ # ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ # ತುಣುಕನ್ನು ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ 3 ನಿಮಿಷಗಳ ಕಾಲ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆಸ್ಥಳ ~* / hls / . * \ . ts $ ( ಪುನಃ ಬರೆಯಿರಿ "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 ಬ್ರೇಕ್ ; ರೂಟ್ / tmp / ; ಅವಧಿ 3 ಮೀ ; ಆಡ್_ಹೆಡರ್ ಸಂಗ್ರಹ - ಸಾರ್ವಜನಿಕ ನಿಯಂತ್ರಣ ;) ಯಾವುದೇ ಚಿತ್ರ ಇಲ್ಲದಿದ್ದರೆ # ಸ್ಥಳವನ್ನು ಹೆಸರಿಸಲಾಗಿದೆಸ್ಥಳ @ fallback_img (ಮರುಬರೆಯಿರಿ (. +) / ಫಾಲ್ಬ್ಯಾಕ್. jpg ಬ್ರೇಕ್; ರೂಟ್ / ಇತ್ಯಾದಿ / nginx /;)

ನಮ್ಮ ಕ್ಯಾಮೆರಾಗಳಿಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ rtmp ಸರ್ವರ್‌ಗಾಗಿ hls ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸೋಣ:

# ನ್ಯಾನೊ ಕ್ಯಾಮೆರಾಗಳು_rtmp_applications.conf

ಚಂಕ್_ಗಾತ್ರ 4000 ; ಅಪ್ಲಿಕೇಶನ್ hls_1 ( ಲೈವ್ ಆನ್ ; ಸಿಂಕ್ 10 ms ; exec_static ffmpeg - i rtsp : //ನಿರ್ವಾಹಕ: [ಇಮೇಲ್ ಸಂರಕ್ಷಿತ]: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 / ; # ಸರ್ವರ್‌ನಲ್ಲಿ ತುಣುಕುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮಾರ್ಗ hls_fragment_naming timestamp ; # ಚಂಕ್‌ಗಳನ್ನು ಹೆಸರಿಸಲು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಬಳಸಿ) ಅಪ್ಲಿಕೇಶನ್ hls_2 (ಲೈವ್ ಆನ್; ಸಿಂಕ್ 10 ms; exec_static ffmpeg - i rtsp: //ನಿರ್ವಾಹಕ: [ಇಮೇಲ್ ಸಂರಕ್ಷಿತ].0.3:554/live1.sdp -c ನಕಲು -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls ಆನ್; hls_path / tmp / hls - 2 / ; hls_fragment_naming timestamp ; )

/tmp/hls-1/ ಡೈರೆಕ್ಟರಿಯ ವಿಷಯಗಳು

$ ls / tmp / hls - 1 / ಲೈವ್ - 10458360. ts ಲೈವ್ - 13292010. ts ಲೈವ್ - 16129440. ts ಲೈವ್ - 18963270. ts ಲೈವ್ - 10930050. ts ಲೈವ್ - 1376020ts live - 13767390 - 11405250. ts ಲೈವ್ - 14239260. ts ಲೈವ್ - 17072820. ts ಲೈವ್ . m3u8 ಲೈವ್ - 11878560. ts ಲೈವ್ - 14710860. ts ಲೈವ್ - 17544960. ts ಲೈವ್ - 12348630. ts ಲೈವ್ - 15182550. ts live - 18020160. ts live - 128217 60.5ts live - 128218

ಉದಾಹರಣೆ live.m3u8 ಫೈಲ್

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, ಲೈವ್ - 16602660. ts #EXTINF:5.246, #EXTINFts820.INFts2820.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" ]; ನಂತರ /etc/init. d/camera_2 ಸ್ಟಾಪ್ fi

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

# ಕ್ಯಾಮರಾಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಿದರೆ [ - f "/etc/init.d/camera_1" ]; ನಂತರ /etc/init. d / camera_1 fi ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ [ - f "/etc/init.d/camera_2" ]; ನಂತರ /etc/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 ಸ್ಟಾರ್ಟ್ಅಪ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಂಪಾದಿಸುತ್ತೇವೆ.

http ಸ್ಥಳಗಳೊಂದಿಗೆ /etc/nginx/nginx_0.conf ನಲ್ಲಿ ನಾನು ಮ್ಯಾಜಿಕ್ ಸಾಲುಗಳನ್ನು ಬರೆಯುತ್ತೇನೆ:

# DIR-PROCESS-NAME /tmp/hls-1/camera_1 # DIR-PROCESS-NAME /tmp/hls-2/camera_2

ಅವರು 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 ) hls_dir ಗಾಗಿ $dir ನಲ್ಲಿ; ಡು find_result = $(ಹುಡುಕಿ $hls_dir -ಹೆಸರು $ಮಾಸ್ಕ್ -ಟೈಪ್ ಎಫ್) ವೇಳೆ [ -z $find_result ] ; ನಂತರ ಪ್ರಕ್ರಿಯೆ = $(find_process $hls_dir) ಸೇವೆ $ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ 15 ಸೆ.

HLS ಅನ್ನು MPEG-DASH ಗೆ ಹೋಲಿಸಲಾಗುತ್ತಿದೆ

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

ಪ್ರಯತ್ನಿಸಿ, ನಕಲಿಸಿ, ಅದಕ್ಕೆ ಹೋಗಿ!

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

Flussonic ಮೀಡಿಯಾ ಸರ್ವರ್ HLS ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ವೀಡಿಯೊ ವಿತರಣೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಲಭ್ಯವಿರುವ ಹಲವು ವೈಶಿಷ್ಟ್ಯಗಳು HLS ಗಾಗಿ ಪ್ರಮಾಣಿತವಲ್ಲದವು, ಆದರೆ ನಿಮ್ಮ ಅನುಕೂಲಕ್ಕಾಗಿ ನಾವು ಅವುಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ.

ಬೆಂಬಲಿತ ಕೋಡೆಕ್‌ಗಳು: H264, H265, MPEG2 ವಿಡಿಯೋ, AAC, MP3, MPEG2 ಆಡಿಯೋ, AC-3.

Flussonic ಮೀಡಿಯಾ ಸರ್ವರ್ ನಿಮಗೆ ಲೈವ್ ಟಿವಿ, ವೀಡಿಯೊ ಆನ್ ಡಿಮ್ಯಾಂಡ್, ಆರ್ಕೈವ್‌ನಿಂದ ವೀಡಿಯೊ (ಕ್ಯಾಚ್‌ಅಪ್ ಮತ್ತು ಟೈಮ್‌ಶಿಫ್ಟ್) HLS ಮೂಲಕ ಸ್ವೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಸುಲಭ HLS ಪ್ಲೇಬ್ಯಾಕ್

ನೀವು ಸರಳ ಲೈವ್ ಸ್ಟ್ರೀಮ್ ಅಥವಾ ಫೈಲ್ ಹೊಂದಿದ್ದರೆ (ಒಂದು ವೀಡಿಯೊ, ಒಂದು ಧ್ವನಿ), ನಂತರ HLS ಮೂಲಕ ಪ್ಲೇ ಮಾಡಲು URL ತುಂಬಾ ಸರಳವಾಗಿದೆ:

http://flussonic-ip/STREAMNAME/index.m3u8

ಅಲ್ಲಿ flussonic-ip ನಿಮ್ಮ Flussonic ಮೀಡಿಯಾ ಸರ್ವರ್‌ನ ವಿಳಾಸ + ಪೋರ್ಟ್‌ಗೆ ಉದಾಹರಣೆಯಾಗಿದೆ.

Flussonic ಮೀಡಿಯಾ ಸರ್ವರ್ ಇತರ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಹಿಮ್ಮುಖ ಹೊಂದಾಣಿಕೆಗಾಗಿ URL ನ ಕೊನೆಯಲ್ಲಿ playlist.m3u8 ಅನ್ನು ಸಹ ಸ್ವೀಕರಿಸುತ್ತದೆ.

ನೀವು ಬಹುಭಾಷಾ ಅಥವಾ ಮಲ್ಟಿಬಿಟ್ರೇಟ್ ವಿಷಯದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ವಿಷಯಗಳು ಹೆಚ್ಚು ಜಟಿಲವಾಗುತ್ತವೆ.

ಬಹುಭಾಷಾ HLS

ನೀವು iPhone ನಲ್ಲಿ ನಿಮ್ಮ ಬಹುಭಾಷಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ಲೇ ಮಾಡಲು ಬಯಸಿದರೆ, ನೀವು ಅದೇ http://192.168.2.3:8080/STREAMNAME/index.m3u8 ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ

ಆದರೆ ನೀವು VLC ಅಥವಾ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಬಹುಭಾಷಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ವೀಕ್ಷಿಸಲು ಬಯಸಿದರೆ, ನೀವು video.m3u8 ಅನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ.

ಆಟಗಾರನಿಗೆ URL: http://flussonic-ip/STREAMNAME/video.m3u8

Apple HLS ನ ಅಗತ್ಯತೆಗಳ ಪ್ರಕಾರ, ಪ್ರತಿಯೊಂದು ಭಾಷೆಗೆ ಆಡಿಯೊ ಮಾತ್ರ ಆಯ್ಕೆಯೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಲೇಪಟ್ಟಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು ಎಂಬುದು ಇದಕ್ಕೆ ಕಾರಣ. MPEG-TS ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿದೆ: ಎಲ್ಲಾ ಆಡಿಯೊ ಟ್ರ್ಯಾಕ್‌ಗಳನ್ನು ವೀಡಿಯೊದ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ಲೇಯರ್ ಸ್ವತಃ ಏನನ್ನು ಪ್ಲೇ ಮಾಡಬೇಕೆಂದು ಆರಿಸಿಕೊಳ್ಳುತ್ತಾನೆ. ಐಫೋನ್‌ನಲ್ಲಿ ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸಲು, ಅದು Apple ನ ಮಾರ್ಗಸೂಚಿಗಳನ್ನು ಪೂರೈಸಬೇಕು. ಆದರೆ VLC ಮತ್ತು ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳು, HLS ಮಾನದಂಡವನ್ನು ಉಲ್ಲಂಘಿಸಿ, MPEG-TS ನ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು HLS ಗೆ ಪರಿವರ್ತಿಸುವ ನಿರೀಕ್ಷೆಯಿದೆ. ಆದ್ದರಿಂದ, ನೀವು video.m3u8 ಅನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ.

Apple ಗಾಗಿ "ಆಡಿಯೋ ಮಾತ್ರ" ಸೇರಿಸಲಾಗುತ್ತಿದೆ

ನಿಮ್ಮ ಎಲ್ಲಾ ಸ್ಟ್ರೀಮ್‌ಗಳಿಗೆ ಯಾವುದೇ ವೀಡಿಯೊ, ಆಡಿಯೊ ಮಾತ್ರ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿರುವುದು Apple ಗೆ ಅಗತ್ಯವಿದೆ.

ಬಳಕೆದಾರರು 3G ಯಲ್ಲಿ ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಒಮ್ಮೆ ಅನಿಶ್ಚಿತ ಸ್ವಾಗತದ ವಲಯದಲ್ಲಿ, ಬಫರಿಂಗ್‌ಗಿಂತ ಧ್ವನಿಯನ್ನು ಮಾತ್ರ ಹೊಂದಿರುವುದು ಉತ್ತಮ ಎಂದು ಅವರು ನಂಬುತ್ತಾರೆ.

ನೀವು ಈ ಆಯ್ಕೆಯನ್ನು Flussonic ಮೀಡಿಯಾ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು:

ಸ್ಟ್ರೀಮ್ ort (url udp:// 239.0.0.1 : 1234 ; add_audio_only ;)

ಇದು ನಿಮ್ಮ index.m3u8 ವಿಳಾಸವನ್ನು VLC ಅಥವಾ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಪ್ಲೇ ಮಾಡಲಾಗದಂತೆ ಮಾಡಬಹುದು ಎಂದು ತಿಳಿದಿರಲಿ. ಅಂತಹ ಸಂದರ್ಭದಲ್ಲಿ, video.m3u8 ಅನ್ನು ಬಳಸಿ.

ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಬಿಟ್ರೇಟ್‌ಗಳು

ನೀವು ಬಹು-ಬಿಟ್ರೇಟ್ ಬಹುಭಾಷಾ ವಿಷಯವನ್ನು ಹೊಂದಿರುವಾಗ ಮತ್ತು ಮಲ್ಟಿ-ಬಿಟ್ರೇಟ್ HLS ಪ್ಲೇಪಟ್ಟಿಗಳನ್ನು ಬೆಂಬಲಿಸದ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಅದನ್ನು ಪ್ಲೇ ಮಾಡಲು ಬಯಸಿದಾಗ, ನೀವು ಒಂದು ವೀಡಿಯೊದೊಂದಿಗೆ ವೈಯಕ್ತಿಕ ಪ್ಲೇಪಟ್ಟಿಗಳನ್ನು ವಿನಂತಿಸಬಹುದು ಮತ್ತು ಮೊನೊದಂತೆಯೇ ಫ್ಲುಸೋನಿಕ್ ಮೀಡಿಯಾ ಸರ್ವರ್‌ನಿಂದ ಎಲ್ಲಾ ಆಡಿಯೊ ಟ್ರ್ಯಾಕ್‌ಗಳು ಆಯ್ಕೆ:

http://flussonic-ip/STREAMNAME/video1. m3u8

ಈ ಪ್ಲೇಪಟ್ಟಿ ಬಹು-ಬಿಟ್ರೇಟ್ ಅಲ್ಲ, ಇದು ಮೊದಲ ವೀಡಿಯೊ ಟ್ರ್ಯಾಕ್ ಮತ್ತು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಆಡಿಯೊ ಟ್ರ್ಯಾಕ್‌ಗಳಲ್ಲಿ ವಿಭಾಗಗಳಿಗೆ URL ಅನ್ನು ಒಳಗೊಂಡಿದೆ.

Apple ನ ಬಹು-ಭಾಷಾ ಮಾನದಂಡವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ ಸೆಟ್-ಟಾಪ್ ಬಾಕ್ಸ್‌ಗಳಿಗೆ ಬಹು-ಭಾಷೆ, ಬಹು-ಬಿಟ್ರೇಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ನೀವು ಬಯಸಿದರೆ, video.m3u8 ಬಳಸಿ:

http://flussonic-ip/STREAMNAME/video. m3u8

ಇದು ಬಹು-ಬಿಟ್ರೇಟ್ ಪ್ಲೇಪಟ್ಟಿಯಾಗಿದ್ದು ಅದು ವಿಭಿನ್ನ ಗುಣಗಳೊಂದಿಗೆ ಪ್ಲೇಪಟ್ಟಿಗಳ ಪಟ್ಟಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ: video1.m3u8, video2.m3u8, ಇತ್ಯಾದಿ.

DVR ಕ್ಯಾಚ್‌ಅಪ್ ಪ್ಲೇಬ್ಯಾಕ್

ನಿಮ್ಮ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಈಗಾಗಲೇ ನಮ್ಮ DVR ಮೂಲಕ ಸರ್ವರ್‌ನಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಿದಾಗ, ನೀವು ಪ್ರಸಾರದ ಪ್ರಾರಂಭ ಮತ್ತು ಅಂತಿಮ ಸಮಯವನ್ನು ಬಳಸಿಕೊಂಡು HLS ಮೂಲಕ ವೀಡಿಯೊವನ್ನು ಪ್ಲೇ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, EPG ನಿಂದ).

http://flussonic-ip/STREAMNAME/archive-1508403742-3600. m3u8

ಈ ಪ್ಲೇಪಟ್ಟಿ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಆಡಿಯೊ ಟ್ರ್ಯಾಕ್ ಅಥವಾ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಿಟ್‌ರೇಟ್ ಇದ್ದರೆ ರೂಪಾಂತರ. ಇದು UTC 1362504585 (2013 ಮಾರ್ಚ್ 5 17:29:45 GMT) ಮತ್ತು ಒಂದು ಗಂಟೆ ಮುಂದೆ ಪ್ರಾರಂಭವಾಗುವ ವಿಭಾಗಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

ಮೊನೊ URL mpeg-ts ನಲ್ಲಿ ಎಲ್ಲಾ ಟ್ರ್ಯಾಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ವಿಭಾಗಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ:

http://flussonic-ip/STREAMNAME/mono-1362504585-3600. m3u8

ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದ videoN ಪ್ಲೇಪಟ್ಟಿಯು N ವೀಡಿಯೊ ಟ್ರ್ಯಾಕ್ ಮತ್ತು ಎಲ್ಲಾ ಆಡಿಯೊ ಟ್ರ್ಯಾಕ್‌ಗಳೊಂದಿಗೆ ವಿಭಾಗಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ:

http://flussonic-ip/STREAMNAME/video1-1362504585-3600. m3u8

ಮತ್ತು videoN ಪ್ಲೇಪಟ್ಟಿಗಳ ಪಟ್ಟಿಯೊಂದಿಗೆ ಭಿನ್ನವಾದ ವೀಡಿಯೊ ಪ್ಲೇಪಟ್ಟಿ:

http://flussonic-ip/STREAMNAME/video-1362504585-3600. m3u8

ರಿವೈಂಡ್ ಪ್ಲೇಪಟ್ಟಿ

ವಿಶೇಷ ಪ್ಲೇಪಟ್ಟಿ ಇದೆ "ರಿವೈಂಡ್-N.m3u8" HLS ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ರಿವೈಂಡ್ ಮಾಡಲು ಮತ್ತು ವಿರಾಮಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ದೊಡ್ಡ "ಸ್ಲೈಡಿಂಗ್" ವಿಂಡೋದೊಂದಿಗೆ.

http://flussonic-ip/STREAMNAME/rewind-7200. m3u8

7200 - ಸೆಕೆಂಡುಗಳಲ್ಲಿ HLS ಪ್ಲೇಪಟ್ಟಿ ಉದ್ದ. ಇದರರ್ಥ ನಿಮ್ಮ ಗ್ರಾಹಕರು 2 ಗಂಟೆಗಳ ಕಾಲ ಪ್ರಸಾರವನ್ನು ವಿರಾಮಗೊಳಿಸಬಹುದು ಅಥವಾ ವಿಶೇಷ ಆರ್ಕೈವ್ ಲಿಂಕ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸದೆಯೇ ಫುಟ್‌ಬಾಲ್ ಪಂದ್ಯದ ಆರಂಭಕ್ಕೆ ರಿವೈಂಡ್ ಮಾಡಬಹುದು.