Live & VOD Streaming Media server 구축 (4) - 오디오, 비디오 코덱 선정 상세

코덱

음성 또는 영상의 아날로그 신호를 디지털 신호로 변환하는 코더(coder)와 디지털신호를 음성 또는 영상으로 변환하는 디코더(decorder)의 합성어이다.

 

동영상과 음악을 압축하고 그것을 해제하는데 필요한 것 

 

인코딩(Encoding)
아날로그 신호나 스트림 데이터로 이루어진 비디오와 오디오를 압축된 부호로 변환하기 위한 규격

디코딩(Decoding)
압축된 데이터를 본래의 아날로그 신호나 스트림 데이터로 복원하기 위한 규격 

 

 

동영상 파일이 우리가 보는 인터넷이나 플레이어 프로그램에서 재생되는 과정

 

동영상 생성

원본 동영상 -> 인코딩(압축) -> 압축된 동영상 파일로서 존재 (mp4,avi 등) 

 

동영상 재생

압축된 동영상 파일로서 존재 (mp4,avi 등) -> 해당 압축방식(codec) 을 해석할 수 있는 코덱이 컴퓨터 내에 존재한다면 **Player** -> 디코딩 -> 재생

 

전체 과정 

원본동영상 -> 인코딩 -> 파일 존재 -> 내 컴퓨터에 해당 코덱 프로그램 존재(player) -> 디코딩 -> 재생 

 

또한 동영상에서는 보통 음성과 비디오가 같이 보이지만 실제로는 따로 존재한다. 

 

AVI Container의 예시이다.

 

동영상에 대한 자세한 정보를 모른다면  https://realizetoday.tistory.com/9

Live & VOD Streaming Media server 구축 (3) - 디지털 동영상이란

해당 글을 보고와도 좋다.

 

보이는 것 처럼 오디오와 비디오가 서로 다른 코덱으로 압축되어있고 따라서 라이브 스트리밍에 필요한 오디오와 비디오 코덱은 따로 선정해야한다. 

 

일단 오디오 코덱과 비디오 코덱을 선정하기 위해 우리 서비스에서 사용할

ingest = RTMP 프로토콜

egress = HLS 프로토콜

 

에서 지원하는 비디오, 오디오 코덱이 어떤 것인지 살펴봤다. 

 

RTMP

• 비디오 코덱 : H.264, VP8, VP6, Sorenson Spark ®, Screen Video v1 및 v2
• 오디오 코덱 : AAC, AAC-LC, HE-AAC + v1 및 v2, MP3, Speex, Opus , Vorbis

HLS

• 비디오 코덱 : H.265, H.264
• 오디오 코덱 : AAC-LC, HE-AAC + v1 및 v2, xHE-AAC, Apple Lossless, FLAC

 

종류가 다양했고, 해당 코덱들을 비교하기 전에 우리가 서비스할 플랫폼들에서도 기본적으로 지원하는 코덱이 있는지 살펴봤어야 했다. 그 이유는 예를들어 Android에서 기본적으로 내장되어있지 않은 코덱이면, 해당 코덱을 지원하는 플레이어를 따로 깔아야하는 불편함을 감수하면서까지 우리 서비스를 사용할 것 같지 않아서이다. 

 

우리 서비스는 웹, IOS, Android 플랫폼에서 이용이 가능하도록 지원할 예정이다. 

 

2022-03-08 기준 

 

Android

• 비디오 코덱 : H.263, H.264 ( BP,MP) , H.265 HEVC, MPEG-4 SP , VP8, VP9
• 오디오 코덱 : AAC LC, HE-AACv1(AAC+), HE-AACv2(개선된 AAC+), AAC ELD(개선된 저지연 AAC), AMR-NB, AMR-WB, FLAC, GSM, MIDI, MP3, Opus, PCM/WAVE , Vorbis

IOS

• 비디오 코덱 : H.265, H.264
• 오디오 코덱 : AAC-LC, HE-AAC + v1 및 v2, xHE-AAC, Apple Lossless, FLAC

 

이렇게 보니 슬슬 좁혀지는 것 같았다. 

 

 

 

---

일단 RTMP, HLS Protocol / Android, IOS Platform 을 모두 지원하는 코덱이어야 하는 이유가 있다. 

 

TransMuxing , Transcoding 의 차이라고도 볼 수 있다.

 

- TransMuxing 

오디오 및 비디오 파일을 파일 내용을 변경하지 않고 다른 전달 형식으로 재패키징하는 프로세스 ( ex RTMP to HLS 코덱 변경 x )

 

- Transcoding

한 인코딩을 다른 인코딩 으로 직접 디지털-디지털 변환하는 것 (ex H.264/AAC to VP8/Opus)

 

 

코덱을 변경하지 않는다고해서 컨테이너를 변경하는 것도 Transcoding 이라고 오해하기 쉬운데 예를들어 위 글 중 Android 기준으로 비디오 코덱을 H.264 , 오디오 코덱을 AAC-LC 로 압축한 mp4 컨테이너 형식이 있다고 가정해보자. 

 

MP4 Container                             -->                AVI Container
H.264 Video codec                                            H.264 Video codec
AAC-LC Audio codec                                         AAC-LC Audio codec 

 

코덱을 담고있는 컨테이너 형식만 변경하게 된다면 트랜스코딩이 아닌 TransMuxing이 되는 것이다. 

 

 

만약 컨테이너만 변경하는게 아닌 실질적인 데이터인 Video, Audio 코덱을 변경하게 되면 압축방식이 아예 달라지는 것이기 때문에 Transcoding 이다. 

 

TransMuxing의 장점

일반적으로 압축되지 않은 원시 비디오 또는 오디오 소스를 수정하지 않기 때문에 더 가벼운 것으로 간주되고 컴퓨팅 성능이 덜 필요하다.

 

 

따라서 코덱을 선정할 때는 자신의 서버 성능이 매우 좋거나 중간에 코덱을 변경해야하는 특별한 이유가 있지 않은 이상 지원하려는 플랫폼들에서 기본적으로 모두 재생이 가능한 코덱을 선정하는 것이 중요하다.

 

 

 

 

Transcoding 은 트랜스먹싱처럼 컨테이너만 변경하거나, 전송 프로토콜만 변경하는 것이 아닌, 실질적인 데이터

즉 비디오와 오디오가 변경된다. **화질, 음질 변경 될 수 있음** 

그렇게 변경하는 가장 큰 이유는 사용자가 느끼는 품질 향상을 위해 가장 많이 사용하기도 하고, 사용자에게 동영상이 가기 전에 어쩔 수 없이 변경해야하는 경우도 있다. 

 

ex)

MP4 Container                             -->                AVI Container
H.264 Video codec                                            VP9 Video codec
AAC-LC Audio codec                                         Opus Audio codec 

하지만 트랜스코딩을 위해서는 서버 성능이 상당히 많이 필요하고, 라이브 스트리밍의 모든 과정에서 지원하는 코덱들이 있으면 서버 리소스를 소모하면서까지 바꿀 필요는 없다고 보여진다 .

 

 

RTMP

• 비디오 코덱 : H.264, VP8, VP6, Sorenson Spark ®, Screen Video v1 및 v2
• 오디오 코덱 : AAC, AAC-LC, HE-AAC + v1 및 v2, MP3, Speex, Opus , Vorbis

HLS

• 비디오 코덱 : H.265, H.264
• 오디오 코덱 : AAC-LC, HE-AAC + v1 및 v2, xHE-AAC, Apple Lossless, FLAC

Android

• 비디오 코덱 : H.263, H.264 ( BP,MP) , H.265 HEVC, MPEG-4 SP , VP8, VP9
• 오디오 코덱 : AAC LC, HE-AACv1(AAC+), HE-AACv2(개선된 AAC+), AAC ELD(개선된 저지연 AAC), AMR-NB, AMR-WB, FLAC, GSM, MIDI, MP3, Opus, PCM/WAVE , Vorbis

IOS

• 비디오 코덱 : H.265, H.264
• 오디오 코덱 : AAC-LC, HE-AAC + v1 및 v2, xHE-AAC, Apple Lossless, FLAC

 

---

따라서 겹치는 코덱을 선정해서 TransMuxing을 통한 RTMP -> HLS 과정만 거치게 된다면 서버 리소스를 낭비하지 않고 사용할 수 있다고 판단했다. 

 

플랫폼들에서 겹치는 코덱

• 비디오 코덱 : H.264
• 오디오 코덱 : AAC-LC, HE-AAC + v1 및 v2

 

비디오 코덱은 현재 기준으로 H.264 코덱이 모든 프로토콜, 플랫폼에서 지원하고 있었고

오디오 코덱은 AAC 코덱 종류들이 겹쳤다. 

 

---

의문점 1 

하지만 RTMP -> 미디어서버 -> HLS 로 변경

즉 미디어서버가 미디어 컨텐츠들을 재패키징 하는 과정에서 H.264 -> H.265(더 효율적인 압축방식) 으로 Transcoding을 했을 때 서버가 리소스를 더 소모하더라도, 사용자 입장에서 드라마틱한 동영상 품질 변경이 있으면 고려해볼 수 있지 않을까? 라는 생각이 들었다.

 

그래서 H.264 말고도 가장 겹치는 부분인 H.265 코덱으로 트랜스코딩 했을 때의 서버 리소스 소모가 얼마나 달라지는지 확인해봤다.

 

실험논문을 하나 찾았는데 여섯개의 영상이 있었다. 

 

 

 

CPU core는 4개라고 되어있었지만 실제로 cpu 모델명을 검색해보니 코어는 2코어로 나왔다. 2코어 4쓰레드

 

화질이 그렇게 좋은 영상들은 아님에도 불구하고 2코어짜리 cpu의 사용률이 너무 높았다. 

하지만 Netflix에서 개발한 동영상을 압축했을때의 품질을 비교해서 점수를 메기는 부분은 

크게 차이가 나지 않았다. 

h.265가 가장 짧은 5초짜리 영상인 4번을 인코딩하는데 30초가 걸렸다. 

레이턴시가 중요한 라이브 스트리밍에서 사용하는건 불가능한 코덱인 것 같았다. 

 

해당 논문의 내용이 더 궁금하다면 

https://www.researchgate.net/publication/345436890_Hardware_and_software_video_encoding_comparison

(PDF) Hardware and software video encoding comparison

가서 읽어봐도 h.264와 h.265 비교하기에는 좋을 것 같다. 

 

따라서 Transcoding 을 하려면 2코어로는 부족하고 훨씬 더 높은 성능의 CPU가 필요하다는 것을 확인했고, TransMuxing으로 H.264 코덱으로 인코딩된 미디어 컨텐츠를 RTMP -> HLS 로만 재패키징 하는게 맞다고 판단했다. 

 

그래서 최종 비디오코덱은 H.264 로 선정했다. 

 

 

오디오 코덱

AAC, AAC-LC, HE-AAC + v1 및 v2 가 모든 플랫폼에서 기본적으로 지원하는 오디오 코덱이었다. 

 

 

 

안드로이드 인코딩 권장사항에 AAC-LC 가 있어서 우리 서비스는 딱히 오디오가 중요하지 않기 때문에 AAC-LC 로 선정했다.