Häufig gestellte Fragen zu Azure Media Services

Weitere Informationen finden Sie im Leitfaden zur Einstellung von Azure Media Services.

Hier sehen Sie eine Auflistung:

• OpenAPI-Spezifikation (Swagger)
• Azure-Befehlszeilenschnittstelle
• .NET
• Java
• Python
• Node.js
• Go

Es empfiehlt sich nicht, die REST-API für Media Services direkt in Ihren eigenen Bibliothekscode einzuschließen. Wollten Sie dies ordnungsgemäß für Produktionszwecke tun, müssten Sie die vollständige Azure Resource Manager-Wiederholungslogik implementieren und verstehen, wie Vorgänge mit langer Ausführungslaufzeit in Resource Manager-APIs verwaltet werden. Die Client-SDKs für verschiedene Sprachen – z. B. .NET, Java, TypeScript, Python und Ruby – übernehmen dies automatisch für Sie, um die Gefahr von Problemen mit Wiederholungslogik oder fehlgeschlagenen API-Aufrufen zu verringern.

Sehen Sie sich die Beispielseiten an. Es gibt Beispiele für Konten, Ressourcen, Livestreaming, VOD-Streaming, Inhaltsschutz, Codierung, Analyse und Verwenden von Playern.

Bei Verwendung der Paginierung sollten Sie immer den Link „Weiter“ verwenden, um die Sammlung zu durchlaufen, und nicht auf eine bestimmte Seitengröße zurückgreifen. Weitere Informationen und Beispiele finden Sie unter Filtern, Sortieren und Auslagern von Entitäten.

Informationen zur Verwendung der Azure-Befehlszeilenschnittstelle zum Koppeln von Media Services mit Key Vault, um Ihre Daten zu verschlüsseln, finden Sie im Tutorial zum Verwenden eines Key Vault-Schlüssels zur Verschlüsselung von Daten in einem Media Services-Konto.

Wenn Sie möchten, dass Media Services auf ein Speicherkonto zugreifen kann, und das Speicherkonto so konfiguriert ist, dass Anforderungen von unbekannten IP-Adressen blockiert werden, führen Sie die Schritte unter Zugreifen auf Speicher mit einer verwalteten Media Services-Identität aus.

Lesen Sie dazu Verschieben eines Media Services-Kontos zwischen Abonnements.

Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung (RBAC) in Azure für Media Services-Konten.

Media Services definiert die folgenden integrierten Rollen:

• Media Services-Kontoadministrator
• Media Services-Medienoperator
• Media Services-Richtlinienadministrator
• Media Services-Administrator für Streamingendpunkte
• Media Services-Administrator für Liveereignisse

Details zu den Rollen finden Sie unter Rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) für Media Services-Konten.

Diese Rollen können verwendet werden, um einem Media Services-Konto präzisen Zugriff zu gewähren. Um einem Media Services-Konto Vollzugriff zu gewähren, kann die Rolle „Besitzer“ oder „Mitwirkender“ verwendet werden. Media Services verfügt über eine ältere API im Ablaufpfad, die keine präzise Zugriffssteuerung unterstützt. Kunden, die eine präzise Zugriffssteuerung benötigen, sollten beim Erstellen eines Media Services-Kontos über das Portal nicht „Klassische APIs aktivieren“ aktivieren (oder die API-Version 2020-05-01 verwenden, wenn sie die API zum Erstellen von Konten verwenden).

Die folgende integrierte Azure Policy kann verwendet werden, um die Erstellung von Konten zu blockieren, die die alte API unterstützen: Azure Media Services-Konten, die Zugriff auf die Legacy-API (v2) erlauben, sollten blockiert werden – Microsoft Azure.

Ein Media Services-Medienobjekt ist ein Azure Storage-Kontocontainer, der für jede hochgeladene Videodatei verwendet wird. Er weist einen eindeutigen Bezeichner auf, der für Transformationen und andere Vorgänge verwendet wird. Lesen Sie dazu Medienobjekte in Azure Media Services v3.

Jedes Mal, wenn Sie eine Mediendatei hochladen und Vorgänge damit durchführen möchten, z. B. Codierung oder Streaming, erstellen Sie ein Medienobjekt, um die Mediendatei und mit ihr verbundene Dateien zu speichern. Medienobjekte werden automatisch für Sie erstellt, wenn Sie das Azure-Portal verwenden. Wenn Sie nicht das Portal zum Hochladen von Dateien verwenden, müssen Sie zuerst ein Medienobjekt erstellen.

Die gängigen Codierungsformate sind mit Media Services Standard Encoder verfügbar. Eine Liste aller Formate finden Sie unter Media Encoder Standard-Formate und -Codecs.

Sie können einen Auftrag im Azure-Portal mithilfe der Azure-Befehlszeilenschnittstelle, REST oder einem der SDKs erstellen. Informationen dazu finden Sie unter Media Services: Beispiele für Ihre bevorzugte Sprache.

Ja. Lesen Sie dazu Codieren mit einer automatisch generierten Reihe von Bitraten-/Auflösungspaaren.

Ja. Media Services kann für ein Video eine Analyse in zwei Durchgängen durchführen. Anschließend kann es basierend auf den Inhalten des Videos die besten Einstellungen für adaptive Bitraten, Auflösungen und Codierung empfehlen.

Ja. Ausführliche Informationen und Links zu einer Beispielanwendung, die zeigt, wie Sie eine vorcodierte MP4-Datei mit einheitlicher Bitrate hochladen, und das Servermanifest (ISM) sowie das Clientmanifest (ISMC) generieren, finden Sie in der Antwort auf die Frage „Kann ich vorhandene MP4-Dateien streamen, die in einer anderen Lösung vorcodiert oder codiert sind?“, welche in dem Abschnitt über Verpackung und Bereitstellung zu finden ist. In dieser Antwort sind außerdem die Auswirkungen auf die Leistung der Quelle beschrieben.

Wir raten davon ab. Sehr kurze Inhalte mit einer Dauer von unter ein oder zwei Minuten eignen sich nicht wirklich für das Streaming mit adaptiven Bitraten. Wenn Sie sehr kurze Dateien streamen möchten, empfiehlt es sich, die Inhalte vorab in einem Format zu codieren, das sich problemlos mit einer einheitlichen Bitrate streamen lässt.

Da die meisten Player mit adaptiver Bitrate Zeit zum Puffern mehrerer Videosegmente sowie Zeit zur Analyse der Netzwerkbandbreite vor dem „Verschieben“ nach oben oder unten in der Reihe adaptiver Bitraten benötigen, ist es oft nicht sinnvoll, viele Bitraten für Inhalte bereitzustellen, die unter 30 Sekunden lang sind. Wenn der Player seinen heuristischen Algorithmus auf Grundlage der Netzwerkbedingungen auf die richtige Bitrate für die Wiedergabe fixiert hat, ist das Streamen der Datei bereits beendet.

Darüber hinaus puffern einige Player standardmäßig bis zu drei Videosegmente. Jedes Segment kann zwei bis sechs Sekunden lang sein. Bei Videos in sehr kurzem Format ist es wahrscheinlich, dass der Player puffert und die Wiedergabe mit der ersten ausgewählten Bitrate des Satzes der adaptiven Bitraten beginnt. Aus diesem Grund empfiehlt es sich, eine MP4-Datei mit einheitlicher Bitrate zu verwenden und sie in ein Medienobjekt hochzuladen, wenn für Sie die Generierung eine HLS- oder DASH-Manifests erforderlich ist. Ausführliche Informationen dazu, wie dies erreicht werden kann, finden Sie in der Antwort auf die Frage „Kann ich vorhandene MP4-Dateien streamen, die in einer anderen Lösung vorcodiert oder codiert sind?“, welche in dem Abschnitt über Verpackung und Bereitstellung zu finden ist.

Die Dateien müssen nur dann im HLS- oder DASH-Format übermittelt werden, wenn Sie die Funktionen dieser Protokolle nutzen möchten. Für Streams mit einheitlicher Bitrate können sie dennoch viel bieten – z. B. schnellere Suche, DRM-Unterstützung, erschwerter Download über eine URL (der aber immer noch möglich ist!) im Vergleich zum Download einer progressiven MP4 in Blobspeicher. Die Unterstützung von Untertiteln für VTT und IMSC1 ist ein weiterer Vorteil. Darüber hinaus ist die Möglichkeit, zusätzliche Audiowiedergaben oder Synchronisierungen in alternativen Sprachen spät zu binden, in einigen Situationen sehr wertvoll.

Wenn Sie Wege suchen, Arbeitsschritte wie das Drehen von Videos, Hinzufügen von Subclips, Zusammenfügen von Videos oder Erstellen von Miniaturansichten und Sprites mit einem Media Services-Encoder durchzuführen, sehen Sie sich doch einmal die Seite Codebeispiele mit ihren unzähligen Beispielcodes an. Die Codebeispiele liegen in den Sprachen Node.JS, Python, .NET und Java vor.

Ein Media Services-Liveereignis ist der Prozess der Erfassung von Livevideofeeds und deren Übertragung über ein RTMPS-Protokoll oder über Smooth Streaming. Weitere Informationen finden Sie unter Liveereignisse und Liveausgaben in Media Services.

Der erste Schritt besteht in der Auswahl eines lokalen Encoders. Wir stellen Beispiele zum Erstellen eines Liveereignisses mit Wirecast und OBS zur Verfügung. Wenn Sie lieber mit einer Übersicht von Media Services-Liveereignissen beginnen möchten, finden Sie weitere Informationen unter Liveereignistypen.

Azure Media Service übermittelt Video, Audio und Text in verschiedenen Protokollen. Wenn Sie Ihren Livestream mittels MPEG-DASH oder HLS/CMAF veröffentlichen, stellt der Dienst neben den Video- und Audiospuren auch den transkribierten Text im IMSC1.1-kompatiblen TTML-Format bereit. Weitere Informationen finden Sie unter Livetranskription.

Sie können Liveereignisse überwachen, indem Sie Event Grid-Ereignisse abonnieren. Weitere Informationen finden Sie unter Event Grid-Ereignisschema. Sie haben folgende Möglichkeiten:

• Abonnieren Sie die Ereignisse für Microsoft.Media.LiveEventEncoderDisconnected auf Streamebene, und überwachen Sie, ob für einen bestimmten Zeitraum neue Verbindungen eingehen, um Ihr Liveereignis zu beenden und zu löschen.
• Abonnieren Sie die Taktereignisse auf Spurebene. Wenn die eingehende Bitrate bei allen Spuren auf 0 fällt oder wenn der letzte Zeitstempel nicht mehr ansteigt, können Sie das Liveereignis sicher beenden. Die Taktereignisse gehen alle 20 Sekunden für jede Spur ein, sodass die Informationsmenge etwas höher ausfallen könnte.

Nein, Sie können die gleiche Streaming-URL nicht einfach wiederverwenden, wenn Sie ein Liveereignis beenden und neu starten. Jedes Mal, wenn Sie eine neue Liveausgabe (und ein Medienobjekt) erstellen und veröffentlichen, wird eine neue Streaming-URL (GUID) für den neuen Locator verwendet. Auf diese Weise ist sichergestellt, dass es keine Cachekonflikte im Streamingendpunkt und im CDN (Content Delivery Network) gibt. Sie können Streaming-URLs im Voraus vorbereiten (und kennen), da Sie eine bestimmte GUID für den Streaminglocator erzwingen und dann den Manifestnamen für die Liveausgabe festlegen können.

Angenommen, Sie möchten GUID 1a7ed69e-a361-433d-8a56-29c61872744f für die Liveausgabe verwenden, die Sie morgen erstellen möchten. Wenn der Tag gekommen ist, starten Sie das Liveereignis und erstellen eine Liveausgabe. Sie können sich entscheiden, „conference1“ für das Manifest zu verwenden und die GUID für den Locator zu erzwingen.

Die Streaming-URL ist vorhersagbar und lautet http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Sie können die gleiche Liveausgabe oder das gleiche Medienobjekt nicht mehrfach wiederverwenden. Stellen Sie sich die Kombination aus Liveausgabe und Medienobjekt als Bandaufzeichnung vor. Nachdem die Liveausgabe im Medienobjekt aufgezeichnet wurde, können Sie sie nicht für eine andere Aufzeichnung wiederverwenden. Wenn Sie dies tun, kommt es zu einem Blobkonflikt oder zu Überschreibungen. Sofern Sie nicht planen, die Blobs im Speicherkonto vollständig zu bereinigen und das CDN ganz zu löschen, treten Probleme auf. Auch dann treten wahrscheinlich noch Probleme auf, da die Fragmente downstream in den Zwischenspeichern von CDN oder Clientgeräten (z. B. im Browsercache) bereits zwischengespeichert wurden.

Einer der häufigsten Gründe ist, dass der Streamingendpunkt, von dem Sie die Wiedergabe ausführen möchten, nicht den Status „Wird ausgeführt“ aufweist.

In Media Services stellt ein Streamingendpunkt einen dynamischen (Just-In-Time-)Paketerstellungs- und Ursprungsdienst dar, der Ihre Live- und On-Demand-Inhalte direkt in einer Clientplayer-App bereitstellen kann, indem er eins der allgemeinen Streamingmedienprotokolle (HLS oder DASH) verwendet. Zudem sorgt der Streamingendpunkt für eine dynamische (Just-In-Time-)Verschlüsselung zu branchenführenden DRM-Systemen. Weitere Informationen finden Sie unter Streamingendpunkte (Ursprung) in Azure Media Services.

Um Videos für die Wiedergabe durch Clients verfügbar zu machen, erstellen Sie einen Streaminglocator und dann die Streaming-URLs. Der Streaminglocator wird außerdem verwendet, um Streamingrichtlinien anzuwenden, die Regeln für die Verwendung der Mediendateien enthalten.

Um eine Streaming-URL zu erstellen, erstellen Sie zunächst einen Streaminglocator. Anschließend verketten Sie den Hostnamen des Streamingendpunkts und den Pfad des Streaminglocators miteinander.

Mithilfe von Streamingrichtlinien können Sie Streamingprotokolle und Verschlüsselungsoptionen für Ihren Streaminglocator definieren. Media Services v3 bietet einige vordefinierte Streamingrichtlinien. Weitere Informationen finden Sie unter Streamingrichtlinien.

Eine Liste der vordefinierten Richtlinien, die Sie für die ersten Schritte verwenden können, finden Sie unter Streamingrichtlinien.

Stellen Sie sicher, dass Sie am Ende Ihres Pfads (nach dem Bereich /manifest der URL) (format=m3u8-cmaf) verwenden, um den Ursprungsserver des Streamings anzuweisen, HLS-Inhalte für die Nutzung auf nativen Apple iOS-Geräten zurückzugeben. Ausführliche Informationen finden Sie unter Bereitstellung von Inhalten.

Ja, der Media Services-Ursprungsserver (Streamingendpunkt) unterstützt die dynamische Paketerstellung von MP4-Dateien im HLS- oder DASH-Streamingformat. Der Inhalt muss jedoch im Closed-GOP-Format (geschlossene Bildgruppe) codiert werden, mit kurzen GOPs mit einer Dauer von zwei bis sechs Sekunden. Es werden die folgenden Einstellungen empfohlen: GOPs von zwei Sekunden Länge, Keyframeabstand von min. und max. zwei Sekunden, Codierung mit konstanter Bitrate (CBR-Modus). Die meisten Inhalte in diesem Format, die mit dem H264- oder HEVC-Videocodec zusammen mit dem AAC-Audioformat codiert werden, können unterstützt werden. Zusätzliche, vorcodierte Audioformate werden möglicherweise ebenfalls unterstützt, z. B. Dolby DD+.

Um dies zu erreichen, erstellen Sie ein Medienobjekt, laden Sie die vorcodierten Medienobjekte mithilfe von Azure Blob-Storage-Client-SDKs in den Container des Medienobjekts hoch und generieren dann die erforderlichen Servermanifest- (.ism) und Clientmanifestdateien. Einzelheiten finden Sie im .NET-Beispielprojekt Stream existing MP4 files (Streamen vorhandener MP4-Dateien).

Beachten Sie, dass dieser Ansatz Auswirkungen auf die Leistung hat, da der integrierte Encoder in Azure Media Services auch binäre Indizes (MPI-Dateien) generiert, die die Zugriffszeit auf die MP4-Dateien verbessern. Ohne diese Dateien belastet der Server bei hoher Auslastung die CPU möglicherweise etwas stärker. Weitere Informationen finden Sie unter Streamen einer vorhandenen MP4-Datei mit einheitlicher Bitrate mit HLS oder Dash.

Wenn Sie bei diesem Ansatz zentral hochskalieren, sollten Sie die CPU-Last des Streamingendpunkts überwachen. Wenn Sie planen, mit einer großen Bibliothek von MP4-Dateien, die außerhalb von Azure Media Services vorcodiert wurden, in die Produktion zu gehen, öffnen Sie ein Supportticket, um Ihre Architektur überprüfen zu lassen und nach Möglichkeiten zu fragen, die Leistung des Ursprungsservers der vorcodierten MP4-Inhalte zu verbessern.

Streaminglocators, die mit der v2-API erstellt wurden, funktionieren weiterhin, nachdem die v2-API deaktiviert wurde. Sobald die Streaminglocatordaten in der Back-End-Datenbank von Media Services erstellt wurden, besteht keine Abhängigkeit von der v2-REST-API für das Streaming. V2-spezifische Datensätze werden nicht aus der Datenbank entfernt, wenn v2 im Februar 2024 deaktiviert wird.

Es gibt einige Eigenschaften von Objekten und Locators, die mit v2 erstellt wurden, auf die die neue v3-API nicht zugreifen und die sie nicht aktualisieren kann. Beispielsweise bietet v2 eine Asset Files-API, die in der v3-API über kein Pendant verfügt. Für die meisten unserer Kunden stellt dies kein Problem dar, da diese Funktion nicht häufig genutzt wird und Sie alte Locators weiterhin streamen und löschen können, wenn sie nicht mehr benötigt werden.

Nach der Migration sollten Sie keine Aufrufe an die v2-API ausführen, um Streaminglocators oder -Objekte zu ändern.

Die dynamische Verschlüsselung schützt Ihre Medien ab dem Zeitpunkt, an dem sie Ihren Computer verlassen, während des gesamten Prozesses der Speicherung, Verarbeitung und Übermittlung. Mit Media Services können Sie Ihre zu übermittelnden Live- und On-Demand-Inhalte dynamisch mit Advanced Encryption Standard (AES-128) oder einem der drei wichtigsten DRM-Systeme verschlüsseln: Microsoft PlayReady, Google Widevine und Apple FairPlay. Weitere Informationen finden Sie unter Inhaltsschutz mit der dynamischen Verschlüsselung von Media Services.

Kunden fragen sich oft, ob sie die AES-Verschlüsselung oder ein DRM-System verwenden sollten. Der Hauptunterschied zwischen den beiden Systemen besteht darin, dass bei der AES-Verschlüsselung der Inhaltsschlüssel per TLS an den Client übertragen wird. Der Schlüssel wird während der Übertragung ohne zusätzliche Verschlüsselung („als Klartext“) verschlüsselt. So kann der Schlüssel zur Entschlüsselung des Inhalts für den Clientplayer zugänglich gemacht und in einer Netzwerkablaufverfolgung auf dem Client als unverschlüsselter Text angezeigt werden. Die Verschlüsselung mit einem unverschlüsselten AES-128-Schlüssel eignet sich für Anwendungsfälle, in denen der Betrachter vertrauenswürdig ist (z.B. bei Unternehmensvideos, die innerhalb eines Unternehmens verteilt und von Mitarbeitern angesehen werden).

DRM-Systeme wie PlayReady, Widevine und FairPlay bieten eine zusätzliche Verschlüsselungsebene für den Schlüssel, der zum Entschlüsseln des Inhalts verwendet wird (im Vergleich zu einem unverschlüsselten AES-128-Schlüssel). Der Inhaltsschlüssel wird zusätzlich zur Verschlüsselung auf Übertragungsebene, die von TLS bereitgestellt wird, mit einem durch die DRM-Runtime geschützten Schlüssel verschlüsselt. Die Entschlüsselung erfolgt in einer sicheren Umgebung auf Betriebssystemebene, wo ein Angriff durch einen böswilligen Benutzer schwieriger auszuführen ist. DRM wird für Anwendungsfälle empfohlen, in denen der Betrachter möglicherweise nicht vertrauenswürdig ist und Sie ein Höchstmaß an Sicherheit benötigen.

Sie müssen keinen bestimmten Tokenanbieter wie Azure Active Directory (Azure AD) verwenden. Sie können einen eigenen JWT-Anbieter (einen sogenannten Sicherheitstokendienst oder STS) erstellen und dabei eine Verschlüsselung mit asymmetrischem Schlüssel verwenden. Sie können in Ihrem benutzerdefinierten Sicherheitstokendienst Ansprüche basierend auf Ihrer Geschäftslogik hinzufügen.

Stellen Sie sicher, dass der Aussteller, die Zielgruppe und die Ansprüche genau dem Inhalt des JWT und dem Wert ContentKeyPolicyRestriction in ContentKeyPolicy entsprechen.

Weitere Informationen finden Sie unter Inhaltsschutz mit der dynamischen Verschlüsselung von Media Services.

Für die Produktion benötigen Sie einen Sicherheitstokendienst (Webdienst), der bei einer HTTPS-Anforderung ein JWT-Token ausgibt. Zum Testen können Sie den in der GetTokenAsync-Methode angegebenen Code verwenden, der in Program.cs definiert ist.

Nach der Authentifizierung eines Benutzers fordert der Player ein solches Token beim STS an und weist dieses als Wert des Tokens zu. Sie können die Azure Media Player-API verwenden.

Ein Beispiel für die Ausführung des STS mit einem symmetrischen oder einem asymmetrischen Schlüssel finden Sie im JWT-Tool. Ein Beispiel für einen Player, der auf Azure Media Player basiert und ein solches JWT-Token verwendet, finden Sie im Azure-Medientesttool. (Erweitern Sie den Link player_settings, um die Tokeneingabe anzuzeigen.)

Der richtige Ansatz ist die Nutzung von eines Sicherheitstokendiensts. Fügen Sie im STS je nach Benutzerprofil unterschiedliche Ansprüche hinzu (z. B. „Premium-Benutzer“, „Basic-Benutzer“ oder „Benutzer der kostenlosen Testversion“). Bei unterschiedlichen Ansprüchen in einem JWT kann der Benutzer unterschiedliche Inhalte sehen. Für andere Inhalte oder Medienobjekte weist ContentKeyPolicyRestriction den entsprechenden Wert für RequiredClaims auf.

Verwenden Sie die Azure Media Services-APIs für die Konfiguration von Lizenzen/Schlüsselbereitstellungen und die Verschlüsselung Ihrer Objekte (siehe dieses Beispiel).

Dieses Verhalten scheint durch den Entwurf der Beispielanwendung bedingt zu sein. Wenn ein alternativer Audiotitel vorhanden ist (was bei HLS der Fall ist), verwenden sowohl iOS 10 als auch iOS 11 im Offlinemodus standardmäßig den alternativen Audiotitel. Um dieses Verhalten im FPS-Offlinemodus zu kompensieren, entfernen Sie den alternativen Audiotitel aus dem Datenstrom. Um dies für Media Services zu erreichen, fügen Sie den dynamischen Manifestfilter audio-only=false hinzu. Eine HLS-URL endet somit mit .ism/manifest(format=m3u8-aapl,audio-only=false) .

Je nach Cacheschlüsseldesign für das Content Delivery Network wird der Inhalt möglicherweise zwischengespeichert. Löschen Sie den Cacheinhalt.

Die heruntergeladene Dateistruktur auf einem iOS-Gerät sieht aus wie auf dem folgenden Screenshot. Im Ordner _keys sind heruntergeladene FPS-Lizenzen gespeichert, wobei für jeden Lizenzdiensthost eine Speicherdatei verwendet wird. Im Ordner .movpkg sind Audio- und Videoinhalte gespeichert.

Der erste Ordner mit einem Namen, der mit einem Bindestrich gefolgt von einer Zahl endet, weist Videoinhalte auf. Der numerische Wert ist die Spitzenbandbreite der Videowiedergabe. Der zweite Ordner mit einem Namen, der mit einem Bindestrich endet, auf den „0“ folgt, enthält Audioinhalte. Der dritte Ordner namens Data enthält die Hauptwiedergabeliste der FPS-Inhalte. Schließlich enthält boot.xml eine vollständige Beschreibung des Inhalts des Ordners .movpkg.

Beispiel für die Datei „boot.xml“:

<?xml version="1.0" encoding="UTF-8"?>
<HLSMoviePackage xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://apple.com/IMG/Schemas/HLSMoviePackage" xsi:schemaLocation="http://apple.com/IMG/Schemas/HLSMoviePackage /System/Library/Schemas/HLSMoviePackage.xsd">
  <Version>1.0</Version>
  <HLSMoviePackageType>PersistedStore</HLSMoviePackageType>
  <Streams>
    <Stream ID="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" Path="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(127000)/Manifest(aac_eng_2_127,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
    <Stream ID="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" Path="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(161000)/Manifest(video,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
  </Streams>
  <MasterPlaylist>
    <NetworkURL>https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/manifest(format=m3u8-aapl,audio-only=false)</NetworkURL>
  </MasterPlaylist>
  <DataItems Directory="Data">
    <DataItem>
      <ID>CB50F631-8227-477A-BCEC-365BBF12BCC0</ID>
      <Category>Playlist</Category>
      <Name>master.m3u8</Name>
      <DataPath>Playlist-master.m3u8-CB50F631-8227-477A-BCEC-365BBF12BCC0.data</DataPath>
      <Role>Master</Role>
    </DataItem>
  </DataItems>
</HLSMoviePackage>

Da Media Services v3 ein Medienobjekt mit mehreren StreamingLocator-Instanzen zulässt, können folgende Elemente zur gleichen Zeit vorhanden sein:

• Eine ContentKeyPolicy-Instanz mit license_type = "persistent", ContentKeyPolicyRestriction mit Anspruch auf "persistent" und ihre StreamingLocator-Instanz.
• Eine weitere ContentKeyPolicy-Instanz mit license_type="nonpersistent", ContentKeyPolicyRestriction mit Anspruch auf "nonpersistent„ und ihre StreamingLocator-Instanz.
• Zwei StreamingLocator-Instanzen mit unterschiedlichen ContentKey-Werten.

Abhängig von der Geschäftslogik des benutzerdefinierten STS werden unterschiedliche Ansprüche im JWT-Token ausgegeben. Mit dem Token kann nur die dazugehörige Lizenz abgerufen und nur die entsprechende URL wiedergegeben werden.

In der Widevine DRM-Architekturübersicht von Google sind drei verschiedene Sicherheitsstufen definiert. In der Azure Media Services-Dokumentation zur Widevine-Lizenzvorlage werden jedoch fünf Sicherheitsstufen (Clientstabilitätsanforderungen für die Wiedergabe) beschrieben.

Google Widevine definiert beide Sicherheitsstufen. Der Unterschied besteht in der Nutzungsebene: Architektur oder API. Die fünf Sicherheitsstufen werden in der Widevine-API verwendet. Der Widevine-Lizenzdienst von Azure Media Services deserialisiert das content_key_specs-Objekt, das security_level enthält, und übergibt es an den globalen Widevine-Übermittlungsdienst. Die folgende Tabelle zeigt die Zuordnung zwischen den beiden Gruppen von Sicherheitsstufen.

Verwenden Sie Azure Monitor, um nachzuverfolgen, was mit Ihren Media Services-Ressourcen geschieht. Weitere Informationen finden Sie unter Überwachen von Media Services. „Gewusst-wie“-Anleitungen werden am Ende der Seite aufgelistet.

Verwenden Sie Azure Event Grid, um Ihr Liveereignis ohne einen Abrufdienst zu überwachen. Weitere Informationen finden Sie unter Erstellen und Überwachen von Media Services-Ereignissen mit Event Grid mithilfe der Azure-Portal.

Media Services funktioniert mit vielen Playern. Sehen Sie sich die Liste der kompatiblen Mediaplayer an, oder probieren Sie die Beispiele für Player von Drittanbietern aus.

Weitere Informationen zu Media Services und Hochverfügbarkeit finden Sie unter Hochverfügbarkeit bei Media Services und Video on Demand (VoD).

Wir haben einen umfassenden Leitfaden für die Migration von v2 zu v3 erstellt. Wir sind daran interessiert, mehr über Ihre Migrationserfahrung und Ihre Anforderungen zu erfahren. Senden Sie uns daher gerne Ihr Feedback über ein GitHub-Problem oder Supportticket.

Wir haben Fehlercodes in den folgenden Referenzen dokumentiert: Fehlercodes für Streamingendpunkte, Fehlercodes für Liveereignisse und Fehlercodes für Aufträge. Wenn Sie dort keine Antworten finden, erstellen Sie ein Supportticket.

Sie können Ihre Kontoanmeldeinformationen mithilfe der Azure-CLI zurücksetzen.

Weitere Informationen finden Sie unter den Preisinformationen zu Media Services.

Weitere Informationen finden Sie unter Media Services: Kontingente und Grenzwerte.

Kunden fügen ihren Azure Media Services-Konten ihre eigenen Speicherkonten an. Alle Medienobjektdaten werden in diesen zugeordneten Speicherkonten gespeichert, und der Kunde steuert den Standort und den Replikationstyp dieses Speichers.

Zusätzliche Daten, die dem Media Services Konto zugeordnet sind (einschließlich Inhaltsverschlüsselungsschlüssel, Tokenüberprüfungsschlüssel, JobInputHttp-URLs und andere Entitätsmetadaten), werden in Microsoft-eigenem Speicher innerhalb der Region gespeichert, die für das Media Services-Konto ausgewählt ist.

Aufgrund der Anforderungen an die Datenresidenz in den Regionen „Brasilien, Süden“ und „Asien, Südosten“ werden zusätzliche Kontodaten auf zonenredundante Weise gespeichert und sind in einer einzigen Region enthalten. Für Asien, Südosten, werden alle zusätzlichen Kontodaten in Singapur gespeichert. Für Brasilien, Süden, erfolgt die Speicherung der Daten in Brasilien. In anderen Regionen als „Brasilien, Süden“ und „Asien, Südosten“ können die zusätzlichen Kontodaten auch in Microsoft-eigenem Speicher im Regionspaar gespeichert sein.

Azure Media Services ist ein regionaler Dienst und bietet keine Hochverfügbarkeit oder Datenreplikation. Wir empfehlen Kunden, die diese Features benötigen, eine Lösung mithilfe von Media Services-Konten in mehreren Regionen zu erstellen. Ein Beispiel für das Erstellen einer Lösung für hohe Verfügbarkeit mit Video on Demand (VoD) von Media Services ist als Leitfaden verfügbar.