Son bir neçə ildə rəqəmsal yayım dünyasında böyük dəyişikliklər baş verib. Adobe tərəfindən hazırlanmış İnternet üzərindən məzmunun çatdırılması texnologiyası olan Flash, mövcudluğunu sürətlə azaldır. Və onun yerini HLS kimi protokollar tutur.

HTML5 və HLS açıq mənbədir, istədiyiniz kimi dəyişdirilə bilər və istifadə etmək pulsuzdur. Onlar həmçinin sələflərindən daha təhlükəsiz, daha etibarlı və sürətlidirlər. Bu yazıda biz onlayn yayım anlayışlarını izah etməyə, axın protokollarının təsvirini və HLS-dən istifadə üçün tövsiyələri verməyə çalışacağıq.

HLS nədir

HLS, İnternet üzərindən media məlumatlarının ötürülməsi üçün protokol olan HTTP Live Streaming deməkdir. HLS MP4 formatında video məzmunu qısa 10 saniyəlik bloklara, parçalara kəsir. Bu qısa fraqmentlər HTTP üzərindən ötürülür, bu da protokolu əksər cihazlar və təhlükəsizlik duvarları ilə uyğunlaşdırır.

HLS ilk növbədə onlayn yayımların əla keyfiyyətini təmin edir. Ancaq nəzərə almaq lazımdır ki, onlayn yayım zamanı gecikmə 15-30 saniyədir. Server tərəfində yayım yaradıcısı axın kodlamasını bir neçə keyfiyyətə təyin edə bilər. Sonra oyunçu dinamik olaraq müəyyən bir anda İnternet kanalının genişliyinə əsaslanaraq optimal keyfiyyət tələb edir. Müvafiq olaraq, fraqmentlərin keyfiyyəti fərqli ola bilər.

Məsələn, cib telefonu HD keyfiyyətində video oynayır və bir dəqiqə sonra tamaşaçı özünü zəif qəbul edilən ərazidə tapır. Oyunçu əlaqə keyfiyyətində azalma aşkar etdikdə, daha aşağı keyfiyyətli video parçaları tələb edir. Bu, tamponlama, donma və digər problemləri azaldır.

HLS-nin yaranma tarixi

HLS ilk olaraq 2009-cu ilin yayında iPhone 3 ilə birlikdə Apple tərəfindən istifadəyə verilmişdir. Əvvəlki iPhone modelləri bəzən Wi-Fi şəbəkələri və mobil məlumat ötürülməsi arasında keçid etdiyinə görə onlayn yayımda problemlər yaşayırdılar.

HLS buraxılmazdan əvvəl Apple-ın əsas axın media protokolu Quicktime Streaming Server idi. Yaxşı xidmətdir, lakin məlumatların ötürülməsi üçün qeyri-standart portlardan istifadə etdiyi üçün onun RTSP protokolu vaxtaşırı firewalllar tərəfindən bloklanırdı. Yavaş internetlə birlikdə bu, bu protokoldan imtinaya səbəb oldu. Lakin onun həyata keçirilməsindən əldə edilən dərslər HLS-nin inkişafında çox faydalı oldu.

HLS axını tez yaradılır və HTTP serverində saxlanılır. Video faylları, yuxarıda qeyd edildiyi kimi, .ts - MPEG2 Nəqliyyat axını ilə qısa fraqmentlərə bölünür.

HTTP serveri həmçinin bütün video hissələrini indeksləşdirməyə xidmət edən .M3U8 (həmçinin manifest adlanır) genişləndirilməsi ilə pleylist faylı yaradır. Bu pleylist faylı mövcud yayım keyfiyyətlərinin hər biri üçün əlavə indeks fayllarına işarə edir. Bir keyfiyyətdən istifadə edərək yayım etmək qərarına gəlsəniz belə, yenə də “manifest” yaradılacaq.

İstifadəçinin oyunçusu İnternetdə məlumat ötürmə sürətinin pisləşməsini və ya yaxşılaşmasını tanımalıdır. Belə bir hadisə baş verdikdə, oyunçu hansı video keyfiyyətinə keçəcəyini müəyyən etmək üçün manifest faylına daxil olur. Daha sonra oyunçu videonun tamaşaçının dayandığı hissəsini yükləmək üçün keyfiyyətə uyğun indeks faylı tələb edir. Bütün bu proses istifadəçi üçün görünməzdir. HLS protokolu həmçinin qapalı yazıları dəstəkləyir,

Axın protokollarına ümumi baxış

Əvvəllər yaradılmış protokolların hər biri media axınında bəzi innovasiyaların həyata keçirilməsini təmsil edirdi. Blu-Ray-ə qarşı HD-DVD və VHS-ə qarşı Betamax kimi “format müharibələri” də var idi. HLS onlayn yayımda liderdir, lakin bu, həmişə belə olmayıb və gələcəkdə də belə qalacağı fakt deyil.

RTMP və ya Real-Time Messaging Protocol, real vaxt məlumat axını protokolu. Macromedia audio və video məzmunu çatdırmaq üçün 2000-ci ilin ortalarında yaradılmışdır. Çox vaxt sadəcə Flash adlanır. Macromedia daha sonra RTMP-ni yarı açıq protokol kimi inkişaf etdirməyə davam edən Adobe Inc ilə birləşdi.

Son onillikdə RTMP internet üzərindən dominant yayım üsulu olmuşdur. Yalnız HLS-nin meydana çıxması ilə onun payı azalmağa başladı. Bu gün əksər onlayn video platformalar daxil olan RTMP axını ilə işləyir. Başqa sözlə, siz onlayn video platformanın HLS-də kodlaşdırdığı və son izləyicilərə çatdırdığı RTMP-də yayımlayırsınız. Doğrudur, bir çox CDN operatorları RTMP dəstəyindən imtina etməyə başlayır - sübut

Adobe tərəfindən hazırlanmış növbəti nəsil axın protokolu HDS - HTTP Dynamic Streaming adlanır. Flash oynatma plagininə uyğundur, lakin onun istifadə tezliyi ümumi HLS-dən xeyli aşağıdır.

Flash-ı dəstəkləyən cihazlar və brauzerlər üçün HDS ən yaxşı seçimdir. Yayım zamanı minimal gecikmə təmin edir, HLS kimi, media fayllarını kiçik fraqmentlərə bölür, şifrələməni və DRM-ni dəstəkləyir.

Microsoft Smooth Streaming

Microsoft, Microsoft Smooth Streaming adlı öz onlayn axın protokolunu yaratdı. MSS həmçinin məzmunu mümkün olan ən yaxşı keyfiyyətdə çatdırmaq üçün adaptiv bit sürətindən istifadə edir.

Adaptiv bitrate yayımı 2008-ci ildə təqdim edilib. MSS 2008 Yay Olimpiya Oyunlarının yayımı üçün istifadə edilmişdir. Bu növ yayımın əsas istifadəçisi XBox One platformasıdır. Eyni zamanda, MSS bu gün ən populyar protokollardan biridir.

MPEG-DASH

Axın protokolları sahəsində ən son əhəmiyyətli həllərdən biri MPEG-DASH-dır, burada DASH HTTP üzərindən Dinamik Adaptiv Axın deməkdir.

MPEG-DASH-ın üstünlüyü ondan ibarətdir ki, o, HTTP vasitəsilə media yayımı üçün vahid beynəlxalq standart kimi tanınır. Hazırda o, hələ geniş yayılmayıb və bütün yayımçılar bunu dəstəkləmir. Ancaq bütün hesablara görə, bir neçə ildən sonra bu xüsusi standart ən populyar yayım protokoluna çevriləcəkdir.

MPEG-DASH kodek növündən asılı deyil, siz bu protokoldan istifadə edərək media göndərmək üçün onlardan hər hansı birini istifadə edə bilərsiniz - H.264, HEVC/H.265, VP10

Onlayn yayım üçün HLS-dən nə vaxt istifadə edilməlidir

HLS-dən hər zaman istifadə etməyi tövsiyə edirik. Bu, ən müasir və geniş şəkildə dəstəklənən media axını protokoludur. Mobil cihazlara yayım etmək istəyirsinizsə, onsuz edə bilməzsiniz. Doğma HTML5 pleyer dəstəyi və təbii ki, adaptiv bit sürəti optimal görüntü keyfiyyətini təmin edir.

Təcrübə göstərdiyi kimi, RTMP ilə müqayisədə video üçün ən yaxşı nəqliyyat HLS-dir. Bunun səbəbləri:

Nginx vasitəsilə keşləmə ilə çox sadə proxy. Birincisi, ona görə ki, kamera bir cihaz olaraq, bir qayda olaraq, eyni vaxtda 10-dan çox əlaqəni idarə edə bilməz. Bu mənada, RTMP axınlarının zəmanətli proxyləşdirilməsi yalnız ödənişli həllər vasitəsilə mümkündür və böyük imkanlar tələb edir. Heç bir xüsusi server proqramı tələb olunmur.

Bütün server infrastrukturunun sadələşdirilməsi. İdeyaya görə, video hissələrə bölünərək http vasitəsilə 80 port vasitəsilə göndərilir. Nginx özü statik məlumatların çatdırılmasına cavabdeh ola bilər. Statik faylları (hər biri 50 kB olan video parçaları) qaytarmaq nginx üçün çox asan işdir.

Əksər mobil cihazlar, masaüstü kompüterlər və planşetlər üçün birbaşa brauzerdən dəstək.

Prinsipcə RTSP vasitəsilə yayımdan daha sadədir. Push (axın dərc etmək) və ya pull (axın qəbulu) kimi prosedurlar olmadığı üçün.

Daha çox http dostu format.

Dezavantajlar aşağıdakılardır:

Yenə də bütün cihazlar bu formatı dəstəkləmir. 4.2-dən aşağı olan Android versiyaları rəsmi olaraq H.264 kodek və nəqliyyatını dəstəkləmir, lakin Android-də brauzer əvəzinə üçüncü tərəf proqramından istifadə edə bilərsiniz - məsələn MX Player

Hamısı kameradan asılıdır. Kamera səhvdirsə, məsələn Dlink DCS-3010, onda bütün sistem çox zəif işləyəcək (ffmpeg daim sönür). Məsələn, AXIS M1011-W, HIKVISION DS-2CD2412F-IW kameraları bu kombinasiyada yaxşı işləyir (şikayətsiz bir aya qədər (sadəcə daha uzun müddət sınaqdan keçirməmişəm)). Kabel marşrutu da böyük əhəmiyyət kəsb edir. Bu mənada ideal variantı nəzərdən keçirəcəyik.

HLS nəqliyyat nədir

H.264 kodlaşdırmasındakı video axını (Yeri gəlmişkən: profilin əsas xətti Android cihazları tərəfindən başa düşülür), *.ts genişlənməsi ilə parçalara bölünür, məsələn, hər biri 5 saniyə, canlı.m3u8-də pleylist yaradılır. bu parçaların ardıcıl təsviri. Pleylistin uzunluğu əvvəlcədən müəyyən edilmişdir, məsələn, 10 ədəd. 11-ci video görünəndə 1 video silinir, pleylist yenidən yaradılır. Daha ətraflı məlumatı tərtibatçının saytında tapa bilərsiniz.

Sistemin işləməsi üçün kameralardan alınan şəkli saytda görmək istədiyimiz şəkildə, şəkil formatını və keyfiyyətini konfiqurasiya edəcəyik. Biz serverdə yenidən kodlaşdırmayacağıq. Buna görə kamera lazım olan görüntünü yaratmaq üçün icad edilmişdir. Kameralar adətən bir neçə profilə malikdir. Siz H.264, HLS üçün bir profili, MPEG-DASH üçün isə MPEG4 ilə ikincisini konfiqurasiya edə bilərsiniz. Siz həmçinin geniş və dar İnternet kanalı üçün müxtəlif keyfiyyətlər konfiqurasiya edə bilərsiniz. Özünüz düşünün - özünüz qərar verin.

Vacibdir! Kamera yenidən kodlaşdırılmasına ehtiyac olmayan bir görüntü çıxarmalıdır.

Yüksək yük üçün blok diaqramı

Kamera (rtsp) ----->

-----> bir əlaqə FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-modulu) ----->

-----> böyük keş ilə ara nginx proksi ilə bir əlaqə =====>

=====> çoxlu JWPlayer(hls) müştərisi

Serverimiz ffmpeg istifadə edərək kameraya qoşulur və nginx hls tətbiqi ilə qeydiyyatdan keçir. nginx müəyyən bir kataloqda parçalar və pleylist yaradır. Sonra bu parçaları proxy serverə göndərir. Müştərilər JWPlayer istifadə edərək proksiyə qoşulurlar.

Nginx tətbiqinin qurulması

Nginx-i nginx-rtmp-modulu ilə quraq. Bu prosedur məqalədə ətraflı təsvir edilmişdir.

Tutaq ki, bir neçə kameramız var, onları seriya nömrəsinə bölün. Mən 2 kamera üçün nginx konfiqurasiyasını təsvir edəcəyəm. Statik şəkilləri yerli keşdə 5 dəqiqə yaddaşda saxlayırıq, əgər şəkil 5 saniyə ərzində yüklənmirsə, statik ekran qoruyucusu göndəririk.

# nano /etc/nginx/nginx.conf

Nginx konfiqurasiyasını redaktə edək

istifadəçi www - data;

işçi_prosesləri avtomatik ;

pid/run/nginx. pid; error_log /var/log/nginx/nginx_error. log debug;

env PATH;

hadisələr ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error . log ; mime daxildir . növləri ; default_type proqram / octet - stream ; sendfile on ; keepalive_timeout 65 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 ( dinləmək 80 ; stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) yer / stat xsl ( # stat . xsl'i başqa yerə köçürə bilərsiniz kök / s / nginx ; ) yer / ( rtmp_control all ; ) error_page 500 502 x 50 / html yer = / 50 x html (root html;) daxildir cameras_http_locations ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( 1935 ; ping 30 s ; notify_method get ;

cameras_rtmp_applications daxildir. conf; ) ) Keş üçün yol yaradaq # mkdir /var/www/cache/local Keş üçün hüquqları düzəldək: # chmod -R 755 /var/www/cache/local# chown -R www-data:www-data /var/www/cache/local` Kameralar üçün http yerləri yaradaq: # nano kameralar_http_locations.conf; proxy_set_header Avtorizasiya "Əsas" ; error_page 502 504 404 @ fallback_img ;) # pleylistini verin - /1/hls/live.m3u8 və ya /3/hls/live.m3u8 # pleylist proksidə 10 saniyə ərzində yaddaşda saxlanılır yer ~* /hls/ . *\. m3u8 $ ( yenidən yazın "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 fasilə ; # yenidən yazma sorğusu / 1 / hls / to / hls - 1 / root / tmp / ; müddəti 10 bitir s add_header Cache - Nəzarət ictimai ;# kameralardan bir parça video verin - /1/hls/live-12345678.ts və ya /2/hls/live-12345678.ts Yerli kompüterdə # keşləmə tələb olunmur# parça proksidə 3 dəqiqə yaddaşda saxlanılır

yer ~* /hls/ . *\. ts $ ( yenidən yazın "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 fasilə ; kök / tmp / ; müddəti 3 m bitir; add_header Cache - İctimaiyyətə nəzarət ; )

Şəkil yoxdursa # adlandırılmış yer

yer @ fallback_img ( yenidən yazın ( . + ) / geri qaytarın . jpg fasilə ; root / etc / nginx / ;) Kameralarımız üçün proqramlarla rtmp server konfiqurasiyası üçün hls faylı yaradaq: # nano cameras_rtmp_applications.conf yığın_ölçüsü 4000; proqram hls_1 (canlı; sinxronizasiya 10 ms; exec_static ffmpeg - i rtsp: Kameralarımız üçün proqramlarla rtmp server konfiqurasiyası üçün hls faylı yaradaq: # nano cameras_rtmp_applications.conf//admin:[email protected]

:554/live1.sdp -c surəti -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log;

hls on ;

hls_path /tmp/hls - 1/ ;

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

Kameraların düşməsi ilə bağlı problemin həlli

Ən yaxşı həll kameranı dəyişdirməkdir. Bu, 90% hallarda kömək edir. Heç bir yol yoxdursa və birtəhər hərəkət etməlisinizsə, aşağıdakı həll kömək edəcəkdir.

Bu həll iki tamamlayıcıdan ibarətdir:

Hər kamera üçün ayrıca nginx prosesini və statik məlumatların qaytarılması üçün ümumi bir prosesi işə salın. Yəni, iki kamera üçün rtmp serverləri ilə ayrı-ayrı konfiqurasiyalar yazın və bir ümumi http ilə. Sonra glitch kamera ümumi prosesə təsir etməyəcək.

Kameradan gələn axın onun nasazlıqları (həddindən artıq qızma, zəif korpus, qeyri-kafi PoE enerji təchizatı və s.) nəticəsində pozulursa, o zaman kamera yıxılacaq, ffmpeg uşaq prosesi paketləri rədd edəcək və nginx faylları qeyd etməyi dayandıracaq. video. Və ffmpeg prosesi başa çatdıqda, nginx chunks qovluğundan bütün faylları siləcək. Cron istifadə edərək qovluğu təmizləməyin bu anını hesablayırıq və lazımi nginx prosesini yenidən başladın.

Hər kamera üçün kamera_1 və kamera_2 adlı nginx surəti olan /etc/init.d/ daxilində icra edilə bilən skript yaradılır.

# 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 başlanğıc skriptinin redaktə edilməsi.

nano/etc/init. d/nginx

DAEMON_OPTS dəyişənini dəyişdirin. Əsas nginx demonu bütün statik məlumatları təmin edəcək. O, həmçinin kameralara cavabdeh olan demonları işə salacaq və dayandıracaq./ init . d / camera_1 stop fi əgər [ - f "/etc/init.d/camera_2" ];

sonra / etc / init. d/camera_2 stop fi

do_reload funksiyasına əlavə edin:

# kameraları yenidən yüklə, əgər [ - f "/etc/init.d/camera_1" ];

sonra / etc / init. d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ];

sonra / etc / init. d/camera_2 fi

Biz nümunəyə uyğun olaraq kamera 1 kamera_1 və kamera 2 kamera_2 üçün nginx işə salma skriptini redaktə edirik.

# nano /etc/init.d/camera_1

DAEMON_OPTS və DESC dəyişənlərini dəyişdirin

DESC = "CAMERA-1 üçün kamera_1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf" Nümunəyə uyğun olaraq kamera 2 camera_2 üçün nginx başlanğıc skriptini redaktə edək.

Onlar boşluqla ayrılaraq axtarılan DIR-PROCESS-NAME sözünü, qovluğu və yenidən işə salınmalı olan prosesin adını göstərir.

İmtahan:

# service nginx start # service camera_1 restart * CAMERA üçün kamera_1 yenidən işə salınır - 1 konfiqurasiya nginx # xidmət kamerası_2 yenidən işə salınır * CAMERA üçün kamera_2 yenidən işə salınır - 2 konfiqurasiya nginx

Kameraları yenidən işə salan skript. Parçalarla qovluqlardan keçir, *.m3u8 faylları olmayanları axtarır. Əgər qovluqda heç bir fayl yoxdursa, o, DIR-PROCESS-NAME sətirindən istifadə edərək əsas demonun konfiqurasiyasında müvafiq demonu axtarır. Onu yenidən yükləyir.

# 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 ) üçün hls_dir $dir ; find_result = $(tap $hls_dir -ad $mask -tip f) əgər [ -z $tap_nəticə ] ; sonra proses = $(find_process $hls_dir ) xidmət $process yenidən başladın fi bitdi yuxu 15s

HLS-nin MPEG-DASH ilə müqayisəsi

MPEG-DASH, Google tərəfindən MPEG-4 üçün nəqliyyat kimi yaradılmış HLS analoqudur. Bu nəqliyyat geniş yayılmayıb və praktiki olaraq dəstəklənmir. Onun ideologiyası eynidir, axını parçalara ayırın, yalnız daha çox parça var, video üçün ayrı, audio üçün ayrı. Nginx-rtmp-modulunda bu format HLS kimi konfiqurasiya edilmişdir.

Çalışın, kopyalayın, cəsarət edin!

Məqalə sizin üçün faydalıdırsa, lütfən, elanın üzərinə klikləyin. Təşəkkür edirəm!

Xidmətlərin göstərilməsi IPTVİnternet və yerli kompüter şəbəkələri vasitəsilə getdikcə daha geniş formalar alır. MDB ölkələrində video yayım etməyən iri provayderlər demək olar ki, qalmayıb multicast yerli şəbəkələrinə daxil olur, yəni xidmət göstərir IPTV. Lakin yerli şəbəkənizdən kənar TV xidmətlərinin göstərilməsi bəzi aparat xərcləri və tələb olunan yayım keyfiyyətini təmin etmək çətinliyi ilə bağlıdır.

HTTP Canlı Yayım kimi də tanınır H.L.S., Apple tərəfindən həyata keçirilən rabitə protokoludur. Onun özəlliyi ondan ibarətdir ki, ümumi axın kiçik yükləmə faylları ardıcıllığına bölünür, hər endirmə nəqliyyat axınının kiçik bir fraqmentini yükləyir. Axın oxunduqda, müştəri mövcud bit sürətinə uyğunlaşmağa imkan verən, müxtəlif bit sürətlərində qeydə alınmış eyni materialdan ibarət bir neçə fərqli alternativ axın arasından seçim edə bilər. Yayım sessiyasının başlanğıcında, mövcud olan müxtəlif alt axınlar üçün metadata ehtiva edən təkmil M3U (m3u8) pleylist yüklənir. Sorğular yalnız standart HTTP əməliyyatlarından istifadə etdiyi üçün HTTP Canlı Yayım RTP kimi UDP protokollarından fərqli olaraq standart HTTP trafikinə imkan verən hər hansı bir firewall və ya proxy-dən yan keçə bilir.

HLS HTTP-yə əsaslanır. HLS həmçinin AES istifadə edərək standart şifrələmə mexanizmini və HTTPS və ya HTTP kukilərindən istifadə edərək təhlükəsizlik açarının paylanması metodunu müəyyən edir ki, bunlar birlikdə sadə müəllif hüquqlarının qorunması sistemini təmin edir.

HLS necə işləyir?

İndi bu texnologiyanın üstünlükləri və mənfi cəhətləri nə olduğunu öyrənək. Üstünlüklər şübhəsiz və göz qabağındadır. Bu, ilk növbədə, məlumatların ötürülməsi sürətinin xəttin və qəbuledici cihazın xüsusiyyətlərinə uyğunlaşması, ikincisi, daxili müəllif hüquqlarının qorunması mexanizmləridir. Üçüncüsü, genişlik məhdudiyyətləri olan heç bir marşrutlaşdırıcı tələb olunmur multicast axın WI_FI vasitəsilə, bu, multicast istifadə edərək IP televiziya yayımı halında, bütün kanal eninin multicast axınları tərəfindən udulmasının qarşısını almağa kömək edəcəkdir. Həmçinin, funksiyası olan əlavə cihaz tələb olunmur UDP proxy Abunəçinin yerli şəbəkəsində UDP proxy funksiyasını yerinə yetirən marşrutlaşdırıcıda və ya digər cihazda aparat yüklənməsinə təsir etsə də, çox vaxt mobil cihazlar üçün tələb olunan multicast axını HTTP-yə çevirmək. HLS standartı kifayət qədər geniş yayılmışdır və demək olar ki, bütün müasir video pleyerlər və IPTV pristavkaları tərəfindən dəstəklənir.

IPTV pristavka

Əhəmiyyətli bir çatışmazlıq abunəçilərin HLS standartlarını dəstəkləməyən və ya onları düzgün dəstəkləməyən köhnəlmiş proqram təminatı və ya köhnəlmiş dizaynı olan multimedia pristavkalarına və smart-televiziya pristavkalarına malik olmasıdır. Həmçinin, problemlərdən biri tələb olunan video fraqmentin müddətindən daha qısa zaman intervallarında xətt xüsusiyyətlərinin dəyişməsi şəraitində sabit yayım üçün keyfiyyətin düzgün seçilə bilməməsidir.

Onlayn yayımları real vaxt rejimində təşkil etmək, tələb olunan video (vod), həmçinin video axınlarını yazmaq üçün nginx-rtmp-modul modulu ilə birlikdə nginx-dən istifadə edə bilərsiniz.

Media serverləri

Bu gün bir neçə məşhur media serverləri var, onlardan birində daha çox oxuya bilərsiniz. Real vaxt rejimində onlayn yayım yaratmaq üçün media serverləri lazımdır.

Müxtəlif funksiyaları özündə birləşdirən həm ödənişli, həm də pulsuz media serverləri var. Bu gün bir pulsuz və olduqca yaxşı bir həll haqqında danışacağıq.

Ngnix-rtmp

Media serverinin əsas funksionallığı pulsuz proqram təminatından - hazırda RTMP və HLS kimi axın protokollarını dəstəkləyən Ngnix-rtmp-modul modulundan istifadə etməklə də həyata keçirilə bilər.

Beləliklə, Ngnix-rtmp (Ngnix veb server + Ngnix-rtmp-modul modulu) istifadə edərək, istifadəçi cihazlarına RTMP və HLS yayımını təşkil edə bilərsiniz. Protokolların və onları dəstəkləyən cihazların xülasə cədvəlini məqalədə tapa bilərsiniz. Həmçinin gələcək məqalələrimin birində Ngnix-rtmp-modul modulunun və digər media serverlərinin funksionallığının müqayisəli cədvəlini hazırlamağı planlaşdırıram.

HLS protokolu ilə onlayn yayım

Bu gün biz HLS protokolundan istifadə edərək adaptiv bit sürəti ilə sadə yayım təşkil etmək üçün Nginx-rtmp modulundan necə istifadə edəcəyimizi nəzərdən keçirəcəyik. İlk öncə Nginx veb serverinin mənbə kodlarını rəsmi internet saytından endirməliyik. Aşağıda təqdim olunan bütün əmrlər Linux-da icra edilmişdir.

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

Faylları arxivdən çıxarın.

• tar -zxvf nginx-1.4.1.tar.gz

Zip arxivini nginx-rtmp-modul modulunun mənbə faylları ilə yükləyin və faylları arxivdən çıxarın.

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

İndi modulla nginx-i tərtib etməliyik nginx-rtmp modulu , bunun üçün nginx-i konfiqurasiya edərkən seçimdə qeyd etməlisiniz --modul əlavə edin mənbə fayllarının yeri nginx-rtmp modulu , və siz həmçinin əlavə seçim göstərməlisiniz http_ssl_modulu ilə .

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

quraşdırmaq

• Hər şey səhvsiz keçdisə, serveri qurmağa başlaya bilərsiniz. Varsayılan olaraq, server kataloqda quraşdırılmışdır/usr/local/nginx . nginx.conf server konfiqurasiya faylı kataloqda yerləşir/usr/local/nginx/conf . Konfiqurasiya faylının rtmp:server bölməsinə daha yaxından nəzər salaq. Dinləmə parametri serverin rtmp sorğularını qəbul edəcəyi portu müəyyən edir.
• Sonra testli tətbiqi qurmaq üçün bölməni açırıq. Burada canlı yayımımız olduğunu bildiririk - canlı yayım parametri, biz bu proqram üçün hls protokolu üçün dəstəyi işə salırıq - hls on parametri.
• Parametrdən istifadə etməklə hls_path axının hissələrinin (parçalarının) yerləşəcəyi kataloqu təyin edirik. Hər bir video axını üçün parçaların (parçaların) ayrıca qovluqda yerləşməsi üçün direktivi daxil etməlisiniz. hls_nested on .
• Sonra, parametrdən istifadə edərək dərc etməyə icazə verin biz sizə kompüterinizdən və parametrdən istifadə edərək axınları dərc etməyə imkan veririk hamısını dərc etməyi inkar et Biz hər kəsə video yayımlamağı qadağan edirik.
• İndi bölməyə baxaqhttp:server . Parametrdə qulaq as serverin hansı portda qəbul edəcəyini göstərmək lazımdırhttp sorğular. Biz 8080 portunu təyin edirik. Və nümunə konfiqurasiya faylından bölməni köçürünhttp:server:location/hls . Konfiqurasiya faylının bütün direktivləri haqqında daha ətraflı məlumatı bu ünvanda görə bilərsiniz:https://github.com/arut/nginx-rtmp-module/wiki/Directives.
• Serveri işə salmağın vaxtıdır. Bunu etmək üçün kataloqa getmək lazımdır /usr/local/nginx/bin və əmri işə salın ./nginx .

İndi bir misala baxaq. Serverə üç video axını göndəririk:

• test 1 256 kbit/s bit sürəti ilə,
• test2 512 kbit/s bit sürəti ilə,
• test3 1024 kbps bit sürəti ilə.

Məqsədimiz HLS protokolundan istifadə edən müştərinin (cihazlar: Mac, iPad, iPhone) İnternet bağlantısının keyfiyyətindən asılı olaraq axınlar arasında dinamik keçid edə bilməsidir. Bunu etmək üçün bizə kataloq lazımdır /usr/local/nginx/html uzantılı bir fayl yaradın m3u8 , Məsələn playlist.m3u8 , aşağıdakı məzmunla:

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=256000,ROLUTION=640×480

hls/test1/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BAND WIDTH=512000,ROLUTION=640×480

hls/test2/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1024000,REOLUTION=640×480

hls/test3/index.m3u8

Verilişə baxın

Video axınlarına baxmaq üçün aşağıdakı kodu saytın veb səhifəsinə daxil etməlisiniz.

- nginx serverinizin IP ünvanı.

[playlist adı]- əvvəlki paraqrafda yaradılmış faylın adı (playlist.m3u8).

Aşağıda sadə nginx.conf konfiqurasiya faylının nümunəsi verilmişdir.

işçi_prosesləri 1;

server(

qulaq as 1935;

canlı tətbiq testi (

yaşamaq;

hls on;

hls_path /tmp/hls;

hls_nested on;

dərc etməyə icazə 10.10.146.148;

hamısını dərc etməyi inkar etmək;

server(

qulaq asmaq 8080;

server_name rtmp_test;

charset utf-8;

yer/(

kök html;

indeks index.html index.htm;

yer /hls (

növləri (

application/vnd.apple.mpegurl m3u8;

ləqəb /tmp/hls;

Nəticə

Bu məqalə həmkarım Yevgeni Petrovla birgə yazılıb dərc olunub. Bu moduldan (Ngnix-rtmp) müxtəlif layihələrdə istifadə edirik. Ngnix-rtmp, Wowza server haqqında hər hansı bir sualınız varsa, yazın. Əgər nəyisə konfiqurasiya etmək və ya media serverləri və multimedia sistemləri ilə bağlı məsləhət almaq lazımdırsa, mənimlə və komandamızla əlaqə saxlaya bilərsiniz.

Texniki cəhətdən mükəmməl proqramların yaradılması adətən son dərəcə çətin və vaxt aparan işdir. Eyni zamanda, faydalı məlumatlar çox vaxt bir çox mənbələrə səpələnir. Bu, digər məsələlərlə yanaşı, iOS üçün video proqramların hazırlanmasına da aiddir. Bu məqalə HTTP Live Streaming imkanlarının tam spektrindən səmərəli istifadə etməyə imkan verən ən vacib və faydalı məlumatları, həmçinin əsas mənbələrin siyahısını ehtiva edir. Bu materiallar yüksək keyfiyyətli və istifadəçi dostu video xidmətləri yaratmaqda maraqlı olan bütün oxucular üçün faydalı olacaqdır.

Video xidmətlərinin rahatlığının və interaktivliyinin artırılması sürətli işə salma və geri çevirmə, həmçinin buferləşdirmənin olmaması ilə əldə edilir. Ən yaxşı nəticə əldə etmək üçün aşağıdakı hərəkətlər dəsti təklif olunur.

• Aşağı video keyfiyyəti ilə başlayın. Videoya başlamaq üçün ən azı bir parça tələb olunur. Müvafiq olaraq, bir parçanın ölçüsü nə qədər kiçik olsa, video daha sürətli başlayacaq. Başlanğıc axınının bit sürətini azaltmaq və yığının müddətini azaltmaq videonun daha sürətli işə salınmasına səbəb olur. Biz 4-8 saniyəlik yığın müddətini və 200-300 Kbps başlanğıc bit sürətini tövsiyə edirik. Beləliklə, videonu oynatmağa başlamaq üçün istifadəçi maksimum 300 KB yükləməli olacaq.
• Pleylist optimallaşdırılması. Pleylistlər ümumi məlumat axınının əhəmiyyətli bir hissəsini tuta bilər, xüsusən kiçik parça ölçüləri və uzunmüddətli məzmunu ilə (bir neçə saat). Əksər hallarda, pleylistləri video pleyerə köçürərkən, onları arxivləşdirmək tövsiyə olunur.
• Əsas çərçivələr. Hər seqment üçün ən azı bir IDR çərçivəsinin olması arzu edilir, tercihen seqmentin ən əvvəlində. Bundan əlavə, videonu mobil şəbəkələr vasitəsilə ötürərkən, ən azı 3 saniyədə bir dəfə əsas kadrların yaradılması tövsiyə olunur.
• TS Yerüstü. HTTP LS konteyner kimi MPEG TS-dən istifadə edir, ona görə də TS yükünü minimuma endirmək çox vacibdir (video keyfiyyəti aşağı olsa belə, 10%-dən az olmalıdır). Bu vəziyyətdə, trafik zibillərindən istifadə edərək real bit sürətlərini ölçməyə və istifadə olunan paketləyiciləri (seqmentləri) optimallaşdırmağa dəyər.
• Pleylistdəki hədəf müddəti parametri. Bu parametr işə düşmə vaxtına təsir edir, lakin Apple onu 10 saniyəyə təyin etməyi tövsiyə edir, çünki aşağı parametrlər, xüsusən də gecikmə müddəti yüksək olan mobil şəbəkələrdə buferləşmə ehtimalını artırır. 20 saniyədən uzun seqmentlər yaratmaq da tövsiyə edilmir.
• Dinamik bit sürəti.İOS-da quraşdırılmış adaptiv axın mexanizmi variant pleylistində dəqiq müəyyən edilmiş bit sürətlərində optimal işləyir (pleylistin özünün trafiki nəzərə alınmaqla). Bu halda, müxtəlif bit sürətləri olan axınlar üçün maksimuma yaxın bir dəyər təyin etməlisiniz. Əks halda, cari video axınının dəyişdirilməsi ilə bağlı yanlış qərarlar qəbul edilə bilər. Qonşu bitrates sürətdə 1,5 - 2 dəfə fərqlənməlidir.
• Yalnız audio axını. HE-AAC audio kodeki əhəmiyyətli dərəcədə daha səmərəlidir və əksər cihazlar tərəfindən dəstəklənir. Yalnız audio kanalların çatdırılmasının MPEG Elementary Stream vasitəsilə həyata keçirilməsi tövsiyə olunur, nəinki MPEG Transport Stream (əhəmiyyətli dərəcədə kiçik yük).

Video pleyerinizi inkişaf etdirərkən siz HTTP Canlı Yayım jurnalından (accessLog) faydalı məlumat əldə edə bilərsiniz. Bu, avtomatik keçidin necə baş verdiyi, hansı bit sürətlərindən istifadə edildiyi və s. Jurnalda mövcud olan məlumatlar haqqında təfərrüatlar. Bu məlumatlara əsaslanaraq, istifadəçiləriniz haqqında video analitik məlumat toplaya bilərsiniz.

Əlavə tövsiyələr
Onlayn video yayımları vəziyyətində, CDN-də gecikmələr səbəbindən, həmçinin pleylist yeniləmə vaxtının çox qısa olduğu və serverin vaxtında seqmentlər yaratmağa vaxtı olmadığı hallarda buferləmə də mümkündür. Geri sarma mexanizmini optimallaşdırmaq üçün tam olmayan (faktiki) seqment müddəti dəyərlərindən istifadə etmək tövsiyə olunur: əks halda xəta yığıla bilər.

Tətbiqinizin müxtəlif cihazlarda istifadə edilməsi nəzərdə tutulursa, siz siyahıda müxtəlif ekran qətnamələrində fərqli video keyfiyyətini təyin edə bilərsiniz. Bu yolla siz Retina displeyli iPad-də və nisbətən köhnə iPhone-da müxtəlif videolar çıxara bilərsiniz.

HTTP Live Streaming protokolu həmçinin nasazlığa dözümlülüyün təmin edilməsi mexanizmlərini təmin edir (yedək video mənbələrini qeyd etməklə). Bu funksiya xidmətlərinizin etibarlılığını artırmaq üçün faydalı ola bilər.

Bilik mənbələri
Video proqramlarda HTTP Live Streaming-dən istifadə ilə bağlı materialların qısa siyahısı:
HTTP Canlı Yayım layihəsi
HTTP Canlı Yayım Tez-tez verilən suallar
HLS üçün ən yaxşı təcrübələr

Nəhayət, qeyd etmək lazımdır ki, WWDC 2012-dən pulsuz texniki video sessiyaları qeydiyyatdan keçmiş Mac/iOS/Safari tərtibatçıları üçün əlçatandır ki, onlar da çoxlu faydalı məlumatları, xüsusən də video ilə işləmək və HTTP Live Streaming-dən istifadəni ehtiva edir.