Azure Media Services에 대한 일반적인 질문

Azure Media Services 사용 중지 가이드를 참조하세요.

목록은 다음과 같습니다.

• OpenAPI 사양(Swagger)
• Azure CLI
• .NET
• Java
• Python
• Node.JS
• Go

Media Services용 REST API를 자체 라이브러리 코드에 직접 래핑하지 않는 것이 좋습니다. 프로덕션 목적으로 올바르게 수행하려면 전체 Azure Resource Manager 다시 시도 논리를 구현하고 Resource Manager API에서 장기 실행 작업을 관리하는 방법을 이해해야 합니다. 다양한 언어(예: .NET, Java, TypeScript, Python 및 Ruby)용 클라이언트 SDK는 이를 자동으로 처리하여 다시 시도 논리 또는 실패한 API 호출 문제의 가능성을 줄입니다.

샘플 페이지를 참조하세요. 계정, 자산, 라이브 스트리밍, VOD 스트리밍, 콘텐츠 보호, 인코딩, 분석 및 플레이어 사용에 대한 샘플이 있습니다.

페이지 매김을 사용할 때는 항상 다음 링크를 사용하여 컬렉션을 열거하고, 특정 페이지 크기에 의존하지 않아야 합니다. 자세한 내용과 예는 항목 필터링, 순서 지정 및 페이징을 참조하세요.

Azure CLI를 사용하여 Media Services를 Azure Key Vault와 페어링하여 데이터를 암호화하는 방법에 대한 자세한 내용은 Key Vault 키를 사용하여 데이터를 Media Services 계정으로 암호화 자습서를 참조하세요.

알 수 없는 IP 주소의 요청을 차단하도록 스토리지 계정이 구성된 경우 Media Services에서 스토리지 계정에 액세스하도록 하려면 Media Services 관리 ID로 스토리지 액세스의 단계를 따릅니다.

구독 간 Media Services 계정 이동을 참조하세요.

Media Services 계정에 대한 Azure RBAC(역할 기반 액세스 제어)를 참조하세요.

Media Services는 다음과 같은 기본 제공 역할을 정의합니다.

• Media Services 계정 관리자
• Media Services 미디어 운영자
• Media Services 정책 관리자
• Media Services 스트리밍 엔드포인트 관리자
• Media Services 라이브 이벤트 관리자

이러한 역할은 Media Services 계정에 대한 Azure RBAC(역할 기반 액세스 제어)에 자세히 설명되어 있습니다.

이러한 역할을 사용하여 Media Services 계정에 세분화된 액세스 권한을 부여할 수 있습니다. Media Services 계정에 대한 모든 액세스를 허용하려면 "소유자" 또는 "기여자" 역할을 사용하면 됩니다. Media Services에는 세분화된 액세스 제어를 지원하지 않는 지원 중단 경로에 이전 API가 있습니다. 세분화된 액세스 제어가 필요한 고객은 포털을 사용하여 Media Services 계정을 만들 때 "클래식 API 사용"을 선택하거나 API를 사용하여 계정을 만드는 경우 2020-05-01 API 버전을 사용하면 안 됩니다.

다음 기본 제공 Azure Policy를 사용하여 이전 API를 지원하는 계정 만들기를 차단할 수 있습니다. 레거시 v2 API에 대한 액세스를 허용하는 Azure Media Services 계정을 차단해야 합니다 - Microsoft Azure

Media Services 자산은 업로드하는 각 동영상 파일에 사용되는 Azure Storage 계정 컨테이너입니다. 변환 및 기타 작업에 사용되는 고유 식별자가 있습니다. Azure Media Services v3의 자산을 참조하세요.

미디어 파일을 업로드하고 인코딩 또는 스트리밍과 같은 작업을 수행할 때마다 미디어 파일 및 관련 파일을 저장할 자산을 만듭니다. Azure Portal을 사용하는 경우 자산이 자동으로 만들어집니다. 포털을 사용하여 파일을 업로드하지 않는 경우 먼저 자산을 만들어야 합니다.

일반적인 인코딩 형식은 Media Services 표준 인코더에서 사용할 수 있습니다. 모든 형식 목록은 표준 인코더 형식 및 코덱을 참조하세요.

Azure CLI, REST 또는 SDK를 사용하여 Azure Portal에서 작업을 만들 수 있습니다. 원하는 언어에 대한 Media Services 샘플을 참조하세요.

예. 자동 생성된 비트 전송률 사다리로 인코딩을 참조하세요.

예. Media Services는 동영상에 대해 2단계 분석을 수행할 수 있습니다. 그런 다음 동영상 콘텐츠를 기반으로 최적의 적응 비트 전송률 집합, 해상도 및 인코딩 설정을 권장할 수 있습니다.

예. 미리 인코딩된 단일 비트 전송률 MP4 파일을 업로드하고 서버 매니페스트(.ism) 및 클라이언트 매니페스트(.ismc)를 생성하는 방법을 보여 주는 샘플 애플리케이션에 대한 자세한 내용과 링크는 패키징 및 배달에 대한 섹션에서 "다른 솔루션에서 미리 인코딩되거나 인코딩된 기존 MP4 파일을 스트리밍할 수 있나요?"라는 질문에 대한 답변을 참조하세요. 이 답변은 원본에 미치는 성능 영향도 설명합니다.

이는 권장되지 않습니다. 1~2분 미만의 매우 짧은 콘텐츠는 적응 비트 전송률 스트리밍에 적합하지 않습니다. 매우 짧은 형식의 파일을 스트리밍하려는 경우 단일 비트 전송률을 사용하여 쉽게 스트리밍할 수 있는 형식으로 콘텐츠를 미리 인코딩하는 것이 좋습니다.

대부분의 적응 비트 전송률 플레이어는 비디오의 여러 세그먼트를 버퍼링하는 시간뿐만 아니라 적응 비트 전송률을 따라 위아래로 "이동"하기 전에 네트워크 대역폭을 분석하는 데 시간이 필요하기 때문에 30초 미만의 콘텐츠에 대해 많은 비트 전송률을 제공해도 쓸모 없는 경우가 종종 있습니다. 플레이어가 네트워크 조건에 따라 재생할 올바른 비트 전송률에서 발견적 알고리즘을 잠글 때까지 파일 스트리밍이 완료됩니다.

또한 일부 플레이어는 기본적으로 최대 3개의 동영상 세그먼트를 버퍼링합니다. 각 세그먼트의 길이는 2~6초입니다. 매우 짧은 형식의 동영상의 경우 플레이어는 적응 비트 전송률 집합의 첫 번째 선택한 비트 전송률을 버퍼링하고 재생을 시작합니다. 따라서 HLS 또는 DASH 매니페스트를 생성해야 하는 경우 단일 비트 전송률 MP4 파일을 사용하고 자산에 업로드하는 것이 좋습니다. 이를 달성하는 방법에 대한 자세한 내용은 패키징 및 배달에 대한 섹션에서 "다른 솔루션에서 미리 인코딩되거나 인코딩된 기존 MP4 파일을 스트리밍할 수 있나요?"라는 질문에 대한 답변을 참조하세요.

이러한 프로토콜의 기능을 활용하려면 반드시 HLS 또는 DASH 형식으로 파일을 전달해야 해야 합니다. 단일 비트 전송률 스트림의 경우 Blob 스토리지의 점진적 다운로드 MP4보다 검색은 더 빠르고, DRM(디지털 권한 관리)이 더 많이 지원되지만, URL을 통해 다운로드하는 것이 더 많은 것을 제공할 수 있습니다. VTT 및 IMSC1에 대한 캡션 지원은 또 다른 이점입니다. 또한 추가 오디오 변환을 런타임에 바인딩하는 기능이 있거나 다른 언어 더빙을 사용하면 일부 상황에서 매우 유용할 수 있습니다.

Media Services 인코더를 사용하여 비디오 회전, 비디오 서브클립, 비디오 스티치, 썸네일 및 스프라이트 만들기 등의 작업을 수행하는 방법을 찾고 있다면 코드 샘플 페이지에 많은 코드 샘플이 있습니다. 사용 가능한 샘플 언어에는 Node.JS, Python, .NET 및 Java가 포함됩니다.

Media Services 라이브 이벤트는 RTMPS 프로토콜 또는 부드러운 스트리밍을 통해 라이브 비디오 피드를 수집하고 브로드캐스트하는 프로세스입니다. 자세한 내용은 Media Services의 라이브 이벤트 및 라이브 출력을 참조하세요.

첫 번째 단계는 온-프레미스 인코더를 선택하는 것입니다. Wirecast 및 OBS를 사용하여 라이브 이벤트를 만드는 예를 제공했습니다. Media Services 라이브 이벤트에 대한 개요로 시작하려면 라이브 이벤트 유형을 참조하세요.

Azure Media Service는 다양한 프로토콜로 동영상, 오디오 및 텍스트를 제공합니다. MPEG-DASH 또는 HLS/CMAF를 사용하여 라이브 스트림을 게시하면 비디오 및 오디오와 함께 서비스가 IMSC1.1 호환 TTML로 기록된 텍스트를 제공합니다. 자세한 내용은 라이브 대화 내용 기록을 참조하세요.

Azure Event Grid 이벤트를 구독하여 라이브 이벤트를 모니터링할 수 있습니다. 자세한 내용은 Event Grid 이벤트 스키마를 참조하세요. 다음 작업 중 하나를 수행할 수 있습니다.

• 스트림 수준의 Microsoft.Media.LiveEventEncoderDisconnected 이벤트를 구독하고 라이브 이벤트를 중지하고 삭제하기 위해 잠시 동안 재연결이 들어오는지 모니터링합니다.
• 트랙 수준의 하트 비트 이벤트를 구독합니다. 들어오는 비트 전송률이 모든 트랙에서 0으로 떨어지거나 마지막 타임스탬프가 더 이상 늘어나지 않으면 라이브 이벤트를 안전하게 종료할 수 있습니다. 하트비트 이벤트는 모든 트랙에 대해 20초마다 들어오므로 약간 많을 수 있습니다.

아니요, 라이브 이벤트를 중지하고 시작하면 동일한 스트리밍 URL을 쉽게 사용할 수 없습니다. 새 라이브 출력(및 자산)을 만들고 게시할 때마다 새 로케이터에 새 스트리밍 URL(GUID)이 사용됩니다. 그렇게 하면 스트리밍 엔드포인트와 CDN(콘텐츠 배달 네트워크)에서 캐시 충돌이 발생하지 않습니다. 스트리밍 로케이터에 대해 특정 GUID를 강제 적용한 다음 라이브 출력에 사용할 매니페스트 이름을 결정할 수 있으므로 스트리밍 URL을 미리 준비하고 알 수 있습니다.

내일 만들 라이브 출력에 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 또는 클라이언트 디바이스 캐시(예: 브라우저 캐시)의 다운스트림에 캐시되어 있기 때문에 여전히 문제가 있을 수 있습니다.

가장 일반적인 이유 중 하나는 재생하려고 하는 스트리밍 엔드포인트가 실행 중 상태가 아니기 때문입니다.

Media Services에서 스트리밍 엔드포인트는 일반적인 스트리밍 미디어 프로토콜(HLS 또는 DASH)을 사용하여 라이브 및 주문형 콘텐츠를 클라이언트 플레이어 앱에 직접 배달할 수 있는 원본 서비스와 동적(Just-In-Time) 패키징을 나타냅니다. 또한 스트리밍 엔드포인트는 업계 최고의 DRM 시스템에 동적(Just-In-Time) 암호화를 제공합니다. 자세한 내용은 Azure Media Services의 스트리밍 엔드포인트(원본)를 참조하세요.

비디오를 재생용 클라이언트에 사용할 수 있도록 하려면 스트리밍 로케이터를 만든 다음, 스트리밍 URL을 빌드합니다. 스트리밍 로케이터는 미디어 파일 사용 방법에 대한 규칙을 포함하는 스트리밍 정책을 적용하는 데도 사용됩니다.

스트리밍 URL을 빌드하려면 먼저 스트리밍 로케이터를 만듭니다. 그런 다음 스트리밍 엔드포인트의 호스트 이름과 스트리밍 로케이터의 경로를 연결합니다.

스트리밍 정책을 사용하면 스트리밍 로케이터에 대한 스트리밍 프로토콜 및 암호화 옵션을 정의할 수 있습니다. Media Services v3은 미리 정의된 일부 스트리밍 정책을 제공합니다. 자세한 내용은 스트리밍 정책을 참조하세요.

시작하는 데 사용할 수 있는 사전 정의된 정책 목록은 스트리밍 정책을 참조하세요.

경로 끝(URL의 /manifest 부분 뒤)에 (format=m3u8-cmaf)를 추가하여 스트리밍 원본 서버에 Apple iOS 네이티브 디바이스에서 사용할 수 있게 HLS 콘텐츠를 반환하도록 지정합니다. 자세한 내용은 콘텐츠 배달을 참조하세요.

예, Media Services 원본 서버(스트리밍 엔드포인트)는 MP4 파일을 HLS 또는 DASH 스트리밍 형식으로 동적 패키징하도록 지원합니다. 그러나 콘텐츠는 2~6초 범위의 짧은 GOP와 함께 폐쇄형 GOP 형식으로 인코딩되어야 합니다. 2초 GOP, 2초의 키 프레임 최대 및 최소 거리, 고정 비트 전송률 인코딩(CBR 모드) 설정을 권장합니다. AAC 오디오 형식과 함께 H.264 또는 HEVC 동영상 코덱을 통해 인코딩된 이 형식의 대부분의 콘텐츠가 지원될 수 있습니다. Dolby DD+와 같이 사전 인코딩된 추가 오디오 형식도 지원될 수 있습니다.

이러한 방식을 가능하게 하는 핵심은 자산을 만들고, Azure Blob Storage 클라이언트 SDK를 사용하여 미리 인코딩된 자산을 자산의 컨테이너에 업로드한 다음, 필요한 서버 매니페스트(.ism) 및 클라이언트 매니페스트 파일을 생성하는 데 있습니다. 자세한 내용은 기존 MP4 파일 스트리밍에서 .NET 샘플 프로젝트를 참조하세요.

Media Services의 기본 제공 인코더는 MP4 파일에 대한 액세스 시간을 개선하는 이진 인덱스(.mpi 파일)도 생성하기 때문에 이 액세스 방식을 사용할 때 성능에 영향이 있음을 기억합니다. 이러한 파일이 없으면 서버는 높은 로드에서 약간 더 많은 CPU를 사용할 수 있습니다. 자세한 내용은 HLS 또는 Dash를 사용하여 기존 단일 비트 전송률 MP4 파일 스트리밍을 참조하세요.

이 방법으로 크기 조정할 때 스트리밍 엔드포인트의 CPU 로드를 모니터링해야 합니다. Media Services 외부에서 사전 인코딩된 대규모 MP4 파일 라이브러리를 사용하여 프로덕션으로 이동할 계획이라면 지원 티켓을 제출하여 아키텍처를 검토하고 사전 인코딩된 MP4 콘텐츠의 원본 서버 성능을 개선하는 방법에 대해 문의합니다.

v2 API로 만들어진 스트리밍 로케이터는 v2 API가 꺼진 후에도 계속 작동합니다. 스트리밍 로케이터 데이터가 Media Services 백 엔드 데이터베이스에 만들어지고 나면 스트리밍을 위한 v2 REST API에 대한 종속성이 없습니다. 2024년 2월에 v2가 해제될 때 데이터베이스의 v2 관련 레코드는 제거되지 않습니다.

v2로 만든 자산과 로케이터의 몇 가지 속성은 새 v3 API를 사용하여 액세스하거나 업데이트할 수 없습니다. 예를 들어 v2에서 노출되는 자산 파일 API와 동등한 기능이 v3 API에는 없습니다. 널리 사용되는 기능이 아니며, 이전 로케이터를 계속 스트리밍하고 더 이상 필요하지 않을 때 삭제할 수 있기 때문에 대부분의 고객에게는 문제가 되지 않는 경우가 많습니다.

마이그레이션 후에는 스트리밍 로케이터나 자산을 수정하기 위한 v2 API 호출을 피해야 합니다.

동적 암호화는 컴퓨터를 떠날 때부터 스토리지, 처리 및 배달에 이르는 과정 내내 미디어를 보호합니다. Media Services를 사용하면 Advanced Encryption Standard(AES-128) 또는 Microsoft PlayReady, Google Widevine, Apple FairPlay 등 세 가지 주요 DRM 시스템 중 하나로 동적으로 암호화된 라이브 및 주문형 콘텐츠를 제공할 수 있습니다. 자세한 내용은 Media Services 동적 암호화로 콘텐츠 보호를 참조하세요.

고객들은 종종 AES 암호화 또는 DRM 시스템을 사용해야 할지 여부를 궁금해 합니다. 두 시스템의 주요 차이점은 AES 암호화를 사용하여 콘텐츠 키가 TLS를 통해 클라이언트로 전송된다는 것입니다. 키는 추가 암호화 없이 전송 중에 암호화됩니다("일반"). 그 결과 콘텐츠 암호 해독에 사용되는 키는 클라이언트 플레이어에 접근할 수 있으며, 일반 텍스트로 클라이언트에 대한 네트워크 추적에서 볼 수 있습니다. AES-128 암호화되지 않은 키 암호화는 뷰어가 신뢰할 만한 당사자(예: 직원이 볼 수 있도록 회사 내에 배포되는 회사 비디오 암호화)인 사용 사례에 적합합니다.

PlayReady, Widevine, FairPlay 등의 DRM 시스템은 AES-128 암호화되지 않은 키와 비교했을 때 콘텐츠 암호 해독에 사용되는 키에 대한 추가 수준의 암호화를 제공합니다. 콘텐츠 키는 TLS가 제공하는 전송 수준 암호화 외에도 DRM 런타임으로 보호되는 키로 암호화됩니다. 암호 해독은 악의적인 사용자가 공격하기에 좀 더 어려운 운영 체제 수준의 보안 환경에서 처리됩니다. DRM은 뷰어가 신뢰할 만한 당사자가 아니고 가장 높은 수준의 보안이 필요한 경우에 권장됩니다.

Azure AD(Azure Active Directory)와 같은 특정 토큰 공급자를 사용할 필요가 없습니다. 비대칭 키 암호화를 사용하여 고유한 JWT 공급자(보안 토큰 서비스 또는 STS)를 만들 수 있습니다. 사용자 지정 STS에서 자체 비즈니스 논리에 따라 클레임을 추가할 수 있습니다.

발급자, 대상 그룹 및 클레임이 모두 JWT의 내용과 ContentKeyPolicyRestriction에서 사용되는 ContentKeyPolicy 값 사이에서 정확하게 일치하는지 확인합니다.

자세한 내용은 Media Services 동적 암호화를 사용하여 콘텐츠 보호를 참조하세요.

프로덕션 환경의 경우 HTTPS 요청 시 JWT 토큰을 발급하는 STS(보안 토큰 서비스, 즉 웹 서비스)가 있어야 합니다. Program.cs에 정의된 GetTokenAsync 메서드에 있는 코드를 테스트에 사용할 수 있습니다.

사용자가 인증되면 플레이어에서 STS에 토큰을 요청하고 토큰의 값으로 할당합니다. Azure Media Player API를 사용할 수 있습니다.

대칭 키 또는 비대칭 키를 사용하여 STS를 실행하는 예제는 JWT 도구를 참조하세요. 이러한 JWT 토큰을 사용하는 Azure Media Player 기반 플레이어의 예는 Azure 미디어 테스트 도구를 참조하세요. (토큰 입력을 보려면 player_settings 링크를 확장합니다.)

올바른 방법은 STS(보안 토큰 서비스)를 활용하는 것입니다. STS에서 사용자 프로필에 따라 서로 다른 클레임(예: "프리미엄 사용자", "기본 사용자" 또는 "평가판 사용자")을 추가합니다. JWT에서 서로 다른 클레임을 사용하면 사용자가 각각의 콘텐츠를 볼 수 있습니다. 다른 콘텐츠 또는 자산의 경우는 ContentKeyPolicyRestriction이 해당 RequiredClaims 값을 갖습니다.

이 샘플과 같이 Azure Media Services API를 사용하여 라이선스/키 배달을 구성하고 자산을 암호화합니다.

이 동작은 의도적으로 샘플 앱의 것입니다. 오프라인 모드 중에 대체 오디오 트랙(HLS의 경우)이 있으면 iOS 10과 iOS 11 모두 대체 오디오 트랙으로 기본 설정됩니다. FPS 오프라인 모드에 대해 이 동작을 보정하려면 스트림에서 대체 오디오 트랙을 제거합니다. Media Services에서 이를 실행하기 위해 동적 매니페스트 필터 audio-only=false를 추가합니다. 즉, HLS URL은 .ism/manifest(format=m3u8-aapl,audio-only=false) 로 끝납니다.

CDN(콘텐츠 배달 네트워크)에 대한 캐시 키 디자인에 따라 콘텐츠가 캐시될 수 있습니다. 캐시를 제거합니다.

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>

Media Services v3에서는 자산에 여러 StreamingLocator 인스턴스를 포함할 수 있기 때문에 다음을 가질 수 있습니다.

• license_type = "persistent", "persistent"에 클레임이 있는 ContentKeyPolicyRestriction, 해당 StreamingLocator 인스턴스를 가진 한 개의 ContentKeyPolicy 인스턴스.
• license_type="nonpersistent", "nonpersistent에 클레임이 있는 ContentKeyPolicyRestriction, 해당 StreamingLocator 인스턴스를 가진 또 다른 ContentKeyPolicy 인스턴스.
• 서로 다른 StreamingLocator 값을 가진 두 개의 ContentKey 인스턴스.

사용자 지정 STS의 비즈니스 논리에 따라 JWT 토큰에서 다른 클레임이 발급됩니다. 이 토큰을 사용하여 해당 라이선스만 가져올 수 있고 해당 URL만 재생할 수 있습니다.

Google의 Widevine DRM 아키텍처 개요에서는 3가지 보안 수준을 정의하고 있습니다. 그러나 Widevine 라이선스 템플릿에 대한 Azure Media Services 설명서는 5가지 보안 수준(재생을 위한 클라이언트 견고성 요구 사항)을 간략하게 설명합니다.

Google Widevine은 두 가지 보안 수준 집합을 모두 정의합니다. 차이점은 사용 수준이 아키텍처인지 API인지입니다. 5가지 보안 수준은 Widevine API에서 사용됩니다. Azure Media Services Widevine 라이선스 서비스는 security_level이 포함된 content_key_specs 개체를 역직렬화하여 Widevine 전역 배달 서비스로 전달합니다. 다음 표에서는 두 보안 수준 집합 간의 매핑을 보여줍니다.

Azure Monitor를 사용하여 Media Services 리소스에서 발생하는 작업을 추적합니다. 자세한 내용은 Media Services 모니터링을 참조하세요. 가이드 방법은 페이지 끝에 나열됩니다.

Azure Event Grid를 사용하여 폴링 서비스 없이 라이브 이벤트를 모니터링합니다. Azure Portal 사용하여 Event Grid를 사용하여 Media Services 이벤트 만들기 및 모니터링을 참조하세요.

Media Services는 많은 플레이어와 함께 작동합니다. 호환되는 미디어 플레이어 목록을 참조하거나 타사 플레이어 샘플을 사용해 보세요.

Media Services 및 고가용성에 대한 자세한 내용은 Media Services 및 VOD(주문형 동영상)의 고가용성을 참조하세요.

v2에서 v3으로의 마이그레이션을 위한 종합 가이드를 만들었습니다. 사용자의 마이그레이션 환경 및 요구 사항을 파악하는 데 관심이 있으므로 GitHub 문제 또는 지원 티켓을 통해 자유롭게 피드백을 제공해 주세요.

다음 참조: 스트리밍 엔드포인트 오류 코드, 라이브 이벤트 오류 코드, 작업 오류 코드에서 오류 코드를 문서화했습니다. 여기에서 답변을 찾을 수 없는 경우 지원 티켓을 만드세요.

Azure CLI를 사용하여 계정 자격 증명을 다시 설정할 수 있습니다.

Media Services 가격 책정 가이드를 참조하세요.

Media Services 할당량 및 제한을 참조하세요.

고객은 Azure Media Services 계정에 자신의 스토리지 계정을 연결합니다. 모든 자산 데이터는 이렇게 연결된 스토리지 계정에 저장되고 고객은 이 스토리지의 위치 및 복제 유형을 제어합니다.

Media Services 계정과 연결된 추가 데이터(콘텐츠 암호화 키, 토큰 확인 키, JobInputHttp URL 및 기타 엔터티 메타데이터)는 Media Services 계정에 대해 선택된 지역 내에서 Microsoft 소유의 스토리지에 저장됩니다.

브라질 남부 및 동남 아시아의 데이터 보존 요구 사항으로 인해 추가 계정 데이터는 영역 중복 방식으로 저장되며 단일 지역에 포함됩니다. 동남 아시아의 경우 모든 추가 계정 데이터는 싱가포르에 저장됩니다. 브라질 남부의 경우 데이터가 브라질에 저장됩니다. 브라질 남부 및 동남 아시아 이외의 지역에서는 추가 계정 데이터가 쌍을 이루는 지역의 Microsoft 소유 스토리지에 저장될 수도 있습니다.

Azure Media Services는 지역 서비스이며 고가용성 또는 데이터 복제를 제공하지 않습니다. 이러한 기능이 필요한 고객은 여러 지역에서 Media Services 계정을 사용하여 솔루션을 빌드할 것을 권장합니다. Media Services VOD로 고가용성 솔루션을 빌드하는 방법을 보여 주는 샘플이 가이드로 제공됩니다.