FFmpeg의 가이드에 따르면 x264로 인코딩하는 경우 CRF(Constant Rate Factor)가 17~18일 때 무손실에 가깝다고 한다.
또한, 충분히 양호한 품질을 원하면 CRF을 23으로 하면 되며, 사용할만한 범위는 17~28 이내[각주:1]라고 한다.
그렇다면 이 값들로 동영상을 인코딩 시의 PSNR을 확인하면 다른 인코더에 적용할만한 CRF(또는 이에 준하는 값)[각주:2]을 역셈할 수 있다.
그래서 돌렸다. 열심히 반복해서.
우선 확인해야 할 지점은 x264가 가이드에서 얘기한 Q(CRF)로 인코딩시 어떤 정도의 PSNR을 보여주는지 하는 점이다.
샘플 영상 기준으로 볼 때, PSNR이 48dB 이상이면 무손실로 봐도 무방할 것 같다.
기본값인 Q=23으로 인코딩 시에는 45dB 정도가 나오며, 사용할만한 최소 범위인 Q=18에서는 42dB 정도가 나온다.
다시 말하면, 가이드에서 얘기하는 Q 값의 의미는 PSNR이 48 이상이면 거의 무손실(visually lossless or nearly so), PSNR이 45 정도면 충분히 양호, 42 이상이면 사용할만한 품질 정도로 이해할 수 있음
품질의 최소 목표치는 43 이상으로 잡기로 했다.
도움말을 보면 crf와 유사한 기능을 갖는 옵션은 cq이다.
그런데, 막상 cq를 적용하여 테스트하면 아래와 같은 결과가 도출된다.
Q 값의 변화에 따라 영상의 품질은 변하지 않고, 결과물의 품질은 목표치보다 낮다..
자료를 뒤져보니 guru3D에 한 현자가 해결책을 적어놓으셨다.
cq 대신 rc 옵션을 사용하는 것.
이렇게 적용해서 인코딩한 결과를 x264와 비교하면 아래와 같다.
x264과 비교해서, 유사한 품질에 대해 대략 20%정도 큰 파일을 생성해주는 것을 확인할 수 있다.
또한, preset에 상관 없이 결과 파일이 동일하다는 점도 눈에 띈다.
인텔 qsv는 crf 대신 q 라는 옵션을 통해 Q 값을 지정할 수 있다.
i8700(8세대 i7)에서 보여주는 결과는 놀랍다.
사실상 x264와 큰 차이가 없는 용량 대비 결과물을 보여준다.
심지어, 인코딩에 소요되는 시간은 1/10 수준밖에 되지 않는다.
여기도 nvenc와 동일하게 preset이 달라도 결과 파일은 동일하다.
위의 결과는 i8700인데, i3770(3세대 i7)에서는 어떤 결과를 보여주는지 확인해보니 재미있는 결과가 나온다.
즉, i8700의 qsv는 i3770의 qsv에 비해 뭔가 미묘하게 변한[각주:3] 것이다.
이 테스트를 통해 H.264에 대해서는 대략 다음과 같은 변환 기준값을 도출했다.
물론, 이 값들은 언제나 이렇게 동작하는 건 아니고, 소스에 따라선 다른 결과를 보일 수도 있다.
구분 | 고화질 | 보통 | 최소값 |
x264 | Q=17 Bitrate: 6,329kbps 압축률: 1/144 |
Q=23 Bitrate: 2,694kbps 압축률: 1/338 |
Q=25 Bitrate: 2,050kbps 압축률: 1/444 |
nvenc | Q=20 Bitrate: 6,647kbps 압축률: 1/137 |
Q=25 Bitrate: 3,501kbps 압축률: 1/260 |
Q=28 Bitrate: 2,268kbps 압축률: 1/402 |
qsv | Q=17 Bitrate: 6,231kbps 압축률: 1/146 |
Q=23 Bitrate: 2,568kbps 압축률: 1/355 |
Q=25 Bitrate: 2,029kbps 압축률: 1/449 |
nvenc와 qsv의 결과만 비교해보면 다음과 같은 결과를 보여준다.
즉, 전체적으로는 qsv가 좀 더 높은 품질을 달성하지만, Q 값이 아주 높은 경우엔 nvenc가 더 높은 결과를 볼 수 있다.
앞에도 언급했던 내용이지만, i8700과 i3770는 결과물은 다르게 나오지만, 상당히 비슷한 경향성을 보여준다.
역시 이번에도 기준을 잡는 것은 x265.
같은 소스에 대해 아래와 같은 결과를 확인할 수 있었다.
목표했던 품질을 달성하기 위한 Q 값은 각각 18, 24, 28로 잡기로 했다.
이 결과를 x264와 비교하면 아래와 같다.
물론 인코딩에 소요되는 시간은 훨씬 길지만[각주:4], 동일 화질 기준으로 약 65% 정도의 파일 크기를 보여준다.
nvenc로 인코딩한 결과는 다음과 같다.
nvenc는 x265에 비해 용량 대비 화질이 좀 떨어지는 편이다.
다음은 인텔 qsv.
여기서는 몇 가지에 주목할 필요가 있다.
즉, medium preset은 쓰지 않고, 무조건 slow preset만 써야 한다는 판단.
qsv를 이용한 인코딩에서 slow와 medium preset의 결과만 따로 뽑아보면 아래와 같다.
아래 그래프에서 볼 수 있듯이, medium preset에서 수시로 품질이 떨어지지만 떨어지지 않는 경우는 slow preset의 결과물과 100% 동일하다.
HEVC에 대해서는 대략 다음과 같은 변환 기준값을 도출했다.
물론, 이 값들 역시 소스에 따라 다른 결과를 보일 수도 있다.
구분 | 고화질 | 보통 | 최소값 |
x265 | Q=18 Bitrate: 4,098kbps 압축률: 1/222 |
Q=24 Bitrate: 1,755kbps 압축률: 1/519 |
Q=28 Bitrate: 1,015kbps 압축률: 1/897 |
nvenc | Q=20 Bitrate: 6,282kbps 압축률: 1/145 |
Q=25 Bitrate: 3,019kbps 압축률: 1/302 |
Q=29 Bitrate: 1,648kbps 압축률: 1/553 |
qsv | Q=14 Bitrate: 6,687kbps 압축률: 1/136 |
Q=20 Bitrate: 2,527kbps 압축률: 1/361 |
Q=24 Bitrate: 1,456kbps 압축률: 1/626 |
참고로, nvenc와 qsv를 비교하면 아래와 같다.
즉, H.264와 달리 HEVC 쪽은 nvenc와 qsv의 결과물이 거의 유사한 수준을 보여준다.
물론, qsv는 medium preset에서 툭툭 튄다는 점은 제외하고.
앞의 그래프는 아래의 그래프와 비교해서 볼 필요가 있다.
nvenc로 HEVC 인코딩한 결과물은 x264와 비슷한 용량 대비 화질 결과를 보여준다.
1080p 영상 인코딩에 대한 소결론은 다음과 같다.
1. H.264
- 인텔 qsv를 쓸 수 있는 경우는 무조건 써야 함2. HEVC
- x265는 x264에 비해 동일 화질 기준으로 파일 크기가 65% 정도를 달성함
H.264 HW 인코더 품질/성능 추가시험 (0) | 2019.06.23 |
---|---|
ffmpeg용 H.264/HEVC 인코더 품질/성능 비교 3/3 (0) | 2019.05.06 |
ffmpeg용 H.264/HEVC 인코더 품질/성능 비교 1/3 (4) | 2019.04.28 |
ffmpeg을 이용한 HW 비디오 인코딩 테스트 결과 (2) | 2018.02.04 |
TIFF에 포함된 lossless JPEG 읽기 대장정 (1) | 2017.01.30 |