Běžné otázky týkající se Azure Media Services

Tady je seznam:

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

nedoporučujeme, abyste se pokusili zabalit REST API pro Media Services přímo do vlastního kódu knihovny. V takovém případě pro účely produkčního prostředí budete potřebovat implementovat úplnou logiku Azure Resource Manager opakování a porozumět tomu, jak spravovat dlouhodobě běžící operace v rozhraních API Správce prostředků. Klientské sady SDK pro různé jazyky – například .NET, Java, TypeScript, Python a Ruby, jsou pro vás automaticky, aby se snížila pravděpodobnost potíží s logikou opakování nebo neúspěšnými voláními rozhraní API. Kolekce post je poskytována více jako učebnní nástroj a ukazuje, co dělají klientské sady SDK na lince během vývoje s nimi.

seznam ukázek najdete v článku Media Services v3 samples .

Při použití stránkování byste měli vždy použít další odkaz k zobrazení výčtu kolekce a nezáleží na konkrétní velikosti stránky. Podrobnosti a příklady najdete v tématu filtrování, řazení a stránkování entit.

informace o použití rozhraní příkazového řádku Azure ke spárování Media Services s Azure Key Vault k šifrování dat najdete v kurzu použití Key Vault k šifrování dat do Media Servicesho účtu .

pokud chcete, aby Media Services přístup 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 části přístup k úložišti pomocí Media Services spravované identity.

viz přesunutí účtu Media Services mezi předplatnými.

přečtěte si téma řízení přístupu na základě role v azure (Azure RBAC) pro účty Media Services.

Media Services asset je kontejner Azure Storage účtu, který se používá pro každý videosoubor, který nahráváte. Má jedinečný identifikátor, který se používá pro transformace a jiné operace. viz assety v Azure Media Services v3.

Pokaždé, když chcete nahrát mediální soubor a dělat s ním něco, jako je kódování nebo streamování, vytvoříte Asset pro uložení mediálního souboru a přidružených souborů. Assety se automaticky vytvoří, pokud použijete Azure Portal. Pokud nepoužíváte portál k nahrávání souborů, musíte nejdřív vytvořit Asset. Další informace najdete v tématu Vytvoření assetu.

společné formáty kódování jsou k dispozici ve službě Media Services Standard Encoder. Seznam všech formátů najdete v tématu formáty a kodeky Standard Encoder.

Úlohu můžete v Azure Portal vytvořit pomocí rozhraní příkazového řádku Azure, REST nebo jakékoli sady SDK. podívejte se na ukázky Media Services pro jazyk, kterému dáváte přednost.

Ano. Viz kódování s automaticky generovaným žebříkem přenosové rychlosti.

Ano. Media Services může na videu provádět analýzu dvou průchodů. Pak může na základě obsahu videa doporučit nastavení, nastavení rozlišení a kódování na nejvyšší adaptivní přenosové rychlosti. Další informace najdete v tématu Jak používat přednastavení kódování zohledňující obsah.

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 generuje manifest serveru (. ISM) a manifest klienta (. ISMC), najdete v odpovědi na otázku "mohu streamovat stávající soubory MP4, které jsou předem zakódované nebo zakódované v jiném řešení?" v části o balení a doručování. Tato odpověď také popisuje dopad na výkon zdroje.

Nedoporučujeme ji. Velmi krátký obsah, který je kratší než minuta nebo dvě v době trvání, není ideální pro streamování s adaptivní přenosovou rychlostí. Pokud máte v úmyslu streamovat velmi krátké soubory, doporučujeme, abyste obsah předem zakódovat do formátu, který je snadno streamovaná s jednou přenosovou rychlostí.

Vzhledem k tomu, že většina přehrávačů adaptivní přenosové rychlosti potřebuje čas do vyrovnávací paměti více segmentů videa a zároveň čas potřebný k analýze šířky pásma sítě před tím, než se posune nahoru nebo dolů, se dá použít žebřík s adaptivní přenosovou rychlostí, často je nepotřebné poskytnout velké množství přenosů obsahu, který je kratší než 30 sekund. V době, kdy hráč zamkne svůj Heuristický algoritmus na pravé přenosové rychlosti pro přehrávání na základě podmínek sítě, bude soubor streamování dokončeno.

Kromě toho některé přehrávače standardně ukládají do vyrovnávací paměti až do tří segmentů videa. Každý segment může být dlouhý 2 až šest sekund. V případě velmi krátkých videí je přehrávač pravděpodobně ve vyrovnávací paměti a zahájí přehrávání první vybrané přenosové rychlosti sady s adaptivní přenosovou rychlostí. Z tohoto důvodu doporučujeme použít soubor MP4 s jednou přenosovou rychlostí a odeslat ho do assetu, pokud potřebujete generování manifestu HLS nebo POMLČKou. Podrobnosti o tom, jak toho dosáhnout, najdete v odpovědi na otázku mohu streamovat stávající soubory MP4, které jsou předem kódované nebo kódované v jiném řešení? " v části o balení a doručování.

Soubory je potřeba doručovat v HLS nebo POMLČKovém formátu jenom v případě, že chcete využívat výhod těchto protokolů. U datových proudů s jednou přenosovou rychlostí může stále docházet k většímu množství, jako je rychlejší hledání, podpora DRM (Správa digitálních práv) a zvýšení obtížnosti při stahování přes adresu URL (ale stále možná!) než ke progresivnímu stažení MP4 v BLOB Storage. Podpora popisků pro VTT a IMSC1 je další výhodou. Kromě toho je možnost pozdní vazby dalších zvukových verzí nebo Dubbings v alternativních jazycích, takže v některých situacích je vhodná.

Media Services živá událost je proces ingestování živých informačních kanálů a jejich vysílání prostřednictvím protokolu rtmp nebo Smooth Streaming. Další informace najdete v tématu živé události a živé výstupy v Media Services.

Prvním krokem je výběr místního kodéru. Poskytli jsme příklady pro vytvoření živé události s Wirecast a OBS. pokud byste chtěli začít s přehledem Media Services živé události, přečtěte si téma typy událostí typu live.

Služba Azure Media Service nabízí video, zvuk a text v různých protokolech. Když publikujete živý datový proud pomocí MPEG-POMLČKy nebo HLS/CMAF a pak společně s videem a zvukem, služba doručí text přepisu v TTML kompatibilním s IMSC 1.1. Další informace najdete v tématu živý přepis.

Můžete monitorovat živé události tím, že se přihlásíte k odběru Azure Event Gridch událostí. Další informace najdete v tématu schéma události Event Grid. Máte tyto možnosti:

• Přihlaste se k odběru událostí Microsoft. Media. LiveEventEncoderDisconnected na úrovni datového proudu a sledujte, že v průběhu chvilky nejsou žádné znovu navázány, aby se zastavila a odstranila živá událost.
• Přihlaste se k odběru událostí prezenčního signálu na úrovni sledování. Pokud se u všech stop přestanou příchozí přenosové rychlosti na 0 nebo když se poslední časové razítko nezvyšuje, můžete živou událost bezpečně vypnout. Události heartbeat přicházejí pro každou stopu každých 20 sekund, takže to může být trochu podrobné.

Ne, pokud zastavíte a spustíte živou událost, nemůžete snadno použít stejnou adresu URL streamování. Při každém vytvoření a publikování nového živého výstupu (a prostředku) se pro nový lokátor použije nová adresa URL streamování (GUID). Tím jste si jisti, že koncový bod streamování a síť pro doručování obsahu (CDN) nebudou mít žádný konflikt mezipaměti. Adresy URL streamování si můžete připravit (a znát) předem, protože můžete vynutit konkrétní identifikátor GUID lokátoru streamování a pak rozhodnout, který název manifestu 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ý vytvoříte zítra. 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 lokátoru.

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

Stejný živý výstup nebo prostředek nemůžete opakovaně používat. Kombinaci živého výstupu a aktiva si představte jako záznam pásky. Po zaznamenání živého výstupu do assetu ho nemůžete znovu použít pro jinou nahrávku. Pokud to budete dělat znovu, dojde ke konfliktu nebo přepsání objektů blob. Pokud nemáte v plánu úplně vyprázdnit objekty blob v účtu úložiště a CDN úplně vymazat, budou mít problémy. Pravděpodobně budou i nadále problémy, protože fragmenty jsou už uložené v podřízené mezipaměti v 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.

V Media Services koncový bod streamování představuje dynamickou (za běhu) balení a službu 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í jednoho z běžných protokolů streamovacích médií (HLS nebo DASH). Kromě toho koncový bod streamování poskytuje dynamické šifrování (za běhu) předním systémům DRM v oboru. Další informace najdete v tématu Koncové body streamování (zdroj) v Azure Media Services.

Aby byla videa klientům k dispozici pro přehrávání, vytvoříte lokátor streamování a pak vytvoří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 používání mediálních souborů.

Pokud chcete vytvořit adresu URL streamování, nejprve vytvořte lokátor streamování. Pak zřetězit název hostitele koncového bodu streamování a cestu lokátoru streamování. Viz Vytvoření lokátoru streamování a adres URL pro sestavení.

Zásady streamování umožňují definovat protokoly streamování a možnosti šifrování pro lokátory streamování. 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 na konci cesty (za částí adresy URL /manifest) máte (format=m3u8-cmaf), aby server původu streamování vrátil obsah HLS ke spotřebě 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 gopy v rozsahu dvou až šesti sekund. Doporučujeme následující nastavení: dvousekundové standardy GOP, maximální snímek 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ý prostřednictvím kodeku videa H.264 nebo HEVC, spolu se zvukovým formátem AAC. Můžou být podporované i další předkódované zvukové formáty, jako je do do do dd+.

Klíčem k tomu, aby to fungovalo, je vytvořit asset, nahrát předkódované prostředky do kontejneru prostředku pomocí klientských sdk služby Azure Blob Storage a pak vygenerovat požadovaný manifest serveru (.ism) Storage soubory 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 použití tohoto přístupu má vliv na výkon, protože integrovaný kodér v Media Services také generuje binární indexy (soubory .mpi), které zlepšují dobu přístupu k souborům MP4. Bez těchto souborů může server při vysokém zatížení používat o něco větší procesor. Další informace najdete v tématu Streamování existujícího souboru MP4 s jednou přenosovou rychlostí pomocí HLS nebo Dash.

Při škálování tímto přístupem 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, zaprovřete lístek podpory, aby se vaše architektura prozkousovala, a ptejte se na způsoby, jak zlepšit výkon serveru původu předkódovaného obsahu MP4.

Dynamické šifrování zabezpečuje vaše média od okamžiku, kdy opouští váš počítač, a to až po uložení, zpracování a doručení. S Media Services můžete dynamicky doručovat živý obsah a obsah na vyžádání šifrovaný pomocí standard AES (Advanced Encryption Standard) (AES-128) nebo libovolného ze tří hlavních systémů DRM: Microsoft PlayReady, Google Widevine a Apple FairPlay. Další informace najdete v tématu Ochrana obsahu pomocí Media Services dynamického šifrování.

Zákazníci se často ptá, jestli by měli použít š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ášejí do klienta přes protokol TLS. Klíč je při přenosu zašifrovaný bez dalšího šifrování ("v vymazání"). V důsledku toho je klíč, který se používá k dešifrování obsahu, přístupný klientskému přehrávači a lze ho zobrazit v trasování sítě na klientovi v prostém textu. Šifrování s jasným klíčem AES-128 je vhodné pro případy použití, kdy je divák důvěryhodnou stranou (například šifrování podnikových videí distribuovaných v rámci společnosti, aby je zaměstnanci prohlíželi).

Systémy DRM, jako jsou 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šifritelným klíčem AES-128. Klíč obsahu se kromě šifrování na úrovni přenosu, které protokol TLS poskytuje, šifruje na klíč chráněný modul runtime DRM. 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 v případech, kdy divák nemusí být důvěryhodnou stranou a potřebujete nejvyšší úroveň zabezpečení.

Nemusíte používat žádného konkrétního poskytovatele tokenů, jako je Azure Active Directory (Azure AD). Pomocí asymetrického šifrování klíčů můžete vytvořit vlastního zprostředkovatele JWT (tzv. Secure Token Service nebo STS). Ve vlastních STS můžete přidat deklarace identity na základě vaší obchodní logiky.

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

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

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

Po ověření uživatele hráč předá službě STS žádost o takový token a přiřadí ji jako hodnotu tokenu. Můžete použít rozhraní AZURE MEDIA PLAYER API.

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

Správným přístupem je použití služby tokenů zabezpečení. V STS v závislosti na profilu uživatele přidejte různé deklarace identity (například "Premium User", "Basic User" nebo "Free Trial User"). S různými deklaracemi identity v JWT může uživatel zobrazit jiný obsah. Pro jiný obsah nebo prostředky ContentKeyPolicyRestriction bude mít odpovídající RequiredClaims hodnotu.

Pomocí Azure Media Services API můžete nakonfigurovat doručování licencí nebo klíčů a šifrovat prostředky (jak je znázorněno v této ukázce).

Další informace naleznete v tématu:

• Přehled ochrany obsahu
• Návrh systému ochrany obsahu s více variantami DRM s využitím řízení přístupu

Toto chování se jeví jako návrh ukázkové aplikace. Pokud je v offline režimu k dispozici alternativní zvuková stopa (což platí pro HLS), výchozí nastavení pro iOS 10 i iOS 11 je alternativní zvuková stopa. Pokud chcete toto chování kompenzovat v offline režimu FPS, odeberte alternativní zvukové stopy ze streamu. Pokud to chcete udělat Media Services přidejte filtr dynamického manifestu audio-only=false. Jinými slovy, adresa URL HLS končí na .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. Vyprázdnit mezipaměť.

Stažená struktura souborů na zařízení se systémem iOS 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ý a video obsah.

První složka s názvem, který končí spojovníkem následovaným číslem, obsahuje obsah videa. Číselná hodnota je šířka pásma ve špičce pro verze videa. Druhá složka s názvem, který končí čárkou následovanou 0, obsahuje zvukový obsah. Třetí složka s názvem data obsahuje hlavní seznam skladeb obsahu FPS. Nakonec boot.xml poskytuje úplný popis obsahu složky . movpkg .

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

vzhledem k tomu, že Media Services v3 umožňuje assetu mít více StreamingLocator instancí, můžete mít:

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

V závislosti na obchodní logice vlastní služby STS se v tokenu JWT vydávají různé deklarace identity. U tokenu lze získat pouze odpovídající licenci a přehrát lze pouze odpovídající adresu URL.

Přehled architektury DRM Google Widevine definuje tři úrovně zabezpečení. dokumentace Azure Media Services v šabloně licence Widevine ale 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í. služba Azure Media Services Widevine license deserializace content_key_specs objekt, který obsahuje security_level , a předá ho službě Widevine global delivery service. Následující tabulka ukazuje mapování mezi dvěma sadami úrovní zabezpečení.

využijte Azure Monitor k udržení přehledu o tom, co se děje s vašimi prostředky Media Services. Další informace najdete v tématu monitorování Media Services. návody zahrnují monitorování Media Services metriky a monitorování Media Services diagnostických protokolů.

Pomocí Azure Event Grid můžete monitorovat živou událost bez služby cyklického dotazování. příručky s postupy zahrnují vytváření a monitorování Media Servicesch událostí pomocí Event Grid pomocí Azure Portal a vytváření a monitorování Media Services událostí s Event Grid pomocí Azure CLI.

Media Services funguje s Azure Media Player, Shaka a Video.js. podívejte se na dokumentaci Azure Media Player, jak používat přehrávač Shaka s Azure Media Servicesnebo jak používat Video.js player se Azure Media Services.

informace o Media Services a vysoké dostupnosti najdete v tématu vysoká dostupnost pomocí Media Services a videa na vyžádání (VOD).

Vytvořili jsme komplexní průvodce migrací z verze V2 na V3. zajímá vás o vaše možnosti migrace a o potřebách, takže můžete zdarma poskytovat zpětnou vazbu prostřednictvím GitHubho lístku pro vydání nebo podporu.

Popsali jsme chybové kódy v následujících odkazech: streamování chybových kódů koncových bodů, kódů chyb živé událostia chybových kódů úlohy. Pokud tam nenajdete odpovědi, vytvořte prosím lístek podpory.

Přihlašovací údaje k účtu můžete resetovat pomocí rozhraní příkazového řádku Azure CLI.

podívejte se na článek s cenami Media Services.

viz Media Services kvóty a omezení.

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

další data přidružená k Media Servicesmu účtu (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ých společností Microsoft v oblasti vybrané pro účet Media Services.

S ohledem na požadavky na umístění dat v oblasti Brazílie – jih a jihovýchodní Asie se data dalších účtů ukládají v rámci redundantní zóny a jsou obsažena v jedné oblasti. V jihovýchodní Asie se všechna data dalších účtů ukládají v Singapuru. V oblasti Brazílie – jih jsou data uložená v Brazílii. V oblastech, které jsou jiné než Brazílie – jih a jihovýchodní Asie, mohou být v úložišti vlastněných společností Microsoft uloženy také další data účtu v spárované oblasti.

Azure Media Services je místní služba a neposkytuje vysokou dostupnost nebo replikaci dat. doporučujeme, aby zákazníci, kteří potřebují tyto funkce, mohli vytvořit řešení pomocí Media Services účtů v několika oblastech. ukázka, která ukazuje, jak vytvořit řešení pro vysokou dostupnost s Media Services video na vyžádání je k dispozici jako průvodce.