DAN24 - 인공지능의 마법으로 실시간 라이브 인코딩에 날개를 달다

https://tv.naver.com/v/67446801

플레이 네이버(PLAY NAVER)

 

 
 

AI 인코딩 최적화가 필요한 이유

 
네이버tv, 스포츠, 치지직, 클립 등 다양한 서비스에서 VOD 사용: 비약적인 비용 증가
네이버 클라우드에서의 VOD 처리 절차

• 다양한 기기에서 VOD 영상 업로드
• CODEC, container 등의 변환
• CDN으로 다양한 환경에서 재생 지원.

이 중 가장 많은 서버자원, 시간, 리소스가 필요한 부분은 Encoding. 고해상도, 고화질 영상일수록 증가. 따라서

• 자체 분산인코더 개발
• CDN, storage 비용 개선을 위한 인코딩 용량 줄여서 저장 / 전송 최적화를 연구중

일반적으로는 영상의 비트레이트가 높을수록 영상 품질이 좋아짐.

• 영상 복잡도가 낮은 영상일수록 비트레이트 높일 때 화질개선 효과가 확실함.
• 복잡도 높은 영상일수록 단위 비트레이트 상승 대비 화질개선 효과가 적다

일정 수준 이상의 비트레이트 이상에서는 화질을 높여도 사람 눈으로 구별이 어려워진다. 영상 간 차이가 크게 나지 않음.

• 예시의 경우, 3Mbps로 인코딩한 것과 2Mbps로 인코딩한 것의 화질차이가 눈으로 구별이 어렵다.
• 3Mbps가 오히려 낭비되는 용량을 만든 셈

 
일반적으로, 움직임이나 디테일이 많은 영상일수록 인코더가 처리해야 할 정보가 많아짐 = 더 많은 비트레이트가 필요하다.

• 즉, 인지 가능 경계선에서 복잡도가 낮은 영상은 더 낮은 비트레이트를 사용해서 인코딩해도 문제가 없다

 
그럼 적정 화질은 어떻게 찾나?

• 인코더에서 제공하는 옵션은 상대적인 화질 손실 (QP) 정도.
  • 같은 손실 레벨로 인코딩했을 때, 영상특성에 따라 품질이 크게 떨어지는 경우가 생길 수 있음
• 적정값을 찾기 위해 여러 번 인코딩한다?
  • 한 개 해상도 인코딩에 최소 3회는 필요하다 (QP 23 -> 18 -> 20, 23 -> 17 -> 16)
  • 정확한 옵션은 찾을 수 있으나, 인코딩 비용이 과하게 증가.

AI 기반으로 적절한 인코딩 옵션값을 예측하려는 시도.

• 1회 인코딩 횟수 / 인코딩 가용량은 유지한 채
• 한 번의 inference로 목표 화질을 만족하는 최적의 옵션을 예측한다.

AI 인코딩 최적화를 위한 여정: VOD AI 인코딩 최적화 기술

영상 특성은 매우 다양함. 정적인 영상 / 정적이지만 배경이 디테일한 영상 / 움직임과 변화가 많은 영상.

• 영상 특성 / 최적의 옵션을 연결할 수 있는 Function이 필요함.
• feature도 많고 옵션도 많아서, 단순한 구조의 모델이 나오긴 어렵다

 

• 딥러닝으로 다양한 VOD의 feature / 최적옵션 간 relation을 학습
  • feature 정보도 딥러닝으로 자동 추출
• feature 추출에 강점인 CNN, 시간 변화에 따른 데이터 간 관계 추출에 강점인 RNN으로 feature 추출
• option class 간 관계를 딥러닝으로 학습

당시에 고려한 option: CRF 선택

• QP: frame / block 단위로 조절할 수 있지만, 결과물의 화질이나 크기를 알 수 없다
• CBR / VBR: 용량은 일정하지만 화질이 들쭉날쭉함.
• CRF: x64, 265에서 사용되는 방식으로, 타 옵션 대비 균일한 화질 + 용량 효율적임.

 
화질을 수치화하기 위한 옵션으로는 VMAF 선택.

• 인간의 지각 관련 부분을 가장 잘 반영하는 것으로 알려진 옵션
• 가로축 / 세로축이 선형일수록 사람의 화질 평가와 Quality Metric 간 유사도가 높음.

 
모델 학습: 입력 영상 segment의 frame 이미지를 입력으로 받아서 -> 최적 option class로 구분하는 End to End 트레이닝

• 처음에는 CNN의 imageNet 기반 pretrained model의 feature를 쓰려고 했는데, 성능 향상에 제약이 있었음
• 그래서 CNN 포함한 전체 모델을 하나의 loss function으로 학습.

이미지 분류 -> VOD feature 분류 모델로 가중치 학습한 셈

모델 적용: 매 초마다 대표 frame 이미지 추출, 3초 단위로 frame하는 예시

• 3초 구간마다 대표 이미지들을 모델에 입력
• segment에 최적인 option 도출

예측된 옵션으로 인코딩하는 식.

단계적으로 도입이 확대될수록 CDN 사용량이 감소하는 것이 확인됨.

Live 영역으로의 확대

네이버는 자체 개발한 Live Cloud에서 수많은 라이브 스트리밍 서비스를 제공하고 있음.

• 라이브 영상 시스템의 경우, 영상 전송에 쓰이는 CDN 비용이 크게 발생.
• 화질을 유지하면서 영상 크기를 줄이는 방법?
  • 화질 대비 압축률이 높은 CODEC: 높은 연산량이 필요함. 인코딩의 실시간성을 유지하려면 더 많은 가용서버가 필요함. (인프라 확장)
  • 따라서 h.264 CODEC을 최적화하는 식으로 접근

라이브 스트리밍의 핵심은 Low Latency. 스트리머가 보는 영상과 시청자가 보는 영상 간 시차가 최대한 적어야 한다.

• 따라서 인코딩에 드는 latency를 최대한 줄이는 방향으로 최적화해야 한다

VOD에 AI 적용했던 접근법은 'latency'가 최우선이 아니기 때문에, 라이브 스트리밍 영상에 활용할 수는 없었음.

• 영상을 segment 단위로 추출 <- buffering 발생
• AI로 최적화질 예측
• 최적 화질로 segment 인코딩

buffering이 초 단위로 발생. 라이브 스트리밍은 수십 ~ 수백ms의 latency여야 함.

라이브 스트리밍은, 특성상 장면 변화가 급격하지는 않은 편.

• 예컨대 위 예시의 경우 장면이 바뀌는 기준을 5가지로 구분할 수 있음.
• 최적의 인코딩 옵션 예측 시점 / 적용 시점이 다르더라도, 비슷한 장면이 지속된다면 동일한 옵션을 도입할 수 있다

장면 기반 인코딩: 동일한 장면에는 같은 인코딩 화질 옵션을 적용한다.

• 넷플릭스 등 VOD 분야에서는 사용되지만, 라이브 스트리밍에서는 아직 선례가 없음
• 도입하려면 크게 두 가지가 필요함
  • 장면의 변화를 정확히 판단하는 기술
  • 장면별로 최적의 옵션을 예측 / 적용하는 기술

• 장면 변화를 판단하는 기술: 자체 개발
• 최적의 옵션 예측 / 적용 기술: VOD AI 개발에 썼던 리소스 (데이터, 모델, 학습환경...) 최대한 활용
  • 라이브 인코딩 환경에 맞도록 개선

목표: Live latency 최소화, 인프라 비용을 최대한 덜 쓰도록.

최종 구상

• 라이브 인코딩에서 새로운 장면이 시작 -> 초반 수 초 분량을 샘플링해서 AI 모델에 inference
  • 버퍼링 수행 + frame을 즉시 encoder로 전달
• 최적 옵션을 받으면, 동일한 장면에 최적 옵션을 encoder에 적용

장점: inference를 위한 frame buffer를 encoder가 대기하지 않음 -> 인코딩에서의 지연은 발생하지 않음.

• 단, 최적 옵션을 encoder에 적용하는 시점에서 지연이 발생할 수 있다.

아이디어의 구체화

• 장면 변화를 어떻게 판단할 것인가?
• 어떤 인코딩 옵션을 어떤 기준으로 최적화할 것인가?
• 구간별 최적의 인코딩 옵션은 어떻게 도출할 것인가?

장면 변화를 어떻게 판단할 것인가?

'장면'이란 유사한, 연속된 프레임의 모음.

• 프레임 간 유사도 측정 -> 유사도가 바뀌는 지점을 판단해야 한다.
• 일반적인 방법으로는 구별이 쉽지 않다.
  • 픽셀값 차이 감지 방식: 점진적으로 바뀌는 라이브 영상에는 정확하지 않음
  • 정확도가 높은 방식은 연산량이 높고, 여러 프레임을 참조하는 형태라서 인코딩 지연이 발생함.

낮은 연산량 + 인코딩 연산과정에 포함했을 때 가용량에 영향을 미치지 않으며, 장면 변화를 적절하게 탐지하는 것이 필요하다

영상에서

• 각 frame의 특징을 확인할 수 있는 feature를 빠르게 추출하고
• 짧은 단위 길이로 feature 비교하는 방식을 사용함.
  • 사용한 feature는 크게 두 가지. 프레임 내 복잡도 (Spatial Complexity. SC) / 프레임 간 복잡도 (Temporal Complexity, TC)
• 추출법: frame을 block 단위로 분할 -> 주파수 영역으로 변환.
  • 영상 압축은 주파수 도메인에서 수행되므로, 주파수는 압축 결과물과 관련이 높은 feature.

주파수는 픽셀 값을 직접 이용하는 것보다는 느리지만, 라이브 인코딩에 포함할 만한 속도가 나오도록 SIMD 등의 최적화 기법을 적용해서 구현.

 
가로축은 frame 번호, 세로축은 frame의 feature값.

• 장면 변화 지점과 TC, SC 변화에는 높은 상관관계가 있었다.

장면 감지 로직은 직접 개발 + 유효한 영상 구간을 감지할 수 있도록 했다.

• 예컨대 지나치게 복잡한 영상구간의 경우, 인코딩 화질 옵션값보다는 최대 비트레이트 제한 옵션값의 영향을 받는다.
• 화질 옵션값이 유효한 구간에서만 인코딩 최적화 동작을 수행할 수 있게끔 했다.

어떤 인코딩 옵션을 어떤 기준으로 최적화할 것인가?

• 화질 판단에 기준이 될 필드는 CRF 사용.
• 목표 화질 기준으로는 영상압축 분야에서 사용하는 JND 개념을 참고함.
  • JND란, 시청자가 차이를 느끼지 못할 만큼의 화질 차이를 의미함.
  • 영상마다 달라서 일률적으로 정의할 수는 없으나, 일반적으로는 VMAF 기준 3~6 정도의 차이 값으로 알려져 있다.
• 네이버는 직접 실험해서 자체적인 VMAF 값 기준 JND 범위를 결정하고, JND 범위 내에서 화질을 세부 조정하는 추가 실험을 거쳐 목표 화질 값을 결정함.

장면 구간별 최적의 인코딩 옵션은 어떻게 도출하는가?

AI모델은 VOD용 모델 그대로 쓰되, 학습 데이터를 라이브 영상 서비스에 특화시켰음.

• 모든 학습 데이터는 단일 장면으로 생성.
• 모델 input으로 들어오는 이미지 생성과정을 라이브 인코딩 동작과정에 맞게 최적화.

 
구현한 PoC.

• 새로운 장면이 감지되면, inference를 위한 segment buffer에 저장 + Encoder에도 장면 전달.
  • 인코딩 지연을 최소화한다.
• 동일 장면이 지속되어 inference 가능할 만큼 buffer에 누적되면, AI 모델로 전달.
  • AI 모델은 최적 encoding option을 응답한다
• 지속되는 동일 장면에는 AI 모델에게 받은 최적 인코딩 옵션을 계속 유지한다. 동일 장면이므로 frame buffer하지는 않음.
• 새로운 장면이 감지될 때까지 반복한다.

기능 자체는 가능함. 추가로 고려할 부분은

• AI 모델이 최적옵션을 전달해주기 전에 적용할 기본 화질 옵션은?
• 다양한 예외상황
  • frame 샘플링 도중에 장면이 전환되는 경우
  • 예측옵션을 적용하려는 시점에 장면 변환이 발생하는 경우
  • ...

개발 및 적용

데이터 구축: 학습데이터 생성에 사용할, 수 초 분량의 짧은 영상 segment.

• 자체 보유 데이터 중 라이브 영상 특성과 비슷한 것들 사용. segment는 단일 장면으로 구성.
  • sc와 tc값을 사용해서 단일 장면으로 segment 구분했음.
  • = segment의 tc / sc값을 frame 단위로 구해서, 분산 값이 일정 수치 이하인 경우를 '단일 장면'으로 정의함.
• '분산'을 사용했기에 단순한 영상 / 복잡한 영상 구분없이 다양하게 확보 가능.

 
적 encode option인 ground truth CRF 값 구하기

• 목표 화질 결정
  • 다양한 라이브서비스 샘플 영상의 VMAF 분포 확인 -> 전체 화질을 대표할 수 있는 VMAF 선정.
  • 서비스화질의 JND 범위 내에서 화질 조정해가며 시각 테스트 -> 화질 단계별 비트레이트 절감률 고려해서 목표 VMAF 선택.

학습데이터 생성: 목표 화질을 만족하는 라벨 데이터 생성하기

• 단위 영상 segment들을 목표화질로 인코딩하기 위한 ground truth CRF 값 구하기...
  • 하나의 영상을 CRF 값 바꿔가면서 반복 인코딩해야 하기 때문에, 매우 오래걸리는 작업.
  • 이진탐색 / interpolation 기법 등으로 반복 인코딩 횟수를 최소화.
  • 이 과정에서 학습에 부적합한 샘플도 필터링됨

학습데이터는 많은 연산이 필요... 수 개월까지도 걸리는 작업. 이걸 위한 별도 시스템 구축이 필요했음. MLOps 솔루션으로 자동화

• kubeflow pipeline으로 전처리 시스템 구축.
  • ML 전체 개발과정을 파이프라인으로 자동화할 수 있는 k8s 기반 MLOps 솔루션
  • 각 단계가 container로 수행되므로 배포 / 운영이 쉽고, 여러 파이프라인 프리셋을 제공함.
• 목표: 최대한 빠르게 데이터 생성 작업이 진행되도록 한다.
  • kubeflow는 하나의 컴포넌트가 끝나야 다음 컴포넌트로 전체 작업이 전달되는 batch 방식... 다수의 영상데이터를 빠르게 처리하기에는 부적합.
  • component 사이에 queue 삽입해서, batch가 아니라 streaming 방식으로 처리 가능하도록 구현함.
  • 오래걸리는 작업에는 많은 리소스 할당해서 작업에 드는 시간을 줄였다.

모델 파라미터 최적화

• 학습 입력데이터: 각 영상 segment별 <sample image>, ground truth CRF 값 형태로 주어진다
  • 입력 이미지의 샘플링 개수는 모델 정확도, 동작시간, 학습 소요시간과도 연관이 있음.
  • 해상도는 224 ~ 560, 개수는 10~20장까지 변경해가며 조합 테스트. 모델 동작속도와 학습시간을 최적화할 수 있는 조합 선택.

이 과정에서 모델 정확도도 8%가량 개선되었는데

• 학습 데이터를 장면 단위로 구성
• 학습데이터 종류를 다변화 / 각 클래스별 학습 데이터 개수를 비슷하게 맞춤 / 모델 입력이미지 화질 개선... 등

적용 결과, 기존 AI모델보다도 inference 횟수가 1/4로 감소.

• 라이브 동영상 클라우드에 적용할 때 필요한 인프라 비용을 최소화했다.

모듈화해서, encoding pipeline에 쉽게 도입할 수 있도록 한다.

• 기존 시스템은 낮은 인코딩 리소스 / 시스템 사용률에 초점을 맞춰 개발됨.
• 장점을 유지하기 위해, 모든 기능은 인코딩 과정과 별개로 동작하도록, 비동기식으로 구현함.
• 비동기 방식이라서 인코딩 지연은 증가하지 않지만, 인코딩 옵션이 적용되는 시점이 1프레임 정도는 지연될 수 있다.

모듈 (AI Optimizer)은 인코더 바로 앞단에 위치.

• encoder에 최적 CRF값을 전달. encoder는 인코딩 중단 없이 바로 적용.

VOD 적용 기술을 라이브에도 유사하게 적용한 거 같지만

• 기존 시스템 강점 유지
• 라이브영상 특징에 맞는 최적화 기술 도입

전반적인 동작 방식 / 세세한 부분의 최적화 작업이 필요했다.

2024년 하반기부터 라이브 서비스에 적용됨. 비트레이트 15% 이상의 개선으로 CDN 비용 절감.

• 대표적인 사용자 QOE 지표 비교: 적용 시점부터 지속적으로 개선되는 경향성을 보임.
  • initial time: 재생요청 후 실제 재생까지 걸리는 시간
  • buffering time: 버퍼링 이벤트 발생 시, 얼마나 지속되었는지

 
앞으로도 개선 예정.

• 서비스 확대 적용 - 장면전환이 많은 라이브 컨텐츠 대상으로도 확대
• 인코더 확대 적용 - HW (GPU) 인코더
• CODEC 확대 - H.264 외 차세대