Skonfiguruj Nginx na Ubuntu, aby przesyłać strumieniowo wideo na żywo HLS

HTTP Live Streaming (HLS) to bardzo solidny protokół przesyłania strumieniowego wideo wdrożony przez Apple Inc. HLS wykorzystuje transakcje HTTP, które z łatwością przechodzą przez zapory ogniowe, serwery proxy i mogą być dystrybuowane za pośrednictwem sieci CDN. Dlatego ta technologia jest w stanie dotrzeć do znacznie większej liczby odbiorców niż RTP lub inne protokoły oparte na UDP. Większość dzisiejszych strumieniowych transmisji wideo online jest obsługiwana przez drogie systemy korzystające z HLS, ale są one generalnie drogie i wymagają dużej ilości zasobów serwerowych. W tym samouczku pokażemy, jak skonfigurować bardzo przystępny cenowo system Ubuntu 14.04 VULTR VPS, aby przeprowadzać transmisje na żywo HLS przy użyciu tylko oprogramowania typu open source.

Pierwszym krokiem jest przeczytanie i skonfigurowanie serwera zgodnie z Vultr Doc „ Instalacja Nginx-RTMP na Ubuntu 14.04 ”. Instrukcje w tym dokumencie były najbardziej wyczerpujące na etapie instalacji w momencie pisania. Wspomnę, że możesz zastąpić „nginx-1.7.5” „nginx-1.9.4” lub jakąkolwiek najnowszą dostępną wersją Nginx. Inną sugestią jest skompilowanie Nginx z modułem statusu kodu pośredniczącego HTTP, aby umożliwić sobie monitorowanie liczby przeglądających HLS na żywo, które masz później.

Zamiast kompilować z:

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

Użyj tego ciągu w procedurze opisanej we wstępnym dokumencie:

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

Przykład w tym samouczku utworzy zarówno strumień „na żywo”, jak i „mobilny” (zoptymalizowany) i użyje programu ffmpeg (zainstalowanego w poprzednim samouczku) do wygenerowania strumienia HLS zoptymalizowanego pod kątem przepływności. Przykład pokaże także, w jaki sposób zmusić serwer do automatycznego nagrywania twoich transmisji na żywo i umożliwić odtwarzanie nagrań jako usługi odtwarzania wideo na żądanie (VOD).

Najpierw utwórz struktury folderów niezbędne do przechowywania manifestów i fragmentów wideo HLS na żywo i na urządzeniach mobilnych:

sudo mkdir /HLS
sudo mkdir /HLS/live
sudo mkdir /HLS/mobile
sudo mkdir /video_recordings
sudo chmod -R 777 /video_recordings

Prawdopodobnie dobrym pomysłem jest włączenie zapory sieciowej, jeśli jeszcze tego nie zrobiłeś. Jeśli tak, musisz zezwolić na ruch do portów używanych przez Nginx i HLS. Jeśli na razie chcesz uruchomić zaporę ogniową, zignoruj ​​sekcję ufw poniżej.

sudo ufw limit ssh
sudo ufw allow 80
sudo ufw allow 1935
sudo ufw enable

Przesyłanie strumieniowe HLS wymaga znacznie innej konfiguracji Nginx niż konfiguracji RTMP w pierwszym artykule. Edytuj nginx.confplik, aby użyć następujących, zastępując „my-ip” i „my-stream-key” informacjami. Możesz użyć czegokolwiek, co chcesz, do „my-stream-key” to tylko jedno słowo, które jest dla ciebie wyjątkowe i pomocne. Możesz najpierw wykonać kopię zapasową oryginalnego pliku konfiguracyjnego, a następnie wkleić dostarczone informacje o konfiguracji do edytora, zastępując wszystko, co tam było:

sudo cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.original
sudo nano /usr/local/nginx/conf/nginx.conf

Nowy plik nginx.conf:

worker_processes  1;
error_log  logs/error.log debug;
events {
worker_connections  1024;
}
rtmp {
server {
listen 1935;
allow play all;

#creates our "live" full-resolution HLS videostream from our incoming encoder stream and tells where to put the HLS video manifest and video fragments
application live {
allow play all;
live on;
record all;
record_path /video_recordings;
record_unique on;
hls on;
hls_nested on;
hls_path /HLS/live;
hls_fragment 10s;

#creates the downsampled or "trans-rated" mobile video stream as a 400kbps, 480x360 sized video
exec ffmpeg -i rtmp://192.168.254.178:1935/$app/$name -acodec copy -c:v libx264 -preset veryfast -profile:v baseline -vsync cfr -s 480x360 -b:v 400k maxrate 400k -bufsize 400k -threads 0 -r 30 -f flv rtmp://192.168.254.178:1935/mobile/$;
}

#creates our "mobile" lower-resolution HLS videostream from the ffmpeg-created stream and tells where to put the HLS video manifest and video fragments
application mobile {
allow play all;
live on;
hls on;
hls_nested on;
hls_path /HLS/mobile;
hls_fragment 10s;
}

#allows you to play your recordings of your live streams using a URL like "rtmp://my-ip:1935/vod/filename.flv"
application vod {
play /video_recordings;
}
}
}


http {
include       mime.types;
default_type  application/octet-stream;

server {
listen 80;
server_name 192.168.254.178;

#creates the http-location for our full-resolution (desktop) HLS stream - "http://my-ip/live/my-stream-key/index.m3u8"      
location /live {
types {
application/vnd.apple.mpegurl m3u8;
}
alias /HLS/live;
add_header Cache-Control no-cache;
}

#creates the http-location for our mobile-device HLS stream - "http://my-ip/mobile/my-stream-key/index.m3u8"        
location /mobile {
types {
application/vnd.apple.mpegurl m3u8;
}
alias /HLS/mobile;
add_header Cache-Control no-cache;
}   

#allows us to see how stats on viewers on our Nginx site using a URL like: "http://my-ip/stats"     
location /stats {
stub_status;
}

#allows us to host some webpages which can show our videos: "http://my-ip/my-page.html"     
location / {
root   html;
index  index.html index.htm;
}   
}
}

Naciśnij Ctrl + X, aby wyjść. Powiedz „tak”, aby zapisać zmiany.

W tym nginx.confpliku można znaleźć jasne instrukcje i przykłady zmiennych możliwych , jeśli zapytasz swoją ulubioną wyszukiwarkę o „dyrektywy nginx-rtmp”. Używam nginx-rtmp z HLS od kilku lat, bez użycia dyrektyw „zezwalaj na publikowanie” i „odmawiaj publikowania” i widziałem zero przypadków osób używających / atakujących moje serwery wideo. Więc nie zawarłem tutaj tych dyrektyw. Przeczytaj i dodaj te dyrektywy, jeśli chcesz.

Po zmianie nginx.confpliku musisz zrestartować Nginx, aby użyć nowej konfiguracji:

sudo service nginx restart

Uważnie obserwuj wszelkie komunikaty o błędach Nginx i usuwaj wszelkie błędy, które mogły być spowodowane błędną pisownią, własnością folderu lub problemami z uprawnieniami. Jeśli nie masz żadnych komunikatów o błędach, możesz utworzyć strumień kodowania.

Musisz mieć koder wideo, aby utworzyć strumień. Używam OBS (Open Broadcaster Software) - oprogramowania typu open source i działa dobrze dla mnie. Istnieją inne rozwiązania do wyboru, które są poza zakresem tego samouczka. Nie omówię wszystkiego na temat konfigurowania kodera wideo RTMP. Wszystkie wymagają jednak mniej więcej tych samych zmiennych wejściowych. Kluczowe ustawienia, które musisz wprowadzić, aby użyć mojej dokładnej nginx.confkonfiguracji i dobrze funkcjonować w większości odtwarzaczy / przeglądarek / platform, są następujące:

1. Encoder-x264
2. Zmienna przepływność (nie CBR lub stała przepływność), najwyższa jakość
3. Maksymalna przepływność - 600 kb / s
4. Audio-Codec-AAC
5. Format audio-44,1 kHz
6. Audio-bitrate-64kbps
7. FMS URL- „rtmp: // my-ip: 1935 / live”
8. Klucz strumienia - „mój klucz strumienia”
9. Rozdzielczość 640x480
10. FPS (klatki na sekundę) -30
11. CFR (Constant Frame Rate) - Tak
12. Interwał klatki kluczowej - 2 sekundy (jedna klatka kluczowa co 2 sekundy)
13. Kodowanie x264 Profil podstawowy (może działać z głównym - zależy od użytego odtwarzacza)
14. Procesor x264 Bardzo szybki

Polecam wypróbowanie różnych koderów i eksperymentowanie z nimi. Możesz potrzebować szerokiego współczynnika proporcji - lub może wymagać tego twój aparat (lub inna transmisja). Jeśli tak, pamiętaj o zmianie tych informacji w koderze, a także o proporcjach wymienionych w sekcji exec-ffmpeg nginx.confpliku, który dostarczyłem; w przeciwnym razie dostaniesz trochę głupkowato wyglądających kanałów wideo.

Po skonfigurowaniu enkodera możesz przetestować wszystko. Uruchom koder za pomocą kamery internetowej lub działającej na nim paszy testowej. W tym momencie możesz obejrzeć transmisję za pomocą odtwarzacza VLC, używając adresów URL takich jak:

http://my-ip/live/my-stream-key/index.m3u8
http://my-ip/mobile/my-stream-key/index.m3u8

Są to odpowiednio dla głównego i mobilnego strumienia wideo. Zastąp swój adres IP i odpowiednio klucz strumienia.

Po pomyślnym wyemitowaniu pierwszej transmisji strumieniowej (za pośrednictwem ssh lub ftp) sprawdź, czy transmisja na żywo została nagrana w /video_recordingsfolderze na Vultr VPS. Możesz także spróbować odtworzyć ten nagrany plik w VLC pod adresem URL:

rtmp://my-ip/vod/filename.flv

Dostępne są także statystyki Nginx (z Nginx stub_status). Aby wyświetlić statystyki odwiedzających / przeglądających, uzyskaj dostęp:

http://my-ip/stats

Aby oglądać wideo na stronie internetowej, potrzebujesz wbudowanego odtwarzacza. Istnieje wiele dostępnych odtwarzaczy, które będą odtwarzać wideo HLS. Używam JW Player od kilku lat, ale darmowa wersja nie będzie odtwarzać HLS. Flowplayer i Bitdash firmy Bitmovin (wśród innych rozwiązań) są na tyle hojne, że oferują niekomercyjną wersję swoich odtwarzaczy za darmo, która sprawi, że Twój strumień HLS zostanie osadzony na stronie internetowej. W tym artykule wypróbowałem je oba i stwierdziłem, że oba działają całkiem dobrze z moim serwerem wideo opartym na Vultr / Nginx. Pokrótce pokażę, w jaki sposób uruchomiłem Flowplayer na mojej maszynie testowej.

Jeśli zamierzasz korzystać z przesyłania strumieniowego HLS na żywo w jakikolwiek regularny, trwały lub komercyjny sposób, zachęcam do zakupu licencji od Flowplayer lub dowolnego odtwarzacza, którego zdecydujesz się użyć. Otrzymasz gracza, który ma mniej ograniczeń, więcej funkcji i może być oznaczony marką Twojej organizacji. Otrzymasz również wsparcie - co może być bardzo ważne. Oprócz Vultr VPS jest to naprawdę jedyny koszt związany z projektem.

Zanim zrobisz cokolwiek innego, ważne jest, aby zadbać o tak zwane ograniczenia „międzydomenowe”, które w przeciwnym razie uniemożliwiłyby Ci możliwość strumieniowego przesyłania na stronę internetową. Utwórz crossdomain.xmlplik w swoim nginx/htmlfolderze i umieść w nim instrukcje, aby umożliwić przepływ danych między domenami:

sudo nano /usr/local/nginx/html/crossdomain.xml

Najpierw skopiuj (z tej strony), a następnie wklej (kliknij prawym przyciskiem myszy) w polu edytora nano następujące dane XML:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>

Naciśnij Ctrl + O, aby zapisać, a następnie Ctrl + X, aby zapisać plik na dysku i wyjść.

Chwyciłem HTML5 (wersja 6.0.3) Flowplayer, który po rozpakowaniu dał mi wiele plików i folderów. Przesłałem wszystkie pliki i folder do podfolderu folderu głównego Nginx / HTML, który nazwałem „flowplayer”. Dokładna ścieżka była /usr/local/nginx/html/flowplayer.

Aby przetestować nasze wideo po umieszczeniu na stronie internetowej, utwórz kilka plików HTML w katalogu głównym folderu Nginx / HTML za pomocą nano i wypełnij je następującą zawartością.

Plik:

sudo nano /usr/local/nginx/html/hls.html

Kod HTML:

<!doctype html>
<head>
<link rel="stylesheet" href="#">
</head>

<body>
640x480 664kbps (live) Desktop Browsers<br>
<div style="width:640px;" class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src="">
</video>
</div>
<br><br>
480x360 464kbps (mobile) Mobile Browsers <br>
<div style="width:480px;" class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src="">
</video>
</div>
</body>

Plik:

sudo nano /usr/local/nginx/html/hls_progressive.html

Kod HTML:

<!doctype html>
<head>
<link rel="stylesheet" href="#">
<style> .flowplayer { width: 640px; } </style>
</head>

<body>
<div class="flowplayer" data-swf="flowplayer/flowplayer.swf" data-ratio="0.75">
<video>
<source type="application/x-mpegurl" src=""> 
<source type="application/x-mpegurl" src="">
</video>
</div>
<br>
</body>

Pamiętaj, aby zastąpić „my-ip” i „my-stream-key” swoimi danymi.

Musisz zastąpić ścieżkę flowplayer/skin/functional.cssznakiem „#” w arkuszu stylów href="#". Oprogramowanie samouczka obiera ścieżkę. Musisz wypełnić URL w src=""części - jest on pozbawiony przez samouczek oprogramowania, użytkowania http://my-ip/live/my-stream-key/index.m3u8i http://my-ip/mobile/my-stream-key/index.m3u8odpowiednio. Musisz także dodać srcznaczniki skryptu w nagłówku zarówno dla, jak jquery-1.11.2.min.jsi dla flowplayer.min.js. Tagi są usuwane przez oprogramowanie samouczka. Możesz dowiedzieć się, jak zrobić te tagi, patrząc na example htmlplik dołączony do zestawu Flowplayer.

Uruchom koder za pomocą kamery internetowej lub działającej na nim paszy testowej. Możesz wyświetlić swoją transmisję w przeglądarce, używając następujących adresów URL:

http://my-ip/hls.html
http://my-ip/hls_progressive.html

Pierwsza strona po prostu pokazuje każdy z twoich strumieni - główny i platformę mobilną. Będziesz mógł je uruchomić i przeglądać. Zauważysz, że strumień platformy mobilnej jest mniejszy. Te kroki mają na celu upewnienie się, że wszystko działa.

Druga strona pokazuje pojedynczy strumień. Ale jest skonfigurowany w sposób, który nazywa się „progresywnym streamingiem”. Oznacza to, że gdy przeglądający odtworzy wideo, zarówno serwer, jak i odtwarzacz starają się zapewnić widzowi strumień o wysokiej przepływności i wysokiej jakości, jeśli połączenie z widzem może go utrzymać. Jeśli ich połączenie jest słabe i nie może utrzymać połączenia, wyświetla się strumień o niższej przepływności (mobilny), który ma przepustowość o 200 kb / s. Jeśli chcesz, możesz stworzyć bardziej stopniowane, progresywne strumienie za pomocą ffmpeg i skonfigurować je na moim przykładzie.

Przetestowałem tę konfigurację na jednym rdzeniu, Vultr VPS o pojemności 1 GB i stwierdziłem, że z jednym strumieniem na żywo, a także z transmisyjnym strumieniem mobilnym, który tworzy z ffmpeg, użycie procesora było mniejsze niż 35% i zużyło tylko 100 MB mój 1 GB pamięci RAM. To bardzo wydajna konfiguracja.

Jeśli planujesz przesyłać strumieniowo wideo, które ma znacznie większe wymiary w pikselach niż SD, może się okazać, że musisz użyć mocniejszego VPS. Byłem ciekawy tego i uruchomiłem mój główny strumień do 1280 x 960 pikseli i 2 Mb / s - nakładając na to dodatkowe obciążenie. Ale VPS nadal zużywał tylko 50% procesora, a zużycie pamięci pozostało na 100 MB. Dodałem tuzin przeglądarek / przeglądarek i nie miało to prawie żadnego znaczenia w obciążeniu VPS - wzrosła tylko używana przepustowość. Jestem pewien, że tworzenie dodatkowych strumieni z oceną za pomocą ffmpeg nadal obciążałoby system.

Użyłem tego typu serwera w środowiskach produkcyjnych z 50 do 100 równoczesnymi użytkownikami i stwierdziłem, że użycie zasobów wzrosło bardzo niewiele wraz ze wzrostem liczby połączeń z przeglądarką. Eksperymentuj z tym. Sądzę jednak, że większość użytkowników byłaby zadowolona z jednordzeniowego VPS 1 GB. Ciesz się swoim nowym serwerem strumieniowym HLS!