Veelvoorkomende vragen over Azure Media Services

Hier is een overzicht:

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

We raden u niet aan om de gegevens voor REST API te Media Services in uw eigen bibliotheekcode. Als u dit voor productiedoeleinden goed doet, moet u de volledige logica voor opnieuw proberen Azure Resource Manager implementeren en inzicht krijgen in het beheren van langlopende bewerkingen in Resource Manager API's. De client-SDK's voor verschillende talen, zoals .NET, Java, TypeScript, Python en Ruby, verwerken dit automatisch voor u, om de kans op problemen met logica voor opnieuw proberen of mislukte API-aanroepen te verminderen. De Postman-verzameling wordt meer aangeboden als een onderwijsprogramma en om u te laten zien wat de client-SDK's op de kabel doen tijdens uw ontwikkeling met deze programma's.

Zie het artikel Media Services v3-voorbeelden voor een lijst met voorbeelden.

Wanneer u paginering gebruikt, moet u altijd de volgende koppeling gebruiken om de verzameling op te semuleren en niet afhankelijk te zijn van een bepaald paginaformaat. Zie Filtering, ordering, and paging en paging entitiesvoor meer informatie en voorbeelden.

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

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

Zie Moving a Media Services account between subscriptions (Een Media Services verplaatsen tussen abonnementen).

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

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 voor het opslaan van het mediabestand en de bijbehorende bestanden. Assets worden automatisch voor u gemaakt als u de Azure Portal. Als u de portal niet gebruikt om bestanden te uploaden, moet u eerst een asset maken. Zie Een asset maken voor meer informatie.

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

U kunt een taak in de Azure Portal met behulp van de Azure CLI,REST of een van de SDK's. Zie de Media Services voor de taal die u wilt gebruiken.

Ja. Zie Coderen met een automatisch gegenereerde bitrate-ladder.

Ja. Media Services kunt een twee-wachtwoordanalyse uitvoeren op een video. Vervolgens kunt u de beste instellingen voor adaptieve bitrates, resoluties en codering aanbevelen op basis van de inhoud van de video. Zie De vooraf ingestelde inhoudsbewuste codering gebruiken voor meer informatie.

Ja. Zie 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, 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. Dat antwoord beschrijft ook de invloed van de prestaties op de oorsprong.

Dit wordt niet aanbevolen. Zeer korte inhoud die minder dan een minuut of twee duurt, is niet ideaal voor Adaptive Bitrate Streaming. Als u zeer korte bestanden 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 adaptive bitrate-spelers tijd nodig hebben om meerdere videosegmenten te bufferen, en ook tijd nodig hebben om de netwerkbandbreedte te analyseren voordat de adaptive bitrate-ladder omhoog of omlaag wordt geschuift, is het vaak onbruikbaar om een groot aantal bitrates te leveren voor inhoud die minder dan 30 seconden lang is. Tegen de tijd dat de speler het heuristische algoritme op de juiste bitrate vergrendelt om af te spelen op basis van netwerkomstandigheden, wordt het bestand gestreamd.

Bovendien zijn sommige spelers standaard ingesteld op het bufferen van maximaal drie videosegmenten. Elk segment kan twee tot zes seconden lang zijn. Voor video's in zeer korte notatie zal de speler waarschijnlijk de eerste geselecteerde bitrate van de adaptieve bitrateset bufferen en afspelen. Daarom raden we u aan een SINGLE-bitrate MP4-bestand te gebruiken en dit te uploaden naar een asset als u het HLS- of DASH-manifest wilt genereren. Zie het antwoord op de vraag 'Kan ik bestaande MP4-bestanden streamen die vooraf zijn gecodeerd of gecodeerd in een andere oplossing?' voor meer informatie over hoe u dit doet. 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, ondersteuning voor digital rights management (DRM) en meer moeite om te downloaden via URL (maar nog steeds mogelijk!) dan een MP4 voor progressief downloaden in blobopslag. Ondertitelingsondersteuning voor VTT en IMSC1 is een ander voordeel. Bovendien is de mogelijkheid om te laat aanvullende audioweergaven, of uitingen in andere talen, te binden, een waardevolle keuze voor bepaalde situaties.

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

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 wilt beginnen met Media Services livegebeurtenissen.

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

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

• Abonneer u op microsoft.Media.LiveEventEncoderDisconnected-gebeurtenissen op streamniveau en controleer of er een tijdje geen nieuwe verbindingen zijn om uw livegebeurtenis te stoppen en te verwijderen.
• Abonneer u op heartbeatgebeurtenissen op track-niveau. Als voor alle sporen een binnenkomende bitsnelheid naar 0 wordt gedropt of als de laatste tijdstempel niet meer toeneemt, kunt u de livegebeurtenis veilig afsluiten. De heartbeat-gebeurtenissen worden elke 20 seconden voor elke track binnen, 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 netwerk voor contentlevering (CDN). U kunt de streaming-URL's van tevoren voorbereiden (en weten), omdat u een specifieke GUID voor de streaming-locator kunt forceerd en vervolgens kunt bepalen welke manifestnaam u wilt gebruiken voor de live-uitvoer.

Stel dat u besluit GUID 1a7ed69e-a361-433d-8a56-29c61872744f te gebruiken voor de live-uitvoer die u morgen maakt. Wanneer de dag is, 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. U kunt de combinatie van de live-uitvoer en asset zien als een tapeopname. Nadat de live-uitvoer is vastgelegd in de asset, kunt u deze niet opnieuw gebruiken voor een andere opname. Als u dit opnieuw doet, is er sprake van blobconflicten of overschreven. Tenzij u van plan bent om de blobs in het opslagaccount volledig op te CDN, zijn er problemen. Er zullen waarschijnlijk nog steeds problemen zijn omdat de fragmenten al downstream in de cache zijn opgeslagen op de CDN of in caches van clientapparaat (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 status Actief.

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

Als u video's beschikbaar wilt maken voor clients voor afspelen, 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 het gebruik van de mediabestanden.

Als u een streaming-URL wilt maken, maakt u eerst een streaming-locator. Vervolgens worden de hostnaam en het pad van de streaming-locator van het streaming-eindpunt samenvoegd. Zie Een streaming-locator maken en URL's bouwen.

Met streamingbeleid kunt u streamingprotocollen en versleutelingsopties voor uw streaming-locators definiëren. Media Services v3 biedt een aantal vooraf gedefinieerde streamingbeleidsregels. Zie Streamingbeleid 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 origin-server de HLS-inhoud te laten retourneren voor gebruik op iOS-apparaten van Apple. Zie Inhoud leveren voor meer informatie.

Ja, de Media Services origin-server (streaming-eindpunt) ondersteunt dynamische verpakking van MP4-bestanden naar de streaming-indeling HLS of DASH. De inhoud moet echter worden gecodeerd in gesloten GOP-indeling, met korte GOP's 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 de AAC-audio-indeling, kan worden ondersteund. Aanvullende audio-indelingen die vooraf zijn gecodeerd, kunnen ook worden ondersteund, zoals Dolby DD+.

Het is belangrijk om een asset te maken, de vooraf gecodeerde assets te uploaden naar de container van de asset met behulp van Azure Blob Storage client-SDK's en vervolgens het vereiste servermanifest (.ism) en clientmanifestbestanden te genereren. Zie het .NET-voorbeeldproject in Bestaande MP4-bestandenstreamen voor meer informatie.

Houd er rekening mee dat er gevolgen zijn voor de prestaties wanneer u deze methode 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 bitsnelheid streamen met HLS of Dash) voor meer informatie.

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

Dynamische versleuteling is het beveiligen van uw media vanaf het moment dat deze uw computer helemaal verlaat via opslag, verwerking en levering. Met Media Services kunt u uw live en on-demand inhoud dynamisch versleutelen 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 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 de 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 als tekst zonder tekst worden bekeken in een netwerk tracering op de client. AES-128 clear key-versleuteling is geschikt voor gebruiksvoorbeelden waarbij de viewer een vertrouwde partij is (bijvoorbeeld het versleutelen van bedrijfsvideo's die zijn gedistribueerd binnen een bedrijf om te worden bekeken door werknemers).

DRM-systemen zoals PlayReady, Widevine en FairPlay bieden een extra versleutelingsniveau voor de sleutel die wordt gebruikt voor het ontsleutelen van de inhoud, vergeleken met een duidelijke AES-128-sleutel. De inhoudssleutel wordt versleuteld met een sleutel die wordt beveiligd door de DRM-runtime, naast eventuele versleuteling op transportniveau die door TLS wordt verstrekt. Ontsleuteling wordt afgehandeld in een beveiligde omgeving op het niveau van het besturingssysteem, waar het moeilijker is voor kwaadwillende gebruikers om aan te vallen. We raden DRM aan voor gebruiksgevallen 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 (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 vergever, doelgroep en claims exact overeenkomen tussen wat zich in JWT en de waarde die ContentKeyPolicyRestriction wordt gebruikt in ContentKeyPolicy .

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

Voor productie moet u secure token service (dat wil zeggen, een webservice), die een JWT-token bij een HTTPS-aanvraag uit te geven. 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, doet de speler een aanvraag voor een dergelijk token bij STS en wijst deze toe als de waarde van het token. U kunt de api Azure Media Player gebruiken.

Zie het JWT-hulpprogrammavoor een voorbeeld van het uitvoeren van STS met een symmetrische sleutel of een asymmetrische sleutel. Zie het testhulpprogramma voor Azure-mediavoor een voorbeeld van een speler Azure Media Player een dergelijk JWT-token gebruikt. (Vouw de koppeling player_settings om de tokeninvoer weer te geven.)

De juiste aanpak is het gebruik van Secure Token Service. 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).

Zie voor meer informatie:

• Overzicht van inhoudsbeveiliging
• Ontwerp van een inhoudsbeveiligingssysteem van een multi-DRM met toegangsbeheer

Dit gedrag lijkt aan het ontwerp van de voorbeeld-app te zijn. Wanneer er een alternatief audiospoor aanwezig is (dit is het geval voor HLS) tijdens de offlinemodus, worden iOS 10 en iOS 11 standaard ingesteld op het alternatieve audiospoor. Verwijder het alternatieve audiospoor uit de stream om dit gedrag in de offlinemodus van DEP 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 met .ism/manifest(format=m3u8-aapl,audio-only=false).

Afhankelijk van het ontwerp van de cachesleutel voor het netwerk voor contentlevering, kan de inhoud in de cache worden opgeslagen. Leeg de cache.

De gedownloade bestandsstructuur op een iOS-apparaat ziet eruit als in de volgende schermopname. In _keys map worden gedownloade FPS-licenties opgeslagen, met één opgeslagen bestand voor elke licentieservicehost. 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 hoofdplaylist van de FPS-inhoud. Ten slotte boot.xml een volledige beschrijving van de mapinhoud .movpkg.

Hier is een voorbeeld van 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://willzhanmswest.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://willzhanmswest.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://willzhanmswest.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 , met een claim op en het exemplaar license_type = "persistent" ContentKeyPolicyRestriction "persistent" StreamingLocator ervan.
• Een ContentKeyPolicy ander exemplaar met , met een claim op license_type="nonpersistent" ContentKeyPolicyRestriction "nonpersistent ', en het exemplaar StreamingLocator ervan.
• 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 Azure Media Services over de Widevine-licentiesjabloon bevat echter vijf beveiligingsniveaus (vereisten voor de robuustheid van de client 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 deserialiseert het -object, dat bevat , en geeft het door aan de content_key_specs security_level globale widevine-leveringsservice. 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 Monitor Media Services voor meer informatie. Handleidingen zijn onder andere Monitor Media Services metrics en Monitor Media Services diagnostic logs.

Gebruik Azure Event Grid om uw livegebeurtenis te bewaken zonder een pollingservice. Handleidingen zijn onder andere Media Services-gebeurtenissen maken en bewaken met Event Grid met behulp van de Azure Portal en Media Services-gebeurtenissen maken en bewaken met Event Grid met behulp van de Azure CLI.

Media Services werkt met Azure Media Player, Shaka en Video.js. Zie de Azure Media Player,De Shaka-spelergebruiken met Azure Media Services of De Video.js-spelergebruiken met Azure Media Services .

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

We hebben een uitgebreide handleiding gemaakt voor migratie van v2 naar v3. We willen graag meer weten over uw migratie-ervaring en behoeften. U kunt feedback geven via GitHub probleem of ondersteuningsticket.

We hebben foutcodes gedocumenteerd in de volgende verwijzingen: Foutcodesvoor streaming-eindpunten, foutcodes voor livegebeurtenissenen taakfoutcodes. Als u hier geen antwoorden kunt vinden, maakt u een ondersteuningsticket.

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

Zie de Media Services voor meer informatie.

Zie Media Services quota en limieten.

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 (inclusief versleutelingssleutels voor inhoud, tokenverificatiesleutels, JobInputHttp-URL's en andere entiteitsmetagegevens) worden opgeslagen in opslag van Microsoft in de regio die is geselecteerd voor het Media Services-account.

Vanwege vereisten voor gegevensopslag in Brazilië - zuid Azië - zuidoost worden extra accountgegevens opgeslagen op een zone-redundante manier en zijn ze opgenomen in één regio. Voor Azië - zuidoost worden alle extra accountgegevens opgeslagen in Singapore. Voor Brazilië - zuid worden de gegevens opgeslagen in Brazilië. In andere regio's dan Brazilië - zuid Azië - zuidoost kunnen extra accountgegevens ook worden opgeslagen in opslag 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 Media Services accounts in meerdere regio's. Een voorbeeld dat laat zien hoe u een oplossing bouwt voor hoge beschikbaarheid met Media Services video on demand is beschikbaar als richtlijn.