przesyłanie strumieniowe hls. Kiedy używać protokołu HLS

Prowizja za usługi Telewizja IP za pośrednictwem Internetu i lokalnych sieci komputerowych staje się coraz bardziej rozpowszechnionymi formami. Na terytorium krajów WNP prawie nie ma dużych dostawców, którzy nie transmitują wideo multiemisja do ich sieci lokalnych, czyli świadczących usługę IPTV. Jednak świadczenie usług telewizyjnych poza siecią lokalną wiąże się z pewnymi kosztami sprzętowymi i złożonością zapewnienia wymaganej jakości transmisji.

Transmisja na żywo HTTP znany również jako HLS, to protokół komunikacyjny zaimplementowany przez firmę Apple. Jego cechą charakterystyczną jest to, że cały strumień jest podzielony na sekwencję małych plików do pobrania, przy czym każde pobieranie pobiera jeden mały fragment strumienia transportowego. Podczas odtwarzania strumienia klient może wybrać spośród kilku różnych alternatywnych strumieni zawierających ten sam materiał, nagranych z różnymi przepływnościami, co pozwala mu dostosować się do dostępnej przepływności. Na początku sesji przesyłania strumieniowego ładowana jest rozszerzona lista odtwarzania M3U (m3u8), zawierająca metadane dla różnych dostępnych strumieni podrzędnych. Ponieważ żądania wykorzystują tylko standardowe operacje HTTP, HTTP Live Streaming może ominąć każdą zaporę lub serwer proxy, który zezwala na standardowy ruch HTTP, w przeciwieństwie do protokołów UDP, takich jak RTP.

HLS jest oparty na protokole HTTP. HLS definiuje również standardowy mechanizm szyfrowania za pomocą AES oraz sposób dystrybucji klucza bezpieczeństwa za pomocą HTTPS lub plików cookie HTTP, które razem zapewniają prosty system ochrony praw autorskich.

Zasada działania HLS

Teraz dowiedzmy się, jakie są zalety i wady tej technologii. Korzyści są niezaprzeczalne i oczywiste. Jest to po pierwsze możliwość dostosowania szybkości transmisji danych do właściwości łącza i urządzenia odbiorczego, a po drugie wbudowane mechanizmy ochrony praw autorskich. Po trzecie, nie jest wymagany router o ograniczonej szerokości strumień multiemisji nad WI_FI, co pozwoliłoby uniknąć pochłaniania całej szerokości kanału przez strumienie multicast, w przypadku nadawania telewizji IP z wykorzystaniem multicast. Nie wymaga również dodatkowego urządzenia z tą funkcją Serwer proxy UDP do konwersji strumienia multiemisji na HTTP, co jest często wymagane w przypadku urządzeń mobilnych, chociaż wpływa na obciążenie sprzętowe routera lub innego urządzenia pełniącego funkcję proxy UDP w sieci lokalnej abonenta. Standard HLS stał się dość powszechny i ​​​​jest obsługiwany przez prawie wszystkie nowoczesne odtwarzacze wideo i dekodery dla IPTV.

Dekoder IPTV

Istotną wadą jest posiadanie przez abonentów dekoderów multimedialnych i smart-tv z przestarzałym oprogramowaniem lub przestarzałymi konstrukcjami, które nie obsługują standardów HLS lub nie obsługują ich poprawnie. Jednym z problemów jest również brak możliwości dobrania odpowiedniej jakości dla stabilnej transmisji w warunkach zmiany charakterystyk linii w odstępach czasu krótszych niż czas trwania żądanego fragmentu wideo.

Przetwarzając, przechowując i przesyłając wideo do swojego projektu online, zamiast korzystać z witryn takich jak YouTube, nieuchronnie dochodzi do pytania, jakiego protokołu transferu użyć do transmisji wideo na urządzenia użytkowników. Wybór jest niewielki, bo Istnieje wiele standardów branżowych, które obsługują określone urządzenia. Ponadto wybór protokołu w dużej mierze zależy od „klasy” wideo – transmisja na żywo lub wideo na żądanie. Wybór serwera multimediów, który będzie silnikiem Twojej maszyny medialnej, zależy również od wyboru protokołu: czy zainstalujesz kilka heterogenicznych serwerów, czy zbudujesz sieć dostaw w oparciu o jedno rozwiązanie? Dlatego musisz wszystko zważyć i podjąć decyzję na podstawie kryteriów swojej firmy.

Na ogół otrzymuje się równanie z wieloma niewiadomymi. Istotna jest tu dynamika procesu – dokąd ogólnie zmierza branża? A co jeśli zainwestuję w technologię wspierającą, a ona umrze za rok, bo to już się stało. A może postawię na modną technologię, ale nikt jej nie obsługuje?

Postanowiliśmy ocenić, jak zmieniał się udział różnych protokołów w czasie – spojrzeć na cały proces w dynamice. Dane zostały wzięte z ubiegłego roku.

Wstępne dane

Na początek, kim jesteśmy, aby oceniać udziały w rynku? Jesteśmy twórcami usługi internetowej raportowania dla serwerów multimedialnych. Działamy na rynku czwarty rok i zgłaszają się do nas firmy z różną infrastrukturą, różną liczbą serwerów i różnymi potrzebami. Okazuje się, że dobra obsada stanu branży.

Przygotowaliśmy mały raport, w którym możesz wybrać zakres dat i uzyskać dane z wykresem liczby wyświetleń wideo za pomocą różnych protokołów.

Raport zawiera dane dotyczące serwerów:

• Wowza Streaming Engine we wszystkich wersjach od 2.2 do najnowszej 4.x; najwięcej - 3.x.
• Nimble Streamer współpracujący z HLS, Smooth, HDS i progresywnym pobieraniem to nasz rozwój.
• Windows Media Services - jest ich dosłownie kilkadziesiąt, ale istnieją i musimy je wziąć pod uwagę

Raport jest również okresowo aktualizowany na naszym blogu, jest dostępny pod odpowiednim tagiem.

Iść

Raport za czerwiec/lipiec 2014 wygląda mniej więcej tak. Z 1,4 miliarda wyświetleń ponad połowa to HLS. Na drugim miejscu jest RTMP z jedną czwartą wyświetleń. RTSP to około jedna szósta. Reszta mieści się w obszarze błędu statystycznego.

Co wydarzyło się rok temu w tym samym okresie? Sytuacja jest niemal lustrzanym odbiciem. RTMP - prawie dwie trzecie, RTSP i HLS dzielą drugie i trzecie miejsce. To prawda, że ​​​​baza do pomiarów była prawie 3 razy mniejsza - „tylko” 500 milionów wyświetleń. Oczywiście w naszym serwisie było też mniej serwerów.

Przejdźmy między tymi dwoma punktami.

A więc czerwiec - sierpień 2014, 3 miesiące lata. 800 milionów wyświetleń, ale udziały te same, sierpień bez zmian.

Wrzesień - Listopad 2013. Rozpoczął się nowy sezon, HLS zaczął pochłaniać część RTMP. Całkowity 1,1 miliarda wyświetleń, RTMP ma około połowy całości, HLS ma jedną czwartą.

grudzień 2013 - luty 2014. 1,4 miliarda wyświetleń, z czego HLS stanowi ponad 40%. RTMP i RTMP zajmują drugie i trzecie miejsce z udziałem jednej czwartej. Olimpiada w Soczi dała wzrost oglądalności i jednocześnie wymusiła na dostawcach zapamiętanie wszystkich klientów ze wszystkimi ich egzotycznymi lub starymi urządzeniami, które rozumieją tylko RTSP - stąd skok w tym protokole.

Jak pokazała praktyka, najlepszym transportem wideo w porównaniu do RTMP jest HLS. Powody tego:

Bardzo proste proxy, z buforowaniem przez nginx. Po pierwsze dlatego, że kamera jako urządzenie nie może z reguły obsłużyć więcej niż 10 połączeń jednocześnie. W tym sensie gwarantowane proxy strumieni RTMP jest możliwe tylko za pomocą płatnych rozwiązań i wymaga dużej mocy. Nie jest wymagane żadne specjalne oprogramowanie serwera.

Uproszczenie całej infrastruktury serwerowej. Zgodnie z ideą wideo jest podawane w częściach, przez port 80 przez http. Sam Nginx może być odpowiedzialny za zwracanie statyki. Zwracanie statyki (fragmenty wideo o rozmiarze 50 kB) jest bardzo łatwym zadaniem dla nginx.

Ponieważ liczba elementów jest stała, stare są usuwane, nowe są dodawane, dysk twardy nigdy się nie przepełni.

Częstość występowania jest większa niż w przypadku RTMP. HLS z kodowaniem wideo H.264 jest obsługiwany przez system iOS i działa płynnie. Od 1 lipca 2014 r. strumieniowe połączenia wideo z transportem HLS wynoszą 55%, RTMP - 26%, RTSP - 15%, a MPEG-DASH mniej niż 1%.

Obsługa większości urządzeń mobilnych, komputerów stacjonarnych, tabletów bezpośrednio z przeglądarki.

Zasadniczo znacznie łatwiejsze niż nadawanie w RTSP. Ponieważ nie ma takich procedur jak push (publikowanie strumienia) lub pull (pobieranie strumienia).

Znacznie bardziej przyjazny dla http format.

Wady są następujące:

Mimo to nie wszystkie urządzenia obsługują ten format. Wersje Androida mniejsze niż 4.2 nie obsługują oficjalnie kodeka i transportu H.264, ale na Androidzie zamiast przeglądarki możesz użyć aplikacji innej firmy do przeglądania - na przykład MX Player

Wszystko zależy od aparatu. Jeśli kamera jest wadliwa, na przykład Dlink DCS-3010, wtedy cały system będzie działał bardzo źle (ffmpeg ciągle odpada). Na przykład kamery AXIS M1011-W, HIKVISION DS-2CD2412F-IW działają dobrze w takim pakiecie (do miesiąca bez żadnych reklamacji (po prostu nie testowałem tego dłużej)). Istotne jest również prowadzenie kabli. W tym sensie rozważymy idealną opcję.

Co to jest transport HLS

Strumień wideo zakodowany jest w h.264 (notabene: baseline profilu jest rozumiany przez urządzenia z systemem Android), podzielony na części z rozszerzeniem *.ts, np. po 5 sekund każdy, playlista tworzona jest w live.m3u8 , z sekwencyjnym opisem tych elementów. Długość playlisty jest z góry ustalona, ​​na przykład 10 sztuk. Gdy pojawi się jedenasty fragment filmu, pierwszy fragment zostanie usunięty, a lista odtwarzania zostanie utworzona ponownie. Więcej szczegółów można znaleźć na stronie dewelopera.

Aby system działał, ustawimy obraz z kamer tak, jak chcemy widzieć go na stronie, format obrazu i jakość obrazu. Nie będziemy rekodować na serwerze. Aparat został zaprojektowany tak, aby dawał obraz, którego potrzebujesz. Aparaty zwykle mają kilka profili. Możesz skonfigurować jeden profil dla H.264 dla HLS, a drugi dla MPEG4 dla MPEG-DASH. Możesz także ustawić inną jakość dla szerokiego i wąskiego kanału internetowego. Myśl samodzielnie - decyduj za siebie.

Ważny! Kamera powinna mieć obraz wyjściowy, który nie wymaga ponownego kodowania.

Schemat strukturalny dla dużego obciążenia

Kamera(rtsp) ----->

-----> jedno połączenie FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> jedno połączenie z pośrednim serwerem proxy nginx z dużą pamięcią podręczną =====>

=====> wielu klientów JWPlayer(hls).

Nasz serwer łączy się z kamerą za pomocą ffmpeg i rejestruje się w aplikacji nginx hls. nginx tworzy elementy i listę odtwarzania w określonym katalogu. Następnie wysyła te elementy do serwera proxy. Klienci łączą się z serwerem proxy za pomocą JWPlayer.

Konfiguracja aplikacji nginx

Zbudujmy nginx z modułem nginx-rtmp. Ta procedura została szczegółowo opisana w artykule.

Powiedzmy, że mamy kilka kamer, podzielimy je według numeru seryjnego. Opiszę konfigurację nginx dla 2 kamer. Obrazy statyczne buforujemy przez 5 minut w lokalnej pamięci podręcznej, jeśli obraz nie ładuje się w ciągu 5 sekund, wyświetlamy statyczny ekran powitalny.

# nano /etc/nginx/nginx.conf

Edytuj konfigurację nginx

dane www użytkownika; worker_processes auto ; pid/uruchom/nginx. pid; dziennik_błędów / var / log / nginx / nginx_ błąd . debugowanie dziennika; ŚCIEŻKA środowiska; zdarzenia ( # multi_accept on ; ) http ( log dostępu / var / log / nginx / dostęp. log; dziennik_błędów / var / log / nginx / error. log; zawierać mime. typy; typ domyślny aplikacji / octet-stream; plik wysyłania włączony; limit czasu keepalive 65 ; proxy_cache_path / var / www / cache / poziomy lokalne = 1: 2 keys_zone = nginx_local_cache: 1 m nieaktywne = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; serwer (list 80 ; # rtmp stat location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat. xsl ; ) location / stat. xsl ( # możesz przenieść stat. xsl do innej lokalizacji root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html ; lokalizacja = / 50 x .html ( główny html ; ) zawiera kamery_http_lokalizacje .conf ; ) ) rtmp ( dziennik_dostępu / var / log / nginx / rtmp_access. log ; serwer ( nasłuchuj 1935 ; ping 30 s ; metoda powiadamiania get ; uwzględnij camera_rtmp_applications . konf.; ))

Utwórz ścieżkę do pamięci podręcznej # mkdir /var/www/cache/local Napraw uprawnienia do pamięci podręcznej:

# chmod -R 755 /var/www/cache/local # chown -R www-data:www-data /var/www/cache/local`

Utwórzmy lokalizacje http dla kamer:

# nanokamery_http_locations.conf

typy ( aplikacja / vnd . apple . mpegurl m3u8 ; wideo / mp2t ts ; ) # daj obraz z kamery 1 - /1/img/ # są różne dla wszystkich aparatów, ponieważ adresy IP kamer są różne „http://192.168.0.2/GetImage.cgi?CH=1”# daj obraz z kamery 2 - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; wygasa 1 m ; # cache na 1 minutę add_header Cache - Control public ; # buforować na proxy proxy_ignore_headers Cache - Control ; # usuwać nagłówki z kamery proxy_pass „http://192.168.0.3/GetImage.cgi?CH=1”; proxy_set_header Autoryzacja "Podstawowa" ; error_page 502 504 404 @ fallback_img ; ) # podaj listę odtwarzania - /1/hls/live.m3u8 lub /3/hls/live.m3u8 # playlista jest przechowywana w pamięci podręcznej przez 10 sekund na serwerze proxy lokalizacja ~* / hls / . * \ . m3u8 $ ( przepisz "/(.*)/hls/(.*)$" / hls - 1 $ / 2 $ przerwa ; # przepisz żądanie / 1 / hls / do / hls - 1 / root / tmp / ; wygasa 10 s ;add_header Pamięć podręczna - Kontrola publiczna;) # daj kawałek wideo z kamer - /1/hls/live-12345678.ts lub /2/hls/live-12345678.ts # buforowanie na komputerze lokalnym nie jest wymagane # kawałek jest buforowany przez 3 minuty na serwerze proxy lokalizacja ~* / hls / . * \ . ts $ (przepisz "/(.*)/hls/(.*)$" / hls - 1 $ / 2 $ break ; root / tmp / ; wygasa 3 m ; add_header Cache - Control public ; ) # nazwana lokalizacja, jeśli nie ma obrazu lokalizacja @ fallback_img (przepisz (. +) / fallback. jpg przerwa; root / etc / nginx /;)

Stwórzmy plik konfiguracyjny hls dla serwera rtmp z aplikacjami dla naszych kamer:

# nano camera_rtmp_applications.conf

rozmiar_porcji 4000 ; aplikacja hls_1 (na żywo; synchronizacja 10 ms; exec_static ffmpeg - i rtsp: //Admin: [e-mail chroniony]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls włączony; ścieżka_hls / tmp / hls - 1 / ; # ścieżka do przechowywania kawałków na serwerze hls_fragment_naming znacznik czasu; # użyj znacznika czasu do nazwania fragmentów) application hls_2 (live on; sync 10 ms; exec_static ffmpeg -i rtsp: //Admin: [e-mail chroniony]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls włączony; ścieżka_hls / tmp / hls - 2 / ; znacznik czasu hls_fragment_naming; )

Zawartość katalogu /tmp/hls-1/

$ ls / tmp / hls - 1 / live - 10458360. ts live - 13292010. ts live - 16129440. ts live - 18963270. ts live - 10930050. ts live - 13767390. ts live - 16602660. ts live - 194350 50. ts na żywo - 11405250. ts na żywo - 14239260. ts na żywo - 17072820. ts na żywo . m3u8 na żywo - 11878560. ts na żywo - 14710860. ts na żywo - 17544960. ts na żywo - 12348630. ts na żywo - 15182550. ts na żywo - 18020160. ts na żywo - 12821760. ts na żywo - 15658740. ts na żywo - 184 92750.ts

Przykładowy plik live.m3u8

#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:35 #EXT-X-TARGETDURATION:5 #EXTINF:5,224, na żywo - 16602660. ts #EXTINF:5,246, na żywo - 17072820. ts #EXTINF :5,280, na żywo - 17544960. ts #EXTINF:5,251, na żywo - 18020160. ts #EXTINF:5,228, na żywo - 18492750. ts #EXTINF:5,242, na żywo - 18963270. ts

Rozwiązanie problemu ze spadającymi aparatami

Najbardziej słuszną decyzją jest zmiana buggy aparatu. Pomaga w 90% przypadków. Jeśli nie ma sposobu i musisz jakoś żyć, pomoże następujące rozwiązanie.

Rozwiązanie to składa się z dwóch - uzupełniających się:

Uruchom oddzielny proces nginx dla każdej kamery i wspólny proces zwracania statystyk. Oznacza to, że dla dwóch kamer napisz osobne konfiguracje z serwerami rtmp i jedną wspólną z http. Wtedy wadliwa kamera nie wpłynie na cały proces.

Jeśli strumień z kamery zostanie zakłócony w wyniku jej wadliwego działania (przegrzanie, słabe okablowanie, niewystarczające zasilanie przez PoE itp.), kamera odpadnie, proces potomny ffmpeg odrzuci pakiety, a nginx przestanie zapisywać fragmenty wideo . A kiedy proces ffmpeg zakończy się, nginx usunie wszystkie pliki z katalogu chunks. Obliczamy ten moment czyszczenia folderu przez crona i restartujemy niezbędny proces nginx.

Dla każdej kamery tworzony jest wykonywalny skrypt w /etc/init.d/, kopia nginx o nazwach camera_1 i 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

Edycja skryptu startowego nginx.

nano /etc/init. d/nginx

Zmień zmienną DAEMON_OPTS. Główny demon nginx będzie obsługiwał wszystkie statyczne. Uruchamia również i zatrzymuje demony odpowiedzialne za kamery. / init . d /camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; następnie /etc/init. d/camera_2 zatrzymaj fi

Dodaj do funkcji do_reload:

# przeładuj kamery, jeśli [ - f "/etc/init.d/camera_1" ]; następnie /etc/init. d / camera_1 przeładuj fi, jeśli [ - f "/etc/init.d/camera_2" ]; następnie /etc/init. d/camera_2 przeładuj fi

Edytujemy skrypt startowy nginx dla kamery 1 kamera_1 i dla kamery 2 kamera_2 według przykładu.

# nano /etc/init.d/camera_1

Zmiana zmiennych DAEMON_OPTS i DESC

DESC = "camera_1 dla CAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Edytujemy skrypt startowy nginx dla kamery 2 camera_2 według przykładu.

W /etc/nginx/nginx_0.conf z lokalizacjami http piszę magiczne linie:

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

Wskazują szukane słowo DIR-PROCESS-NAME, oddzielone spacją, katalog i nazwę procesu, który ma zostać zrestartowany.

Badanie:

# service nginx start # service camera_1 restart * Restart camera_1 dla CAMERA - 1 konfiguracja nginx # service camera_2 restart * Restart camera_2 dla CAMERA - 2 konfiguracja nginx

Skrypt, który przeładowuje kamery. Przechodzi przez foldery fragmentów, szukając miejsc, w których nie ma plików *.m3u8. Jeśli w folderze nie ma plików, szuka odpowiedniego demona zgodnie z konfiguracją demona głównego, według wiersza DIR-PROCESS-NAME . Ładuje ponownie.

# nano /script/cameras_reloader.sh

Porównanie HLS z MPEG-DASH

MPEG-DASH jest analogiem HLS stworzonym przez Google jako transport dla MPEG-4. Transport ten nie jest rozpowszechniony i praktycznie nie jest obsługiwany. Jego ideologia jest taka sama, podziel strumień na części, tylko więcej części, osobne części dla wideo, osobne dla audio. W module nginx-rtmp ten format jest skonfigurowany podobnie do HLS.

Spróbuj, skopiuj, działaj!

Jeśli artykuł był dla Ciebie przydatny, kliknij w reklamę. Dziękuję!

Flussonic Media Server obsługuje dystrybucję wideo za pośrednictwem protokołu HLS.

Wiele z dostępnych funkcji jest niestandardowych dla HLS, ale obsługujemy je dla Twojej wygody.

Obsługiwane kodeki: H264, H265, MPEG2 video, AAC, MP3, MPEG2 audio, AC-3.

Flussonic Media Server umożliwia odbiór telewizji na żywo, wideo na żądanie, wideo z archiwum (catchup i timeshift) przez HLS.

Łatwe odtwarzanie HLS

Jeśli masz prostą transmisję na żywo lub plik (jeden film, jeden dźwięk), adres URL do odtwarzania przez HLS jest bardzo prosty:

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

gdzie flussonic-ip to przykład adresu + portu Twojego Flussonic Media Server.

Flussonic Media Server akceptuje również playlistę.m3u8 na końcu adresu URL w celu zachowania wstecznej kompatybilności z innymi serwerami.

Kiedy zaczynasz pracować z treściami wielojęzycznymi lub wielobitowymi, sprawy stają się bardziej skomplikowane.

Wielojęzyczny HLS

Jeśli chcesz odtwarzać swój wielojęzyczny strumień na iPhonie, musisz użyć tego samego http://192.168.2.3:8080/NAZWASTRUMIENI/index.m3u8

Ale jeśli chcesz oglądać wielojęzyczny strumień za pomocą VLC lub dekodera, musisz dołączyć video.m3u8.

Adres URL odtwarzacza: http://flussonic-ip/STREAMNAME/video.m3u8

Wynika to z faktu, że zgodnie z wymaganiami Apple HLS dla każdego języka należy określić oddzielną listę odtwarzania z opcją tylko audio. MPEG-TS ma inny mechanizm: wszystkie ścieżki audio są umieszczone obok wideo, a odtwarzacz sam wybiera, co będzie odtwarzane. Aby film można było obejrzeć na iPhonie, musi on spełniać wytyczne Apple. Ale VLC i dekodery, z naruszeniem standardu HLS, oczekują starej wersji MPEG-TS przekonwertowanej na HLS. Dlatego musisz dołączyć plik video.m3u8 .

Dodanie „Tylko dźwięk” dla Apple

Apple wymaga, aby wszystkie Twoje strumienie miały opcję bez wideo, tylko audio.

Uważają, że jeśli użytkownik ogląda wideo przez 3G i znajdzie się w strefie niepewnego odbioru, to lepiej dla niego będzie mieć tylko dźwięk niż buforowanie.

Możesz włączyć tę opcję w Flussonic Media Server:

ort strumienia (url udp:// 239.0.0.1:1234; add_audio_only;)

Pamiętaj, że może to uniemożliwić odtworzenie twojego adresu index.m3u8 w VLC lub dekoderze. W takim przypadku użyj video.m3u8 .

Oddzielne bitrate dla dekoderów

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

Ta playlista nie jest multi-bitrate, zawiera adresy URL do segmentów, w których znajduje się pierwsza ścieżka wideo i wszystkie dostępne ścieżki audio.

Jeśli chcesz dostarczać wielojęzyczne, wielobitowe strumienie do dekoderów, które nie rozumieją wielojęzycznego standardu Apple, użyj video.m3u8:

http://flussonic-ip/NAZWASTRUMIENI/wideo. m3u8

Jest to lista odtwarzania o wielu przepływnościach, która zwraca listę list odtwarzania o różnych jakościach: wideo1.m3u8, wideo2.m3u8 itd.

Odtwarzanie przechwytywania DVR

Gdy Twój stream jest już nagrany na serwerze przez nasz DVR, możesz odtworzyć wideo przez HLS korzystając z czasu rozpoczęcia i zakończenia transmisji (np. z EPG).

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

Ta playlista będzie tzw. wariant, jeśli w strumieniu będzie więcej niż jedna ścieżka audio lub więcej niż jedna szybkość transmisji. Spowoduje to wyświetlenie segmentów zaczynających się od UTC 1362504585 (5 marca 2013 r., 17:29:45 GMT) i godzinę do przodu.

Mono URL da listę segmentów zawierających wszystkie ścieżki w mpeg-ts:

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

Bardziej szczegółowa lista odtwarzania videoN wyświetli listę segmentów ze ścieżką wideo N i wszystkimi ścieżkami audio:

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

oraz wariant listy odtwarzania wideo z listą list odtwarzania wideoN:

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

Przewiń listę odtwarzania

Jest specjalna playlista „przewiń do tyłu-N.m3u8” z dużym „przesuwanym” oknem, które pozwala przewijać i wstrzymywać strumienie HLS na długie godziny.

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

7200 - Długość listy odtwarzania HLS w sekundach. Oznacza to, że Twoi klienci mogą wstrzymać transmisję na 2 godziny lub przewinąć do początku meczu piłki nożnej bez dostępu do specjalnych linków do archiwum.