Az Azure Media Services szolgáltatással kapcsolatos gyakori kérdések

Az Azure Media Services kivonási útmutatójának megtekintése

Íme egy lista:

• OpenAPI-specifikáció (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• Ugrás

Nem javasoljuk, hogy próbálja meg közvetlenül a saját kódtárkódjába csomagolni a Media ServicesHEZ készült REST API-t. Az éles környezetben való megfelelő működéshez a teljes Azure-Resource Manager újrapróbálkozási logikát kell implementálnia, és meg kell értenie, hogyan kezelheti a hosszú ideig futó műveleteket Resource Manager API-kban. A különböző nyelvek ügyféloldali SDK-jai – például .NET, Java, TypeScript, Python és Ruby – automatikusan kezelik ezt, így csökkentve az újrapróbálkozással vagy a sikertelen API-hívásokkal kapcsolatos problémák esélyét.

Tekintse meg a mintalapokat. A fiókokhoz, az eszközökhöz, az élő streameléshez, a VOD-streameléshez, a tartalomvédelemhez, a kódoláshoz, az elemzéshez és a játékosok használatához vannak minták.

Lapozás használatakor mindig a következő hivatkozást kell használnia a gyűjtemény számbavételéhez, és nem egy adott oldalmérettől függ. Részletekért és példákért lásd: Szűrési, rendezési és lapozási entitások.

A Media Services és az Azure Key Vault Az adatok titkosítása Key Vault kulccsal történő titkosítása Media Services-fiókba című oktatóanyagban talál további információt arról, hogy az Azure CLI-vel párosítható-e a Media Services és az Azure Key Vault.

Ha azt szeretné, hogy a Media Services hozzáférjen egy tárfiókhoz, ha a tárfiók úgy van konfigurálva, hogy blokkolja az ismeretlen IP-címekről érkező kéréseket, kövesse a Media Services által felügyelt identitással rendelkező Tárterület elérése című témakör lépéseit.

Lásd: Media Services-fiók áthelyezése előfizetések között.

Lásd: Azure-beli szerepköralapú hozzáférés-vezérlés (Azure RBAC) a Media Services-fiókokhoz.

A Media Services a következő beépített szerepköröket határozza meg:

• Media Services-fiókadminisztrátor
• Media Services Media Operator
• Media Services-szabályzat rendszergazdája
• Media Services streamvégpontok rendszergazdája
• Media Services élő események rendszergazdája

Ezeket a szerepköröket a Media Services-fiókok Azure szerepköralapú hozzáférés-vezérlése (Azure RBAC) ismerteti.

Ezek a szerepkörök részletes hozzáférést biztosítanak egy Media Services-fiókhoz. A Media Services-fiókokhoz való hozzáférés engedélyezéséhez a "Tulajdonos" vagy a "Közreműködő" szerepkör használható. A Media Services egy régebbi API-val rendelkezik az elavult elérési úton, amely nem támogatja a részletes hozzáférés-vezérlést. Azok az ügyfelek, akik részletes hozzáférés-vezérlést igényelnek, ne válassza a "Klasszikus API-k engedélyezése" lehetőséget a Media Services-fiók portálon történő létrehozásakor (vagy a 2020-05-01 API-verzió használata esetén, ha az API-t használják fiókok létrehozásához).

A következő beépített Azure Policy a régi API-t támogató fiókok létrehozásának letiltására használható: Le kell tiltani az örökölt v2 API-hoz hozzáférést engedélyező Azure Media Services-fiókokat – Microsoft Azure

A Media Services-objektum egy Azure Storage-fióktároló, amelyet minden feltöltött videófájlhoz használnak. Egyedi azonosítóval rendelkezik, amelyet átalakításokhoz és más műveletekhez használnak. Lásd: Eszközök az Azure Media Services v3-ban.

Minden alkalommal, amikor fel szeretne tölteni egy médiafájlt, és valamilyen műveletet szeretne végezni vele, például kódolást vagy streamelést, létre kell hoznia egy objektumot a médiafájl és a társított fájlok tárolásához. Ha a Azure Portal használja, a rendszer automatikusan létrehozza az eszközöket. Ha nem a portált használja fájlok feltöltésére, először létre kell hoznia egy objektumot.

A Media Services Standard Encoder gyakran használt kódolási formátumai érhetők el. Az összes formátum listáját a Standard Kódolók formátumai és kodekei című témakörben találja.

A Azure Portal az Azure CLI, a REST vagy bármely SDK használatával hozhat létre feladatot. A kívánt nyelvhez tekintse meg a Media Services-mintákat .

Igen. Lásd: Kódolás automatikusan létrehozott bitsebesség-létrával.

Igen. A Media Services kétlépéses elemzést végezhet egy videón. Ezután a videó tartalma alapján javasolhatja a legjobb adaptív sávszélesség-készletet, a felbontásokat és a kódolási beállításokat.

Igen. Az előre kódolt és a kiszolgálói jegyzékfájlt (.ism) és az ügyféljegyzéket (.ismc) létrehozó egybites sebességű MP4-fájl feltöltését bemutató mintaalkalmazás részleteiért és hivatkozásaiért tekintse meg a csomagolásról és kézbesítésről szóló szakaszban a "Streamelhetem a meglévő MP4-fájlokat, amelyek előre vannak kódolva vagy más megoldásban vannak kódolva?" kérdésre. Ez a válasz azt is ismerteti, hogy milyen hatással van a teljesítmény a forrásra.

Nem javasoljuk. A nagyon rövid, egy-két percnél rövidebb tartalom nem ideális adaptív sávszélességű streameléshez. Ha nagyon rövid formátumú fájlokat szeretne streamelni, javasoljuk, hogy előre kódolja a tartalmat olyan formátumba, amely egyszerűen streamelhető egyetlen sávszélesség használatával.

Mivel a legtöbb adaptív sávszélességű játékosnak időre van szüksége a videó több szegmensének pufferelésére, valamint a hálózati sávszélesség elemzésére, mielőtt az adaptív bitsebesség-létrán "felfelé vagy lefelé" váltanak, gyakran felesleges sok bitrátát biztosítani a 30 másodpercnél hosszabb tartalomhoz. Mire a lejátszó zárolja a heurisztikus algoritmust a megfelelő sávszélességen a hálózati feltételek alapján történő lejátszáshoz, a fájl streamelése befejeződik.

Emellett egyes játékosok alapértelmezés szerint legfeljebb három videószegmenst pufferelnek. Minden szegmens 2–6 másodperc hosszú lehet. A nagyon rövid formátumú videók esetében a lejátszó valószínűleg puffereli és elkezdi az adaptív bitsebesség-készlet első kiválasztott bitsebességének lejátszását. Ezért azt javasoljuk, hogy használjon egy egybites mp4-fájlt, és töltse fel egy objektumba, ha HLS- vagy DASH-jegyzéklétrehozásra van szüksége. Ennek eléréséről a csomagolásról és a kézbesítésről szóló szakaszban talál választ a "Meglévő MP4-fájlok streamelhetők, amelyek előre vannak kódolva vagy egy másik megoldásban vannak kódolva?" című szakaszban.

A fájlokat csak akkor kell HLS vagy DASH formátumban kézbesíteni, ha ki szeretné használni a protokollok képességeit. Az egybites streamek esetében továbbra is sok mindent nyújthatnak – ilyen például a gyorsabb keresés, a digitális jogkezelés (DRM) támogatása, valamint az URL-címmel (de továbbra is lehetséges!) való letöltési nehézség, mint egy progresszív MP4-letöltés a Blob Storage-ban. A VTT és az IMSC1 felirattámogatása egy másik előny. Emellett a további hangmegjelenítések vagy más nyelveken történő szinkronizálások késői kötésének képessége bizonyos helyzetekben értékes választássá teszi ezt.

Ha egy Media Services-kódolót szeretne használni a videók elforgatásához, a videók alcsomópontjához, a videók összefűzéséhez, miniatűrök és spritesek létrehozásához, akkor rengeteg kódmintát találhat a Kódminták lapon. Az elérhető mintanyelvek közé tartozik a Node.JS, a Python, a .NET és a Java.

A Media Services élő eseménye az élő videócsatornák betöltésének és az RTMPS protokollon vagy a Smooth Streamingen keresztül történő közvetítésének folyamata. További információ: Élő események és élő kimenetek a Media Servicesben.

Az első lépés egy helyszíni kódoló kiválasztása. Példákat adtunk egy élő esemény létrehozásához a Wirecast és az OBS használatával. Ha inkább a Media Services élő eseményeinek áttekintésével szeretne kezdeni, tekintse meg az Élő eseménytípusok című témakört.

Az Azure Media Service különböző protokollokban biztosít videókat, hangokat és szöveget. Amikor MPEG-DASH vagy HLS/CMAF használatával teszi közzé az élő streamet, akkor a szolgáltatás a videóval és a hanggal együtt IMSC1.1-kompatibilis TTML-ben kézbesíti az átírt szöveget. További információ: Élő átírás.

Az élő eseményeket Azure Event Grid eseményekre való feliratkozással figyelheti. További információ: Event Grid eseményséma. A következő lehetőségek közül választhat:

• Iratkozzon fel a Microsoft.Media.LiveEventEncoderDisconnected eseményekre, és figyelje meg, hogy az élő esemény leállításához és törléséhez egy ideig nem jönnek létre újracsatlakozások.
• Iratkozzon fel a sávszintű szívverési eseményekre. Ha az összes sáv bejövő bitráta 0-ra csökken, vagy az utolsó időbélyeg már nem növekszik, biztonságosan leállíthatja az élő eseményt. A szívverési események minden számhoz 20 másodpercenként érkeznek, ezért lehet, hogy kicsit részletesek.

Nem, nem használhatja egyszerűen ugyanazt a streamelési URL-címet, ha leállítja és elindít egy élő eseményt. Minden alkalommal, amikor új élő kimenetet (és objektumot) hoz létre és tesz közzé, egy új streamelési URL-címet (GUID) használ a rendszer az új lokátorhoz. Így biztosan nem lesz gyorsítótár-ütközés a streamvégponton és a tartalomkézbesítési hálózaton (CDN). Előre előkészítheti (és megismerheti) a streamelési URL-címeket, mert kényszeríthet egy adott GUID-t a streamelési lokátorhoz, majd eldöntheti, hogy a jegyzékfájl nevét használja-e az élő kimenethez.

Tegyük fel, hogy úgy dönt, hogy a GUID 1a7ed69e-a361-433d-8a56-29c61872744f azonosítót használja a holnap létrehozandó élő kimenethez. Amikor eljön a nap, elindítja az élő eseményt, és létrehoz egy élő kimenetet. Dönthet úgy, hogy a "conference1" kifejezést használja a jegyzékhez, és kényszeríti a guid azonosítót a lokátorhoz.

A streamelési URL-cím kiszámítható, és a következő http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest: .

Nem használhatja fel többször ugyanazt az élő kimenetet vagy objektumot. Képzelje el az élő kimenet és az objektum kombinációját szalagos felvételként. Miután az élő kimenetet rögzítette az objektumhoz, nem használhatja fel egy másik felvételhez. Ha ismét ezt teszi, blobütközés vagy felülírás történik. Ha nem tervezi teljesen kiüríteni a tárfiókban lévő blobokat, és teljesen törli a CDN-t, problémák merülnek fel. Valószínűleg továbbra is problémák merülnek fel, mert a töredékek már a CDN-en vagy az ügyféleszköz-gyorsítótárakban (például a böngésző gyorsítótárában) vannak gyorsítótárazva.

Az egyik leggyakoribb ok az, hogy nem rendelkezik azzal a streamvégpontmal, amelyről vissza szeretne játszani a futó állapotban.

A Media Servicesben a streamvégpontok egy dinamikus (igény szerinti) csomagolási és forrásszolgáltatást jelentenek, amely közvetlenül az ügyféllejátszó alkalmazásba képes eljuttatni az élő és igény szerinti tartalmakat az egyik gyakori streamelési médiaprotokoll (HLS vagy DASH) használatával. Emellett a streamvégpont dinamikus (igény szerinti) titkosítást biztosít az iparágvezető DRM-rendszerek számára. További információ: Streamvégpontok (forrás) az Azure Media Servicesben.

Ha elérhetővé szeretné tenni a videókat az ügyfelek számára a lejátszáshoz, hozzon létre egy streamelési lokátort, majd hozzon létre streamelési URL-címeket. A streamelési lokátorokat a médiafájlok felhasználására vonatkozó szabályokat tartalmazó streamelési szabályzatok alkalmazására is használják.

Streamelési URL-cím létrehozásához először létre kell hoznia egy streamelési lokátort. Ezután összefűzheti a streamvégpont gazdagépnevét és a streamelési lokátor elérési útját.

A streamelési szabályzatok lehetővé teszik a streamelési protokollok és a titkosítási beállítások meghatározását a streamelési lokátorokhoz. A Media Services v3 előre definiált streamelési szabályzatokat biztosít. További információ: Streamelési szabályzatok.

Az első lépésekhez használható előre definiált szabályzatok listáját a Streamelési szabályzatok című témakörben találja.

Győződjön meg arról, hogy ( format=m3u8-cmaf) van az elérési út végén (az URL /manifest része után), hogy tájékoztassa a streamelő forráskiszolgálót, hogy adja vissza a HLS-tartalmat az Apple iOS natív eszközein való használat céljából. Részletekért lásd: Tartalom kézbesítése.

Igen, a Media Services forráskiszolgálója (streamvégpont) támogatja az MP4-fájlok dinamikus csomagolását HLS vagy DASH streamelési formátumba. A tartalmat azonban zárt GOP formátumban kell kódolni, a rövid GOP-k pedig 2–6 másodperces időtartamtartományban. A következő beállításokat javasoljuk: két másodperces GOP-k, kulcskeret maximális és minimális távolsága két másodperc, állandó bitsebesség kódolása (CBR mód). A H.264-en vagy HEVC videokodeken keresztül kódolt formátum legtöbb tartalma, valamint az AAC hangformátuma is támogatott. Az előre kódolt további hangformátumok is támogatottak lehetnek, például a Dolby DD+.

Ennek a munkának az a kulcsa, hogy létrehoz egy objektumot, feltölti az előre kódolt objektumokat az objektum tárolójába Azure Blob Storage ügyféloldali SDK-k használatával, majd létrehozza a szükséges kiszolgálói jegyzékfájlokat (.ism) és az ügyféljegyzékfájlokat. Részletekért lásd a .NET-mintaprojektet a Meglévő MP4-fájlok streamelése című témakörben.

Ne feledje, hogy ennek a megközelítésnek a használata teljesítménybeli következményekkel jár, mivel a Media Services beépített kódolója bináris indexeket (.mpi fájlokat) is létrehoz, amelyek javítják az MP4-fájlok hozzáférési idejét. Ezek nélkül a fájlok nélkül a kiszolgáló valamivel több processzort használhat nagy terhelés esetén. További információ: Meglévő egybites átviteli sebességű MP4-fájl streamelése HLS vagy Dash használatával.

Ha ezzel a módszerrel skáláz fel, figyelnie kell a streamvégpont processzorterhelését. Ha a Media Servicesen kívül előre kódolt MP4-fájlok nagy tárával szeretne éles környezetben üzemelni, küldjön egy támogatási jegyet az architektúra áttekintéséhez, és kérdezze meg, hogyan javíthatja az előre kódolt MP4-tartalom forráskiszolgálói teljesítményét.

A v2 API-val létrehozott streamelési lokátorok továbbra is működni fognak, miután a v2 API ki van kapcsolva. Miután létrejött a Streamelési lokátor adatai a Media Services háttéradatbázisában, a streameléshez nincs függőség a v2 REST API-tól. Nem távolítunk el v2-rekordokat az adatbázisból, ha a v2 2024 februárjában ki van kapcsolva.

A v2-vel létrehozott objektumok és lokátorok néhány tulajdonsága nem érhető el és nem frissíthető az új v3 API használatával. A v2 például olyan Asset Files API-t tesz elérhetővé, amely nem rendelkezik egyenértékű funkcióval a v3 API-ban. Ez gyakran nem jelent problémát a legtöbb ügyfelünk számára, mivel ez nem egy széles körben használt funkció, és továbbra is streamelheti a régi lokátorokat, és törölheti őket, ha már nincs rájuk szükség.

A migrálás után el kell kerülnie a v2 API-ra irányuló hívásokat a streamelési lokátorok vagy -objektumok módosításához.

A dinamikus titkosítás biztosítja a médiatartalmat attól az időponttól kezdve, amikor a számítógép a tároláson, feldolgozáson és kézbesítésen keresztül elhagyja a számítógépet. A Media Services segítségével dinamikusan titkosíthatja élő és igény szerinti tartalmait az Advanced Encryption Standard (AES-128) vagy a három fő DRM-rendszer bármelyikével: Microsoft PlayReady, Google Widevine és Apple FairPlay. További információ: Tartalom védelme a Media Services dinamikus titkosításával.

Az ügyfelek gyakran felmerülnek a kérdésben, hogy AES-titkosítást vagy DRM-rendszert kell-e használniuk. A két rendszer közötti fő különbség az, hogy az AES-titkosítással a tartalomkulcs TLS-en keresztül lesz továbbítva az ügyfélnek. A kulcs átvitel közben titkosítva van további titkosítás nélkül ("a szabadban"). Ennek eredményeképpen a tartalom visszafejtéséhez használt kulcs elérhető az ügyféllejátszó számára, és egyszerű szövegben tekinthető meg egy hálózati nyomkövetésben az ügyfélen. Az AES-128 egyértelmű kulcstitkosítás olyan használati esetekre alkalmas, amikor a megtekintő megbízható fél (például egy vállalaton belül terjesztett vállalati videók titkosítása az alkalmazottak számára).

Az olyan DRM-rendszerek, mint a PlayReady, a Widevine és a FairPlay, további titkosítási szintet biztosítanak a tartalom visszafejtéséhez használt kulcson, szemben az AES-128 tiszta kulcsával. A tartalomkulcs a TLS által biztosított átviteli szintű titkosítás mellett a DRM-futtatókörnyezet által védett kulcsra van titkosítva. A visszafejtést biztonságos környezetben kezelik az operációs rendszer szintjén, ahol a rosszindulatú felhasználók nehezebben támadnak. A DRM-et olyan használati esetekhez ajánljuk, amikor a megtekintő nem megbízható fél, és a legmagasabb szintű biztonságra van szüksége.

Nem kell konkrét jogkivonat-szolgáltatót használnia, például az Azure Active Directoryt (Azure AD). Aszimmetrikus kulcstitkosítással létrehozhatja saját JWT-szolgáltatóját (az úgynevezett Secure Token Service-t vagy STS-t). Az egyéni STS-ben az üzleti logikája alapján adhat hozzá jogcímeket.

Győződjön meg arról, hogy a kiállító, a célközönség és a jogcímek mindegyike pontosan megegyezik a JWT-ben található adatok és a ContentKeyPolicyRestriction alkalmazásban ContentKeyPolicyhasznált érték között.

További információ: Tartalom védelme a Media Services dinamikus titkosításával.

Éles környezetben rendelkeznie kell a Secure Token Service szolgáltatással (azaz egy webszolgáltatással), amely JWT-jogkivonatot ad ki EGY HTTPS-kéréskor. Teszteléshez használhatja a Program.cs fájlban definiált metódusban GetTokenAsync látható kódot.

A felhasználó hitelesítése után a játékos kérést küld az STS-nek egy ilyen jogkivonathoz, és hozzárendeli azt a jogkivonat értékeként. Az Azure Media Player API-t használhatja.

Ha szimmetrikus vagy aszimmetrikus kulccsal futtatja az STS-t, tekintse meg a JWT eszközt. Egy ilyen JWT-jogkivonatot használó Azure Media Player-alapú lejátszóra az Azure media test eszközben talál példát. (Bontsa ki a player_settings hivatkozást a jogkivonat bemenetének megtekintéséhez.)

A helyes módszer a Biztonságos jogkivonat-szolgáltatás használata. Az STS-ben a felhasználói profiltól függően adjon hozzá különböző jogcímeket (például "Prémium felhasználó", "Alapszintű felhasználó" vagy "Ingyenes próbaverziós felhasználó"). A JWT különböző jogcímeivel a felhasználó különböző tartalmakat láthat. A különböző tartalmak vagy objektumok ContentKeyPolicyRestriction esetében a megfelelő RequiredClaims értékkel fog rendelkezni.

Használja az Azure Media Services API-kat a licencek/kulcsok kézbesítésének konfigurálásához és az objektumok titkosításához (az ebben a példában látható módon).

Úgy tűnik, hogy ez a viselkedés a mintaalkalmazás kialakítása alapján történik. Ha offline módban alternatív hangsáv van jelen (ami a HLS esetében is így van), akkor az iOS 10 és az iOS 11 is alapértelmezés szerint az alternatív hangsávot használja. Ha kompenzálni szeretné ezt a viselkedést FPS offline módban, távolítsa el a másik hangsávot a streamből. Ha ezt a Media Services szolgáltatásban szeretné elvégezni, adja hozzá a hang-only=false dinamikus jegyzékszűrőt. Más szóval a HLS URL-címe .ism/manifest(format=m3u8-aapl,audio-only=false) végződésű.

A tartalomkézbesítési hálózat gyorsítótárkulcsának kialakításától függően előfordulhat, hogy a tartalom gyorsítótárazva van. Ürítse ki a gyorsítótárat.

Az iOS-eszközön letöltött fájlstruktúra az alábbi képernyőképhez hasonlóan néz ki. A _keys mappa a letöltött FPS-licenceket tárolja, minden licencszolgáltatás-gazdagéphez egy tárolt fájllal. A .movpkg mappa tárolja a hang- és videotartalmakat.

Az első mappa egy kötőjellel végződő névvel, majd egy számmal, amely videotartalmat tartalmaz. A numerikus érték a videómegjelenítések maximális sávszélessége. A második mappa, amelynek neve kötőjellel végződik, majd 0, hangtartalmat tartalmaz. A harmadik Data nevű mappa tartalmazza az FPS-tartalom fő lejátszási listáját. Végül boot.xml a .movpkg mappa tartalmának teljes leírását tartalmazza.

Íme egy minta boot.xml fájl:

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

Mivel a Media Services v3 lehetővé teszi, hogy egy objektum több StreamingLocator példánnyal rendelkezzen, a következőket teheti:

• Egy ContentKeyPolicy példány a -vel license_type = "persistent", ContentKeyPolicyRestriction a jogcímével "persistent"és annak példányával StreamingLocator .
• Egy másik ContentKeyPolicy példány a következővel license_type="nonpersistent": , ContentKeyPolicyRestriction jogcímmel a következőre "nonpersistent: ", és annak példánya StreamingLocator .
• Két StreamingLocator különböző értékkel rendelkező ContentKey példány.

Az egyéni STS üzleti logikájától függően a JWT-jogkivonat különböző jogcímeket ad ki. A jogkivonattal csak a megfelelő licenc szerezhető be, és csak a megfelelő URL-cím játszható le.

A Google Widevine DRM Architecture Overview három biztonsági szintet határoz meg. A Widevine-licencsablon Azure Media Services-dokumentációja azonban öt biztonsági szintet ismertet (a lejátszáshoz szükséges ügyfél-robusztussági követelményeket).

A Google Widevine mindkét biztonsági szintet meghatározza. A különbség a használati szint: architektúra vagy API. Az öt biztonsági szintet a Widevine API használja. Az Azure Media Services Widevine licencszolgáltatás deszerializálja az objektumot, amely tartalmazza security_levela content_key_specs objektumot, és továbbítja azt a Widevine globális kézbesítési szolgáltatásnak. Az alábbi táblázat a két biztonsági szintcsoport közötti leképezést mutatja be.

Az Azure Monitorral nyomon követheti, hogy mi történik a Media Services-erőforrásokkal. További információ: Media Services monitorozása. Az útmutatók az oldal végén jelennek meg.

A Azure Event Grid használatával monitorozza az élő eseményt lekérdezési szolgáltatás nélkül. Lásd: Media Services-események létrehozása és monitorozása az Event Griddel az Azure Portal használatával.

A Media Services számos játékossal működik együtt. Tekintse meg a kompatibilis médialejátszók listáját , vagy próbálja ki a külső lejátszómintákat.

További információ a Media Servicesről és a magas rendelkezésre állásról: Magas rendelkezésre állás a Media Services és az igény szerinti videó (VOD) használatával.

Létrehoztunk egy átfogó útmutatót a v2-ről a v3-ra való migráláshoz. Kíváncsiak vagyunk a migrálási élményre és az igényekre, ezért nyugodtan küldjön visszajelzést a GitHub-problémán vagy támogatási jegyen keresztül.

A hibakódokat a következő hivatkozásokban dokumentáltuk: Streamvégpont hibakódjai, Élő esemény hibakódjai és Feladat hibakódok. Ha ott nem talál választ, hozzon létre egy támogatási jegyet.

A fiók hitelesítő adatait az Azure CLI használatával állíthatja alaphelyzetbe.

Tekintse meg a Media Services díjszabási útmutatóját.

Lásd: Media Services-kvóták és -korlátok.

Az ügyfelek saját tárfiókokat csatolnak az Azure Media Services-fiókjukhoz. A rendszer minden eszközadatot ezekben a társított tárfiókokban tárol, és az ügyfél szabályozza a tároló helyét és replikációs típusát.

A Media Services-fiókhoz társított további adatok (beleértve a tartalomtitkosítási kulcsokat, a jogkivonat-ellenőrző kulcsokat, a JobInputHttp URL-címeket és az entitás egyéb metaadatait) a Media Services-fiókhoz kiválasztott régióban, a Microsoft tulajdonában lévő tárolóban vannak tárolva.

A dél-brazíliai és délkelet-ázsiai adattárolási követelmények miatt a további fiókadatok zónaredundáns módon vannak tárolva, és egyetlen régióban vannak tárolva. Délkelet-Ázsia esetében az összes további fiókadat Szingapúrban van tárolva. Dél-Brazília esetében az adatok Tárolása Brazíliában történik. A Dél-Brazília és Délkelet-Ázsia kivételével más régiókban további fiókadatok is tárolhatók a Microsoft által birtokolt tárolóban a párosított régióban.

Az Azure Media Services egy regionális szolgáltatás, amely nem biztosít magas rendelkezésre állást vagy adatreplikálást. Arra biztatjuk azokat az ügyfeleket, akiknek szükségük van ezekre a funkciókra, hogy több régióban használva hozzanak létre megoldást a Media Services-fiókok használatával. Útmutatóként elérhető egy minta, amely bemutatja, hogyan hozhat létre magas rendelkezésre állású megoldást a Media Services igény szerinti videójával .