Flussonique Serveur multimédia prend en charge la distribution vidéo via le protocole HLS.

Un grand nombre de Options disponibles ne sont pas standard pour HLS, mais nous les prenons en charge pour votre commodité.

Codecs pris en charge : H264, H265, vidéo MPEG2, AAC, MP3, audio MPEG2, AC-3.

Flussonic Media Server vous permet de recevoir la TV en direct, la vidéo à la demande, la vidéo de l'archive (catchup et timeshift) via HLS.

Lecture HLS facile

Si vous avez un flux ou un fichier en direct simple (une vidéo, un son), alors l'URL à lire via HLS est très simple :

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

où flussonic-ip est un exemple d'adresse + port de votre Flussonic Media Server.

Flussonic Media Server accepte également playlist.m3u8 à la fin de l'URL pour une rétrocompatibilité avec d'autres serveurs.

Lorsque vous commencez à travailler avec du contenu multilingue ou multibitrate, les choses se compliquent.

HLS multilingue

Si vous souhaitez lire votre flux multilingue sur iPhone, vous devez utiliser le même http://192.168.2.3:8080/STREAMNAME/index.m3u8

Mais si vous souhaitez regarder un flux multilingue à l'aide de VLC ou d'un décodeur, vous devez inclure video.m3u8.

URL du lecteur : http://flussonic-ip/STREAMNAME/video.m3u8

Cela est dû au fait que, selon les exigences d'Apple HLS, une liste de lecture distincte avec une option audio uniquement doit être spécifiée pour chaque langue individuelle. MPEG-TS a un mécanisme différent : toutes les pistes audio sont placées à côté de la vidéo, et le joueur choisit lui-même ce qui sera lu. Pour qu'une vidéo puisse être visionnée sur un iPhone, elle doit respecter les directives d'Apple. Mais VLC et les décodeurs, en violation de la norme HLS, attendent l'ancienne version de MPEG-TS convertie en HLS. Par conséquent, vous devez inclure video.m3u8 .

Ajout de "Audio uniquement" pour Apple

Apple exige que tous vos flux aient une option sans vidéo, uniquement audio.

Ils estiment que si l'utilisateur regarde de la vidéo en 3G et qu'une fois dans la zone de réception incertaine, il vaudra mieux pour lui n'avoir que le son que le buffering.

Vous pouvez activer cette option dans Flussonic Media Server :

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

Sachez que cela peut rendre votre adresse index.m3u8 illisible dans VLC ou un décodeur. Dans ce cas, utilisez video.m3u8 .

Débits séparés pour les décodeurs

Lorsque vous avez un contenu multilingue multi-débit et que vous souhaitez le lire sur un décodeur qui ne prend pas en charge les listes de lecture HLS multi-débit, vous pouvez demander des listes de lecture individuelles avec une vidéo et toutes les pistes audio de Flussonic Media Server, tout comme avec le option mono :

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

Cette liste de lecture n'est pas multi-bitrate, elle contient l'URL des segments, dans lesquels la première piste vidéo et toutes les pistes audio disponibles.

Si vous souhaitez diffuser des flux multilingues à débits multiples vers des décodeurs qui ne comprennent pas la norme multilingue d'Apple, utilisez video.m3u8 :

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

Il s'agit d'une liste de lecture multi-bitrate qui donne une liste de listes de lecture avec différentes qualités: vidéo1.m3u8, vidéo2.m3u8 etc.

Lecture de rattrapage DVR

Lorsque votre flux est déjà enregistré sur le serveur par notre DVR, vous pouvez lire la vidéo via HLS en utilisant les heures de début et de fin de la transmission (par exemple, depuis EPG).

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

Cette liste de lecture sera la soi-disant. variante s'il y en aura plusieurs dans le flux bande sonore ou plus d'un bitrate. Il listera les segments à partir de UTC 1362504585 (2013 Mar 5 17:29:45 GMT) et une heure à l'avance.

Mono URL donnera une liste de segments contenant toutes les pistes en mpeg-ts :

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

Une liste de lecture vidéoN plus spécifique donnera une liste de segments avec N piste vidéo et toutes les pistes audio :

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

et une variante de playlist vidéo avec une liste de playlists videoN :

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

Rembobiner la liste de lecture

Il y a une liste de lecture spéciale "rembobiner-N.m3u8" avec une grande fenêtre "coulissante" qui vous permet de rembobiner et de mettre en pause les flux HLS pendant de longues heures.

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

7200 - Longueur de la liste de lecture HLS en secondes. Cela signifie que vos clients peuvent suspendre la diffusion pendant 2 heures ou revenir au début d'un match de football sans accéder à des liens d'archives spéciaux.

Traiter, stocker et transférer des vidéos pour son projet en ligne, plutôt que d'utiliser des sites comme YouTube, il se pose inévitablement la question du protocole de transfert à utiliser pour diffuser des vidéos sur les appareils des utilisateurs. Le choix est restreint, car Il existe un certain nombre de normes industrielles qui prennent en charge certains appareils. De plus, le choix du protocole dépend largement de la "classe" de vidéo - diffusion en direct ou vidéo à la demande. Le choix d'un serveur média, qui sera le moteur de votre machine média, dépend aussi du choix du protocole : allez-vous installer plusieurs serveurs hétérogènes ou construire un réseau de diffusion basé sur une seule solution ? Par conséquent, vous devez tout peser et prendre une décision en fonction des critères de votre entreprise.

En général, on obtient une équation à plusieurs inconnues. La dynamique du processus est importante ici - où va l'industrie en général ? Et si j'investis dans la technologie de support, et qu'elle mourra dans un an, car cela s'est déjà produit. Ou vais-je parier sur une technologie à la mode, mais que personne ne supporte ?

Nous avons décidé d'évaluer comment la part des différents protocoles a changé au fil du temps - pour examiner l'ensemble du processus dans la dynamique. Les données ont été prises de l'année dernière.

Donnée initiale

Pour commencer, qui sommes-nous pour juger des parts de marché ? Nous sommes les développeurs d'un service Web de création de rapports pour les serveurs de médias. Nous travaillons sur le marché depuis la quatrième année et les entreprises viennent à nous avec différentes infrastructures, différents nombres de serveurs et différents besoins. Il s'avère un bon casting de l'état de l'industrie.

Nous avons créé un petit rapport dans lequel vous pouvez sélectionner une plage de dates et obtenir des données avec un graphique sur le nombre de vues vidéo via différents protocoles.

Le rapport fournit des données sur les serveurs :

• Wowza Streaming Engine dans toutes les versions de 2.2 à la dernière 4.x ; la plupart - 3.x.
• Nimble Streamer qui fonctionne avec HLS, Smooth, HDS et le téléchargement progressif est notre développement.
• Services Windows Media - il y en a littéralement quelques dizaines, mais ils existent et nous devons les prendre en compte

Au moment d'écrire ces lignes, le service dessert environ 1000 serveurs de 60 pays.

Le rapport est également mis à jour périodiquement sur notre blog, il est disponible sous la balise correspondante.

Aller

Le rapport de juin/juillet 2014 ressemble à ceci. De 1,4 milliard de vues plus de la moitié sont HLS. En deuxième position se trouve RTMP avec un quart des vues. RTSP est d'environ un sixième. Les autres sont dans la région de l'erreur statistique.

Que s'est-il passé il y a un an pour la même période ? La situation est presque une image miroir. RTMP - près des deux tiers, RTSP et HLS se partagent les deuxième et troisième places. Certes, la base de mesure était presque 3 fois inférieure - "seulement" 500 millions de vues. Il y avait aussi moins de serveurs dans notre service, bien sûr.

Allons entre ces deux points.

Donc, juin - août 2014, 3 mois d'été. 800 millions de vues, mais les actions sont les mêmes, août n'a apporté aucun changement.

Septembre - novembre 2013. Une nouvelle saison a commencé, HLS a commencé à grignoter la part de RTMP. Total 1,1 milliard de vues, RTMP a environ la moitié du total, HLS a un quart.

Décembre 2013 - Février 2014. 1,4 milliard de vues, dont HLS représente plus de 40 %. RTMP et RTMP sont à égalité pour les deuxième et troisième avec un quart de part. Les Jeux olympiques de Sotchi ont augmenté le nombre de vues et ont en même temps obligé les fournisseurs à se souvenir de tous les clients avec tous leurs appareils exotiques ou anciens qui ne comprennent que RTSP - d'où le saut dans ce protocole.

Comme l'a montré la pratique, le meilleur transport pour la vidéo par rapport à RTMP est HLS. Raisons à cela :

Proxy très simple, avec mise en cache via nginx. En premier lieu, parce que la caméra, en tant qu'appareil, ne peut pas desservir, en règle générale, plus de 10 connexions en même temps. En ce sens, le proxying garanti des flux RTMP n'est possible qu'au travers de solutions payantes, et demande beaucoup de puissance. Aucun logiciel serveur spécial n'est nécessaire.

Simplification de l'ensemble de l'infrastructure serveur. En vertu de l'idée, la vidéo est donnée en morceaux, via le port 80 via http. Nginx lui-même peut être responsable du retour des statiques. Le retour de statiques (morceaux vidéo de 50 Ko) est une tâche très simple pour nginx.

Comme le nombre de pièces est constant, les anciennes sont supprimées, de nouvelles sont ajoutées, Disque dur ne débordera jamais.

La prévalence est supérieure à celle du RTMP. HLS avec encodage vidéo H.264 est pris en charge par iOS et fonctionne de manière transparente. Depuis le 1er juillet 2014, les connexions vidéo en streaming avec transport HLS sont de 55 %, RTMP - 26 %, RTSP - 15 % et MPEG-DASH moins de 1 %.

Soutien majoritaire appareils mobiles, ordinateurs de bureau, ordinateurs tablettes directement depuis le navigateur.

Beaucoup plus facile que la diffusion en RTSP en principe. Puisqu'il n'y a pas de procédures telles que push (publier un flux) ou pull (obtenir un flux).

Format http beaucoup plus convivial.

Les inconvénients sont les suivants :

Tout de même, tous les appareils ne supportent pas ce format. Versions Android moins de 4.2 ne prend pas officiellement en charge le codec et le transport H.264, mais sur Android, au lieu d'un navigateur, vous pouvez utiliser application tierce- par exemple MX Player

Tout dépend de la caméra. Si la caméra est boguée, par exemple Dlink DCS-3010, alors tout le système fonctionnera très mal (ffmpeg tombe constamment). Par exemple, les caméras AXIS M1011-W, HIKVISION DS-2CD2412F-IW fonctionnent bien dans un tel bundle (jusqu'à un mois sans aucune plainte (je ne l'ai juste pas testé plus longtemps)). De la même façon grande importance dispose d'un acheminement des câbles. En ce sens, nous considérerons l'option idéale.

Qu'est-ce que le transport HLS

Flux vidéo encodé h.264 (Au fait : ligne de base du profil comprendre Appareils Android), est divisé en morceaux avec l'extension *.ts, par exemple, 5 secondes chacun, une playlist est créée dans live.m3u8 , avec une description séquentielle de ces morceaux. La longueur de la liste de lecture est prédéterminée, par exemple 10 morceaux. Lorsque le 11e morceau de vidéo apparaît, le 1er morceau de vidéo est supprimé, la liste de lecture est recréée. Plus de détails peuvent être trouvés sur le site Web du développeur.

Pour que le système fonctionne, nous allons configurer l'image des caméras comme nous voulons la voir sur le site, le format d'image et la qualité d'image. Nous ne recoderons pas sur le serveur. L'appareil photo est conçu pour donner l'image dont vous avez besoin. Les caméras ont généralement plusieurs profils. Vous pouvez configurer un profil pour H.264, pour HLS, et le second avec MPEG4 pour MPEG-DASH. Vous pouvez également configurer une qualité différente pour un canal Internet large et étroit. Pensez par vous-même - décidez par vous-même.

Important! La caméra doit avoir une image de sortie qui n'a pas besoin d'être réencodée.

Schéma structurel pour charge élevée

Caméra (rtsp) ----->

-----> une connexion FFmpeg(rtsp->hls) -> Nginx(nginx-rtmp-module) ----->

-----> une connexion à un proxy nginx intermédiaire avec un grand cache =====>

=====> de nombreux clients JWPlayer(hls)

Notre serveur se connecte avec ffmpeg à la caméra et s'enregistre avec l'application nginx hls. nginx crée les morceaux et la playlist dans un répertoire spécifique. Ensuite, il envoie ces pièces au serveur proxy. Les clients se connectent au serveur proxy à l'aide de JWPlayer .

Configuration de l'application nginx

Construisons nginx avec nginx-rtmp-module. Cette procédure est décrite en détail dans l'article.

Disons que nous avons plusieurs caméras, nous les diviserons par numéro de série. Je vais décrire la configuration nginx pour 2 caméras. Nous mettons en cache les images statiques pendant 5 minutes dans le cache local, si l'image ne se charge pas dans les 5 secondes, nous donnons un écran de démarrage statique.

# nano /etc/nginx/nginx.conf

Modifier la configuration nginx

données www de l'utilisateur ; processus_travailleur automatique ; pid/exécuter/nginx. pid ; error_log / var / log / nginx / nginx_error . journal de débogage ; env CHEMIN ; 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_path / var / www / cache / niveaux locaux = 1 : 2 keys_zone = nginx_local_cache : 1 m inactif = 30 m max_size = 512 M ; proxy_temp_path / var / www / cache / local / tmp ; serveur ( écoute 80 ; # stat rtmp location / stat ( rtmp_stat all ; rtmp_stat_stylesheet stat . xsl ; ) location / stat . xsl ( # vous pouvez déplacer stat . xsl vers un autre emplacement root / etc / nginx ; ) location / ( rtmp_control all ; ) error_page 500 502 503 504 / 50 x .html ; location = / 50 x .html ( root html ; ) include cameras_http_locations .conf ; ) ) rtmp ( access_log / var / log / nginx / rtmp_access . log ; server ( listen 1935 ; ping 30 s ; notify_method obtenir ; inclure caméras_rtmp_applications . conf ; ) )

Créez un chemin de cache # mkdir /var/www/cache/local Corrigez les autorisations de cache :

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

Créons des emplacements http pour les caméras :

# nano caméras_http_locations.conf

types ( application / vnd . pomme . mpegurl m3u8 ; vidéo / mp2t ts ; ) # donne l'image de la caméra 1 - /1/img/ # sont différents pour toutes les caméras, car les adresses IP des caméras sont différentes "http://192.168.0.2/GetImage.cgi?CH=1"# donne l'image de la caméra 2 - /2/img/ location / 1 / img / ( proxy_cache nginx_local_cache ; proxy_cache_key $ request_uri ; expire 1 m ; # cache pendant 1 minute add_header Cache - Control public ; # pour mettre en cache sur le proxy proxy_ignore_headers Cache - Control ; # pour supprimer les en-têtes de la caméra proxy_pass "http://192.168.0.3/GetImage.cgi?CH=1"; proxy_set_header Autorisation "Basique" ; erreur_page 502 504 404 @ fallback_img ; ) # donner la playlist - /1/hls/live.m3u8 ou /3/hls/live.m3u8 # liste de lecture est mise en cache pendant 10 secondes sur le proxy emplacement ~* / hls / . * \ . m3u8 $ ( rewrite "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; # rewrite request / 1 / hls / to / hls - 1 / root / tmp / ; expire 10 s ; add_header Cache - Contrôle public ; ) # donner un morceau de vidéo à partir de caméras - /1/hls/live-12345678.ts ou /2/hls/live-12345678.ts # mise en cache ordinateur local non requis # la pièce est mise en cache pendant 3 minutes sur le proxy emplacement ~* / hls / . * \ . ts $ ( réécrire "/(.*)/hls/(.*)$" / hls - $ 1 / $ 2 break ; root / tmp / ; expire 3 m ; add_header Cache - Control public ; ) # emplacement nommé s'il n'y a pas d'image location @ fallback_img ( rewrite (. + ) / fallback . jpg break ; root / etc / nginx / ; )

Créons un fichier de configuration hls pour le serveur rtmp avec des applications pour nos caméras :

# nano caméras_rtmp_applications.conf

taille_morceau 4000 ; application hls_1 ( en direct ; synchronisation 10 ms ; exec_static ffmpeg - i rtsp : //administrateur : [courriel protégé]:554/live1.sdp -c copie -f flv -an rtmp://localhost:1935/hls_1/live 2>>/var/log/nginx/ffmpeg_1.log; hls sur ; hls_path / tmp / hls - 1 / ; # chemin de stockage des morceaux sur le serveur hls_fragment_naming timestamp ; # utiliser l'horodatage pour nommer les morceaux ) application hls_2 ( en direct ; synchronisation 10 ms ; exec_static ffmpeg - i rtsp : //administrateur : [courriel protégé]:554/live1.sdp -c copie -f flv -an rtmp://localhost:1935/hls_2/live 2>>/var/log/nginx/ffmpeg_2.log; hls sur ; hls_path / tmp / hls - 2 / ; horodatage hls_fragment_naming ; )

Contenu du répertoire /tmp/hls-1/

$ ls / tmp / hls - 1 / en direct - 10458360. ts en direct - 13292010. ts en direct - 16129440. ts en direct - 18963270. ts en direct - 10930050. ts en direct - 13767390. ts en direct - 16602660. ts en direct - 19435050. ts en direct - 11405250. ts en direct - 14239260. ts en direct - 17072820. ts en direct . m3u8 en direct - 11878560. ts en direct - 14710860. ts en direct - 17544960. ts en direct - 12348630. ts en direct - 15182550. ts en direct - 18020160. ts en direct - 12821760. ts en direct - 15658740. ts en direct - 184 ts2750

Exemple de fichier live.m3u8

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

Résoudre le problème des caméras qui tombent

Plus la bonne décision, changez la caméra buggy. Cela aide 90% du temps. S'il n'y a aucun moyen et que vous devez vivre d'une manière ou d'une autre, la solution suivante vous aidera.

Cette solution se compose de deux - complémentaires :

Exécutez un processus nginx distinct pour chaque caméra et processus général au retour de l'électricité statique. Autrement dit, pour deux caméras, écrivez des configurations distinctes avec des serveurs rtmp et une commune avec http. Ensuite, la caméra buggy n'affectera pas le processus global.

Si le flux de la caméra est interrompu à cause de son bogue (surchauffe, mauvais câblage, alimentation insuffisante sur PoE, etc.), alors la caméra tombera, le processus enfant ffmpeg rejettera les paquets et nginx arrêtera d'écrire des morceaux vidéo . Et lorsque le processus ffmpeg se termine, nginx supprime tous les fichiers du répertoire chunks. Nous calculons ce moment de nettoyage du dossier par cron et redémarrons le processus nginx nécessaire.

Dans pour chaque caméra, un script exécutable est créé dans /etc/init.d/, une copie de nginx , nommée camera_1 et 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

Modification du script de démarrage nginx.

nano/etc/init. d/nginx

Modifiez la variable DAEMON_OPTS. Le démon nginx principal servira tous les fichiers statiques. Il démarrera et arrêtera également les démons responsables des caméras. /init . d /camera_1 stop fi if [ - f "/etc/init.d/camera_2" ]; puis /etc/init. d/camera_2 stop fi

Ajoutez à la fonction do_reload :

# recharger les caméras if [ - f "/etc/init.d/camera_1" ] ; puis /etc/init. d / camera_1 recharge fi if [ - f "/etc/init.d/camera_2" ]; puis /etc/init. d/camera_2 recharger fi

Nous éditons le script de démarrage nginx pour la caméra 1 camera_1 et pour la caméra 2 camera_2 selon l'exemple.

# nano /etc/init.d/camera_1

Modification des variables DAEMON_OPTS et DESC

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

Nous éditons le script de démarrage nginx pour la caméra 2 camera_2 selon l'exemple.

Dans /etc/nginx/nginx_0.conf avec des emplacements http, j'écris des lignes magiques :

# DIR-NOM-PROCESSUS /tmp/hls-1/camera_1 # DIR-NOM-PROCESSUS /tmp/hls-2/camera_2

Ils indiquent le mot de recherche DIR-PROCESS-NAME, séparé par un espace, le répertoire et le nom du processus à relancer.

Examen:

# service nginx start # service camera_1 restart * Redémarrage de camera_1 pour CAMERA - 1 configuration nginx # service camera_2 restart * Redémarrage de camera_2 pour CAMERA - 2 configuration nginx

Script qui recharge les caméras. Il parcourt les dossiers de blocs, à la recherche de l'endroit où il n'y a pas de fichiers *.m3u8. S'il n'y a pas de fichiers dans le dossier, il recherche le démon correspondant selon la configuration du démon principal, par la ligne DIR-PROCESS-NAME . Le recharge.

# 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-*" fonction find_process())( process_str = $(cat /etc/nginx/nginx_0.conf | grep "# DIR-PROCESS-NAME" | grep $1 | cut -d" " -f4) echo $process_str ) pour hls_dir dans $dir ; faire 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

Comparaison entre HLS et MPEG-DASH

MPEG-DASH est un analogue de HLS créé par Google, en tant que transport pour MPEG-4. Ce transport est peu répandu et n'est pratiquement pas pris en charge. Son idéologie est la même, diviser le flux en morceaux, seulement plus de morceaux, des morceaux séparés pour la vidéo, des morceaux séparés pour l'audio. Dans nginx-rtmp-module, ce format est configuré de la même manière que HLS.

Essayez, copiez, lancez-vous !

Si l'article vous a été utile, veuillez cliquer sur l'annonce. Merci!

La création d'applications techniquement idéales est généralement une tâche extrêmement complexe et chronophage. Dans le même temps, les informations utiles sont souvent dispersées sur plusieurs sources. Cela s'applique, entre autres, au développement d'applications vidéo pour iOS. Cet article contient les informations les plus importantes et les plus utiles qui vous permettent d'utiliser qualitativement la gamme complète des fonctionnalités HTTP Live Streaming, ainsi qu'une liste de sources principales. Ces documents seront utiles à tous les lecteurs intéressés par la création de services vidéo de haute qualité et conviviaux.

Le renforcement de la commodité et de l'interactivité des services vidéo passe par Démarrage rapide et rembobiner, ainsi que le manque de mémoire tampon. Pour obtenir le meilleur résultat, l'ensemble d'actions suivant est suggéré.

• À commencer par une faible qualité vidéo. Au moins un morceau est nécessaire pour démarrer une vidéo. En conséquence, plus la taille d'un morceau est petite, plus la vidéo démarrera rapidement. La réduction du débit binaire du flux de démarrage et la réduction de la durée du bloc entraînent un démarrage vidéo plus rapide. Nous recommandons une durée de bloc de 4 à 8 secondes et un débit binaire de départ de 200 à 300 Kbps. Ainsi, pour commencer à lire la vidéo, l'utilisateur devra télécharger un maximum de 300 ko.
• Optimisation de la liste de lecture. Les listes de lecture peuvent occuper une part importante du flux de données global, en particulier avec de petites tailles de blocs et un contenu long (plusieurs heures). Dans la plupart des cas, lors du transfert de listes de lecture vers un lecteur vidéo, il est recommandé de les archiver.
• images clés. Il est souhaitable d'avoir au moins une trame IDR par segment, de préférence au tout début du segment. De plus, lors du transfert de vidéo vers réseaux cellulaires il est recommandé d'effectuer une image clé au moins une fois toutes les 3 secondes.
• Frais généraux TS. HTTP LS utilise MPEG TS comme conteneur, il est donc très important de minimiser la surcharge TS (doit être inférieure à 10 % même avec une faible qualité vidéo). Dans ce cas, il convient de mesurer les débits réels à l'aide de vidages de trafic et d'optimiser les packers (segmenteurs) utilisés.
• Le paramètre Durée cible dans la liste de lecture. Ce paramètre affecte le temps de démarrage, mais Apple recommande de le régler sur 10 secondes car des valeurs inférieures augmentent les chances de mise en mémoire tampon, en particulier sur les réseaux cellulaires à latence élevée. Il est également déconseillé de créer des segments de plus de 20 secondes.
• débit binaire dynamique. Le mécanisme de streaming adaptatif intégré à iOS fonctionne de manière optimale à des débits spécifiés avec précision dans une liste de lecture variante (en tenant compte du trafic de la liste de lecture elle-même). Dans ce cas, pour les flux dont le débit binaire change, vous devez spécifier une valeur plus proche du maximum. Sinon, des décisions incorrectes concernant la modification du flux vidéo actuel sont possibles. Les débits binaires voisins doivent différer en vitesse de 1,5 à 2 fois.
• Diffuse "audio uniquement". Le codec audio HE-AAC est nettement plus efficace et est pris en charge par la plupart des appareils. Il est recommandé de mettre en œuvre la livraison de canaux audio uniquement à l'aide du flux élémentaire MPEG, et non du flux de transport MPEG (un temps système beaucoup plus faible).

Au fur et à mesure que vous développez votre lecteur vidéo, vous pouvez obtenir des informations utiles à partir du journal HTTP Live Streaming (accessLog). Il contient des données sur la façon dont la commutation automatique a eu lieu, les débits binaires utilisés, etc. Détails des informations disponibles dans le journal. Sur la base de ces données, vous pourrez collecter des données d'analyse vidéo sur vos utilisateurs.

Recommandations supplémentaires
Dans le cas des diffusions en ligne, la mise en mémoire tampon des vidéos est également possible en raison de retards dans le CDN, ainsi que dans les cas où le temps de mise à jour de la liste de lecture est trop court et que le serveur n'a pas le temps de générer des segments à temps. Pour optimiser le mécanisme de rembobinage, il est recommandé d'utiliser des valeurs de durée de segment non entières (réelles), sinon une erreur peut s'accumuler.

Si votre application est destinée à être utilisée sur différents appareils, vous pouvez spécifier différentes qualités vidéo à différentes résolutions d'écran dans la liste. De cette façon, vous pourrez afficher différentes vidéos sur un iPad avec un écran Retina et sur un iPhone relativement ancien.

Le protocole HTTP Live Streaming fournit également des mécanismes de basculement (indiquant des sources vidéo redondantes). Cette fonctionnalité peut être utile pour améliorer la fiabilité de vos services.

Sources de connaissances
Une courte liste de ressources sur l'utilisation de HTTP Live Streaming dans les applications vidéo :
Brouillon de diffusion HTTP en direct
Questions fréquemment posées sur la diffusion en direct HTTP
Meilleures pratiques pour HLS

Enfin, il convient de noter que pour les développeurs Mac/iOS/Safari enregistrés, la gratuité vidéos techniques sessions avec WWDC 2012, où il y a aussi beaucoup informations utiles, en particulier - sur le travail avec la vidéo et l'utilisation de HTTP Live Streaming.

Fourniture de services Télévision sur IP via Internet et local réseaux informatiques se généralise de plus en plus. Sur le territoire des pays de la CEI, il n'y a presque pas de grands fournisseurs qui ne diffusent pas de vidéo via multidiffusionà leurs réseaux locaux, c'est-à-dire ceux qui fournissent le service IPTV. Mais la fourniture d'un service de télévision en dehors de son réseau local associés à certains coûts de matériel et à la complexité de fournir la qualité de diffusion requise.

Diffusion HTTP en direct aussi connu sous le nom HLS, est un protocole de communication implémenté par Apple. Sa particularité est que le flux global est divisé en une séquence de petits fichiers de téléchargement, chaque téléchargement télécharge un petit fragment du flux de transport. Lorsqu'un flux est lu, le client peut choisir parmi plusieurs flux alternatifs différents contenant le même matériel, enregistré à différents débits binaires, ce qui lui permet de s'adapter au débit binaire disponible. Au début d'une session de streaming, une liste de lecture M3U étendue (m3u8) est chargée contenant des métadonnées pour les différents sous-flux disponibles. Étant donné que les requêtes n'utilisent que des opérations HTTP standard, HTTP Live Streaming est capable de contourner tout pare-feu ou serveur proxy qui autorise le trafic HTTP standard, contrairement aux protocoles UDP tels que RTP.

HLS est basé sur HTTP. HLS définit également un mécanisme de cryptage standard utilisant AES et un moyen de distribuer une clé de sécurité à l'aide de cookies HTTPS ou HTTP, qui, ensemble, fournissent système simple protection du droit d'auteur.

Principe de fonctionnement HLS

Voyons maintenant quels sont les avantages et les inconvénients de cette technologie. Les avantages sont indéniables et évidents. Il s'agit, tout d'abord, de l'adaptabilité du débit de transfert de données aux propriétés de la ligne et de l'appareil de réception, et deuxièmement, des mécanismes intégrés de protection des droits d'auteur. Troisièmement, aucun routeur à largeur limitée n'est requis flux multidiffusion sur WI_FI, ce qui permettrait d'éviter l'absorption de toute la largeur du canal par les flux multicast, dans le cas de la diffusion de télévision IP en multicast. Il ne nécessite pas non plus d'appareil supplémentaire avec la fonction Mandataire UDP pour convertir un flux multicast en HTTP, ce qui est souvent requis pour les appareils mobiles, bien que cela affecte la charge matérielle sur le routeur ou un autre appareil qui exécute la fonction de proxy UDP dans le réseau local de l'abonné. La norme HLS est devenue assez courante et est prise en charge par presque tous les lecteurs vidéo et décodeurs modernes pour IPTV.

Décodeur IPTV

Un inconvénient important est que les abonnés disposent de décodeurs multimédias et de décodeurs Smart TV avec un micrologiciel obsolète ou des conceptions obsolètes qui ne prennent pas en charge les normes HLS ou ne les prennent pas correctement en charge. En outre, l'un des problèmes est l'incapacité de choisir la bonne qualité pour une diffusion stable dans des conditions de changement de caractéristiques de ligne dans des intervalles de temps plus courts que la durée du fragment vidéo demandé.