카메라를 통해서 활용하는 신호가 사람의 눈으로 전달되기까지 다음과 같은 과정을 거치게 된다.
요즘 출시되는 카메라의 경우 파일로 바로 저장이 되지만 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
과 같은 방식도 존재한다. 이런 경우 그 형태는 파일로 존재를 하게 된다.
우리가 흔히 알고 있는 코덱은 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이다.
인코딩은 압축과정을 의미합니다. 예를 들어 압축되지 않은 무압축 영상을 코덱을 이용하여 압축하는 작업을 의미한다. 카메라에서 촬영하면서 저장된 무압축 mp4를 h.264 Codec을 통해 HD, FHD 등으로 해상도를 줄이면서 압축하는 작업이다. 이 과정에서 중요한 점은 바로 어느 정도의 손실을 감수하고 화질을 줄일지 결정하는 부분이다. 사실상 플랫폼 서비스를 위해서 인코딩과 동시에 트랜스코딩이 함께 진행된다고 보면 된다.
트랜스코딩은 영상소스가 다른 형식으로 변환됨을 의미합니다. 주로 이 부분은 현업에서 어떤 상황이냐면, RTMP가 원본인 영상을 고객에게 화질별로 서비스하기 위해서 SD
, HD
, FHD
이렇게 3가지로 인코딩이 되고 인코딩 된 영상이 아이폰과 안드로이드로 DRM 암호화 된 서비스가 된다는 가정에 있어 다음과 같은 종류로 파일이 트랜스코딩됩니다.
- SD: 640480 해상도 / HLS 형식의 m3u8 파일 FirePlay 적용
- HD: 720p 해상도
- FHD: 1080p 해상도
- SD: 640480 해상도 / Dash 형식의 mpd 파일 Widevine, Playready(PC용)
- HD: 720p 해상도
- FHD: 1080p 해상도
이렇게 원본 1개가 각 화질로 총 6개의 서비스 파일이 인코딩 되는 동시에 DRM이 패키징 된 다른 형식의 파일로 트랜스코딩 하게 된다.
AWS 이외 다른 솔류션들에서도 마찬가지로 변환되어 출력되는 결과물의 분당 과금으로 요금을 책정하는게 일반적이다. 물론 Live의 경우 input과 output 둘 다를 과금하는 형태도 있다.
이때 정말 조심해야 할 부분은 기획 단계에서 콘텐츠 변환 비용을 예측하기 위해 단순히 몇분에 얼마라는 식으로 단순히 계산하면 안된다. 어떠한 화질로 어떤 환경에서 어떤 디바이스에 서비스할지 잘 기획해야 한다.
인코딩 단계에서 압축 과정 중 원본영상의 손실을 얼마나 가져갈지 그리고 화질을 얼마나 유지할지 기준이 되는 것이 바로 Bitrate이다.
방송의 경우 29.976fps
로 서비스되고, 영화는 23.976fps
로 서비스 된다. 여기서 숫자가 의미하는 것은 1초에 몇개의 이미지로 서비스되는지를 의미한다. 결국 방송은 1초에 약 30장의 이미지로 생성된 영상으로 서비스한다는 말과 같다.
여기서 영상을 구성하는 각 프레임의 이미지 압축과 변환에서 몇 Mbps로 만들지를 설정하는 부분이다. 비트레이트가 높으면 높을수록 화질은 좋아진다.
현재 다양한 솔루션에서 각자의 기술력으로 고효율을 내세워 다양한 변환방식을 제공한다. 여기서 비트레이트를 고정으로 변환할 것인지 아니면 가변으로 변환할 것인지를 설정하게 된다.
CBR(고정 비트레이트 변환)
말 그대로 프레임을 변환할 때 가량 2Mbps로 비트레이트를 설정했다면 화면을 구성하는 색이나 화질의 왜곡여부에 관계없이 무조건 2Mbps로 변환한다.
VBR(가변 비트레이트 변환)
영상을 구성하는 프레임들이 어두운화면 또는 밝은 화면등과 같이 그 화면의 효율을 연산하여 각기 다른 비트레이트로 변환하는 방식을 의미한다. 보통 VBR 같은 경우 Max와 Min으로 최소와 최대치를 설정하고 그 범위 안에서 용량을 가변적으로 변환한다.
이렇듯 비트레이트는 화질과 직결된 항목이니 만큼 영상을 서비스하는 입장에서는 매우 중요한 요소가 된다.
비트레이트는 화질이라는 단순한 개념 그 이상으로 운영비용에도 직결되는 매우 중요한 부분이다. 쉽게 말해 Outbound Traffic은 이 비트레이트를 기반으로 발생한다. 따라서 고화질의 높은 비트레이트로 서비스를 한다는 것은 그만큼의 CDN 비용이 더 나온다고 생각하면 된다.
또한 유튜브와 같이 사용자의 네트워크 상황에 따라 화질이 Auto라는 옵션명으로 제공되는 Adaptive Streaming 방식으로 서비스한다면 운영비용의 절감을 가져올 수 있다.
원본 영상파일 또는 신호를 1차적으로 인코딩을 통해 화질별로 압축하는 동시에 서비스 스펙에 맞는 파일 형태로 트랜스코딩 한다고 생각하면 된다. 그래서 일각에서는 이를 통칭해 인코딩 솔루션 또는 트랜스코딩 솔루션이라고 부른다.