# AWS 및 OBS 라이브 스트리밍 설정 AWS 라이브 워크플로를 만들고, OBS를 구성하고, DRM 재생을 테스트하고, 이벤트 후 리소스를 중지하세요. 암호화된 동영상과 DRM 라이선스는 서로 다른 경로로 전달됩니다 CDN은 암호화된 동영상을 전달합니다. 백엔드가 접근 권한을 확인하고, DRM 라이선스 서비스가 호환 기기에서의 복호화를 승인합니다. - 01**스토리지 / CDN** 암호화된 미디어를 플레이어에 전달합니다. - 02**고객 백엔드** 시청 권한을 확인하고 DRM-X에 재생 승인을 요청합니다. - 03**DRM-X** 재생 승인 정보를 검증하고 DRM 라이선스 요청을 처리합니다. - 04**플레이어 + 기기** 기기의 DRM 시스템으로 라이선스를 받아 암호화된 미디어를 재생합니다. 귀하의 백엔드가 접근을 결정합니다. DRM-X는 서명 된 정책을 시행합니다. 암호화 된 미디어 및 DRM 라이센스는 별도의 배송 경로를 따릅니다. Trial 및 유료 계정은 라이브 DRM 채널을 생성할 수 있습니다. 이 워크플로에는 S3 저장소 연결이 필요하지 않습니다. AWS 미디어 인코딩, 패키징, 전달 및 보유 리소스에 대해 별도로 요금이 부과됩니다. 전달 경로는 OBS → AWS Elemental MediaLive → MediaPackage v2 → CloudFront → DRM-X 플레이어입니다. DRM-X는 SPEKE을 통해 암호화 키를 제공하고 DRM License Token로 각 뷰어에 권한을 부여합니다. ## DRM-X에서 라이브 이벤트 만들기[#](#create-a-live-event) - 고객 콘솔에 로그인하고 이벤트를 소유할 조직과 환경을 선택합니다. - **Live events → New Live Channel**를 엽니다. 제목을 입력하세요. 새 계정의 경우 **Create new live content**를 선택하고 고유한 Content ID을 입력하세요. 또는 기존 라이브 콘텐츠를 선택하세요. - AWS 리전, 키 순환 간격, DVR 보관 시간을 선택하세요. MediaLive, MediaPackage, SPEKE 브리지는 같은 AWS 리전을 사용합니다. 시작 설정 예시는 키 순환 600초, DVR 미디어 보관 7200초입니다. - 채널을 생성합니다. 통합 ID 및 별도의 DASH 및 HLS 리소스 ID와 함께 일회성 원본 비밀번호를 안전하게 저장하세요. 플레이어, 스크린샷, 지원 티켓 또는 공개 저장소에 비밀을 넣지 마십시오. DRM-X 채널은 콘텐츠 및 인증 구성입니다. DRM-X Live Run 시작과 AWS 인코더 시작은 별도의 작업입니다. ## AWS 계정 구성[#](#configure-aws) - 결제가 활성화된 AWS 계정과 CloudFormation, MediaLive, MediaPackage v2, API Gateway, IAM 서비스 역할 및 CloudFront을 관리할 수 있는 공인 운영자를 사용하세요. 리허설 전에 지역별 할당량과 현재 가격을 확인하세요. - 콘솔에서 [DRM-X AWS CloudFormation 템플릿](https://6.drm-x.com/downloads/drmx-live-aws.yaml)을 다운로드하세요. `CreateMediaResources=false`, DRM-X 통합/리소스 ID 및 원본 암호를 사용하여 스택을 생성합니다. 템플릿은 범위가 지정된 서비스 역할과 IAM 승인 SPEKE 브리지를 생성합니다. - DRM-X **Configure AWS**에 AWS 계정 ID과 스택의 정확한 `SpekeRoleArn`을 입력하세요. DRM-X Live Run를 시작하면 인증된 키 요청이 성공할 수 있습니다. - `CreateMediaResources=true`로 동일한 스택을 업데이트합니다. 기존 비밀 및 기타 매개변수를 유지합니다. 스택이 완료될 때까지 기다립니다. - 스택 출력 `DashOriginUrl`, `HlsOriginUrl`, `DashCloudFrontUrl` 및 `HlsCloudFrontUrl`를 일치하는 DRM-X 필드에 복사합니다. 시청자는 CloudFront URL을 사용합니다. Origin는 CloudFront로 제한됩니다. - MediaLive에 **RTMP push** 입력을 만드세요. 입력 보안 규칙 `/32`를 사용하여 송출자의 현재 공인 IP만 허용합니다. ISP가 IP를 변경하면 이 규칙을 업데이트해야 합니다. - 스택의 `MediaLiveRoleArn`로 MediaLive 채널을 생성하고 입력을 연결한 다음 스택의 채널 그룹과 채널 이름을 사용하여 **MediaPackage v2 CMAF** 출력 그룹을 추가합니다. 단일 파이프라인은 제한된 테스트에 적합합니다. 생산 이벤트에는 적절한 중복 설계가 필요합니다. 템플릿은 Widevine 및 PlayReady에 대해 DASH-CENC를 생성하고 FairPlay에 대해 HLS-CBCS를 생성합니다. `PRESET_AUDIO_1` 및 `PRESET_VIDEO_3` 계약은 오디오, SD, HD 및 UHD 키를 분리합니다. `PRESET_VIDEO_2`을 사용하는 기존 설치에서는 별도의 정책으로 UHD를 추가하기 전에 암호화 계약 업데이트를 검토해야 합니다. [AWS 암호화 사전 설정](https://docs.aws.amazon.com/mediapackage/latest/userguide/drm-content-speke-v2-presets.html)을 참조하세요. ## 4K용 OBS Studio 구성[#](#configure-obs-for-4k) - OBS 프로필 및 장면 컬렉션을 복제하세요. 알아보기 쉬운 라이브 이벤트 이름을 지정하세요. - 원하는 비디오 또는 캡처 소스를 추가합니다. 실제로 3840×2160인지 확인하고 캔버스에 맞추고 오디오를 확인합니다. 리허설 파일의 경우 루프를 활성화합니다. 사용하지 않는 창 또는 데스크탑 캡처를 숨깁니다. - **Settings → Video**에서 캔버스와 출력 해상도를 모두 `3840x2160`로 설정하고 이 예에서는 `30`fps를 선택합니다. - **Output → Advanced → Streaming**에서 지원되는 H.264 하드웨어 인코더(예: NVIDIA NVENC H.264)를 선택합니다. CBR `18000 Kbps`, `2 s` 키프레임 간격, high profile을 사용하고 출력 크기 조정을 비활성화합니다. NVENC, P5 및 고품질이 출발점입니다. 리허설 중에 인코딩 부하를 확인하세요. - AAC 오디오 및 48kHz 스테레오를 사용합니다. 원치 않는 마이크 및 데스크톱 오디오 소스를 비활성화합니다. - **Stream**에서 Custom을 선택하세요. MediaLive RTMP 입력 URL을 서버/애플리케이션 URL과 마지막 스트림 이름 부분으로 나눕니다. 마지막 부분을 Stream Key에 입력하고 값은 마스킹된 상태로 유지하세요. 결합된 비디오 및 오디오 비트 전송률보다 높은 헤드룸이 있는 안정적인 업로드 연결을 사용합니다. OBS에서 지속적인 네트워크 또는 인코딩 중단이 보고되면 시청자에게 이벤트를 공개하기 전에 이를 수정하세요. [OBS 하드웨어 인코딩 지침](https://obsproject.com/kb/hardware-encoding)을 참조하세요. ## 적응형 출력 구성[#](#configure-4k-adaptive-outputs) 위의 OBS 설정에는 최대 20Mbps의 AVC/UHD MediaLive 입력 사양을 사용하세요. 닫힌 2초 GOP와 정렬된 6초 CMAF 세그먼트를 사용하여 30fps에서 다음 H.264 출력을 생성합니다. AAC 오디오를 자체 rendition으로 유지하세요. | 해상도 | 예시 비디오 비트레이트 | 키 그룹 | | --- | --- | --- | | 3840×2160 | 16 Mbps | UHD | | 1920×1080 | 5 Mbps | HD | | 1280×720 | 2.5 Mbps | HD | | 854×480 | 1.2 Mbps | SD | | 640×360 | 0.7 Mbps | SD | 이는 리허설 설정이며 품질 보증이 아닙니다. 4K 채널은 소형 디스플레이, 제한된 네트워크 및 DRM 보안 수준으로 인해 품질이 제한되는 장치에 대해 여전히 더 낮은 rendition이 필요합니다. 다른 인코더를 선택하는 경우 현재 [MediaLive 코덱 및 해상도 지원](https://docs.aws.amazon.com/medialive/latest/ug/eml-limitations-and-rules.html)을 확인하세요. ## 이전 이벤트 이후 채널 재사용[#](#reuse-channel-history) 인코더가 실행 중이라고 해서 시청자에게 최신 미디어가 전달되는 것은 아닙니다. MediaPackage의 manifest-last-updated 헤더와 제공되는 해상도를 확인하세요. 인코더나 rendition을 변경한 뒤에도 재사용한 채널이 이전 세그먼트를 제공한다면 [AWS 채널 기록 초기화 절차](https://docs.aws.amazon.com/mediapackage/latest/userguide/channel-reset.html)를 따르세요. - 이전 DVR 콘텐츠를 영구적으로 삭제할 수 있는지 확인하세요. 재설정은 롤백 작업이 아닙니다. - OBS와 MediaLive 채널을 중지하고 MediaLive가 Idle 상태가 될 때까지 기다리세요. - MediaPackage에서는 특정 테스트 채널의 기록을 재설정합니다. 재설정이 완료된 후 30초 이상 기다립니다. - MediaLive를 시작하고 Running을 기다린 다음 OBS를 시작합니다. 최신 DASH/HLS 미디어, SPEKE 교환, 기기 재생을 다시 확인하세요. ## PHP, Android, iOS에 이벤트를 추가합니다.[#](#test-web-android-ios) 모든 예시에서 동일한 라이브 Content ID 및 환경을 사용합니다. Site Key 및 Access Key를 PHP 서버에 유지하세요. 주최된 샘플 이벤트는 `aws-live-test-20260902`이며 제목은 **4K Live DRM Test**입니다. 리허설이 진행되는 동안에만 사용할 수 있습니다. PHP에서 `id`, `title` 및 `type: live`를 사용하여 신뢰할 수 있는 재생목록 항목을 추가합니다. 샘플의 세션 자격을 새로 고치려면 다시 로그인하세요. 백엔드는 등록된 라이브 매니페스트를 확인하고 카탈로그와 일치하지 않는 클라이언트 제공 유형을 거부합니다. ``` 'playlist' => [ ['id' => 'your-live-content-id', 'title' => 'My live event', 'type' => 'live'], ], ``` Android에서 `DrmXPlaylistItem("your-live-content-id", "My live event", "live")`를 추가하고 재생 준비 시 콘텐츠 유형을 전달합니다. Apple 샘플에서는 `DrmXPlaylistItem(contentId: "your-live-content-id", title: "My live event", contentType: .live)`를 사용합니다. 라이브 항목은 스트리밍용이므로 오프라인 다운로드 대기열에 들어갈 수 없습니다. ## 시작, 확인 및 중지[#](#start-and-stop-the-broadcast) - DRM-X Live Run을 시작한 뒤 AWS MediaLive 채널을 시작하세요. MediaLive가 Running 상태를 표시할 때까지 기다립니다. - OBS에서 스트리밍을 시작하세요. 비트 전송률, 프레임 손실, 오디오 및 인코더 로드를 확인하세요. - 진행 중인 DASH/HLS 매니페스트에 예상되는 표현과 DRM 신호가 포함되어 있는지 확인하세요. 브라우저, Android Widevine 및 iPhone FairPlay에서 디코딩된 사진과 오디오를 확인하세요. 하나 이상의 키 순환에 걸쳐 플레이어를 연결된 상태로 두고 나중에 새로운 뷰어를 테스트하세요. - 테스트를 마치면 OBS 송출, MediaLive 채널, DRM-X Live Run을 모두 중지하세요. MediaLive가 Idle 상태로 돌아왔는지 확인합니다. OBS만 중지하면 AWS 인코더 요금은 계속 발생합니다. 유지된 입력, 패키징/저장소, 요청, 전송 비용을 각각 확인하세요. [MediaLive 요금 안내](https://aws.amazon.com/medialive/pricing/)와 AWS 결제 콘솔을 확인하세요. ## 검증된 리허설: 2026년 9월 17일[#](#verified-rehearsal) 채널은 암호화된 3840×2160 비디오와 낮은 해상도의 적응형 rendition을 제공했습니다. 실제 iPhone은 4K를 디코딩하고 600초 키 순환 간격의 경계를 지나는 6분간의 재생 테스트를 통과했습니다. Samsung Android 기기는 보고된 표시 상한인 1080p에서 10분간 재생했습니다. 두 기기 모두 키 순환 후 새 접속 테스트를 통과했습니다. 결과는 테스트한 기기, 코덱, 정책에 한정됩니다. 캐시되지 않은 라이브 매니페스트에는 Android SDK **1.0.0-preview.13** 이상을 사용하세요. 다운로드한 동영상을 보존하려면 기존 [Android 평가 앱](https://docs.drm-x.com/downloads/android/1.0.0-preview.13/drmx-android-player-1.0.0-preview.13.apk)을 업그레이드하세요. 업데이트된 Apple 샘플은 FairPlay의 200바이트 SPC 식별자 제한에 맞게 MediaPackage 메타데이터를 압축하는 동시에 ID 및 IV 키를 유지합니다. 해상도 기본 설정은 너비와 높이를 모두 제공하므로 적응형 재생이 4K에 도달할 수 있습니다. ### Safari 실시간 재생 Safari에서는 Web SDK 1.2.0-preview.13 이상을 사용하세요. macOS, iOS, iPadOS에서 native Apple Media Keys를 사용할 수 있으면 이를 선택하고, live/VOD 재생목록을 전환해도 같은 API를 유지합니다. Live 재생은 MSE/SINF로 전환하지 않습니다. 이 경로는 MediaPackage의 키 회전 후 오래된 초기화 세그먼트 키를 요청할 수 있기 때문입니다. HLS 신호에는 현재 key ID와 IV를 정확히 유지하세요. DRM-X SPEKE는 압축 KeyId/IV 자산 식별자를 생성하므로 Safari는 식별자 크기 제한 내에서 FairPlay 라이선스를 요청할 수 있습니다. DRM License Token는 여전히 정확한 콘텐츠와 키를 승인합니다. 키 서비스를 업데이트한 후 종속 SPEKE 게이트웨이가 실행 중인지 확인하세요. 키 전달을 사용할 수 없는 동안에는 비디오를 수신하는 인코더가 새로운 보호 출력을 게시할 수 없습니다. 별도의 15분 Safari 테스트에서 Mac과 iPhone이 키 순환을 거치면서 재생을 계속하는 것을 확인했습니다. iPhone은 네이티브 Apple Media Keys를 사용했습니다. Mac은 키 순환 확인에 모던 EME를 사용했으며, 이후 모던 EME 시작 오류가 간헐적으로 발생한 뒤 네이티브 Apple Media Keys로 새로 접속하는 테스트를 통과했습니다. 브라우저의 적응형 재생은 Mac에서 720p, iPhone에서 480p에 도달했습니다. 이 결과는 브라우저의 4K 재생이나 Mac이 최종적으로 사용한 호환성 경로의 키 순환을 검증하지 않습니다. 앞서 소개한 네이티브 앱의 4K 결과는 별도 테스트입니다. ### 리허설을 다시 시작하기 전 - SPEKE 엔드포인트에 연결할 수 있고 콘솔에 최근 교환이 표시되는지 확인하세요. 입력을 수신하는 인코더는 키 전달이 실패해도 오래된 미디어를 계속 제공할 수 있습니다. - VOD/offline 미디어 캐시를 라이브 매니페스트 소스와 별도로 유지하세요. - 실제 디코딩된 크기를 확인하세요. 4K 채널을 선택하는 것만으로는 4K 재생이 입증되지 않습니다. - 이번 리허설은 중단되었습니다. 라이브 카탈로그 항목을 다시 테스트하기 전에 새로운 인증된 DRM-X Live Run, AWS 인코더 및 OBS 스트림을 시작하세요.