Często zadawane pytania dotyczące usługi Azure Media Services

Zobacz przewodnik po wycofaniu usługi Azure Media Services

Oto lista:

• Specyfikacja interfejsu OpenAPI (Swagger)
• Interfejs wiersza polecenia platformy Azure
• .NET
• Java
• Python
• Node.js
• Przejdź

Nie zalecamy opakowowania interfejsu API REST dla usługi Media Services bezpośrednio do własnego kodu biblioteki. W tym celu w celach produkcyjnych należy zaimplementować pełną logikę ponawiania prób platformy Azure Resource Manager i zrozumieć, jak zarządzać długotrwałymi operacjami w interfejsach API Resource Manager. Zestawy SDK klienta dla różnych języków — na przykład .NET, Java, TypeScript, Python i Ruby — obsługują je automatycznie, aby zmniejszyć szanse na problemy z logiką ponawiania prób lub nieudanymi wywołaniami interfejsu API.

Zobacz strony przykładów. Istnieją przykłady dla kont, zasobów, transmisji strumieniowej na żywo, przesyłania strumieniowegoVOD, ochrony zawartości, kodowania, analizy i używania graczy.

W przypadku korzystania z stronicowania zawsze należy użyć następnego linku, aby wyliczyć kolekcję i nie zależy od określonego rozmiaru strony. Aby uzyskać szczegółowe informacje i przykłady, zobacz Filtrowanie, porządkowanie i stronicowanie jednostek.

Aby uzyskać informacje na temat używania interfejsu wiersza polecenia platformy Azure do parowania usługi Media Services z usługą Azure Key Vault do szyfrowania danych, zobacz samouczek Używanie klucza Key Vault do szyfrowania danych na koncie usługi Media Services.

Jeśli chcesz, aby usługa Media Services uzyskiwała dostęp do konta magazynu, gdy konto magazynu jest skonfigurowane do blokowania żądań z nieznanych adresów IP, wykonaj kroki opisane w temacie Uzyskiwanie dostępu do magazynu przy użyciu tożsamości zarządzanej usługi Media Services.

Zobacz Przenoszenie konta usługi Media Services między subskrypcjami.

Zobacz Kontrola dostępu oparta na rolach (RBAC) platformy Azure dla kont usługi Media Services.

Usługa Media Services definiuje następujące wbudowane role:

• Administrator konta usługi Media Services
• Media Services Media Operator
• Administrator zasad usługi Media Services
• Administrator punktów końcowych przesyłania strumieniowego usługi Media Services
• Administrator zdarzeń na żywo usługi Media Services

Te role są szczegółowo opisane w temacie Kontrola dostępu oparta na rolach (RBAC) platformy Azure dla kont usługi Media Services.

Te role mogą służyć do zapewniania szczegółowego dostępu do konta usługi Media Services. Aby zezwolić na dostęp do konta usługi Media Services, można użyć roli "Właściciel" lub "Współautor". Usługa Media Services ma starszy interfejs API w ścieżce wycofywania, która nie obsługuje szczegółowej kontroli dostępu. Klienci, którzy wymagają szczegółowej kontroli dostępu, nie powinni wybierać opcji "Włącz klasyczne interfejsy API" podczas tworzenia konta usługi Media Services przy użyciu portalu (lub użyć wersji interfejsu API 2020-05-01, jeśli używają interfejsu API do tworzenia kont).

Następujące wbudowane Azure Policy mogą służyć do blokowania tworzenia kont obsługujących stary interfejs API: konta usługi Azure Media Services, które zezwalają na dostęp do starszego interfejsu API w wersji 2, powinny być blokowane — Microsoft Azure

Zasób usługi Media Services to kontener konta usługi Azure Storage używany dla każdego przekazanego pliku wideo. Ma unikatowy identyfikator używany z przekształceniami i innymi operacjami. Zobacz Zasoby w usłudze Azure Media Services w wersji 3.

Za każdym razem, gdy chcesz przekazać plik multimedialny i zrobić z nim coś, na przykład kodowanie lub przesyłanie strumieniowe, należy utworzyć zasób do przechowywania pliku multimedialnego i skojarzonych plików. Zasoby są tworzone automatycznie, jeśli używasz Azure Portal. Jeśli nie używasz portalu do przekazywania plików, musisz najpierw utworzyć zasób.

Typowe formaty kodowania są dostępne w programie Media Services Standard Encoder. Aby uzyskać listę wszystkich formatów, zobacz Standardowe formaty kodera i kodery.

Zadanie można utworzyć w Azure Portal przy użyciu interfejsu wiersza polecenia platformy Azure, rest lub dowolnego zestawu SDK. Zapoznaj się z przykładami usługi Media Services , aby zapoznać się z preferowanym językiem.

Tak. Zobacz Kodowanie za pomocą drabiny z automatyczną szybkością transmisji bitów.

Tak. Usługa Media Services może przeprowadzić analizę dwuprzepustową na filmie wideo. Następnie może zalecić najlepszy zestaw, rozdzielczość i ustawienia kodowania adaptacyjnego szybkości transmisji bitów na podstawie zawartości filmu wideo.

Tak. Aby uzyskać szczegółowe informacje i linki do przykładowej aplikacji, która pokazuje, jak przekazać plik MP4 o pojedynczej szybkości transmisji bitów zakodowany wstępnie i wygenerować manifest serwera (.ism) i manifest klienta (ismc), zobacz odpowiedź na pytanie "Czy mogę przesyłać strumieniowo istniejące pliki MP4, które są wstępnie zakodowane lub zakodowane w innym rozwiązaniu?" w sekcji dotyczącej pakowania i dostarczania. Ta odpowiedź opisuje również wpływ wydajności na pochodzenie.

Nie zalecamy tego. Bardzo krótka zawartość, która jest mniejsza niż minuta lub dwie w czasie trwania, nie jest idealna do przesyłania strumieniowego z adaptacyjną szybkością transmisji bitów. Jeśli zamierzasz przesyłać strumieniowo bardzo krótkie pliki, zalecamy wstępne zakodowanie zawartości do formatu, który jest łatwo przesyłany strumieniowo przy użyciu pojedynczej szybkości transmisji bitów.

Ponieważ większość adaptacyjnych odtwarzaczy transmisji bitów potrzebuje czasu na buforowanie wielu segmentów wideo, a także czasu na analizowanie przepustowości sieci przed "przesunięciem" w górę lub w dół drabiny adaptacyjnej szybkości transmisji bitów, często jest bezużyteczne, aby zapewnić dużo szybkości transmisji bitów dla zawartości, która jest poniżej 30 sekund. Do czasu, gdy odtwarzacz zablokuje algorytm heurystyczny z prawej szybkości transmisji bitów do odtwarzania na podstawie warunków sieciowych, plik zostanie wykonany strumieniowo.

Ponadto niektórzy gracze domyślnie buforowali maksymalnie trzy segmenty wideo. Każdy segment może trwać od dwóch do sześciu sekund. W przypadku bardzo krótkich filmów wideo odtwarzacz prawdopodobnie buforuje i rozpoczyna odtwarzanie pierwszej wybranej szybkości transmisji bitów z adaptacyjną szybkością transmisji bitów. Z tego powodu zalecamy użycie pliku MP4 o pojedynczej szybkości transmisji bitów i przekazanie go do zasobu, jeśli potrzebujesz generowania manifestu HLS lub DASH. Aby uzyskać szczegółowe informacje na temat osiągnięcia tego celu, zobacz odpowiedź na pytanie "Czy mogę przesyłać strumieniowo istniejące pliki MP4, które są wstępnie zakodowane lub zakodowane w innym rozwiązaniu?" w sekcji dotyczącej pakowania i dostarczania.

Należy dostarczyć pliki w formacie HLS lub DASH tylko wtedy, gdy chcesz skorzystać z możliwości tych protokołów. W przypadku strumieni o pojedynczej szybkości transmisji bitów nadal mogą oferować wiele ofert — takich jak szybsze wyszukiwanie, obsługa zarządzania prawami cyfrowymi (DRM) i zwiększona trudność pobierania za pośrednictwem adresu URL (ale nadal jest to możliwe!) niż progresywne pobieranie MP4 w magazynie obiektów blob. Obsługa podpisów dla VTT i IMSC1 to kolejna korzyść. Ponadto możliwość opóźnionego wiązania dodatkowych odwzorowań dźwiękowych lub dubbingów w językach alternatywnych sprawia, że jest to cenny wybór w niektórych sytuacjach.

Jeśli szukasz sposobów użycia kodera usługi Media Services do wykonywania takich czynności jak obracanie wideo, podkrop wideo, łączenie filmów wideo, tworzenie miniatur i sprites, mamy mnóstwo przykładów kodu na stronie Przykłady kodu. Dostępne przykładowe języki obejmują Node.JS, Python, .NET i Java.

Wydarzenie na żywo usługi Media Services to proces pozyskiwania kanałów wideo na żywo i nadawania ich za pośrednictwem protokołu RTMPS lub Smooth Streaming. Aby uzyskać więcej informacji, zobacz Wydarzenia na żywo i dane wyjściowe na żywo w usłudze Media Services.

Pierwszym krokiem jest wybranie kodera lokalnego. Przedstawiliśmy przykłady tworzenia wydarzenia na żywo za pomocą usługi Wirecast i OBS. Jeśli wolisz zacząć od omówienia wydarzeń na żywo w usłudze Media Services, zobacz Typy zdarzeń na żywo.

Usługa Azure Media Service udostępnia wideo, dźwięk i tekst w różnych protokołach. Po opublikowaniu strumienia na żywo przy użyciu formatu MPEG-DASH lub HLS/CMAF wraz z wideo i audio usługa dostarcza transkrypcji tekstu w formacie TTML zgodnym z protokołem IMSC1.1. Aby uzyskać więcej informacji, zobacz Transkrypcja na żywo.

Możesz monitorować wydarzenia na żywo, subskrybując Azure Event Grid zdarzenia. Aby uzyskać więcej informacji, zobacz Schemat zdarzeń usługi Event Grid. Można:

• Zasubskrybuj zdarzenia Microsoft.Media.LiveEventEncoderDisconnected na poziomie strumienia i monitoruj, że nie są na chwilę ponownie nawiążone połączenia, aby zatrzymać i usunąć wydarzenie na żywo.
• Zasubskrybuj zdarzenia pulsu na poziomie śledzenia. Jeśli wszystkie ścieżki mają spadek szybkości transmisji bitów przychodzących do 0 lub ostatni sygnatura czasowa nie rośnie, można bezpiecznie zamknąć wydarzenie na żywo. Zdarzenia pulsu pojawiają się co 20 sekund dla każdego toru, więc może to być nieco pełne.

Nie, nie można łatwo użyć tego samego adresu URL przesyłania strumieniowego, jeśli zatrzymasz i uruchomisz wydarzenie na żywo. Za każdym razem, gdy tworzysz i publikujesz nowe dane wyjściowe na żywo (i zasób), nowy adres URL przesyłania strumieniowego (GUID) będzie używany dla nowego lokalizatora. W ten sposób na pewno nie będzie żadnych konfliktów pamięci podręcznej w punkcie końcowym przesyłania strumieniowego i sieci dostarczania zawartości (CDN). Możesz przygotować (i znać) adresy URL przesyłania strumieniowego z wyprzedzeniem, ponieważ można wymusić określony identyfikator GUID lokalizatora przesyłania strumieniowego, a następnie zdecydować, czy nazwa manifestu ma być używana dla danych wyjściowych na żywo.

Załóżmy, że zdecydujesz się użyć identyfikatora GUID 1a7ed69e-a361-433d-8a56-29c61872744f dla danych wyjściowych na żywo, które utworzysz jutro. Kiedy nadejdzie dzień, rozpoczniesz wydarzenie na żywo i utworzysz dane wyjściowe na żywo. Możesz zdecydować się na użycie "conference1" dla manifestu i wymusić identyfikator GUID lokalizatora.

Adres URL przesyłania strumieniowego jest przewidywalny i ma wartość http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Nie można wielokrotnie używać tych samych danych wyjściowych ani elementów zawartości na żywo. Połączenie danych wyjściowych i elementów zawartości na żywo można traktować jako nagranie na taśmie. Po zarejestrowaniu danych wyjściowych na żywo w zasobie nie można użyć go ponownie do innego nagrania. Jeśli to zrobisz ponownie, wystąpi konflikt obiektów blob lub zostaną zastąpione. Jeśli nie planujesz całkowitego przeczyszczania obiektów blob na koncie magazynu i całkowitego przeczyszczania sieci CDN, wystąpią problemy. Prawdopodobnie nadal będą występować problemy, ponieważ fragmenty są już buforowane podrzędnie w sieci CDN lub w pamięciach podręcznych urządzeń klienckich (na przykład w pamięci podręcznej przeglądarki).

Jedną z najczęstszych przyczyn jest to, że nie masz punktu końcowego przesyłania strumieniowego, z którego próbujesz odtworzyć stan działania.

W usłudze Media Services punkt końcowy przesyłania strumieniowego reprezentuje dynamiczne (just in time) pakowanie i usługę pochodzenia, która może dostarczać zawartość na żywo i na żądanie bezpośrednio do aplikacji odtwarzacza klienta przy użyciu jednego z typowych protokołów multimediów przesyłania strumieniowego (HLS lub DASH). Ponadto punkt końcowy przesyłania strumieniowego zapewnia dynamiczne (just in time) szyfrowanie do wiodących w branży systemów DRM. Aby uzyskać więcej informacji, zobacz Streaming endpoints (origin) in Azure Media Services (Punkty końcowe przesyłania strumieniowego (origin) w usłudze Azure Media Services.

Aby udostępnić filmy wideo klientom do odtwarzania, należy utworzyć lokalizator przesyłania strumieniowego, a następnie utworzyć adresy URL przesyłania strumieniowego. Lokalizatory przesyłania strumieniowego są również używane do stosowania zasad przesyłania strumieniowego zawierających reguły dotyczące sposobu korzystania z plików multimedialnych.

Aby utworzyć adres URL przesyłania strumieniowego, należy najpierw utworzyć lokalizator przesyłania strumieniowego. Następnie połączysz nazwę hosta punktu końcowego przesyłania strumieniowego i ścieżkę lokalizatora przesyłania strumieniowego.

Zasady przesyłania strumieniowego umożliwiają definiowanie protokołów przesyłania strumieniowego i opcji szyfrowania dla lokalizatorów przesyłania strumieniowego. Usługa Media Services w wersji 3 udostępnia niektóre wstępnie zdefiniowane zasady przesyłania strumieniowego. Aby uzyskać więcej informacji, zobacz Zasady przesyłania strumieniowego.

Aby uzyskać listę wstępnie zdefiniowanych zasad, których można użyć do rozpoczęcia pracy, zobacz Zasady przesyłania strumieniowego.

Upewnij się, że na końcu ścieżki ( po części adresu URL /manifest) na końcu ścieżki (po części adresu URL /manifest ) upewnij się, że serwer pochodzenia przesyłania strumieniowego zwróci zawartość HLS do użycia na urządzeniach natywnych dla systemu iOS firmy Apple. Aby uzyskać szczegółowe informacje, zobacz Dostarczanie zawartości.

Tak, serwer źródłowy usługi Media Services (punkt końcowy przesyłania strumieniowego) obsługuje dynamiczne pakowanie plików MP4 do formatu przesyłania strumieniowego HLS lub DASH. Jednak zawartość musi być zakodowana w formacie closed-GOP z krótkimi adresami GOP w zakresie czasu trwania od dwóch do sześciu sekund. Zalecamy następujące ustawienia: dwusekundowe adresy GOPs, maksymalna ramka klucza i minimalna odległość dwóch sekund, kodowanie stałej szybkości transmisji bitów (tryb CBR). Większość zawartości w tym formacie zakodowana za pomocą kodera-dekodera wideo H.264 lub HEVC, wraz z formatem audio AAC, może być obsługiwana. Mogą być również obsługiwane dodatkowe formaty audio, które są wstępnie zakodowane, takie jak Dolby DD+.

Kluczem do jego działania jest utworzenie elementu zawartości, przekazanie wstępnie zakodowanych zasobów do kontenera zasobu przy użyciu zestawów SDK klienta Azure Blob Storage, a następnie wygenerowanie wymaganego manifestu serwera (ism) i plików manifestu klienta. Aby uzyskać szczegółowe informacje, zobacz przykładowy projekt platformy .NET w temacie Stream existing MP4 files (Przesyłanie strumieniowe istniejących plików MP4).

Należy pamiętać, że w przypadku korzystania z tego podejścia występują konsekwencje dotyczące wydajności, ponieważ wbudowany koder w usłudze Media Services generuje również indeksy binarne (pliki mpi), które zwiększają czas dostępu do plików MP4. Bez tych plików serwer może używać nieco więcej procesora CPU przy dużym obciążeniu. Aby uzyskać więcej informacji, zobacz Przesyłanie strumieniowe istniejącego pliku MP4 o pojedynczej szybkości transmisji bitów z HLS lub Dash.

Podczas skalowania w górę przy użyciu tego podejścia należy monitorować obciążenie procesora CPU punktu końcowego przesyłania strumieniowego. Jeśli planujesz przejść do środowiska produkcyjnego z dużą biblioteką plików MP4, które są wstępnie zakodowane poza usługą Media Services, utwórz bilet pomocy technicznej, aby twoja architektura została sprawdzona i zapytać o sposoby poprawy wydajności serwera pochodzenia wstępnie zakodowanej zawartości MP4.

Lokalizatory przesyłania strumieniowego utworzone za pomocą interfejsu API w wersji 2 będą nadal działać po wyłączeniu interfejsu API w wersji 2. Po utworzeniu danych lokalizatora przesyłania strumieniowego w bazie danych zaplecza usługi Media Services nie ma zależności od interfejsu API REST w wersji 2 na potrzeby przesyłania strumieniowego. Nie usuniemy rekordów specyficznych dla wersji 2 z bazy danych, gdy wersja 2 zostanie wyłączona w lutym 2024 r.

Istnieją pewne właściwości zasobów i lokalizatorów utworzonych za pomocą wersji 2, do których nie można uzyskać dostępu lub zaktualizować przy użyciu nowego interfejsu API w wersji 3. Na przykład wersja 2 uwidacznia interfejs API plików elementów zawartości , który nie ma równoważnej funkcji w interfejsie API w wersji 3. Często nie jest to problem dla większości naszych klientów, ponieważ nie jest to powszechnie używana funkcja i nadal można przesyłać strumieniowo stare lokalizatory i usuwać je, gdy nie są już potrzebne.

Po migracji należy unikać wykonywania wywołań interfejsu API w wersji 2 w celu modyfikowania lokalizatorów przesyłania strumieniowego lub zasobów.

Szyfrowanie dynamiczne zabezpiecza nośnik od momentu opuszczenia komputera przez magazyn, przetwarzanie i dostarczanie. Usługa Media Services umożliwia dynamiczne dostarczanie zawartości na żywo i na żądanie za pomocą standardu Advanced Encryption Standard (AES-128) lub dowolnej z trzech głównych systemów DRM: Microsoft PlayReady, Google Widevine i Apple FairPlay. Aby uzyskać więcej informacji, zobacz Ochrona zawartości za pomocą szyfrowania dynamicznego usługi Media Services.

Klienci często zastanawiają się, czy powinni używać szyfrowania AES, czy systemu DRM. Główną różnicą między dwoma systemami jest to, że w przypadku szyfrowania AES klucz zawartości jest przesyłany do klienta za pośrednictwem protokołu TLS. Klucz jest szyfrowany podczas przesyłania bez dodatkowego szyfrowania ("w jasnym przypadku"). W związku z tym klucz używany do odszyfrowywania zawartości jest dostępny dla odtwarzacza klienta i można go wyświetlić w śladzie sieciowym na kliencie w postaci zwykłego tekstu. Szyfrowanie klucza jasnego AES-128 jest odpowiednie w przypadkach użycia, w których osoba przeglądająca jest zaufaną stroną (na przykład szyfrowanie firmowych filmów wideo dystrybuowanych w firmie do wyświetlania przez pracowników).

Systemy DRM, takie jak PlayReady, Widevine i FairPlay, zapewniają dodatkowy poziom szyfrowania klucza używanego do odszyfrowywania zawartości w porównaniu z kluczem clear AES-128. Klucz zawartości jest szyfrowany do klucza chronionego przez środowisko uruchomieniowe DRM oprócz szyfrowania na poziomie transportu zapewnianego przez protokół TLS. Odszyfrowywanie jest obsługiwane w bezpiecznym środowisku na poziomie systemu operacyjnego, gdzie trudniej jest atakować złośliwego użytkownika. Zalecamy drM w przypadku przypadków użycia, w których osoba przeglądająca może nie być zaufaną stroną i potrzebujesz najwyższego poziomu zabezpieczeń.

Nie musisz używać żadnego określonego dostawcy tokenów, takiego jak usługa Azure Active Directory (Azure AD). Możesz utworzyć własnego dostawcę JWT (tzw. secure token service lub STS) przy użyciu szyfrowania klucza asymetrycznego. W niestandardowych usługach STS można dodawać oświadczenia na podstawie logiki biznesowej.

Upewnij się, że wystawca, odbiorcy i oświadczenia pasują dokładnie między wartością JWT a wartością używaną w elemencie ContentKeyPolicyRestrictionContentKeyPolicy.

Aby uzyskać więcej informacji, zobacz Ochrona zawartości przy użyciu szyfrowania dynamicznego usługi Media Services.

W przypadku środowiska produkcyjnego musisz mieć usługę bezpiecznego tokenu (czyli usługę internetową), która wystawia token JWT na żądanie HTTPS. Do testowania można użyć kodu pokazanego w metodzie zdefiniowanej GetTokenAsync w pliku Program.cs.

Po uwierzytelnieniu użytkownika gracz wysyła żądanie do usługi STS dla takiego tokenu i przypisuje go jako wartość tokenu. Możesz użyć interfejsu API usługi Azure Media Player.

Aby zapoznać się z przykładem uruchamiania usługi STS z kluczem symetrycznym lub kluczem asymetrycznym, zobacz narzędzie JWT. Aby zapoznać się z przykładem odtwarzacza opartego na usłudze Azure Media Player, który używa takiego tokenu JWT, zobacz narzędzie do testowania multimediów platformy Azure. (Rozwiń link player_settings , aby wyświetlić dane wejściowe tokenu).

Prawidłową metodą jest użycie usługi bezpiecznego tokenu. W usłudze STS, w zależności od profilu użytkownika, dodaj różne oświadczenia (takie jak "Użytkownik Premium", "Użytkownik podstawowy" lub "Użytkownik bezpłatnej wersji próbnej"). W przypadku różnych oświadczeń w JWT użytkownik może zobaczyć różne treści. W przypadku różnych zawartości lub zasobów ContentKeyPolicyRestriction będzie miała odpowiednią RequiredClaims wartość.

Użyj interfejsów API usługi Azure Media Services do konfigurowania dostarczania licencji/klucza i szyfrowania zasobów (jak pokazano w tym przykładzie).

To zachowanie wydaje się być oparte na projekcie przykładowej aplikacji. Gdy istnieje alternatywny utwór audio (w przypadku HLS) w trybie offline, zarówno system iOS 10, jak i iOS 11 domyślnie do alternatywnej ścieżki audio. Aby zrekompensować to zachowanie w trybie offline FPS, usuń alternatywny utwór audio ze strumienia. Aby to zrobić w usłudze Media Services, dodaj dynamiczny filtr manifestu tylko audio=false. Innymi słowy, adres URL HLS kończy się ciągiem .ism/manifest(format=m3u8-aapl,audio-only=false).

W zależności od projektu klucza pamięci podręcznej dla sieci dostarczania zawartości zawartość może być buforowana. Przeczyść pamięć podręczną.

Struktura pobranego pliku na urządzeniu z systemem iOS wygląda podobnie jak na poniższym zrzucie ekranu. Folder _keys przechowuje pobrane licencje FPS z jednym przechowywanym plikiem dla każdego hosta usługi licencji. Folder .movpkg przechowuje zawartość audio i wideo.

Pierwszy folder o nazwie kończącej się kreską, po której następuje liczba, zawiera zawartość wideo. Wartość liczbowa to szczytowa przepustowość odwzorowań wideo. Drugi folder o nazwie kończącej się kreską, po której następuje 0, zawiera zawartość audio. Trzeci folder o nazwie Data zawiera główną listę odtwarzania zawartości FPS. Na koniec boot.xml zawiera pełny opis zawartości folderu .movpkg .

Oto przykładowy plik boot.xml:

<?xml version="1.0" encoding="UTF-8"?>
<HLSMoviePackage xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://apple.com/IMG/Schemas/HLSMoviePackage" xsi:schemaLocation="http://apple.com/IMG/Schemas/HLSMoviePackage /System/Library/Schemas/HLSMoviePackage.xsd">
  <Version>1.0</Version>
  <HLSMoviePackageType>PersistedStore</HLSMoviePackageType>
  <Streams>
    <Stream ID="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" Path="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" NetworkURL="https://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>

Ponieważ usługa Media Services w wersji 3 umożliwia zasobowi posiadanie wielu StreamingLocator wystąpień, można mieć następujące możliwości:

• Jedno ContentKeyPolicy wystąpienie z license_type = "persistent"ContentKeyPolicyRestriction oświadczeniem w systemie "persistent"i jego StreamingLocator wystąpieniem.
• Inne ContentKeyPolicy wystąpienie z license_type="nonpersistent"ContentKeyPolicyRestriction oświadczeniem ""nonpersistent, a jego StreamingLocator wystąpieniem.
• Dwa StreamingLocator wystąpienia, które mają różne ContentKey wartości.

W zależności od logiki biznesowej niestandardowej usługi STS różne oświadczenia są wystawiane w tokenie JWT. Przy użyciu tokenu można uzyskać tylko odpowiednią licencję i można odtworzyć tylko odpowiedni adres URL.

Omówienie architektury DRM widevine firmy Google definiuje trzy poziomy zabezpieczeń. Jednak dokumentacja usługi Azure Media Services w szablonie licencji Widevine zawiera pięć poziomów zabezpieczeń (wymagania dotyczące niezawodności klienta na potrzeby odtwarzania).

Google Widevine definiuje oba zestawy poziomów zabezpieczeń. Różnica dotyczy poziomu użycia: architektury lub interfejsu API. Pięć poziomów zabezpieczeń jest używanych w interfejsie API Widevine. Usługa licencjonowania Widevine usługi Azure Media Services deserializuje content_key_specs obiekt, który zawiera security_levelobiekt i przekazuje go do globalnej usługi dostarczania Widevine. W poniższej tabeli przedstawiono mapowanie między dwoma zestawami poziomów zabezpieczeń.

Użyj usługi Azure Monitor, aby śledzić, co się dzieje z zasobami usługi Media Services. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Media Services. Instrukcje dotyczące przewodników są wyświetlane na końcu strony.

Użyj Azure Event Grid do monitorowania wydarzenia na żywo bez usługi sondowania. Zobacz Tworzenie i monitorowanie zdarzeń usługi Media Services za pomocą usługi Event Grid przy użyciu Azure Portal.

Usługa Media Services współpracuje z wieloma graczami. Zapoznaj się z listą zgodnych odtwarzaczy multimedialnych lub wypróbuj przykłady odtwarzacza innych firm.

Aby uzyskać informacje o usłudze Media Services i wysokiej dostępności, zobacz Wysoka dostępność za pomocą usług Media Services i Wideo na żądanie (VOD).

Utworzyliśmy kompleksowy przewodnik migracji z wersji 2 do wersji 3. Interesuje nas wiedza na temat twojego środowiska migracji i potrzeb, więc możesz bezpłatnie przekazać opinię za pośrednictwem problemu z usługą GitHub lub biletu pomocy technicznej.

Udokumentowaliśmy kody błędów w następujących odwołaniach: Kody błędów punktu końcowego przesyłania strumieniowego, kody błędów zdarzeń na żywo i kody błędówzadania. Jeśli nie możesz znaleźć tam odpowiedzi, utwórz bilet pomocy technicznej.

Poświadczenia konta można zresetować przy użyciu interfejsu wiersza polecenia platformy Azure.

Zobacz przewodnik po cenach usługi Media Services.

Zobacz Limity przydziału i limity usługi Media Services.

Klienci dołączają własne konta magazynu do kont usługi Azure Media Services. Wszystkie dane zasobów są przechowywane na tych skojarzonych kontach magazynu, a klient kontroluje lokalizację i typ replikacji tego magazynu.

Dodatkowe dane skojarzone z kontem usługi Media Services (w tym klucze szyfrowania zawartości, klucze weryfikacji tokenu, adresy URL JobInputHttp i inne metadane jednostki) są przechowywane w magazynie należącym do firmy Microsoft w obrębie regionu wybranego dla konta usługi Media Services.

Ze względu na wymagania dotyczące przechowywania danych w Brazylii Południowej i Azji Południowo-Wschodniej dodatkowe dane konta są przechowywane w sposób strefowo nadmiarowy i są zawarte w jednym regionie. W przypadku Azji Południowo-Wschodniej wszystkie dodatkowe dane konta są przechowywane w Singapurze. W przypadku Brazylii Południowej dane są przechowywane w Brazylii. W regionach innych niż Brazylia Południowa i Azja Południowo-Wschodnia dodatkowe dane konta mogą być również przechowywane w magazynie należącym do firmy Microsoft w sparowanym regionie.

Usługa Azure Media Services jest usługą regionalną i nie zapewnia wysokiej dostępności ani replikacji danych. Zachęcamy klientów, którzy potrzebują tych funkcji do utworzenia rozwiązania przy użyciu kont usługi Media Services w wielu regionach. Przykład pokazujący sposób tworzenia rozwiązania pod kątem wysokiej dostępności za pomocą wideo usługi Media Services na żądanie jest dostępny jako przewodnik.