Questions fréquentes (FAQ) sur Amazon Kinesis Video Streams

Un flux vidéo est une ressource qui vous permet de capturer des vidéos en direct et autres données à horodatage, éventuellement de les stocker, et de mettre ces données à disposition pour une consommation aussi bien en temps réel que sur la base d'un lot, ou ponctuellement. Lorsque vous choisissez de stocker des données dans le flux vidéo, Kinesis Video Streams les chiffre et génère un index temporel des données stockées. S'il est normalement configuré, un flux vidéo Kinesis ne possède qu'un seul producteur qui y publie des données. Le flux vidéo Kinesis peut être consommé par différentes applications qui traitent les contenus du flux vidéo.

Un fragment est une séquence de contenu multimédia autonome. Les images appartenant à un fragment ne doivent dépendre d'aucune autre image provenant d'autres fragments. À la réception des fragments, Kinesis Video Streams attribue à chacun d'entre eux un numéro de fragment unique, par ordre croissant. Il stocke également les horodatages côté producteur et côté serveur pour chaque fragment, en tant que métadonnées spécifiques à Kinesis Video Streams.

Un producteur est un terme générique utilisé pour désigner un appareil ou une source qui envoie des données dans un flux vidéo Kinesis. Peut être producteur tout appareil capable de générer de la vidéo, comme une caméra de surveillance, portée sur le corps, de smartphone ou de tableau de bord. Un producteur peut également envoyer d'autres données à horodatage, telles que des supports audio, des images ou des données radar. Un producteur peut générer un ou plusieurs flux vidéo. Par exemple, une caméra vidéo peut envoyer des données vidéo dans un flux vidéo Kinesis et des données dans un autre.

Les consommateurs sont vos applications personnalisées qui consomment et traitent les données des flux vidéo Kinesis en temps réel, ou une fois les données stockées durablement et indexées dans le temps lorsqu'un traitement à faible latence n'est pas nécessaire. Vous pouvez créer ces applications de consommateurs pour qu'elles s'exécutent dans des instances Amazon EC2. Vous pouvez également utiliser d'autres services Amazon AI, comme Amazon Rekognition, ou des tiers fournisseurs d'analyses vidéo pour traiter vos flux vidéo.

Lors de la réception des données d'un producteur, Kinesis Video Streams stocke les données multimédia reçues par lots. Chaque lot est constitué du fragment multimédia en question, d'une copie des métadonnées multimédia envoyées par le producteur, et des métadonnées propres à Kinesis Video Streams, telles que le numéro de fragment et les horodatages côté serveur et côté producteur. Lorsqu’un consommateur demande des données par l’intermédiaire de l’opération API GetMedia, Kinesis Video Streams renvoie un flux de lots qui commence par le numéro de fragment précisé lors de votre demande.

Quatre contributeurs sont essentiels à la latence dans un flux de données média complet.

• Le temps passé dans le pipeline média du matériel de l'appareil : ce pipeline peut comprendre le capteur photographique, et autant d'encodeurs matériels que nécessaire. En théorie, cela peut être aussi court que la durée d'une trame unique. C'est rarement le cas en pratique. Pour encoder des médias avec efficacité (compression), tous les encodeurs accumulent plusieurs trames pour construire un fragment. Ce processus et tout algorithme de compensation de mouvement correspondant peut ajouter une à plusieurs seconde(s) de latence sur l'appareil avant que les données ne soient empaquetées à des fins de transmission.
• Latence encourue par la transmission des données sur Internet : la qualité du débit et la latence du réseau peuvent varier de manière significative en fonction de l'endroit où se trouve l'appareil producteur.
• Latence ajoutée par Kinesis Video Streams quand il reçoit des données de l’appareil producteur : les données entrantes sont immédiatement mises à disposition de toutes les applications de consommateurs par l’intermédiaire de l’opération API GetMedia. Si vous choisissez de conserver vos données, Kinesis Video Streams s'assure qu'elles soient chiffrées en utilisant AWS Key Management Service (AWS KMS), et génère un index temporel des fragments individuels du flux vidéo. Lorsque vous accédez à ces données conservées en utilisant l’API GetMediaforFragmentList, Kinesis Video Streams récupère les fragments à partir du stockage durable, déchiffre les données et les met à disposition des applications de consommateurs.
• Temps de latence lors de la retransmission des données au consommateur : des appareils consommateurs sur Internet ou dans d'autres régions AWS peuvent demander à accéder aux données média. La qualité du débit et la latence du réseau peuvent varier de manière significative en fonction de l'endroit où se trouve l'appareil producteur.

Vous pouvez ajouter des données multimédia à un flux vidéo Kinesis par l’intermédiaire de l’opération PutMedia, ou utiliser les kits SDK du producteur Kinesis Video Streams dans Java, C++ ou Android. Si vous décidez d’utiliser directement l’opération PutMedia, vous devrez empaqueter le flux multimédia selon la spécification des données Kinesis Video Streams, gérer la création du flux, la rotation des ordres de paiement et toute autre action nécessaire à la diffusion fiable de données multimédia vers le Cloud AWS. Nous vous recommandons d’utiliser les kits SDK du producteur afin de faciliter ces tâches et démarrer plus rapidement.

Kinesis Video Streams propose une API PutMedia pour écrire des données multimédia dans un flux vidéo Kinesis. Dans une demande PutMedia, le producteur envoie un flux de fragments média. À la réception des fragments, Kinesis Video Streams attribue à chacun d'entre eux un numéro de fragment unique, par ordre croissant. Il stocke également les horodatages côté producteur et côté serveur pour chaque fragment, en tant que métadonnées spécifiques à Kinesis Video Streams.

Les kits SDK du producteur Amazon Kinesis Video Streams sont constitués d’un ensemble de bibliothèques extrêmement faciles à utiliser et à configurer, que vous pouvez installer et personnaliser en fonction de vos propres producteurs. Le kit SDK vous permet de créer facilement une application pour appareil qui se connecte en toute sécurité à un flux vidéo et ajoute efficacement des vidéos et d'autres données média à Kinesis Video Streams. Il s'occupe de toutes les tâches sous-jacentes nécessaires à l'empaquetage des trames et des fragments générés par le pipeline média de l'appareil. Le kit SDK gère également la création de flux, la rotation des ordres de paiement pour un streaming sécurisé et ininterrompu, les confirmations de traitement renvoyées par Kinesis Video Streams, ainsi que d'autres tâches.

Le processeur du kit SDK du producteur Kinesis Video Streams est programmé en C, il est donc efficace et s'adapte à différentes plates-formes matérielles. La plupart des développeurs préfèrent utiliser les versions C, C++ ou Java du kit SDK du producteur Kinesis Video Streams. Il existe également une version Android du kit SDK du producteur pour les développeurs d'applications mobiles qui souhaitent diffuser des données vidéo depuis des appareils Android.

Le kit SDK du producteur Kinesis Video Streams fait le gros du travail en empaquetant les trames et les fragments, établit une connexion sécurisée et diffuse de la vidéo à AWS de manière fiable. Il y a cependant plusieurs variétés différentes d'appareils matériels et de pipelines média qui s'y exécutent. Pour faciliter le processus d'intégration avec le pipeline média, nous vous recommandons d'avoir quelques connaissances en ce qui concerne : 1) les limites des trames, 2) le type de trames utilisé pour les limites (iframe ou non), et 3) l'horodatage du codage des trames.

Vous pouvez utiliser l’API GetMedia pour extraire du contenu multimédia d’un flux vidéo Kinesis. Dans la demande, vous devez préciser le nom ou l'Amazon Resource Name (ARN) du flux et le lot de départ. Kinesis Video Streams vous fournit alors un flux de lots par ordre de numéro de fragment. Lorsque vous introduisez des données média (fragments) dans un flux, Kinesis Video Streams stocke chaque fragment entrant avec les métadonnées correspondantes dans un « lot ». L'API GetMedia vous fournit un flux de ces lots, en commençant par le lot spécifié dans votre demande.

Vous pouvez utiliser l’API GetMediaForFragmentList pour extraire les données multimédia pour une liste de fragments (définis par leur numéro de fragment) des données archivées dans un flux vidéo Kinesis. Habituellement, un appel de cette opération d’API est précédé d’un appel de l’API ListFragments.

Vous pouvez utiliser l’API ListFragments pour renvoyer une liste de fragments d’un flux vidéo et d’un emplacement de départ précis (en utilisant le numéro de fragment ou les horodatages) vers les données conservées.

Vous pouvez stocker des données dans leur flux aussi longtemps que vous le souhaitez. Kinesis Video Streams vous permet de configurer la période de rétention des données pour qu'elle réponde à vos besoins en matière d'archivage et de stockage.

Pour les développeurs, la bibliothèque d'analyseurs Kinesis Video Streams facilite la consommation et le traitement de la sortie de l'opération GetMedia de Kinesis Video Streams. Les développeurs d'applications ajoutent cette bibliothèque à leurs analyses vidéo et applications de traitement qui fonctionnent sur des flux vidéo. Les applications en tant que telles s'exécutent sur des instances EC2, même si elles peuvent aussi s'exécuter ailleurs. La bibliothèque possède des fonctions qui facilitent l'obtention d'un objet au niveau de la trame et des métadonnées qui lui sont associées, et l'extraction et la collecte de métadonnées propres à Kinesis Video Streams et rattachées aux fragments et aux fragments consécutifs. Vous pouvez ensuite créer des applications personnalisées qui exploitent plus facilement les données vidéo brutes pour vos cas d'utilisation.

En général, si vous voulez consommer des flux vidéo, puis les manipuler pour qu'ils s'adaptent à vos besoins d'application personnalisés, il faut réfléchir à deux étapes. Premièrement, rassemblez les octets dans une trame du flux formaté distribué par l'API GetMedia. Vous pouvez utiliser la bibliothèque d’analyseurs de flux afin d’obtenir les objets de la trame. Regroupez ensuite les métadonnées nécessaires au décodage d'une trame, telles que la hauteur et la largeur des pixels et l'ID et les données privées du codec. Ces métadonnées sont intégrées aux éléments de suivi. La bibliothèque d'analyseurs facilite l'extraction de ces informations en proposant des cours d'entraide pour collecter les informations de suivi d'un fragment.

À la suite de cela, les étapes dépendent grandement de l'application. Si vous souhaitez décoder les trames, formatez-les pour un moteur de lecture, transcodez-les pour en distribuer le contenu ou incorporez-les à un format d'application de deep learning personnalisée. La bibliothèque d’analyseurs de flux Kinesis Video Streams est un service libre, que vous pouvez donc étendre à tous vos cas d’utilisation spécifiques.

Vous pouvez utiliser les fonctionnalités HTTP Live Streams (HLS) et Dynamic Adaptive Streaming over HTTP (DASH) d'Amazon Kinesis Video Streams pour lire la vidéo importée au format MP4 fragmenté ou MPEG_TS packagé. HLS est un protocole de diffusion multimédia HTTP conforme aux normes du secteur. Lorsque vous capturez des vidéos à partir d'appareils utilisant Amazon Kinesis Video Streams, vous pouvez utiliser les API HLS ou DASH pour lire des vidéos en direct ou enregistrées. Cette capacité est entièrement gérée, de sorte que vous n'avez pas besoin de construire une infrastructure cloud pour prendre en charge la lecture vidéo. Pour la lecture à latence faible et la diffusion bidirectionnelle de contenu multimédia, consultez la rubrique Questions fréquentes (FAQ) sur la diffusion basée sur WebRTC.

Pour visualiser un flux vidéo Kinesis en utilisant HLS ou DASH, vous devez d’abord créer une session de streaming en utilisant les API GetHLSStreamingSessionURL ou GetDASHStreamingSessionURL. Cette action renvoie une URL (contenant un jeton de session) pour accéder à la session HLS ou DASH, que vous pouvez ensuite utiliser dans un lecteur multimédia ou une application autonome pour lire le flux. Vous pouvez utiliser un lecteur tiers (tel que Video.js ou Google Shaka Player) pour afficher le flux vidéo, en fournissant l'URL de la session de diffusion HLS ou DASH, soit par programme, soit manuellement. Vous pouvez également lire la vidéo en entrant l'URL de la session de diffusion HLS ou DASH dans la barre de localisation des navigateurs Apple Safari ou Microsoft Edge. De plus, vous pouvez utiliser les lecteurs vidéo pour Android (Exoplayer) et iOS (AVMediaPlayer) pour les applications mobiles.

Un flux vidéo Amazon Kinesis a les exigences suivantes pour fournir des données par HLS :

• Le contenu multimédia doit comporter un fichier vidéo encodé au format H.264 ou H.265 et un fichier audio encodé au format AAC (facultatif). Plus précisément, l'ID du codec de la piste 1 doit être « V_MPEG/ISO/AVC » pour le format H.264 ou « V_MPEG/ISO/HEVC » pour le format H.265. L'ID du codec de la piste 2 doit être « A_AAC » (facultatif).
• La piste vidéo de chaque fragment doit contenir les données privées du codec dans Advanced Video Coding (AVC) pour le format H.264 ou HEVC pour le format H.265 (spécification MPEG-4 ISO/IEC 14496-15). Pour plus d’informations sur l’adaptation des données de flux à un format donné, consultez NAL Adaptation Flags.
• La rétention des données doit être supérieure à 0.
• Le cas échéant, la piste audio de chaque fragment doit contenir les données privées du codec au format AAC (spécification AAC ISO/IEC 13818-7).

Un flux vidéo Amazon Kinesis a les exigences suivantes pour fournir des données par DASH :

• Le contenu multimédia doit comporter un fichier vidéo encodé au format H.264 ou H.265 et un fichier audio encodé au format AAC ou G.711 (facultatif). Plus précisément, l'ID du codec de la piste 1 doit être « V_MPEG/ISO/AVC » (pour le format H.264) ou « V_MPEGH/ISO/HEVC » (pour le format H.265). L'ID du codec de la piste 2 doit être « A_AAC » (pour AAC) ou « A_MS/ACM » (pour G.711) (facultatif).
• La piste vidéo de chaque fragment doit contenir les données privées du codec dans Advanced Video Coding (AVC) pour le format H.264 et HEVC pour le format H.265. Pour plus d’informations, consultez MPEG-4 specification ISO/IEC 14496-15. Pour plus d’informations sur l’adaptation des données de flux à un format donné, consultez NAL Adaptation Flags.
• La rétention des données doit être supérieure à 0.
• Le cas échéant, la piste audio de chaque fragment doit contenir les données privées du codec au format AAC (spécification AAC ISO/IEC 13818-7) ou au format MS Wave.

Il existe deux modes de lecture différents pris en charge par HLS et DASH : Live (en direct) et On Demand (à la demande).

LIVE : pour les sessions en direct, la playlist multimédia HLS est continuellement mise à jour avec les derniers fragments au fur et à mesure qu'ils deviennent disponibles. Lorsque ce type de session est lu dans un lecteur multimédia, l'interface utilisateur affiche généralement une notification « en direct », sans contrôle du programme de nettoyage pour choisir la position dans la fenêtre de lecture à afficher.

ON DEMAND : pour les sessions à la demande, la playlist multimédia HLS contient tous les fragments de la session, jusqu'au nombre spécifié dans MaxMediaPlaylistFragmentResults. La playlist ne peut être récupérée qu'une seule fois pour chaque session.

En outre, HLS prend également en charge la lecture en mode LIVE_REPLAY. Dans ce mode, la playlist multimédia HLS est mise à jour de la même manière que pour le mode LIVE, mais elle commence à inclure les fragments à partir d'une heure de début donnée. Ce mode peut s'avérer utile lorsque vous souhaitez démarrer la lecture à partir d'un point du passé pour du contenu multimédia stocké, puis poursuivre sous forme de diffusion en direct.

La latence pour la lecture en direct est généralement comprise entre 3 et 5 secondes, mais cela peut varier. Nous vous recommandons fortement d'effectuer vos propres tests et démonstrations de faisabilité pour déterminer les latences cibles. Divers facteurs influent sur les latences, notamment le cas d'utilisation, la façon dont le producteur génère les fragments vidéo, la taille du fragment vidéo, la syntonisation du lecteur et les conditions du réseau, qu'il s'agisse de la diffusion en continu sur les SSFE ou hors des SSFE pour la lecture. Pour la lecture à latence faible, consultez la rubrique Questions fréquentes (FAQ) sur la diffusion basée sur WebRTC.

Un flux vidéo Kinesis peut prendre en charge un maximum de dix sessions de diffusion HLS ou DASH actives. Si une nouvelle session est créée alors que le nombre maximal de sessions est déjà actif, la session la plus ancienne (la plus anciennement créée) est fermée. Le nombre de connexions GetMedia actives sur un flux vidéo Kinesis ne compte pas dans cette limite, et le nombre de sessions HLS actives ne compte pas dans la limite de connexion GetMedia active. Pour en savoir plus, consultez Kinesis Video Streams Limits.

AWS Elemental MediaLive est un service d'encodage vidéo en direct de niveau professionnel. Le service vous permet de créer des flux vidéo de haute qualité en vue d'une diffusion sur les télévisions et les appareils multiécran connectés à Internet, comme les télévisions connectées, les tablettes, les smartphones et les décodeurs TV. Le service fonctionne indépendamment ou en tant que partie intégrante d'AWS Media Services.

Amazon Kinesis Video Streams facilite la diffusion sécurisée de vidéo vers AWS depuis des appareils connectés pour le machine learning (ML) en temps réel et en traitement par lot, la lecture vidéo et l'analyse et d'autres méthodes de traitement. Il permet aux clients de construire des applications basées sur la vision automatique qui alimentent les maisons intelligentes, les villes intelligentes, l'automatisation industrielle, la surveillance de la sécurité, et plus encore.

Kinesis Video Streams propose un système de tarification à l'utilisation très simple. Aucun investissement initial n'est nécessaire et vous payez uniquement pour les ressources que vous utilisez. La tarification de Kinesis Video Streams se base sur le volume des données importées (en Go), le volume des données consommées (en Go), y compris par l'intermédiaire des API HLS ou DASH, et les données stockées (en Go/mois) dans tous les flux vidéo de votre compte. Pour plus d’informations, consultez la page Tarification.
 

L'agent périphérique Kinesis Video Streams est un ensemble de bibliothèques faciles à utiliser et hautement configurables que vous pouvez installer et personnaliser pour le stockage vidéo local et le téléchargement programmé sur le cloud. Vous pouvez télécharger l'agent périphérique et le déployer sur vos appareils de calcul en périphérie sur site. Vous pouvez également les déployer facilement dans des conteneurs Docker exécutés sur des machines Amazon EC2. Une fois les nouvelles Amazon Kinesis Video Streams déployées, vous pouvez les utiliser pour mettre à jour les configurations d'enregistrement vidéo et de chargement dans le cloud. Cette fonctionnalité est compatible avec toutes les caméras IP capables de diffuser du contenu via le protocole RTSP et ne nécessite aucun déploiement de microprogramme supplémentaire sur les caméras. Nous proposons l'installation de l'agent périphérique Amazon Kinesis Video Streams sur les appareils AWS Snowball Edge, en tant que composant AWS Greengrass ou dans le cadre d'un déploiement IoT natif. Pour accéder à l’agent périphérique Amazon Kinesis Video Streams, cliquez ici.

WebRTC est une spécification de technologie ouverte qui permet une communication en temps réel (RTC) entre les navigateurs et les applications mobiles par l'intermédiaire d'API simples. Cette technologie s'appuie sur des techniques d'appairage pour l'échange de données en temps réel entre des pairs connectés et fournit la diffusion de contenu multimédia à faible latence nécessaire aux interactions humaines. La spécification WebRTC comprend un ensemble de protocoles IETF, notamment l’Interactive Connectivity Establishment (ICE RFC5245), le Traversal Using Relay around NAT (TURN RFC5766) et le Session Traversal Utilities for NAT (STUN RFC5389), destiné à établir une connectivité pair à pair, en plus de spécifications liées aux protocoles pour la diffusion de contenu multimédia et de données en temps réel. Kinesis Video Streams fournit une mise en œuvre WebRTC conforme aux normes, qu'il présente comme une fonctionnalité entièrement gérée. Vous pouvez utiliser cette fonctionnalité pour diffuser du contenu multimédia en direct et en toute sécurité ou pour créer une interaction vidéo ou audio bidirectionnelle entre n'importe quel appareil IoT équipé d'une caméra et tout lecteur Web ou mobile compatible avec WebRTC. Puisqu'il s'agit d'une fonctionnalité entièrement gérée, vous n'avez besoin de créer, d'exploiter ou de dimensionner aucune infrastructure Cloud associée à WebRTC, comme les serveurs de signalisation ou de relais multimédia, pour diffuser en toute sécurité votre contenu multimédia sur plusieurs applications et appareils.

Kinesis Video Streams fournit des points de terminaison gérés pour la signalisation WebRTC, ce qui permet aux applications de se connecter en toute sécurité les unes aux autres aux fins de diffusion multimédia en direct de pair à pair. Ensuite, il inclut des points de terminaison gérés pour TURN, ce qui permet le relais multimédia par le Cloud lorsque les applications ne peuvent pas diffuser en continu le contenu multimédia pair à pair. Il inclut également des points de terminaison gérés pour STUN, ce qui permet aux applications de déterminer leur adresse IP publique lorsqu'elles sont situées derrière un NAT ou un pare-feu. De plus, il fournit des SDK faciles à utiliser pour activer les appareils IoT des caméras par le biais des fonctionnalités WebRTC. Enfin, il fournit aux clients des SDK pour Android, iOS et pour les applications Web afin d'intégrer les capacités de signalisation WebRTC, TURN et STUN de Kinesis Video Streams à tout lecteur Web ou mobile compatible avec WebRTC.

Avec la fonctionnalité WebRTC de Kinesis Video Streams, vous pouvez facilement créer des applications pour la diffusion de contenu multimédia en direct ou pour l'interactivité audio ou vidéo en temps réel entre les caméras des appareils IoT, les navigateurs Web et les appareils mobiles pour divers cas d'utilisation : aider les parents à garder un œil sur la chambre de leur bébé, permettre aux habitants d'une maison d'utiliser une sonnette vidéo pour voir qui se trouve à leur porte, offrir aux propriétaires d'aspirateurs robots équipés d'une caméra la possibilité de contrôler le robot à distance en visionnant en direct le flux de la caméra depuis un téléphone mobile, etc.

Vous pouvez commencer par créer et exécuter les exemples d’application dans les kits SDK Kinesis Video Streams pour WebRTC disponibles pour les appareils mobiles basés sur des navigateurs Web, Android ou iOS et pour les appareils IoT fonctionnant sur Linux, Raspbian et MacOS. Vous pouvez également lancer une rapide démonstration de cette fonctionnalité dans la console de gestion Kinesis Video Streams en créant un canal de signalisation et en exécutant l’application de démonstration pour diffuser du contenu audio et vidéo en direct à partir de la caméra et du microphone intégrés à votre ordinateur portable.

Un canal de signalisation est une ressource permettant aux applications de découvrir, de configurer, de contrôler et d'arrêter une connexion pair à pair en échangeant des messages de signalisation. Les messages de signalisation correspondent aux métadonnées que deux applications échangent entre elles pour établir une connectivité pair à pair. Ces métadonnées comprennent des informations sur le contenu multimédia local, comme les codecs multimédia, les paramètres des codecs et les candidats potentiels en termes de chemins d'accès pour que les deux applications se connectent entre elles à des fins de diffusion en direct.

Les applications de diffusion peuvent assurer une connectivité permanente avec un canal de signalisation et attendre que d'autres applications se connectent avec elles, ou se connecter à un canal de signalisation seulement lorsqu'elles ont besoin de diffuser du contenu multimédia en direct. Le canal de signalisation permet aux applications de se connecter entre elles sur le modèle « une vers plusieurs », grâce au concept d'après lequel une application « maître » se connecte à plusieurs autres applications « spectatrices ». L'application à l'origine de la connexion endosse la responsabilité de « maître » par l'intermédiaire de l'API ConnectAsMaster et attend les autres applications. À partir de là, 10 applications au maximum peuvent se connecter à ce canal de signalisation en tant que « spectatrices » par l'intermédiaire de l'API ConnectAsViewer. Une fois connectées au canal de signalisation, l'application « maître » et les applications « spectatrices » peuvent s'envoyer des messages de signalisation entre elles, afin d'établir une connectivité pair à pair pour la diffusion de contenu multimédia en direct.

Les applications utilisent le point de terminaison STUN de Kinesis Video Streams pour déterminer leur adresse IP publique lorsqu'elles sont situées derrière un NAT ou un pare-feu. Une application fournit son adresse IP publique en tant qu'emplacement potentiel où elle peut recevoir des demandes de connexion de la part d'autres applications pour une diffusion en direct. L'option par défaut pour toutes les communications WebRTC est une connectivité pair à pair directe, mais si le NAT ou le pare-feu ne permet pas une connectivité directe (par ex. dans le cas de NAT symétriques), les applications peuvent se connecter au point de terminaison TURN de Kinesis Video Streams pour relayer du contenu multimédia par l'intermédiaire du Cloud. L'API GetIceServerConfig fournit les informations sur le point de terminaison TURN nécessaires aux applications pour leur configuration WebRTC. Cette configuration permet aux applications d'utiliser le relais TURN comme une solution de secours lorsqu'elles ne sont pas en mesure d'établir une connexion pair à pair directe pour la diffusion en direct.

Le chiffrement de bout en bout est une fonctionnalité obligatoire de WebRTC, et Kinesis Video Streams l'applique à tous ses composants, notamment à la signalisation et à la diffusion de contenu multimédia ou de données. Que la communication se fasse de pair à pair ou soit relayée par l'intermédiaire des points de terminaison TURN de Kinesis Video Streams, toutes les communications WebRTC sont chiffrées de manière sécurisée grâce à des protocoles de chiffrement standardisés. Les messages de signalisation sont échangés par l'intermédiaire de WebSockets (WSS) sécurisées, les flux de données sont chiffrés à l'aide du protocole Datagram Transport Layer Security (DTLS) et les flux de contenu multimédia sont chiffrés grâce au Secure Real-time Transport Protocol (SRTP).

La console de gestion de Kinesis Video Streams vous permet de créer, de mettre à jour, de gérer et de contrôler vos flux vidéo. Elle peut également lire vos flux média en direct ou à la demande, tant que le contenu des flux se trouve dans le type de média pris en charge. En utilisant les panneaux de contrôle, vous pouvez visualiser le flux en direct, avancer ou reculer de 10 secondes et utiliser le sélecteur de date et d'heure pour revenir à un moment passé une fois que vous avez fixé la période de rétention correspondante pour ce flux vidéo. Les capacités de lecture vidéo de la console de gestion de Kinesis Video Streams sont offertes en tant qu'outil de diagnostic rapide du développement et des scénarios de test à l'intention des développeurs qui créent des solutions à l'aide de Kinesis Video Streams.

Le seul type de contenu multimédia vidéo pris en charge pour la lecture avec la console de gestion de Kinesis Video Streams est le format populaire H.264. Ce format média est largement pris en charge par les appareils, les encodeurs matériels et logiciels et les moteurs de lecture. Bien que vous puissiez absorber tous types de données vidéo et audio, ou d'autres données à horodatage personnalisées pour vos propres applications de consommateurs et cas d'utilisation, la console de gestion ne lira pas ces autres types de données.

Quand un producteur transmet des données vidéo au flux vidéo, la lecture en direct dans la console de gestion de Kinesis Video Streams peut accuser un retard de 2 à 10 secondes. La majeure partie de la latence est ajoutée par l'appareil producteur qui accumule les trames sous forme de fragments avant de transmettre les données par Internet. Une fois que les données pénètrent dans le point de terminaison de Kinesis Video Streams et que vous en demandez la lecture, la console extrait les fragments des types de média au format H.264 du stockage durable et empaquette les fragments dans un format média adapté à la lecture sur différents navigateurs Internet. Le contenu média empaqueté est ensuite transféré par Internet jusqu'à l'emplacement depuis lequel vous avec demandé la lecture.

Le chiffrement côté serveur est une fonctionnalité de Kinesis Video Streams qui chiffre automatiquement les données avant qu’elles ne soient au repos, en utilisant une clé AWS KMS que vous spécifiez. Les données sont chiffrées avant d'être écrites dans la couche de stockage de Kinesis Video Streams, et déchiffrées après avoir été extraites du stockage. De ce fait, vos données sont toujours chiffrées au repos dans le service Kinesis Video Streams.

Le chiffrement côté serveur est toujours activé sur les flux vidéo Kinesis. Si l'utilisateur ne fournit aucune clé spécifique lors de la création du flux, alors c'est la clé par défaut (fournie par Kinesis Video Streams) qui est utilisée.

Une clé AWS KMS fournie par l'utilisateur doit être attribuée à un flux Kinesis Video Streams lors de sa création. Il est impossible d’utiliser l’API UpdateStream pour attribuer ultérieurement une clé différente à un flux.

Il existe deux manières d'attribuer une clé AWS KMS fournie par l'utilisateur à un flux vidéo Kinesis. Lorsque vous créez un flux vidéo Kinesis dans la console, spécifiez la clé AWS KMS dans la section Chiffrement de la page Créer un nouveau flux vidéo Kinesis. Sinon, vous pouvez créer un flux Kinesis Video Streams à l’aide de l’API CreateStream et spécifier l’ID de la clé dans le paramètre KmsKeyId.

Lorsque vous appliquez le chiffrement côté serveur, vous êtes assujetti aux coûts liés à l'utilisation d'API et aux clés AWS KMS. À la différence des clés AWS KMS personnalisées, la clé KMS aws/Kinesis Video (par défaut) est offerte gratuitement. Cependant, vous continuez à payer les coûts d'utilisation d'API que Kinesis Video Streams engage pour vous. Les coûts d'utilisation de l'API s'appliquent pour chaque clé KMS, y compris l celles personnalisées. Kinesis Video Streams appelle AWS KMS environ toutes les 45 minutes lorsqu'il effectue la rotation de la clé de données. Sur un mois de 30 jours, le coût total des appels d'API d'AWS KMS initiés par un flux Kinesis Video Streams ne devrait pas dépasser quelques dollars. Ces coûts sont fonction du nombre d'informations d'identification des consommateurs que vous utilisez sur vos producteurs et consommateurs de données, car chaque information d'identification nécessite un appel d'API unique à AWS KMS.

Non. Amazon Kinesis Video Streams n'est actuellement pas disponible dans le cadre de l'offre gratuite d'AWS.

Kinesis Video Streams propose un système de tarification à l'utilisation très simple. Aucun investissement initial n'est nécessaire et nous n'appliquons pas de frais minimum : vous payez uniquement pour les ressources que vous utilisez. La tarification de Kinesis Video Streams se base sur le volume des données ingérées (en Go), le volume des données consommées (en Go) et les données stockées (en Go/mois) dans tous les flux vidéo de votre compte.

En outre, Kinesis Video Streams facture uniquement les données média d'une taille minimum de 4 Go par lot qu'il reçoit avec succès. En comparaison, un échantillon audio de 64 kbit/s possède une taille de 8 Ko ; la taille minimum du lot est donc réglée à un niveau suffisamment bas pour s'adapter aux plus petits des flux audio ou vidéo.

Kinesis Video Streams vous facturera pour la quantité totale de données stockées durablement dans n'importe quel flux. La quantité totale de données stockées par flux vidéo peut être contrôlée à l'aide de périodes de rétention.

Pour utiliser la fonctionnalité WebRTC d'Amazon Kinesis Video Streams, vous êtes facturé sur la base du nombre de canaux de signalisation actifs au cours d'un mois donné, le nombre de messages de signalisation envoyés et reçus ainsi que le nombre de minutes de diffusion TURN utilisées pour relayer le contenu multimédia. Un canal de signalisation est considéré comme actif au cours d'un mois si, à tout moment au cours de celui-ci, un appareil ou une application s'y connecte. Les minutes de diffusion TURN sont calculées par incréments de 1 minute. Pour plus d’informations, consultez la page Tarification.

Notre accord de niveau de service Amazon Kinesis Video Streams SLA garantit un pourcentage de disponibilité mensuel d'au moins 99,9 % pour Amazon Kinesis Video Streams.

Vous pouvez bénéficier d'un crédit SLA pour Amazon Kinesis Video Streams dans le cadre du SLA Amazon Kinesis Video Stream si plusieurs zones de disponibilité dans lesquelles vous exécutez une tâche dans la même région ont un pourcentage de disponibilité mensuel inférieur à 99,9 % pendant un cycle de facturation mensuel.

Pour consulter l’intégralité des conditions générales de l’accord de niveau de service et en savoir plus sur la marche à suivre pour soumettre une demande, consultez la page d’informations d’Amazon Kinesis Video Streams SLA.