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

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

Az Azure Media Services kivonása

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

Tekintse meg Azure Media Services-nyugdíjazási útmutatót

Fejlesztés SDK-kkal

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

Íme egy lista:

• Azure CLI-
• .NET
• Java-
• Python-
• Node.js
• Go

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 tördelni a Media Services REST API-ját. Ha így tesz éles célokra, akkor a teljes Azure Resource Manager újrapróbálkozási logikát kell implementálnia, és meg kell értenie, hogyan kezelheti a hosszan futó műveleteket a Resource Manager API-kban. Az ügyféloldali SDK-k különböző nyelvekhez – például .NET, Java, TypeScript, Python és Ruby – automatikusan kezelik ezt, így csökkenthetik az újrapróbálkozással vagy sikertelen API-hívásokkal kapcsolatos problémák esélyét.

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

Tekintse meg a mintaoldalakat. A -fiókok, eszközök, élő streamelési, VOD-streamelési, Content Protection, Kódolási, Elemzésiés Lejátszó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 függhet egy adott oldalmérettől. További részletekért és példákért lásd szűrési, rendezési és lapozási entitásokat.

Számlák

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

További információ arról, hogy az Azure CLI-vel párosíthatja a Media Servicest az Azure Key Vaulttal az adatok titkosításához, olvassa el a Az adatok Media Services-fiókba való titkosításához használt Key Vault-kulcs használata oktatóanyagban.

Hogyan adhatok hozzáférést a Media Services számára egy korlátozott tárfiókhoz felügyelt identitással?

Ha azt szeretné, hogy a Media Services hozzáférhessen egy tárfiókhoz, amikor 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.

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

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

Biztonság

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

Lásd Media Services-fiókokhoz készült Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC).

Támogatja a Media Services a 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 Médiaszolgáltató
• Media Services-házirend rendszergazdája
• Media Services streamvégpontok rendszergazdája
• Media Services élő események rendszergazdája

Ezeket a szerepköröket Media Services-fiókokhoz készült Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC).

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. Azoknak az ügyfeleknek, 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 régi API-t támogató fiókok létrehozásának letiltására a következő beépített Azure Policy használható: az örökölt v2 API-hoz hozzáférést engedélyező Azure Media Services-fiókokat le kell tiltani – 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. Az átalakításokhoz és más műveletekhez használt egyedi azonosítóval rendelkezik. Lásd: Assets in Azure Media Services v3.

Hogyan hozhatok létre 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 kapcsolódó fájlok tárolásához. Az Azure Portal használata esetén 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.

Kódolás

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

A Media Services Standard Encoderrel közös kódolási formátumok érhetők el. Az összes formátum listáját Standard Kódoló formátumok és kodekekcímű témakörben találja.

Hogyan hozhatok létre Media Services-feladatot?

Az Azure Portalon az Azure CLI, a REST vagy bármely SDK használatával hozhat létre feladatot. Tekintse meg a Media Services-mintákat, a kívánt nyelvet.

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

Igen. Lásd: Kódolás automatikusan létrehozott bitráta létrá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 a legjobb adaptív bitrátakészletet, felbontást és kódolási beállításokat javasolhatja.

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

Igen. Az előre kódolt és a kiszolgálójegyzék (.ism) és az ügyféljegyzék (.ismc) létrehozására szolgáló egybites mp4-fájl feltöltését és a kiszolgálójegyzék (.ism) és az ügyféljegyzék (.ismc) létrehozására szolgáló mintaalkalmazásra mutató hivatkozásokat a csomagolásról és a kézbesítésről szóló szakaszban találja a "Továbbíthatom a meglévő MP4-fájlokat, amelyek előre kódolt vagy más megoldásban vannak kódolva?" kérdésre. Ez a válasz azt is leírja, 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. Az egy percnél vagy két percnél rövidebb, nagyon rövid 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 bitráta használatával.

Mivel a legtöbb adaptív bitráta 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 bitráta 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 játékos zárolja a heurisztikus algoritmust a megfelelő bitrátán, hogy a hálózati feltételek alapján játsszon, a fájl streamelésre kerül.

Emellett néhány játékos alapértelmezés szerint legfeljebb három videószegmenst pufferel. 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 megkezdi az adaptív bitrátakészlet első kiválasztott bitráta lejátszását. Ezért 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 megvalósításáról a csomagolásról és a kézbesítésről szóló szakaszban talál választ a "Továbbíthatom a meglévő MP4-fájlokat, amelyek előre kódoltak vagy más 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 sokat nyújthatnak – például gyorsabb keresés, digitális tartalomvédelmi (DRM) támogatás, valamint az URL-címen keresztüli letöltés nehézsége (de még mindig lehetséges!), 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 nyelvek szinkronizálásának késői kötése értékes választássá teszi ezt bizonyos helyzetekben.

Hogyan forgassa el a videót, alklip egy videót, varrja a videókat, hozzon létre miniatűröket és sprites, stb?

Ha olyan módszereket keres, amelyekkel a Media Services kódolója olyan műveleteket hajthat végre, mint a videó elforgatása, a videók alcsúcsolása, a videók összefűzése, miniatűrök és spritesek létrehozása, akkor a Kódminták lapon számos kódminta található. Az elérhető mintanyelvek közé tartozik a Node.JS, a Python, a .NET és a Java.

Élő streamelés

Mi az az élő Media Services-esemény?

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ó: Media Services-élő események és élő kimenetek.

Hogyan hozhatok létre élő Media Services-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 Wirecast és OBS. Ha inkább a Media Services élő eseményeinek áttekintésével szeretne kezdeni, tekintse meg Élő eseménytípusokcímű témakört.

Hogyan lehet élő átírást végezni a Media Services élő eseményeivel?

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

Hogyan monitorozhatom az élő eseményem állapotát?

Az élő eseményeket az Azure Event Grid-eseményekre való feliratkozással figyelheti. További információ: Event Grid eseményséma. A következőkre van lehetőség:

• Előfizetés a Microsoft.Media.LiveEventEncoderDisconnected streamszintű eseményekre, és figyelje meg, hogy egy darabig nem jönnek létre újrakapcsolódások az élő esemény leállításához és törléséhez.
• Feliratkozás a nyomon követés szintű szívverésre 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, nyugodtan leálltathatja az élő eseményt. A szívverési események minden számhoz 20 másodpercenként érkeznek, ezért lehet, hogy kissé 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 biztos lehet abban, hogy nem lesz gyorsítótár-ütközés a streamvégpontban é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ítheti egy adott GUID-t a streamelési lokátorhoz, majd eldöntheti, hogy melyik jegyzéknevet használja 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 jegyzékhez a "conference1" kifejezést használja, és kényszeríti a guid azonosítót a lokátorhoz.

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

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

Csomagolás és szállítás

Feltöltöttem, kódoltam és közzétettem egy videót. Miért nem játssza 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 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 az élő és igény szerinti tartalmakat közvetlenül egy ügyféllejátszó alkalmazásnak kézbesítheti 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 Services.

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

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

Hogyan hozhatok létre Media Services-stream 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űzi 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átorok számára. A Media Services v3 előre definiált streamelési szabályzatokat biztosít. További információ: Streamelési szabályzatok.

Hogyan hozhatok létre Media Services-streamelési szabályzatot?

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

Hogyan streamelhetem a HLS formátumú tartalmakat az Apple-eszközökre?

Győződjön meg arról, hogy (format=m3u8-cmaf) az elérési út végén (az URL-cím /jegyzék része után), hogy a streamelési forráskiszolgálótól a HLS-tartalmat az Apple iOS-natív eszközökön való felhasználás céljából adja vissza. További információ: 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 két másodperces távolság, állandó bitráta kódolás (CBR mód). A H.264 vagy HEVC videokodek által kódolt legtöbb ilyen formátumú tartalom, valamint az AAC hangformátuma támogatott. További előre kódolt hangformátumok is támogatottak lehetnek, például a Dolby DD+.

A munka kulcsa egy objektum létrehozása, az előre kódolt objektumok feltöltése az objektum tárolójába az Azure Blob Storage ügyféloldali SDK-k használatával, majd a szükséges kiszolgálói jegyzékfájl (.ism) és ügyféljegyzékfájlok létrehozása. További részletekért tekintse meg a .NET-mintaprojektet Meglévő MP4-fájlok streamelése.

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ájlokhoz való hozzáférési idő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 mp4-fájl streamelése HLS vagy Dashhasználatával.

Ha ezzel a módszerrel skáláz fel, figyelnie kell a streamvégpont cpu-terhelé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 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 a v2 API kikapcsolása után is működni fognak. Miután létrehozta a Stream Locator-adatokat a Media Services háttéradatbázisában, nincs függőség a v2 REST API-tól a streameléshez. 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 vagy frissíthető az új v3 API használatával. A v2 például olyan Eszközfájlok API-t tesz elérhetővé, amely nem rendelkezik a v3 API-val egyenértékű funkcióval. Ez gyakran nem jelent problémát a legtöbb ügyfelünk számára, mivel nem 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 streamelt lokátorok vagy objektumok módosításához.

Tartalomvédelem

Hogyan kézbesíthetem a médiatartalmamat dinamikus titkosítással?

A dinamikus titkosítás biztosítja az adathordozót attól az időponttól kezdve, amikor a számítógépről a tárolás, a feldolgozás és a kézbesítés során elhagyja az adathordozót. 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ási.

Használnom kell az AES-128 tiszta kulcstitkosítást 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 továbbítja az ügyfélnek. A kulcs átvitel közben titkosítva van további titkosítás nélkül ("a tiszta"). Ennek eredményeképpen a tartalom visszafejtéséhez használt kulcs elérhető az ügyféllejátszó számára, és az ügyfél hálózati nyomkövetésében, egyszerű szövegben tekinthető meg. Az AES-128 egyértelmű kulcstitkosítás olyan esetekben használható, 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 tartalomkulcsot a TLS által biztosított átviteli szintű titkosítás mellett a DRM-futtatókörnyezet által védett kulcsra titkosítja. A visszafejtést biztonságos környezetben kezelik az operációs rendszer szintjén, ahol a rosszindulatú felhasználók nehezebben támadnak. Javasoljuk a DRM használatát olyan esetekben, amikor a megtekintő nem megbízható fél, és a legmagasabb szintű biztonságra van szüksége.

Hogyan jeleníthetek meg videót csak olyan felhasználóknak, akik adott engedéllyel rendelkeznek az 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étrehozhat saját JWT- szolgáltatót (úgynevezett Secure Token Service-t vagy STS-t). Az egyéni STS-ben az üzleti logika 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 egyezik a JWT-ben szereplő adatok és a ContentKeyPolicyhasznált ContentKeyPolicyRestriction érték között.

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

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

Éles környezetben biztonságos jogkivonat-szolgáltatással (vagyis webszolgáltatással) kell rendelkeznie, amely JWT-jogkivonatot ad ki EGY HTTPS-kérés esetén. A teszteléshez használhatja a GetTokenAsyncProgram.cs.

A felhasználó hitelesítése után a játékos kérést intéz az STS-hez egy ilyen jogkivonathoz, és hozzárendeli azt a jogkivonat értékeként. Az Azure Media Player APIhasználható.

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

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

A helyes módszer a Secure Token Service 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 esetében ContentKeyPolicyRestriction a megfelelő RequiredClaims értékkel fog rendelkezni.

Az Azure Media Services API-kkal konfigurálhatja a licenc-/kulcskézbesítést és titkosíthatja az objektumokat (a minta ).

Miért csak a hang lejátszása és nem a videó lejátszása, ha FairPlay offline módot használok?

Úgy tűnik, hogy ez a viselkedés a mintaalkalmazás tervezésekor jelenik meg. Ha offline módban alternatív hangsáv van jelen (ez a HLS esetében), akkor az iOS 10 és az iOS 11 is alapértelmezés szerint az alternatív hangsávra kerül. Ha ezt a viselkedést az FPS offline módban szeretné kompenzálni, távolítsa el a másik hangsávot a streamből. Ehhez a Media Servicesben adja hozzá a dinamikus jegyzékszűrőt audio-only=false. Más szóval a HLS URL-cím .ism/manifest(format=m3u8-aapl,audio-only=false)végződik.

Miért csak videó mód nélkül játssza le a FairPlay az offline lejátszást a csak audio-only=false hozzáadása után?

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 egy kötőjellel végződő névvel, majd 0-val végződik, amely hangtartalmat tartalmaz. A harmadik Data nevű mappa tartalmazza az FPS-tartalom fő lejátszási listáját. Végül boot.xml teljes leírást nyújt a .movpkg mappa tartalmáról.

Íme egy példa boot.xml fájlra:

<?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ások számára? Meg kell duplikálnom 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ányt használjon, a következőkkel rendelkezhet:

• Egy ContentKeyPolicy példány license_type = "persistent", ContentKeyPolicyRestriction"persistent"jogcímmel és annak StreamingLocator példányával.
• Egy másik ContentKeyPolicy példány license_type="nonpersistent", ContentKeyPolicyRestriction"nonpersistent", és annak StreamingLocator példánya.
• Két StreamingLocator különböző ContentKey értékkel rendelkező 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 leképezés a Widevine és a Media Services DRM biztonsági szintjei között?

A Google Widevine DRM architektúrájának áttekintése három biztonsági szintet határoz meg. A Widevine-licencsablon Azure Media Services-dokumentációja azonban öt biztonsági szintet (a lejátszáshoz szükséges ügyfél-robusztussági követelményeket) vázol fel.

A Google Widevine mindkét biztonsági szintet meghatározza. A különbség a használati szintben van: architektúra vagy API. Az öt biztonsági szintet a Widevine API használja. Az Azure Media Services Widevine licencszolgáltatás deszerializálja a content_key_specs objektumot, amely security_leveltartalmaz, és átadja a Widevine globális kézbesítési szolgáltatásnak. Az alábbi táblázat a két biztonsági szint közötti megfeleltetést mutatja be.

Widevine architektúrában meghatározott biztonsági szintek	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 kezelését hardveralapú TEE-n belül kell kezelni. security_level=4: A tartalom titkosítását és dekódolását hardveralapú TEE-n belül kell elvégezni.
2. biztonsági szint: A titkosítás (de nem videofeldolgozás) a TEE-n belül történik. A visszafejtött pufferek visszakerülnek az alkalmazás tartományába, és külön videohardveren vagy szoftveren keresztül dolgozzák fel. A 2. szinten azonban a titkosítási információk feldolgozása továbbra is csak a TEE-ben történik.	security_level=3: A fő anyag- és titkosítási műveleteket hardveralapú TEE-n belül kell végrehajtani.
3. biztonsági szint: Nincs TEE az eszközön. A gazda operációs rendszer titkosítási információinak és visszafejtett tartalmának védelme érdekében megfelelő intézkedéseket lehet hozni. 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 obfuscated dekóderre van szükség. security_level=1: Szoftveralapú, fehér dobozos titkosítás szükséges.

Ellenőrző

Hogyan monitorozhatom a Media Services-erőforrásaimat?

Az Azure Monitor használatával 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 monitorozhatom a Media Services élő eseményét?

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

Játékosok

Mely videobejá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 harmadik féltől származó 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 a Video on Demand (VOD).

Migrálás v2-ről

Hogyan migrálhatok a Media Services v2-ről a Media Services 3-ra?

Létrehoztunk egy átfogó útmutatót a v2-ről a v3-való migráláshoz. Szeretnénk megismerni a migrálási élményt és az igényeket, ezért nyugodtan küldjön visszajelzést a GitHub-problémáról vagy támogatási jegyről.

Hibaelhárítás

Hogyan deríthetem ki, 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ódjai. Ha nem találja a válaszokat, hozzon létre egy támogatási jegyet.

Hogyan állíthatom alaphelyzetbe a fiók hitelesítő adatait?

Az Azure CLI használatávalalaphelyzetbe állíthatja a fiók hitelesítő adatait.

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

Mennyibe kerül a Media Services?

Lásd a Media Services díjszabási útmutatójának.

Kvóták és korlátok

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

Lásd Media Services-kvótákat és korlátokat.

Megfelelőségi és ügyféladatok

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

Az ügyfelek saját tárfiókokat csatolnak az Azure Media Services-fiókjukhoz. Minden eszközadat ezekben a társított tárfiókokban van tárolva, és az ügyfél szabályozza a tár 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ési kulcsokat, a JobInputHttp URL-címeket és az entitás egyéb metaadatait) a Media Services-fiókhoz kiválasztott régión belül, a Microsoft tulajdonában lévő tárolóban vannak tárolva.

A dél- és délkelet-ázsiai Brazíliában 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 adatokat Brazíliában tárolják. A dél-brazíliai és délkelet-ázsiai régiókon kívül 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 ösztönözzük azokat az ügyfeleket, akiknek szükségük van ezekre a funkciókra, hogy több régióban lévő Media Services-fiókok használatával hozzanak létre megoldást. Útmutatóként elérhető egy minta, amely bemutatja, hogyan hozhat létre megoldást magas rendelkezésre állású Media Services-videóval.

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

Tekintse meg Azure Media Services-nyugdíjazási útmutatót

Íme egy lista:

• Azure CLI-
• .NET
• Java-
• Python-
• Node.js
• Go

Nem javasoljuk, hogy próbálja meg közvetlenül a saját kódtárkódjába tördelni a Media Services REST API-ját. Ha így tesz éles célokra, akkor a teljes Azure Resource Manager újrapróbálkozási logikát kell implementálnia, és meg kell értenie, hogyan kezelheti a hosszan futó műveleteket a Resource Manager API-kban. Az ügyféloldali SDK-k különböző nyelvekhez – például .NET, Java, TypeScript, Python és Ruby – automatikusan kezelik ezt, így csökkenthetik az újrapróbálkozással vagy sikertelen API-hívásokkal kapcsolatos problémák esélyét.

Tekintse meg a mintaoldalakat. A -fiókok, eszközök, élő streamelési, VOD-streamelési, Content Protection, Kódolási, Elemzésiés Lejátszók.

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

További információ arról, hogy az Azure CLI-vel párosíthatja a Media Servicest az Azure Key Vaulttal az adatok titkosításához, olvassa el a Az adatok Media Services-fiókba való titkosításához használt Key Vault-kulcs használata oktatóanyagban.

Ha azt szeretné, hogy a Media Services hozzáférhessen egy tárfiókhoz, amikor 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.

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

Lásd Media Services-fiókokhoz készült Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC).

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

• Media Services-fiókadminisztrátor
• Media Services Médiaszolgáltató
• Media Services-házirend rendszergazdája
• Media Services streamvégpontok rendszergazdája
• Media Services élő események rendszergazdája

Ezeket a szerepköröket Media Services-fiókokhoz készült Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC).

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. Azoknak az ügyfeleknek, 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 régi API-t támogató fiókok létrehozásának letiltására a következő beépített Azure Policy használható: az örökölt v2 API-hoz hozzáférést engedélyező Azure Media Services-fiókokat le kell tiltani – Microsoft Azure

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

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 kapcsolódó fájlok tárolásához. Az Azure Portal használata esetén 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 Encoderrel közös kódolási formátumok érhetők el. Az összes formátum listáját Standard Kódoló formátumok és kodekekcímű témakörben találja.

Az Azure Portalon az Azure CLI, a REST vagy bármely SDK használatával hozhat létre feladatot. Tekintse meg a Media Services-mintákat, a kívánt nyelvet.

Igen. Lásd: Kódolás automatikusan létrehozott bitráta 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 a legjobb adaptív bitrátakészletet, felbontást és kódolási beállításokat javasolhatja.

Igen. Az előre kódolt és a kiszolgálójegyzék (.ism) és az ügyféljegyzék (.ismc) létrehozására szolgáló egybites mp4-fájl feltöltését és a kiszolgálójegyzék (.ism) és az ügyféljegyzék (.ismc) létrehozására szolgáló mintaalkalmazásra mutató hivatkozásokat a csomagolásról és a kézbesítésről szóló szakaszban találja a "Továbbíthatom a meglévő MP4-fájlokat, amelyek előre kódolt vagy más megoldásban vannak kódolva?" kérdésre. Ez a válasz azt is leírja, hogy milyen hatással van a teljesítmény a forrásra.

Nem javasoljuk. Az egy percnél vagy két percnél rövidebb, nagyon rövid 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 bitráta használatával.

Mivel a legtöbb adaptív bitráta 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 bitráta 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 játékos zárolja a heurisztikus algoritmust a megfelelő bitrátán, hogy a hálózati feltételek alapján játsszon, a fájl streamelésre kerül.

Emellett néhány játékos alapértelmezés szerint legfeljebb három videószegmenst pufferel. 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 megkezdi az adaptív bitrátakészlet első kiválasztott bitráta lejátszását. Ezért 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 megvalósításáról a csomagolásról és a kézbesítésről szóló szakaszban talál választ a "Továbbíthatom a meglévő MP4-fájlokat, amelyek előre kódoltak vagy más 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 sokat nyújthatnak – például gyorsabb keresés, digitális tartalomvédelmi (DRM) támogatás, valamint az URL-címen keresztüli letöltés nehézsége (de még mindig lehetséges!), 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 nyelvek szinkronizálásának késői kötése értékes választássá teszi ezt bizonyos helyzetekben.

Ha olyan módszereket keres, amelyekkel a Media Services kódolója olyan műveleteket hajthat végre, mint a videó elforgatása, a videók alcsúcsolása, a videók összefűzése, miniatűrök és spritesek létrehozása, akkor a Kódminták lapon számos kódminta található. 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ó: Media Services-élő események és élő kimenetek.

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 Wirecast és OBS. Ha inkább a Media Services élő eseményeinek áttekintésével szeretne kezdeni, tekintse meg Élő eseménytípusokcímű témakört.

Az Azure Media Service különböző protokollokban biztosít video-, hang- és szövegtartalmakat. Amikor az élő streamet MPEG-DASH vagy HLS/CMAF használatával teszi közzé, akkor a szolgáltatás a videó és a hang mellett 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 az Azure Event Grid-eseményekre való feliratkozással figyelheti. További információ: Event Grid eseményséma. A következőkre van lehetőség:

• Előfizetés a Microsoft.Media.LiveEventEncoderDisconnected streamszintű eseményekre, és figyelje meg, hogy egy darabig nem jönnek létre újrakapcsolódások az élő esemény leállításához és törléséhez.
• Feliratkozás a nyomon követés szintű szívverésre 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, nyugodtan leálltathatja az élő eseményt. A szívverési események minden számhoz 20 másodpercenként érkeznek, ezért lehet, hogy kissé 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 biztos lehet abban, hogy nem lesz gyorsítótár-ütközés a streamvégpontban é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ítheti egy adott GUID-t a streamelési lokátorhoz, majd eldöntheti, hogy melyik jegyzéknevet használja 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 jegyzékhez a "conference1" kifejezést használja, és kényszeríti a guid azonosítót a lokátorhoz.

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

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

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 az élő és igény szerinti tartalmakat közvetlenül egy ügyféllejátszó alkalmazásnak kézbesítheti 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 Services.

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

Streamelési URL-cím létrehozásához először létre kell hoznia egy streamelési lokátort. Ezután összefűzi 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átorok számára. 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ályzatokcímű témakörben találja.

Győződjön meg arról, hogy (format=m3u8-cmaf) az elérési út végén (az URL-cím /jegyzék része után), hogy a streamelési forráskiszolgálótól a HLS-tartalmat az Apple iOS-natív eszközökön való felhasználás céljából adja vissza. További információ: 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 két másodperces távolság, állandó bitráta kódolás (CBR mód). A H.264 vagy HEVC videokodek által kódolt legtöbb ilyen formátumú tartalom, valamint az AAC hangformátuma támogatott. További előre kódolt hangformátumok is támogatottak lehetnek, például a Dolby DD+.

A munka kulcsa egy objektum létrehozása, az előre kódolt objektumok feltöltése az objektum tárolójába az Azure Blob Storage ügyféloldali SDK-k használatával, majd a szükséges kiszolgálói jegyzékfájl (.ism) és ügyféljegyzékfájlok létrehozása. További részletekért tekintse meg a .NET-mintaprojektet Meglévő MP4-fájlok streamelése.

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ájlokhoz való hozzáférési idő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 mp4-fájl streamelése HLS vagy Dashhasználatával.

Ha ezzel a módszerrel skáláz fel, figyelnie kell a streamvégpont cpu-terhelé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 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 a v2 API kikapcsolása után is működni fognak. Miután létrehozta a Stream Locator-adatokat a Media Services háttéradatbázisában, nincs függőség a v2 REST API-tól a streameléshez. 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 vagy frissíthető az új v3 API használatával. A v2 például olyan Eszközfájlok API-t tesz elérhetővé, amely nem rendelkezik a v3 API-val egyenértékű funkcióval. Ez gyakran nem jelent problémát a legtöbb ügyfelünk számára, mivel nem 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 streamelt lokátorok vagy objektumok módosításához.

A dinamikus titkosítás biztosítja az adathordozót attól az időponttól kezdve, amikor a számítógépről a tárolás, a feldolgozás és a kézbesítés során elhagyja az adathordozót. 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ási.

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 továbbítja az ügyfélnek. A kulcs átvitel közben titkosítva van további titkosítás nélkül ("a tiszta"). Ennek eredményeképpen a tartalom visszafejtéséhez használt kulcs elérhető az ügyféllejátszó számára, és az ügyfél hálózati nyomkövetésében, egyszerű szövegben tekinthető meg. Az AES-128 egyértelmű kulcstitkosítás olyan esetekben használható, 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 tartalomkulcsot a TLS által biztosított átviteli szintű titkosítás mellett a DRM-futtatókörnyezet által védett kulcsra titkosítja. A visszafejtést biztonságos környezetben kezelik az operációs rendszer szintjén, ahol a rosszindulatú felhasználók nehezebben támadnak. Javasoljuk a DRM használatát olyan esetekben, 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étrehozhat saját JWT- szolgáltatót (úgynevezett Secure Token Service-t vagy STS-t). Az egyéni STS-ben az üzleti logika 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 egyezik a JWT-ben szereplő adatok és a ContentKeyPolicyhasznált ContentKeyPolicyRestriction érték között.

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

Éles környezetben biztonságos jogkivonat-szolgáltatással (vagyis webszolgáltatással) kell rendelkeznie, amely JWT-jogkivonatot ad ki EGY HTTPS-kérés esetén. A teszteléshez használhatja a GetTokenAsyncProgram.cs.

A felhasználó hitelesítése után a játékos kérést intéz az STS-hez egy ilyen jogkivonathoz, és hozzárendeli azt a jogkivonat értékeként. Az Azure Media Player APIhasználható.

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

A helyes módszer a Secure Token Service 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 esetében ContentKeyPolicyRestriction a megfelelő RequiredClaims értékkel fog rendelkezni.

Az Azure Media Services API-kkal konfigurálhatja a licenc-/kulcskézbesítést és titkosíthatja az objektumokat (a minta ).

Úgy tűnik, hogy ez a viselkedés a mintaalkalmazás tervezésekor jelenik meg. Ha offline módban alternatív hangsáv van jelen (ez a HLS esetében), akkor az iOS 10 és az iOS 11 is alapértelmezés szerint az alternatív hangsávra kerül. Ha ezt a viselkedést az FPS offline módban szeretné kompenzálni, távolítsa el a másik hangsávot a streamből. Ehhez a Media Servicesben adja hozzá a dinamikus jegyzékszűrőt audio-only=false. Más szóval a HLS URL-cím .ism/manifest(format=m3u8-aapl,audio-only=false)végződik.

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 egy kötőjellel végződő névvel, majd 0-val végződik, amely hangtartalmat tartalmaz. A harmadik Data nevű mappa tartalmazza az FPS-tartalom fő lejátszási listáját. Végül boot.xml teljes leírást nyújt a .movpkg mappa tartalmáról.

Íme egy példa boot.xml fájlra:

<?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ányt használjon, a következőkkel rendelkezhet:

• Egy ContentKeyPolicy példány license_type = "persistent", ContentKeyPolicyRestriction"persistent"jogcímmel és annak StreamingLocator példányával.
• Egy másik ContentKeyPolicy példány license_type="nonpersistent", ContentKeyPolicyRestriction"nonpersistent", és annak StreamingLocator példánya.
• Két StreamingLocator különböző ContentKey értékkel rendelkező 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 architektúrájának áttekintése három biztonsági szintet határoz meg. A Widevine-licencsablon Azure Media Services-dokumentációja azonban öt biztonsági szintet (a lejátszáshoz szükséges ügyfél-robusztussági követelményeket) vázol fel.

A Google Widevine mindkét biztonsági szintet meghatározza. A különbség a használati szintben van: architektúra vagy API. Az öt biztonsági szintet a Widevine API használja. Az Azure Media Services Widevine licencszolgáltatás deszerializálja a content_key_specs objektumot, amely security_leveltartalmaz, és átadja a Widevine globális kézbesítési szolgáltatásnak. Az alábbi táblázat a két biztonsági szint közötti megfeleltetést mutatja be.

Widevine architektúrában meghatározott biztonsági szintek	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 kezelését hardveralapú TEE-n belül kell kezelni. security_level=4: A tartalom titkosítását és dekódolását hardveralapú TEE-n belül kell elvégezni.
2. biztonsági szint: A titkosítás (de nem videofeldolgozás) a TEE-n belül történik. A visszafejtött pufferek visszakerülnek az alkalmazás tartományába, és külön videohardveren vagy szoftveren keresztül dolgozzák fel. A 2. szinten azonban a titkosítási információk feldolgozása továbbra is csak a TEE-ben történik.	security_level=3: A fő anyag- és titkosítási műveleteket hardveralapú TEE-n belül kell végrehajtani.
3. biztonsági szint: Nincs TEE az eszközön. A gazda operációs rendszer titkosítási információinak és visszafejtett tartalmának védelme érdekében megfelelő intézkedéseket lehet hozni. 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 obfuscated dekóderre van szükség. security_level=1: Szoftveralapú, fehér dobozos titkosítás szükséges.

Az Azure Monitor használatával 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.

Az Azure Event Grid használatával lekérdezési szolgáltatás nélkül figyelheti az élő eseményt. Lásd: Media Services-események létrehozása és monitorozása az Event Grid használatával az Azure Portalhaszná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 harmadik féltől származó 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 a Video on Demand (VOD).

Létrehoztunk egy átfogó útmutatót a v2-ről a v3-való migráláshoz. Szeretnénk megismerni a migrálási élményt és az igényeket, ezért nyugodtan küldjön visszajelzést a GitHub-problémáról vagy támogatási jegyről.

A hibakódokat a következő hivatkozásokban dokumentáltuk: streamvégpont hibakódjai, élő esemény hibakódjai, és feladat hibakódjai. Ha nem találja a válaszokat, hozzon létre egy támogatási jegyet.

Az Azure CLI használatávalalaphelyzetbe állíthatja a fiók hitelesítő adatait.

Lásd a Media Services díjszabási útmutatójának.

Lásd Media Services-kvótákat és korlátokat.

Az ügyfelek saját tárfiókokat csatolnak az Azure Media Services-fiókjukhoz. Minden eszközadat ezekben a társított tárfiókokban van tárolva, és az ügyfél szabályozza a tár 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ési kulcsokat, a JobInputHttp URL-címeket és az entitás egyéb metaadatait) a Media Services-fiókhoz kiválasztott régión belül, a Microsoft tulajdonában lévő tárolóban vannak tárolva.

A dél- és délkelet-ázsiai Brazíliában 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 adatokat Brazíliában tárolják. A dél-brazíliai és délkelet-ázsiai régiókon kívül 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 ösztönözzük azokat az ügyfeleket, akiknek szükségük van ezekre a funkciókra, hogy több régióban lévő Media Services-fiókok használatával hozzanak létre megoldást. Útmutatóként elérhető egy minta, amely bemutatja, hogyan hozhat létre megoldást magas rendelkezésre állású Media Services-videóval.