Azure 媒體服務的相關常見問題

請參閱 Azure 媒體服務淘汰指南

清單如下：

• OpenAPI 規格 (Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.js
• Go

我們不建議您嘗試將媒體服務的 REST API 直接包裝到您自己的程式碼程式庫中。 適當地這麼做可以達成生產目的，但您必須實作完整的 Azure Resource Manager 重試邏輯，並瞭解如何在 Resource Manager API 中管理長時間執行的作業。 適用於各種語言的用戶端 SDK - 例如 .NET、JAVA、TypeScript、Python 和 Ruby - 可以自動處理這些程序，以減少重試邏輯或失敗 API 呼叫發生問題的機率。

請參閱範例頁面。 有 帳戶、 資產、 即時串流、 VOD 串流、 內容保護、 編碼、 分析和使用 播放機的範例。

使用分頁時，您應一律使用下一頁連結來列舉集合，而不應依存於特定頁面大小。 如需詳細資訊和範例，請參閱篩選、排序和分頁實體。

如需使用 Azure CLI 將媒體服務與 Azure Key Vault 配對以加密資料的相關資訊，請參閱使用 Key Vault 金鑰將資料加密到媒體服務帳戶教學課程。

當儲存體帳戶設定為封鎖來自未知 IP 位址的要求時，若您想要使用媒體服務存取儲存體帳戶，請遵循使用媒體服務受控識別存取儲存體中的步驟。

請參閱在訂用帳戶之間移動媒體服務帳戶。

請參閱媒體服務帳戶的 Azure 角色型存取控制 (Azure RBAC)。

媒體服務會定義下列內建角色：

• Azure 媒體服務帳戶管理員
• 媒體服務媒體運算子
• 媒體服務原則系統管理員
• 媒體服務串流端點管理員
• 媒體服務即時活動系統管理員

這些角色詳述于 媒體服務帳戶的 Azure 角色型存取控制 (Azure RBAC) 。

這些角色可用來提供媒體服務帳戶的細微存取權。 若要允許所有媒體服務帳戶的存取權，可以使用「擁有者」或「參與者」角色。 媒體服務在淘汰路徑上有較舊的 API，不支援更精細的存取控制。 使用入口網站建立媒體服務帳戶時，需要精細存取控制的客戶不應該選取 [啟用傳統 API] (，或使用 2020-05-01 API 版本來建立帳戶) 。

下列內建Azure 原則可用來封鎖建立支援舊版 API 的帳戶：應封鎖允許存取舊版 v2 API 的 Azure 媒體服務帳戶 - Microsoft Azure

媒體服務資產是 Azure 儲存體帳戶容器，用於您上傳的每個影片檔案。 它具有與轉換和其他作業搭配使用的唯一識別碼。 請參閱 Azure 媒體服務 v3 中的資產。

每次您想要上傳媒體檔案並使用它執行動作時，例如編碼或串流，您都會建立一個資產來儲存媒體檔案和相關聯的檔案。 如果您使用 Azure 入口網站，則系統會自動為您建立資產。 如果您不是使用入口網站上傳檔案，則必須先建立資產。

媒體服務標準編碼器提供常見的編碼格式。 如需所有格式的清單，請參閱標準編碼器格式和轉碼器。

您可以使用 Azure CLI、REST 或任何 SDK，在 Azure 入口網站中建立作業。 如需您偏好的語言，請參閱媒體服務範例。

是。 請參閱使用自動產生的位元速率階梯進行編碼。

是。 媒體服務可以對影片執行兩階段分析； 然後，根據影片的內容，建議最佳的自適性位元速率集、解析度和編碼設定。

是。 如需範例應用程式的詳細資料和連結，該範例示範如何上傳預先編碼的單一位元速率 MP4 檔案並產生伺服器資訊清單 (.ism) 和用戶端資訊清單 (.ismc)，請參閱封裝和交付相關章節中問題「我可以串流處理在另一個解決方案中預先編碼或編碼的現有 MP4 檔案嗎？」的答案。 該答案也會描述對原點造成的效能影響。

不建議這樣做。 持續時間不到一或兩分鐘的簡短內容不適合自適性位元速率串流。 如果您想要串流處理簡短格式的檔案，建議您將內容預先編碼為使用單一位元速率可以輕鬆串流處理的格式。

由於大部分自適性位元速率播放程式都需要時間緩衝多個影片區段，也需要時間在上移或下移自適性位元速率階梯之前分析網路頻寬，因此通常無法為長度不到 30 秒的內容提供大量位元速率。 當播放程式根據網路條件將啟發學習演算法鎖定在正確的位元速率進行播放時，檔案就會進行串流處理。

此外，有些播放程式預設為最多緩衝三段影片。 每個區段的長度可以是兩到六秒。 對於非常簡短格式的影片，播放程式可能會先緩衝再開始播放自適性位元速率集的第一個選取位元速率。 基於這個理由，建議您使用單一位元速率 MP4 檔案，並在您需要產生 HLS 或 DASH 資訊清單時將檔案上傳至資產。 如需如何達成此目的的詳細資料，請參閱封裝和交付相關章節中問題「我可以串流處理在另一個解決方案中預先編碼或編碼的現有 MP4 檔案嗎？」的答案。

只有在您想要因這些通訊協定的功能而受益時，才需要以 HLS 或 DASH 格式傳遞檔案。 對於單一位元速率串流，它們仍然可以提供許多功能，例如更快速的搜尋、數位版權管理 (DRM) 支援，以及增加透過 URL (下載的困難！) 比 Blob 儲存體中的漸進式下載 MP4 還要困難。) 。 VTT 和 IMSC1 的標題支援是另一個好處。 此外，能夠在晚期繫結其他音訊轉譯或以替代語言配音，也讓此方法在某些情況下成為重要的選項。

如果您要尋找使用媒體服務編碼器執行動作的方式，例如旋轉視訊、子剪輯視訊、編結影片、建立縮圖和 Sprite，我們在 [程式碼範例] 頁面上有一組程式 代碼範例 。 可用的範例語言包括 Node.JS、Python、.NET 和 JAVA。

媒體服務即時活動是擷取即時影片摘要，並透過 RTMPS 通訊協定或 Smooth Streaming 進行廣播的程序。 如需詳細資訊，請參閱媒體服務中的即時活動和即時輸出。

第一個步驟是選擇內部部署編碼器。 我們已提供使用 Wirecast 和 OBS 建立即時活動的範例。 如果您想要從媒體服務即時活動的概觀開始，請參閱即時活動類型。

Azure 媒體服務可以透過不同通訊協定傳遞視訊、音訊和文字。 當您使用 MPEG-DASH 或 HLS/CMAF 發佈即時串流時，服務會連同視訊和音訊，在與 IMSC1.1 相容的 TTML 中傳遞轉譯的文字。 如需詳細資訊，請參閱即時轉譯。

您可以訂閱 Azure 事件方格事件來監視即時活動。 如需詳細資訊，請參閱事件方格事件結構描述。 您可以：

• 訂閱串流層級 Microsoft.Media.LiveEventEncoderDisconnected 事件，並監視一段時間內沒有重新連線的情況發生，以停止和刪除即時活動。
• 訂閱追蹤層級活動訊號事件。 如果所有播放軌的傳入位元速率均下降至 0，或最後一個時間戳記不再增加，您就可以放心地關閉即時活動。 每個播放軌的活動訊號事件會每隔 20 秒出現一次，可能會顯得有點冗長。

否，如果您停止並啟動即時活動，就無法輕鬆使用相同的串流 URL。 每次您建立並發佈新的即時輸出 (和資產) 時，新的串流 URL (GUID) 將用於新的定位器。 如此一來，您可以確保串流端點和內容傳遞網路 (CDN) 不會發生任何快取衝突。 您可以事先準備 (並知道) 串流 URL，因為您可以強制串流定位器使用特定的 GUID，然後決定要用於即時輸出的資訊清單名稱。

假設您決定要將 GUID 1a7ed69e-a361-433d-8a56-29c61872744f 用於您明天要建立的即時輸出。 到了明天，您就要啟動即時活動並建立即時輸出。 您可以決定將 "conference1" 用於資訊清單，並強制定位器使用 GUID。

串流 URL 是可預測的，而且是 http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest。

您不能多次重複使用相同的即時輸出或資產。 請將即時輸出和資產的組合視為磁帶錄製。 將即時輸出錄製到資產之後，您就不能重複使用該資產進行另一個錄製。 如果用來再次錄製，則會發生 Blob 衝突或覆寫。 除非您打算完整清除儲存體帳戶中的 Blob，並完全清除 CDN，否則會發生問題。 因為片段已在下游的 CDN 或用戶端裝置快取中快取 (例如，瀏覽器快取)，所以可能還是會有問題。

其中一個最常見的原因，就是您嘗試從中進行播放的串流端點不是處於執行中狀態。

在媒體服務中，串流端點代表動態 (Just-In-Time) 封裝及原始服務，其可使用其中一種常見的串流媒體通訊協定 (HLS 或 DASH) 來為您提供即時且隨選的內容，並直接傳遞至用戶端播放應用程式。 此外，串流端點還提供動態 (Just-In-Time) 加密給領先業界的 DRM 系統。 如需詳細資訊，請參閱 Azure 媒體服務中的串流端點 (來源)。

若要讓影片可供用戶端播放，您必須建立串流定位器，然後建置串流 URL。 串流定位器也可用來套用串流原則，其中包含媒體檔案取用方式的規則。

若要建置串流 URL，請先建立串流定位器。 接下來，您需要串連串流端點的主機名稱和串流定位器的路徑。

串流原則可讓您設定串流定位器的串流通訊協定和加密選項。 媒體服務 v3 提供一些預先定義的串流原則。 如需詳細資訊，請參閱串流原則。

如需可用來開始使用的預先定義原則清單，請參閱串流原則。

請確定路徑尾端 (在 URL 的 /manifest 部分之後) 有 (format=m3u8-cmaf)，告知串流原始伺服器傳回 HLS 內容，以供 Apple iOS 原生裝置取用。 如需詳細資訊，請參閱傳遞內容。

是，媒體服務原始伺服器 (串流端點) 支援將 MP4 檔案動態封裝成 HLS 或 DASH 串流格式。 不過，內容必須以封閉式 GOP 格式編碼，且持續時間範圍為 2 到 6 秒的簡短 GOP。 我們建議使用下列設定：兩秒的 GOP、2 秒的主畫格最大和最小距離、常數位元速率編碼 (CBR 模式)。 支援此格式 (透過 H.264 或 HEVC 視訊轉碼器編碼) 的大部分內容，以及 AAC 音訊格式。 可能也支援預先編碼的其他音訊格式，例如 Dolby DD+。

使其發揮作用的關鍵是建立資產、使用 Azure Blob 儲存體用戶端 SDK 將預先編碼的資產上傳至資產的容器，然後產生必要的伺服器資訊清單 (.ism) 和用戶端資訊清單檔案。 如需詳細資訊，請參閱串流處理現有的 MP4 檔案中的 .NET 範例專案。

請記住，使用此方法時會影響效能，因為媒體服務中的內建編碼器也會產生二進位索引 (.mpi 檔案)，縮短 MP4 檔案的存取時間。 如果沒有這些檔案，伺服器可以在高負載時稍微使用多一點的 CPU。 如需詳細資訊，請參閱使用 HLS 或 Dash 串流現有的單一位元速率 MP4 檔案。

使用此方法擴大規模時，應監視串流端點的 CPU 負載。 如果您打算使用在媒體服務外部預先編碼的 MP4 檔案大型程式庫進行實際執行，請提交支援票證以檢閱您的結構，並詢問是否有方法可以改善預先編碼 MP4 內容的原始伺服器效能。

在 v2 API 關閉後，使用 v2 API 建立的串流定位器會繼續運作。 在媒體服務後端資料庫中建立串流定位器資料後，則無需依賴 v2 REST API 進行串流處理。 2024 年 2 月 v2 關閉時，我們不會從資料庫移除 v2 特定記錄。

您無法使用新的 v3 API 來存取或更新以 v2 建立的某些資產和定位器屬性。 例如：v2 所公開的資產檔案在 API v3 API 中沒有對等功能。 這通常不是大部分客戶的問題，因為該功能並非廣泛使用，且您仍可串流舊的定位器，不需要時再將其刪除。

移轉後，應避免進行任何 v2 API 呼叫來修改串流定位器或資產。

動態加密可保護媒體從離開電腦到進行儲存、處理和傳遞時的安全。 媒體服務可讓您傳遞利用進階加密標準 (AES-128) 或下列三個主要 DRM 系統中任一個動態加密的即時與隨選內容：Microsoft PlayReady、Google Widevine 和 Apple FairPlay。 如需詳細資訊，請參閱使用媒體服務動態加密保護您的內容。

客戶通常不知道他們應該使用 AES 加密，還是 DRM 系統。 這兩個系統的主要差異是，使用 AES 加密時，系統會透過 TLS 將內容金鑰傳輸至用戶端。 金鑰會在傳輸過程中加密，無需任何額外的加密 (純文字)。 所以，用戶端播放程式可以存取用來解密內容的金鑰，且可以在用戶端的網路追蹤中以純文字形式檢視該金鑰。 AES-128 未加密金鑰加密適用於檢視者為受信任合作對象的使用案例 (例如，將在公司內部散發的公司影片加密，以供員工檢視)。

與 AES-128 未加密金鑰相比，PlayReady、Widevine 和 FairPlay 等 DRM 系統會在用來解密內容的金鑰上提供額外的加密層級。 除了 TLS 提供的任何傳輸層級加密之外，內容金鑰也會加密為 DRM 執行階段所保護的金鑰。 解密會在安全環境中，惡意使用者更難攻擊的作業系統層級上進行處理。 針對檢視者可能不是受信任的合作對象，而且您需要最高層級安全性的使用案例，建議使用 DRM。

您不需要使用任何特定的權杖提供者，例如 Azure Active Directory (Azure AD)。 您可以使用非對稱金鑰加密，建立自己的 JWT 提供者 (所謂的 Security Token Service 或 STS)。 在您的自訂 STS 中，您可以根據商務邏輯來新增宣告。

請確定簽發者、適用對象和宣告完全符合 JWT 中的內容與 ContentKeyPolicy 中使用的 ContentKeyPolicyRestriction 值。

如需詳細資訊，請參閱使用媒體服務動態加密保護您的內容。

在實際執行環境中，您必須具備 Security Token Service (亦即，Web 服務)，才能根據 HTTPS 要求發出 JWT 權杖。 在測試時，您可以使用 Program.cs 中定義的 GetTokenAsync 方法所顯示的程式碼。

使用者經過驗證之後，播放程式向 STS 提出此類權杖的要求，並將它指派為權杖的值。 您可以使用 Azure 媒體播放器 API。

如需使用對稱金鑰或非對稱金鑰執行 STS 的範例，請參閱 JWT 工具。 如需使用這類 JWT 權杖並以 Azure 媒體播放器為基礎的播放程式範例，請參閱 Azure 媒體測試工具。 (展開 player_settings 連結以查看權杖輸入。)

正確的方法是使用 Secure Token Service。 在 STS 中，根據使用者設定檔，新增不同的宣告 (例如「進階使用者」、「基本使用者」或「免費試用使用者」)。 在 JWT 中使用不同的宣告，使用者可以看見不同的內容。 對於不同的內容或資產，ContentKeyPolicyRestriction 將會有對應的 RequiredClaims 值。

使用 Azure 媒體服務 API 來設定授權/金鑰傳遞並將您的資產加密 (如這個範例所示)。

這個行為似乎是範例應用程式的設計使然。 當替代音訊播放軌在離線模式期間存在 (即 HLS 的情況)，iOS 10 和 iOS 11 便會預設為替代曲目。若要在 FPS 離線模式補償這個行為，請將替代音訊播放軌從串流中移除。 若要對媒體服務執行此操作，請新增動態資訊清單篩選條件 audio-only=false。 換言之，HLS URL 的結尾是 .ism/manifest(format=m3u8-aapl,audio-only=false)。

系統可能會根據內容傳遞網路的快取金鑰設計來快取內容。 所以，請清除快取。

iOS 裝置上所下載的檔案結構看起來如下列螢幕擷取畫面。 _keys 資料夾會儲存下載的 FPS 授權，每個授權服務主機會有一個儲存的檔案。 .movpkg 資料夾會儲存音訊和影片內容。

第一個資料夾名稱的結尾是一個破折號後面接著一個數字，此資料夾包含影片內容。 數值為影片轉譯的尖峰頻寬。 第二個資料夾名稱的結尾是一個破折號後面接著 0，此資料夾包含音訊內容。 第三個名為 Data 的資料夾包含 FPS 內容的主要播放清單。 最後，boot.xml 會提供 .movpkg 資料夾內容的完整描述。

以下是範例 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>

因為媒體服務 v3 允許資產有多個 StreamingLocator 執行個體，所以您可以擁有：

• 一個 ContentKeyPolicy 執行個體，使用 license_type = "persistent"、宣告 "persistent" 的 ContentKeyPolicyRestriction，以及其 StreamingLocator 執行個體。
• 另一個 ContentKeyPolicy 執行個體，使用 license_type="nonpersistent"、宣告 "nonpersistent 的 ContentKeyPolicyRestriction，以及其 StreamingLocator 執行個體。
• 使用不同 ContentKey 值的兩個 StreamingLocator 執行個體。

根據自訂 STS 的商務邏輯，JWT 權杖中會發出不同宣告。 使用權杖時，只能取得對應的授權，且只能播放對應的 URL。

Google 的 Widevine DRM 架構概觀 /(英文/) 定義三個安全性層級。 不過，有關 Widevine 授權範本的 Azure 媒體服務文件概述了五個安全性層級 (用戶端對於播放的穩健性需求)。

Google Widevine 定義了這兩組安全性層級。 不同之處在於使用層級：結構或 API。 Widevine API 中使用的是五個安全性層級。 Azure 媒體服務 Widevine 授權服務會將包含 security_level 的 content_key_specs 物件還原序列化，並傳遞至 Widevine 全域傳遞服務。 下表顯示兩組安全性層級之間的對應。

使用 Azure 監視器來追蹤媒體服務資源的情況。 如需詳細資訊，請參閱監視媒體服務。 如何在頁面結尾列出指南。

使用 Azure 事件方格來監視即時活動，而不需輪詢服務。 請參閱使用事件方格建立和監視媒體服務事件Azure 入口網站。

媒體服務可與許多播放程式搭配運作。 請參閱 相容的媒體播放機清單 ，或嘗試 協力廠商播放機範例。

如需媒體服務和高可用性的相關資訊，請參閱媒體服務和點播視訊 (VOD) 的高可用性。

我們已建立從 v2 移轉至 v3 的完整指南。 我們有興趣了解您的移轉體驗和需求，因此請隨時透過 GitHub 問題或支援票證提供意見反應。

我們已記載下列參考中的錯誤碼：串流端點錯誤碼、即時活動錯誤碼和作業錯誤碼。 如果您在其中找不到答案，請建立支援票證。

您可以使用 Azure CLI 重設帳戶認證。

請參閱媒體服務定價指南。

請參閱Azure 媒體服務配額和限制。

客戶會將自己的儲存體帳戶附加至其 Azure 媒體服務帳戶。 所有資產資料都儲存在這些相關聯的儲存體帳戶中，而客戶會控制此儲存體的位置和複寫類型。

與媒體服務帳戶相關聯的其他資料 (包括內容加密金鑰、權杖驗證金鑰、JobInputHttp URL 和其他實體中繼資料) 會儲存 Microsoft 擁有的儲存體中，該儲存體位於針對媒體服務帳戶所選取的區域。

由於巴西南部和東南亞的資料落地需求，其他帳戶資料會以區域備援的形式儲存，並存放在單一區域中。 在東南亞地區，所有其他帳戶資料都會儲存在新加坡。 在巴西南部，所有資料都會儲存在巴西。 在巴西南部和東南亞以外的區域，其他帳戶資料也可能儲存在配對區域中的 Microsoft 擁有儲存體中。

Azure 媒體服務是區域性服務，不提供高可用性或資料複寫。 我們鼓勵需要這些功能的客戶在多個區域中使用媒體服務帳戶來建置解決方案。 您可以使用我們所提供的範例作為指南，該範例示範如何使用媒體服務點播視訊建置高可用性的解決方案。