영상 인코딩? 트랜스코딩?

OTT 서비스를 운영하거나 개발하는 담당자들 사이에서도 이 두가지의 명확한 뜻을 모르고 그냥 퉁쳐서 부르기 편한걸 그때그때 부르는 경우가 많다.

실제 담당자에게 인코딩은 뭐고 트랜스코딩이 뭐냐고 물어봤을 때 그게 그거 아니냐?하는 경우가 많다. 우선 이 포스팅에서 인코딩과 트랜스코딩을 설명하는 과정에서 온라인에서 서비스 되는 영상의 포멧과 방식에 대해서 간략히 기획자 관점에서 이해하면 좋을만한 수준으로 정리하려 한다.

1. 신호 & 파일형식

카메라를 통해서 촬영하는 신호가 사람의 눈으로 전달되기까지 다음과 같은 과정을 거치게 된다.

요즘 출시되는 카메라의 경우 파일로 바로 저장이 되지만 Live로 촬영되고 있는 영상에 대해서 캡쳐 인터페이스를 통한 파일 생성이 필요하다. 요즘은 카메라 자체적으로 바로 RTMP 신호와 같이 곧바로 스트리밍 신호를 뽑아내는 기능도 가진 카메라들이 많다. 이럴 경우 중간 과정 없이 바로 파일이나 신호로 Output이 나오게 된다.

신호형식이라는 표현을 사용한 이유는 서비스할 콘텐츠가 실시간인 경우에 해당한다. 종류에 따라 HLS로 서비스하는 경우 신호인 동시에 파일이기도 하다.

짧게 말하자면. HLS기준으로 m3u8이라는 manifest file이 생성된다. 이 파일을 메모장으로 열어보면 몇 가지 태그와 함께 하위에 Chunk파일 리스트가 보이게 된다. 즉 m3u8파일은 그 내용이 계속 바뀌게 되고 Chunk라는 짧게 잘린 동영상 파일 목록이 갱신된다. 이 짧은 동영상 mpd 또는 mp4파일들의 길이를 GOP라고 부른다.

RTMP/RTSP (Real Time Streaming Protocol)

실시간 스트리밍 프로토콜로 온라인에서 영상을 서비스하기 위한 통신 프로토콜로 많은 스트리밍 서비스 플랫폼들이 현재도 사용하고 있는 영상 전송을 위한 프로토콜이다.

현재까지도 여러 분야에 걸쳐 영상을 전송하는 목적으로 사용이 되고 있으며, RTMP로 원본을 받아 서비스에 맞는 화질과 포멧으로 변환뒤 다시 고객에게도 RTMP로 서비스하기도 한다.

이외에도 Web 프로토콜을 사용하는 방식도 있으며, 대표적인 Case로는 Apple에서 제공하는 HLS방식도 있으며, MPD확장자로 서비스하는 DASH도 있으며, 이를 통합하기 위한 VP9과 같은 방식도 존재한다. 이런 경우 그 형태는 파일로 존재를 하게 된다.

사실 더 많은 내용을 숙지하고 OTT 플랫폼을 기획한다면 더할 나위 없이 좋겠지만 우선 위에서 설명한 정도의 이해도만 있어도 기획에는 큰 무리가 없으리라 생각된다.

2. 코덱(Codec)

우리가 흔히 알고 있는 코덱은 h.264, h.265, DivX, AV1 등 수많은 종류의 코덱이 존재한다.

쉽게 말해 코덱은 영상을 압축하기 위한 기술이다. 최대한 원본의 화질을 유지하면서 저용량 고화질의 서비스를 위해 영상을 압축하는 S/W를 말한다.

코덱은 많은 회사에서 자체적으로 제공한다. 따라서 유료 일 수 있고 무료일 수 있다. 대부분 영상 서비스에서 많이 사용하고 있는 코덱은 h.264 또는 h.265(HEVC)가 있다.

h.265는 HEVC라는 명칭과 함께 갑작스럽게 유료화 되어 전환을 고민했던 플랫폼 사업자들에게 기존의 h.264를 쓰거나 VP9으로 방향을 돌리게 하는 원인이 된다.

필자가 주로 사용했던 h.264 코덱은 Profile이라는 속성이 있다.

이는 고객에게 서비스할 시 고객의 다양한 재생 조건에 따라 다음과 같은 종류가 있다.

Baseline

Constrained Baseline

Main

Extended

High

High 10

High 10 intra

High 4:2:2

High 4:2:2 intra

High 4:4:4 Predictive

High 4:4:4 intra

CAVLC 4:4:4 intra

Multiview High

여러 종류가 있지만 호환성을 이유로 주로 사용하는 것은 Baseline과 Main이다. 필자가 실제 서비스를 적용하는 시점에서 화질과 효율성을 이유로 High를 적용했을 당시 디바이스에서 재생이 안되는 Case가 발견되어 결국 Main으로 서비스하였다.

Main도 버전에 존재한다. 이 버전이 기획자의 발목을 잡으리라 설정당시 상상도 못했다. 하지만 고도화 프로젝트 진행 당시 iOS 13이 발표가 되면서 DRM암호화를 적용한 콘텐츠가 재생에 문제가 생기면서 Spec.을 내린 적이 있다.

여러 솔루션에서도 코덱 부분은 거의 공통적이거나 유사한 형태로 설정하게 되어있다. 따라서 용어의 차이는 솔루션마다 다소 차이가 있을 수 있지만 설정에 필요한 공통적인 부분은 거의 동일하다고 볼 수 있다.

3. 인코딩(Encoding)

인코딩은 압축과정을 의미합니다. 예를 들어 압축되지 않은 무압축 영상을 코덱을 이용하여 압축하는 작업을 의미한다.카메라에서 촬영하면서 저장된 무압축 mp4를 h.264 Codec을 통해 HD, FHD 등으로 해상도를 줄이면서 압축하는 작업이다.
이 과정에서 중요한 점은 바로 어느 정도의 손실을 감수하고 화질을 줄일지 결정하는 부분이다.
사실상 플랫폼 서비스를 위해서 인코딩과 동시에 트랜스코딩이 함께 진행된다고 보면 된다.

4. 트랜스코딩(Transcoding)

트랜스코딩은 영상소스가 다른 형식으로 변환됨을 의미합니다. 주로 이 부분은 현업에서 어떤 상황이냐면, RTMP가 원본인 영상을 고객에게 화질별로 서비스하기 위해서 SD, HD, FHD 이렇게 3가지로 인코딩이 되고 인코딩 된 영상이 아이폰과 안드로이드로 DRM 암호화 된 서비스 된다는 가정에 있어 다음과 같은 종류로 파일은 트랜스코딩 된다.

iOS (총 3개)

SD : 640480 해상도 / HLS 형식의 m3u8 파일 FirePlay 적용

HD : 720p 해상도

FHD : 1080p 해상도

Android (총3개)

SD : 640480 해상도 / Dash 형식의 mpd 파일 Widevine, Playready(PC용)

HD : 720p 해상도

FHD : 1080p 해상도

이렇게 원본 1개가 각 화질로 총 6개의 서비스 파일이 인코딩 되는 동시에 DRM이 패키징 된 다른 형식의 파일로 트랜스코딩 하게 된다.

AWS 이외 다른 솔루션들에서도 마찬가지로 변환되어 출력되는 결과물의 분당 과금으로 요금을 책정하는게 일반적이다. 물론 Live의 경우 input과 output 둘 다를 과금하는 형태도 있다.

이때 정말 조심해야 할 부분은 기획 단계에서 콘텐츠 변환 비용을 예측하기 위해 단순히 몇분에 얼마라는 식으로 단순히 계산하면 안된다. 어떠한 화질로 어떤 환경에서 어떤 디바이스에 서비스 할지 잘 기획해야 한다.

5. 화질(Bitrate)

인코딩 단계에서 압축 과정 중 원본영상의 손실을 얼마나 가져갈지… 그리고 화질을 얼마나 유지할지 기준이 되는 것이 바로 Bitrate이다.

방송의 경우 29.976fps로 서비스 되고, 영화는 23.976fps로 서비스 된다. 여기서 숫자가 의미하는 것은 1초에 몇개의 이미지로 서비스되는지를 의미한다. 결국 방송은 1초에 약 30장의 이미지로 생성된 영상으로 서비스한다는 말과 같다.

여기서 영상을 구성하는 각 프레임의 이미지 압축과 변환에서 몇 Mbps로 만들지를 설정하는 부분이다. 비트레이트가 높으면 높을수록 화질은 좋아진다.

현재 다양한 솔루션에서 각자의 기술력으로 고효율을 내세워 다양한 변환방식을 제공한다. 여기서 비트레이트를 고정으로 변환할 것인지? 아니면 가변으로 변환할 것인지를 설정하게 된다.

CBR (고정 비트레이트 변환)
말 그대로 프레임을 변환할 때 가량 2Mbps로 비트레이트를 설정했다면 화면을 구성하는 색이나 화질의 왜곡여부에 관계없이 무조건 2Mbps로 변환한다.

VBR (가변 비트레이트 변환)
영상을 구성하는 프레임들이 어두운화면 또는 밝은 화면등과 같이 그 화면의 효율을 연산하여 각기 다른 비트레이트로 변환하는 방식을 의미한다. 보통 VBR같은 경우 Max와 Min으로 최소와 최대치를 설정하고 그 범위 안에서 용량을 가변적으로 변환한다.

이렇듯 비트레이트는 화질과 직결된 항목이니 만큼 영상을 서비스하는 입장에서는 매우 중요한 요소가 된다. 서비스 이전 단계 정책부터 기획은 이러한 화질들의 차이를 눈으로 확인하고 비교하여 최적의 서비스 화질을 찾는 작업이 필요하다고 생각한다.

비트레이트는 화질이라는 단순한 개념 그 이상으로 운영비용에도 직결되는 매우 중요한 부분이다. 쉽게 말해 Outbound Traffic은 이 비트레이트를 기반으로 발생한다. 따라서 고화질의 높은 비트레이트로 서비스를 한다는 것은 그만큼의 CDN비용이 더 나온다고 생각하면 된다.

또한 유투브와 같이 사용자의 네트워크 상황에 따라 화질이 Auto라는 옵션명으로 제공되는 Adaptive Streaming 방식으로 서비스한다면 운영비용의 절감을 가져올 수 있다.

또한 필자가 사용해본 여러 솔루션들 중에 이 비트레이트 변환방식에 따라 같은 해상도의 같은 화질에 최대 30%이상 용량차이가 존재했다.

적어도 미디어 플랫폼 기획자는 단순히 화면을 그리고 서비스를 정의하는 단계는 물론 이러한 운영비용의 절감과 운영공수의 효율화까지 고민하여 기획을 해야 한다고 생각한다.

6. 그래서 인코딩과 트랜스코딩의 차이?

원본 영상파일 또는 신호를 1차적으로 인코딩을 통해 화질별로 압축하는 동시에 서비스 스펙에 맞는 파일 형태로 트랜스코딩 한다고 생각하면 된다. 그래서 일각에서는 이를 통칭해 그냥 인코딩 솔루션 또는 트랜스코딩 솔루션이라고 부른다.

사실 인프라 관점에서 인코딩과 트랜스코딩 인프라가 분리되는 형태의 규모를 가진곳은 보지 못했다. 하지만 하드웨어 성능에 따라 동시에 수용할 수 있는 소스의 갯수와 Output을 뽑아내는 성능에서 차이는 많았다.

Ffmpeg의 경우 많은 기능을 가지고 있으며, 하드웨어 가속을 사용할 수 있는 옵션도 제공하고 있다. Intel CPU를 사용하는 경우 Quick Sync라는 기능을 사용하게 되면 그 변환속도는 눈에 띄게 차이가 났었다.

GPU가속을 사용하는 경우에도 멀티인코딩 환경에서 우수한 퍼포먼스를 보여줬다. 다만 실제 결과물은 장비와 옵션에 따라 차이가 났고 영상 내 빠른 화면전환이 일어나는 장면에서 원하는만큼의 성능이 나는지를 꼭 사전에 POC를 통해 검증할 필요가 있다.

 

최근 관련글

2021.02.16 - [스스로 학습자료/OTT 미디어 플랫폼] - 동영상 플랫폼의 자막서비스에 대하여

동영상 플랫폼의 자막서비스에 대하여

2020.07.03 - [스스로 학습자료/OTT 미디어 플랫폼] - OTT 또는 Media Service의 인프라 전환 -개요-

OTT 또는 Media Service의 인프라 전환 -개요-