Terdapat perubahan besar dalam dunia penyiaran digital sejak beberapa tahun kebelakangan ini. Flash, teknologi untuk menyampaikan kandungan melalui Internet yang dibangunkan oleh Adobe, sedang mengurangkan kehadirannya dengan pantas. Dan tempatnya diambil oleh protokol seperti HLS.

HTML5 dan HLS adalah sumber terbuka, boleh diubah suai mengikut kehendak anda, dan bebas untuk digunakan. Mereka juga lebih selamat, lebih dipercayai dan lebih pantas daripada pendahulunya. Dalam artikel ini kami akan cuba menerangkan konsep penyiaran dalam talian, memberikan penerangan tentang protokol penstriman dan cadangan untuk menggunakan HLS.

Apa itu HLS

HLS adalah singkatan kepada HTTP Live Streaming, protokol untuk menstrim data media melalui Internet. HLS memotong kandungan video dalam format MP4 ke dalam blok 10 saat pendek, ketulan. Serpihan pendek ini dihantar melalui HTTP, menjadikan protokol itu serasi dengan kebanyakan peranti dan tembok api.

HLS terutamanya menyediakan kualiti siaran dalam talian yang sangat baik. Tetapi, anda perlu mengambil kira bahawa kelewatan semasa penyiaran dalam talian adalah 15-30 saat. Di bahagian pelayan, pencipta siaran boleh memperuntukkan pengekodan strim kepada beberapa kualiti. Pemain kemudian secara dinamik meminta kualiti optimum berdasarkan lebar saluran Internet pada masa tertentu. Sehubungan itu, kualiti serpihan mungkin berbeza-beza.

Sebagai contoh, telefon bimbit memainkan video dalam kualiti HD, dan seminit kemudian penonton mendapati dirinya berada di kawasan penerimaan yang kurang baik. Apabila pemain mengesan penurunan dalam kualiti sambungan, ia meminta potongan video dengan kualiti yang lebih rendah. Ini mengurangkan penimbalan, pembekuan dan masalah lain.

Sejarah penciptaan HLS

HLS pada asalnya dilancarkan oleh Apple pada musim panas 2009 bersama-sama dengan iPhone 3. Model iPhone sebelumnya mengalami masalah dengan penyiaran dalam talian kerana fakta bahawa mereka kadang-kadang bertukar antara rangkaian Wi-Fi dan pemindahan data mudah alih.

Sebelum HLS dikeluarkan, protokol media penstriman utama Apple ialah Pelayan Penstriman Quicktime. Perkhidmatan yang baik, tetapi kerana ia menggunakan port bukan standard untuk penghantaran data, protokol RTSPnya disekat secara berkala oleh tembok api. Ditambah dengan Internet yang perlahan, ini membawa kepada pengabaian protokol ini. Tetapi pengajaran yang diperoleh daripada pelaksanaannya sangat berguna dalam pembangunan HLS.

Strim HLS dibuat dengan cepat dan disimpan pada pelayan HTTP. Fail video, seperti yang dinyatakan di atas, dibahagikan kepada serpihan pendek dengan sambungan .ts - MPEG2 Transport Stream.

Pelayan HTTP juga mencipta fail senarai main dengan sambungan .M3U8 (juga dipanggil manifes), yang berfungsi untuk mengindeks semua potongan video. Fail senarai main ini menunjukkan fail indeks tambahan untuk setiap kualiti siaran sedia ada. Walaupun anda memutuskan untuk menyiarkan menggunakan satu kualiti, "manifesto" masih akan dibuat.

Pemain pengguna mesti mengenali kemerosotan atau peningkatan kelajuan penghantaran data di Internet. Apabila peristiwa sedemikian berlaku, pemain mengakses fail manifes untuk menentukan kualiti video yang hendak ditukar. Pemain kemudian meminta fail indeks khusus kualiti untuk memuatkan bahagian video tempat penonton berhenti. Keseluruhan proses ini tidak dapat dilihat oleh pengguna. Protokol HLS juga menyokong kapsyen tertutup,

Gambaran keseluruhan protokol penstriman

Setiap protokol yang dibuat sebelum ini mewakili pelaksanaan beberapa inovasi dalam penstriman media. Terdapat juga "perang format", seperti HD-DVD berbanding Blu-Ray dan Betamax berbanding VHS. HLS ialah peneraju dalam penyiaran dalam talian, tetapi ini tidak selalu berlaku dan bukan hakikat bahawa ia akan kekal sedemikian pada masa hadapan.

RTMP atau Protokol Mesej Masa Nyata, protokol penstriman data masa nyata. Macromedia telah dicipta pada pertengahan tahun 2000 untuk menyampaikan kandungan audio dan video. Ia sering dipanggil hanya Flash. Macromedia kemudiannya bergabung dengan Adobe Inc, yang terus membangunkan RTMP sebagai protokol separa terbuka.

Selama sedekad yang lalu, RTMP telah menjadi kaedah penyiaran yang dominan melalui Internet. Hanya dengan kemunculan HLS bahagiannya mula berkurangan. Hari ini, kebanyakan platform video dalam talian berfungsi dengan strim RTMP masuk. Dalam erti kata lain, anda menyiarkan dalam RTMP, yang kemudiannya dikodkan oleh platform video dalam talian dalam HLS dan dihantar kepada penonton akhir. Benar, banyak pengendali CDN mula meninggalkan sokongan RTMP - bukti

Protokol penstriman generasi seterusnya yang dibangunkan oleh Adobe dipanggil HDS - HTTP Dynamic Streaming. Ia serasi dengan pemalam main balik Flash, tetapi kekerapan penggunaannya jauh lebih rendah daripada HLS biasa.

Untuk peranti dan penyemak imbas yang menyokong Flash, HDS ialah pilihan terbaik. Ia memberikan kelewatan yang minimum semasa penyiaran, sama seperti HLS, ia membahagikan fail media kepada serpihan kecil, menyokong penyulitan dan DRM.

Microsoft Smooth Streaming

Microsoft telah mencipta protokol penstriman dalam taliannya sendiri, Microsoft Smooth Streaming. MSS juga menggunakan kadar bit adaptif untuk menyampaikan kandungan dalam kualiti yang terbaik.

Penyiaran kadar bit suai telah diperkenalkan pada tahun 2008. MSS digunakan untuk menyiarkan Sukan Olimpik Musim Panas 2008. Pengguna utama jenis penyiaran ini ialah platform XBox One. Pada masa yang sama, MSS adalah salah satu protokol yang paling kurang popular hari ini.

MPEG-DASH

Salah satu penyelesaian penting terkini dalam bidang protokol penstriman ialah MPEG-DASH, di mana DASH bermaksud Penstriman Adaptif Dinamik melalui HTTP.

Kelebihan MPEG-DASH ialah ia diiktiraf sebagai standard antarabangsa bersatu untuk penyiaran media melalui HTTP. Pada masa ini, ia masih belum meluas dan tidak semua penyiar menyokongnya. Tetapi, mengikut semua akaun, dalam beberapa tahun piawaian tertentu ini akan menjadi protokol penyiaran paling popular.

MPEG-DASH tidak bergantung pada jenis codec, anda boleh menggunakan mana-mana daripadanya untuk menghantar media menggunakan protokol ini - H.264, HEVC/H.265, VP10

Bila hendak menggunakan HLS untuk penyiaran dalam talian

Kami mengesyorkan menggunakan HLS sepanjang masa. Ia adalah protokol penstriman media yang paling moden dan disokong secara meluas. Anda tidak boleh melakukannya tanpanya jika anda ingin menyiarkan ke peranti mudah alih. Sokongan pemain HTML5 asli dan, sudah tentu, kadar bit adaptif memastikan kualiti tontonan yang optimum.

Seperti yang ditunjukkan oleh amalan, pengangkutan terbaik untuk video berbanding RTMP ialah HLS. Sebab untuk ini:

Proksi yang sangat mudah, dengan caching melalui nginx. Di tempat pertama, kerana kamera, sebagai peranti, tidak boleh, sebagai peraturan, mengendalikan lebih daripada 10 sambungan serentak. Dalam pengertian ini, proksi terjamin bagi aliran RTMP hanya boleh dilakukan melalui penyelesaian berbayar dan memerlukan kapasiti yang besar. Tiada perisian pelayan khas diperlukan.

Memudahkan keseluruhan infrastruktur pelayan. Berdasarkan idea itu, video itu dihantar secara berkeping-keping, melalui port 80 melalui http. Nginx sendiri mungkin bertanggungjawab untuk menyampaikan data statik. Mengembalikan fail statik (kepingan video 50 kB setiap satu) adalah tugas yang sangat mudah untuk nginx.

Sokongan untuk kebanyakan peranti mudah alih, desktop dan tablet terus daripada penyemak imbas.

Jauh lebih mudah daripada penyiaran melalui RTSP pada dasarnya. Memandangkan tiada prosedur seperti menolak (menerbitkan aliran) atau menarik (menerima aliran).

Lebih banyak lagi format mesra http.

Kelemahannya adalah seperti berikut:

Namun, tidak semua peranti menyokong format ini. Versi Android kurang daripada 4.2 tidak menyokong codec dan pengangkutan H.264 secara rasmi, tetapi pada Android, bukannya penyemak imbas, anda boleh menggunakan aplikasi pihak ketiga untuk melihat - contohnya MX Player

Semuanya bergantung pada kamera. Jika kamera buggy, contohnya Dlink DCS-3010, maka keseluruhan sistem akan berfungsi dengan teruk (ffmpeg sentiasa jatuh). Sebagai contoh, kamera AXIS M1011-W, HIKVISION DS-2CD2412F-IW berfungsi dengan baik dalam kombinasi ini (sehingga sebulan tanpa aduan (saya hanya tidak mengujinya lebih lama)). Penghalaan kabel juga sangat penting. Dalam pengertian ini, kami akan mempertimbangkan pilihan yang ideal.

Apakah pengangkutan HLS

Strim video dalam pengekodan h.264 (Dengan cara ini: garis dasar profil difahami oleh peranti Android), dibahagikan kepada bahagian dengan sambungan *.ts, sebagai contoh, 5 saat setiap satu, senarai main dibuat dalam live.m3u8, dengan penerangan berurutan bagi kepingan ini. Panjang senarai main ditentukan terlebih dahulu, contohnya 10 keping. Apabila sekeping video ke-11 muncul, 1 keping video dipadamkan, senarai main dibuat semula. Butiran lanjut boleh didapati di tapak web pembangun.

Untuk sistem berfungsi, kami akan mengkonfigurasi imej daripada kamera dengan cara yang kami mahu lihat di tapak, format imej dan kualiti imej. Kami tidak akan mengekod semula pada pelayan. Inilah sebabnya mengapa kamera dicipta untuk menghasilkan imej yang diperlukan. Kamera biasanya mempunyai beberapa profil. Anda boleh mengkonfigurasi satu profil untuk H.264, untuk HLS dan yang kedua dengan MPEG4 untuk MPEG-DASH. Anda juga boleh mengkonfigurasi kualiti yang berbeza untuk saluran Internet yang luas dan sempit. Fikir sendiri - tentukan sendiri.

Penting! Kamera harus mengeluarkan imej yang tidak perlu dikodkan semula.

Gambar rajah blok untuk beban tinggi

Kamera(rtsp) ----->

-----> satu sambungan FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-modul) ----->

-----> satu sambungan ke proksi nginx perantaraan dengan cache besar =====>

=====> ramai pelanggan JWPlayer(hls).

Pelayan kami menyambung menggunakan ffmpeg ke kamera dan mendaftar dengan aplikasi nginx hls. nginx mencipta kepingan dan senarai main dalam direktori tertentu. Kemudian ia menghantar kepingan ini ke pelayan proksi. Pelanggan menyambung kepada proksi menggunakan JWPlayer.

Menyediakan aplikasi nginx

Mari bina nginx dengan nginx-rtmp-module. Prosedur ini diterangkan secara terperinci dalam artikel.

Katakan kita mempunyai beberapa kamera, bahagikan dengan nombor siri. Saya akan menerangkan konfigurasi nginx untuk 2 kamera. Kami menyimpan imej statik selama 5 minit dalam cache tempatan jika imej tidak dimuatkan dalam masa 5 saat, kami menghantar penyelamat skrin statik.

# nano /etc/nginx/nginx.conf

Mari edit konfigurasi nginx

pengguna www - data ;

pekerja_memproses auto ;

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

env PATH ;

peristiwa ( # multi_accept on ; ) http ( access_log / var / log / nginx / access . log ; error_log / var / log / nginx / error. log ; include mime . types ; default_type application / octet - stream ; sendfile on ; keepalive_timeout 65 ; proxy_cache_path / var / www / cache / local level = 1 : 2 keys_zone = nginx_local_cache : 1 m tidak aktif = 30 m max_size = 512 M ; stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) lokasi / stat xsl ( # anda boleh memindahkan stat. xsl ke akar lokasi yang berbeza / etc / nginx ; ) lokasi / ( rtmp_control all ; ) error_page 500 502 503 504. . html ; lokasi = / 50 x html ( root html ; ) termasuk cameras_http_locations ) rtmp ( access_log / var / log / nginx / rtmp_access. log ; server ( listen 1935 ; ping 30 s ; notify_method get ;

sertakan cameras_rtmp_applications . conf ; ) ) Mari kita cipta laluan untuk cache # mkdir /var/www/cache/local Mari kita betulkan hak untuk cache: # chmod -R 755 /var/www/cache/local# chown -R www-data:www-data /var/www/cache/local` Mari buat lokasi http untuk kamera: # nano cameras_http_locations.conf; proxy_set_header Kebenaran "Asas" ; error_page 502 504 404 @ fallback_img ;) # berikan senarai main - /1/hls/live.m3u8 atau /3/hls/live.m3u8 # senarai main dicache selama 10 saat pada proksi lokasi ~* /hls/ . *\. m3u8 $ ( tulis semula "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 rehat ; # permintaan tulis semula / 1 / hls / to / hls - 1 / root / tmp / ; tamat tempoh 10 s ; add_header Cache - Kawal awam ;# berikan sekeping video daripada kamera - /1/hls/live-12345678.ts atau /2/hls/live-12345678.ts # caching pada komputer tempatan tidak diperlukan# sekeping dicache selama 3 minit pada proksi

lokasi ~* /hls/ . *\. ts $ ( tulis semula "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; tamat tempoh 3 m ; add_header Cache - Control public ; )

# nama lokasi jika tiada imej

lokasi @ fallback_img ( tulis semula ( . + ) / fallback . jpg break ; root / etc / nginx / ; ) Mari buat fail hls untuk konfigurasi pelayan rtmp dengan aplikasi untuk kamera kami: # nano cameras_rtmp_applications.conf chunk_size 4000 ; aplikasi hls_1 ( secara langsung ; segerak 10 ms ; exec_static ffmpeg - i rtsp : Mari buat fail hls untuk konfigurasi pelayan rtmp dengan aplikasi untuk kamera kami: # nano cameras_rtmp_applications.conf//pentadbir:[e-mel dilindungi]

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

hls pada;

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 - 17072820. ts #EXTINF. ts :5.280, live - 17544960. ts #EXTINF:5.251, live - 18020160. ts #EXTINF:5.228, live - 18492750. ts #EXTINF:5.242, live - 18963270. ts

Menyelesaikan masalah dengan kamera jatuh

Penyelesaian terbaik ialah menukar kamera glichy. Ini membantu dalam 90% kes. Sekiranya tidak ada cara dan anda perlu meneruskannya, maka penyelesaian berikut akan membantu.

Penyelesaian ini terdiri daripada dua penyelesaian pelengkap:

Jalankan proses nginx yang berasingan untuk setiap kamera dan proses biasa untuk mengembalikan data statik. Iaitu, untuk dua kamera tulis konfigurasi berasingan dengan pelayan rtmp dan satu biasa dengan http. Kemudian kamera glichy tidak akan menjejaskan keseluruhan proses.

Jika aliran daripada kamera terganggu akibat gangguannya (terlalu panas, selongsong yang lemah, bekalan kuasa PoE tidak mencukupi, dsb.), maka kamera akan jatuh, proses anak ffmpeg akan menolak paket dan nginx akan berhenti merakam kepingan video . Dan apabila proses ffmpeg tamat, nginx akan memadam semua fail dari direktori ketulan. Kami mengira detik ini untuk membersihkan folder menggunakan cron dan mulakan semula proses nginx yang diperlukan.

Untuk setiap kamera, skrip boleh laku dibuat dalam /etc/init.d/, salinan nginx, bernama camera_1 dan 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

Mengedit skrip permulaan nginx.

nano/etc/init. d/nginx

Tukar pembolehubah DAEMON_OPTS. Daemon nginx utama akan membekalkan semua data statik. Ia juga akan memulakan dan menghentikan daemon yang bertanggungjawab untuk kamera./ init . d / camera_1 hentikan fi jika [ - f "/etc/init.d/camera_2" ];

kemudian / etc / init . d/camera_2 stop fi

Tambahkan pada fungsi do_reload:

# muat semula kamera jika [ - f "/etc/init.d/camera_1" ];

kemudian / etc / init . d / camera_1 muat semula fi jika [ - f "/etc/init.d/camera_2" ];

kemudian / etc / init . d/camera_2 muat semula fi

Kami mengedit skrip pelancaran nginx untuk kamera 1 camera_1 dan untuk kamera 2 camera_2 mengikut contoh.

# nano /etc/init.d/camera_1

Tukar pembolehubah DAEMON_OPTS dan DESC

DESC = "kamera_1 untuk CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf" Mari edit skrip permulaan nginx untuk camera 2 camera_2 mengikut contoh.

Mereka menunjukkan, dipisahkan oleh ruang, perkataan yang dicari DIR-PROCESS-NAME, direktori dan nama proses yang perlu dibut semula.

Peperiksaan:

# servis nginx mula # servis camera_1 mulakan semula * Mulakan semula camera_1 untuk CAMERA - 1 konfigurasi nginx # service camera_2 mulakan semula * Mulakan semula camera_2 untuk CAMERA - 2 konfigurasi nginx

Skrip yang but semula kamera. Ia melalui folder dengan kepingan, mencari folder yang tiada fail *.m3u8. Jika tiada fail dalam folder, ia mencari daemon yang sepadan menggunakan konfigurasi daemon utama, menggunakan baris DIR-PROCESS-NAME. But semula.

# 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-*" function find_process())( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) untuk hls_dir dalam $dir ; lakukan find_result = $(cari $hls_dir -name $mask -type f) jika [ -z $find_result] ; kemudian proses = $(find_process $hls_dir ) perkhidmatan $proses mulakan semula fi selesai tidur 15s

Perbandingan HLS dengan MPEG-DASH

MPEG-DASH ialah analog HLS yang dicipta oleh Google sebagai pengangkutan untuk MPEG-4. Pengangkutan ini tidak meluas dan boleh dikatakan tidak disokong. Ideologinya pun sama, pecahkan alirannya, cuma ada lagi keping, pisahkan untuk video, pisahkan untuk audio. Dalam nginx-rtmp-module format ini dikonfigurasikan sama dengan HLS.

Cuba, salin, berani!

Sekiranya artikel itu berguna kepada anda, sila klik pada iklan tersebut. terima kasih!

Penyediaan perkhidmatan IPTV melalui Internet dan rangkaian komputer tempatan memperoleh bentuk yang semakin meluas. Hampir tiada pembekal besar yang tinggal di negara CIS yang tidak menyiarkan video melalui multicast ke dalam rangkaian tempatan mereka, iaitu, menyediakan perkhidmatan IPTV. Tetapi menyediakan perkhidmatan TV di luar rangkaian tempatan anda dikaitkan dengan beberapa kos perkakasan dan kesukaran untuk memastikan kualiti siaran yang diperlukan.

Penstriman Langsung HTTP juga dikenali sebagai H.L.S., ialah protokol komunikasi yang dilaksanakan oleh Apple. Keanehannya ialah aliran keseluruhan dibahagikan kepada urutan fail muat turun kecil, setiap muat turun memuat turun satu serpihan kecil aliran pengangkutan. Apabila strim dimainkan, pelanggan boleh memilih daripada beberapa aliran alternatif berbeza yang mengandungi bahan yang sama, direkodkan pada kadar bit yang berbeza, membolehkan ia menyesuaikan diri dengan kadar bit yang tersedia. Pada permulaan sesi penstriman, senarai main M3U (m3u8) yang dipertingkatkan dimuatkan yang mengandungi metadata untuk pelbagai substrim yang tersedia. Oleh kerana permintaan hanya menggunakan operasi HTTP standard, Penstriman Langsung HTTP dapat memintas mana-mana tembok api atau proksi yang membenarkan trafik HTTP standard berbanding protokol UDP seperti RTP.

HLS adalah berdasarkan HTTP. HLS juga mentakrifkan mekanisme penyulitan standard menggunakan AES dan kaedah pengedaran kunci keselamatan menggunakan kuki HTTPS atau HTTP, yang bersama-sama menyediakan sistem perlindungan hak cipta yang mudah.

Bagaimanakah HLS berfungsi?

Sekarang mari kita ketahui apakah kelebihan dan kekurangan teknologi ini. Kelebihannya tidak diragui dan jelas. Ini, pertama sekali, kebolehsuaian kelajuan penghantaran data kepada sifat talian dan peranti penerima, dan kedua, mekanisme perlindungan hak cipta terbina dalam. Ketiga, tiada penghala dengan had lebar diperlukan aliran multicast melalui WI_FI, yang akan membantu mengelakkan penyerapan keseluruhan lebar saluran oleh aliran multicast dalam kes penyiaran televisyen IP menggunakan multicast. Selain itu, tiada peranti tambahan dengan fungsi diperlukan Proksi UDP untuk menukar strim multicast kepada HTTP, yang selalunya diperlukan untuk peranti mudah alih, walaupun ia menjejaskan beban perkakasan pada penghala atau peranti lain yang melaksanakan fungsi proksi UDP dalam rangkaian tempatan pelanggan. Piawaian HLS telah menjadi agak meluas dan disokong oleh hampir semua pemain video moden dan kotak atas set IPTV.

Kotak set atas IPTV

Kelemahan yang ketara ialah pelanggan mempunyai kotak set atas multimedia dan kotak set atas TV pintar dengan perisian tegar lapuk atau reka bentuk lapuk yang tidak menyokong piawaian HLS atau tidak menyokongnya dengan betul. Selain itu, salah satu masalah ialah ketidakupayaan untuk memilih kualiti dengan betul untuk penyiaran yang stabil dalam keadaan perubahan ciri talian dalam selang masa yang lebih pendek daripada tempoh serpihan video yang diminta.

Untuk mengatur siaran dalam talian dalam masa nyata, video atas permintaan (vod), serta untuk merakam aliran video, anda boleh menggunakan nginx bersama-sama dengan modul nginx-rtmp-modul.

Pelayan media

Hari ini terdapat beberapa pelayan media yang popular, yang boleh anda baca lebih lanjut dalam salah satu daripadanya. Pelayan media diperlukan untuk membuat siaran dalam talian dalam masa nyata.

Terdapat kedua-dua pelayan media berbayar dan percuma yang merangkumi fungsi yang berbeza. Hari ini kita akan bercakap tentang satu penyelesaian percuma dan cukup bagus.

Ngnix-rtmp

Fungsi asas pelayan media juga boleh dilaksanakan menggunakan perisian percuma - modul Ngnix-rtmp-module, yang kini menyokong protokol penstriman seperti RTMP dan HLS.

Oleh itu, menggunakan Ngnix-rtmp (pelayan web Ngnix + modul modul Ngnix-rtmp-modul), anda boleh mengatur penyiaran RTMP dan HLS ke peranti pengguna. Jadual ringkasan protokol dan peranti yang menyokongnya boleh didapati dalam artikel. Juga, dalam salah satu artikel masa depan saya, saya merancang untuk membuat jadual perbandingan kefungsian modul Ngnix-rtmp-modul dan pelayan media lain.

Siaran dalam talian melalui protokol HLS

Hari ini kita akan melihat cara mengatur siaran mudah dengan bitrate adaptif menggunakan protokol HLS menggunakan modul Nginx-rtmp. Pertama sekali, kita perlu memuat turun kod sumber pelayan web Nginx dari laman web rasmi. Semua arahan yang dibentangkan di bawah telah dilaksanakan dalam Linux.

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

Ekstrak fail daripada arkib.

• tar -zxvf nginx-1.4.1.tar.gz

Muat turun arkib zip dengan fail sumber modul nginx-rtmp-module dan ekstrak fail daripada arkib.

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

Sekarang kita perlu menyusun nginx dengan modul nginx-rtmp-modul , untuk melakukan ini, apabila mengkonfigurasi nginx, anda perlu menentukan dalam pilihan --tambah-modul lokasi fail sumber nginx-rtmp-modul , dan anda juga mesti menentukan pilihan tambahan dengan-http_ssl_module .

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

buat pemasangan

• Jika semuanya berjalan tanpa ralat, anda boleh mula menyediakan pelayan. Secara lalai, pelayan dipasang dalam direktori/usr/local/nginx . Fail konfigurasi pelayan nginx.conf terletak dalam direktori/usr/local/nginx/conf . Mari kita lihat dengan lebih dekat bahagian rtmp:server pada fail konfigurasi. Parameter dengar menentukan port yang pelayan akan menerima permintaan rtmp.
• Seterusnya kami membuka bahagian untuk menyediakan aplikasi testlive. Di sini kami menunjukkan bahawa kami mempunyai strim langsung - parameter live on, kami mendayakan sokongan untuk protokol hls untuk aplikasi ini - parameter hls on.
• Menggunakan parameter hls_path kami menetapkan direktori di mana ketulan (kepingan) aliran akan ditempatkan. Agar ketulan (kepingan) untuk setiap strim video ditempatkan dalam direktori yang berasingan, anda perlu memasukkan arahan hls_nested on .
• Seterusnya, menggunakan parameter benarkan penerbitan kami membenarkan anda menerbitkan strim daripada komputer anda dan menggunakan parameter menafikan menyiarkan semua Kami melarang orang lain daripada menerbitkan video.
• Sekarang mari kita lihat bahagianhttp:pelayan . Dalam parameter dengar adalah perlu untuk menunjukkan pada port apa yang akan diterima oleh pelayanhttp permintaan. Kami menentukan port 8080. Dan dari fail konfigurasi contoh alihkan bahagian tersebuthttp:server:location/hls . Anda boleh melihat maklumat lebih terperinci tentang semua arahan fail konfigurasi di:https://github.com/arut/nginx-rtmp-module/wiki/Direktif.
• Sudah tiba masanya untuk memulakan pelayan. Untuk melakukan ini, anda perlu pergi ke direktori /usr/local/nginx/bin dan jalankan arahan ./nginx .

Sekarang mari kita lihat satu contoh. Kami menghantar tiga aliran video ke pelayan:

• ujian1 dengan kadar bit 256 kbit/s,
• ujian2 dengan kadar bit 512 kbit/s,
• ujian3 dengan kadar bit 1024 kbps.

Matlamat kami adalah untuk pelanggan yang menggunakan protokol HLS (peranti: Mac, iPad, iPhone) dapat bertukar secara dinamik antara strim, bergantung pada kualiti sambungan Internet. Untuk melakukan ini kita perlukan dalam direktori /usr/local/nginx/html buat fail dengan sambungan m3u8 , Sebagai contoh senarai main.m3u8 , dengan kandungan berikut:

#EXTM3U

#EXT-X-VERSION:3

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

hls/test1/index.m3u8

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

hls/test2/index.m3u8

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

hls/test3/index.m3u8

Tonton siaran

Untuk melihat strim video, anda perlu membenamkan kod berikut ke dalam halaman web tapak.

- Alamat IP pelayan nginx anda.

[nama senarai main]- nama fail yang dibuat dalam perenggan sebelumnya (senarai main.m3u8).

Di bawah ialah contoh fail konfigurasi nginx.conf yang mudah.

proses_pekerja 1;

pelayan (

dengar 1935;

ujian permohonan secara langsung (

hidup terus;

hls pada;

hls_path /tmp/hls;

hls_nested on;

benarkan penerbitan 10.10.146.148;

menafikan menerbitkan semua;

pelayan (

dengar 8080;

server_name rtmp_test;

charset utf-8;

lokasi/(

html akar;

indeks index.html index.htm;

lokasi /hls (

jenis (

application/vnd.apple.mpegurl m3u8;

alias /tmp/hls;

Kesimpulan

Artikel ini ditulis dan diterbitkan bersama dengan rakan sekerja saya Evgeniy Petrov. Kami menggunakan modul ini (Ngnix-rtmp) dalam projek yang berbeza. Jika sesiapa mempunyai sebarang soalan tentang Ngnix-rtmp, pelayan Wowza, tulis. Jika anda perlu mengkonfigurasi sesuatu atau mendapatkan nasihat tentang pelayan media dan sistem multimedia, anda juga boleh menghubungi saya dan pasukan kami melalui.

Mencipta aplikasi teknikal yang sempurna biasanya merupakan tugas yang sangat sukar dan memakan masa. Pada masa yang sama, maklumat berguna sering tersebar di banyak sumber. Ini terpakai, antara lain, untuk pembangunan aplikasi video untuk iOS. Artikel ini mengandungi maklumat yang paling penting dan berguna yang membolehkan anda menggunakan rangkaian penuh keupayaan Penstriman Langsung HTTP, serta senarai sumber utama. Bahan-bahan ini akan berguna kepada semua pembaca yang berminat untuk mencipta perkhidmatan video berkualiti tinggi dan mesra pengguna.

Meningkatkan kemudahan dan interaktiviti perkhidmatan video dicapai melalui pelancaran pantas dan gulung semula, serta ketiadaan penimbalan. Untuk mencapai hasil terbaik, set tindakan berikut dicadangkan.

• Mulakan dengan kualiti video yang rendah. Untuk memulakan video, sekurang-kurangnya satu bahagian diperlukan. Sehubungan itu, lebih kecil saiz satu bahagian, lebih cepat video akan dimulakan. Mengurangkan kadar bit strim permulaan dan mengurangkan tempoh bongkah membawa kepada pelancaran video yang lebih pantas. Kami mengesyorkan tempoh potongan 4-8 saat dan kadar bit permulaan 200-300 Kbps. Oleh itu, untuk mula memainkan video, pengguna perlu memuat turun maksimum 300 KB.
• Pengoptimuman senarai main. Senarai main boleh mengambil sebahagian besar daripada keseluruhan strim data, terutamanya dengan saiz ketulan kecil dan kandungan tahan lama (beberapa jam). Dalam kebanyakan kes, apabila memindahkan senarai main ke pemain video, adalah disyorkan untuk mengarkibkannya.
• Bingkai utama. Adalah wajar untuk mempunyai sekurang-kurangnya satu bingkai IDR bagi setiap segmen, sebaik-baiknya pada permulaan segmen. Di samping itu, apabila menghantar video melalui rangkaian selular, adalah disyorkan untuk mencipta bingkai utama sekurang-kurangnya sekali setiap 3 saat.
• TS Overhed. HTTP LS menggunakan MPEG TS sebagai bekas, jadi sangat penting untuk meminimumkan overhed TS (sepatutnya kurang daripada 10% walaupun dengan kualiti video yang rendah). Dalam kes ini, adalah berbaloi untuk mengukur kadar bit sebenar menggunakan pembuangan trafik dan mengoptimumkan pembungkus terpakai (segmenter).
• Parameter tempoh sasaran dalam senarai main. Tetapan ini menjejaskan masa permulaan, tetapi Apple mengesyorkan menetapkannya kepada 10 saat kerana tetapan yang lebih rendah meningkatkan kemungkinan penimbalan, terutamanya pada rangkaian selular dengan kependaman tinggi. Ia juga tidak disyorkan untuk membuat segmen lebih lama daripada 20 saat.
• Kadar bit dinamik. Mekanisme penstriman adaptif yang dibina ke dalam iOS berfungsi secara optimum pada kadar bit yang ditentukan dengan tepat dalam senarai main varian (dengan mengambil kira trafik senarai main itu sendiri). Dalam kes ini, untuk strim dengan kadar bit yang berbeza-beza, anda perlu menentukan nilai yang lebih hampir kepada maksimum. Jika tidak, keputusan yang salah tentang menukar strim video semasa adalah mungkin. Kadar bit jiran harus berbeza dalam kelajuan sebanyak 1.5 - 2 kali.
• Strim audio sahaja. Codec audio HE-AAC jauh lebih cekap dan disokong oleh kebanyakan peranti. Penghantaran saluran audio sahaja disyorkan untuk dilaksanakan menggunakan MPEG Elementary Stream, dan bukan MPEG Transport Stream (overhed yang jauh lebih kecil).

Semasa anda membangunkan pemain video anda, anda boleh mendapatkan maklumat berguna daripada log Penstriman Langsung HTTP (accessLog). Ia mengandungi data tentang cara penukaran automatik berlaku, kadar bit yang digunakan, dsb. Butiran tentang maklumat yang terdapat dalam log. Berdasarkan data ini, anda boleh mengumpul data analitis video pada pengguna anda.

Cadangan tambahan
Dalam kes siaran video dalam talian, penimbalan juga mungkin disebabkan oleh kelewatan dalam CDN, serta dalam kes di mana masa kemas kini senarai main terlalu singkat dan pelayan tidak mempunyai masa untuk menjana segmen dalam masa. Untuk mengoptimumkan mekanisme gulung semula, adalah disyorkan untuk menggunakan nilai tempoh segmen bukan integer (sebenar): jika tidak, ralat mungkin terkumpul.

Jika aplikasi anda bertujuan untuk digunakan pada peranti yang berbeza, anda boleh menentukan kualiti video yang berbeza dalam senarai pada resolusi skrin yang berbeza. Dengan cara ini, anda boleh mengeluarkan video yang berbeza pada iPad dengan paparan Retina dan pada iPhone yang agak lama.

Protokol Penstriman Langsung HTTP juga menyediakan mekanisme untuk memastikan toleransi kesalahan (menentukan sumber video sandaran). Ciri ini boleh berguna untuk meningkatkan kebolehpercayaan perkhidmatan anda.

Sumber ilmu
Senarai pendek bahan tentang menggunakan HTTP Live Streaming dalam aplikasi video:
Draf Penstriman Langsung HTTP
Penstriman Langsung HTTP Soalan Lazim
Amalan Terbaik untuk HLS

Akhir sekali, perlu diingat bahawa sesi video teknikal percuma dari WWDC 2012 tersedia untuk pembangun Mac/iOS/Safari yang berdaftar, yang juga mengandungi banyak maklumat berguna, khususnya mengenai bekerja dengan video dan menggunakan Penstriman Langsung HTTP.