BLOG

AWS의 라이브 미디어 워크플로, 압축할지 말지 고민된다면?
작성일: 2021-09-15

소개

 

클라우드 마이그레이션 여정을 성공적으로 마무리하기 위해서는 수많은 결정이 필요합니다. 라이브 미디어 워크플로의 주요한 결정 가운데 하나는 바로 ‘온프레미스에서 클라우드로 콘텐츠를 가져오는 방법’입니다. 예를 들면, 스포츠 경기장에서 촬영 중인 이벤트를 처리하기 위해 클라우드로 가져간 다음, 위성을 통해 배포하기 위해 다시 클라우드에서 온프레미스로 이동시키는 것입니다. 이번 포스팅에서는 라이브 워크플로에서 사용 가능한 압축과 비압축 두 가지 방식에 대해 살펴보고자 합니다. 특히 방송사가 워크플로에 가장 적합한 정보를 기반으로 결정을 내리기 위해서 사용할 수 있는 다양한 고려 사항들을 중점적으로 알아보도록 하겠습니다.

 

 

End-to-end 라이브 미디어 체인

 

시작에 앞서 콘텐츠 제작부터 배포에 이르는 End-to-end 라이브 미디어 워크플로의 주요 구성 요소에 대해 알아보겠습니다. 장소, 스튜디오 및 클라우드의 외부 방송 프로덕션과 같은 온프레미스 환경에서 콘텐츠를 전송하는 경우에는 contribution signal workflow 또는 콘텐츠의 ‘first mile’로 간주되는데요, 이 경우 encoding-decoding 주기의 영향을 완화하기 위해서는 최고 화질을 유지하는 것이 중요하며, 일반적으로 프로덕션 워크플로로 처리하면 배포할 때 더 많은 대기 시간이 소요되기 때문에 대기 시간을 최소한으로 하는 것도 contribution workflo의 핵심입니다.

 

Distribution signal flow 또는 콘텐츠의 ‘last mile’은 다양한 전달 플랫폼으로 전송되는 곳인데요, ‘first mile’ 여정과 비교하여 비트 전송률이 더 낮은 것이 주요 고려 사항입니다. 예를 들어, 위성 전송에는 통계적 다중화를 사용해야 하는 고정 업링크 대역폭이 있습니다. 여기서 가변 비트 전송률(VBR)은 아나운서가 뉴스를 전달하는 것처럼 단순한 콘텐츠에 비해 스포츠 클립과 같이 복잡한 콘텐츠에 더 많은 비트를 할당합니다. 또 다른 예로는 가변 비트 전송률 및 해상도를 사용하는 여러 장치에 대해 인터넷을 통해 전달하기 위해 적응형 비트 전송률(ABR) 트랜스코딩이 사용되는 OTT(Over-Top) 애플리케이션이 있습니다.

 

그림 1: End-to-end 라이브 워크플로의 예

 

이제 압축, 비압축 방식을 선택할 때 고려해야 할 몇 가지 고려 사항을 살펴보겠습니다.

 

  1. 캡처, 처리 및 전달하려는 미디어 콘텐츠의 유형
  2. 재전송, 장애 조치 및 오류 수정 메커니즘을 통해 대역폭 오버헤드가 추가된 안정성
  3. 콘텐츠가 캡처된 시간부터 시청자의 장치(glass-to-glass)에 전달될 때까지 허용 가능한 대기 시간(latency)은 일반적으로 초 단위인 반면 운영자 인터페이스에 대한 대기 시간은 일반적으로 밀리초 단위가 필요합니다. 패킷 크기, 네트워크 상태, 재전송 또는 오류 수정 오버헤드로 인한 버퍼링은 이러한 레이턴시(latency) 요구 사항에 영향을 줍니다.
  4. 온프레미스 및 AWS 클라우드 환경에 대한 현재 또는 미래 로드맵과의 상호 운용성

 

워크플로에 대해 충분히 이해하셨나요? 지금부터는 압축 및 비압축 경로 각각에 대해 자세히 살펴보겠습니다.

 

 

압축 방법

 

압축 경로의 기본 개념은 오디오 및 비디오용 압축 알고리즘과 코덱을 활용하는 것이며, 민감한 세부 정보를 유지하면서 asset의 크기를 줄이는 것입니다. 이러한 주요 코덱 중 일부는 H.264(AVC), H.265(HEVC) 및 JPEG(2000 및 XS)를 포함합니다. 압축 알고리즘은 손실과 무손실로 나눌 수 있지만 일부 코덱은 이 둘의 조합을 지원하기도 합니다.

 

 

  • 압축할 때 고려 사항:

압축된 워크플로는 필요한 해상도(예: UHD 4K 신호 지원), 비트 심도/색상 하위 샘플링(예: 4:2:2 10비트 지원) 및 HDR 요구 사항(있는 경우)과 같은 측면을 고려합니다. 또한, 애플리케이션의 latency 요구 사항과 사용 가능한 대역폭을 이해하는 것이 중요합니다. 마지막으로, 기존 또는 미래의 생태계 선택 또한 워크플로의 코덱에 영향을 미칩니다.

 

 

  • H.264 및 H.265(HEVC):

오늘날 업계에서 가장 일반적으로 사용되는 압축 코덱 중 하나인 MPEG-4 AVC Part 10(H.264라고도 함)과 그 후속 제품인 HEVC(High Efficiency Video Codec), 또는 H.265는 손실 압축 표준의 코덱 예시이며, 밀리초에서 몇 초에 이르는 지연 시간이 있습니다. H.264 및 HEVC 코덱은 GOP(Group of Pictures) 외에 I(인트라 또는 키 프레임), P(예측 프레임), B(양방향 프레임) 프레임의 개념을 사용합니다. H.264(및 HEVC)는 프레임 간 압축 외에 프레임 내를 사용합니다.

 

코끼리, 풀, 푸른 하늘이 있는 그림2를 통해 H.264와 HEVC의 차이점을 설명할 수 있습니다. H.264 프레임 내 압축은 모든 픽셀을 압축하는 대신 이미지를 블록으로 나눕니다. 색상이 실제로 변경되지 않기 때문에 알고리즘은 블록을 대신 기억하여 전체 파일 크기를 줄일 수 있습니다. 인터프레임을 사용하여 코끼리가 움직이는 경우 등 여러 이미지를 상상해 보세요. 잔디 또는 푸른 하늘의 색상 및 위치와 같은 이미지 전체의 일부 정보는 반복되므로 알고리즘은 첫 번째 프레임에서 캡처한 것과 동일한 정보를 사용하고, 프레임 전체에서 차이점을 찾을 수 있습니다.

 

그림 2: 간단한 예시 이미지

 

HEVC는 유사한 방식으로 작동하지만, H.264보다 동적이고 더 큰 블록 크기(H.264의 경우 16×16에 비해 최대 64×64)를 지원하므로 알고리즘이 기억해야 하는 블록 수를 줄여서 전체 파일 크기가 더 커집니다. 또한, HEVC는 H.264에 비해 효율성이 약 50% 더 높으므로 동일한 코딩 품질일 경우 비트 전송률의 약 50%를 절약할 수 있습니다. 정확한 bitrate 절감 정도는  비디오 해상도, 색상 비트 심도 등에 따라 다르게 나타납니다. H.264 및 HEVC는 OTT 배포, 위성 및 무선(OTA)과 같은 배포 응용 프로그램에서 많이 사용되지만 더 높은 비트 전송률, 비트 깊이 및 색상 샘플링을 활용하면서 기여에 사용할 수도 있습니다.

 

  • JPEG2000:

JPEG2000은 독립적인 JPEG2000 스트라이프(스트라이프는 하나 이상의 픽셀 행)를 사용하여 종단 간 지연(1프레임 미만 가능)을 지원하므로 원격 프로덕션과 같이 낮은 지연 시간이 필요한 기여 워크플로에 널리 채택된 프레임 내 압축 코덱입니다. HEVC와 유사하게 이 표준은 사용된 압축 비율(일부 응용 프로그램에서는 2:1, 16:1 또는 30:1)에 따라 무손실 및 손실 압축 기술을 모두 수용합니다.

 

이 코덱에 대한 최근 추가 사항은 다음과 같습니다.

  1. VSF TR01 권장 사항에는 UHD 4k, 4:4:4:4 크로마 서브 샘플링 및 “블록 모드” 추가를 통한 더 높은 해상도 지원이 포함됩니다.
  2. 높은 처리량의 JPEG 2000이 JPEG2000 제품군에 새로 추가되어 복잡성은 낮아지고 코딩은 더 빨라졌습니다.

 

  • JPEG XS:

JPEG XS는 압축 비율이 2:1에서 10:1인 새로운 프레임 내 경량 압축 표준으로, 매우 높은 화질(주관적 용어로 ‘비주얼 무손실’이라고도 함)을 제공합니다. JPEG 2000과 비교할 때 JPEG XS는 프레임의 일부 또는 몇 개의 프레임 라인까지 훨씬 더 짧은 대기 시간을 지원합니다. 이 코덱은 CPU 및 GPU 환경에 이상적이며 JPEG 2000에 비해 단순하고 압축 속도가 빠릅니다. JPEG XS는 MPEG 2 TS 또는 2110-22 스택의 일부를 통해 전송할 수 있으므로 ST2110 온프레미스를 채택한 많은 방송사에게 유리합니다. ST 2110-22 스택의 일부인 JPEG XS(여기서 – 22는 ST 2110 표준의 압축된 비디오 본질)는 압축되지 않은 ST 2110과 비교하여 고해상도(4K, 8K 및 16K)의 프로덕션 워크플로에 대한 대역폭 절약에 도움이 됩니다. 또한, JPEG XS는 품질 저하 없이 여러 인코딩-디코딩 프로세스를 허용할 수 있습니다.

 

 

비압축 방식

 

고성능 연결 및 비압축 라이브 비디오 전송이 필요한 워크로드는 본래 사내 구축형으로 배포되었기 때문에 고객은 민첩성 및 확장성과 같은 클라우드의 다양한 이점을 활용할 수 없었습니다. AWS Cloud Digital Interface (AWS CDI)는 지연 시간, 안정성, 콘텐츠 및 상호 운용성을 포기하지 않으면서 AWS에서 고대역폭 비압축 라이브 비디오 워크플로를 위한 기능을 누리기 위해 생성되었습니다.

 

CDI는 클라우드의 라이브 비디오 애플리케이션에 최적화되어 있으며 초당 최대 2160p 60프레임의 해상도에 대해 SDI 및 2110에 해당하는 대기 시간을 지원할 수 있습니다. 애플리케이션당 인코딩/디코딩의 복잡성을 제거하고 비디오, 오디오 및 보조 메타데이터를 독립적으로 전송할 수 있는 유연성을 추가합니다. CDI는 AWS SRD( Scalable Reliable Datagram )를 사용하여 낮은 지연 시간으로 안정적으로 높은 처리량을 전송할 수 있습니다. AWS SRD는 가용 영역 (AZ) 내의 Amazon Elastic Compute Cloud (Amazon EC2) 네트워크 용으로 설계되었으며, 100Gbps Elastic Fabric Adapter와 결합될 때(EFA)는 페이로드를 전송하기 위한 커널 우회 방법을 제공합니다. AWS CDI 소프트웨어 개발 키트(SDK)는 ISV(독립 소프트웨어 공급업체)에 지연 시간이 짧고 확장 가능하며 안정적인 클라우드 기반 비디오 애플리케이션을 구축할 수 있는 기능을 제공하는 오픈 소스로 제공됩니다.

 

 

작업에 적합한 도구 선택

 

압축, 비압축 방식을 선택할 때 시그널의 여정과 관련된 모든 기준(예: 그림 3에 표시된 콘텐츠 유형, 안정성, 허용 가능한 대기 시간 또는 상호 운용성)을 고려해야 합니다.

 

그림 3: 고려 기준에 대한 매트릭스

 

다음 표에서는 다양한 고려 사항과 그 영향을 단순화하는 데 도움이 되는  워크플로, 작업에 권장되는 도구 및 대기 시간 범위 등을 간락하게 설명하고 있습니다.

  • 대기 시간 범위*:

 

 

 

 

 

 

 

 

*제공된 대기 시간 범위는 독자에게 높은 수준의 아이디어를 제공하는 것을 목표로 합니다. 대기 시간은 네트워크 상태, 작업 프로필 및 구성, 워크플로 요구 사항(예: 출력 형식 및 스트리밍 프로토콜)과 같은 다양한 조건에 따라 다릅니다.

 

다음으로는 프로덕션 워크플로의 예제를 살펴보겠습니다. 온프레미스 시설에서 클라우드로 신호를 이동하기 위해 JPEG XS를 사용하여 다양한 네트워크 경로를 통해 전송하면서 대기 시간을 최소화할 수 있습니다. AWS Elemental MediaConnect는 원활한 장애 조치를 위해 SMPTE 2022-7을 지원하고, AZ 내에서 CDI를 출력하므로 이러한 신호를 수집하는 데 활용할 수 있습니다.

 

각 AZ 내에서 라이브 프로덕션 및 포스트 프로덕션 워크플로는 압축되지 않은 CDI를 활용할 수 있습니다. 예를 들어, 재생, 프로덕션 스위처, 오디오 믹서, 재생 서버, 인제스트 및 자막이 있는 라이브 프로덕션이 있습니다. 처리가 완료되면 위성 업링크 및 OTT와 같은 AWS Elemental MediaLive 배포 워크플로를 사용하여 라이브 채널을 압축할 수 있습니다.

 

아래 그림은 사용 사례/애플리케이션에 따라 수정할 수 있는 아키텍처의 예입니다.

 

그림 4: CDI를 사용하는 AWS의 라이브 프로덕션 워크플로 아키텍처 예시

 

 

결론

 

이번 포스팅에서는 클라우드에서 라이브 프로덕션 워크플로를 계획할 때 고려해야 할 다양한 경로와 주의 사항에 대해 알아보았습니다. 사실 레버리지를 위한 경로를 선택하는 것은 큰 문제가 아니며, 오히려 두 가지가 혼합되어 있을 수도 있습니다. 그러나 의사 결정을 내리는 데 반드시 고려해야 할 세 가지 사항이 있습니다. 바로 화질, 대역폭 및 대기 시간입니다. 워크플로 또는 응용 프로그램이 허용할 수 있는 사항과 우선 순위에 따라 세 가지 고려 사항 사이에는 언제나 기회 비용이 있습니다. 예를 들어, 비압축 또는 JPEG XS에 대해 필요에 따라 고대역폭을 사용할 수 있다면 매우 높은 화질과 매우 짧은 대기 시간을 얻을 수 있지만, 사용 가능한 대역폭이 부족하면 비용이 신호를 압축하는 데 필요한 처리(H.264/H.265)로 이동하여 대기 시간이 길어지고 비트 전송률이 낮아지게 됩니다.

 

오늘 설명 드린 일부 서비스, 모범 사례 및 최신 발표에 대한 추가적인 내용을 확인하시려면 다음 링크를 참조해주세요.

ㅊ

원문URL: https://aws.amazon.com/ko/blogs/media/metfc-live-media-workflows-on-aws-to-compress-or-to-not-compress/

메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.