Vanliga frågor om Azure Media Services

Se guiden för tillbakadragning av Azure Media Services

Här är en lista:

• OpenAPI-specifikation (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• Kör

Vi rekommenderar inte att du försöker omsluta REST-API:et för Media Services direkt i din egen bibliotekskod. Om du gör det på rätt sätt i produktionssyfte måste du implementera den fullständiga Azure-Resource Manager omprövningslogik och förstå hur du hanterar långvariga åtgärder i Resource Manager API:er. Klient-SDK:erna för olika språk , till exempel .NET, Java, TypeScript, Python och Ruby, hanterar detta automatiskt för att minska risken för problem med omprövningslogik eller misslyckade API-anrop.

Se exempelsidorna. Det finns exempel för konton, tillgångar, liveuppspelning, VOD-direktuppspelning, innehållsskydd, kodning, analys och användning av spelare.

När du använder sidnumrering bör du alltid använda nästa länk för att räkna upp samlingen och inte vara beroende av en viss sidstorlek. Mer information och exempel finns i Filtrering, ordning och växling av entiteter.

Information om hur du använder Azure CLI för att koppla Media Services med Azure Key Vault för att kryptera dina data finns i självstudien Använda en Key Vault nyckel för att kryptera data till ett Media Services-konto.

Om du vill att Media Services ska få åtkomst till ett lagringskonto när lagringskontot har konfigurerats för att blockera begäranden från okända IP-adresser följer du stegen i Åtkomstlagring med en Hanterad Media Services-identitet.

Se Flytta ett Media Services-konto mellan prenumerationer.

Se Rollbaserad åtkomstkontroll i Azure (Azure RBAC) för Media Services-konton.

Media Services definierar följande inbyggda roller:

• Media Services-kontoadministratör
• Media Services Media Operator
• Principadministratör för Media Services
• Administratör för Media Services-slutpunkter för direktuppspelning
• Media Services Live Events Administrator

De här rollerna beskrivs i rollbaserad åtkomstkontroll i Azure (Azure RBAC) för Media Services-konton.

Dessa roller kan användas för att ge detaljerad åtkomst till ett Media Services-konto. Om du vill tillåta all åtkomst till ett Media Services-konto kan rollen "Ägare" eller "Deltagare" användas. Media Services har ett äldre API på utfasningssökvägen som inte stöder detaljerad åtkomstkontroll. Kunder som behöver detaljerad åtkomstkontroll bör inte välja "Aktivera klassiska API:er" när de skapar ett Media Services-konto med hjälp av portalen (eller använda API-versionen 2020-05-01 om de använder API:et för att skapa konton).

Följande inbyggda Azure Policy kan användas för att blockera skapandet av konton som stöder det gamla API:et: Azure Media Services-konton som tillåter åtkomst till det äldre v2-API:et bör blockeras – Microsoft Azure

En Media Services-tillgång är en Azure Storage-kontocontainer som används för varje videofil som du laddar upp. Den har en unik identifierare som används med transformeringar och andra åtgärder. Se Tillgångar i Azure Media Services v3.

Varje gång du vill ladda upp en mediefil och göra något med den, till exempel kodning eller strömning, skapar du en tillgång för att lagra mediefilen och associerade filer. Tillgångar skapas automatiskt åt dig om du använder Azure Portal. Om du inte använder portalen för att ladda upp filer måste du först skapa en tillgång.

Vanliga kodningsformat är tillgängliga med Media Services Standard Encoder. En lista över alla format finns i Standard Encoder-format och codecs.

Du kan skapa ett jobb i Azure Portal med hjälp av Azure CLI, REST eller någon av SDK:erna. Se Media Services-exemplen för det språk som du föredrar.

Ja. Se Koda med en automatiskt genererad bithastighetsstege.

Ja. Media Services kan utföra en tvåstegsanalys på en video. Den kan sedan rekommendera den bästa uppsättningen med anpassningsbar bithastighet, upplösningar och kodningsinställningar baserat på innehållet i videon.

Ja. Mer information och länkar till ett exempelprogram som visar hur du laddar upp en MP4-fil med enkel bithastighet som är förkodad och genererar servermanifestet (.ism) och klientmanifestet (.ismc) finns i svaret på frågan "Kan jag strömma befintliga MP4-filer som är förkodade eller kodade i en annan lösning?" i avsnittet om paketering och leverans. Det svaret beskriver också prestandapåverkan på ursprunget.

Vi rekommenderar det inte. Mycket kort innehåll som är mindre än en minut eller två i varaktighet är inte idealiskt för direktuppspelning med anpassningsbar bithastighet. Om du tänker strömma mycket kortformatsfiler rekommenderar vi att du förkodar innehållet till ett format som enkelt strömmas med en enda bithastighet.

Eftersom de flesta spelare med anpassningsbar bithastighet behöver tid att buffra flera segment av video, samt tid att analysera nätverkets bandbredd innan de "skiftar" uppåt eller nedåt på stegen för anpassningsbar bithastighet, är det ofta oanvändbart att tillhandahålla mycket bithastigheter för innehåll som är under 30 sekunder långt. När spelaren låser sin heuristiska algoritm på rätt bithastighet för att spela upp baserat på nätverksförhållanden görs strömning av filen.

Dessutom buffrar vissa spelare upp till tre delar av videon som standard. Varje segment kan vara två till sex sekunder långt. För videor med mycket kort format kommer spelaren troligen att buffra och börja spela upp den första valda bithastigheten i uppsättningen med anpassningsbar bithastighet. Därför rekommenderar vi att du använder en MP4-fil med enkel bithastighet och laddar upp den till en tillgång om du behöver generera HLS- eller DASH-manifestet. Mer information om hur du uppnår detta finns i svaret på frågan "Kan jag strömma befintliga MP4-filer som är förkodade eller kodade i en annan lösning?" i avsnittet om paketering och leverans.

Det är bara nödvändigt att leverera filerna i HLS- eller DASH-format om du vill dra nytta av funktionerna i dessa protokoll. För dataströmmar med enkel bithastighet kan de fortfarande erbjuda mycket – till exempel snabbare sökning, stöd för digital rättighetshantering (DRM) och ökade svårigheter att ladda ned via URL (men fortfarande möjligt!) än en progressiv nedladdning av MP4 i Blob Storage. Stöd för bildtexter för VTT och IMSC1 är en annan fördel. Dessutom gör möjligheten att sent binda ytterligare ljudåtergivningar, eller dubbningar på alternativa språk, detta ett värdefullt val för vissa situationer.

Om du letar efter sätt att använda en Media Services-kodare för att göra saker som att rotera en video, subclip en video, sy videor, skapa miniatyrer och sprites, har vi massor av kodexempel på sidan Kodexempel . Tillgängliga exempelspråk är Node.JS, Python, .NET och Java.

En Media Services-livehändelse är en process för att mata in livevideofeeds och sända dem via ett RTMPS-protokoll eller Smooth Streaming. Mer information finns i Livehändelser och liveutdata i Media Services.

Det första steget är att välja en lokal kodare. Vi har gett exempel på hur du skapar en livehändelse med Wirecast och OBS. Om du hellre vill börja med en översikt över Media Services livehändelser läser du Typer av livehändelser.

Azure Media Service levererar video, ljud och text i olika protokoll. När du publicerar din liveström med hjälp av MPEG-DASH eller HLS/CMAF levererar tjänsten, tillsammans med video och ljud, den transkriberade texten i IMSC1.1-kompatibel TTML. Mer information finns i Live-transkription.

Du kan övervaka livehändelser genom att prenumerera på Azure Event Grid händelser. Mer information finns i Event Grid-händelseschemat. Du kan antingen:

• Prenumerera på händelser på stream-nivå Microsoft.Media.LiveEventEncoderDisconnected och övervaka att inga återanslutningar kommer in ett tag för att stoppa och ta bort livehändelsen.
• Prenumerera påpulsslagshändelser på spårnivå. Om alla spår har en inkommande bithastighet som sjunker till 0 eller om stämpeln för sista gången inte längre ökar kan du stänga av livehändelsen på ett säkert sätt. Pulsslagshändelserna kommer in var 20:e sekund för varje spår, så det kan vara lite utförligt.

Nej, du kan inte enkelt använda samma strömmande URL om du stoppar och startar en livehändelse. Varje gång du skapar och publicerar en ny liveutdata (och tillgång) används en ny strömnings-URL (GUID) för den nya lokaliseraren. På så sätt är du säker på att det inte blir någon cachekonflikt i slutpunkten för direktuppspelning och innehållsleveransnätverket (CDN). Du kan förbereda (och känna till) strömmande URL:er i förväg eftersom du kan framtvinga ett specifikt GUID för positioneraren för direktuppspelning och sedan bestämma vilket manifestnamn som ska användas för liveutdata.

Anta att du bestämmer dig för att använda GUID 1a7ed69e-a361-433d-8a56-29c61872744f för liveutdata som du skapar i morgon. När dagen kommer startar du livehändelsen och skapar liveutdata. Du kan välja att använda "conference1" för manifestet och framtvinga GUID för positioneraren.

Direktuppspelnings-URL:en är förutsägbar och är http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Du kan inte återanvända samma liveutdata eller tillgång flera gånger. Tänk på kombinationen av live-utdata och tillgång som en bandinspelning. När liveutdata har registrerats för tillgången kan du inte återanvända dem för en annan inspelning. Det uppstår blobkonflikter eller överskrivningar om du gör det igen. Om du inte planerar att rensa blobarna fullständigt i lagringskontot och rensa CDN helt, kommer det att uppstå problem. Det kommer troligen fortfarande att uppstå problem eftersom fragmenten redan cachelagras nedströms i CDN eller i klientenhetens cacheminnen (till exempel webbläsarens cacheminne).

En av de vanligaste orsakerna är att du inte har den slutpunkt för direktuppspelning som du försöker spela upp i körningstillståndet.

I Media Services representerar en slutpunkt för direktuppspelning en dynamisk (just-in-time) paketerings- och ursprungstjänst som kan leverera ditt live- och on-demand-innehåll direkt till en klientspelarapp med hjälp av något av de vanliga strömningsmediaprotokollen (HLS eller DASH). Dessutom tillhandahåller slutpunkten för direktuppspelning dynamisk (just-in-time) kryptering till branschledande DRM-system. Mer information finns i Slutpunkter för direktuppspelning (ursprung) i Azure Media Services.

Om du vill göra videor tillgängliga för klienter för uppspelning skapar du en positionerare för direktuppspelning och skapar sedan strömmande URL:er. Positionerare för direktuppspelning används också för att tillämpa strömningsprinciper som innehåller regler för hur mediefilerna används.

Om du vill skapa en direktuppspelnings-URL skapar du först en positionerare för direktuppspelning. Sedan sammanfogar du den strömmande slutpunktens värdnamn och sökvägen till positioneraren för direktuppspelning.

Med strömningsprinciper kan du definiera strömningsprotokoll och krypteringsalternativ för dina positionerare för strömning. Media Services v3 tillhandahåller vissa fördefinierade strömningsprinciper. Mer information finns i Principer för direktuppspelning.

En lista över fördefinierade principer som du kan använda för att komma igång finns i Strömningsprinciper.

Kontrollera att du har (format=m3u8-cmaf) i slutet av sökvägen (efter /manifestdelen av URL:en) för att instruera den strömmande ursprungsservern att returnera HLS-innehåll för förbrukning på Apple iOS-interna enheter. Mer information finns i Leverera innehåll.

Ja, Media Services-ursprungsservern (slutpunkt för direktuppspelning) stöder dynamisk paketering av MP4-filer till HLS- eller DASH-strömningsformat. Innehållet måste dock kodas i formatet closed-GOP, med korta GOPs i varaktighetsintervallet två till sex sekunder. Vi rekommenderar följande inställningar: två sekunders GOP:er, maximalt nyckelfält och minsta avstånd på två sekunder, kodning av konstant bithastighet (CBR-läge). Det mesta innehåll i det här formatet som kodas via H.264 eller HEVC video codec, tillsammans med AAC-ljudformat, kan stödjas. Ytterligare ljudformat som är förkodade kan också stödjas, till exempel Dolby DD+.

Nyckeln till att få det att fungera är att skapa en tillgång, ladda upp de förkodade tillgångarna till tillgångens container med hjälp av Azure Blob Storage klient-SDK:er och sedan generera nödvändiga servermanifest (.ism) och klientmanifestfiler. Mer information finns i .NET-exempelprojektet i Stream-befintliga MP4-filer.

Tänk på att det finns prestandaeffekter när du använder den här metoden, eftersom den inbyggda kodaren i Media Services också genererar binära index (.mpi-filer) som förbättrar åtkomsttiden till MP4-filerna. Utan dessa filer kan servern använda något mer PROCESSOR vid hög belastning. Mer information finns i Strömma en befintlig MP4-fil med enkel bithastighet med HLS eller Dash.

När du skalar upp med den här metoden bör du övervaka strömningsslutpunktens CPU-belastning. Om du planerar att gå till produktion med ett stort bibliotek med MP4-filer som är förkodade utanför Media Services kan du skicka ett supportärende för att få din arkitektur granskad och fråga om sätt att förbättra ursprungsserverns prestanda för förkodat MP4-innehåll.

Positionerare för direktuppspelning som skapats med v2-API:et fortsätter att fungera när vårt v2-API har inaktiverats. När Lokaliseringsdata för direktuppspelning har skapats i Media Services-serverdelsdatabasen finns det inget beroende av rest-API:et v2 för strömning. Vi tar inte bort v2-specifika poster från databasen när v2 är inaktiverat i februari 2024.

Det finns vissa egenskaper för tillgångar och lokaliserare som skapats med v2 som inte kan nås eller uppdateras med hjälp av det nya v3-API:et. V2 exponerar till exempel ett Tillgångsfiler-API som inte har någon motsvarande funktion i v3-API:et. Ofta är detta inte ett problem för de flesta av våra kunder, eftersom det inte är en allmänt använd funktion och du fortfarande kan strömma gamla lokaliserare och ta bort dem när de inte längre behövs.

Efter migreringen bör du undvika att göra några anrop till v2-API:et för att ändra positionerare eller tillgångar för direktuppspelning.

Dynamisk kryptering skyddar dina media från det att det lämnar datorn hela vägen genom lagring, bearbetning och leverans. Med Media Services kan du leverera ditt live- och på begäran-innehåll krypterat dynamiskt med Advanced Encryption Standard (AES-128) eller något av de tre stora DRM-systemen: Microsoft PlayReady, Google Widevine och Apple FairPlay. Mer information finns i Skydda ditt innehåll med dynamisk Media Services-kryptering.

Kunder undrar ofta om de ska använda AES-kryptering eller ett DRM-system. Den största skillnaden mellan de två systemen är att med AES-kryptering överförs innehållsnyckeln till klienten via TLS. Nyckeln krypteras under överföring utan ytterligare kryptering ("i klartext"). Därför är nyckeln som används för att dekryptera innehållet tillgänglig för klientspelaren och kan visas i en nätverksspårning på klienten i klartext. AES-128 clear key encryption är lämplig för användningsfall där visningsprogrammet är en betrodd part (till exempel kryptera företagsvideor som distribueras inom ett företag för att visas av anställda).

DRM-system som PlayReady, Widevine och FairPlay ger ytterligare en krypteringsnivå på nyckeln som används för att dekryptera innehållet, jämfört med en AES-128-klarnyckel. Innehållsnyckeln krypteras till en nyckel som skyddas av DRM-körningen utöver all kryptering på transportnivå som TLS tillhandahåller. Dekryptering hanteras i en säker miljö på operativsystemnivå, där det är svårare för en obehörig användare att attackera. Vi rekommenderar DRM för användningsfall där visningsprogrammet kanske inte är en betrodd part och du behöver den högsta säkerhetsnivån.

Du behöver inte använda någon specifik tokenprovider, till exempel Azure Active Directory (Azure AD). Du kan skapa en egen JWT-provider (så kallad säker tokentjänst eller STS) med hjälp av asymmetrisk nyckelkryptering. I din anpassade STS kan du lägga till anspråk baserat på din affärslogik.

Kontrollera att utfärdaren, målgruppen och anspråken matchar exakt det som finns i JWT och värdet ContentKeyPolicyRestriction som används i ContentKeyPolicy.

Mer information finns i Skydda ditt innehåll med dynamisk Media Services-kryptering.

För produktion måste du ha säker tokentjänst (det vill: en webbtjänst), som utfärdar en JWT-token vid en HTTPS-begäran. För test kan du använda koden som visas i metoden GetTokenAsync som definieras i Program.cs.

När en användare har autentiserats skickar spelaren en begäran till STS om en sådan token och tilldelar den som värdet för token. Du kan använda Azure Media Player-API:et.

Ett exempel på hur du kör STS med antingen en symmetrisk nyckel eller en asymmetrisk nyckel finns i JWT-verktyget. Ett exempel på en spelare baserad på Azure Media Player som använder en sådan JWT-token finns i Testverktyget för Azure Media. (Expandera länken player_settings för att se tokenindata.)

Rätt metod är att använda säker tokentjänst. I STS, beroende på användarprofilen, lägger du till olika anspråk (till exempel "Premium-användare", "Grundläggande användare" eller "Kostnadsfri utvärderingsanvändare"). Med olika anspråk i en JWT kan användaren se olika innehåll. För olika innehåll eller tillgångar ContentKeyPolicyRestriction har motsvarande RequiredClaims värde.

Använd Azure Media Services-API:er för att konfigurera licens-/nyckelleverans och kryptera dina tillgångar (som du ser i det här exemplet).

Det här beteendet verkar vara avsiktligt för exempelappen. När det finns ett alternativt ljudspår (vilket är fallet för HLS) i offlineläge är både iOS 10 och iOS 11 standard för det alternativa ljudspåret. Om du vill kompensera för det här beteendet i FPS offlineläge tar du bort det alternativa ljudspåret från strömmen. Om du vill göra detta på Media Services lägger du till det dynamiska manifestfiltret audio-only=false. Med andra ord slutar en HLS-URL med .ism/manifest(format=m3u8-aapl,audio-only=false).

Beroende på cachenyckeldesignen för innehållsleveransnätverket kan innehållet cachelagras. Rensa cachen.

Den nedladdade filstrukturen på en iOS-enhet ser ut som följande skärmbild. Mappen _keys lagrar nedladdade FPS-licenser med en lagrad fil för varje licenstjänstvärd. Mappen .movpkg lagrar ljud- och videoinnehåll.

Den första mappen med ett namn som slutar med ett bindestreck följt av ett tal innehåller videoinnehåll. Det numeriska värdet är den högsta bandbredden för videoåtergivningarna. Den andra mappen med ett namn som slutar med ett bindestreck följt av 0 innehåller ljudinnehåll. Den tredje mappen med namnet Data innehåller huvudspellistan för FPS-innehållet. Slutligen ger boot.xml en fullständig beskrivning av . movpkg-mappinnehållet .

Här är ett exempel boot.xml fil:

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

Eftersom Media Services v3 tillåter att en tillgång har flera StreamingLocator instanser kan du ha:

• En ContentKeyPolicy instans med license_type = "persistent", ContentKeyPolicyRestriction med ett anspråk på "persistent"och dess StreamingLocator instans.
• En annan ContentKeyPolicy instans med license_type="nonpersistent", ContentKeyPolicyRestriction med ett anspråk på "nonpersistent" och dess StreamingLocator instans.
• Två StreamingLocator instanser som har olika ContentKey värden.

Beroende på affärslogiken för anpassad STS utfärdas olika anspråk i JWT-token. Med token kan endast motsvarande licens hämtas och endast motsvarande URL kan spelas upp.

Googles Översikt över Widevine DRM-arkitektur definierar tre säkerhetsnivåer. Azure Media Services-dokumentationen i Widevine-licensmallen beskriver dock fem säkerhetsnivåer (krav på klientens robusthet för uppspelning).

Google Widevine definierar båda uppsättningarna med säkerhetsnivåer. Skillnaden är användningsnivån: arkitektur eller API. De fem säkerhetsnivåerna används i Widevine-API:et. Azure Media Services Widevine-licenstjänsten deserialiserar content_key_specs objektet, som innehåller security_level, och skickar det till den globala leveranstjänsten Widevine. I följande tabell visas mappningen mellan de två uppsättningarna med säkerhetsnivåer.

Använd Azure Monitor för att hålla reda på vad som händer med dina Media Services-resurser. Mer information finns i Övervaka Media Services. Guider visas i slutet av sidan.

Använd Azure Event Grid för att övervaka livehändelsen utan en avsökningstjänst. Se Skapa och övervaka Media Services-händelser med Event Grid med hjälp av Azure Portal.

Media Services arbetar med många spelare. Se listan över kompatibla mediespelare eller prova spelarexempel från tredje part.

Information om Media Services och hög tillgänglighet finns i Hög tillgänglighet med Media Services och Video on Demand (VOD).

Vi har skapat en omfattande guide för migrering från v2 till v3. Vi är intresserade av att veta om din migreringsupplevelse och dina behov, så ge gärna feedback via GitHub-problem eller supportärende.

Vi har dokumenterat felkoder i följande referenser: Felkoder för direktuppspelningsslutpunkt, livehändelsefelkoder och jobbfelkoder. Om du inte hittar svar där kan du skapa en supportbegäran.

Du kan återställa dina kontoautentiseringsuppgifter med hjälp av Azure CLI.

Se prisguiden för Media Services.

Se Media Services-kvoter och gränser.

Kunder kopplar sina egna lagringskonton till sina Azure Media Services-konton. Alla tillgångsdata lagras i dessa associerade lagringskonton och kunden styr lagringens plats och replikeringstyp.

Ytterligare data som är associerade med ett Media Services-konto (inklusive innehållskrypteringsnycklar, tokenverifieringsnycklar, Url:er för JobInputHttp och andra entitetsmetadata) lagras i Microsoft-ägd lagring i den region som valts för Media Services-kontot.

På grund av kraven på datahemvist i Brasilien, södra och Sydostasien lagras ytterligare kontodata på ett zonredundant sätt och finns i en enda region. För Sydostasien lagras alla ytterligare kontodata i Singapore. För Brasilien, södra lagras data i Brasilien. I andra regioner än Brasilien, södra och Sydostasien, kan ytterligare kontodata också lagras i Microsoft-ägd lagring i den kopplade regionen.

Azure Media Services är en regional tjänst och ger inte hög tillgänglighet eller datareplikering. Vi uppmuntrar kunder som behöver dessa funktioner att skapa en lösning med hjälp av Media Services-konton i flera regioner. Ett exempel som visar hur du skapar en lösning för hög tillgänglighet med Media Services-video på begäran finns som en guide.