Běžné dotazy ke službě Azure Media Services

Projděte si průvodce vyřazením služby Azure Media Services z provozu.

Tady je výpis:

• Specifikace OpenAPI (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• Přejít

Nedoporučujeme, abyste se pokoušeli zabalit rozhraní REST API pro Media Services přímo do vlastního kódu knihovny. Pokud byste to udělali správně pro produkční účely, museli byste implementovat úplnou logiku opakování Azure Resource Manager a pochopit, jak spravovat dlouhotrvající operace v rozhraních API Resource Manager. Klientské sady SDK pro různé jazyky – například .NET, Java, TypeScript, Python a Ruby – to zpracují automaticky, aby se snížila pravděpodobnost problémů s logikou opakování nebo neúspěšnými voláními rozhraní API.

Podívejte se na stránky s ukázkami. K dispozici jsou ukázky pro účty, prostředky, živé streamování, streamování VOD, ochranu obsahu, kódování, analýzu a používání přehrávačů.

Pokud používáte stránkování, měli byste vždy použít další odkaz k vytvoření výčtu kolekce a neměli byste záviset na konkrétní velikosti stránky. Podrobnosti a příklady najdete v tématu Entity filtrování, řazení a stránkování.

Informace o použití Azure CLI ke spárování služby Media Services s Azure Key Vault k šifrování dat najdete v kurzu Použití klíče Key Vault k šifrování dat v účtu Media Services.

Pokud chcete, aby služba Media Services přistupovala k účtu úložiště, když je účet úložiště nakonfigurovaný tak, aby blokoval požadavky z neznámých IP adres, postupujte podle kroků v tématu Přístup k úložišti pomocí spravované identity Služby Media Services.

Viz Přesun účtu Media Services mezi předplatnými.

Viz Řízení přístupu na základě role v Azure (Azure RBAC) pro účty Media Services.

Služba Media Services definuje následující předdefinované role:

• Správce účtu Media Services
• Operátor médií služby Media Services
• Správce zásad služby Media Services
• Správce koncových bodů streamování služby Media Services
• Správce živých událostí služby Media Services

Tyto role jsou podrobně popsané v tématu Řízení přístupu na základě role v Azure (Azure RBAC) pro účty Media Services.

Tyto role se dají použít k poskytnutí podrobného přístupu k účtu Media Services. Pokud chcete povolit veškerý přístup k účtu Media Services, můžete použít roli Vlastník nebo Přispěvatel. Služba Media Services má starší rozhraní API v zastaralé cestě, které nepodporuje podrobné řízení přístupu. Zákazníci, kteří vyžadují podrobné řízení přístupu, by při vytváření účtu Media Services pomocí portálu neměli vybírat možnost Povolit klasická rozhraní API (nebo použít verzi rozhraní API z 1. 5. 2020, pokud k vytváření účtů používají rozhraní API).

K blokování vytváření účtů, které podporují staré rozhraní API, je možné použít následující předdefinované Azure Policy: Účty Azure Media Services, které umožňují přístup ke starší verzi rozhraní API v2, by měly být blokované – Microsoft Azure

Prostředek Media Services je kontejner účtu Azure Storage, který se používá pro každý soubor videa, který nahrajete. Má jedinečný identifikátor, který se používá u transformací a dalších operací. Viz Prostředky ve službě Azure Media Services v3.

Pokaždé, když chcete nahrát multimediální soubor a něco s ním udělat, například kódování nebo streamování, vytvoříte prostředek pro uložení multimediálního souboru a přidružených souborů. Prostředky se vytvoří automaticky, pokud použijete Azure Portal. Pokud k nahrání souborů nepoužíváte portál, musíte nejprve vytvořit prostředek.

Běžné formáty kódování jsou k dispozici se standardním kodérem Media Services. Seznam všech formátů najdete v tématu Formáty a kodeky standardního kodéru.

Úlohu v Azure Portal můžete vytvořit pomocí Azure CLI, REST nebo jakékoli sady SDK. Podívejte se na ukázky Media Services pro upřednostňovaný jazyk.

Ano. Viz Kódování pomocí automaticky generovaného žebříčku přenosových rychlostí.

Ano. Služba Media Services může u videa provést analýzu dvou průchodů. Pak může doporučit nejlepší sadu adaptivní přenosové rychlosti, rozlišení a nastavení kódování na základě obsahu videa.

Ano. Podrobnosti a odkazy na ukázkovou aplikaci, která ukazuje, jak nahrát soubor MP4 s jednou přenosovou rychlostí, který je předem zakódovaný, a vygenerovat manifest serveru (.ism) a manifest klienta (.ismc), najdete v odpovědi na otázku "Můžu streamovat existující soubory MP4, které jsou předkódované nebo zakódované v jiném řešení?" v části věnované balení a doručování. Tato odpověď také popisuje dopad na výkon na původ.

Nedoporučujeme to. Velmi krátký obsah, který trvá méně než minutu nebo dvě, není ideální pro streamování s adaptivní přenosovou rychlostí. Pokud máte v úmyslu streamovat soubory velmi krátkého formátu, doporučujeme předem zakódovat obsah do formátu, který se dá snadno streamovat pomocí jedné přenosové rychlosti.

Vzhledem k tomu, že většina hráčů s adaptivní přenosovou rychlostí potřebuje čas na uložení více segmentů videa do vyrovnávací paměti a také čas na analýzu šířky pásma sítě před "posunem" nahoru nebo dolů v žebříčku adaptivních přenosových rychlostí, je často zbytečné poskytovat velké přenosové rychlosti pro obsah, který je dlouhý pod 30 sekund. V době, kdy přehrávač uzamkne svůj heuristický algoritmus na správnou přenosovou rychlost pro přehrávání na základě síťových podmínek, bude soubor streamován.

Kromě toho některé přehrávače ve výchozím nastavení vyrovnávací paměť až tři segmenty videa. Každý segment může mít délku 2 až 6 sekund. U videí s velmi krátkým formátem bude přehrávač pravděpodobně ukládat do vyrovnávací paměti a začít přehrávat první vybranou přenosovou rychlost sady s adaptivní přenosovou rychlostí. Z tohoto důvodu doporučujeme použít soubor MP4 s jednou přenosovou rychlostí a nahrát ho do prostředku, pokud potřebujete generování manifestu HLS nebo DASH. Podrobnosti o tom, jak toho dosáhnout, najdete v odpovědi na otázku "Můžu streamovat existující soubory MP4, které jsou předkódované nebo kódované v jiném řešení?" v části věnované balení a doručování.

Soubory ve formátu HLS nebo DASH je nutné doručovat pouze v případě, že chcete využívat možnosti těchto protokolů. U datových proudů s jednou přenosovou rychlostí můžou nabídnout hodně – například rychlejší vyhledávání, podporu správy digitálních práv (DRM) a větší potíže při stahování přes adresu URL (ale stále je to možné!) než progresivní stahování souborů MP4 v úložišti objektů blob. Další výhodou je podpora titulků pro VTT a IMSC1. Kromě toho možnost pozdního svázání dalších zvukových verzí nebo dabingů v alternativních jazycích dělá tuto volbu v některých situacích cennou volbou.

Pokud hledáte způsoby, jak pomocí kodéru Media Services dělat věci, jako je otočení videa, podlipka videa, spojování videí, vytváření miniatur a spritů, máme na stránce Ukázky kódu spoustu ukázek kódu. Mezi dostupné ukázkové jazyky patří Node.JS, Python, .NET a Java.

Živá událost služby Media Services je proces ingestování kanálů živého videa a jejich vysílání prostřednictvím protokolu RTMPS nebo technologie Smooth Streaming. Další informace najdete v tématu Živé události a živé výstupy ve službě Media Services.

Prvním krokem je volba místního kodéru. Poskytli jsme příklady pro vytvoření živé události pomocí Wirecastu a OBS. Pokud chcete raději začít přehledem živých událostí Media Services, přečtěte si téma Typy živých událostí.

Azure Media Service poskytuje video, zvuk a text v různých protokolech. Když publikujete živý stream pomocí MPEG-DASH nebo HLS/CMAF, služba spolu s videem a zvukem doručí přepsaný text v jazyce TTML kompatibilním s IMSC1.1. Další informace najdete v tématu Živý přepis.

Živé události můžete monitorovat přihlášením k odběru Azure Event Grid událostí. Další informace najdete ve schématu událostí Event Gridu. Máte tyto možnosti:

• Přihlaste se k odběru událostí Microsoft.Media.LiveEventEncoderDisconnected na úrovni streamu a sledujte, jestli na chvíli nepřijdou žádná opětovná připojení, aby se živá událost zastavila a odstranila.
• Přihlaste se k odběru událostí prezenčního signálu na úrovni sledování. Pokud u všech tras dojde k poklesu příchozí přenosové rychlosti na 0 nebo pokud se už nezvyšuje poslední časové razítko, můžete živou událost bezpečně vypnout. Události prezenčního signálu přicházejí pro každou stopu každých 20 sekund, takže to může být trochu podrobné.

Ne, nemůžete snadno použít stejnou adresu URL streamování, pokud zastavíte a spustíte živou událost. Pokaždé, když vytvoříte a publikujete nový živý výstup (a asset), použije se pro nový lokátor nová adresa URL streamování (GUID). Jste si tak jistí, že nedojde k žádnému konfliktu mezipaměti v koncovém bodu streamování a v síti pro doručování obsahu (CDN). Adresy URL streamování můžete připravit (a znát) předem, protože můžete vynutit konkrétní identifikátor GUID pro lokátor streamování a pak určit název manifestu, který se má použít pro živý výstup.

Řekněme, že se rozhodnete použít GUID 1a7ed69e-a361-433d-8a56-29c61872744f pro živý výstup, který zítra vytvoříte. Když nastane den, spustíte živou událost a vytvoříte živý výstup. Můžete se rozhodnout pro manifest použít "conference1" a vynutit identifikátor GUID pro lokátor.

Adresa URL streamování je předvídatelná a je http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Stejný živý výstup nebo prostředek nemůžete opakovaně použít. Kombinaci živého výstupu a prostředku si můžete představit jako záznam pásky. Po nahrání živého výstupu do prostředku ho nemůžete znovu použít pro jinou nahrávku. Pokud to znovu uděláte, dojde ke konfliktu nebo přepsání objektů blob. Pokud neplánujete úplné vymazání objektů blob v účtu úložiště a úplné vymazání CDN, dojde k problémům. Problémy budou pravděpodobně i nadále, protože fragmenty už jsou uložené v podřízené mezipaměti ve službě CDN nebo v mezipaměti klientských zařízení (například v mezipaměti prohlížeče).

Jedním z nejběžnějších důvodů je, že nemáte koncový bod streamování, ze kterého se pokoušíte přehrát, ve spuštěném stavu.

Koncový bod streamování ve službě Media Services představuje dynamickou službu (za běhu) balení a původu, která dokáže doručovat živý obsah a obsah na vyžádání přímo do aplikace klientského přehrávače pomocí některého z běžných protokolů streamování médií (HLS nebo DASH). Koncový bod streamování navíc poskytuje dynamické šifrování (za běhu) špičkovým systémům DRM v oboru. Další informace najdete v tématu Koncové body streamování (původ) ve službě Azure Media Services.

Pokud chcete zpřístupnit videa klientům pro přehrávání, vytvoříte lokátor streamování a pak sestavíte adresy URL pro streamování. Lokátory streamování se také používají k použití zásad streamování, které obsahují pravidla pro způsob využívání mediálních souborů.

Pokud chcete vytvořit adresu URL streamování, nejprve vytvořte lokátor streamování. Pak zřetězete název hostitele koncového bodu streamování a cestu k lokátoru streamování.

Zásady streamování umožňují definovat protokoly streamování a možnosti šifrování pro vaše lokátory streamování. Služba Media Services v3 poskytuje některé předdefinované zásady streamování. Další informace najdete v tématu Zásady streamování.

Seznam předdefinovaných zásad, které můžete použít k zahájení práce, najdete v tématu Zásady streamování.

Ujistěte se, že máte na konci cesty (za částí adresy URL /manifest) (format=m3u8-cmaf), aby server původu streamování vracel obsah HLS pro použití na zařízeních nativních pro Apple iOS. Podrobnosti najdete v tématu Doručování obsahu.

Ano, server původu Media Services (koncový bod streamování) podporuje dynamické balení souborů MP4 do formátu streamování HLS nebo DASH. Obsah ale musí být kódovaný ve formátu closed-GOP s krátkými gop v rozsahu dvou až šesti sekund. Doporučujeme následující nastavení: dvousekundové goPs, maximální délka snímku klíče a minimální vzdálenost 2 sekundy, kódování s konstantní přenosovou rychlostí (režim CBR). Podporuje se většina obsahu v tomto formátu, který je kódovaný pomocí videokodeku H.264 nebo HEVC, spolu se zvukovým formátem AAC. Můžou se podporovat i další formáty zvuku, které jsou předkódované, například Dolby DD+.

Klíčem k tomu, aby to fungovalo, je vytvoření prostředku, nahrání předem zakódovaných prostředků do kontejneru prostředku pomocí Azure Blob Storage klientských sad SDK a následné vygenerování požadovaného manifestu serveru (.ism) a souborů manifestu klienta. Podrobnosti najdete v ukázkovém projektu .NET v tématu Streamování existujících souborů MP4.

Mějte na paměti, že tento přístup má vliv na výkon, protože integrovaný kodér ve službě Media Services také generuje binární indexy (soubory .mpi), které zkrašují dobu přístupu k souborům MP4. Bez těchto souborů může server při vysokém zatížení využívat o něco více procesoru. Další informace najdete v tématu Streamování existujícího souboru MP4 s jednou přenosovou rychlostí pomocí HLS nebo Dash.

Při vertikálním navýšení kapacity pomocí tohoto přístupu byste měli monitorovat zatížení procesoru koncového bodu streamování. Pokud plánujete přejít do produkčního prostředí s velkou knihovnou souborů MP4, které jsou předem zakódované mimo Media Services, vytvořte lístek podpory, abyste mohli zkontrolovat vaši architekturu, a zeptejte se na způsoby, jak zlepšit výkon serveru původu u předkódovaného obsahu MP4.

Lokátory streamování vytvořené pomocí rozhraní API v2 budou fungovat i po vypnutí našeho rozhraní API v2. Po vytvoření dat lokátoru streamování v back-end databázi Služby Media Services neexistuje závislost na rozhraní REST API v2 pro streamování. Při vypnutí verze 2 v únoru 2024 z databáze neodebereme záznamy specifické pro verzi 2.

Existují některé vlastnosti prostředků a lokátorů vytvořených pomocí v2, ke kterým není možné získat přístup ani je aktualizovat pomocí nového rozhraní API v3. Například verze 2 zpřístupňuje rozhraní API pro soubory prostředků , které nemá ekvivalentní funkci v rozhraní API v3. Často to není problém pro většinu našich zákazníků, protože to není široce používaná funkce a stále můžete streamovat staré lokátory a odstranit je, když už nejsou potřeba.

Po migraci byste se měli vyhnout volání rozhraní API v2, abyste mohli upravovat lokátory nebo prostředky streamování.

Dynamické šifrování zajišťuje zabezpečení médií od okamžiku, kdy počítač opustí, až po uložení, zpracování a doručení. Se službou Media Services můžete živý obsah i obsah na vyžádání doručovat dynamicky šifrovaný pomocí standardu AES-128 (Advanced Encryption Standard) nebo některého ze tří hlavních systémů DRM: Microsoft PlayReady, Google Widevine a Apple FairPlay. Další informace najdete v tématu Ochrana obsahu pomocí dynamického šifrování Media Services.

Zákazníci se často ptají, jestli by měli používat šifrování AES nebo systém DRM. Hlavní rozdíl mezi těmito dvěma systémy spočívá v tom, že při šifrování AES se klíč obsahu přenáší do klienta přes protokol TLS. Klíč se při přenosu zašifruje bez jakéhokoli dalšího šifrování ("v nezašifrované"). V důsledku toho je klíč, který se používá k dešifrování obsahu, přístupný klientskému přehrávači a dá se zobrazit v trasování sítě na klientovi ve formátu prostého textu. Šifrování pomocí nešifrovaného klíče AES-128 je vhodné pro případy použití, kdy je divák důvěryhodnou stranou (například šifrování firemních videí distribuovaných v rámci společnosti, aby je mohli prohlížet zaměstnanci).

Systémy DRM, jako je PlayReady, Widevine a FairPlay, poskytují další úroveň šifrování klíče, který se používá k dešifrování obsahu, v porovnání s nezašifrovaný klíč AES-128. Klíč obsahu je zašifrovaný do klíče chráněného modulem runtime DRM, a navíc k šifrování na úrovni přenosu, které poskytuje protokol TLS. Dešifrování se zpracovává v zabezpečeném prostředí na úrovni operačního systému, kde je pro uživatele se zlými úmysly obtížnější napadnout. DrM doporučujeme pro případy použití, kdy prohlížeč nemusí být důvěryhodnou stranou a vy potřebujete nejvyšší úroveň zabezpečení.

Nemusíte používat žádného konkrétního zprostředkovatele tokenů, jako je Azure Active Directory (Azure AD). Pomocí asymetrického šifrování pomocí klíče můžete vytvořit vlastního zprostředkovatele JWT (tzv. služba tokenů zabezpečení neboli STS). Ve vlastní službě TOKENS můžete přidávat deklarace identity založené na obchodní logice.

Ujistěte se, že vystavitel, cílová skupina a deklarace identity přesně odpovídají tomu, co je v JWT, a hodnotou použitou ContentKeyPolicyRestriction v ContentKeyPolicy.

Další informace najdete v tématu Ochrana obsahu pomocí dynamického šifrování Služby Media Services.

V produkčním prostředí musíte mít službu zabezpečených tokenů (tj. webovou službu), která vydá token JWT při požadavku HTTPS. Pro testování můžete použít kód zobrazený v GetTokenAsync metodě definované v souboru Program.cs.

Po ověření uživatele hráč odešle žádost službě STS o takový token a přiřadí ho jako hodnotu tokenu. Můžete použít rozhraní API Azure Media Playeru.

Příklad spuštění služby TOKENS se symetrickým nebo asymetrickým klíčem najdete v nástroji JWT. Příklad přehrávače založeného na Azure Media Playeru, který používá takový token JWT, najdete v nástroji azure media test. (Rozbalte odkaz player_settings a zobrazte vstup tokenu.)

Správným přístupem je použít službu zabezpečených tokenů. V závislosti na profilu uživatele přidejte do služby STS různé deklarace identity (například "Uživatel Premium", "Základní uživatel" nebo "Uživatel bezplatné zkušební verze"). U různých deklarací identity v JWT může uživatel zobrazit jiný obsah. Pro různé obsahy ContentKeyPolicyRestriction nebo prostředky budou mít odpovídající RequiredClaims hodnotu.

Ke konfiguraci doručování licencí a klíčů a šifrování prostředků použijte rozhraní API služby Azure Media Services (jak je znázorněno v této ukázce).

Zdá se, že toto chování je záměrně ukázkové aplikace. Pokud je v offline režimu k dispozici alternativní zvuková stopa (což je případ HLS), iOS 10 i iOS 11 ve výchozím nastavení alternativní zvukové stopy. Chcete-li toto chování v offline režimu FPS kompenzovat, odeberte ze streamu alternativní zvukovou stopu. Chcete-li to provést ve službě Media Services, přidejte dynamický filtr manifestu audio-only=false. Jinými slovy, adresa URL HLS končí řetězcem .ism/manifest(format=m3u8-aapl,audio-only=false).

V závislosti na návrhu klíče mezipaměti pro síť pro doručování obsahu může být obsah uložen do mezipaměti. Vymažte mezipaměť.

Struktura stažených souborů na zařízení s iOSem vypadá jako na následujícím snímku obrazovky. Složka _keys ukládá stažené licence FPS s jedním uloženým souborem pro každého hostitele licenční služby. Složka .movpkg ukládá zvukový obsah a video.

První složka s názvem, který končí pomlčkou a číslem, obsahuje videoobsoubor. Číselná hodnota je šířka pásma ve špičce verzí videa. Druhá složka s názvem, který končí pomlčkou následovanou 0, obsahuje zvukový obsah. Třetí složka s názvem Data obsahuje hlavní seznam stop obsahu FPS. Nakonec boot.xml poskytne úplný popis obsahu složky .movpkg .

Tady je ukázkový soubor boot.xml:

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

Vzhledem k tomu, že Služba Media Services v3 umožňuje, aby prostředek měl více StreamingLocator instancí, můžete mít:

• Jedna ContentKeyPolicy instance s license_type = "persistent", ContentKeyPolicyRestriction s deklarací identity v "persistent"a její StreamingLocator instancí.
• Další ContentKeyPolicy instance s license_type="nonpersistent", ContentKeyPolicyRestriction s deklarací identity pro "nonpersistenta její StreamingLocator instancí.
• Dvě StreamingLocator instance, které mají různé ContentKey hodnoty.

V závislosti na obchodní logice vlastních tokenů zabezpečení se v tokenu JWT vydávají různé deklarace identity. Pomocí tokenu je možné získat pouze odpovídající licenci a přehrát pouze odpovídající adresu URL.

Přehled architektury DRM Widevine společnosti Google definuje tři úrovně zabezpečení. Dokumentace ke službě Azure Media Services k šabloně licence Widevine však popisuje pět úrovní zabezpečení (požadavky na odolnost klienta pro přehrávání).

Google Widevine definuje obě sady úrovní zabezpečení. Rozdíl je v úrovni využití: architektura nebo rozhraní API. V rozhraní API Widevine se používá pět úrovní zabezpečení. Licenční služba Azure Media Services Widevine deserializuje content_key_specs objekt, který obsahuje security_level, a předá ho globální službě doručování Widevine. Následující tabulka ukazuje mapování mezi těmito dvěma sadami úrovní zabezpečení.

Pomocí Služby Azure Monitor můžete sledovat, co se děje s vašimi prostředky Media Services. Další informace najdete v tématu Monitorování služby Media Services. Návody jsou uvedené na konci stránky.

Pomocí Azure Event Grid můžete monitorovat živou událost bez služby dotazování. Viz Vytváření a monitorování událostí Media Services pomocí služby Event Grid pomocí Azure Portal.

Služba Media Services funguje s mnoha přehrávači. Podívejte se na seznam kompatibilních přehrávačů médií nebo vyzkoušejte ukázky přehrávačů třetích stran.

Informace o službě Media Services a vysoké dostupnosti najdete v tématech Vysoká dostupnost s Media Services a Video na vyžádání (VOD).

Vytvořili jsme komplexního průvodce migrací z v2 na v3. Zajímá nás informace o vašich možnostech a potřebách pro migraci, takže nám můžete poskytnout zpětnou vazbu prostřednictvím githubu problému nebo lístku podpory.

Kódy chyb jsme zdokumentovali v následujících odkazech: Kódy chyb koncových bodů streamování, Kódy chyb živých událostí a Kódy chyb úloh. Pokud tam nemůžete najít odpovědi, vytvořte lístek podpory.

Přihlašovací údaje k účtu můžete resetovat pomocí Azure CLI.

Projděte si průvodce cenami služby Media Services.

Viz Kvóty a omezení služby Media Services.

Zákazníci připojují ke svým účtům Azure Media Services vlastní účty úložiště. Všechna data prostředků se ukládají v těchto přidružených účtech úložiště a zákazník řídí umístění a typ replikace tohoto úložiště.

Další data přidružená k účtu Media Services (včetně šifrovacích klíčů obsahu, ověřovacích klíčů tokenů, adres URL JobInputHttp a dalších metadat entit) se ukládají do úložiště vlastněného Microsoftem v oblasti vybrané pro účet Media Services.

Vzhledem k požadavkům na rezidenci dat v Brazílii – jižní a jihovýchodní Asii se další data účtu ukládají zónově redundantním způsobem a jsou obsažena v jedné oblasti. Pro jihovýchodní Asii jsou všechna další data účtu uložená v Singapuru. V oblasti Brazílie – jih jsou data uložená v Brazílii. V jiných oblastech než Brazílie – jih a Jihovýchodní Asie můžou být v úložišti vlastněné Microsoftem ve spárované oblasti uložená také další data účtu.

Azure Media Services je regionální služba, která neposkytuje vysokou dostupnost ani replikaci dat. Doporučujeme zákazníkům, kteří potřebují tyto funkce, aby vytvořili řešení pomocí účtů Media Services ve více oblastech. Jako vodítko je k dispozici ukázka, která ukazuje, jak vytvořit řešení pro zajištění vysoké dostupnosti s videem media services na vyžádání .