Configuration du streaming Amazon IVS

Amazon Interactive Video Service (IVS) permet aux développeurs de diffuser facilement et avec une faible latence des vidéos aux utilisateurs du monde entier. Avec Amazon IVS, les streamers doivent gérer uniquement la production de flux, puis envoyer le flux à Amazon IVS. Amazon IVS gère le traitement vidéo (ingestion et transcodage), la livraison et la lecture aux utilisateurs à l'aide du lecteur Amazon IVS.

Il existe une multitude de solutions pour la diffusion en direct. Que vous ayez un studio équipé de plusieurs caméras, de commutateurs visuels, de la composition graphique et d'une variété d'équipements de mixage audio, ou que vous envisagiez de démarrer votre premier flux à partir d'un smartphone, vous devez gérer plusieurs concepts et paramètres d'encodage identiques.

Ce document décrit comment configurer des encodeurs vidéo pour qu'ils diffusent sur Amazon IVS. Ce document s’adresse aux développeurs qui souhaitent intégrer des fonctionnalités de streaming dans leurs applications.

Notez que l’entrée audio uniquement n’est pas prise en charge pour le streaming à faible latence IVS.

Prérequis

Suivez les étapes de Mise en route avec le streaming à faible latence IVS pour créer un canal et configurer le streaming. Dans le processus, un ARN (Amazon Resource Name) de canal et une clé de flux sont affectés, ainsi que des URL pour l'ingestion et la lecture d'un flux. Vous devrez pointer votre application de streaming vers l'URL d'ingestion.

Avant de lire ce document, vous devez être familiarisé avec :

Réduction de la latence

Le streaming à faible latence Amazon IVS est compatible avec la plupart des applications de streaming et ne nécessite que des modifications mineures de la configuration de votre application de streaming. Pour la latence la plus faible possible, vous devez utiliser le lecteur Amazon IVS ; les lecteurs vidéo HLS tiers ne sont pas pris en charge. Consultez la documentation du Kit SDK du lecteur Amazon IVS.

Pour préparer votre application de streaming pour le streaming à faible latence, procédez comme suit. (Remarque : toutes ces options ne sont pas disponibles sur chaque application de streaming.)

Éviter les services de streaming/transfert tiers

Nous vous recommandons vivement de ne pas utiliser de service tiers pour rediffuser ou transférer du contenu à Amazon IVS. Cela entraînera une latence supplémentaire. Pour une faible latence, diffusez directement sur Amazon IVS.

Paramètres d’encodeur

Ingestion de flux : Codecs et protocoles d’ingestion

Codecs : Amazon IVS prend en charge H.264 pour la vidéo et AAC (LC) pour l'audio.

Protocoles d’ingestion : Amazon IVS prend en charge les protocoles d’ingestion les plus courants utilisés dans les logiciels et le matériel de diffusion : RTMPS (protocole de messagerie en temps réel via une connexion TLS/SSL), RTMP et SRT (protocole d’ingestion sécurisé). La diffusion d’Amazon IVS via RTMPS nécessite la version 1.2 ou ultérieure de TLS.

RTMPS/RTMP

Votre encodeur vidéo doit se connecter à l'ingestion Amazon IVS via le protocole RTMPS associé au port sortant 443/TCP. Pour ce faire, précisez un serveur d'ingestion IVS, dont le chemin d'accès comprend le port :

rtmps://<IVS-ingest-server>/<IVS-stream-key>

Par exemple :

rtmps://a1b2c3d4e5f6.global-contribute.live-video.net:443/app/<IVS-stream-key>

Les canaux IVS peuvent également être configurés pour autoriser l'ingestion RTMP non sécurisée, bien que nous vous recommandons d'utiliser le protocole RTMPS, sauf si vous avez des cas d'utilisation spécifiques et vérifiés nécessitant le protocole RTMP. Lorsque vous diffusez du RTMP, assurez-vous que le protocole est défini sur rtmp:// et supprimez le port :443. Par exemple :

rtmp://a1b2c3d4e5f6.global-contribute.live-video.net/app/<IVS-stream-key>

SRT

Votre encodeur vidéo doit se connecter au point de terminaison d’ingestion à l’aide du protocole SRT au port 9000. Pour vous en assurer, spécifiez un point de terminaison d’ingestion, qui inclut le port et la phrase de passe dans le chemin d’accès :

srt://<ingest-endpoint>:<port>?streamid=<stream-key>&passphrase=<passphrase>

N’utilisez une phrase de passe que si l’ingestion non sécurisée n’est pas activée pour le canal.

Par exemple :

srt://a1b2c3d4e5f6.srt.live-video.net:9000?streamid=sk_us-west-2_abcd1234efgh5678ijkl&passphrase=ZU5A3yrjGAkghUNDr0c5NXBhsPrjlmtcKMNBluh7oImwJQ3ijeyClvMKxlpPcGAMziICJ

Pour optimiser les performances des flux SRT, consultez ce blog Haivision : Comment configurer les paramètres SRT sur votre encodeur vidéo pour des performances optimales.

Résolution/débit/FPS

La résolution du flux détermine en grande partie son débit binaire et sa fréquence d'images (images par seconde, ou FPS). Utilisez les lignes directrices suivantes ; ce sont nos recommandations. Notez que les résolutions correspondent à une orientation paysage (horizontal x vertical), donc inversez ces résolutions pour l’orientation portrait.

Le débit binaire, le FPS et la résolution sont interdépendants. Les valeurs optimales dépendent des circonstances et peuvent être compliquées à déterminer. Le meilleur conseil que nous puissions vous donner est de commencer par les valeurs ci-dessus et d'expérimenter d'autres valeurs si vous le souhaitez. L'objectif est un mouvement clair et fluide des composants vidéo pendant le streaming et une bonne résolution dans la bande passante disponible. L’augmentation de la fréquence d’images et/ou de la résolution augmente la qualité vidéo globale, mais cela est nécessairement limité par la bande passante.

Amazon IVS prend en charge les fréquences d'images jusqu'à 60 FPS (y compris les fréquences d'images standard européennes PAL 25 et 50). Plus la fréquence d’images est élevée, meilleure est la qualité, tant que la bande passante de débit binaire est suffisante. En fonction de l'application, une faible fréquence d'images peut être suffisante, par exemple pour une caméra de sécurité.

Types de canaux

Le type de canal détermine la résolution et le débit binaire autorisés. Si vous dépassez la résolution ou le débit d’entrée autorisé, le flux se déconnectera probablement immédiatement.

Il existe quatre types de canaux : STANDARD, ADVANCED_SD, ADVANCED_HD et BASIC. Lorsque vous créez un canal, le type par défaut est STANDARD.

Il existe deux types de traitement vidéo, le transcodage et le transmuxing. Il est déterminé par le type de canal, si le canal est configuré pour une entrée vidéo multipiste et si le diffuseur utilise un client compatible multipiste. (La vidéo multipiste est configurée avec la propriété API multitrackInputConfiguration du type de données Channel.)

Tous les canaux transcodés ont des préréglages de transcodage qui déterminent les rendus produits. Considérez-les comme des échelles ABR. Ils vous permettent de trouver un compromis entre la bande passante de téléchargement disponible et la qualité vidéo, afin d'optimiser l'expérience de visionnage.

Canaux STANDARD

Entrée vidéo à piste unique

Les canaux STANDARD sont transcodés. La résolution vidéo la plus élevée produite est la Full HD, 1080p. Il s'agit du type de canal par défaut.

Entrée vidéo multipiste

Les canaux STANDARD sont transmutés lorsque l’entrée est une vidéo multipiste. La résolution vidéo la plus élevée produite est limitée par la propriété multitrackInputConfiguration.maximumResolution. Les rendus spécifiques sont dynamiques et dépendent du système du diffuseur et des exigences environnementales.

Pour tous les rendus vidéo, l’audio est transmis depuis la source.

Canaux ADVANCED-HD

Les canaux ADVANCED-HD sont transcodés. La résolution vidéo la plus élevée produite est HD, 720p.

Canaux ADVANCED-SD

Les canaux ADVANCED-SD sont transcodés. Les rendus disponibles sont limités à la qualité d'entrée, sans conversion ascendante.

Canaux BASIC

Les canaux BASIC sont transmutés. Un seul rendu est produit.

Paramètres vidéo

Nous vous recommandons de définir les paramètres suivants : Ils sont disponibles pour la plupart des logiciels d’encodage vidéo H.264 ou des API matérielles.

Paramètres audio

Nous prenons en charge les paramètres suivants :

Utiliser un CBR, et non un VBR

Utilisez toujours un débit binaire constant (CBR), et non un débit binaire variable (VBR), comme méthode de contrôle de la vitesse pour les encodeurs. Le CBR est mieux adapté à la nature des réseaux, qui sont à bande passante fixe, et il assure une lecture vidéo plus prévisible et plus stable pour les périphériques clients. Avec un débit binaire cohérent, il est facile pour les utilisateurs de sélectionner un niveau de qualité que leur connexion peut gérer au fil du temps.

Selon la complexité de la scène, le VBR peut entraîner des pics de débit binaire, qui peuvent entraîner à leur tour des abandons d'images avant que la vidéo n'atteigne Amazon IVS et/ou une mise en mémoire tampon dans les lecteurs clients.

Nous vous recommandons fortement d'utiliser uniquement le CBR. Si vous utilisez le VBR, vous courez un risque plus élevé de mise en mémoire tampon de vos flux et de lectures non fluides.

Utiliser des signaux progressifs

Utilisez des flux de signaux progressifs ; évitez toute vidéo entrelacée dans le flux de production et/ou l'encodage. Les signaux de flux progressifs offrent une meilleure qualité de lecture en affichant une image entière à la fois, évitant les artefacts de mouvement provoqués par l'affichage d'un signal entrelacé.

Exigences réseau

Vous devez disposer d'une connexion Internet stable pouvant maintenir un flux de téléchargement adéquat et constant. Une connexion Internet instable pourrait entraîner des sauts et le retard de flux pour vos utilisateurs.

Utilisez des connexions filaires. Les connexions WiFi et LTE peuvent être instables ou subir des interférences ou une latence en raison d'une mauvaise hiérarchisation de qualité de service/file d'attente de paquets. Dans la mesure du possible, utilisez une connexion câblée pour les flux.

Prévoyez d'allouer 50 % de bande passante en plus du minimum requis. La surcharge est ajoutée pour compenser les fluctuations de débit dans le codage d'un flux binaire vidéo.

Utilisez un VLAN Internet dédié pour coder les machines. Le fait de conserver l'encodeur sur un réseau distinct évite les effets potentiellement perturbateurs, notamment la pollution par le trafic, les goulots d'étranglement de la bande passante et les facteurs de sécurité défavorables.

Sous-titrage codé

IVS prend en charge le sous-titrage codé. En tant que streamer, si vous souhaitez proposer des sous-titres à votre audience, vous devez transmettre les données de sous-titres dans un format accepté, soit incorporé dans votre flux, soit à côté de votre flux, via votre encodeur vidéo.

Amazon IVS accepte les sous-titres intégrés aux formats 21 CEA-708/EIA-608 (également appelés 608 sur 708). Vous pouvez transmettre des sous-titres à l’aide de l’une des méthodes suivantes :

Remarque : les kits SDK du lecteur Amazon IVS ne prennent en charge les données de sous-titre qu'en format CC1 NTSC field 1. Ils ne prennent pas en charge la lecture de sous-titres multipistes.

Lors de la transmission via RTMPS, la charge utile doit contenir un tableau ECMA avec deux paires d’éléments :

Par exemple :

 
00000000  12 00 00 69 00 00 00 00  00 00 00 02 00 0d 6f 6e  |...i..........on|
00000010  43 61 70 74 69 6f 6e 49  6e 66 6f 08 00 00 00 02  |CaptionInfo.....|
00000020  00 04 74 79 70 65 02 00  03 37 30 38 00 04 64 61  |..type...708..da|
00000030  74 61 02 00 3c 74 51 41  78 52 30 45 35 4e 41 4e  |ta..<tQAxR0E5NAN|
00000040  4c 41 50 79 55 72 76 79  55 49 50 79 52 51 50 7a  |LAPyUrvyUIPyRQPz|
00000050  49 35 66 7a 73 37 50 7a  76 4c 50 77 67 56 50 7a  |I5fzs7PzvLPwgVPz|
00000060  33 36 66 7a 30 34 2f 78  6f 67 50 79 55 4c 2f 38  |36fz04/xogPyUL/8|
00000070  3d 00 00 09 00 00 00 74                           |=......t|

Si vous utilisez l'encodeur Elemental, configurez-le comme suit :

Pour de plus amples informations, veuillez consulter le billet de blog Adding Closed Captions to an Amazon IVS Live Stream.

Streaming via FFmpeg

FFmpeg est un projet libre et open source comprenant une vaste suite de bibliothèques logicielles pour la gestion de fichiers vidéo, audio et autres fichiers et flux multimédias. Vous pouvez l'utiliser avec de nombreux systèmes d'exploitation et appareils.

Consultez le site web de FFmpeg pour l’installation et d’autres informations sur FFmpeg. Utilisez la dernière version statique (ne pas compiler).

Après l'installation, choisissez une source d'entrée audio/vidéo pour FFmpeg. Vous pouvez rechercher ce qui est disponible, comme suit :

ffmpeg -list_devices true -f dshow -i dummy.

Pour plus d'informations, consultez ce lien. Selon ce qui est disponible et la méthode de capture ciblée, vous devriez être en mesure de capturer la vidéo / l'audio (intégré) directement à partir de votre appareil sélectionné et encoder les signaux avec FFmpeg. Exemples :

Pour de plus amples informations sur les informations à saisir pour <IVS-ingest-server> et <IVS-stream-key>, consultez les informations sur la configuration d’un logiciel de streaming dans Mise en route avec le streaming à faible latence IVS. Par exemple :

Reprise de flux

La reprise de flux permet à un utilisateur de remplacer un flux en cours sur une chaîne qu’il possède par un nouveau flux. Au cours de ce processus, le flux précédent n’est jamais déconnecté, il est simplement remplacé par le nouveau flux. Cela permet aux utilisateurs de se connecter de manière transparente à un nouveau flux sans avoir à attendre que le flux en cours se déconnecte complètement.

Le processus de reprise de flux prolonge une session de flux en cours mais n’en lance pas une nouvelle. Cela permet de maintenir la continuité du flux sans que les utilisateurs n’aient à actualiser le lecteur, bien qu’ils puissent être confrontés à un bref état de mise en mémoire tampon. Il n’y a pas de discontinuité dans les enregistrements des sessions de diffusion au cours desquelles une reprise de diffusion a lieu.

Pour lancer une reprise de flux, ajoutez le paramètre URL priority à la clé de flux de l’utilisateur. La clé de flux devient <IVS-stream-key>?priority=<priority>, où <priority> est un nombre entier positif compris entre 1 et 2 147 483 647.

La syntaxe URI pour l’utilisation de la reprise de flux avec le protocole RTMPS est la suivante :

rtmps://<uri>/<streamkey>?priority=N

Pour l’ingestion SRT, la syntaxe URI pour la reprise de flux est la suivante :

srt://<uri>?streamid=#!::u=<streamkey>,priority=N&passphrase=foobar

Une reprise réussit si l’entier de priorité fourni pour le nouveau flux est supérieur à l’entier de priorité pour le flux en cours, ou si aucun entier de priorité précédent n’a été défini. En outre, l’ancien et le nouveau flux doivent avoir la même résolution, le même codec vidéo, le même codec audio et le même nombre de pistes.

Par défaut, il est possible d’effectuer jusqu’à 100 reprises dans un seul flux, à condition d’utiliser un nombre entier de priorité plus élevé pour chaque reprise successive. Le nombre maximum de reprises de flux est réglable par compte AWS (consultez Service Quotas). Une fois le flux terminé, le canal ne conserve aucune mémoire des entiers de priorité précédents ou du nombre de reprises effectuées, de sorte que n’importe quel entier de priorité peut être réutilisé dans les flux futurs. De même, si les paramètres de l’encodeur ont été modifiés pour la reprise du flux, la session de flux ne conserve aucune mémoire des paramètres précédents de l’encodeur et n’affiche que les derniers paramètres.

Si la fonction de reconnexion automatique est activée, les kits SDK de diffusion mobile d’IVS utilisent la reprise de flux pour se reconnecter automatiquement lorsqu’un diffuseur bascule d’un réseau à l’autre (par exemple, du WiFi au cellulaire). Pour activer la reconnexion automatique :

Considérations relatives à l’utilisation conjointe de la reconnexion automatique et de la reprise de flux

Lorsque les clients du kit SDK de diffusion mobile activent la reconnexion automatique comme décrit ci-dessus, le diffuseur en cours (diffuseur A) tentera de se reconnecter jusqu’à cinq fois à la suite d’une perturbation du réseau, en commençant par priority=1 et en incrémentant la priorité à chaque tentative de reconnexion. Ce processus permet à la diffusion de se rétablir automatiquement sur des réseaux instables en augmentant progressivement la priorité à chaque reconnexion réussie.

Cependant, en raison de la nature incrémentielle du comportement de reconnexion automatique, il devient difficile pour un autre diffuseur (diffuseur B) d’utiliser avec succès la reprise de flux lorsque le diffuseur d’origine utilise la reconnexion automatique. La valeur de priorité requise pour garantir une reprise réussie sera imprévisible, car les tentatives de reconnexion par le diffuseur A augmentent la valeur de priorité à chaque nouvel essai pendant la durée du flux.

Remarque : nous ne recommandons pas d’utiliser la reprise de flux pour remplacer un flux provenant du kit SDK de diffusion mobile lorsque la reconnexion automatique est activée, car vous devrez gérer ou conserver un enregistrement de la priorité requise pour la reprise. Si la définition d’une valeur de priorité élevée peut fonctionner dans un premier temps, elle risque de poser des problèmes si une autre prise en charge est nécessaire ultérieurement. Nous vous recommandons de maintenir la reconnexion automatique pour le diffuseur A en cas d’instabilité du réseau et la reprise du flux par le diffuseur B en tant que cas d’utilisation distincts.

Streaming avec le SDK de diffusion Amazon IVS

Le SDK de diffusion Amazon IVS est destiné aux développeurs qui créent des applications Android, iOS ou Web avec Amazon IVS. Consultez la documentation du SDK de diffusion dans le guide de l’utilisateur pour Amazon IVS (à partir d’ici). Il contient des sous-pages contenant des guides pour le streaming avec Android, iOS et le Web. Les SDK de diffusion vous permettent de personnaliser la vitesse de transmission, la fréquence d'images et la résolution.

Test du flux

Vérifiez toujours que votre flux fonctionne.

Accédez au flux vidéo dans la fenêtre Amazon IVS console (Console Amazon IVS) pour voir ce qui est en cours de diffusion et gérer le flux en direct.