Megosztás a következőn keresztül:


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

Ez a cikk az Azure Media Services szolgáltatással kapcsolatos gyakori kérdésekre ad választ.

Az Azure Media Services kivezetése

Hol találhatok további információt az Azure Media Services kivonásáról?

Fejlesztés SDK-kkal

Hol találom a Media Services API-t és az SDK-t?

Használjam az ügyféloldali SDK-kat, vagy írjak közvetlenül a REST API-ba?

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.

Hol találhatók a Media Services-minták?

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.

Hogyan működik a nagy eredményhalmazok (például az eszközök listája) lapozása az API-ban?

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.

Fiókok

Hogyan felügyelt identitással titkosítja az adatokat a Media Servicesbe?

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.

Hogyan felügyelt identitással hozzáférést ad a Media Servicesnek egy korlátozott tárfiókhoz?

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.

Mi a Media Services-fiók előfizetések közötti áthelyezésének folyamata?

Biztonság

Milyen Azure-szerepkörök hajthatnak végre műveleteket a Media Services-erőforrásokon?

Támogatja a Media Services a részletes szerepköralapú hozzáférés-vezérlést (RBAC)?

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

Eszközök, feltöltés és tárolás

Mi az a Media Services-eszköz?

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.

Hogyan létrehozni egy Media Services-objektumot?

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.

Encoding

Milyen kódolási formátumok érhetők el a Media Servicesben?

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.

Hogyan létrehozni egy Media Services-feladatot?

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 .

Létrehozhatok automatikusan létrehozott bitrátalétrát a Media Services használatával?

Támogatja a Media Services a tartalomérzékeny kódolást?

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.

Használhatok külső kódolású vagy meglévő MP4-fájlt a Media Servicesben?

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.

Használható a Media Services nagyon rövid formátumú fájltartalom kódolásához?

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.

Videó elforgatása, videó allipje, videók összefűzése, miniatűrök és spritesek létrehozása stb.

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.

Live streaming (Élő adatfolyam)

Mi az a Media Services élő eseménye?

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.

Hogyan hozzon létre egy Media Services élő eseményt?

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.

Hogyan élő átírást végez egy Media Services élő eseményével?

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.

Hogyan monitorozni az élő esemény állapotát?

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.

Újra felhasználhatom ugyanazt a streamelési URL-címet egy élő esemény újraindításakor?

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.

Csomagolás és kézbesítés

Feltöltöttem, kódoltam és közzétettem egy videót. Miért nem játszható le a videó, amikor megpróbálom streamelni?

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

Mi az a Media Services streamvégpontja?

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.

Mi az a Media Services streamelési lokátora?

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.

Hogyan létrehozni egy Media Services streamelési lokátort?

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.

Mi az a streamelési szabályzat?

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.

Hogyan media services streamelési szabályzatot létrehozni?

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.

Hogyan HLS-formátumú tartalmat streamel az Apple-eszközökre?

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.

Továbbíthatok egy másik megoldásban előre kódolt vagy kódolt meglévő MP4-fájlokat?

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.

2024 februárja után is működni fognak a v2-alapú streamelési lokátorok?

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.

Tartalomvédelem

Hogyan a médiatartalmat dinamikus titkosítással kézbesíteni?

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.

Használnom kell az AES-128 clear key encryptiont vagy egy DRM-rendszert?

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.

Hogyan csak azoknak a felhasználóknak jelenítsen meg videót, akik adott engedéllyel rendelkeznek, Azure AD használata nélkül?

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.

Hogyan és hol szerezhetek be JWT-jogkivonatot, mielőtt licencet vagy kulcsot kérnék?

É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.)

Hogyan engedélyezi a videók AES-titkosítással történő streamelésére irányuló kéréseket?

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).

Miért csak a hang játssza le a hangot, és nem a videót, ha FairPlay offline módot használok?

Ú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ű.

Miért játszik le a FairPlay offline hangot videó mód nélkül, miután hozzáadtam a csak audio-only=false értéket?

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.

Mi a letöltött/offline fájlstruktúra iOS-eszközökön?

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.

Képernyőkép a FairPlay iOS-mintaalkalmazás offline fájlszerkezetéről.

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

Hogyan biztosíthatok állandó licenceket (offline engedélyezve) egyes ügyfelek/felhasználók számára, illetve nem állandó licenceket (offline letiltva) másoknak? Duplikálnom kell a tartalmat, és külön tartalomkulcsokat kell használnom?

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.

Mi a Widevine és a Media Services DRM biztonsági szintjei közötti leképezés?

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.

A Widevine architektúrában meghatározott biztonsági szintek A Widevine API-ban használt biztonsági szintek
1. biztonsági szint: Minden tartalomfeldolgozás, titkosítás és vezérlés a megbízható végrehajtási környezetben (TEE) történik. Egyes implementációs modellekben a biztonsági feldolgozás különböző chipekben végezhető el. security_level=5: A (tömörített és tömörítetlen) adathordozó titkosítását, dekódolását és minden kezelését hardveres TEE-n belül kell kezelni.

security_level=4: A tartalom titkosítását és dekódolását hardveres tee-n belül kell elvégezni.
2. biztonsági szint: A titkosítás (de a videófeldolgozás nem) a TEE-ben történik. A visszafejtett pufferek visszakerülnek az alkalmazástartományba, és külön videohardveren vagy szoftveren keresztül lesznek feldolgozva. A 2. szinten azonban a titkosítási információk feldolgozása továbbra is csak a TEE-n belül történik. security_level=3: A fő anyag- és titkosítási műveleteket hardveres tee-ben kell végrehajtani.
3. biztonsági szint: Nincs TEE az eszközön. Megfelelő intézkedéseket lehet tenni a gazda operációs rendszer titkosítási információinak és visszafejtett tartalmának védelme érdekében. A 3. szintű implementációk hardveres titkosítási motort is tartalmazhatnak, de ez csak a teljesítményt javítja, nem a biztonságot. security_level=2: Szoftveres titkosításra és rejtjelezett dekóderre van szükség.

security_level=1: Szoftveralapú, dobozos titkosítás szükséges.

Figyelés

Hogyan monitorozni a Media Services-erőforrásokat?

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.

Hogyan monitorozni a Media Services élő eseményét?

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.

Játékosok

Mely video lejátszók használhatók a Media Services szolgáltatással?

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.

Magas rendelkezésre állás

Támogatja a Media Services a magas rendelkezésre állást?

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.

Migrálás a v2-ről

Hogyan migrálni a Media Services v2-ről a Media Services v3-ra?

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.

Hibaelhárítás

Hogyan megtudja, mit jelent ez a hibakód?

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.

Hogyan a fiók hitelesítő adatainak alaphelyzetbe állítását?

Számlázás és költségbecslések

Mennyibe kerül a Media Services?

Kvóták és korlátok

Milyen kvóták és korlátok vonatkoznak a Media Servicesre?

Megfelelőségi és ügyféladatok

A Media Services tárol ügyféladatokat a szolgáltatási régión kívül?

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.

A Media Services magas rendelkezésre állást vagy adatreplikálást biztosít?

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 .