중요 개념

이해 사용자 입력의 지시: OTT 및 RTC의 미디어 플레이어 이해

10 분 읽기
Feb 18, 2025

OTT(Over-the-Top) 콘텐츠 전달 및 실시간 통신(RTC) 세계에서 미디어 플레이어는 최종 사용자에게 고품질 오디오 및 비디오 경험을 제공하는 데 중요한 역할을 합니다. 이 블로그 포스트에서는 미디어 플레이어의 내부 작동 방식을 살펴보고, 그 과정을 파일 획득, 오디오-비디오 분리, 디코딩 및 동기화, 렌더링의 네 가지 주요 단계로 나누어 설명하겠습니다.

1. 파일 획득

재생 과정의 첫 번째 단계는 미디어 파일을 획득하는 것입니다. 이는 두 가지 주요 방법으로 발생할 수 있습니다:

네트워크 다운로드: 파일은 RTMP(Real-Time Messaging Protocol) 또는 HTTP(Hypertext Transfer Protocol)와 같은 프로토콜을 사용하여 원격 서버에서 다운로드될 수 있습니다.

로컬 접근: 파일은 일반적으로 file:// 프로토콜을 통해 로컬 디스크에서 액세스할 수 있습니다.

플레이어가 파일을 획득한 후에는 컨테이너 형식을 분석하여 콘텐츠가 어떻게 패키징되었는지 이해합니다.

2. 오디오-비디오 분리

파일을 획득한 후, 플레이어는 미디어의 다양한 구성 요소를 분리해야 합니다. 이 과정은 다음을 포함합니다:

메타데이터 분석: 플레이어는 파일의 메타데이터를 분석하여 콘텐츠에 대한 정보를 수집합니다.

스트림 분리: 콘텐츠는 별도의 스트림으로 분리됩니다. 여기에는 다음이 포함될 수 있습니다:

  • 비디오 스트림
  • 오디오 스트림
  • 자막
  • 챕터 정보

이 분리는 분리기 또는 디멀티플렉서라는 모듈에 의해 수행됩니다. 이는 주로 데이터를 수집하고 분리하며 선택하는 작업이므로 일반적으로 계산 집약적이지 않습니다.

3. 디코딩 및 동기화

스트림이 분리된 후, 이를 디코딩하고 동기화해야 합니다. 이 과정은 원활한 시청 경험을 보장하는 데 중요합니다.

디코딩

다양한 스트림은 각각의 디코더로 전송됩니다:

  • H.264 비디오 스트림은 비디오 디코더로 전송됩니다.
  • AAC 오디오 스트림은 오디오 디코더로 전송됩니다.

각 디코더는 인코딩된 데이터를 원래 형식으로 다시 압축 해제합니다.

동기화 문제

디코딩 후, 우리는 별도로 디코딩된 오디오 및 비디오 스트림이 완벽하게 동기화되도록 어떻게 보장할 것인가 하는 중요한 질문에 직면하게 됩니다.

여기서 DTS(디코더 타임 스탬프)와 PTS(프레젠테이션 타임 스탬프)가 등장합니다. 이 타임스탬프는 오디오와 비디오 데이터 간의 동기화 문제를 해결하는 데 중요하며, 디코더 입력 버퍼 오버플로우나 언더플로우를 방지하는 데 도움을 줍니다.

  • DTS (디코더 타임 스탬프): 데이터를 디코더에 공급할 시점을 나타냅니다.
  • PTS (프레젠테이션 타임 스탬프): 디코딩된 프레임을 표시할 시점을 나타냅니다.

DTS와 PTS는 상대적인 시간일 수 있으며, 대부분의 경우 동일합니다.

비디오 동기화

비디오의 경우, 각 I, P, B 프레임은 DTS와 PTS를 모두 가지고 있습니다. 이는 프레임의 저장 순서가 표시 순서와 다를 수 있기 때문에 필요합니다. 예를 들어, 저장 순서는 IPBBBBB...일 수 있지만, 표시 순서는 IBBBBBP...입니다. 표시하기 전에 디코더의 버퍼에 있는 프레임은 재정렬되어야 하며, PTS는 이 과정에서 필수적입니다.

오디오 동기화

오디오 데이터에도 프레임의 개념이 있지만, 이는 인위적으로 정의된 것입니다. 일반적으로 특정 수의 연속 샘플이 오디오 프레임으로 선택되고 이 프레임에 PTS가 추가됩니다. AAC의 경우, 일반적으로 1024개의 연속 샘플이 하나의 프레임을 형성합니다. 48000Hz의 샘플링 속도에서 각 오디오 프레임은 약 21.33ms(1024×1000÷48000)입니다.

동기화 과정

대부분의 경우, 오디오의 고정 샘플링 속도로 인해 오디오 프레임의 PTS는 상대적으로 안정적입니다. 따라서 표시할 때, 오디오 프레임의 PTS를 시간 기준으로 사용합니다. 오디오 프레임을 디코딩하고 표시할 때, 동시에 표시하기 위해 가까운 PTS를 가진 비디오 프레임을 찾습니다. 이렇게 하여 오디오-비디오 동기화를 달성합니다.

오디오와 비디오 프레임의 PTS 값이 정확히 일치하는 것은 어려운 점에 유의해야 합니다. 일반적으로 PTS 값의 차이가 200ms 이내일 경우 오디오와 비디오가 동기화된 것으로 간주합니다.

동기화 문제 해결

PTS 차이가 작지만 이미지와 소리가 여전히 맞지 않는 경우, 이는 캡처 과정 중에 문제가 있었음을 나타내는 경우가 많습니다.

이러한 동기화 기술을 이해하고 적절히 구현함으로써 개발자는 OTT 및 RTC 애플리케이션이 최종 사용자에게 고품질의 동기화된 오디오-비디오 경험을 제공하도록 할 수 있습니다.

4. 렌더링 및 디스플레이

최종 단계는 디코딩된 콘텐츠를 렌더링하는 것입니다:

비디오 렌더링

디코딩된 비디오 프레임은 각 픽셀의 색상 값을 포함하여 화면에 표시하기 위해 렌더러로 전송됩니다.

오디오 렌더링

디코딩된 오디오 데이터는 파형 형태로 사운드 카드로 전송되고, 이후 스피커를 통해 재생됩니다.

운영 체제는 일반적으로 렌더링을 위한 API를 제공합니다:

  • Windows: DirectX
  • Android: OpenGL ES(비디오) 및 OpenSL ES(오디오)
  • iOS: OpenGL ES(비디오) 및 AudioUnit(오디오)

개발자는 커스텀 렌더링을 구현할 수 있지만, 일반적으로 관련된 복잡성 때문에 권장되지 않습니다.

완전한 오디오-비디오 흐름

전체 과정을 더 잘 이해하기 위해 오디오-비디오 흐름을 검토해 보겠습니다:

OTT (Over-the-Top) content delivery and real-time communication (RTC) play a crucial role in providing high-quality audio and video experiences to end-users. This blog post explores the internal functioning of media players, explaining the process in four main stages: file acquisition, audio-video separation, decoding and synchronization, and rendering and display. 1. **File Acquisition**: The first stage involves acquiring media files, which can occur through network download using protocols like RTMP or HTTP, or local access. After obtaining the files, the player analyzes the container format to understand how the content is packaged. 2. **Audio-Video Separation**: Following file acquisition, the player separates the various components of the content. This includes analyzing metadata and separating the streams into individual components such as video streams, audio streams, subtitles, and chapter information. This separation is typically performed by分解器或demultiplexer modules. 3. **Decoding and Synchronization**: After separating the streams, they need to be decoded and synchronized. This process is essential to ensure a smooth viewing experience. Decoding involves converting encoded data back into its original format using decoders specific to each stream type (e.g., H.264 for video, AAC for audio). Synchronization ensures that the audio and video streams are aligned in time. 4. **Rendering and Display**: The final stage involves rendering and displaying the decoded content. Decoded video frames are sent to the renderer for display, while decoded audio data is sent to the sound card for playback through speakers. Operating systems provide APIs (e.g., DirectX for Windows, OpenGL ES for Android and iOS) for rendering, and developers can implement custom rendering if necessary. By understanding and appropriately implementing these stages, developers can ensure that OTT and RTC applications provide high-quality, synchronized audio-video experiences to end-users.

캡처:

  • 마이크로폰으로 캡처된 오디오
  • 카메라로 캡처된 비디오

처리:

  • 원시 오디오 데이터(PCM) 처리됨
  • 원시 비디오 데이터(YUV420/ARGB) 처리됨

인코딩:

  • 오디오는 AAC/Opus와 같은 형식으로 인코딩됨
  • 비디오는 H.264/MPEG-4/H.265와 같은 형식으로 인코딩됨

패키징:

  • 인코딩된 스트림이 FLV/MP4/TS/AVI/MKV와 같은 컨테이너에 패키징됨

전송:

  • 패키징된 데이터가 UDP/RTMP/HTTP-FLV/HLS와 같은 프로토콜을 사용하여 전송됨

수신 및 언팩킹:

  • 수신된 데이터가 언팩킹됨

디코딩:

  • 오디오 및 비디오 스트림이 각각 PCM 및 YUV420/ARGB로 디코딩됨

후처리 및 동기화:

  • 디코딩된 스트림이 처리되고 동기화됨

렌더링:

  • 오디오는 오디오 재생 장치를 통해 재생됨
  • 비디오는 비디오 디스플레이 장치를 통해 표시됨

결론

미디어 플레이어의 복잡성을 이해하는 것은 OTT 및 RTC 기술에서 작업하는 개발자에게 중요합니다. 파일 획득에서 렌더링까지, 각 단계는 원활한 시청 경험을 제공하는 데 중요한 역할을 합니다. 기술이 계속 발전함에 따라, 이러한 프로세스를 최신 상태로 유지하는 것이 효율적이고 고품질의 미디어 애플리케이션을 개발하는 데 핵심이 될 것입니다.