[O+T] 영상 품질 기반 개선기 (1. 올바른 영상 변환과 품질 측정 방식)

영상 트랜스코딩 - VMAF 품질 측정 과정을 거치며 마주한 문제를 해결하는 과정에 대해 적어놓은 글입니다. 문제 해결 중심으로 글이 전개되므로 영상에서 사용하는 개념에 대한 설명이 적게 들어가 있습니다!

[O+T] 영상 품질 측정하기 (2. Per-Title-Encoding 적용)

1편: https://yestomo.tistory.com/25 [O+T]: 영상 품질 측정하기 (1. 올바른 영상 변환과 품질 측정)영상 트랜스코딩 - VMAF 품질 측정 과정을 거치며 마주한 문제를 해결하는 과정에 대해 적어놓은 글입니다.

yestomo.tistory.com

0. 개요

영상 업로드와 스트리밍을 제공하는 OTT 서비스 프로젝트에서 트랜스코딩 서버를 개발했습니다. FFmpeg으로 HLS 변환을 완료하면 360p, 720p, 1080p 결과물은 생성되지만, 막상 해당 영상이 '잘 변환되었는지' 판단하기는 어려웠습니다.

눈으로 봤을 때 큰 차이를 느끼기 어려웠고, 모든 영상을 하나하나 사람이 볼 수도 없었습니다. 영상 원본과 트랜스코딩 후 변환된 영상을 수치로 비교할 수 있으면 좋겠다고 생각했고 이를 기반으로 내가 정말 잘 변환했는지, 더 좋은 방법이 있는지 알 수 있을 것이라고 생각했습니다.

이번 글에서는 트랜스코딩 결과물에 대한 최적화(2편, Per-Title-Encoding) 전 영상 변환 시 기본적으로 적용해야 할 요소들을 다룹니다. 품질을 측정하며 이상한 숫자가 발견되면 원인을 찾고 정말 문제인지 알아보며 진행했습니다.

1. 영상 품질 측정

1-1.지표 선택

화질을 수치화하는 방식으로 보통 세 가지가 사용됩니다.

	PSNR (픽셀 오차)	SSIM (구조적 유사도)	VMAF (사람 체감 예측)
세대	1세대	2세대	3세대
무엇을 재나	픽셀이 얼마나 다른가	구조(윤곽·명암 패턴)가 얼마나 비슷한가	사람이 몇 점이라 느낄까
원리	원본 ↔ 압축본의 수학적 픽셀 오차	사람은 개별 픽셀이 아닌 '전체 형태'로 인식한다는 점 활용	사람이 직접 매긴 평가를 학습해 예측 (여러 지표를 fusion)
결과 형태	dB (높을수록 좋음)	0~1 (1에 가까울수록 좋음)	0~100 점수
사람 체감과의 일치	낮음 (괴리 큼)	중간	높음
약점	픽셀 오차 작아도 눈엔 거슬리거나 그 반대	픽셀보단 낫지만 여전히 체감과 거리있음	결국 예측값임

낮은 세대일수록 계산이 빠르고 단순하다는 장점이 있지만, 그 수치가 영상 품질을 대표하기 부정확하다는 단점이 있습니다. 이번 작업의 목표는 그저 픽셀 차이를 줄이는 것이 아니라 트랜스코딩 후 사용자가 체감하는 품질을 확인하는 것이기 때문에 VMAF을 선택했습니다.

추가로 실제로는 전체 영상에 대한 검수는 PSNR과 SSIM으로 빠르게 처리하고, 최종 품질 판단은 VMAF로 하는 방식으로 섞기도 한다고 합니다.

1-2. 영상 고르기

품질 측정 대상은 하나의 영상만 사용하지 않기로 했습니다. 영상마다 움직임의 양, 장면 전환 빈도, 질감, 조명, FPS 특성이 다르기 때문에 한 영상에서 좋은 결과가 나왔다고 해서 기존 트랜스코딩 로직이 항상 안정적이라고 보기 어렵기 때문입니다.

저는 저/중/고 복잡도로 나눠 서로 다른 특성의 영상을 세 개 준비했습니다. 움직임은 적은 애니메이션을 복잡도가 낮은 영상으로, 액션이 많은 실사 CG 영상을 고복잡도 영상으로 골랐습니다.

Big Buck Bunny (낮은 복잡도): 밝은 애니메이션 영상
Meridian (중간 복잡도): 높은 FPS 특성을 가진 영상
Tears of Steel (높은 복잡도): 장면 전환, 실사, 어두운 장면 등 압축 난도가 높은 영상

2. 기존 트랜스코딩 방식으로 vmaf 측정

먼저 기존 트랜스코딩 로직으로 생성된 HLS 결과물을 기준으로 VMAF를 측정했습니다. 측정 대상은 Big Buck Bunny, Meridian, Tears of Steel 세 영상이었고, 각 영상마다 360p, 720p, 1080p 결과물을 비교했습니다.

2-1. 측정 방식

원본(4K)과 변환본의 해상도가 다르기 때문에 원본을 HLS 결과물의 실제 해상도로 낮춘 뒤 비교했습니다. 예를 들어 720p 결과물을 평가할 때는 원본도 720p 기준으로 맞춘 뒤 VMAF를 계산했습니다.

넷플릭스는 VMAF 측정의 국룰?로 HLS 결과물을 원본 해상도에 맞추는 Upscale 방식을 사용하라고 합니다. 하지만, 지금 저의 측정 의도는 최종 시청 품질을 판단하기 위한 목적이 아닌 현재 트랜스코딩 결과물의 압축 품질과 측정 과정에서 발생할 수 있는 문제 신호를 확인하기 위한 진단용 측정이기 때문에 스케일로 인한 점수 저하는 배제하고자 Downscale로 측정했습니다. 이는 같은 해상도 안에서 '현재 인코딩 결과가 얼마나 원본 정보를 유지하는가'를 진단하기 위함입니다

2-2. 측정 결과

저/중 복잡도 영상은 VMAF 점수가 정상으로 나타났지만, 고복잡도 영상은 점수가 이상하리만치 낮았습니다. 하위 5% 구간의 점수가 0이 나타난 것을 보아 상당 구간에서 이상치가 발생한 것임을 알 수 있었습니다.

각 영상의 평균 VMAF 점수를 표로 보면 아래와 같습니다.

영상	360p	720p	1080p	해석
Big Buck Bunny	96.43	96.92	97.17	정상
Meridian	95.68	95.07	94.52	정상
Tears of Steel	49.84	40.23	35.55	비정상

문제를 두 갈래로 나누기

결과만 보면 고복잡도 영상의 트랜스코딩 품질이 크게 낮다고 판단할 수도 있지만, 품질 측정 과정에서 오류가 발생했을 수도 있습니다. VMAF는 원본과 변환본을 비교하는 방식이기 때문에, 비교 조건이 어긋나도 점수가 낮게 나올 수 있기 때문입니다.

따라서 문제를 두 갈래로 나누어 보기로 했습니다.

첫 번째는 트랜스코딩 산출물 자체의 문제입니다. 트랜스코딩 과정에서 적절한 보정이 이뤄지지 않아 segment와 keyframe 구조가 불안정하다면 VMAF 이전에 결과물 자체를 먼저 보완해야 합니다.

두 번째는 VMAF 측정 방식의 문제입니다. timestamp, frame alignment, FPS 처리 방식이 맞지 않으면 실제 화질이 나쁘지 않아도 서로 다른 프레임끼리 비교되어 점수가 낮게 나올 수 있습니다.

실제 화질이 나쁜 것인지, 아니면 비교 조건이 잘못된 것인지를 분리해서 '트랜스코딩 변환'과 'VMAF 측정' 과정에서의 오류로 나눠서 살펴보았습니다.

먼저 HLS 산출물에서 확인된 문제를 정리하고, 그 다음 VMAF 측정 방식에서 점수를 왜곡할 수 있는 요소를 분리해 확인했습니다.

3. 트랜스코딩 산출물 문제

앞서 분리한 두 문제는 완전하게 떨어지지 않습니다. 특히, 고복잡도 영상의 낮은 점수에는 측정 왜곡과 산출물 문제가 섞여 있었습니다. 그래서 먼저 점수가 몇 점이든 상관없이 결과물(HLS) 자체에서 객관적으로 확인되는 구조적 결함만 먼저 정리하기로 했습니다. '그래서 실제 화질이 낮은가?'라는 판단은 측정 왜곡을 걷어낸 뒤 진행해야 또다른 오류로 인해 엉키는 문제가 없기 때문입니다.

즉, 산출물 문제는 '결과물이 원래부터 가지고 있던, 측정과 무관한 문제'입니다.

3-1. master.m3u8 표기와 실제 HLS 해상도가 달랐다

첫 번째로 확인한 문제는 master.m3u8에 표기된 해상도와 실제 HLS 결과물의 해상도가 다르다는 점이었습니다.

Big Buck Bunny와 Meridian은 master에 표기된 해상도와 실제 HLS 해상도가 일치했지만, Tears of Steel은 달랐습니다.

영상	화질	master 표기	실제 HLS 해상도
Tears of Steel	360p	640x360	806x360
	720p	1280x720	1614x720
	1080p	1920x1080	2420x1080

Tears of Steel은 원본 영상의 화면 비율이 프로젝트 정책 16:9와 다른 21:9였고, 트랜스코딩 과정에서 비율을 유지하며 리사이징되었습니다. 그 결과 실제 출력 영상은 806x360, 1614x720, 2420x1080처럼 생성되었습니다.

문제는 실제 출력은 비율을 유지해 정상적으로 생성되었지만, master에는 고정된 16:9 해상도처럼 기록되고 있었다는 점입니다.

불일치가 발생한 이유

두 값이 서로 다른 출처에서 나왔기 때문입니다.

기존 방식은 360p, 720p, 1080p 같은 화질 enum을 기준으로 master 정보를 구성하고 있었습니다. 실제 영상은 ffmpeg의 scale=-2:height 명령어로 만들어지며, 높이만 맞추고 너비는 원본 비율대로 자동 계산합니다. 일반적인 16:9 영상에서는 큰 문제가 없어 보일 수 있지만, 입력 영상의 화면 비율이 다르면 실제 출력 해상도는 enum에 고정된 값과 달라질 수 있습니다.

반면, 매니페스트(master.m3u8) 표기는 코드에 박힌 고정값(16:9를 가정한 640 × 360 등)을 그대로 적었습니다. 실제 출력물을 다시 확인하지 않았습니다.

즉, '영상을 만드는 쪽'과 '목록에 적는 쪽'에서 각기 다른 것을 바라보도록 로직이 작성되어 있었기 때문입니다.

왜 문제인가

처음에는 단순한 metadata 표기 오류처럼 보였습니다. 하지만 HLS에서 master playlist는 플레이어가 각 화질을 선택할 때 참고하는 정보입니다. master에 적힌 해상도와 실제 미디어의 해상도가 다르면, 플레이어와 모니터링 도구는 실제 출력과 다른 정보를 기준으로 판단하게 됩니다.

또한, VMAF 측정에서도 혼란이 생길 수 있습니다. 측정은 실제 HLS 해상도를 기준으로 진행했지만, master에 기록된 값과 실제 값이 다르다면 '어떤 해상도의 결과물을 평가하고 있는가'를 문서와 리포트에서 명확히 설명하기 어려워집니다.

ABR 환경에서 플레이어는 master의 해상도·대역폭을 보고 네트워크 상황에 맞는 화질을 고름. 표기가 틀리면 잘못된 화질을 선택할 수 있음.
측정·리포트에서 '해상도'의 의미가 흔들림. 640 × 360을 비교 기준으로 삼으면 실제 806 × 360 결과를 잘못 평가하게 됨.

해결

매니페스트를 고정값이 아니라 실제 출력물을 다시 probe한 값 기준으로 생성하는 것입니다. 원본의 비율을 살리기로 결정했다면, 해당 비율에 맞춰 스케일된 실제 값을 매니페스트 파일에 작성합니다.

기존 방식	보완 방향
360p, 720p, 1080p enum 기준으로 master 작성	실제 HLS output metadata 기준으로 master 작성
예상 해상도를 기록	실제 생성된 해상도를 기록
코드가 의도한 결과를 기준으로 설명	FFmpeg이 실제 만든 결과를 기준으로 설명

이렇게 해야 HLS 산출물과 metadata가 서로 일치하고, 이후 품질 측정 리포트에서도 어떤 결과물을 비교했는지 명확하게 설명할 수 있습니다.

3-2. 키프레임/GOP가 고정되어 있지 않다

HLS는 단일 영상 파일이 아니라 여러 segment와 playlist로 구성됩니다. 따라서 파일이 생성되었다고 해서 곧바로 안정적인 HLS 결과물이라고 볼 수는 없습니다. 특히, ABR 스트리밍에서는 segment 길이, keyframe 위치, rendition 간 segment 정렬이 중요합니다. 화질 전환은 보통 segment 경계에서 발생하기 때문에, keyframe과 segment 구조가 어긋나면 seek나 화질 전환 시점에서 문제가 생길 수 있습니다.

키프레임은 혼자서 완전히 디코딩되는 프레임이고, GOP(Group of Pictures)는 키프레임 하나부터 다음 키프레임 직전까지의 묶음을 말합니다.

하지만, 기존 ffmpeg 명령에는 키프레임 간격을 정하는 옵션(-g, -keyint_min, force_key_frames)이 하나도 없었습니다. 키프레임을 언제 넣을지를 인코더 자율에 맡긴 셈입니다.

이렇게 되면 세그먼트는 시간(ex. 6초)으로 자르는데, 키프레임 간격이 제멋대로면 세그먼트 시작점이 키프레임과 맞지 않습니다. 그래서 화질 전환(ABR) 시 깨지거나, 특정 시점 이동(seek)이 부정확하거나, 세그먼트 단위로 영상을 다룰 때 경계가 어긋납니다.
측정 관점에서도 세그먼트 경계가 들쭉날쭉하면 구간 단위 분석이 불안정합니다.

해결

GOP를 일정 간격(예: 2초)으로 고정하고, 장면 전환마다 키프레임을 추가로 넣지 않도록(closed GOP) 만들어 세그먼트 경계와 키프레임을 정렬합니다.

저는 GOP를 2초로 설정했는데, 중요한 건 세그먼트 길이의 약수로 설정하는 것입니다. 세그먼트의 경계와 키프레임이 일치해야 영상을 끊김없이 독립적으로 제공할 수 있기 때문입니다.

추가로 세그먼트 길이는 6초로 설정했습니다. 일반적으로 HLS에서 6초를 많이 사용한다고 하며, 길이에 따라 장단점이 존재합니다. 세그먼트가 길면 압축 효율이 좋고 클라이언트가 적은 요청으로 재생할 수 있다는 장점이 있지만, 네트워크 상황에 민감하게 반응하지 못 한다는 단점이 있습니다. 반대로 세그먼트 길이가 짧으면 네트워크 상황에 따라 빠르게 화질을 변경할 수 있지만, 압축 효율이 좋지 않습니다.

또한, independent_segments를 설정하여 각 세그먼트가 독립적으로 디코딩 가능하도록 했습니다. 결국 세그먼트 단위로 전송되고 플레이어에서 재생되기 때문에 하나의 세그먼트만 있어도 그만큼의 영상을 시청할 수 있도록 하기 위함입니다.

4. VMAF 측정 방식 문제

HLS 산출물에서 확인된 구조적 문제를 정리한 뒤에는 VMAF 측정 방식 자체를 확인했습니다. 여기서 확인하려는 것은 “영상이 정말 나쁜가?”가 아니라 “같은 장면끼리 비교하고 있는가?”입니다.

앞에서 본 측정에서 고복잡도(Tears) 영상의 VMAF 점수가 낮았습니다. 이에 대한 결과 지표를 중심으로 하나씩 원인을 파악하고 개선해보겠습니다.

4-1. 시도 1: 시작 시간 맞추기

측정 전 ffprobe로 원본과 HLS 출력의 정보를 확인했는데, 이를 바탕으로 살펴보니 HLS 결과물이 원본보다 늦게 시작했습니다(BBB 1.445초, Meridian 1.433초, Tears 1.463초). VMAF는 '원본 0초 프레임 ↔ 변환본 0초 프레임'을 비교한다고 가정하는데, 한쪽이 1.4초 밀려 있으면 같은 인덱스인데 다른 장면을 비교하게 되므로 정상적인 비교를 할 수 없습니다.

가장 먼저 시작 시점을 맞추는 필터 setpts=PTS-STARTPTS(각 입력의 첫 프레임을 0초로 당김)를 떠올려 바로 적용해봤습니다. 여기서 PTS는 간단하게 말하면 '이 프레임을 영상의 몇 초 시점에 화면에 보여줘야 하는가'를 나타내는 시간표입니다.

Tears에 적용하니 전체 영상 평균이 회복됐지만, 저복잡도인 BBB에서는 오히려 점수가 크게 떨어졌습니다. 흐르는 눈물을 닦고 제가 놓친 것이 무엇인가 고민해보았습니다.

세 영상 모두 start_time이 비슷한 1.4초였는데 결과가 갈렸으므로 start_time이 직접적인 원인이 아니었습니다.

찾아보니 setpts는 같은 장면을 찾아 맞춰주는 필터가 아니라 첫 PTS를 0으로 미는 필터였습니다. Tears는 그 밀림이 오차라 0으로 당기는 게 도움이 됐지만, BBB는 그 밀림 자체가 '원본이 정확히 몇 프레임 늦다'는 의미 있는 정렬 정보였습니다. 이 상태에서 setpts가 그 정보를 지워버리니, 오히려 어긋난 프레임끼리 비교된 것입니다.

진짜 기준은 디코딩된 첫 프레임의 PTS가 fps 프레임 격자(1/fps 간격의 눈금) 위 어디에 놓이는가이고, 모든 영상에 같은 보정을 적용하면 안 되었습니다.

4-2. 시도 2: 영상마다 다르게 정렬하기

FPS와 PTS

fps는 프레임의 시각(PTS)을 결정합니다.

fps = 초당 프레임 수 → 1프레임의 시간 = 1/fps (30fps면 0.033초, 24fps면 0.042초)
PTS = 그 프레임이 표시될 시각. CFR이면 프레임 N의 PTS = 첫 PTS + N × (1/fps)

프레임들은 1/fps 간격으로 시간축에 일정하게 놓입니다. 이 균일한 눈금이 프레임 격자입니다.

Offset이 정수냐 비정수냐

원본과 HLS는 같은 fps라 격자 간격은 똑같습니다. 다만 첫 PTS가 다르면 격자가 통째로 옆으로 밀리는데(offset), 이 밀림이 프레임 간격의 정수배냐 아니냐가 갈림길입니다.

BBB: offset 0.067초 = 30fps로 정확히 2.0프레임(정수) → 두 격자 눈금이 포개짐 → 1:1로 깔끔. 이 2프레임은 "원본이 2칸 늦다"는 정확한 정렬 정보라 보존해야 합니다. 따라서 이를 setpts로 지우면 깨지는 것입니다.
Tears: offset 0.003초 = 24fps로 0.072프레임(비정수) → 눈금이 영영 포개지지 않아 framesync가 경계에서 흔들립니다. 그래서 0으로 리셋(reset)해 양쪽을 같은 칸에 올리는 게 낫습니다.

보강: 프레임 끝단 오염 차단

시작점을 맞춰도 원본과 HLS의 프레임 수가 미세하게 다르면 끝부분에서 한 칸씩 밀려 비교가 오염될 수 있습니다. 그래서 측정 명령에 'shortest=1:repeatlast=0:eof_action=endall'을 넣어 짧은 쪽 기준으로 비교를 종료하고, 끝 프레임이 반복되며 점수를 왜곡하는 것을 막았습니다.

결과

정렬을 모두 보정하자 Tears의 중간값은 90점대, 평균은 70점대가 나타났습니다. 이는 아직 이상치가 존재한다는 신호였습니다.

처음 측정 결과인 '비정상 저점'의 상당 부분은 화질이 아니라 측정 정렬 문제였습니다. 다만, 정렬 후에도 Tears 평균은 72~77로 90 미만이 남았습니다. 남은 문제는 VMAF 측정 문제가 아닌 인코딩 결과물에 대한 보정이 필요했습니다.

5. CFR로 재인코딩

측정 자체를 신뢰할 수 있게 만든 다음, 3장에서 살펴본 산출물 결함(키프레임/GOP 등)을 실제로 고쳐 HLS를 CFR로 재인코딩하고 같은 규칙으로 다시 측정했습니다.

VFR 원본과 CFR 출력의 비대칭

VFR은 Variable Frame Rate, 즉 프레임 간격이 일정하지 않은 영상이고, CFR은 Constant Frame Rate, 즉 일정한 간격으로 프레임이 배치된 영상입니다. VMAF는 프레임 단위 비교이기 때문에, 한쪽은 VFR이고 다른 한쪽은 CFR이면 문제가 생길 수 있습니다.

Tears는 원본이 VFR(가변 프레임레이트)이었습니다(다른 영상은 원본이 CFR). reset_pts로 시작점은 맞췄지만, VFR 원본과 CFR 출력의 프레임 간격 자체가 달라 여전히 짝이 어긋났습니다.

기존 명령에는 출력 프레임레이트를 명시적으로 CFR로 고정하는 정책이 없었습니다. 그래서 입력이 VFR일 때 출력의 프레임 간격을 어떤 기준으로 정규화할지 파이프라인에서 결정하지 못했습니다. 이 점이 아래 두 문제를 일으켰습니다.

측정: 시작점을 맞춰도(reset) 프레임 간격이 불규칙해서, 중간 프레임들이 다시 한 칸씩 어긋납니다. 시작만 정렬해선 부족했던 이유입니다.
재생·세그먼트: 프레임 타이밍이 들쭉날쭉하면 세그먼트 경계 정렬과 플레이어 동기화에 불리합니다.

그래서 인코딩할 때 '-r {대표 fps} -fps_mode cfr'로 출력을 CFR로 고정했습니다. 입력이 VFR이어도 출력은 일정한 간격의 프레임으로 정규화하여 일정한 fps 격자 위에 놓이도록 만든 것입니다.

다만 VFR을 CFR로 바꾸는 과정에서는 프레임 복제나 삭제가 발생할 수 있습니다. 이는 원본의 시간 리듬을 일부 바꿀 수 있다는 단점이 있지만, HLS 재생 안정성과 VMAF 측정 일관성을 얻기 위한 선택이었습니다.

그리고 측정할 때는 원본도 출력과 같은 fps 격자에 올린 뒤 비교했습니다. 즉 “원본 VFR vs 출력 CFR”을 그대로 비교하지 않고, 양쪽을 같은 시간 격자에 맞춘 상태에서 VMAF를 측정했습니다.

이렇게 출력을 CFR로 만들어 두면, 측정할 때 원본(VFR)과 출력(CFR)을 같은 fps 격자 위에 올려 공정하게 비교할 수 있습니다.

그래서 원본과 출력을 모두 같은 24fps 격자에 올린 뒤 정렬하는 'symmetric_cfr_reset_pts'를 적용했고, Tears의 VMAF 점수는 360p 94.97 / 720p 95.52 / 1080p 95.56으로 정상 수준에 올라왔습니다.

아래 표로 정리해보았습니다.

영상	원본 프레임레이트	인코딩 (HLS 출력)	측정 (VMAF 정렬)
BBB	CFR 30fps	-fps mode cfr -> CFR 30fps	preserve_pts (PTS 보존)
Meridian	CFR 59.94fps	-fps mode cfr -> CFR 59.94fps	preserve_pts (PTS 보존)
Tears	VFR	-fps mode cfr -> CFR 24fps	symmetric_cfr_reset_pts (원본, 출력을 원본(24) fps 격자로 맞춤 + 시작점 리셋)

6. 결론 및 정리

BBB와 Meridian은 원래 높았던 점수를 유지했고, Tears의 점수가 정상 궤도로 진입했다고 볼 수 있는 값이 되었습니다.

Tears의 상승을 단계별로 그려봤습니다. 보정 전 41.9 → 측정 정렬만 바로잡은 단계(기존 출력 그대로) 74.6 → 출력 개선 + 대칭 측정 95.4로 상승분 기준 약 60%는 정렬 보정 단계에서 회복되었고, 화질 자체 문제는 일부였습니다.

3장에서 개선한 트랜스코딩 과정에서의 보강은 GOP/세그먼트 보강은 재생 안정성이 1차 목적이고, CFR/대칭 측정은 VMAF 신뢰성에도 관련이 있었습니다.

마무리

이 글에서 다룬 작업은 'VMAF를 몇 점 올렸다'보다 아래 두 가지 목적이 있었습니다.

측정을 신뢰할 수 있게 만들었다 (정렬·프레임·해상도 기준 확립).
HLS 구조를 안정화했다 (GOP·세그먼트·매니페스트·CFR).

이들이 합쳐져 신뢰 가능한 VMAF 기준선을 얻었고, 이것이 2편(Per-Title Encoding)의 출발점이 되어 영상과 품질 측정에서의 문제로 슬플 일이 없게 해줍니다.

인코딩하고 측정하는 시간이 너무 오래 걸려서 힘들었습니다... 영상 관련 내용도 이론으로 공부를 해 두었던 게 조금은 도움이 되었던 것 같아요. 이것저것 참고하고, 의심하며 측정을 여러 번 해봤습니다.

다음 편에는 넷플릭스에서 제시한 Per-Title-Encoding을 적용한 과정을 다뤄보겠습니다.