Veelgestelde vragen over Azure Media Services

Zie de handleiding voor buitengebruikstelling van Azure Media Services

Hier volgt een overzicht:

• OpenAPI-specificatie (Swagger)
• Azure-CLI
• .NET
• Java
• Python
• Node.js
• Go

Het is niet raadzaam om de REST API voor Media Services rechtstreeks in uw eigen bibliotheekcode te verpakken. Als u dit op de juiste manier doet voor productiedoeleinden, moet u de volledige Logica voor opnieuw proberen van Azure Resource Manager implementeren en begrijpen hoe u langlopende bewerkingen in Resource Manager API's beheert. De client-SDK's voor verschillende talen, zoals .NET, Java, TypeScript, Python en Ruby, verwerken dit automatisch voor u om de kans te verkleinen op problemen met logica voor opnieuw proberen of mislukte API-aanroepen.

Zie de voorbeeldpagina's. Er zijn voorbeelden voor Accounts, Assets, Live Streaming, VOD Streaming, Content Protection, Encoding, Analytics en using Players.

Wanneer u paginering gebruikt, moet u altijd de volgende koppeling gebruiken om de verzameling op te sommen en niet afhankelijk te zijn van een bepaald paginaformaat. Zie Entiteiten filteren, ordenen en paggineren voor meer informatie en voorbeelden.

Zie de zelfstudie Een Key Vault sleutel gebruiken om gegevens te versleutelen in een Media Services-account voor informatie over het gebruik van de Azure CLI om Media Services te koppelen aan Azure Key Vault om uw gegevens te versleutelen.

Als u wilt dat Media Services toegang heeft tot een opslagaccount wanneer het opslagaccount is geconfigureerd om aanvragen van onbekende IP-adressen te blokkeren, volgt u de stappen in Opslag openen met een beheerde Media Services-identiteit.

Zie Een Media Services-account verplaatsen tussen abonnementen.

Zie Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor Media Services-accounts.

Media Services definieert de volgende ingebouwde rollen:

• Media Services-accountbeheerder
• Media Services Media Operator
• Media Services-beleidsbeheerder
• Beheerder van Media Services-streaming-eindpunten
• Beheerder van Media Services-livegebeurtenissen

Deze rollen worden beschreven in Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) voor Media Services-accounts.

Deze rollen kunnen worden gebruikt om nauwkeurige toegang te geven tot een Media Services-account. Als u alle toegang tot een Media Services-account wilt toestaan, kan de rol 'Eigenaar' of 'Inzender' worden gebruikt. Media Services heeft een oudere API op het afschaffingspad die geen ondersteuning biedt voor fijnmazig toegangsbeheer. Klanten die fijnmazig toegangsbeheer nodig hebben, moeten klassieke API's inschakelen niet selecteren bij het maken van een Media Services-account via de portal (of de API-versie 2020-05-01 gebruiken als ze de API gebruiken om accounts te maken).

De volgende ingebouwde Azure Policy kunnen worden gebruikt om het maken van accounts te blokkeren die ondersteuning bieden voor de oude API: Azure Media Services-accounts die toegang tot de verouderde v2-API toestaan, moeten worden geblokkeerd - Microsoft Azure

Een Media Services-asset is een Azure Storage-accountcontainer die wordt gebruikt voor elk videobestand dat u uploadt. Het heeft een unieke id die wordt gebruikt met transformaties en andere bewerkingen. Zie Assets in Azure Media Services v3.

Telkens wanneer u een mediabestand wilt uploaden en er iets mee wilt doen, zoals coderen of streamen, maakt u een asset om het mediabestand en de bijbehorende bestanden op te slaan. Assets worden automatisch voor u gemaakt als u de Azure Portal gebruikt. Als u de portal niet gebruikt om bestanden te uploaden, moet u eerst een asset maken.

De algemene coderingsindelingen zijn beschikbaar met Media Services Standard Encoder. Zie Standard Encoder-indelingen en -codecs voor een lijst met alle indelingen.

U kunt een taak maken in de Azure Portal met behulp van de Azure CLI, REST of een van de SDK's. Zie de Media Services-voorbeelden voor de gewenste taal.

Ja. Zie Coderen met een automatisch gegenereerde bitrate ladder.

Ja. Media Services kan een tweeledige analyse uitvoeren op een video. Vervolgens kunnen de beste adaptieve bitrate-set, resoluties en coderingsinstellingen worden aanbevolen op basis van de inhoud van de video.

Ja. Voor meer informatie en koppelingen naar een voorbeeldtoepassing die laat zien hoe u een MP4-bestand met één bitsnelheid uploadt dat vooraf is gecodeerd en het servermanifest (.ism) en clientmanifest (.ismc) genereert, raadpleegt u het antwoord op de vraag 'Kan ik bestaande MP4-bestanden streamen die vooraf zijn gecodeerd of gecodeerd in een andere oplossing?' in de sectie over verpakking en levering. Dit antwoord beschrijft ook de invloed op de prestaties van de oorsprong.

We raden het niet aan. Zeer korte inhoud die minder dan een minuut of twee duurt, is niet ideaal voor adaptive bitrate streaming. Als u bestanden van zeer korte vorm wilt streamen, raden we u aan de inhoud vooraf te coderen in een indeling die eenvoudig kan worden gestreamd met behulp van één bitrate.

Omdat de meeste adaptieve bitrate-spelers tijd nodig hebben om meerdere videosegmenten te bufferen, evenals tijd om de netwerkbandbreedte te analyseren voordat ze omhoog of omlaag gaan op de adaptieve bitsnelheidsladder, is het vaak nutteloos om veel bitrates te bieden voor inhoud die minder dan 30 seconden lang is. Tegen de tijd dat de speler zijn heuristische algoritme vergrendelt op de juiste bitsnelheid om af te spelen op basis van netwerkomstandigheden, is het bestand gestreamd.

Bovendien bufferen sommige spelers standaard maximaal drie videosegmenten. Elk segment kan twee tot zes seconden lang zijn. Voor video's met een zeer korte indeling zal de speler waarschijnlijk bufferen en beginnen met het afspelen van de eerste geselecteerde bitsnelheid van de adaptieve bitsnelheidset. Daarom raden we u aan een MP4-bestand met één bitsnelheid te gebruiken en dit te uploaden naar een asset als u HLS- of DASH-manifestgeneratie nodig hebt. Voor meer informatie over hoe u dit kunt bereiken, raadpleegt u het antwoord op de vraag 'Kan ik bestaande MP4-bestanden streamen die vooraf zijn gecodeerd of gecodeerd in een andere oplossing?' in de sectie over verpakking en levering.

U hoeft de bestanden alleen in HLS- of DASH-indeling te leveren als u wilt profiteren van de mogelijkheden van deze protocollen. Voor single-bitrate streams kunnen ze nog steeds veel bieden, zoals sneller zoeken, DRM-ondersteuning (Digital Rights Management) en meer moeite om te downloaden via URL (maar nog steeds mogelijk!) dan een progressieve download MP4 in blob-opslag. Ondersteuning voor ondertiteling voor VTT en IMSC1 is een ander voordeel. Bovendien maakt de mogelijkheid om extra audioweergaven of nasynchronisaties in alternatieve talen te binden, dit voor sommige situaties een waardevolle keuze.

Als u op zoek bent naar manieren om een Media Services-encoder te gebruiken om dingen te doen zoals een video draaien, een video subclip maken, video's samenvoegen, miniaturen en sprites maken, staan er veel codevoorbeelden op de pagina Codevoorbeelden . Beschikbare voorbeeldtalen zijn Node.JS, Python, .NET en Java.

Een Media Services-livegebeurtenis is het proces van het opnemen van livevideofeeds en het uitzenden ervan via een RTMPS-protocol of Smooth Streaming. Zie Livegebeurtenissen en live-uitvoer in Media Services voor meer informatie.

De eerste stap is het kiezen van een on-premises encoder. We hebben voorbeelden gegeven voor het maken van een livegebeurtenis met Wirecast en OBS. Zie Typen livegebeurtenissen als u liever begint met een overzicht van Media Services-livegebeurtenissen.

Azure Media Service levert video, audio en tekst in verschillende protocollen. Wanneer u uw livestream publiceert met behulp van MPEG-DASH of HLS/CMAF, levert de service samen met video en audio de getranscribeerde tekst in IMSC1.1-compatibele TTML. Zie Livetranscriptie voor meer informatie.

U kunt livegebeurtenissen controleren door u te abonneren op Azure Event Grid gebeurtenissen. Zie het Event Grid-gebeurtenisschema voor meer informatie. U hebt de volgende mogelijkheden:

• Abonneer u op de gebeurtenissen Microsoft.Media.LiveEventEncoderDisconnected op streamniveau en controleer of er een tijdje geen nieuwe verbindingen meer zijn om uw livegebeurtenis te stoppen en te verwijderen.
• Abonneer u op de heartbeat-gebeurtenissen op trackniveau. Als alle sporen een binnenkomende bitrate hebben die daalt naar 0 of als het laatste tijdstempel niet meer toeneemt, kunt u de livegebeurtenis veilig afsluiten. De heartbeat-gebeurtenissen komen elke 20 seconden binnen voor elk nummer, dus het kan een beetje uitgebreid zijn.

Nee, u kunt niet eenvoudig dezelfde streaming-URL gebruiken als u een livegebeurtenis stopt en start. Telkens wanneer u een nieuwe live-uitvoer (en asset) maakt en publiceert, wordt er een nieuwe streaming-URL (GUID) gebruikt voor de nieuwe locator. Op die manier weet u zeker dat er geen cacheconflicten zijn in het streaming-eindpunt en het Content Delivery Network (CDN). U kunt de streaming-URL's van tevoren voorbereiden (en weten), omdat u een specifieke GUID voor de streaming-locator kunt afdwingen en vervolgens de manifestnaam kunt bepalen die moet worden gebruikt voor de live-uitvoer.

Stel dat u besluit guid 1a7ed69e-a361-433d-8a56-29c61872744f te gebruiken voor de live-uitvoer die u morgen gaat maken. Wanneer de dag komt, start u de livegebeurtenis en maakt u een live-uitvoer. U kunt besluiten om 'conference1' te gebruiken voor het manifest en de GUID voor de locator af te dwingen.

De streaming-URL is voorspelbaar en is http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

U kunt dezelfde live-uitvoer of asset niet meerdere keren opnieuw gebruiken. Beschouw de combinatie van de live-uitvoer en asset als een tape-opname. Nadat de live-uitvoer naar de asset is vastgelegd, kunt u deze niet opnieuw gebruiken voor een andere opname. Er treedt een blobconflict op of overschrijft als u dat opnieuw doet. Tenzij u van plan bent om de blobs in het opslagaccount volledig te verwijderen en het CDN volledig op te leegen, zijn er problemen. Er zijn waarschijnlijk nog steeds problemen omdat de fragmenten al downstream zijn opgeslagen in de cache op het CDN of in de cache van clientapparaten (bijvoorbeeld de browsercache).

Een van de meest voorkomende redenen is dat u niet het streaming-eindpunt hebt van waaruit u probeert af te spelen in de actieve status.

In Media Services vertegenwoordigt een streaming-eindpunt een dynamische (Just-In-Time)-pakket- en origin-service die uw live- en on-demand inhoud rechtstreeks aan een clientspeler-app kan leveren met behulp van een van de algemene protocollen voor streaming media (HLS of DASH). Daarnaast biedt het streaming-eindpunt dynamische (Just-In-Time) versleuteling voor toonaangevende DRM-systemen. Zie Streaming-eindpunten (origin) in Azure Media Services voor meer informatie.

Als u video's beschikbaar wilt maken voor clients om af te spelen, maakt u een streaming-locator en bouwt u vervolgens streaming-URL's. Streaming-locators worden ook gebruikt om streamingbeleid toe te passen dat regels bevat voor de wijze waarop de mediabestanden worden gebruikt.

Als u een streaming-URL wilt maken, maakt u eerst een streaming-locator. Vervolgens voegt u de hostnaam van het streaming-eindpunt en het pad van de streaming-locator samen.

Met streamingbeleid kunt u streamingprotocollen en versleutelingsopties definiëren voor uw streaming-locators. Media Services v3 biedt een aantal vooraf gedefinieerde beleidsregels voor streaming. Zie Streaming-beleid voor meer informatie.

Zie Streamingbeleid voor een lijst met vooraf gedefinieerde beleidsregels die u kunt gebruiken om aan de slag te gaan.

Zorg ervoor dat u (format=m3u8-cmaf) aan het einde van uw pad (na het / manifest-gedeelte van de URL) hebt om de streaming-oorsprongserver te vertellen HLS-inhoud te retourneren voor gebruik op Apple iOS-apparaten. Zie Content leveren voor meer informatie.

Ja, de Media Services-oorsprongserver (streaming-eindpunt) ondersteunt dynamisch verpakken van MP4-bestanden naar HLS- of DASH-streaming-indeling. De inhoud moet echter worden gecodeerd in closed-GOP-indeling, met korte GOPs in het duurbereik van twee tot zes seconden. We raden de volgende instellingen aan: GOPs van twee seconden, sleutelframe maximum en minimale afstand van twee seconden, constante bitrate codering (CBR-modus). De meeste inhoud in deze indeling die is gecodeerd via H.264- of HEVC-videocodec, samen met AAC-audio-indeling, kan worden ondersteund. Aanvullende audio-indelingen die vooraf zijn gecodeerd, kunnen ook worden ondersteund, zoals Dolby DD+.

De sleutel om dit te laten werken, is het maken van een asset, het uploaden van de vooraf gecodeerde assets naar de container van de asset met behulp van Azure Blob Storage client-SDK's en vervolgens het vereiste servermanifest (.ism) en clientmanifestbestanden genereren. Zie het .NET-voorbeeldproject in bestaande MP4-bestanden van Stream voor meer informatie.

Houd er rekening mee dat er gevolgen zijn voor de prestaties wanneer u deze benadering gebruikt, omdat de ingebouwde encoder in Media Services ook binaire indexen (MPI-bestanden) genereert die de toegangstijd tot de MP4-bestanden verbeteren. Zonder deze bestanden kan de server iets meer CPU gebruiken bij hoge belasting. Zie Streaming an existing single bitrate MP4 file with HLS or Dash (Een bestaand MP4-bestand met één bitrate streamen met HLS of Dash) voor meer informatie.

Wanneer u met deze methode omhoog schaalt, moet u de CPU-belasting van het streaming-eindpunt controleren. Als u van plan bent om naar productie te gaan met een grote bibliotheek met MP4-bestanden die vooraf zijn gecodeerd buiten Media Services, dient u een ondersteuningsticket in om uw architectuur te laten beoordelen en vraagt u naar manieren om de prestaties van de oorspronkelijke server van vooraf gecodeerde MP4-inhoud te verbeteren.

Streaming-locators die zijn gemaakt met v2-API, blijven werken nadat onze v2-API is uitgeschakeld. Zodra de streaming-locatorgegevens zijn gemaakt in de back-enddatabase van Media Services, is er geen afhankelijkheid van de v2 REST API voor streaming. We verwijderen v2-specifieke records niet uit de database wanneer v2 is uitgeschakeld in februari 2024.

Er zijn enkele eigenschappen van assets en locators die met v2 zijn gemaakt en die niet kunnen worden geopend of bijgewerkt met de nieuwe v3-API. Met v2 wordt bijvoorbeeld een Asset Files-API weergegeven die geen gelijkwaardige functie in de v3-API heeft. Vaak is dit geen probleem voor de meeste van onze klanten, omdat het geen veelgebruikte functie is en u nog steeds oude locators kunt streamen en verwijderen wanneer ze niet meer nodig zijn.

Na de migratie moet u voorkomen dat u de v2-API aanroept om streaming-locators of assets te wijzigen.

Dynamische versleuteling beveiligt uw media vanaf het moment dat deze uw computer verlaat, tot en met opslag, verwerking en levering. Met Media Services kunt u uw live en on-demand inhoud dynamisch versleuteld leveren met Advanced Encryption Standard (AES-128) of een van de drie belangrijkste DRM-systemen: Microsoft PlayReady, Google Widevine en Apple FairPlay. Zie Uw inhoud beveiligen met dynamische versleuteling van Media Services voor meer informatie.

Klanten vragen zich vaak af of ze AES-versleuteling of een DRM-systeem moeten gebruiken. Het belangrijkste verschil tussen de twee systemen is dat met AES-versleuteling de inhoudssleutel via TLS naar de client wordt verzonden. De sleutel wordt tijdens overdracht versleuteld zonder extra versleuteling ('in the clear'). Als gevolg hiervan is de sleutel die wordt gebruikt voor het ontsleutelen van de inhoud toegankelijk voor de clientspeler en kan deze worden weergegeven in een netwerktracering op de client in tekst zonder opmaak. AES-128 clear key encryption is geschikt voor gebruiksvoorbeelden waarbij de kijker een vertrouwde partij is (bijvoorbeeld het versleutelen van bedrijfsvideo's die binnen een bedrijf worden gedistribueerd om door werknemers te worden bekeken).

DRM-systemen zoals PlayReady, Widevine en FairPlay bieden een extra versleutelingsniveau voor de sleutel die wordt gebruikt om de inhoud te ontsleutelen, vergeleken met een AES-128 clear-sleutel. De inhoudssleutel wordt versleuteld naar een sleutel die wordt beveiligd door de DRM-runtime, naast eventuele versleuteling op transportniveau die TLS biedt. Ontsleuteling wordt afgehandeld in een veilige omgeving op het niveau van het besturingssysteem, waar het moeilijker is voor een kwaadwillende gebruiker om aan te vallen. We raden DRM aan voor gebruiksvoorbeelden waarbij de viewer mogelijk geen vertrouwde partij is en u het hoogste beveiligingsniveau nodig hebt.

U hoeft geen specifieke tokenprovider te gebruiken, zoals Azure Active Directory (Azure AD). U kunt uw eigen JWT-provider (de zogenaamde Secure Token Service of STS) maken met behulp van asymmetrische sleutelversleuteling. In uw aangepaste STS kunt u claims toevoegen op basis van uw bedrijfslogica.

Zorg ervoor dat de verlener, doelgroep en claims allemaal exact overeenkomen tussen wat zich in JWT en de ContentKeyPolicyRestriction waarde in ContentKeyPolicy.

Zie Uw inhoud beveiligen met dynamische versleuteling van Media Services voor meer informatie.

Voor productie moet u een beveiligde tokenservice (dat wil gezegd een webservice) hebben, die een JWT-token uitgeeft bij een HTTPS-aanvraag. Voor de test kunt u de code gebruiken die wordt weergegeven in de GetTokenAsync methode die is gedefinieerd in Program.cs.

Nadat een gebruiker is geverifieerd, dient de speler een aanvraag in bij STS voor een dergelijk token en wijst deze toe als de waarde van het token. U kunt de Azure Media Player-API gebruiken.

Zie het JWT-hulpprogramma voor een voorbeeld van het uitvoeren van STS met een symmetrische sleutel of een asymmetrische sleutel. Voor een voorbeeld van een speler op basis van Azure Media Player die gebruikmaakt van een dergelijk JWT-token, raadpleegt u het hulpprogramma Azure-mediatest. (Vouw de koppeling player_settings uit om de tokeninvoer te zien.)

De juiste aanpak is om Secure Token Service te gebruiken. Voeg in STS, afhankelijk van het gebruikersprofiel, verschillende claims toe (zoals 'Premium User', 'Basic User' of 'Free Trial User'). Met verschillende claims in een JWT kan de gebruiker verschillende inhoud zien. Voor verschillende inhoud of assets, ContentKeyPolicyRestriction heeft de bijbehorende RequiredClaims waarde.

Gebruik Azure Media Services-API's voor het configureren van de levering van licenties/sleutels en het versleutelen van uw assets (zoals weergegeven in dit voorbeeld).

Dit gedrag lijkt te komen door het ontwerp van de voorbeeld-app. Wanneer een alternatief audiospoor aanwezig is (wat het geval is voor HLS) tijdens de offlinemodus, worden zowel iOS 10 als iOS 11 standaard ingesteld op het alternatieve audiospoor. Verwijder het alternatieve audiospoor uit de stream om dit gedrag in de offlinemodus van fps te compenseren. Als u dit wilt doen op Media Services, voegt u het dynamische manifestfilter audio-only=false toe. Met andere woorden, een HLS-URL eindigt op .ism/manifest(format=m3u8-aapl,audio-only=false).

Afhankelijk van het cachesleutelontwerp voor het netwerk voor inhoudslevering, kan de inhoud in de cache worden opgeslagen. De cache leegmaken.

De gedownloade bestandsstructuur op een iOS-apparaat ziet er als volgt uit. In de map _keys worden gedownloade FPS-licenties opgeslagen, met één opgeslagen bestand voor elke host van de licentieservice. In de map .movpkg wordt audio- en video-inhoud opgeslagen.

De eerste map met een naam die eindigt op een streepje gevolgd door een getal bevat video-inhoud. De numerieke waarde is de piekbandbreedte van de videoweergaven. De tweede map met een naam die eindigt op een streepje gevolgd door 0 bevat audio-inhoud. De derde map met de naam Gegevens bevat de hoofdafspeellijst van de FPS-inhoud. Ten slotte biedt boot.xml een volledige beschrijving van de inhoud van de .movpkg-map .

Hier volgt een voorbeeld van een boot.xml-bestand:

<?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>

Omdat Media Services v3 toestaat dat een asset meerdere StreamingLocator exemplaren heeft, kunt u het volgende hebben:

• Eén ContentKeyPolicy exemplaar met license_type = "persistent", ContentKeyPolicyRestriction met een claim op "persistent"en het bijbehorende StreamingLocator exemplaar.
• Een ander ContentKeyPolicy exemplaar met license_type="nonpersistent", ContentKeyPolicyRestriction met een claim op "nonpersistent', en het bijbehorende StreamingLocator exemplaar.
• Twee StreamingLocator exemplaren met verschillende ContentKey waarden.

Afhankelijk van de bedrijfslogica van aangepaste STS worden verschillende claims uitgegeven in het JWT-token. Met het token kan alleen de bijbehorende licentie worden verkregen en kan alleen de bijbehorende URL worden afgespeeld.

Het overzicht van De Widevine DRM-architectuur van Google definieert drie beveiligingsniveaus. De Documentatie van Azure Media Services over de Widevine-licentiesjabloon bevat echter een overzicht van vijf beveiligingsniveaus (robuustheidsvereisten voor clients voor afspelen).

Google Widevine definieert beide sets beveiligingsniveaus. Het verschil zit in het gebruiksniveau: architectuur of API. De vijf beveiligingsniveaus worden gebruikt in de Widevine-API. De Azure Media Services Widevine-licentieservice deserialisatie van het content_key_specs object, dat , bevat security_level, en geeft het door aan de wereldwijde leveringsservice van Widevine. In de volgende tabel ziet u de toewijzing tussen de twee sets beveiligingsniveaus.

Gebruik Azure Monitor om bij te houden wat er gebeurt met uw Media Services-resources. Zie Media Services bewaken voor meer informatie. Hulplijnen voor instructies worden aan het einde van de pagina weergegeven.

Gebruik Azure Event Grid om uw livegebeurtenis te bewaken zonder pollingservice. Zie Media Services-gebeurtenissen maken en bewaken met Event Grid met behulp van de Azure Portal.

Media Services werkt met veel spelers. Bekijk de lijst met compatibele mediaspelers of probeer de voorbeelden van spelers van derden.

Zie Hoge beschikbaarheid met Media Services en Video on Demand (VOD) voor informatie over Media Services en hoge beschikbaarheid.

We hebben een uitgebreide handleiding gemaakt voor migratie van v2 naar v3. We willen graag weten wat uw migratie-ervaring en -behoeften zijn, dus u kunt feedback geven via een GitHub-probleem of ondersteuningsticket.

We hebben foutcodes gedocumenteerd in de volgende verwijzingen: Foutcodes voor streaming-eindpunten, Foutcodes voor livegebeurtenissen en Taakfoutcodes. Als u daar geen antwoorden kunt vinden, maakt u een ondersteuningsticket.

U kunt uw accountreferenties opnieuw instellen met behulp van de Azure CLI.

Zie de Media Services-prijshandleiding.

Zie Quota en limieten voor Media Services.

Klanten koppelen hun eigen opslagaccounts aan hun Azure Media Services-accounts. Alle assetgegevens worden opgeslagen in deze gekoppelde opslagaccounts en de klant bepaalt de locatie en het replicatietype van deze opslag.

Aanvullende gegevens die zijn gekoppeld aan een Media Services-account (met inbegrip van inhoudsversleutelingssleutels, tokenverificatiesleutels, JobInputHttp-URL's en andere metagegevens van entiteiten) worden opgeslagen in microsoft-opslag binnen de regio die is geselecteerd voor het Media Services-account.

Vanwege de vereisten voor gegevenslocatie in Brazilië - zuid- en Zuidoost-Azië, worden extra accountgegevens op een zone-redundante manier opgeslagen en zijn ze opgenomen in één regio. Voor Zuidoost-Azië worden alle aanvullende accountgegevens opgeslagen in Singapore. Voor Brazilië - zuid worden de gegevens opgeslagen in Brazilië. In andere regio's dan Brazilië - zuid en Zuidoost-Azië kunnen aanvullende accountgegevens ook worden opgeslagen in opslag die eigendom is van Microsoft in de gekoppelde regio.

Azure Media Services is een regionale service en biedt geen hoge beschikbaarheid of gegevensreplicatie. We raden klanten die deze functies nodig hebben aan om een oplossing te bouwen met behulp van Media Services-accounts in meerdere regio's. Een voorbeeld dat laat zien hoe u een oplossing voor hoge beschikbaarheid bouwt met Media Services-video op aanvraag , is beschikbaar als richtlijn.