Flussonic Medienserver unterstützt die Videoverteilung über das HLS-Protokoll.

Viele von Verfügbare Optionen sind kein Standard für HLS, aber wir unterstützen sie für Ihre Bequemlichkeit.

Unterstützte Codecs: H264, H265, MPEG2-Video, AAC, MP3, MPEG2-Audio, AC-3.

Flussonic Media Server ermöglicht den Empfang von Live-TV, Video on Demand, Video aus dem Archiv (Catchup und Timeshift) über HLS.

Einfache HLS-Wiedergabe

Wenn Sie einen einfachen Live-Stream oder eine Datei haben (ein Video, ein Ton), dann ist die URL zum Abspielen über HLS sehr einfach:

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

wobei flussonic-ip ein Beispiel für die Adresse + Port Ihres Flussonic Media Servers ist.

Flussonic Media Server akzeptiert auch playlist.m3u8 am Ende der URL für die Abwärtskompatibilität mit anderen Servern.

Wenn Sie anfangen, mit mehrsprachigen oder mehrbitratigen Inhalten zu arbeiten, werden die Dinge komplizierter.

Mehrsprachiges HLS

Wenn Sie Ihren mehrsprachigen Stream auf dem iPhone abspielen möchten, müssen Sie denselben http://192.168.2.3:8080/STREAMNAME/index.m3u8 verwenden

Wenn Sie jedoch einen mehrsprachigen Stream mit VLC oder einer Set-Top-Box ansehen möchten, müssen Sie video.m3u8 einbinden.

URL für den Player: http://flussonic-ip/STREAMNAME/video.m3u8

Dies liegt daran, dass gemäß den Anforderungen von Apple HLS für jede einzelne Sprache eine eigene Playlist mit einer Nur-Audio-Option angegeben werden muss. MPEG-TS hat einen anderen Mechanismus: Alle Audiospuren werden neben dem Video platziert, und der Player wählt selbst aus, was abgespielt wird. Damit ein Video auf einem iPhone angezeigt werden kann, muss es den Richtlinien von Apple entsprechen. VLC und Set-Top-Boxen erwarten jedoch entgegen dem HLS-Standard, dass die alte Version von MPEG-TS in HLS konvertiert wird. Daher müssen Sie video.m3u8 einbinden.

„Nur Audio“ für Apple hinzugefügt

Apple verlangt, dass alle Ihre Streams eine Option ohne Video, nur Audio haben.

Sie glauben, dass der Benutzer, wenn er sich Videos über 3G ansieht, und sobald er sich in der Zone mit unsicherem Empfang befindet, nur einen besseren Ton als Pufferung hat.

Sie können diese Option in Flussonic Media Server aktivieren:

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

Beachten Sie, dass dies Ihre index.m3u8-Adresse in VLC oder Set-Top-Box unspielbar machen kann. Verwenden Sie in einem solchen Fall video.m3u8 .

Separate Bitraten für Set-Top-Boxen

Wenn Sie mehrsprachige Inhalte mit mehreren Bitraten haben und diese auf einer Set-Top-Box abspielen möchten, die HLS-Wiedergabelisten mit mehreren Bitraten nicht unterstützt, können Sie individuelle Wiedergabelisten mit einem Video und allen Audiospuren vom Flussonic Media Server anfordern, genau wie beim Mono-Option:

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

Diese Playlist ist nicht multibitratig, sie enthält die URL zu den Segmenten, in denen sich die erste Videospur und alle verfügbaren Audiospuren befinden.

Wenn Sie mehrsprachige Streams mit mehreren Bitraten an Set-Top-Boxen liefern möchten, die den mehrsprachigen Standard von Apple nicht verstehen, verwenden Sie video.m3u8:

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

Dies ist eine Wiedergabeliste mit mehreren Bitraten, die eine Liste mit Wiedergabelisten enthält unterschiedliche Qualitäten: video1.m3u8, video2.m3u8 usw.

DVR-Catchup-Wiedergabe

Wenn Ihr Stream bereits von unserem DVR auf dem Server aufgezeichnet wird, können Sie das Video mit der Start- und Endzeit der Übertragung (z. B. aus dem EPG) über HLS abspielen.

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

Diese Wiedergabeliste wird die sogenannte sein. Variante, wenn es mehr als einen im Stream geben wird Tonspur oder mehr als eine Bitrate. Es werden Segmente ab UTC 1362504585 (5. März 2013 17:29:45 GMT) und eine Stunde im Voraus aufgelistet.

Mono URL gibt eine Liste von Segmenten aus, die alle Tracks in MPEG-Ts enthalten:

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

Eine spezifischere VideoN-Wiedergabeliste gibt eine Liste von Segmenten mit N Videospuren und allen Audiospuren:

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

und eine Variante der Video-Playlist mit einer Liste von videoN-Playlists:

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

Wiedergabeliste zurückspulen

Es gibt eine spezielle Playlist "Zurückspulen-N.m3u8" mit einem großen "gleitenden" Fenster, mit dem Sie HLS-Streams für lange Stunden zurückspulen und anhalten können.

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

7200 - Länge der HLS-Wiedergabeliste in Sekunden. Das bedeutet, dass Ihre Kunden die Übertragung für 2 Stunden pausieren oder zum Beginn eines Fußballspiels zurückspulen können, ohne auf spezielle Archiv-Links zugreifen zu müssen.

Videos für sein Online-Projekt zu verarbeiten, zu speichern und zu übertragen, anstatt Seiten wie YouTube zu nutzen, stellt sich zwangsläufig die Frage, welches Übertragungsprotokoll er verwenden soll, um Videos auf die Geräte der Nutzer zu streamen. Die Auswahl ist klein, denn Es gibt eine Reihe von Industriestandards, die bestimmte Geräte unterstützen. Darüber hinaus hängt die Wahl des Protokolls weitgehend von der „Klasse“ des Videos ab – Live-Übertragung oder Video-on-Demand. Die Wahl eines Medienservers, der der Motor Ihrer Medienmaschine sein wird, hängt auch von der Wahl des Protokolls ab: Werden Sie mehrere heterogene Server installieren oder ein Bereitstellungsnetzwerk basierend auf einer Lösung aufbauen? Daher müssen Sie alles abwägen und eine Entscheidung basierend auf den Kriterien Ihres Unternehmens treffen.

Im Allgemeinen erhält man eine Gleichung mit vielen Unbekannten. Wichtig ist hier die Dynamik des Prozesses – wohin geht die Branche generell? Was ist, wenn ich in unterstützende Technologie investiere und sie in einem Jahr sterben wird, weil dies bereits geschehen ist? Oder setze ich auf eine trendige Technologie, die aber niemand unterstützt?

Wir haben uns entschieden, zu bewerten, wie sich der Anteil verschiedener Protokolle im Laufe der Zeit verändert hat – um den gesamten Prozess dynamisch zu betrachten. Die Daten stammen aus dem letzten Jahr.

Ausgangsdaten

Für den Anfang, wer sind wir, um Marktanteile zu beurteilen? Wir sind die Entwickler eines Melde-Webdienstes für Medienserver. Wir sind bereits das vierte Jahr am Markt tätig und Unternehmen kommen mit unterschiedlichen Infrastrukturen, unterschiedlicher Anzahl an Servern und unterschiedlichen Bedürfnissen zu uns. Es stellt sich eine gute Besetzung des Zustands der Branche heraus.

Wir haben einen kleinen Bericht erstellt, in dem Sie einen Datumsbereich auswählen und Daten mit einem Diagramm zur Anzahl der Videoaufrufe über verschiedene Protokolle abrufen können.

Der Bericht enthält Daten zu Servern:

• Wowza Streaming Engine in allen Versionen von 2.2 bis 4.x; die meisten - 3.x.
• Nimble Streamer, der mit HLS, Smooth, HDS und progressivem Download funktioniert, ist unsere Entwicklung.
• Windows Media Services - es gibt buchstäblich ein paar Dutzend davon, aber sie existieren, und wir müssen sie berücksichtigen

Zum Zeitpunkt des Schreibens dieses Artikels bedient der Dienst etwa 1000 Server aus 60 Ländern.

Der Bericht wird auch regelmäßig auf unserem Blog aktualisiert, er ist unter dem entsprechenden Tag verfügbar.

gehen

Der Bericht für Juni/Juli 2014 sieht in etwa so aus. Aus 1,4 Milliarden Aufrufe mehr als die Hälfte sind HLS. An zweiter Stelle steht RTMP mit einem Viertel der Views. RTSP liegt bei etwa einem Sechstel. Der Rest liegt im Bereich des statistischen Fehlers.

Was geschah vor einem Jahr für denselben Zeitraum? Die Situation ist fast ein Spiegelbild. RTMP – fast zwei Drittel, RTSP und HLS teilen sich die Plätze zwei und drei. Richtig, die Basis für Messungen war fast dreimal geringer - "nur" 500 Millionen Aufrufe. Es gab natürlich auch weniger Server in unserem Service.

Lassen Sie uns zwischen diesen beiden Punkten gehen.

Also, Juni - August 2014, 3 Monate Sommer. 800 Millionen Aufrufe, aber die Aktien sind die gleichen, August brachte keine Änderungen.

September - November 2013. Eine neue Saison hat begonnen, HLS hat begonnen, den Anteil von RTMP wegzufressen. Gesamt 1,1 Milliarden Aufrufe, RTMP hat etwa die Hälfte der Gesamtzahl, HLS ein Viertel.

Dezember 2013 - Februar 2014. 1,4 Milliarden Aufrufe, von denen HLS mehr als 40 % ausmacht. RTMP und RTMP liegen mit einem Viertelanteil auf den Plätzen zwei und drei. Die Olympischen Spiele in Sotschi sorgten für eine Steigerung der Aufrufzahlen und zwangen die Anbieter gleichzeitig dazu, sich all die Kunden mit all ihren exotischen oder alten Geräten zu merken, die nur RTSP verstehen – daher der Sprung in dieses Protokoll.

Wie die Praxis gezeigt hat, ist HLS der beste Transport für Video im Vergleich zu RTMP. Gründe dafür:

Sehr einfaches Proxying mit Caching durch nginx. Zum einen, weil die Kamera als Gerät in der Regel nicht mehr als 10 Anschlüsse gleichzeitig bedienen kann. In diesem Sinne ist ein garantiertes Proxying von RTMP-Streams nur über kostenpflichtige Lösungen möglich und erfordert viel Leistung. Keine spezielle Serversoftware erforderlich.

Vereinfachung der gesamten Serverinfrastruktur. Aufgrund der Idee wird das Video in Teilen über Port 80 über http bereitgestellt. Nginx selbst kann für die Rückgabe von Statiken verantwortlich sein. Das Zurückgeben von Statik (Videostücke von 50 kB) ist eine sehr einfache Aufgabe für nginx.

Da die Stückzahl konstant ist, werden alte entfernt, neue hinzugefügt, Festplatte wird niemals überlaufen.

Die Prävalenz ist größer als die von RTMP. HLS mit H.264-Videocodierung wird von iOS unterstützt und funktioniert nahtlos. Ab dem 1. Juli 2014 betragen Streaming-Videoverbindungen mit HLS-Transport 55 %, RTMP - 26 %, RTSP - 15 % und MPEG-DASH weniger als 1 %.

Mehrheitliche Unterstützung mobile Geräte, Desktops, Tablet-Computer direkt aus dem Browser.

Im Prinzip viel einfacher als das Senden in RTSP. Da gibt es keine Verfahren wie Push (Veröffentlichen eines Streams) oder Pull (Erhalten eines Streams).

Viel http-freundlicheres Format.

Die Nachteile sind folgende:

Allerdings unterstützen nicht alle Geräte dieses Format. Android-Versionen weniger als 4.2 unterstützt den H.264-Codec und -Transport nicht offiziell, aber auf Android können Sie anstelle eines Browsers verwenden Anwendung von Drittanbietern- zum Beispiel MX Player

Es hängt alles von der Kamera ab. Wenn die Kamera fehlerhaft ist, z. B. Dlink DCS-3010, funktioniert das gesamte System sehr schlecht (ffmpeg fällt ständig ab). Zum Beispiel funktionieren die Kameras AXIS M1011-W, HIKVISION DS-2CD2412F-IW in einem solchen Bündel gut (bis zu einem Monat ohne Beanstandungen (ich habe es nur nicht länger getestet)). Gleicher Weg sehr wichtig hat eine Kabelführung. In diesem Sinne werden wir die ideale Option in Betracht ziehen.

Was ist HLS-Transport

Videostream kodiert h.264 (Übrigens: Profilbaseline verstehen Android-Geräte), in Stücke mit der Erweiterung *.ts unterteilt wird, z. B. jeweils 5 Sekunden, wird eine Wiedergabeliste in live.m3u8 erstellt, mit einer sequentiellen Beschreibung dieser Stücke. Die Länge der Playlist ist vorgegeben, beispielsweise 10 Stück. Wenn das 11. Video erscheint, wird das 1. Video gelöscht und die Wiedergabeliste neu erstellt. Weitere Details finden Sie auf der Website des Entwicklers.

Damit das System funktioniert, richten wir das Bild von den Kameras so ein, wie wir es auf der Website sehen möchten, sowie das Bildformat und die Bildqualität. Wir werden nicht auf dem Server recodieren. Die Kamera ist so konzipiert, dass sie das Bild liefert, das Sie benötigen. Kameras haben in der Regel mehrere Profile. Sie können ein Profil für H.264, für HLS und das zweite mit MPEG4 für MPEG-DASH konfigurieren. Sie können auch unterschiedliche Qualitäten für einen breiten und einen schmalen Internetkanal einrichten. Selber denken – selber entscheiden.

Wichtig! Die Kamera sollte ein Ausgangsbild haben, das nicht neu codiert werden muss.

Strukturdiagramm für hohe Belastung

Kamera (rtsp) ----->

-----> eine Verbindung FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> eine Verbindung zu einem zwischengeschalteten Nginx-Proxy mit großem Cache =====>

=====> viele JWPlayer(hls)-Clients

Unser Server verbindet sich mit ffmpeg mit der Kamera und registriert sich bei der nginx hls-Anwendung. nginx erstellt die Stücke und die Wiedergabeliste in einem bestimmten Verzeichnis. Dann sendet er diese Teile an den Proxy-Server. Clients verbinden sich mit JWPlayer mit dem Proxy-Server.

Nginx-Anwendung einrichten

Lassen Sie uns nginx mit nginx-rtmp-module erstellen. Dieses Verfahren wird im Artikel ausführlich beschrieben.

Nehmen wir an, wir haben mehrere Kameras, wir werden sie nach Seriennummern aufteilen. Ich werde die nginx-Konfiguration für 2 Kameras beschreiben. Wir speichern statische Bilder für 5 Minuten im lokalen Cache. Wenn das Bild nicht innerhalb von 5 Sekunden geladen wird, geben wir einen statischen Begrüßungsbildschirm aus.

# nano /etc/nginx/nginx.conf

Bearbeiten Sie die nginx-Konfiguration

Benutzer www-Daten; worker_processes auto ; pid/run/nginx. PID ; error_log / var / log / nginx / nginx_error . Debuggen protokollieren ; env PFAD ; events ( # 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_Pfad / var / www / Cache / lokale Ebenen = 1 : 2 Schlüssel_Zone = nginx_local_cache : 1 m inaktiv = 30 m max_size = 512 M ; Proxy_Temp_Pfad / var / www / Cache / local / tmp ; Server ( listen 80 ; # rtmp stat location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # Sie können stat . xsl an einen anderen Ort verschieben root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html ;location = / 50 x .html ( root html ; ) include camera_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( listen 1935 ; ping 30 s ; Benachrichtigungsmethode erhalten ; schließen Sie camera_rtmp_applications ein. conf ; ) )

Cache-Pfad erstellen # mkdir /var/www/cache/local Cache-Berechtigungen korrigieren:

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

Lassen Sie uns HTTP-Standorte für Kameras erstellen:

# Nano-Kameras_http_locations.conf

Typen ( Anwendung / vnd . apple . mpegurl m3u8 ; video / mp2t ts ; ) # Bild von Kamera 1 geben - /1/img/ # sind für alle Kameras unterschiedlich, weil Kamera-IP-Adressen sind unterschiedlich "http://192.168.0.2/GetImage.cgi?CH=1"# Bild von Kamera 2 geben - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; läuft 1 m ab ; # Cache für 1 Minute add_header Cache - Control public ; # zum Zwischenspeichern auf dem Proxy proxy_ignore_headers Cache - Control ; # zum Entfernen von Headern von der Kamera proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Berechtigung "Basic" ; error_page 502 504 404 @ fallback_img ; ) # Geben Sie die Wiedergabeliste an - /1/hls/live.m3u8 oder /3/hls/live.m3u8 # Wiedergabeliste wird 10 Sekunden lang auf dem Proxy zwischengespeichert Standort ~* /hls / . * \ . m3u8 $ ( rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; # rewrite request / 1 / hls / to / hls - 1 / root / tmp / ; läuft ab am 10 s ; add_header Cache - Kontrolle öffentlich ; ) # Geben Sie ein Video von Kameras - /1/hls/live-12345678.ts oder /2/hls/live-12345678.ts # Caching aktiviert lokalen Computer nicht erforderlich # Das Stück wird für 3 Minuten auf dem Proxy zwischengespeichert Standort ~* /hls / . * \ . ts $ ( rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; läuft 3 m ab ; add_header Cache - Control public ; ) # benannter Ort, wenn kein Bild vorhanden ist location @ fallback_img ( rewrite (. + ) / fallback . jpg break ; root / etc / nginx / ; )

Lassen Sie uns eine hls-Konfigurationsdatei für den rtmp-Server mit Anwendungen für unsere Kameras erstellen:

# Nano-Kameras_rtmp_applications.conf

chunk_size 4000 ; Anwendung hls_1 ( live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //Administrator: [E-Mail geschützt]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls an ; hls_pfad / tmp / hls - 1 / ; # Pfad zum Speichern von Teilen auf dem Server hls_fragment_naming timestamp ; # Zeitstempel zum Benennen von Chunks verwenden ) Anwendung hls_2 ( live on ; sync 10 ms ; exec_static ffmpeg - i rtsp : //Administrator: [E-Mail geschützt]:554/live1.sdp -c copy -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls an ; hls_path / tmp / hls - 2 / ; hls_fragment_naming Zeitstempel ; )

Inhalt des Verzeichnisses /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 - 0.3 5 - 11405250. ts live - 14239260. ts live - 17072820. ts live . m3u8 live - 11878560. ts live - 14710860. ts live - 17544960. ts live - 12348630. ts live - 15182550. ts live - 18020160. ts live - 12821760. ts live - 15658740. 184 ts live - .ts

Beispiel einer live.m3u8-Datei

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

Lösung des Problems mit fallenden Kameras

Die meisten die richtige Entscheidung, ändern Sie die Buggy-Kamera. Es hilft zu 90% der Zeit. Wenn es keine Möglichkeit gibt und Sie irgendwie weiterleben müssen, hilft die folgende Lösung.

Diese Lösung besteht aus zwei - sich ergänzenden:

Führen Sie für jede Kamera einen separaten Nginx-Prozess aus und allgemeiner Ablauf bei der Rückkehr von Statik. Das heißt, schreiben Sie für zwei Kameras separate Konfigurationen mit rtmp-Servern und eine gemeinsame mit http. Dann hat die Buggy-Kamera keinen Einfluss auf den Gesamtprozess.

Wenn der Stream von der Kamera aufgrund eines Fehlers (Überhitzung, schlechte Verkabelung, unzureichende Stromversorgung über PoE usw.) unterbrochen wird, fällt die Kamera ab, der untergeordnete ffmpeg-Prozess lehnt Pakete ab und nginx hört auf, Videostücke zu schreiben . Und wenn der ffmpeg-Prozess beendet wird, entfernt nginx alle Dateien aus dem Chunks-Verzeichnis. Wir berechnen diesen Moment des Bereinigens des Ordners per Cron und starten den erforderlichen Nginx-Prozess neu.

Für jede Kamera wird ein ausführbares Skript in /etc/init.d/ erstellt, eine Kopie von nginx mit den Namen camera_1 und 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

Bearbeiten des nginx-Startskripts.

nano /etc/init. d/nginx

Ändern Sie die Variable DAEMON_OPTS. Der Haupt-Nginx-Daemon wird die gesamte Statik bedienen. Es startet und stoppt auch die für die Kameras verantwortlichen Daemons. /init . d /camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; dann /etc/init. d/camera_2 stopp fi

Fügen Sie der Funktion do_reload hinzu:

# Kameras neu laden if [ - f "/etc/init.d/camera_1" ]; dann /etc/init. d / camera_1 reload fi if [ - f "/etc/init.d/camera_2" ]; dann /etc/init. d/camera_2 neu laden fi

Wir bearbeiten das nginx-Startskript für Kamera 1 Kamera_1 und für Kamera 2 Kamera_2 gemäß dem Beispiel.

# nano /etc/init.d/camera_1

Ändern der Variablen DAEMON_OPTS und DESC

DESC = "Kamera_1 für KAMERA-1" DAEMON_OPTS = "-c /etc/nginx/nginx_1.conf"

Wir bearbeiten das nginx-Startskript für Kamera 2 camera_2 gemäß dem Beispiel.

In /etc/nginx/nginx_0.conf mit http-Standorten schreibe ich magische Zeilen:

# DIR-PROZESSNAME /tmp/hls-1/camera_1 # DIR-PROZESSNAME /tmp/hls-2/camera_2

Sie geben das Suchwort DIR-PROCESS-NAME, getrennt durch ein Leerzeichen, das Verzeichnis und den Namen des neu zu startenden Prozesses an.

Untersuchung:

# service nginx start # service camera_1 restart * Neustart von camera_1 for CAMERA - 1 configuration nginx # service camera_2 restart * Neustart von camera_2 for CAMERA - 2 configuration nginx

Skript, das die Kameras neu lädt. Es durchsucht die Chunk-Ordner und sucht nach Stellen, an denen keine *.m3u8-Dateien vorhanden sind. Wenn der Ordner keine Dateien enthält, sucht es nach dem entsprechenden Daemon gemäß der Konfiguration des Haupt-Daemons anhand der Zeile DIR-PROCESS-NAME . Lädt es neu.

# 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-*" Funktion find_process()( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) für hls_dir in $dir ; do find_result = $(find $hls_dir -name $mask -type f) if [ -z $find_result ] ; then process = $(find_process $hls_dir ) service $process restart fi done sleep 15s

Vergleich von HLS mit MPEG-DASH

MPEG-DASH ist ein Analogon von HLS, das von erstellt wurde Google, als Transportmittel für MPEG-4. Dieser Transport ist nicht weit verbreitet und wird praktisch nicht unterstützt. Seine Ideologie ist die gleiche, den Stream in Stücke zerlegen, nur mehr Stücke, separate Stücke für Video, separate Stücke für Audio. In nginx-rtmp-module wird dieses Format ähnlich wie HLS konfiguriert.

Probieren, kopieren, loslegen!

Wenn der Artikel für Sie nützlich war, klicken Sie bitte auf die Anzeige. Vielen Dank!

Die Erstellung technisch idealer Anwendungen ist in der Regel eine äußerst komplexe und zeitaufwändige Aufgabe. Gleichzeitig sind nützliche Informationen oft über mehrere Quellen verstreut. Dies gilt unter anderem für die Entwicklung von Videoanwendungen für iOS. Dieser Artikel enthält die wichtigsten und nützlichsten Informationen, mit denen Sie die gesamte Palette der HTTP-Live-Streaming-Funktionen qualitativ nutzen können, sowie eine Liste der primären Quellen. Diese Materialien sind für alle Leser nützlich, die daran interessiert sind, qualitativ hochwertige und benutzerfreundliche Videodienste zu erstellen.

Die Stärkung des Komforts und der Interaktivität von Videodiensten wird erreicht durch Schnellstart und Zurückspulen sowie das Fehlen von Pufferung. Um das beste Ergebnis zu erzielen, werden die folgenden Maßnahmen vorgeschlagen.

• Beginnend mit niedriger Videoqualität. Mindestens ein Chunk ist erforderlich, um ein Video zu starten. Je kleiner die Größe eines Chunks ist, desto schneller startet das Video. Das Reduzieren der Bitrate des Startstreams und das Reduzieren der Dauer des Chunks führt zu einem schnelleren Videostart. Wir empfehlen eine Chunk-Dauer von 4–8 Sekunden und eine anfängliche Bitrate von 200–300 Kbps. Um das Video abzuspielen, muss der Benutzer also maximal 300 kb herunterladen.
• Playlist-Optimierung. Playlists können einen erheblichen Teil des gesamten Datenstroms einnehmen, insbesondere bei kleinen Chunk-Größen und langen Inhalten (mehrere Stunden). In den meisten Fällen wird beim Übertragen von Wiedergabelisten auf einen Videoplayer empfohlen, sie zu archivieren.
• Keyframes. Es ist wünschenswert, mindestens einen IDR-Rahmen pro Segment zu haben, vorzugsweise ganz am Anfang des Segments. Darüber hinaus beim Übertragen von Videos zu Mobilfunknetze Es wird empfohlen, mindestens alle 3 Sekunden Keyframes zu erstellen.
• TS-Overhead. HTTP LS verwendet MPEG TS als Container, daher ist es sehr wichtig, den TS-Overhead zu minimieren (sollte selbst bei niedriger Videoqualität weniger als 10 % betragen). In diesem Fall lohnt es sich, reale Bitraten anhand von Traffic-Dumps zu messen und die verwendeten Packer (Segmentierer) zu optimieren.
• Der Parameter Zieldauer in der Playlist. Dieser Parameter wirkt sich auf die Startzeit aus, Apple empfiehlt jedoch, sie auf 10 Sekunden einzustellen, da niedrigere Werte die Wahrscheinlichkeit einer Pufferung erhöhen, insbesondere in Mobilfunknetzen mit hoher Latenz. Es wird auch nicht empfohlen, Segmente zu erstellen, die länger als 20 Sekunden sind.
• dynamische Bitrate. Der in iOS integrierte adaptive Streaming-Mechanismus funktioniert optimal bei genau festgelegten Bitraten in einer Varianten-Playlist (unter Berücksichtigung des Datenverkehrs der Playlist selbst). In diesem Fall müssen Sie für Streams mit sich ändernder Bitrate einen Wert näher am Maximum angeben. Andernfalls sind falsche Entscheidungen zum Ändern des aktuellen Videostreams möglich. Benachbarte Bitraten sollten sich in der Geschwindigkeit um das 1,5- bis 2-fache unterscheiden.
• Streamt "nur Audio". Der Audiocodec HE-AAC ist deutlich effizienter und wird von den meisten Geräten unterstützt. Es wird empfohlen, die Bereitstellung von reinen Audiokanälen mit MPEG Elementary Stream und nicht mit MPEG Transport Stream (ein viel geringerer Overhead) zu implementieren.

Bei der Entwicklung Ihres Videoplayers können Sie nützliche Informationen aus dem HTTP-Live-Streaming-Protokoll (accessLog) abrufen. Es enthält Daten darüber, wie die automatische Umschaltung stattgefunden hat, welche Bitraten verwendet wurden usw. Details zu den im Protokoll verfügbaren Informationen. Basierend auf diesen Daten können Sie Videoanalysedaten über Ihre Benutzer sammeln.

Zusätzliche Empfehlungen
Bei Online-Übertragungen ist eine Videopufferung auch aufgrund von Verzögerungen im CDN sowie in Fällen möglich, in denen die Aktualisierungszeit der Wiedergabeliste zu kurz ist und der Server keine Zeit hat, Segmente rechtzeitig zu generieren. Um den Rückspulmechanismus zu optimieren, wird empfohlen, nicht ganzzahlige (tatsächliche) Segmentdauerwerte zu verwenden, da sich sonst ein Fehler ansammeln kann.

Wenn Ihre Anwendung verwendet werden soll verschiedene Geräte, können Sie in der Liste unterschiedliche Videoqualitäten bei unterschiedlichen Bildschirmauflösungen angeben. Auf diese Weise können Sie auf einem iPad mit Retina-Display und auf einem relativ alten iPhone unterschiedliche Videos anzeigen.

Das HTTP-Live-Streaming-Protokoll bietet auch Failover-Mechanismen (zeigt redundante Videoquellen an). Diese Funktion kann nützlich sein, um die Zuverlässigkeit Ihrer Dienste zu verbessern.

Wissensquellen
Eine kurze Liste von Ressourcen zur Verwendung von HTTP-Live-Streaming in Videoanwendungen:
HTTP-Live-Streaming-Entwurf
Häufig gestellte Fragen zum HTTP-Live-Streaming
Best Practices für HLS

Schließlich ist es erwähnenswert, dass es für registrierte Mac/iOS/Safari-Entwickler kostenlos ist Technische Videos Sitzungen mit WWDC 2012, wo es auch viele gibt nützliche Informationen, insbesondere - zur Arbeit mit Video und zur Verwendung von HTTP-Live-Streaming.

Erbringung von Dienstleistungen IP-TVüber das Internet und lokal Computernetzwerke findet immer mehr Verbreitung. Auf dem Territorium der GUS-Staaten gibt es fast keine großen Anbieter, die kein Video übertragen Multicast an ihre lokalen Netzwerke, d. h. diejenigen, die den Dienst bereitstellen IPTV. Aber die Bereitstellung von TV-Diensten außerhalb seiner lokales Netzwerk mit einigen Hardwarekosten und der Komplexität der Bereitstellung der erforderlichen Sendequalität verbunden.

HTTP-Live-Streaming auch bekannt als HLS, ist ein implementiertes Kommunikationsprotokoll von Apple. Seine Besonderheit besteht darin, dass der Gesamtstrom in eine Folge kleiner Download-Dateien aufgeteilt wird, wobei jeder Download ein kleines Fragment des Transportstroms herunterlädt. Wenn ein Stream abgespielt wird, kann der Client aus mehreren verschiedenen alternativen Streams auswählen, die das gleiche Material enthalten, das mit unterschiedlichen Bitraten aufgezeichnet wurde, wodurch er sich an die verfügbare Bitrate anpassen kann. Zu Beginn einer Streaming-Sitzung wird eine erweiterte M3U-Wiedergabeliste (m3u8) geladen, die Metadaten für die verschiedenen verfügbaren Substreams enthält. Da Anfragen nur Standard-HTTP-Vorgänge verwenden, kann HTTP Live Streaming im Gegensatz zu UDP-Protokollen wie RTP jede Firewall oder jeden Proxy-Server umgehen, der Standard-HTTP-Datenverkehr zulässt.

HLS basiert auf HTTP. HLS definiert auch einen Standardverschlüsselungsmechanismus mit AES und eine Möglichkeit, einen Sicherheitsschlüssel mit HTTPS oder HTTP-Cookies zu verteilen, die zusammen bereitgestellt werden einfaches System urheberrechtlicher Schutz.

HLS-Arbeitsprinzip

Lassen Sie uns nun herausfinden, was die Vor- und Nachteile dieser Technologie sind. Die Vorteile sind unbestreitbar und offensichtlich. Das liegt zum einen an der Anpassbarkeit der Datenübertragungsrate an die Eigenschaften der Leitung und des Empfangsgeräts und zum anderen an den eingebauten Urheberschutzmechanismen. Drittens ist kein Router mit begrenzter Breite erforderlich Multicast-Streamüber WI_FI, was helfen würde, die Absorption der gesamten Kanalbreite durch Multicast-Ströme zu vermeiden, wenn IP-Fernsehen unter Verwendung von Multicast gesendet wird. Es wird auch kein zusätzliches Gerät mit der Funktion benötigt UDP-Proxy um einen Multicast-Stream in HTTP zu konvertieren, was häufig für mobile Geräte erforderlich ist, obwohl es die Hardwarelast auf dem Router oder einem anderen Gerät beeinflusst, das die UDP-Proxy-Funktion im lokalen Netzwerk des Teilnehmers ausführt. Der HLS-Standard ist weit verbreitet und wird von fast allen modernen Videoplayern und Set-Top-Boxen für IPTV unterstützt.

IPTV-Set-Top-Box

Ein wesentlicher Nachteil besteht darin, dass Abonnenten Multimedia-Set-Top-Boxen und Smart-TV-Set-Top-Boxen mit veralteter Firmware oder veraltetem Design haben, die HLS-Standards nicht oder nicht richtig unterstützen. Eines der Probleme ist auch die Unfähigkeit, die richtige Qualität für eine stabile Übertragung unter Bedingungen sich ändernder Leitungseigenschaften in Zeitintervallen auszuwählen, die kürzer sind als die Dauer des angeforderten Videofragments.