Vanliga frågor om Azure Media Services

Här är en lista:

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

Vi rekommenderar inte att du försöker omsluta REST API för Media Services direkt i din egen bibliotekskod. Om du gör det i produktionssyfte måste du implementera den fullständiga Azure Resource Manager logiken för omförsök och förstå hur du hanterar långvariga åtgärder i Resource Manager API:er. Klient-API: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. Postman-samlingen tillhandahålls mer som ett undervisningsverktyg och för att visa dig vad klient-SDK:erna gör under utvecklingen med dem.

En lista över Media Services finns i artikeln Media Services v3-exempel.

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 data finns i självstudiekursen Använda en Key Vault-nyckel för att kryptera data till ett Media Services-konto.

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

Se Flytta ett Media Services mellan prenumerationer.

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

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 tillhörande 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. Mer information finns i Skapa en tillgång.

De vanliga kodningsformaten är tillgängliga 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 för det språk du föredrar.

Ja. Se Koda med en automatiskt genererad bithastighetsstege.

Ja. Media Services kan utföra en analys med två pass på en video. Den kan sedan rekommendera den bästa uppsättningen med anpassningsbar bithastighet, upplösningar och kodningsinställningar baserat på videons innehåll. Mer information finns i Så här använder du den innehållsmedvetna kodningsförinställningen.

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. Svaret beskriver även 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 korta filer rekommenderar vi att du kodar innehållet i förväg till ett format som enkelt kan strömmas med en enda bithastighet.

Eftersom de flesta spelare med anpassningsbar bithastighet behöver tid för att buffra flera segment av video, samt tid att analysera nätverksbandbredden innan de "växlar" upp eller ned stegen för anpassningsbar bithastighet, är det ofta oanvändbart att tillhandahålla många bithastigheter för innehåll som är under 30 sekunder långt. När spelaren låser sin heuristiska algoritm till höger bithastighet för att spela upp baserat på nätverksförhållanden, kommer filen att vara klar med strömning.

Dessutom buffrar vissa spelare som standard upp till tre videosegment. Varje segment kan vara två till sex sekunder långt. För mycket korta videor kommer spelaren sannolikt att buffra och börja spela upp den första valda bithastigheten för 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 generering av 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.

Du behöver bara 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, DRM-stöd (Digital Rights Management) och ökad problem med nedladdning 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 dubbning på alternativa språk, detta till ett värdefullt val i vissa situationer.

En Media Services livehändelse är processen att mata in livevideor 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 angett exempel för att skapa en livehändelse med Wirecast och OBS. Om du hellre vill börja med en översikt över Media Services livehändelser kan du se Livehändelsetyper.

Azure Media Service levererar video, ljud och text i olika protokoll. När du publicerar liveuppspelningen med MPEG-DASH eller HLS/CMAF, och sedan tillsammans med video och ljud, levererar tjänsten 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å Microsoft.Media.LiveEventEncoderDisconnected-händelser på stream-nivå och övervaka att inga återanslutningar kommer in ett tag för att stoppa och ta bort livehändelsen.
• Prenumerera på pulsslagshändelser på spårad nivå. Om alla spår har en inkommande bithastighet som sjunker till 0 eller om den senaste tidsstämpeln 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 använda samma strömnings-URL om du stoppar och startar en livehändelse. Varje gång du skapar och publicerar nya liveutdata (och tillgångar) 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 kommer att finnas någon cachekonflikt i slutpunkten för direktuppspelning och nätverket för innehållsleverans (CDN). Du kan förbereda (och känna till) strömnings-URL:erna i förväg eftersom du kan tvinga fram ett specifikt GUID för strömningslokaliseraren och sedan bestämma manifestnamnet 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 tvinga GUID:t för lokaliseraren.

Strömnings-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 liveutdata och tillgången som en bandinspelning. När liveutdata har registrerats för tillgången kan du inte återanvända den för en annan inspelning. Det kommer att finnas en blobkonflikt eller skriva över om du gör det igen. Om du inte planerar att helt rensa blobarna i lagringskontot och rensa CDN helt, kommer det att finnas problem. Det kommer troligen fortfarande att finnas problem eftersom fragmenten redan cachelagras nedströms i CDN eller i klientenhetscacheminnen (till exempel webbläsarens cacheminne).

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

I Media Services representerar en slutpunkt för direktuppspelning en dynamisk paketerings- och ursprungstjänst (just-in-time) som kan leverera live- och på begäran-innehåll direkt till en klientspelarapp genom att använda något av de vanliga protokollen för direktuppspelande media (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 uppspelning av klienter skapar du en positionerare för direktuppspelning och skapar sedan strömnings-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 strömnings-URL skapar du först en positionerare för direktuppspelning. Sedan sammanfogar du strömningsslutpunktens värdnamn och strömningslokaliserarens sökväg. Se Skapa en positionerare för direktuppspelning och skapa URL:er.

Med direktuppspelningsprinciper kan du definiera strömningsprotokoll och krypteringsalternativ för dina strömningslokaliserare. Media Services v3 innehåller vissa fördefinierade direktuppspelningsprinciper. 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 Direktuppspelningsprinciper.

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

Ja, den ursprungliga Media Services (slutpunkt för direktuppspelning) stöder dynamisk paketering av MP4-filer till HLS- eller DASH-strömningsformat. Innehållet måste dock kodas i stängt GOP-format, med korta GOP:er i varaktighetsintervallet på två till sex sekunder. Vi rekommenderar följande inställningar: tvåsekunders GOP:er, högsta och minsta avstånd på två sekunder, kodning med 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 servermanifestfiler (.ism) och klientmanifestfiler. Mer information finns i .NET-exempelprojektet i Strömma befintliga MP4-filer.

Tänk på att prestandan påverkas när du använder den här metoden, eftersom den inbyggda kodaren i Media Services även genererar binära index (.mpi-filer) som förbättrar åtkomsttiden till MP4-filerna. Utan dessa filer kan servern använda lite mer CPU 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 cpu-belastningen för slutpunkten för direktuppspelning. Om du planerar att gå till produktion med ett stort bibliotek med MP4-filer som är förkodade utanför Media Services kan du skapa en supportbiljett 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.

Dynamisk kryptering skyddar dina media från den tidpunkt då de lämnar datorn hela vägen genom lagring, bearbetning och leverans. Med Media Services kan du leverera live- och på-begäran-innehåll krypterat dynamiskt med Advanced Encryption Standard (AES-128) eller något av de tre större DRM-systemen: Microsoft PlayReady, Google Widevine och Apple FairPlay. Mer information finns i Skydda ditt innehåll med hjälp Media Services dynamisk 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 klar klar). 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 oformaterad text. AES-128-kryptering med klarnyckel lämpar sig för användningsfall där visningsprogrammet är en betrodd part (till exempel kryptering av företagsvideor som distribueras inom ett företag som ska visas av anställda).

DRM-system som PlayReady, Widevine och FairPlay ger ytterligare en krypteringsnivå för nyckeln som används för att dekryptera innehållet, jämfört med en klarkodsnyckel för AES-128. 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 angripa. 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.k. Secure Token Service eller STS) med hjälp av asymmetrisk nyckelkryptering. I din anpassade sts kan du lägga till anspråk baserat på din affärslogik.

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

Mer information finns i Skydda ditt innehåll med hjälp av Media Services dynamisk kryptering.

För produktion måste du ha En säker tokentjänst (det vill säga en webbtjänst), som utfärdar en JWT-token på 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 gör 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.

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 som baseras på Azure Media Player som använder en sådan JWT-token finns i Azure Media Test Tool. (Expandera player_settings för att se tokenindata.)

Rätt metod är att använda Säker tokentjänst. I STS lägger du, beroende på användarprofil, till olika anspråk (till exempel "Premium-användare", "Basic-användare" eller "Användare av kostnadsfri utvärderingsversion"). 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 (se det här exemplet).

Mer information finns i:

• Översikt över innehållsskydd
• Utforma multi-DRM-innehållsskyddssystem med åtkomstkontroll

Det här beteendet verkar vara design för exempelappen. När det finns ett alternativt ljudspår (vilket är fallet för HLS) i offlineläge, används som standard både iOS 10 och iOS 11 som alternativ ljudspår. För att kompensera för det här beteendet i OFFLINE-läge tar du bort det alternativa ljudspåret från strömmen. Om du vill göra 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å cachenyckelns design för nätverket för innehållsleverans kan innehållet cachelagras. Rensa cachen.

Den nedladdade filstrukturen på en iOS-enhet ser ut som på följande skärmbild. Mappen _keys lagrar nedladdade FP-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 huvudspelningslistan för INNEHÅLLET IOS. Slutligen innehåller boot.xml en fullständig beskrivning av mappinnehållet i .movpkg.

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://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>

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

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

Beroende på affärslogik i anpassad SÄKERHETStoken utfärdas olika anspråk i JWT-token. Med token kan endast motsvarande licens hämtas och endast motsvarande URL kan spelas upp.

Googles Widevine DRM-arkitekturöversikt definierar tre säkerhetsnivåer. I dokumentationen Azure Media Services Widevine-licensmallen beskrivs dock fem säkerhetsnivåer (krav på klientsäkerhet för uppspelning).

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

Använd Azure Monitor att hålla reda på vad som händer med dina Media Services resurser. Mer information finns i Övervaka Media Services. I vägledningarna finns Monitor Media Services mått och Monitor Media Services diagnostic logs.

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

Media Services fungerar med Azure Media Player, Shaka och Video.js. Se dokumentationen Azure Media Player,Använda Shaka-spelarenmed Azure Media Services eller Använda Video.js-spelaren med Azure Media Services.

Information om Media Services 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 mer om din migreringsupplevelse och dina behov, så ge gärna feedback via GitHub eller supportbiljett.

Vi har dokumenterat felkoder i följande referenser: Felkoder för slutpunkter fördirektuppspelning, Felkoder för livehändelseoch felkoder för jobb. Om du inte hittar några svar där kan du skapa en supportbiljett.

Du kan återställa autentiseringsuppgifterna för ditt konto med hjälp av Azure CLI.

Se Media Services prisguiden.

Se Media Services kvoter och begränsningar.

Kunder bifogar 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, JobInputHttp-URL:er och andra entitetsmetadata) lagras i Microsoft-ägd lagring i den region som valts för Media Services-kontot.

På grund av kraven på datahemhemlighet 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 Sydostasien kan ytterligare kontodata också lagras i Microsoft-ägda lagringsutrymmen i den parkopplade 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 för att skapa en lösning genom att använda Media Services-konton i flera regioner. Ett exempel som visar hur du skapar en lösning för hög tillgänglighet Media Services en video på begäran finns som vägledning.