Флюссоник медиа сервер HLS протоколоор дамжуулан видео түгээлтийг дэмждэг.

Олон боломжтой сонголтууд HLS-ийн стандарт биш боловч бид танд тав тухтай байлгах үүднээс тэдгээрийг дэмждэг.

Дэмжигдсэн кодлогч: H264, H265, MPEG2 видео, AAC, MP3, MPEG2 аудио, AC-3.

Flussonic Media Server нь танд HLS-ээр дамжуулан шууд ТВ, хүсэлтээр видео, архиваас видео (барах, цаг шилжүүлэх) хүлээн авах боломжийг олгодог.

HLS хялбар тоглуулах

Хэрэв танд энгийн шууд дамжуулалт эсвэл файл (нэг видео, нэг дуу) байгаа бол HLS-ээр тоглуулах URL нь маш энгийн:

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

Энд flussonic-ip нь таны Flussonic медиа серверийн хаяг + портын жишээ юм.

Flussonic Media Server нь 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 нь өөр механизмтай: бүх аудио замыг видеоны хажууд байрлуулсан бөгөөд тоглуулагч өөрөө юу тоглуулахаа өөрөө сонгодог. Видеог iPhone дээр үзэхийн тулд энэ нь Apple-ийн удирдамжийг хангасан байх ёстой. Гэхдээ HLS стандартыг зөрчиж байгаа VLC болон дээд хайрцагнууд нь MPEG-TS-ийн хуучин хувилбарыг HLS болгон хөрвүүлэхийг хүлээж байна. Тиймээс та видео.m3u8 оруулах хэрэгтэй.

Apple-д зориулж "Зөвхөн аудио"-г нэмж байна

Apple таны бүх дамжуулалтыг зөвхөн видеогүй, зөвхөн аудио сонголттой байхыг шаарддаг.

Хэрэв хэрэглэгч 3G-ээр видео үзэж байгаа бөгөөд тодорхой бус хүлээн авалтын бүсэд орвол буфер хийхээс илүүтэйгээр зөвхөн дуу чимээтэй байх нь дээр гэж тэд үзэж байна.

Та энэ сонголтыг Flussonic Media Server дээр идэвхжүүлж болно:

урсгал ort ( url udp:// 239.0.0.1 : 1234 ; зөвхөн аудио_нэмэх ; )

Энэ нь таны index.m3u8 хаягийг VLC эсвэл тоглуулагч төхөөрөмж дээр тоглуулах боломжгүй болгож болзошгүйг анхаарна уу. Ийм тохиолдолд video.m3u8 ашиглана уу.

Settop box-д зориулсан тусдаа битийн хурд

Хэрэв танд олон битийн хурдтай олон хэл дээрх контент байгаа бөгөөд үүнийг олон битийн хурдтай HLS тоглуулах жагсаалтыг дэмждэггүй дээд хайрцагт тоглуулахыг хүсвэл моно файлын нэгэн адил Flussonic Media Server-с нэг видео болон бүх аудио бичлэг бүхий тус бүр тоглуулах жагсаалт хүсэлт гаргах боломжтой. сонголт:

http://flussonic-ip/STREAMNAME/video1. м3у8

Энэ тоглуулах жагсаалт нь олон битийн хурдтай биш бөгөөд эхний видео бичлэг болон боломжтой бүх аудио бичлэгүүд байгаа сегментүүдийн URL-г агуулдаг.

Хэрэв та Apple-ийн олон хэлний стандартыг ойлгодоггүй тохируулагч төхөөрөмжид олон хэлтэй, олон битийн дамжуулалтыг хүргэхийг хүсвэл video.m3u8-г ашиглана уу:

http://flussonic-ip/STREAMNAME/video. м3у8

Энэ нь тоглуулах жагсаалтын жагсаалтыг өгдөг олон битийн тоглуулах жагсаалт юм өөр өөр чанарууд: video1.m3u8, video2.m3u8 гэх мэт.

DVR барьж тоглуулах

Таны дамжуулалтыг манай DVR сервер дээр аль хэдийн бичсэн бол та дамжуулалтын эхлэх болон дуусах цагийг (жишээлбэл, EPG-ээс) ашиглан HLS-ээр дамжуулан видеог тоглуулах боломжтой.

http://flussonic-ip/STREAMNAME/archive-1508403742-3600. м3у8

Энэ тоглуулах жагсаалт гэж нэрлэгдэх болно. урсгалд нэгээс олон байх тохиолдолд хувилбар дууны замэсвэл нэгээс олон битийн хурд. Энэ нь UTC 1362504585 (2013 оны 3-р сарын 5-ны 17:29:45 GMT)-аас эхэлж, нэг цагийн өмнө сегментүүдийг жагсаах болно.

Mono URL нь mpeg-ts доторх бүх дууг агуулсан сегментүүдийн жагсаалтыг өгөх болно:

http://flussonic-ip/STREAMNAME/mono-1362504585-3600. м3у8

Илүү тодорхой videoN тоглуулах жагсаалт нь N видео бичлэг болон бүх аудио зам бүхий сегментүүдийн жагсаалтыг өгөх болно:

http://flussonic-ip/STREAMNAME/video1-1362504585-3600. м3у8

болон videoN тоглуулах жагсаалтын жагсаалт бүхий хувилбар видео тоглуулах жагсаалт:

http://flussonic-ip/STREAMNAME/video-1362504585-3600. м3у8

Тоглуулах жагсаалтыг эргүүлэх

Тусгай тоглуулах жагсаалт байдаг "буцах-N.m3u8" HLS урсгалыг олон цагийн турш эргүүлж, түр зогсоох боломжийг олгодог том "гулсах" цонхтой.

http://flussonic-ip/STREAMNAME/rewind-7200. м3у8

7200 - HLS тоглуулах жагсаалтын урт секундээр. Энэ нь таны үйлчлүүлэгчид тусгай архивын холбоос руу орохгүйгээр нэвтрүүлгээ 2 цагийн турш түр зогсоох эсвэл хөлбөмбөгийн тэмцээний эхэнд эргүүлэх боломжтой гэсэн үг юм.

YouTube гэх мэт сайтуудыг ашиглахын оронд өөрийн онлайн төсөлд зориулж видео боловсруулж, хадгалах, дамжуулахдаа тэрээр хэрэглэгчдийн төхөөрөмж рүү видео дамжуулахын тулд ямар дамжуулах протокол ашиглах вэ гэсэн асуултанд зайлшгүй гарч ирдэг. Сонголт нь бага, учир нь Тодорхой төхөөрөмжийг дэмждэг хэд хэдэн салбарын стандартууд байдаг. Нэмж дурдахад протоколын сонголт нь видео бичлэгийн "ангилал" -аас ихээхэн хамаардаг - шууд нэвтрүүлэг эсвэл видео бичлэг. Таны медиа машины хөдөлгүүр болох медиа серверийн сонголт нь протоколын сонголтоос хамаарна: та хэд хэдэн ялгаатай серверүүдийг суулгах уу эсвэл нэг шийдэлд суурилсан хүргэх сүлжээг бий болгох уу? Тиймээс бүх зүйлийг дэнсэлж, бизнесийнхээ шалгуураар шийдвэр гаргах хэрэгтэй.

Ерөнхийдөө олон үл мэдэгдэх тэгшитгэлийг олж авдаг. Энд үйл явцын динамик чухал - энэ салбар ерөнхийдөө хаашаа явж байна вэ? Технологийг дэмжихэд хөрөнгө оруулалт хийвэл энэ нь нэг жилийн дараа үхэх болно, учир нь энэ нь аль хэдийн болсон. Эсвэл би загварлаг технологи дээр бооцоо тавих уу, гэхдээ хэн ч үүнийг дэмжихгүй байна уу?

Бид янз бүрийн протоколуудын эзлэх хувь цаг хугацааны явцад хэрхэн өөрчлөгдсөнийг үнэлэхээр шийдсэн - бүх үйл явцыг динамикаар харах. Өнгөрсөн жилийн мэдээллийг авсан.

Анхны өгөгдөл

Эхлээд бид зах зээлийн хувьцааг шүүхээр хэн бэ? Бид медиа серверт зориулсан мэдээлэх вэб үйлчилгээг хөгжүүлэгчид юм. Бид дөрөв дэх жилдээ зах зээл дээр ажиллаж байгаа бөгөөд компаниуд өөр өөр дэд бүтэц, өөр өөр серверийн тоо, өөр өөр хэрэгцээтэй ирдэг. Энэ нь салбарын төлөв байдлын талаар сайн дүр зураг харагдаж байна.

Бид огнооны мужийг сонгож, янз бүрийн протоколоор дамжуулан видео үзсэн тоон график бүхий өгөгдлийг авах боломжтой жижиг тайланг хийсэн.

Тайлан нь серверүүдийн мэдээллийг өгдөг:

• Wowza Streaming Engine 2.2-оос хамгийн сүүлийн үеийн 4.x хүртэлх бүх хувилбарт; хамгийн их - 3.x.
• HLS, Smooth, HDS болон дэвшилтэт таталттай ажилладаг Nimble Streamer нь бидний хөгжүүлэлт юм.
• Windows Media Services - эдгээрийн хэдэн арван нь байдаг, гэхдээ тэдгээр нь байдаг тул бид тэдгээрийг анхаарч үзэх хэрэгтэй.

Үүнийг бичиж байх үед үйлчилгээ нь 60 орны 1000 орчим серверт үйлчилдэг.

Тайлан нь манай блог дээр үе үе шинэчлэгддэг бөгөөд холбогдох шошгон дээр байдаг.

Яв

2014 оны 6/7 сарын тайлан иймэрхүү харагдаж байна. -аас 1.4 тэрбум үзсэнталаас илүү хувь нь HLS байна. Хоёрдугаарт дөрөвний нэгийг үзсэн RTMP байна. RTSP нь зургаагийн нэг орчим юм. Үлдсэн хэсэг нь статистикийн алдааны бүсэд байна.

Жилийн өмнө яг ижил хугацаанд юу болсон бэ? Нөхцөл байдал нь бараг толин тусгал юм. RTMP - бараг гуравны хоёр, RTSP болон HLS хоёр, гуравдугаар байрыг хуваалцдаг. Үнэн бол хэмжилтийн суурь нь бараг 3 дахин бага байсан - "зөвхөн" 500 сая үзсэн. Мэдээжийн хэрэг манай үйлчилгээнд цөөн тооны серверүүд байсан.

Энэ хоёр цэгийн хооронд орцгооё.

Тиймээс 2014 оны 6-8 сар, зуны 3 сар. 800 сая үзсэн, гэхдээ хувьцаа нь адилхан, наймдугаар сард өөрчлөлт авчирсангүй.

2013 оны 9-р сараас 11-р сар. Шинэ улирал эхэлж, HLS RTMP-ийн хувийг идэж эхлэв. Нийт 1.1 тэрбум үзсэн, RTMP нийт дүнгийн тал орчим хувийг, HLS дөрөвний нэгийг эзэлдэг.

2013 оны 12-р сар - 2014 оны 2-р сар. 1.4 тэрбум үзсэн, үүнээс HLS 40 гаруй хувийг эзэлдэг. RTMP болон RTMP дөрөвний нэг хувьтай хоёр, гуравдугаар байрт тэнцэж байна. Сочид болсон Олимп үзүүлэгчдийн тоог нэмэгдүүлж, үүнтэй зэрэгцэн үйлчилгээ үзүүлэгчдийг зөвхөн RTSP-ийг ойлгодог бүх чамин эсвэл хуучин төхөөрөмжөөрөө бүх үйлчлүүлэгчдээ санахыг албадав - иймээс энэ протоколд үсрэлт хийсэн.

Дадлагаас харахад RTMP-тэй харьцуулахад видеоны хамгийн сайн тээвэрлэлт бол HLS юм. Үүний шалтгаанууд:

Nginx-ээр дамжуулан кэш хийх маш энгийн прокси. Юуны өмнө камер нь төхөөрөмжийн хувьд нэг дор 10-аас дээш холболт хийх боломжгүй байдаг. Энэ утгаараа RTMP урсгалын баталгаатай прокси нь зөвхөн төлбөртэй шийдлүүдийн тусламжтайгаар боломжтой бөгөөд маш их хүч шаарддаг. Тусгай серверийн програм хангамж шаардлагагүй.

Серверийн бүх дэд бүтцийг хялбаршуулах. Энэ санааны дагуу видеог хэсэг хэсгээр нь 80 портоор дамжуулан http-ээр дамжуулан өгдөг. Nginx өөрөө статикийг буцаах үүрэгтэй. Статик (50 кБ видео хэсэг) буцаах нь nginx-ийн хувьд маш хялбар ажил юм.

Хэсгийн тоо тогтмол байдаг тул хуучин нь хасагдаж, шинээр нэмэгддэг, HDDхэзээ ч халихгүй.

Тархалт нь RTMP-ээс их байна. H.264 видео кодчилол бүхий HLS нь iOS системээр дэмжигддэг бөгөөд ямар ч саадгүй ажилладаг. 2014 оны 7-р сарын 1-ний байдлаар HLS тээвэрлэлттэй видео урсгалын холболт 55%, RTMP - 26%, RTSP - 15%, MPEG-DASH 1% -иас бага байна.

Олонхийн дэмжлэг хөдөлгөөнт төхөөрөмж, ширээний компьютерууд, таблет компьютеруудшууд хөтөчөөс.

Зарчмын хувьд RTSP дээр цацахаас хамаагүй хялбар. Түлхэх (гүйлгээг нийтлэх), татах (стрим авах) гэх мэт журам байхгүй тул.

Илүү http-д ээлтэй формат.

Сул талууд нь дараах байдалтай байна.

Үүнтэй адил бүх төхөөрөмжүүд энэ форматыг дэмждэггүй. Android хувилбарууд 4.2-оос бага хувилбар нь H.264 кодлогч болон тээвэрлэлтийг албан ёсоор дэмждэггүй боловч Android дээр хөтчийн оронд та ашиглаж болно. гуравдагч этгээдийн өргөдөл- жишээ нь MX Player

Энэ бүхэн камераас хамаарна. Хэрэв камер алдаатай бол, жишээлбэл Dlink DCS-3010 бол бүх систем маш муу ажиллах болно (ffmpeg байнга унтардаг). Жишээлбэл, AXIS M1011-W, HIKVISION DS-2CD2412F-IW камерууд ийм багцад сайн ажилладаг (ямар ч гомдолгүйгээр нэг сар хүртэл (би үүнийг удаан туршиж үзээгүй)). Нэг арга зам их ач холбогдолкабелийн чиглүүлэлттэй. Энэ утгаараа бид хамгийн тохиромжтой сонголтыг авч үзэх болно.

HLS тээвэр гэж юу вэ

Видео урсгал h.264 кодлогдсон (Дашрамд: профайлын үндсэн ойлголт Android төхөөрөмжүүд), *.ts өргөтгөлтэй хэсгүүдэд хуваагддаг, жишээлбэл, тус бүр 5 секунд, эдгээр хэсгүүдийн дараалсан тайлбар бүхий тоглуулах жагсаалт live.m3u8 дээр үүсгэгддэг. Тоглуулах жагсаалтын уртыг урьдчилан тодорхойлсон, жишээлбэл, 10 ширхэг. 11-р видео гарч ирэхэд 1-р видео устаж, тоглуулах жагсаалтыг дахин үүсгэнэ. Дэлгэрэнгүй мэдээллийг хөгжүүлэгчийн вэбсайтаас авах боломжтой.

Системийг ажиллуулахын тулд бид камераас авсан зургийг сайт дээр үзэхийг хүссэн байдлаар, зургийн формат, зургийн чанарыг тохируулна. Бид сервер дээр дахин кодлохгүй. Камер нь танд хэрэгтэй дүрсийг өгөх зорилготой юм. Камерууд ихэвчлэн хэд хэдэн профайлтай байдаг. Та H.264, HLS-д зориулсан нэг профайлыг, хоёр дахь нь MPEG-DASH-д зориулсан MPEG4-ийг тохируулах боломжтой. Та мөн өргөн, нарийн интернетийн сувагт өөр өөр чанарыг тохируулж болно. Өөрийнхөө төлөө бод - өөрөө шийд.

Чухал!Камер нь дахин кодлох шаардлагагүй гаралтын дүрстэй байх ёстой.

Өндөр ачааллын бүтцийн диаграмм

Камер (rtsp) ----->

-----> нэг холболт FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-модуль) ----->

-----> том кэш бүхий завсрын nginx прокситэй нэг холболт =====>

=====> олон JWPlayer(hls) үйлчлүүлэгч

Манай сервер ffmpeg-тэй камертай холбогдож, nginx hls програмд ​​​​бүртгүүлдэг. nginx нь тодорхой директор дотор хэсгүүд болон тоглуулах жагсаалтыг үүсгэдэг. Дараа нь эдгээр хэсгүүдийг прокси сервер рүү илгээдэг. Үйлчлүүлэгчид JWPlayer ашиглан прокси серверт холбогддог.

Nginx програмыг тохируулж байна

nginx-rtmp-модуль ашиглан 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 / access . log ; error_log / var / log / nginx / алдаа . log ; mime оруулах . төрлүүд ; анхдагч_төрлийн програм / октет - урсгал ; sendfile асаалттай ; keepalive_timeout 65 ;proxy_cache_path / var / www / cache / local level = 1 : 2 keys_zone = nginx_local_cache : 1 м идэвхгүй = 30 м max_size = 512 M ; proxy_temp_path / var / www / кэш / local / tmp ; сервер ( # rt 80 сонсох; байршил / стат ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) байршил / стат . xsl ( # та стат . xsl-ийг өөр байршил руу шилжүүлж болно root / гэх мэт / nginx ; ) байршил / ( rtmp_control all ; ) алдаа_хуудас 500 50504 / 50 x .html ;байршил = / 50 x .html ( root html ; ) Үүнд cameras_http_locations .conf ; )) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server (сонсох 1935 ; ping 30 s ; notify_method авах; 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

төрөл (програм / vnd. apple. mpegurl m3u8; видео / mp2t ts;) # камер 1-ээс зураг өгөх - /1/img/ # бүх камерын хувьд өөр өөр байдаг, учир нь камерын IP хаягууд өөр байна "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 минутын кэш add_header Cache - Public Control ; # proxy on cache_ignore_headers Cache - Control ; # камерын прокси_асс толгойг арилгах "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Зөвшөөрөл "Үндсэн" ; error_page 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 завсарлага ; root / tmp / ; 3 м-ийн хугацаа дуусна; add_header Cache - Нийтийн хяналт ; ) Зураг байхгүй бол # нэрлэсэн байршилбайршил @ fallback_img (дахин бичих (. + ) / нөөц . jpg завсарлага ; root / etc / nginx / ; )

rtmp серверийн hls тохиргооны файлыг манай камерт зориулсан программуудыг үүсгэцгээе:

# nano cameras_rtmp_applications.conf

хэсэг_хэмжээ 4000; програм hls_1 (аалттай; синк 10 мс; exec_static ffmpeg - i rtsp: //админ: [имэйлээр хамгаалагдсан]:554/live1.sdp -c copy -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 timetamp ; # хэсэг хэсгүүдийг нэрлэхийн тулд цагийн тэмдэг ашиглана уу) програм hls_2 (аалттай байна; синхрончлол 10 мс; exec_static ffmpeg - i rtsp: //админ: [имэйлээр хамгаалагдсан]:554/live1.sdp -c copy -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 цагийн тэмдэг; )

/tmp/hls-1/ лавлахын агуулга

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767390ts live - 13767390ts live - 13767390ts live - 13767390ts6. - 11405250. ts live - 14239260. ts live - 17072820. ts live . m3u8 live - 11878560. ts live - 14710860. ts live - 17544960. ts live - 12348630. ts live - 15182550. ts live - 18020160. ts live - 1215084ts live - 121508ts live

Live.m3u8 файлын жишээ

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5.224, live - 16602660. ts #EXTINF:5.246, live - 17072820. :5.280, шууд - 17544960. ts #EXTINF:5.251, live - 18020160. ts #EXTINF:5.228, live - 18492750. ts #EXTINF:5.242, live - 18963270.

Камер унахтай холбоотой асуудлыг шийдэж байна

Ихэнх зөв шийдвэр, алдаатай камерыг солих. Энэ нь 90% -д тусалдаг. Хэрэв ямар нэгэн арга байхгүй бөгөөд та ямар нэгэн байдлаар амьдрах шаардлагатай бол дараах шийдэл туслах болно.

Энэхүү шийдэл нь нэмэлт хоёр зүйлээс бүрдэнэ.

Камер тус бүрт тусдаа nginx процессыг ажиллуулж, ерөнхий үйл явцстатик буцах тухай. Өөрөөр хэлбэл, хоёр камерын хувьд rtmp серверүүд болон http-тэй нэг нийтлэг тохиргоог тусад нь бичнэ. Дараа нь алдаатай камер нь ерөнхий процесст нөлөөлөхгүй.

Хэрэв камерын дамжуулалт алдааны улмаас тасалдвал (хэт халалт, утас муутай, PoE-ийн хүчдэл хангалтгүй гэх мэт) камер унаж, ffmpeg хүүхэд процесс нь пакетуудаас татгалзаж, nginx нь видео бичихээ зогсооно. . Мөн ffmpeg процесс дуусахад nginx нь chunks лавлахаас бүх файлыг устгах болно. Бид хавтсыг цэвэрлэх энэ мөчийг cron-оор тооцоолж, шаардлагатай nginx процессыг дахин эхлүүлнэ.

Камер бүрийн хувьд nginx-ийн хуулбар болох /etc/init.d/-д camera_1 болон camera_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 stop fi if [ - f "/etc/init.d/camera_2" ]; дараа нь /etc/init. d/camera_2 stop fi

do_reload функцэд нэмэх:

Хэрэв [ - f "/etc/init.d/camera_1" ] бол # камеруудыг дахин ачаалах; дараа нь /etc/init. d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ]; дараа нь /etc/init. d/camera_2 дахин ачаалах fi

Бид 1-р камерын камерын_1 болон камерын 2-ын камерын nginx эхлүүлэх скриптийг жишээний дагуу засдаг.

# нано /etc/init.d/camera_1

DAEMON_OPTS болон DESC хувьсагчдыг өөрчлөх

DESC = "CAMERA-1-д зориулсан камер_1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Бид камер 2 camera_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 хайлтын үг, лавлах болон дахин эхлүүлэх процессын нэрийг заана.

Шалгалт:

# service nginx start # service camera_1 restart * CAMERA-д зориулсан камер_1-г дахин эхлүүлж байна - 1 тохиргоо nginx # үйлчилгээний камер_2 дахин эхлүүлэх * CAMERA-д зориулсан камер_2-г дахин эхлүүлж байна - nginx 2 тохиргоо

Камеруудыг дахин ачаалах скрипт. Энэ нь *.m3u8 файл байхгүй хэсгийг хайдаг хавтаснуудаар дамждаг. Хэрэв хавтсанд файл байхгүй бол үндсэн дэмоны тохиргооны дагуу DIR-PROCESS-NAME гэсэн мөрөнд тохирох демоныг хайна. Дахин ачаална.

# нано /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 -нэр $маск -төрлийн f) хэрэв [ -z $find_result ] ; дараа нь процесс = $(find_process $hls_dir ) үйлчилгээ $process дахин эхлүүлэх fi 15 секунд унтлаа.

HLS-ийг MPEG-DASH-тай харьцуулах

MPEG-DASH нь HLS-ийн аналог юм Google, MPEG-4-ийн тээвэрлэлт болгон. Энэ тээвэр өргөн тархаагүй бөгөөд бараг дэмжигддэггүй. Түүний үзэл баримтлал нь ижил, урсгалыг хэсэг болгон хуваах, зөвхөн илүү олон хэсэг, видеог тусад нь, аудио нь тусдаа хэсгүүд. Nginx-rtmp-модульд энэ форматыг HLS-тэй адил тохируулсан.

Оролдоод үзээрэй, хуулж ав!

Хэрэв нийтлэл танд хэрэгтэй байсан бол зар дээр дарна уу. Баярлалаа!

Техникийн хувьд хамгийн тохиромжтой програмуудыг бий болгох нь ихэвчлэн маш төвөгтэй бөгөөд цаг хугацаа шаардсан ажил юм. Үүний зэрэгцээ, хэрэгцээтэй мэдээлэл нь ихэвчлэн олон эх сурвалжид тархсан байдаг. Энэ нь бусад зүйлсийн дунд iOS-д зориулсан видео програмуудыг хөгжүүлэхэд хамаарна. Энэ нийтлэл нь HTTP Live Streaming функцуудыг бүрэн хэмжээгээр чанарын хувьд ашиглах боломжийг олгодог хамгийн чухал бөгөөд хэрэгцээтэй мэдээлэл, түүнчлэн үндсэн эх сурвалжуудын жагсаалтыг агуулдаг. Эдгээр материалууд нь өндөр чанартай, хэрэглэгчдэд ээлтэй видео үйлчилгээг бий болгох сонирхолтой бүх уншигчдад хэрэгтэй болно.

Видео үйлчилгээний тохь тух, интерактив байдлыг бэхжүүлэх нь дамжуулан хүрдэг хурдан ажиллуулахболон буцаах, түүнчлэн буферийн дутагдал. Хамгийн сайн үр дүнд хүрэхийн тулд дараахь үйлдлүүдийн багцыг санал болгож байна.

• Видеоны чанар муутайгаас эхэлнэ.Видеог эхлүүлэхийн тулд дор хаяж нэг хэсэг шаардлагатай. Үүний дагуу нэг ширхэгийн хэмжээ бага байх тусам видео хурдан эхлэх болно. Эхлэх урсгалын битийн хурдыг бууруулж, хэсэгчилсэн үргэлжлэх хугацааг багасгах нь видеог хурдан эхлүүлэхэд хүргэдэг. Бид 4-8 секундын үргэлжлэх хугацаа, 200-300 Kbps эхлэх бит хурдыг санал болгож байна. Тиймээс, видеог тоглуулж эхлэхийн тулд хэрэглэгч дээд тал нь 300 кб татаж авах шаардлагатай болно.
• Тоглуулах жагсаалтыг оновчтой болгох.Тоглуулах жагсаалтууд нь нийт өгөгдлийн урсгалын ихээхэн хэсгийг эзэлдэг, ялангуяа жижиг хэсгүүдийн хэмжээ, урт агуулгатай (хэдэн цаг). Ихэнх тохиолдолд тоглуулах жагсаалтыг видео тоглуулагч руу шилжүүлэхдээ тэдгээрийг архивлахыг зөвлөж байна.
• гол хүрээнүүд.Сегмент бүрт дор хаяж нэг IDR хүрээтэй байх нь зүйтэй бөгөөд энэ нь сегментийн хамгийн эхэнд байх нь зүйтэй юм. Үүнээс гадна, видеог шилжүүлэх үед үүрэн сүлжээ 3 секунд тутамд дор хаяж нэг удаа үндсэн фрэйм ​​хийхийг зөвлөж байна.
• TS Overhead. HTTP LS нь MPEG TS-ийг контейнер болгон ашигладаг тул TS-ийн ачааллыг багасгах нь маш чухал (видео чанар муутай байсан ч 10% -иас бага байх ёстой). Энэ тохиолдолд замын хөдөлгөөний овоолгыг ашиглан бодит битийн хурдыг хэмжиж, ашигласан савлагчдыг (сегментүүд) оновчтой болгох нь зүйтэй.
• Тоглуулах жагсаалт дахь Зорилтот үргэлжлэх хугацааны параметр. Энэ параметрэхлүүлэх хугацаанд нөлөөлдөг боловч бага утгууд нь ялангуяа өндөр хоцрогдолтой үүрэн сүлжээнд буферлэх боломжийг нэмэгдүүлдэг тул Apple үүнийг 10 секунд болгож тохируулахыг зөвлөж байна. Мөн 20 секундээс урт сегмент үүсгэхийг зөвлөдөггүй.
• динамик битийн хурд. IOS-д суурилуулсан дасан зохицох урсгалын механизм нь хувилбарын тоглуулах жагсаалтад (тоглуулах жагсаалтын урсгалыг харгалзан) нарийн заасан битийн хурдаар оновчтой ажилладаг. Энэ тохиолдолд битийн хурдыг өөрчилдөг урсгалын хувьд та хамгийн ихдээ ойртсон утгыг зааж өгөх хэрэгтэй. Үгүй бол одоогийн видео урсгалыг өөрчлөх талаар буруу шийдвэр гаргах боломжтой. Хөрш зэргэлдээх битийн хурд нь 1.5-2 дахин ялгаатай байх ёстой.
• "Зөвхөн аудио" дамжуулалт. HE-AAC аудио кодлогч нь илүү үр дүнтэй бөгөөд ихэнх төхөөрөмж дэмждэг. Зөвхөн аудио сувгуудыг хүргэхийг MPEG Transport Stream биш харин MPEG Elementary Stream ашиглан хийхийг зөвлөж байна (илүү бага зардал).

Та видео тоглуулагчаа хөгжүүлснээр HTTP Live Streaming лог (accessLog) -аас хэрэгтэй мэдээлэл авах боломжтой. Энэ нь автомат шилжүүлэлт хэрхэн явагдсан, ямар битийн хурд ашигласан гэх мэт мэдээллийг агуулдаг. Бүртгэлд байгаа мэдээллийн дэлгэрэнгүй. Энэ өгөгдөл дээр үндэслэн та хэрэглэгчдийнхээ видео аналитик өгөгдлийг цуглуулах боломжтой болно.

Нэмэлт зөвлөмжүүд
Онлайн нэвтрүүлгийн хувьд CDN-ийн саатал, тоглуулах жагсаалтыг шинэчлэх хугацаа хэт богино, сервер нь сегментүүдийг цаг тухайд нь үүсгэх цаг байхгүй тохиолдолд видео буфер хийх боломжтой. Буцах механизмыг оновчтой болгохын тулд бүхэл бус (бодит) сегментийн үргэлжлэх хугацааны утгыг ашиглахыг зөвлөж байна, эс тэгвээс алдаа хуримтлагдаж болзошгүй.

Хэрэв таны програмыг ашиглахаар төлөвлөж байгаа бол янз бүрийн төхөөрөмжүүд, та жагсаалтад өөр өөр дэлгэцийн нягтралд өөр өөр видео чанарыг зааж өгч болно. Ингэснээр та Retina дэлгэцтэй iPad болон харьцангуй хуучин iPhone дээр өөр өөр видеог үзүүлэх боломжтой болно.

HTTP Live Streaming протокол нь мөн шилжүүлгийн механизмаар хангадаг (ийлмэл видео эх сурвалжийг заана). Энэ функц нь таны үйлчилгээний найдвартай байдлыг сайжруулахад тустай байж болох юм.

Мэдлэгийн эх сурвалжууд
Видео аппликешнүүдэд HTTP Live Streaming-г ашиглах нөөцийн товч жагсаалт:
HTTP шууд дамжуулалтын ноорог
HTTP шууд дамжуулалт Түгээмэл асуудаг асуултууд
HLS-ийн шилдэг туршлагууд

Эцэст нь, бүртгэлтэй Mac/iOS/Safari хөгжүүлэгчдэд үнэ төлбөргүй гэдгийг тэмдэглэх нь зүйтэй техникийн видео WWDC 2012-той хийсэн уулзалтууд, тэнд бас олон байдаг хэрэгтэй мэдээлэл, ялангуяа - видеотой ажиллах, HTTP Live Streaming ашиглах талаар.

үйлчилгээ үзүүлэх IP ТВИнтернет болон орон нутгийн замаар компьютерийн сүлжээнүүдулам бүр дэлгэрч байна. ТУХН-ийн орнуудын нутаг дэвсгэр дээр видео цацдаггүй томоохон үйлчилгээ үзүүлэгч бараг байдаггүй олон дамжуулалтлокал сүлжээнд, өөрөөр хэлбэл үйлчилгээ үзүүлдэг хүмүүст IPTV. Харин түүний гадна телевизийн үйлчилгээ үзүүлэх дотоод сүлжээзарим техник хангамжийн зардал, шаардлагатай өргөн нэвтрүүлгийн чанарыг хангах нарийн төвөгтэй байдалтай холбоотой.

HTTP шууд дамжуулалтгэж бас нэрлэдэг HLS, хэрэгжсэн харилцааны протокол юм Apple компани. Үүний онцлог нь ерөнхий урсгал нь жижиг татаж авах файлуудын дараалалд хуваагддаг бөгөөд татаж авах бүр нь тээврийн урсгалын нэг жижиг фрагментийг татаж авдаг. Дамжуулалтыг тоглуулах үед үйлчлүүлэгч өөр өөр битийн хурдаар бичигдсэн ижил материал агуулсан хэд хэдэн өөр өөр урсгалуудаас сонгож, боломжтой битийн хурдад дасан зохицох боломжтой. Дамжуулах сессийн эхэнд боломжтой төрөл бүрийн дэд урсгалуудын мета өгөгдлийг агуулсан өргөтгөсөн M3U (m3u8) тоглуулах жагсаалтыг ачаалдаг. Хүсэлт нь зөвхөн стандарт HTTP үйлдлүүдийг ашигладаг тул HTTP Live Streaming нь RTP гэх мэт UDP протоколуудаас ялгаатай нь стандарт HTTP урсгалыг зөвшөөрдөг ямар ч галт хана эсвэл прокси серверийг тойрч гарах боломжтой.

HLS нь HTTP дээр суурилдаг. HLS нь AES ашиглан стандарт шифрлэлтийн механизм болон HTTPS эсвэл HTTP күүки ашиглан аюулгүй байдлын түлхүүрийг түгээх арга замыг тодорхойлдог. энгийн системзохиогчийн эрхийг хамгаалах.

HLS ажиллах зарчим

Одоо энэ технологийн давуу болон сул талууд юу болохыг олж мэдье. Үр ашиг нь маргаангүй бөгөөд ойлгомжтой юм. Энэ нь нэгдүгээрт, өгөгдөл дамжуулах хурдыг шугам, хүлээн авагч төхөөрөмжийн шинж чанарт дасан зохицох чадвар, хоёрдугаарт, зохиогчийн эрхийг хамгаалах механизм юм. Гуравдугаарт, өргөн хязгаарлагдмал чиглүүлэгч шаардлагагүй олон дамжуулалт WI_FI дээр, энэ нь олон дамжуулалтыг ашиглан IP телевизийг цацаж байгаа тохиолдолд сувгийн өргөнийг олон дамжуулалтаар шингээхээс зайлсхийхэд тусална. Энэ нь мөн функцтэй нэмэлт төхөөрөмж шаарддаггүй UDP проксизахиалагчийн дотоод сүлжээнд UDP прокси функцийг гүйцэтгэдэг чиглүүлэгч эсвэл бусад төхөөрөмж дээрх техник хангамжийн ачаалалд нөлөөлдөг хэдий ч хөдөлгөөнт төхөөрөмжүүдэд ихэвчлэн шаардлагатай байдаг HTTP руу multicast урсгалыг хөрвүүлэх. HLS стандарт нь нэлээд түгээмэл болсон бөгөөд бараг бүх орчин үеийн видео тоглуулагч, IPTV-д зориулсан дээд хайрцагт дэмжлэг үзүүлдэг.

IPTV дээд хайрцаг

Захиалагчид HLS стандартыг дэмждэггүй эсвэл зөв дэмждэггүй хуучирсан программ хангамж эсвэл хуучирсан загвартай мультимедиа тохируулагч, ухаалаг ТВ-ийн дээд хайрцагтай байдаг нь мэдэгдэхүйц сул тал юм. Мөн бэрхшээлүүдийн нэг нь хүссэн видео фрагментийн үргэлжлэх хугацаанаас богино хугацааны интервалаар шугамын шинж чанарыг өөрчлөх нөхцөлд тогтвортой нэвтрүүлгийн зөв чанарыг сонгох боломжгүй юм.