ab-av1으로 HCRF, VMAF 값 찾는 연습
231005 작성
https://github.com/alexheretic/ab-av1
GitHub - alexheretic/ab-av1: AV1 re-encoding using ffmpeg, svt-av1 & vmaf.
AV1 re-encoding using ffmpeg, svt-av1 & vmaf. Contribute to alexheretic/ab-av1 development by creating an account on GitHub.
github.com
ab-av1
- 영상을 분석해서 VMAF 값과 CRF 값, 인코딩 용량, 인코딩 소요 시간을 찾아주는 소프트웨어.
(VMAF - 넷플릭스에서 개발, 비디오 품질 평가에 사용되는 알고리즘. PSNR, SSIM 등 다양한 메트릭을 결합하여 품질 점수를 매김.)
즉 VMAF을 기준으로 어떤 CRF 값이 화질은 괜찮고 용량은 가장 적을까?를 자동으로 테스트해서 찾아준다.
주로 쓰이는 기능은 crf-search와 sample-encode.
1) crf-search는 시간은 오래 걸리지만 입력한 프리셋(ex. medium), 옵션(ex. --min-vmaf 95)을 기반으로 VMAF 점수, CRF 추천 값과 예상 용량, 소요시간을 알려줌.
2) sample-encode는 짧은 샘플을 몇개 만들어서 측정함. 시간은 짧게 소요 되지만 CRF 값(ex. 18), 프리셋(ex. medium)을 직접 대입해야한다. VMAF 점수, 예상 용량, 소요시간을 알려줌.
여기서 VMAF 점수는 영상의 퀄리티 점수이며 0~100까지이고 대략 95점이면 프레임을 정지해서 보는 게 아닌 이상 육안으로 구분하기 힘든 점수였음. 개인적으로는 90점도 구분하기 어려운 느낌. (..막눈?)
1. crf-search
명령어(예시) : ab-av1 crf-search -e libx265 -i 경로 --preset fast (옵션 --min-vmaf 95)
- 경로의 영상을 x265(HEVC) 코덱과 프리셋으로 인코딩하면서, 여러 CRF 값을 자동으로 테스트해 VMAF 95 이상을 만족하는 가장 효율적인 화질/용량 조합을 찾아 인코딩하는 명령.
- 시간은 오래 걸리지만 VMAF 점수 필터를 걸 수 있어서 편리함.
A파일 - H264 3840x2160 60fps, 23000kbps, 2시간 분량, 24GB
B파일 - H264 3840x2160 60fps, 24000kbps, 2시간 분량, 26GB
- 라이젠 3900X 12코어 24스레드 H265 SW인코딩
=====================================================================
1) crf-search (프리셋 : ultrafast)
입력 : ab-av1 crf-search -e libx265 -i A파일.mp4 --preset ultrafast --min-vmaf 95
- crf 28 VMAF 84.42 (9%) )
- crf 19 VMAF 94.59 (30%) )
- crf 10 VMAF 98.93 (137%) )
- crf 18.2 VMAF 95.25 (35%) )
01:35:55 ##################################### (sampling crf 18.5, eta 0s)
Encode with: ab-av1 encode -e libx265 -i A파일.mp4 --crf 18.5 --preset ultrafast
crf 18.5 VMAF 95.15 predicted video stream size 8.28 GiB (34%) taking 3 hours
2) crf-search (프리셋 : fast)
입력: ab-av1 crf-search -e libx265 -i B파일.mp4 --preset fast --min-vmaf 95
- crf 28 VMAF 92.54 (12%) )
- crf 19 VMAF 97.56 (47%) )
- crf 23.6 VMAF 95.50 (23%) )
- crf 24.3 VMAF 95.11 (20%) )
- crf 24.5 VMAF 94.99 (20%) )
02:18:33 ##################################### (sampling crf 24.4, eta 0s)
Encode with: ab-av1 encode -e libx265 -i B파일.mp4 --crf 24.4 --preset fast
crf 24.4 VMAF 95.05 predicted video stream size 5.28 GiB (20%) taking 5 hours
======================================================================
# CRF 추천 값으로 실제 풀 인코딩
1. 인코더: 샤나 인코더 코덱: H265 CRF: 18.5 프리셋: ultrafast
> 용량: 8.70GB 소요시간: 3시간 23분
2. 인코더: 샤나 인코더 코덱: H265 CRF: 24.4 프리셋: fast
> 용량: 6.66GB 소요시간: 5시간 37분
95점에 맞춰서 풀 인코딩 해봤고 소요 시간은 얼추 맞는데 용량은 애매하다.
품질은 단순히 걍 봤을때? 원본과 별 차이없음. 프레임 정지해가면서 보기도 했는데 엄청 깐깐하게 보는 게 아닌 이상 큰 문제 없음.
2. sample-encode
- CRF 값과 프리셋을 직접 대입해서 VMAF 및 용량 등의 결과 확인.
- 원하는 VMAF 점수를 찾기 위해 노가다 대입 필요.
- 파일: H264, 3840x2160 60fps 23000Kbps 3시간 분량 13.7GB
- 라이젠 3900X 12코어 24스레드 H265 SW인코딩
=====================================================================
1) sample-encode (CRF: 18, 프리셋: fast)
입력: ab-av1 sample-encode -e libx265 -i 파일.mp4 --preset fast --crf 18
- Sample 1 (76%) vmaf 97.23 )
- Sample 2 (78%) vmaf 98.72 )
- Sample 3 (134%) vmaf 99.18 )
- Sample 4 (88%) vmaf 97.66 )
- Sample 5 (109%) vmaf 98.39 )
- Sample 6 (117%) vmaf 98.74 )
- Sample 7 (93%) vmaf 97.87 )
- Sample 8 (89%) vmaf 97.52 )
- Sample 9 (95%) vmaf 98.83 )
- Sample 10 (78%) vmaf 97.51 )
- Sample 11 (61%) vmaf 98.05 )
- Sample 12 (90%) vmaf 97.56 )
- Sample 13 (91%) vmaf 98.75 )
- Sample 14 (72%) vmaf 98.77 )
- Sample 15 (88%) vmaf 99.09 )
00:13:33 Sample 15/15 ########################################## (sampling, eta 0s)
Encode with: ab-av1 encode -e libx265 -i 파일.mp4 --crf 18 --preset fast
VMAF 98.26 predicted video stream size 12.01 GiB (91%) taking 4 hours
sample-encode (CRF: 18, 프리셋: ultrafast)
입력: ab-av1 sample-encode -e libx265 -i 파일.mp4 --preset ultrafast --crf 18
- Sample 1 (45%) vmaf 95.81 )
- Sample 2 (44%) vmaf 97.28 )
- Sample 3 (99%) vmaf 98.15 )
- Sample 4 (51%) vmaf 96.27 )
- Sample 5 (72%) vmaf 97.14 )
- Sample 6 (80%) vmaf 97.52 )
- Sample 7 (55%) vmaf 96.49 )
- Sample 8 (52%) vmaf 95.95 )
- Sample 9 (60%) vmaf 97.72 )
- Sample 10 (44%) vmaf 96.05 )
- Sample 11 (32%) vmaf 96.65 )
- Sample 12 (53%) vmaf 96.14 )
- Sample 13 (56%) vmaf 97.35 )
- Sample 14 (40%) vmaf 97.62 )
- Sample 15 (55%) vmaf 98.03 )
00:10:52 Sample 15/15 ############################################ (sampling, eta 0s)
Encode with: ab-av1 encode -e libx265 -i 파일.mp4 --crf 18 --preset ultrafast
VMAF 96.94 predicted video stream size 7.44 GiB (56%) taking 2 hours
=====================================================================
sample-encode 노가다 결과 값 요약
| 프리셋 | CRF 값 | 비디오 코덱 | VMAF | 예상 소요 시간 | 인코딩 추정 용량 |
| Ultrafast | 18 | H265(SW) | 93.73 | 4시간 | 5.43 GiB (18%) |
| superfast | 95.22 | 4시간 | 6.39 GiB (22%) | ||
| veryfast | 96.38 | 5시간 | 9.33 GiB (32%) | ||
| faster | 96.38 | 5시간 | 9.34 GiB (32%) | ||
| fast | 96.65 | 7시간 | 10.35 GiB (35%) | ||
| medium | 97.16 | 10시간 | 10.79 GiB (37%) |
- 프리셋은 내려갈수록 품질( ↑ ) 소요 시간( ↑ ) 용량( ↑ )
올라갈수록 품질( ↓ ) 소요 시간( ↓ ) 용량( ↓ )
5분 인코딩
| 프리셋 | CRF 값 | 비디오 코덱 | 평균 fps | 예상 소요 시간 | 용량 (5분 인코딩) |
| Ultrafast | 18 | H265(SW) | 0.73x (43fps) | 2시간 40분 | 190MB |
| superfast | 0.66x (39fps) | 3시간 | 248MB | ||
| veryfast | 0.50x (30fps) | 4시간 | 332MB | ||
| faster | 0.50x (30fps) | 4시간 | 332MB | ||
| fast | 0.41x (25fps) | 4시간 40분 | 345MB | ||
| medium | 0.24x (14fps) | 8시간 20분 | 391MB |
- 프리셋마다 품질과 용량 추세를 보고자 인코딩 진행. 다 하기엔 넘 오래걸려서 짧게 5분 측정함.
- 샤나 인코더 H265 SW인코딩, CRF 18 동일
- 프레임을 정지해가면서 봤는데 프리셋을 올릴수록 주변을 뭉뚱그려서 밀어버림. 세부 디테일 날라감.
- 용량은 프리셋 내릴수록 증가함.
챗쥐피티로 공부.
- 프리셋은 압축률에 영향을 끼치니까 프리셋이 낮을수록 화질 향상에 도움이 될 것이고. (시간↑ 용량↓)
🟠 지적:
“프리셋이 낮을수록 인코딩 효율이 좋아지고 화질이 향상되지만,
코덱에 따라 용량이 줄거나(예: x264) 오히려 늘 수도 있다(x265).”
- CRF 값도 낮을 수록 프레임마다 분배되는 비트레이트를 높여서(움직임이 큰 장면)
화질 향상에 도움이 되겠지만 용량은 커질것임.
결국엔 둘다 용량과 품질과 밀접한 관련이 있다는 거 같음.
🟢 정확함.
CRF와 프리셋 둘 다 인코딩의 품질·용량에 직접적으로 영향을 미칩니다.
- 퀄리티모드는 가변적으로 비트레이트를 높였다 낮췄다하니까 FHD, 4K 두 해상도 모두 CRF 값을 원본에 가깝게 낮게 줘서 기본 비트레이트를 높이는 것이 좋지 않을까 싶고
🟡 대체로 맞지만, 주의점 있음.
- CRF를 너무 낮추면 시각적 이득 대비 용량 증가폭이 커집니다.
특히 4K의 경우 이미 픽셀 밀도가 높아서 CRF 18 이하로 내려도 체감 차이가 적어요.
- 프리셋 같은 경우는 FHD는 몰라도 4K 동영상은 이미 고해상도 품질을 가졌으니,
이미 CRF는 무손실에 준하는 18만큼 준다는 가정하에
프리셋은 높게 주어도 화질의 열화는 크게 없지 않을까 싶은 생각임. (둘다 낮을수록이 베스트긴 하겠지만)
🟢 정확함.
4K는 이미 해상도 자체의 정보량이 많기 때문에,
프리셋을 높여도(빠르게 해도) 시각적 열화가 잘 안 느껴짐.
즉, “fast” 정도면 충분한 품질 확보 가능.
- 아직도 의아한 것은 영상에 따라 다르다지만은 대부분 프리셋을 낮춰도 용량은 줄어들지 않았다는 거. 오히려 ultrafast보다 용량이 높아진 인코딩본들이 많았음.
🟢 정확함.
이건 x265에서 매우 일반적인 현상입니다.
“느린 프리셋”은 세밀한 텍스처·색보간·움직임 예측을 더 많이 보존하기 때문에,
같은 CRF에서도 **비트레이트가 증가(=용량 증가)**합니다.즉, “압축률 향상”이 용량 감소가 아니라 화질 유지 효율 증가로 나타난 거예요.
📘 정리 버전 (수정 반영)
- 프리셋은 압축 효율에 영향을 주며, 낮출수록(느릴수록) 화질 향상에는 도움이 된다.
다만 코덱별로 다르게 작동해, x264는 용량이 줄어드는 경향, x265는 오히려 늘어나는 경향이 있다.- CRF 값은 낮을수록 프레임별로 비트레이트가 높아지고, 화질이 향상되지만 용량은 커진다.
- 즉, 프리셋과 CRF는 모두 용량과 화질에 직결되는 요소다.
- CRF는 FHD는 18~20, 4K는 17~19가 적정선이며, 그 이하로 낮추면 용량 증가폭이 급격해진다.
- 4K 영상의 경우 이미 고해상도이므로, 프리셋을 높여도 화질 손실은 미미하며
인코딩 시간 대비 효율을 고려하면 ‘fast’나 ‘faster’ 정도가 현실적이다.- 실제 테스트에서도 프리셋을 낮춰도 용량이 줄지 않고 오히려 증가하는 현상은 정상이며,
이는 x265가 더 많은 세부 정보를 보존하기 때문이다.
.. 인코딩의 세계는 여전히 잘 모르겠다.
원래는 그냥 나 좋은대로, 육안으로 봐가면서 오락가락 기준의 인코딩을 하다가 VMAF 덕분에 일관적인 기준으로 인코딩을 하고 있다는 생각에 뭔가 안심(?)이 되긴 하더라.
근데 VMAF 값 뽑아서 실제 인코딩 수행까지가 시간이 너무 오래 걸린다. 몇번 해보다가 VMAF 값 찾는 과정들이 귀찮아져서 그만 뒀다. 작업 과정을 줄여보고자 CPU도 5950X로도 바꿔봤는데 굳이 이렇게 까지 해야할까 싶기도 하고 데이터 쪼가리가 뭐라고.. 자괴감이 드는 것도 그렇고...
오히려 나에겐 잠깐 테스트 해본 4000 시리즈 글카의 하드웨어 인코딩이 더 나은 경험이었다. 사실 품질과 용량은 SW 인코딩이 낫다고 느껴지긴 하지만, 내게 있어서 HW 인코딩의 속도와 효율 앞에서는 그 차이가 크게 의미 있진 않았다.
FHD는 10분이면 끝나고, 4K도 한 시간 남짓이면 완료되니까 기다리는 시간도 짧아지고 다음 작업도 빨리 할 수 있더라.
앞으로도 HW 인코딩을 사용할 생각이다. 이젠 발열로 방이 데워지며 기다리는 일은 없을 듯하다.
5950X 버리고 5600으로 회귀할 시간이 됐다.