Azure Media Services hakkında sık sorulan sorular

Bkz. Azure Media Services kullanımdan kaldırma kılavuzu

Bir liste aşağıdadır:

• OpenAPI Belirtimi (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• Git

Media Services için REST API'yi doğrudan kendi kitaplık kodunuz içine sarmaya çalışmanızı önermiyoruz. Üretim amaçları doğrultusunda bunu düzgün bir şekilde yapmak için tam Azure Resource Manager yeniden deneme mantığını uygulamanız ve Resource Manager API'lerde uzun süre çalışan işlemlerin nasıl yönetileceğini anlamanız gerekir. .NET, Java, TypeScript, Python ve Ruby gibi çeşitli diller için istemci SDK'ları, yeniden deneme mantığı veya başarısız API çağrılarıyla ilgili sorun olasılığını azaltmak için bunu sizin için otomatik olarak işler.

Örnek sayfalarına bakın. Hesaplar, Varlıklar, Canlı Akış, VOD Akışı, İçerik Koruması, Kodlama, Analiz ve Oynatıcıları kullanma örnekleri vardır.

Sayfalandırma kullanırken, belirli bir sayfa boyutuna bağlı değil, koleksiyonu numaralandırmak için her zaman bir sonraki bağlantıyı kullanmanız gerekir. Ayrıntılar ve örnekler için bkz. Varlıkları filtreleme, sıralama ve sayfalama.

Verilerinizi şifrelemek için Media Services'ı Azure Key Vault ile eşleştirmek için Azure CLI kullanma hakkında bilgi için, Media Services hesabında verileri şifrelemek için Key Vault anahtarı kullanma öğreticisine bakın.

Depolama hesabı bilinmeyen IP adreslerinden gelen istekleri engelleyecek şekilde yapılandırıldığında Media Services'ın bir depolama hesabına erişmesini istiyorsanız, Media Services yönetilen kimliğiyle depolamaya erişme bölümündeki adımları izleyin.

Bkz . Media Services hesabını abonelikler arasında taşıma.

Media Services hesapları için bkz. Azure rol tabanlı erişim denetimi (Azure RBAC).

Media Services aşağıdaki yerleşik rolleri tanımlar:

• Media Services Hesap Yöneticisi
• Media Services Media İşleci
• Media Services İlke Yöneticisi
• Media Services Akış Uç Noktaları Yöneticisi
• Media Services Canlı Etkinlik Yöneticisi

Bu roller, Media Services hesapları için Azure rol tabanlı erişim denetiminde (Azure RBAC) ayrıntılı olarak yer alır.

Bu roller, Media Services hesabına ayrıntılı erişim vermek için kullanılabilir. Media Services hesabına tüm erişime izin vermek için "Sahip" veya "Katkıda Bulunan" rolü kullanılabilir. Media Services,kullanımdan kaldırma yolunda ayrıntılı erişim denetimini desteklemeyen eski bir API'ye sahiptir. Ayrıntılı erişim denetimi gerektiren müşteriler portalı kullanarak Media Services hesabı oluştururken "Klasik API'leri etkinleştir" seçeneğini seçmemelidir (veya hesap oluşturmak için API kullanıyorlarsa 2020-05-01 API sürümünü kullanmamalıdır).

Eski API'yi destekleyen hesapların oluşturulmasını engellemek için aşağıdaki yerleşik Azure İlkesi kullanılabilir: Eski v2 API'sine erişime izin veren Azure Media Services hesapları engellenmelidir - Microsoft Azure

Media Services varlığı, karşıya yüklediğiniz her video dosyası için kullanılan bir Azure Depolama hesabı kapsayıcısıdır. Dönüşümler ve diğer işlemler ile kullanılan benzersiz bir tanımlayıcıya sahiptir. Bkz. Azure Media Services v3'teki varlıklar.

Bir medya dosyasını karşıya yükleyip kodlama veya akış gibi bir işlem yapmak istediğinizde, medya dosyasını ve ilişkili dosyaları depolamak için bir varlık oluşturursunuz. Azure portal kullanırsanız varlıklar sizin için otomatik olarak oluşturulur. Dosyaları karşıya yüklemek için portalı kullanmıyorsanız, önce bir varlık oluşturmanız gerekir.

Yaygın kodlama biçimleri Media Services Standard Encoder ile kullanılabilir. Tüm biçimlerin listesi için bkz. Standart Kodlayıcı biçimleri ve codec'leri.

Azure CLI, REST veya SDK'lardan herhangi birini kullanarak Azure portal iş oluşturabilirsiniz. Tercih ettiğiniz dil için Media Services örneklerine bakın.

Evet. Bkz . Otomatik olarak oluşturulan bit hızı merdiveni ile kodlama.

Evet. Media Services bir videoda iki geçişli analiz gerçekleştirebilir. Daha sonra videonun içeriğine göre en iyi uyarlamalı bit hızı kümesini, çözünürlükleri ve kodlama ayarlarını önerebilir.

Evet. Önceden kodlanmış tek bit hızlı bir MP4 dosyasını karşıya yüklemeyi ve sunucu bildirimini (.ism) ve istemci bildirimini (.ismc) oluşturmayı gösteren örnek bir uygulamanın ayrıntıları ve bağlantıları için paketleme ve teslim hakkındaki bölümdeki "Önceden kodlanmış veya başka bir çözümde kodlanmış mevcut MP4 dosyalarının akışını yapabilir miyim?" sorusunun yanıtına bakın. Bu yanıt, performansın kaynak üzerindeki etkisini de açıklar.

Bunu önermiyoruz. Süresi bir veya iki dakikadan kısa olan çok kısa içerik, bit hızı uyarlamalı akış için ideal değildir. Çok kısa biçimli dosyaların akışını yapmak istiyorsanız, içeriği tek bir bit hızı kullanılarak kolayca akışa alınabilecek bir biçimde önceden kodlamanızı öneririz.

Uyarlamalı bit hızına sahip oyuncuların çoğu videonun birden çok segmentini arabelleğe almak için zamana ihtiyaç duyduğundan ve uyarlamalı bit hızı merdivenini "kaydırmadan" önce ağ bant genişliğini analiz etmek için zamana ihtiyaç duyduğundan, 30 saniyenin altındaki içerikler için çok fazla bit hızı sağlamak genellikle işe yaramaz. Oyuncu, buluşsal algoritmasını ağ koşullarına göre oynatmak için doğru bit hızına kilitleyene kadar dosya akışı yapılır.

Buna ek olarak, bazı oyuncular varsayılan olarak en fazla üç video segmentini arabelleğe alır. Her segment iki ile altı saniye uzunluğunda olabilir. Çok kısa biçimli videolar için oynatıcının, uyarlamalı bit hızı kümesinin seçilen ilk bit hızını arabelleğe alıp oynatmaya başlaması muhtemeldir. Bu nedenle, HLS veya DASH bildirim oluşturma gereksiniminiz varsa tek bit hızlı bir MP4 dosyası kullanmanızı ve bir varlığa yüklemenizi öneririz. Bunu nasıl başarabileceğinize ilişkin ayrıntılar için paketleme ve teslim hakkındaki bölümdeki "Önceden kodlanmış veya başka bir çözümde kodlanmış mevcut MP4 dosyalarının akışını yapabilir miyim?" sorusunun yanıtına bakın.

Dosyaları yalnızca bu protokollerin özelliklerinden yararlanmak istiyorsanız HLS veya DASH biçiminde teslim etmek gerekir. Tek bit hızlı akışlar için, daha hızlı arama, dijital hak yönetimi (DRM) desteği ve blob depolamadaki aşamalı indirme MP4'e kıyasla URL aracılığıyla indirme zorluğu (ancak yine de mümkün!) gibi birçok şey sunabilirler. VTT ve IMSC1 için açıklamalı alt yazı desteği de bir diğer avantajdır. Buna ek olarak, ek ses işlemelerini veya alternatif dillerde dublajları geç bağlama özelliği, bunu bazı durumlar için değerli bir seçim haline getirir.

Video döndürme, videoyu altclip etme, videoları birleştirme, küçük resim ve sprite oluşturma gibi işlemleri yapmak için Media Services kodlayıcısını kullanmanın yollarını arıyorsanız Kod Örnekleri sayfasında bir ton kod örneğimiz vardır. Kullanılabilir örnek diller Node.JS, Python, .NET ve Java'dır.

Media Services canlı etkinliği, canlı video akışlarını alma ve bunları RTMPS protokolü veya Kesintisiz Akış aracılığıyla yayınlama işlemidir. Daha fazla bilgi için bkz . Media Services'da canlı etkinlikler ve canlı çıkışlar.

İlk adım, şirket içi kodlayıcı seçmektir. Wirecast ve OBS ile canlı etkinlik oluşturmaya yönelik örnekler sağladık. Media Services canlı etkinliklerine genel bir bakışla başlamak isterseniz bkz . Canlı etkinlik türleri.

Azure Media Service çeşitli protokollerde video, ses ve metin sunar. MPEG-DASH veya HLS/CMAF kullanarak canlı akışınızı yayımladığınızda, hizmet IMSC1.1 uyumlu TTML'de dökümü alınmış metni video ve ses ile birlikte sunar. Daha fazla bilgi için bkz. Canlı transkripsiyon.

Canlı etkinlikleri izlemek için Azure Event Grid etkinliklere abone olabilirsiniz. Daha fazla bilgi için bkz . Event Grid olay şeması. Şunlardan birini yapabilirsiniz:

• Akış düzeyi Microsoft.Media.LiveEventEncoderDisconnected olaylarına abone olun ve canlı etkinliğinizi durdurmak ve silmek için bir süre boyunca hiçbir yeniden bağlantının gelmediğini izleyin.
• İzleme düzeyi sinyal olaylarına abone olun. Tüm parçaların bit hızı 0'a düştüğünde veya son zaman damgası artmazsa canlı etkinliği güvenli bir şekilde kapatabilirsiniz. Sinyal olayları her parça için 20 saniyede bir gelir, bu nedenle biraz ayrıntılı olabilir.

Hayır, canlı etkinliği durdurup başlatırsanız aynı akış URL'sini kolayca kullanamazsınız. Yeni bir canlı çıkış (ve varlık) oluşturup yayımladığınızda, yeni bulucu için yeni bir akış URL'si (GUID) kullanılır. Bu şekilde, akış uç noktasında ve içerik teslim ağında (CDN) önbellek çakışması olmayacağından emin olursunuz. Akış bulucu için belirli bir GUID'yi zorlayabildiğiniz ve ardından canlı çıkış için kullanılacak bildirim adına karar verebileceğiniz için akış URL'lerini önceden hazırlayabilir (ve öğrenebilirsiniz).

Yarın oluşturacağınız canlı çıktı için GUID 1a7ed69e-a361-433d-8a56-29c61872744f kullanmaya karar verelim. Gün geldiğinde canlı etkinliği başlatır ve canlı bir çıkış oluşturursunuz. Bildirim için "conference1" kullanmaya karar verebilir ve bulucu için GUID'yi zorlayabilirsiniz.

Akış URL'si tahmin edilebilir ve şeklindedir http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Aynı canlı çıkışı veya varlığı birden çok kez yeniden kullanamazsınız. Canlı çıkışın ve varlığın birleşimini bir bant kaydı olarak düşünün. Canlı çıkış varlığa kaydedildikten sonra başka bir kayıt için yeniden kullanamazsınız. Bunu yeniden yaparsanız blob çakışması veya üzerine yazma olur. Depolama hesabındaki blobları tamamen temizlemeyi ve CDN'yi tamamen temizlemeyi planlamadığınız sürece sorunlarla karşılaşabilirsiniz. Parçalar CDN'de veya istemci cihaz önbelleklerinde (örneğin, tarayıcı önbelleği) önceden önbelleğe alınmış aşağı akış olduğundan sorunlarla karşılaşabilirsiniz.

En yaygın nedenlerden biri, çalıştırma durumunda kayıttan yürütmeye çalıştığınız akış uç noktasına sahip olmanızdır.

Media Services'te akış uç noktası, ortak akış medya protokollerinden (HLS veya DASH) birini kullanarak canlı ve isteğe bağlı içeriğinizi doğrudan bir istemci oynatıcı uygulamasına sunabilen dinamik (tam zamanında) paketleme ve kaynak hizmetini temsil eder. Ayrıca akış uç noktası, sektör lideri DRM sistemlerine dinamik (tam zamanında) şifreleme sağlar. Daha fazla bilgi için bkz. Azure Media Services'te akış uç noktaları (kaynak).

Videoları kayıttan yürütme için istemcilerin kullanımına açmak için bir akış bulucu oluşturur ve ardından akış URL'leri oluşturursunuz. Akış bulucuları, medya dosyalarının nasıl kullanıldığına ilişkin kurallar içeren akış ilkelerini uygulamak için de kullanılır.

Akış URL'si oluşturmak için önce bir akış bulucu oluşturursunuz. Ardından akış uç noktasının ana bilgisayar adını ve akış bulucunun yolunu birleştirirsiniz.

Akış ilkeleri, akış bulucularınız için akış protokollerini ve şifreleme seçeneklerini tanımlamanızı sağlar. Media Services v3 önceden tanımlanmış bazı akış ilkeleri sağlar. Daha fazla bilgi için bkz . Akış ilkeleri.

Başlamak için kullanabileceğiniz önceden tanımlanmış ilkelerin listesi için bkz . Akış ilkeleri.

Akış kaynağı sunucusuna Apple iOS yerel cihazlarında kullanılmak üzere HLS içeriği döndürmesini bildirmek için, yolunuzun sonunda (url'nin /manifest bölümünden sonra) (format=m3u8-cmaf) olduğundan emin olun. Ayrıntılar için bkz . İçerik teslim etme.

Evet, Media Services kaynak sunucusu (akış uç noktası), MP4 dosyalarının HLS veya DASH akış biçimine dinamik olarak paketlenmesi destekler. Ancak, içerik kapalı GOP biçiminde kodlanmalıdır ve iki ila altı saniyelik süre aralığında kısa GOP'lar olmalıdır. Şu ayarları öneririz: iki saniyelik GOP'lar, anahtar kare maksimum ve iki saniyelik minimum uzaklık, sabit bit hızı kodlaması (CBR modu). AAC ses biçimiyle birlikte H.264 veya HEVC video codec bileşeni aracılığıyla kodlanmış bu biçimdeki çoğu içerik desteklenebilir. Dolby DD+ gibi önceden kodlanmış ek ses biçimleri de desteklenebilir.

Bunu yapmanın anahtarı bir varlık oluşturmak, önceden kodlanmış varlıkları Azure Blob Depolama istemci SDK'larını kullanarak varlığın kapsayıcısına yüklemek ve ardından gerekli sunucu bildirimini (.ism) ve istemci bildirim dosyalarını oluşturmaktır. Ayrıntılar için Var olan MP4 dosyalarını akışla aktarma makalesindeki .NET örnek projesine bakın.

Media Services'teki yerleşik kodlayıcı, MP4 dosyalarına erişim süresini iyileştiren ikili dizinler (.mpi dosyaları) da oluşturduğundan, bu yaklaşımı kullandığınızda performans etkilerinin olabileceğini unutmayın. Bu dosyalar olmadan, sunucu yüksek yükte biraz daha fazla CPU kullanabilir. Daha fazla bilgi için bkz . HLS veya Dash ile mevcut bir tek bit hızlı MP4 dosyasını akışla aktarma.

Bu yaklaşımla ölçeği artırdığınızda akış uç noktasının CPU yükünü izlemeniz gerekir. Media Services dışında önceden kodlanmış büyük bir MP4 dosyası kitaplığıyla üretime gitmeyi planlıyorsanız, mimarinizin gözden geçirilmesini sağlamak ve önceden kodlanmış MP4 içeriğinin kaynak sunucu performansını iyileştirmenin yollarını sormak için bir destek bileti oluşturun.

v2 API'siyle oluşturulan akış bulucuları, v2 API'miz kapatıldıktan sonra çalışmaya devam edecektir. Media Services arka uç veritabanında Akış Bulucu verileri oluşturulduktan sonra akış için v2 REST API'sine bağımlılık olmaz. Şubat 2024'te v2 kapatıldığında v2'ye özgü kayıtları veritabanından kaldırmayacağız.

v2 ile oluşturulan varlıkların ve bulucuların yeni v3 API kullanılarak erişilemeyen veya güncelleştirilemeyen bazı özellikleri vardır. Örneğin, v2, v3 API'sinde eşdeğer bir özelliğe sahip olmayan bir Varlık Dosyaları API'sini kullanıma sunar. Yaygın olarak kullanılan bir özellik olmadığından ve artık ihtiyaç duyulmadığında eski bulucuların akışını yapabilir ve silebilirsiniz.

Geçişten sonra, akış bulucularını veya varlıklarını değiştirmek için v2 API'sine çağrı yapmaktan kaçınmanız gerekir.

Dinamik şifreleme, medyanızı bilgisayarınızdan ayrılışından itibaren depolama, işleme ve teslim işlemleri boyunca güvenli hale getirir. Media Services ile canlı ve isteğe bağlı içeriğinizi Gelişmiş Şifreleme Standardı (AES-128) veya başlıca üç DRM sisteminden herhangi biriyle dinamik olarak şifrelenmiş olarak sunabilirsiniz: Microsoft PlayReady, Google Widevine ve Apple FairPlay. Daha fazla bilgi için bkz. Media Services dinamik şifrelemesi ile içeriğinizi koruma.

Müşteriler genellikle AES şifrelemesi mi yoksa DRM sistemi mi kullanması gerektiğini merak eder. İki sistem arasındaki temel fark, AES şifrelemesi ile içerik anahtarının TLS üzerinden istemciye iletilmesidir. Anahtar aktarım sırasında ek şifreleme olmadan şifrelenir ("açık") . Sonuç olarak, içeriğin şifresini çözmek için kullanılan anahtar istemci oynatıcı tarafından erişilebilir ve istemcideki bir ağ izlemesinde düz metin olarak görüntülenebilir. AES-128 şifresiz anahtar şifrelemesi, görüntüleyicinin güvenilir bir taraf olduğu kullanım örnekleri için uygundur (örneğin, çalışanlar tarafından görüntülenmek üzere bir şirket içinde dağıtılan kurumsal videoları şifreleme).

PlayReady, Widevine ve FairPlay gibi DRM sistemleri, AES-128 şifresiz anahtarına kıyasla içeriğin şifresini çözmek için kullanılan anahtar üzerinde ek bir şifreleme düzeyi sağlar. İçerik anahtarı, TLS'nin sağladığı aktarım düzeyi şifrelemeye ek olarak DRM çalışma zamanı tarafından korunan bir anahtarla şifrelenir. Şifre çözme, kötü amaçlı bir kullanıcının saldırmasının daha zor olduğu işletim sistemi düzeyinde güvenli bir ortamda işlenir. Görüntüleyicinin güvenilir bir taraf olmayabileceği ve en yüksek güvenlik düzeyine ihtiyacınız olduğu kullanım örnekleri için DRM'yi öneririz.

Azure Active Directory (Azure AD) gibi belirli bir belirteç sağlayıcısını kullanmanız gerekmez. Asimetrik anahtar şifrelemesi kullanarak kendi JWT sağlayıcınızı (Güvenli Belirteç Hizmeti veya STS olarak adlandırılır) oluşturabilirsiniz. Özel STS'nizde, iş mantığınıza göre talep ekleyebilirsiniz.

Verenin, hedef kitlenin ve taleplerin tümünün JWT'deki ile içinde kullanılan ContentKeyPolicydeğer arasında tam olarak eşleştiğinden ContentKeyPolicyRestriction emin olun.

Daha fazla bilgi için bkz . Media Services dinamik şifrelemesini kullanarak içeriğinizi koruma.

Üretim için, HTTPS isteği üzerine JWT belirteci veren Güvenli Belirteç Hizmeti'ne (yani bir web hizmetine) sahip olmanız gerekir. Test için Program.cs dosyasında tanımlanan yöntemde GetTokenAsync gösterilen kodu kullanabilirsiniz.

Bir kullanıcının kimliği doğrulandıktan sonra, oyuncu böyle bir belirteç için STS'ye bir istekte bulunur ve bunu belirtecin değeri olarak atar. Azure Media Player API'sini kullanabilirsiniz.

Simetrik anahtar veya asimetrik anahtar ile STS çalıştırma örneği için bkz. JWT aracı. Böyle bir JWT belirteci kullanan Azure Media Player'ı temel alan bir oynatıcı örneği için bkz. Azure medya testi aracı. (Belirteç girişini görmek için player_settings bağlantısını genişletin.)

Doğru yaklaşım, Güvenli Belirteç Hizmeti'ni kullanmaktır. STS'de, kullanıcı profiline bağlı olarak farklı talepler ekleyin ("Premium Kullanıcı", "Temel Kullanıcı" veya "Ücretsiz Deneme Kullanıcısı" gibi). JWT'de farklı talepler olduğunda, kullanıcı farklı içerikleri görebilir. Farklı içerikler veya varlıklar ContentKeyPolicyRestriction için karşılık gelen RequiredClaims değere sahip olacaktır.

Lisans/anahtar teslimini yapılandırmak ve varlıklarınızı şifrelemek için Azure Media Services API'lerini kullanın ( bu örnekte gösterildiği gibi).

Bu davranış, örnek uygulamanın tasarımına göre oluşturulmuş gibi görünüyor. Çevrimdışı modda alternatif bir ses parçası (HLS için geçerlidir) mevcut olduğunda, hem iOS 10 hem de iOS 11 varsayılan olarak alternatif ses parçası olur. FPS çevrimdışı modunda bu davranışı telafi etmek için alternatif ses parçasını akıştan kaldırın. Bunu Media Services'da yapmak için audio-only=false dinamik bildirim filtresini ekleyin. Başka bir deyişle, HLS URL'si .ism/manifest(format=m3u8-aapl,audio-only=false) ile biter.

İçerik teslim ağının önbellek anahtarı tasarımına bağlı olarak, içerik önbelleğe alınmış olabilir. Önbelleği temizleyin.

Bir iOS cihazında indirilen dosya yapısı aşağıdaki ekran görüntüsüne benzer. _keys klasörü, indirilen FPS lisanslarını depolar ve her lisans hizmeti konağı için bir depo dosyası bulunur. .movpkg klasörü ses ve video içeriğini depolar.

Adı kısa çizgiyle biten ve ardından bir sayıyla biten ilk klasör video içeriği içerir. Sayısal değer, video işlemelerinin en yüksek bant genişliğidir. Adında tire ve ardından 0 bulunan ikinci klasörde ses içeriği bulunur. Data adlı üçüncü klasör, FPS içeriğinin ana çalma listesini içerir. Son olarak ,boot.xml.movpkg klasör içeriğinin tam açıklamasını sağlar.

Örnek bir boot.xml dosyası aşağıda verilmişti:

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

Media Services v3 bir varlığın birden çok StreamingLocator örneğine sahip olmasını sağladığından şunları yapabilirsiniz:

• ContentKeyPolicy üzerinde talebi "persistent"olan bir örneği license_type = "persistent"ContentKeyPolicyRestriction ve örneğini StreamingLocator içeren bir örnek.
• " ContentKeyPolicyRestriction üzerinde talep içeren ile başka ContentKeyPolicy bir örnek license_type="nonpersistent"ve StreamingLocator"nonpersistentörneği.
• Farklı ContentKey değerlere sahip iki StreamingLocator örnek.

Özel STS'nin iş mantığına bağlı olarak, JWT belirtecinde farklı talepler verilir. Belirteçle yalnızca ilgili lisans alınabilir ve yalnızca ilgili URL oynatılabilir.

Google'ın Widevine DRM Mimarisine Genel Bakış üç güvenlik düzeyi tanımlar. Ancak Widevine lisans şablonundaki Azure Media Services belgelerinde beş güvenlik düzeyi (kayıttan yürütme için istemci sağlamlığı gereksinimleri) özetlenmektedir.

Google Widevine her iki güvenlik düzeyi kümesini de tanımlar. Fark kullanım düzeyindedir: mimari veya API. Widevine API'sinde beş güvenlik düzeyi kullanılır. Azure Media Services Widevine lisans hizmeti, öğesini içeren security_levelnesnesini seri durumdan content_key_specs çıkararak Widevine genel teslim hizmetine geçirir. Aşağıdaki tabloda iki güvenlik düzeyi kümesi arasındaki eşleme gösterilmektedir.

Media Services kaynaklarınızda neler olduğunu izlemek için Azure İzleyici'yi kullanın. Daha fazla bilgi için bkz. Media Services'ı izleme. Nasıl yapılır kılavuzları sayfanın sonunda listelenir.

Canlı etkinliğinizi yoklama hizmeti olmadan izlemek için Azure Event Grid kullanın. bkz. Azure portal kullanarak Event Grid ile Media Services olayları oluşturma ve izleme.

Media Services birçok oyuncuyla çalışır. Uyumlu medya oynatıcıların listesine bakın veya üçüncü taraf oyuncu örneklerini deneyin.

Media Services ve yüksek kullanılabilirlik hakkında bilgi için bkz. Media Services ile yüksek kullanılabilirlik ve İsteğe Bağlı Video (VOD).

v2'den v3'e geçiş için kapsamlı bir kılavuz oluşturduk. Geçiş deneyiminizi ve gereksinimlerinizi öğrenmekle ilgileniyoruz, bu nedenle GitHub sorunu veya destek bileti aracılığıyla geri bildirim sağlamaktan çekinmeyin.

Aşağıdaki başvurularda hata kodlarını belgeledik: Akış uç noktası hata kodları, Canlı olay hata kodları ve İş hata kodları. Yanıtları orada bulamazsanız lütfen bir destek bileti oluşturun.

Azure CLI kullanarak hesap kimlik bilgilerinizi sıfırlayabilirsiniz.

Bkz. Media Services fiyatlandırma kılavuzu.

Bkz. Media Services kotaları ve sınırları.

Müşteriler Azure Media Services hesaplarına kendi depolama hesaplarını ekler. Tüm varlık verileri bu ilişkili depolama hesaplarında depolanır ve müşteri bu depolamanın konumunu ve çoğaltma türünü denetler.

Media Services hesabıyla ilişkili ek veriler (içerik şifreleme anahtarları, belirteç doğrulama anahtarları, JobInputHttp URL'leri ve diğer varlık meta verileri dahil) Media Services hesabı için seçilen bölge içinde Microsoft'a ait depolama alanında depolanır.

Güney Brezilya ve Güneydoğu Asya'daki veri yerleşimi gereksinimleri nedeniyle, ek hesap verileri alanlar arası yedekli bir şekilde depolanır ve tek bir bölgede yer alır. Güneydoğu Asya için tüm ek hesap verileri Singapur'da depolanır. Güney Brezilya için veriler Brezilya'da depolanır. Güney Brezilya ve Güneydoğu Asya dışındaki bölgelerde, ek hesap verileri eşleştirilmiş bölgedeki Microsoft'a ait depolama alanında da depolanabilir.

Azure Media Services bölgesel bir hizmettir ve yüksek kullanılabilirlik veya veri çoğaltması sağlamaz. Bu özelliklere ihtiyaç duyan müşterilerin birden çok bölgede Media Services hesaplarını kullanarak bir çözüm oluşturmasını öneririz. İsteğe bağlı Media Services videosuyla yüksek kullanılabilirliğe yönelik bir çözüm oluşturmayı gösteren bir örnek, kılavuz olarak sağlanır.