Amazon Kinesis Video Streams – Häufig gestellte Fragen

Ein Videostream ist eine Ressource, mit der Sie Live-Videos und andere zeitcodierte Daten erfassen und optional speichern können. Diese Daten können Sie dann sowohl in Echtzeit als auch auf Batch- oder Ad-hoc-Basis für Benutzer zur Verfügung stellen. Wenn Sie sich dazu entschließen, Daten im Videostream zu speichern, verschlüsselt Kinesis Video Streams diese Daten und generiert einen zeitbasierten Index für die gespeicherten Daten. Bei einer typischen Konfiguration wird ein Kinesis-Videostream von nur einem Produzenten mit Daten gefüttert. Der Kinesis-Video-Stream kann über mehrere konsumierende Anwendungen verfügen, die die Inhalte des Video-Streams verarbeiten.

Ein Fragment ist eine in sich geschlossene Folge von Media-Frames. Die Frames in einem Fragment sollten nicht von Frames in anderen Fragmenten abhängig sein. Kinesis Video Streams weist jedem neuen Fragment eine eindeutige Fragmentnummer in aufsteigender Reihenfolge zu. Außerdem speichert es die ersteller- und serverseitigen Zeitstempel für jedes Fragment als Kinesis Video Stream-eigene Metadaten.

Ein Ersteller ist ein allgemeiner Begriff, der ein Gerät oder eine Quelle bezeichnet, das/die Daten in einen Kinesis-Videostream speist. Ein Ersteller kann ein beliebiges Gerät sein, das Videodaten erstellt, z. B. eine Überwachungskamera, eine am Körper getragene Kamera, eine Smartphone-Kamera oder eine Dashboard-Kamera. Ein Ersteller kann außerdem videofremde, zeitcodierte Daten versenden, wie Audio-Feeds, Bilder oder Radardaten. Ein Ersteller kann einen oder mehrere Videostreams generieren. Eine Videokamera kann beispielsweise Videodaten an einen Kinesis-Video-Stream senden und die Audiodaten an einen anderen Video-Stream.

Konsumenten sind die benutzerdefinierten Anwendungen, die Daten in Kinesis-Videostreams konsumieren und verarbeiten – entweder in Echtzeit oder nachdem die Daten dauerhaft mit Zeitindex gespeichert wurden, sollte eine Niedriglatenzverarbeitung nicht erforderlich sein. Diese Konsumenten-Anwendungen können so entwickelt werden, dass sie auf Amazon EC2-Instances ausgeführt werden können. Sie können auch andere Amazon-KI-Services, wie Amazon Rekognition, oder Videoanalyse-Services von Drittanbietern zur Verarbeitung von Video-Streams nutzen.

Nachdem Kinesis Video Streams die Daten vom Ersteller erhalten hat, speichert es die eingehenden Medien als Datenblöcke. Jeder Datenblock besteht aus dem eigentlichen Medienfragment, einer Kopie der Medien-Metadaten, die vom Ersteller übermittelt wurden, und den spezifischen Kinesis Video Stream-Metadaten, wie der Fragmentnummer und den server- und erstellerseitigen Zeitstempeln. Wenn ein Konsument Mediendaten über einen GetMedia API-Prozess anfordert, gibt Kinesis Video Streams einen Datenblock-Stream wieder, beginnend mit der Fragmentnummer, die Sie in der Anfrage festlegen.

Es gibt vier Schlüsselbereiche, die bei einem durchgängigen Datenfluss zur Latenz beitragen.

• Die Zeit, die die Daten in der Medien-Pipeline der Gerätehardware verbringen: Die Pipeline kann aus dem Bildsensor und den erforderlichen Hardware-Encodern bestehen. Theoretisch dauert dies nur einen einzigen Frame lang. Praktisch stimmt das leider selten. Alle Encoder sammeln mehrere Frames an, um ein Fragment zu erstellen, damit die Medien-Codierung (Kompression) effektiv durchgeführt werden kann. Dieser Prozess und dazugehörige Bewegungskompensationsalgorithmen sorgen für eine bis mehrere Sekunden an Latenz auf dem Gerät, bevor die Daten zur Übertragung gepackt wurden.
• Bei der Übertragung über das Internet: Die Qualität der Netzwerkübertragung und der Latenz kann sich je nach Standort des Ersteller-Geräts drastisch ändern.
• Durch Kinesis Video Streams bei Abruf der Daten vom Ersteller-Gerät: Die eingehenden Daten werden dem GetMedia API-Prozess sofort für jede konsumierende Anwendung verfügbar gemacht. Wenn Sie die Daten behalten möchten, stellt Kinesis Video Streams sicher, dass die Daten mit AWS Key Management Service (AWS KMS) verschlüsselt werden, und es erstellt einen zeitbasierten Index im individuellen Fragment im Videostream. Wenn Sie auf diese beibehaltenen Daten über die GetMediaforFragmentList-API zugreifen möchten, ruft Kinesis Video Streams die Fragmente aus dem dauerhaften Speicher ab, entschlüsselt die Daten und stellt sie den konsumierenden Anwendungen zur Verfügung.
• Zeitverzögerung bei der Datenübertragung zurück an den Kunden: Es können konsumierende Geräte im Internet oder in anderen AWS-Regionen vorhanden sein, die die Mediendaten anfordern. Die Qualität der Netzwerkübertragung und die Latenz können durch den Standort des konsumierenden Geräts geringfügig beeinflusst werden.

Sie können Mediendaten über den PutMedia-Prozess in einem Kinesis-Videostream veröffentlichen oder die Kinesis Video Streams-Ersteller-SDKs in Java, C++ oder Android verwenden. Wenn Sie sich für den direkten Weg über den PutMedia-Prozess entscheiden, müssen Sie sich selbst um das Packen des Medien-Streams gemäß der Kinesis Video Streams-Datenspezifierungen, die Stream-Erstellung, die Token-Rotation und die anderen Aktionen kümmern, die erforderlich sind, um Mediendaten in die AWS Cloud zu streamen. Wir empfehlen Ihnen stattdessen, die Ersteller-SDKs zu nutzen, um diesen Vorgang zu vereinfachen und zu beschleunigen.

Kinesis Video Streams bietet Ihnen eine PutMedia-API, mit der Sie Mediendaten in einen Kinesis-Videostream schreiben können. Bei einer PutMedia-Anfrage schickt der Ersteller einen Stream mit Medienfragmenten. Kinesis Video Streams weist jedem neuen Fragment eine eindeutige Fragmentnummer in aufsteigender Reihenfolge zu. Außerdem speichert es die ersteller- und serverseitigen Zeitstempel für jedes Fragment als Kinesis Video Stream-eigene Metadaten.

Das Amazon Kinesis Video Streams-Ersteller-SDK ist eine Reihe benutzerfreundlicher und in hohem Maße konfigurierbarer Bibliotheken, die Sie für bestimmte Ersteller installieren und anpassen können. Das SDK ermöglicht die einfache Entwicklung einer Geräteanwendung, die sich gesichert mit einem Videostream verbinden und Video- und andere Mediendaten zuverlässig an Kinesis Video Streams senden kann. Es kümmert sich um die zugrundeliegenden Aufgaben, die zum Packen der Frames und Fragmente erforderlich sind, die von der Medien-Pipeline des Geräts generiert werden. Das SDK kümmert sich außerdem um die Stream-Erstellung, die Token-Rotation zum sicheren und unterbrechungsfreien Streamen, die Verarbeitung der Antworten, die von Kinesis Video Streams wiedergegeben werden, und andere Aufgaben.

Der Kern des Kinesis Video Streams-Ersteller-SDKs wurde in C geschrieben, weshalb es sich auf verschiedene Hardwareplattformen portieren und dort effizient einsetzen lässt. Die meisten Entwickler bevorzugen die Versionen C, C++ oder Java des Kinesis Video Streams-Ersteller-SDKs. Es gibt auch eine Android-Version des Ersteller-SDKs für Entwickler von Mobilgeräte-Apps, die Daten über Android-Geräte streamen möchten.

Das Kinesis Video Streams-Ersteller-SDK kümmert sich um das Packen von Frames und Fragmenten, stellt eine sichere Verbindung her und streamt die Videodaten zuverlässig an AWS. Es gibt jedoch eine Menge verschiedener Hardwaregeräte und Medien-Pipelines, die auf diesen ausgeführt werden. Um die Integration mit der Medien-Pipeline zu vereinfachen, sollten Sie die Frame-Grenzen, den für die Grenzen verwendeten Frame-Typ (I-Frame oder kein I-Frame) und den Frame-Codierungs-Zeitstempel kennen.

Sie können über die GetMedia API Medieninhalte aus einem Kinesis-Video-Stream abrufen. Bei der Anfrage müssen Sie den Stream-Namen oder den Amazon-Ressourcenname (ARN) des Streams sowie den ersten Datenblock angeben. Kinesis Video Streams gibt dann einen Stream an Datenblöcken nach Fragmentnummer wieder. Wenn Sie Mediendaten (Fragmente) auf einem Stream veröffentlichen, speichert Kinesis Video Streams alle eingehenden und verwandten Metadaten in einem sogenannten Datenblock. Die GetMedia-API gibt einen Stream dieser Datenblöcke wieder, beginnend ab dem Datenblock, den Sie in Ihrer Anfrage angegeben haben.

Mit der GetMediaForFragmentList API können Sie Mediendaten für eine Liste von Fragmenten (aufgeführt nach Fragmentnummer) von den archivierten Daten in einem Kinesis-Video-Stream abrufen. Einem Aufruf dieses API-Prozesses geht für gewöhnlich ein Aufruf an die ListFragments API voraus.

Mit der ListFragments API können Sie über die Fragmentnummer oder die Zeitstempel eine Liste an Fragmenten vom angegebenen Videostream und Startzeitpunkt in den gespeicherten Daten wiedergeben.

Sie können die Daten so lange speichern, wie Sie möchten. Bei Kinesis Video Streams können Sie den Zeitraum des Datenerhalts selbst festlegen, damit dies Ihren Archivierungs- und Speicheranforderungen gerecht wird.

Mit der Kinesis Video Streams-Parser-Bibliothek können Entwickler problemlos die Ausgabe des Kinesis Video Streams-GetMedia-Prozesses konsumieren und verarbeiten. Anwendungsentwickler nutzen die Bibliothek bei der Videoanalyse und bei verarbeitenden Anwendungen, die auf Videostreams arbeiten. Die Anwendungen selbst werden auf EC2-Instances ausgeführt, müssen aber nicht zwangsweise dort ausgeführt werden. Die Bibliothek verfügt über Funktionen, mit denen Objekte auf Frame-Ebene und die dazugehörigen Metadaten leicht abgerufen sowie Kinesis Video Streams-eigene Metadaten, die an Fragmente und nachfolgende Fragmente gebunden sind, extrahiert und gesammelt werden können. Sie können daraufhin eigene Anwendungen entwickeln, die die Videorohdateien leichter für Anwendungsfälle nutzen können.

Wenn Sie Videostreams nutzen und dann verändern möchten, damit sie den Anforderungen Ihrer eigenen Anwendung entsprechen, sind im Regelfall zwei Schritte entscheidend. Zuerst müssen Sie die Byte in einem Frame aus dem formatierten Stream über die GetMedia-API abrufen. Sie können die Stream-Parser-Bibliothek verwenden, um die Frame-Objekte abzurufen. Als Nächstes müssen Sie die Metadaten abrufen, die für die Entschlüsselung eines Frames notwendig sind, z. B. Pixelhöhe, Code-ID und Codec-Privatdaten. Diese Metadaten sind in den Spurelementen eingebettet. Mit der Parser-Bibliothek können Sie diese Informationen einfacher extrahieren, da Ihnen Helferklassen zur Verfügung stehen, die die Spurinformationen für ein Fragment sammeln.

Danach hängt alles von der jeweiligen Anwendung ab. Eventuell müssen Sie die Frames dekodieren, sie für eine Abspiel-Engine formatieren, sie zur Inhaltsverteilung transcodieren oder sie in ein benutzerdefiniertes Deep-Learning-Anwendungsformat einspeisen. Die Kinesis Video Streams-Parser-Bibliothek ist im Open-Source-Format verfügbar. Sie können sie also Ihren Anforderungen entsprechend erweitern.

Sie können die Funktionen HTTP Live Streams (HLS) und Dynamic Adaptive Streaming over HTTP (DASH) von Amazon Kinesis Video Streams verwenden, um das aufgenommene Video in fragmentiertem MP4- oder MPEG_TS-Paketformat wiederzugeben. HLS und DASH sind branchenübliche, HTTP-basierte Medien-Streaming-Protokolle. Beim Aufnehmen von Videos von Geräten mit Amazon Kinesis Video Streams können Sie die HLS- oder DASH-APIs verwenden, um Live-Videos oder aufgezeichnete Videos wiederzugeben. Diese Funktion ist voll verwaltet, Sie müssen also keine cloud-basierte Infrastruktur zur Videowiedergabe bereitstellen. Informationen zur Wiedergabe mit geringer Latenz und zum bidirektionalen Medienstreaming finden Sie in den häufig gestellten Fragen zum WebRTC-basierten Streaming.

Um einen Kinesis Video Stream mit HLS oder DASH anzuzeigen, erstellen Sie zunächst eine Streaming-Sitzung mit den APIs GetHLSStreamingSessionURL oder GetDASHStreamingSessionURL. Diese Aktion gibt eine URL (die ein Sitzungstoken enthält) für den Zugriff auf die HLS- oder DASH-Sitzung zurück, die Sie dann in einem Media Player oder einer eigenständigen Anwendung zum Wiedergeben des Streams verwenden können. Sie können einen Player eines Drittanbieters (z. B. Video.js oder Google Shaka Player) zum Anzeigen des Videostreams verwenden, indem Sie die URL der HLS- oder DASH-Streaming-Sitzung entweder programmgesteuert oder manuell angeben. Sie können Videos auch wiedergeben, indem Sie die URL der HLS- oder DASH-Streaming-Sitzung in die Adressleiste des Apple Safari- oder Microsoft Edge-Browsers eingeben. Darüber hinaus können Sie bei Mobilgeräten die Videowiedergabeprogramme Exoplayer (Android) bzw. AVMediaPlayer (iOS) verwenden.

Ein Amazon Kinesis Video-Stream hat folgende Anforderungen, um Daten über HLS bereitstellen zu können:

• Das Medium muss mit h.264 oder h.265 codiertes Video und optional mit AAC codiertem Audio enthalten. Insbesondere sollte die Codec-ID von Spur 1 V_MPEG/ISO/AVC for h.264 oder V_MPEG/ISO/HEVC für h.265 sein. Optional sollte die Codec-ID von Spur 2 A_AAC sein.
• Die Videospur jedes Fragments muss private Codec-Daten im Format Advanced Video Coding (AVC) für h.264 oder HEVC für h.265 (MPEG-4-Spezifikation ISO/IEC 14496-15) enthalten. Informationen zur Adaptierung von Stream-Daten für ein bestimmtes Format, siehe NAL Adaptation Flags.
• Der Datenerhaltzeitraum muss größer als 0 sein.
• Die Audiospur (falls vorhanden) jedes Fragments muss private Codec-Daten im AAC-Format (AAC-Spezifikation ISO/IEC 13818-7) enthalten.

Ein Amazon Kinesis Video-Stream hat folgende Anforderungen, um Daten über DASH bereitstellen zu können:

• Das Medium muss mit h.264 oder h.265 codiertes Video und optional mit AAC oder G.711 codiertem Audio enthalten. Insbesondere sollte die Codec-ID von Spur 1 V_MPEG/ISO/AVC (für h.264) oder V_MPEG/ISO/HEVC für (h.265) sein. Optional sollte die Codec-ID von Spur 2 A_AAC (für AAC) oder A_MS/ACM (für G.711) sein.
• Die Videospur jedes Fragments muss private Codec-Daten im Format Advanced Video Coding (AVC) für H.264 und HEVC für H.265 enthalten. Weitere Informationen finden Sie in der MPEG-4 Spezifikation ISO/IEC 14496-15. Informationen zur Adaptierung von Stream-Daten für ein bestimmtes Format, siehe NAL Adaptation Flags.
• Der Datenerhaltzeitraum muss größer als 0 sein.
• Die Audiospur (falls vorhanden) jedes Fragments muss private Codec-Daten im AAC-Format (AAC-Spezifikation ISO/IEC 13818-7) oder das MS Wave-Format enthalten.

Es gibt zwei verschiedene Wiedergabemodi, die sowohl von HLS als auch von DASH unterstützt werden: Live und On Demand.

LIVE: Bei Live-Sitzungen wird die HLS-Medienwiedergabeliste kontinuierlich mit den neuesten Fragmenten aktualisiert, sobald sie verfügbar sind. Wird diese Art von Sitzung in einem Medienwiedergabeprogramm abgespielt, zeigt die Benutzeroberfläche in der Regel eine "Live"-Kennzeichnung und keine Suchleiste zur Positionswahl im Wiedergabefenster wird angezeigt.

ON DEMAND: Beim On-Demand-Modus enthält die HLS-Medienwiedergabeliste alle Fragmente für die Sitzung bis zur Anzahl, die in MaxMediaPlaylistFragmentResults angegeben wurde. Die Wiedergabeliste kann nur einmal für jede Sitzung abgerufen werden.

Zusätzlich unterstützt HLS die Wiedergabe im LIVE_REPLAY-Modus. In diesem Modus wird die HLS-Medienwiedergabeliste auf ähnliche Weise wie im LIVE-Modus aktualisiert, mit der Ausnahme, dass Fragmente von einer bestimmten Startzeit eingefügt werden. Dieser Modus eignet sich für Fälle, in denen Sie die Wiedergabe von gespeicherten Medien an einem früheren Zeitpunkt starten und mit dem Live-Streaming fortfahren möchten.

Die Live-Wiedergabelatenz liegt in der Regel zwischen 3 und 5 Sekunden. Dieser Wert kann aber variieren. Wir empfehlen, Ihre eigenen Tests und Machbarkeitsstudien durchzuführen, um die Ziellatenzen zu bestimmen. Eine Vielzahl von Faktoren kann sich auf die Latenzen auswirken, darunter das Einsatzszenario, wie die Videofragmente vom Produzenten generiert werden, die Größe des Videofragements, die Konfiguration des Wiedergabeprogramms und die Netzwerkbedingungen, sowohl bei der Stream-Übertragung in AWS hinein als auch bei der Ausgabe aus AWS. Informationen zur Wiedergabe mit geringer Latenz finden Sie in den häufig gestellten Fragen zum WebRTC-basierten Streaming.

Ein Kinesis Video Stream unterstützt maximal zehn aktive HLS- oder DASH-Streaming-Sitzungen. Wird eine neue Sitzung erstellt, während die maximale Anzahl der Sitzungen bereits aktiv ist, wird die älteste (zuerst erstellte) Sitzung geschlossen. Die Anzahl der aktiven GetMedia-Verbindungen in einem Kinesis Video Stream wird bei dieser Begrenzung nicht berücksichtigt, und die Anzahl aktiver HLS-Sitzungen wird nicht für die Begrenzung aktiver GetMedia-Verbindungen berücksichtigt. Weitere Informationen finden Sie unter Kinesis Video Stream-Begrenzungen.

AWS Elemental MediaLive ist ein Enkodierungs-Service zur Ausstrahlung von Live-Videos. Mit ihm können Sie hochwertige Video-Streams zur Bereitstellung für Fernsehsysteme und mit dem Internet verbundene Multiscreen-Geräte wie angeschlossene Fernsehgeräte, Tablets, Smartphones und Set-Top-Boxen erstellen. Der Service arbeitet unabhängig oder als Teil der AWS Media Services.

Mit Amazon Kinesis Video Streams ist es ein Kinderspiel, Video von verbundenen Geräten für Echtzeit- und stapelbasiertes Machine Learning (ML), Videowiedergabe, Analysen und für andere Verarbeitungsmethoden sicher auf AWS zu streamen. So können Kunden auf maschinellem Sehen basierte Anwendungen entwickeln, die intelligente Heimsysteme, intelligente Städte, industrielle Automatisierung, Sicherheitsüberwachung und mehr antreiben.

Kinesis DataVideo Streams verwendet nutzungsabhängige Preise. Es fallen keine Vorabkosten an und Sie zahlen nur für die Ressourcen, die Sie nutzen. Die Preise für Kinesis Video Streams basieren auf dem aufgenommenen Datenvolumen (GB), dem über die HLS- oder DASH-APIs aufgenommenen Datenvolumen (GB) und den in allen Video Streams in Ihrem Konto gespeicherten Daten (GB-Monat). Weitere Informationen finden Sie auf der Seite mit den Preisangaben.
 

Der Kinesis Video Streams-Edge Agent ist eine Reihe benutzerfreundlicher und hochgradig konfigurierbarer Bibliotheken, die Sie für die lokale Videospeicherung und den geplanten Upload in die Cloud installieren und anpassen können. Sie können den KVS-Edge-Laufzeitagenten herunterladen und ihn auf Ihren Edge-Rechengeräten On-Premises bereitstellen. Alternativ können Sie diese einfach in Docker-Containern bereitstellen, die auf Amazon-EC2-Maschinen laufen. Nach der Bereitstellung können Sie die Amazon Kinesis Video Streams APIs verwenden, um die Konfigurationen für die Videoaufzeichnung und das Hochladen in die Cloud zu aktualisieren. Die Funktion kann mit jeder IP-Kamera verwendet werden, die über das RTSP-Protokoll streamt. Es ist keine zusätzliche Firmware-Installation für die Kameras erforderlich. Wir bieten die Amazon-Kinesis-Video-Streams-Edge Agent-Installationen auf AWS-Snowball Edge-Geräten, als AWS Greengrass-Komponente oder in einer nativen IoT-Bereitstellung an. Den Zugriff auf den Amazon Kinesis Video Streams Edge Agent finden Sie hier.

WebRTC ist eine offene Technologiespezifikation für die Echtzeitkommunikation ( Real-Time Communication, RTC) zwischen Browsern und mobilen Anwendungen über einfache APIs. Es nutzt Peering-Techniken für den Echtzeit-Datenaustausch zwischen verbundenen Peers und bietet eine geringe Latenz für das Media-Streaming, die für die Interaktion von Mensch zu Mensch erforderlich ist. Die WebRTC-Spezifikation enthält eine Reihe von IETF-Protokollen, einschließlich ICE RFC5245 (Interactive Connectivity Establishment), TURN RFC5766 (Traversal Using Relay Around NAT) und STUN RFC5389 (Session Traversal Utilities) zum Einrichten der Peer-to-Peer-Konnektivität (Peer-to-Peer-Konnektivität) Spezifikationen für Echtzeit-Medien- und Daten-Streaming. Kinesis Video Streams bietet eine standardkonforme WebRTC-Implementierung als vollständig verwaltete Funktion. Mit dieser Funktion können Sie Live-Streaming-Medien sicher übertragen oder Audio- oder Video-Interaktionen in beide Richtungen zwischen einem beliebigen Kamera-IoT-Gerät und WebRTC-kompatiblen Mobil- oder Web-Playern durchführen. Als vollständig verwaltete Funktion müssen Sie keine WebRTC-bezogene Cloud-Infrastruktur wie Signalisierungs- oder Media Relay-Server erstellen, betreiben oder skalieren, um Medien sicher über Anwendungen und Geräte zu streamen.

Kinesis Video Streams bietet verwaltete Endpunkte für die WebRTC-Signalisierung, mit denen Anwendungen eine sichere Verbindung für das Peer-to-Peer-Live-Media-Streaming herstellen können. Darüber hinaus enthält es verwaltete Endpunkte für TURN, die die Medienweiterleitung über die Cloud ermöglichen, wenn Anwendungen keine Peer-to-Peer-Medien streamen können. Ebenso enthalten sind verwaltete Endpunkte für STUN. So können Anwendungen ihre öffentliche IP-Adresse ermitteln, wenn sie sich hinter einer NAT oder einer Firewall befinden. Darüber hinaus bietet es einfach zu bedienende SDKs, um Kamera-IoT-Geräte mit WebRTC-Funktionen zu aktivieren. Schließlich bietet sind Client-SDKs für Android, iOS und für Webanwendungen vorhanden, um Kinesis Video Streams-WebRTC-Signalisierungs-, TURN- und STUN-Funktionen in alle WebRTC-kompatiblen mobilen oder Webplayer zu integrieren.

Mit Kinesis Video Streams WebRTC können Sie auf einfache Weise Anwendungen für Live-Media-Streaming oder Audio- oder Video-Interaktivität in Echtzeit zwischen Kamera-IoT-Geräten, Webbrowsern und Mobilgeräten erstellen -Eigentümer verwenden eine Videotürklingel, um zu überprüfen, wer vor der Tür steht. Besitzer von kameragesteuerten Roboterstaubsaugern können den Roboter fernsteuern, indem sie den Live-Kamerastream auf einem Mobiltelefon anzeigen und vieles mehr.

Sie können beginnen, indem Sie die Beispielanwendungen in den Kinesis Video Streams SDKs für WebRTC erstellen und ausführen, die für Webbrowser, Android- oder iOS-basierte Mobilgeräte sowie für Linux-, Raspbian- und MacOS-basierte IoT-Geräte verfügbar sind. Sie können diese Funktion auch in der Kinesis Video Streams-Managementkonsole kurz testen, indem Sie einen Signalisierungskanal erstellen und die Demoanwendung ausführen, um Audio- und Videostreams von der integrierten Kamera und dem Mikrofon Ihres Laptops zu übertragen.

Ein Signalisierungskanal ist eine Ressource, die es Anwendungen ermöglicht, eine Peer-to-Peer-Verbindung durch Austausch von Signalisierungsnachrichten zu erkennen, einzurichten, zu steuern und zu beenden. Signalisierungsnachrichten sind Metadaten, die zwei Anwendungen miteinander austauschen, um eine Peer-to-Peer-Konnektivität herzustellen. Diese Metadaten enthalten lokale Medieninformationen wie Mediencodecs und Codec-Parameter sowie mögliche Netzwerkkandidatenpfade, über die sich die beiden Anwendungen für das Live-Streaming miteinander verbinden können.

Streaming-Anwendungen können eine dauerhafte Konnektivität mit einem Signalisierungskanal aufrechterhalten und warten, bis andere Anwendungen eine Verbindung zu ihnen herstellen, oder sie können nur dann eine Verbindung zu einem Signalisierungskanal herstellen, wenn sie Live-Streaming-Medien benötigen. Über den Signalisierungskanal können Anwendungen in einem bis wenigen Modell miteinander verbunden werden. Dabei wird das Konzept eines Masters verwendet, der eine Verbindung zu mehreren Viewern herstellt. Die Anwendung, die die Verbindung initiiert, übernimmt die Verantwortung eines Masters über die ConnectAsMaster-API und wartet auf Betrachter. Bis zu 10 Anwendungen können dann über die ConnectAsViewer-API eine Verbindung zu diesem Signalisierungskanal herstellen, indem sie die Zuschauerverantwortung übernehmen. Sobald die Verbindung zum Signalisierungskanal hergestellt ist, können sich die Master- und Viewer-Anwendungen gegenseitig Signalisierungsnachrichten senden, um eine Peer-to-Peer-Konnektivität für das Live-Media-Streaming herzustellen.

Anwendungen verwenden den Kinesis Video Streams STUN-Endpunkt, um ihre öffentliche IP-Adresse zu ermitteln, wenn sie sich hinter einem NAT oder einer Firewall befinden. Eine Anwendung stellt ihre öffentliche IP-Adresse als möglichen Speicherort bereit, an dem Verbindungsanforderungen von anderen Anwendungen für das Live-Streaming empfangen werden können. Die Standardoption für die gesamte WebRTC-Kommunikation ist die direkte Peer-to-Peer-Konnektivität. Wenn NAT oder Firewall jetzt eine direkte Konnektivität zulassen (z. B. bei symmetrischen NATs), können Anwendungen eine Verbindung zu den Kinesis Video Streams TURN-Endpunkten herstellen, über die Medien weitergeleitet werden die Wolke. Die GetIceServerConfig-API stellt die erforderlichen TURN-Endpunktinformationen bereit, die Anwendungen in ihrer WebRTC-Konfiguration verwenden können. Diese Konfiguration ermöglicht es Anwendungen, TURN-Relay als Fallback zu verwenden, wenn sie keine direkte Peer-to-Peer-Verbindung für das Live-Streaming herstellen können.

End-to-End-Verschlüsselung ist eine obligatorische Funktion von WebRTC, und Kinesis Video Streams erzwingt sie für alle Komponenten, einschließlich Signalisierung und Medien- oder Datenstreaming. Unabhängig davon, ob die Kommunikation Peer-to-Peer ist oder über Kinesis Video Streams TURN-Endpunkte weitergeleitet wird, wird die gesamte WebRTC-Kommunikation über standardisierte Verschlüsselungsprotokolle sicher verschlüsselt. Die Signalisierungsnachrichten werden über sichere Websockets (WSS) ausgetauscht, Datenströme werden mit Datagram Transport Layer Security (DTLS) verschlüsselt und Medienströme werden mit Secure Real-Time Transport Protocol (SRTP) verschlüsselt.

Mit der Kinesis Video Streams-Management-Konsole können Sie Ihre Video-Streams erstellen, aktualisieren, verwalten und überwachen. Sie können außerdem Ihre Medien-Streams live oder auf Anfrage darüber abspielen, solange die Inhalte des Streams in einem unterstützten Medientyp vorhanden sind. Über die Player-Steuerung können Sie den Live-Stream ansehen, 10 Sekunden vor- oder zurückspulen und mit der Datum- und Zeitauswahl an den Punkt zurückspulen, zu dem Sie den entsprechenden Datenspeicherungszeitraum des Videostreams festgelegt haben. Die Videoabspielfunktionen der Kinesis Video Streams-Management-Konsole werden als schnelles Diagnose-Tool für Entwicklungs- und Testszenarien für Entwickler bei der Entwicklung von Lösungen mit Kinesis Video Streams angeboten.

Der einzig unterstützte Videomedientyp zum Abspielen in der Kinesis Video Streams-Management-Konsole ist das gängige H.264-Format. Dieses Medienformat wird auf den meisten Geräten, Hardware- und Software-Encodern und Abspiel-Engines unterstützt. Sie können zwar alle möglichen Video- und Audio-Datentypen sowie andere benutzerdefinierte zeitcodierte Datentypen für Ihre eigenen konsumierenden Anwendungen und Anwendungsfälle aufnehmen, aber die Management-Konsole kann diese Datentypen nicht abspielen.

Bei einem Ersteller, der Videodaten in den Video-Stream überträgt, müssen Sie mit einer Verzögerung von etwa 2 bis 10 Sekunden bis zur Live-Übertragung in der Kinesis Video Streams-Management-Konsole rechnen. Der Großteil dieser Verzögerung entsteht dadurch, dass das Erstellergerät Frames in Fragmente anhäuft, bevor es die Daten über das Internet sendet. Sobald die Daten im Kinesis Video Streams-Endpunkt verfügbar sind und Sie die Wiedergabe anfordern, ruft die Konsole die H.264-Medientypfragmente aus dem dauerhaften Speicher ab und packt die Fragmente in ein Medienformat, das für die Wiedergabe in verschiedenen Internetbrowsern geeignet ist. Die gepackten Medieninhalte werden dann über das Internet an Ihren Standort übermittelt, von dem aus Sie die Wiedergabe angefordert haben.

Die serverseitige Verschlüsselung ist ein Feature in Kinesis Video Streams, bei der Daten automatisch über einen AWS-KMS-Schlüssel, den Sie festlegen, verschlüsselt werden, bevor sie ruhen. Die Daten werden verschlüsselt, bevor Sie in die Kinesis Video Streams-Speicherschicht geschrieben werden, und werden verschlüsselt, nachdem sie aus dem Speicher abgerufen werden. Das bedeutet, dass Ihre ruhenden Daten im Kinesis Video Streams-Service stets verschlüsselt sind.

Die serverseitige Verschlüsselung ist in den Kinesis-Video-Streams immer aktiviert. Wenn kein vom Benutzer bereitgestellter Schlüssel bei der Erstellung des Streams festgelegt wird, wird der Standard-Schlüssel verwendet, der von Kinesis Video Streams bereitgestellt wird.

Ein vom Benutzer bereitgestellter AWS KMS-Schlüssel muss einem Kinesis Video Streams-Stream bei der Erstellung zugewiesen werden. Später können Sie dem Stream über die UpdateStream API einen anderen Schlüssel zuweisen.

Sie können einem Kinesis-Video-Stream einen vom Benutzer bereitgestellten AWS KMS-Schlüssel auf zwei verschiedene Weisen zuweisen: Legen Sie bei Erstellung eines Kinesis-Video-Streams in der Konsole den AWS KMS-Schlüssel im Bereich "Encryption" (Verschlüsselung) auf der Seite "Create new Kinesis Video stream" (Neuen Kinesis-Video-Stream erstellen) fest. Alternativ können Sie bei Erstellung eines Kinesis Video Streams-Streams die Schlüssel-ID über die CreateStream API im KmsKeyId-Parameter festlegen.

Die serverseitige Verschlüsselung unterliegt den AWS KMS-API-Nutzungs- und Schlüssel-Kosten. Im Gegensatz zu individuellen AWS KMS-Schlüsseln ist der (standardmäßig verwendete) KMS-Schlüssel aws/kinesis-video kostenlos verfügbar. Die Kosten für die API-Nutzung, die Kinesis Video Streams in Ihrem Namen verursacht, müssen Sie dennoch bezahlen. Für jeden KMS-Schlüssel (auch für die benutzerdefinierten) fallen API-Nutzungsgebühren an. Kinesis Video Streams ruft die AWS KMS bei der Rotation der Datenschlüssel ungefähr alle 45 Minuten auf. In einem Monat mit 30 Tagen sollten sich die Gesamtkosten der von Kinesis Video Streams initiierten AWS KMS API-Aufrufe auf wenige US-Dollar belaufen. Diese Kosten steigen mit der Anzahl an Anmeldedaten, die Sie für Ihre Datenproduzenten und -verbraucher verwenden, da für die einzelnen Anmeldedaten je ein individueller API-Aufruf an AWS KMS erforderlich ist.

Amazon Kinesis Video Streams fällt nicht unter das kostenlose Kontingent für AWS.

Kinesis DataVideo Streams verwendet nutzungsabhängige Preise. Es gibt weder Vorlaufkosten noch Mindestgebühren. Sie zahlen nur für die Ressourcen, die Sie tatsächlich nutzen. Die Kosten für Kinesis Video Streams basiert auf dem aufgenommenen Datenvolumen (GB), dem verbrauchten Datenvolumen (GB) und den gespeicherten Daten (GB-Monat) in allen Video-Streams in Ihrem Konto.

Außerdem berechnet Kinesis Video Streams nur Mediendaten, die erfolgreich übertragen wurden, wobei die Mindestgröße eines Datenblocks 4 KB betragen muss. Zum Vergleich: eine Audio-Sample-Datei mit 64 Kbit/s ist bereits 8 KB groß. Die Mindestgröße für einen Datenblock ist also so niedrig angesiedelt, das selbst die kleinsten Audio- oder Video-Streams unterstützt werden.

Kinesis Video Streams rechnet den Gesamtwert aller dauerhaft gespeicherten Daten in allen Streams ab. Sie können den Gesamtwert der gespeicherten Daten pro Video-Stream über den Datenerhaltzeitraum kontrollieren.

Für die Verwendung der WebRTC-Funktion von Amazon Kinesis Video Streams wird eine Gebühr berechnet, die auf der Anzahl der in einem bestimmten Monat aktiven Signalisierungskanäle, der Anzahl der gesendeten und empfangenen Signalisierungsnachrichten und der TURN-Streaming-Minuten für die Weiterleitung von Medien basiert. Ein Signalisierungskanal wird in einem Monat als aktiv betrachtet, wenn zu einem beliebigen Zeitpunkt im Monat ein Gerät oder eine Anwendung eine Verbindung zu ihm herstellt. TURN-Streaming-Minuten werden in Schritten von 1 Minute gemessen. Weitere Informationen finden Sie auf der Seite mit den Preisangaben.

Unser Amazon Kinesis Video Streams-SLA garantiert einen monatlichen Verfügbarkeitsprozentsatz von mindestens 99,9 % für Amazon Kinesis Data Streams.

Sie sind für eine SLA-Gutschrift für Amazon Kinesis Video Streams im Rahmen der Amazon Kinesis Video Streams-SLA anspruchsberechtigt, wenn mehr als eine Availability Zone, in der Sie eine Aufgabe ausführen, innerhalb derselben Region während eines beliebigen monatlichen Abrechnungszyklus einen monatlichen Verfügbarkeitsprozentsatz von weniger als 99,9 % aufweist.

Ausführliche Informationen zu allen Bestimmungen des SLA sowie Einzelheiten zur Geltendmachung eines Anspruchs finden Sie auf der Detailseite zur SLA von Amazon Kinesis Video Streams.