(샤나인코더 홈페이지에 게시했던 글을 교차 투고합니다.)
라이센스에 발목잡힌 HEVC을 대신할 차세대 (무료) 영상 코덱으로 기대를 한몸에 받고 있는 AV1이 현재 어디까지 개발되고 있는지 실제 인코딩을 해봄으로써 테스트했습니다. AV1 코덱에 대해서는 위키피디어의 해당 문서를 참고하십시오.
일단 AV1이 금년 3월 비트스트림 스펙 표준안이 확정되고 표준 코덱 개발이 발표된 매우 초기의 코덱이라는 것을 유념할 필요가 있습니다. 따라서 아직은 많은 부분에서 불완전하고 불안정해서 오류도 잦고 속도도 무척 느립니다.
이 포스팅은 윈도우(64비트)에서 실제로 AV1 인코딩을 해보며, 어떻게 인코딩을 진행했는지에 대한 설명과 함께 개인적인 소감을 적었습니다.
우선 현재 개발되고 있는 AV1 코덱을 간략하게 정리하면 다음과 같습니다.
인코더
|
디코더
|
FFmpeg에 포함 여부
|
개발 기관
|
(lib)aom의 aomenc
|
(lib)aom의 aomdec
|
둘 다 libaom-av1으로 래핑됨
|
AOM(Alliance for Open Media)
|
rav1e
|
dav1d
|
No
|
rav1e: Xiph.Org
dav1d: VideoLAN
|
이 중 dav1d는 VLC의 개발기관이자 x264, x265 등을 지원하고 있는 VideoLAN에서 금년 10월 1일 개발이 발표된 걸음마 단계의 디코더입니다.
(lib)aom은 AV1 코덱을 위해 설립한 AOM에서 주로 구글에 의해 주도되며 개발되고 있고, 그렇기 때문에 vpx 계열과 많은 부분이 유사합니다. 이 libaom 코덱이 AV1의 표준 코덱(reference codec)입니다.
rav1e는 ogg, theora, vorbis, opus 코덱 개발을 주도한 Xiph.org이 daala 코덱의 후속작 성격으로 개발하고 있는 AV1의 인코더입니다. libaom의 느린 속도를 극복하기 위해 개발하고 있는 인코더입니다.
현재 FFmpeg 기반 디코더들을 커스텀 빌드해서 내장하고 있는 다음 팟플레이어와 LAV filters는 AV1 디코딩을 지원하므로 팟플레이어와 MPC-HC에서 AV1 영상을 재생해서 보실 수 있습니다.
우리가 관심 있는 부분은 인코딩이므로 실제로 사용하게 될 방법은,
- 1) 독자적인(stand-alone) 바이너리로 빌드된 rav1e 실행 파일로 인코딩하거나 (rav1e 인코딩)
- 2) 역시 독자적인 바이너리로 빌드된 aomenc 실행 파일로 인코딩하는 방법 (aomenc 인코딩), 그리고
- 3) FFmpeg에서 libaom-av1을 호출해서 aomenc를 사용하는 방법 (aomenc 인코딩),
이 세 가지입니다. 이 중 제가 실제로 진행한 방법은 1)과 3) 두 가지입니다.
1. 인코딩 환경 구성
1) rav1e
- 미리 빌드된 바이너리를 다운로드: 여기
- media-autobuild_suite으로 FFmpeg를 커스텀 빌드하면서 독자적인 바이너리로 빌드 => 제가 사용한 방법
2) aomenc
- 미리 빌드된 바이너리를 구함: 현재 윈도우 용으로 따로 배포하는 곳은 없는 것으로 알고 있습니다. (확인 필요)
- media-autobuild_suite으로 FFmpeg를 커스텀 빌드하면서 독자적인 바이너리로 빌드
- media-autobuild_suite으로 FFmpeg를 커스텀 빌드하면서 (lib)aom을 래핑(--enable-libaom) => 제가 사용한 방법 1
- (lib)aom이 래핑된 FFmpeg 바이너리를 구해서 실행: 여기에서 Zeranoe의 FFmpeg 바이너리를 다운로드 => 제가 사용한 방법 2
aomenc에서 두 가지 방법을 병행한 이유는, aom 최신 버전이 libvpx와 충돌해서 빌드 오류가 발생하거나, 빌드가 되더라도 인코딩/디코딩 단계에서 실패하거나 해서입니다. 서로 다른 버전 두 개를 구해서 되는 것으로 진행했습니다.
2. 인코딩 원본
심슨 극장판 예고편을 오디오를 없애고 25초부터 30초 길이를 잘라 원본으로 삼았습니다.
사용한 명령어:
ffmpeg -hide_banner -ss 00:00:25 -i "The Simpsons Movie - 1080p Trailer.mp4" -t 30 -an -c copy -y "The Simpsons Movie - 1080p Trailer clip.mp4"
생성된 원본 영상 특징:
비트레이트 6,008 kbps (21.9 MB), 길이: 30.57 초, 코덱: H264, 프레임수: 733 frames
유튜브 링크:
원본 다운로드 링크: https://drive.google.com/open?id=1BHC1ILrSFG6is-oJvBEu7ga5oVXiml_5
3. rav1e 인코딩
참조 사이트: https://github.com/xiph/rav1e
rav1e는 input으로는 raw video format인 Y4M을, output으로는 간략한 vpx 계열 컨테이너 형식인 IVF만을 만들어 내므로 rav1e 인코딩 앞뒤로 FFmpeg를 통해 파일을 변환해야 합니다. 그냥 IVF 생성만으로 AV1 인코딩은 끝난 셈이지만 그것을 우리에게 익숙한 형식인 mkv나 webm으로 변환하기 위해서는 AV1 디코더(aomdec)가 libaom-av1으로 래핑된 FFmpeg의 도움이 꼭 필요합니다.
인코딩에 사용된 rav1e의 버전은 0.1.0입니다.
1) Y4M 파일 생성
사용한 명령어:
ffmpeg -hide_banner -i "The Simpsons Movie - 1080p Trailer clip.mp4" -y output1.y4m
실행 속도:
346 fps
생성된 영상 특징:
1.54 GB, 30.03 초, 720 프레임
2) IVF 파일 생성 (AV1 인코딩)
사용한 명령어:
rav1e output1.y4m -o "The Simpsons Movie - 1080p Trailer clip.rav1e.q170.s3.ivf" --quantizer 170 --speed 3
- quantizer 값이 작을수록 고화질
- speed 값이 작을수록 고화질
- 크게 눈에 띄게 뭉개지는 부분이 없도록 두 값을 조정함.
실행 속도:
약 0.14 fps (5,159 초 소요)
실제 진행 상황 및 CPU 점유 상황 스크린샷:
<rav1e 인코딩 실제 진행 상황. 고정된 이미지가 아니라 움짤입니다.>
<rav1e 인코딩 시 CPU 점유 상황>
생성된 영상 특징:
비트레이트 1,112 kbps (4.06 MB), 30.03 초
다운로드 링크: https://drive.google.com/open?id=1icYZ_A_E3lIyN03cO7YB-xpzdpuNdc6X (팟플레이어나 MPC-HC로 재생 가능)
3) MKV 파일로 변환
사용한 명령어:
ffmpeg -hide_banner -i "The Simpsons Movie - 1080p Trailer clip.rav1e.q170.s3.ivf" -c:v copy "The Simpsons Movie - 1080p Trailer clip.rav1e.q170.s3.mkv"
실행 속도:
959x, 즉 30.03/959 = 약 0.031 초
생성된 영상 특징:
비트레이트 1,135 kbps (4.06 MB), 30.03 초
유튜브 링크:
다운로드 링크: https://drive.google.com/open?id=1MGakYSp315n4hDMlBO50urSVH5tLKO45
4. aomenc 인코딩 (FFmpeg의 libaom-av1)
참조 사이트: https://trac.ffmpeg.org/wiki/Encode/AV1
FFmpeg의 AV1 인코딩은 비교적 간략합니다. FFmpeg 내에서 libaom-av1을 코덱으로 호출하여 mkv 포맷으로 인코딩하면 됩니다.
이때 퀄리티 모드, 2-패스 인코딩, 1-패스 인코딩 등 세 가지 방법이 가능한데 지나치게 긴 인코딩 시간 때문에 1-패스 인코딩만 실행했습니다.
인코딩에 사용된 (lib)aom의 버전은 1.0.0-691-gbb8157b89입니다.
사용한 명령어:
ffmpeg -hide_banner -i "The Simpsons Movie - 1080p Trailer clip.mp4" -strict experimental -c:v libaom-av1 -b:v 1M -cpu-used 2 -y "The Simpsons Movie - 1080p Trailer clip.aom.1M.cpu2.1pass.mkv"
- -strict experimental 옵션은 반드시 들어가야 함.
- rav1e 인코딩 버전과 비교하기 위해 비슷한 비트레이트인 1 Mbps = 1,000 kbps를 선택함.
- -cpu-used 값이 높을수록 인코딩 속도는 개선되나 화질은 저하됨. 기본값 1에서 약간 높은 값을 선택함.
실행 속도:
0.1 fps, 0.00302x => 30.03/0.00302 = 약 9,944초 소요
CPU 점유 상황 스크린샷:
<FFmpeg(aomenc) 인코딩 시 CPU 점유 상황>
생성된 영상 특징:
비트레이트 1,079 kbps (3.86 MB), 30.03 초
다운로드 링크: https://drive.google.com/open?id=1wdtr3rCPACRVVKG7RanhRQJpBuEw45sF
5. 결론
- 아직은 인코딩 속도가 한심할 정도로 느립니다. 그나마 rav1e가 낫지만 두 배 가까운 속도 향상에도 불구하고 (또는, 그렇기 때문에) 화질은 aomenc보다 떨어집니다. 심지어 비트레이트가 더 높은데도 그렇습니다.
- rav1e와 aomenc 둘 다 CPU를 충분히 활용하지 못합니다. 코어는 모두 사용하는 것으로 보이지만 CPU 점유율은 인코딩 내내 40% 대를 유지합니다.
- 당연한 얘기지만, 아직 개발 초기이기에 호환성은 무척 낮습니다. 팟플레이어나 MPC-HC, mpv 같은 데스크탑 재생기에서는 재생이 가능하지만 재생 중 탐색이 무척이나 느리거나 아예 불가능합니다. 웹브라우저 내에 video 태그를 붙여서 재생하는 옵션은, 크롬 같은 경우 버전 70 이후부터 AV1 디코더가 지원되므로 현재 시점에서는 아직은 불가능합니다. (관련 문서) Firefox나 Opera 같은 경우에는 최근에 AV1 디코더를 지원하기 시작했고, Safari는 아직 지원이 되지 않고 있습니다. Edge에 대해서는 잘 모르겠군요.
- 현재로서는 버그가 없으며 안정적이면서도 실용적인 속도를 낼 수 있는 수준까지는 갈 길이 멉니다.
이상입니다.
제가 걱정(?)하는 부분은, V9과 libvpx 때처럼 구글이 나 몰라라 하고 나가 떨어지지는 않을까 하는 겁니다. 현재 엔드 유저 수준에서 인코딩 쪽에 하드웨어 가속을 기대하기는 정말 힘들고 (엔비디아, AMD 모두 일반 소비자 용 대부분의 그래픽 카드에서 인코딩에 하드웨어 가속을 지원하지 않고 있죠.) 소프트웨어는 그나마 있는 libvpx도 속도가 정말 개판이죠. 어쩌면 유튜브가 본격적으로 활성화되면서 서버 단위의 V9 인코딩 쪽에 올인한다는 느낌을 받았는데, 이제 aom 쪽으로 개발자들이 몰리게 되니 그런 현상은 더 심해질 것 같습니다. 뭐 "VP9 코덱으로 인코딩하고 싶으면 유튜브에 올려라!" 이런 거겠죠.
어차피 대기업들이 H.264와 HEVC 라이센스 수수료를 MPEG-LA 쪽에 지불하기 싫어서 시작한 프로젝트이니 일단 만들어지긴 하겠죠. 문제는 엔드 유저가 별 어려움 없이 인코딩을 할 수 있게 솔루션을 내놓느냐 하는 문제인데... 현재 추세로 보면 그건 좀 힘들어지지 않을까 싶기도 합니다. 쩝...
왕년에 AV1에 들어가는 기술들을 살펴본 적이 있는데
HEVC와 달리 논문으로나 낼 만한
복잡도 끝판왕들을
상당히 많이 포함시켜 놨더군요.
HEVC는 표준화 시
칩회사들이 참여해서
복잡도와 성능 향상을
적절히 조율(HW가속이 잘 되도록)하여 선정하는 반면
AV1은 그렇지 못한 듯 합니다.
앞으로 HW가속기반 어느정도 향상될지
궁금해지네요 ^^
애초에 워낙 복잡해서..
AMD에서는 최적화가 안되어있는지 코어를 하나만 사용하네요
정확히는 16개 중에 하나씩 여기저기 번갈아가면서 100%찍는 그런현상이 나타나네요
전 ffmpeg에서 windows 빌드링크에 있는것으로 해본거니 아마 Zeranoe FFmpeg가 맞을겁니다.
readme열어보니 맞는거같네요.
x264가 상당히 오래되어서 최적화도 많이되고 해서 속도가 빠르지만 표준 encoder정도의 성능이 나옵니다.
hevc는 x265는 실시간은 불가능하지만 그래도 어느정도 봐줄만한 속도가 나옵니다.
하지만 hevc자체가 매우 복잡한 코덱이다 보니 속도를 이정도 내기 위해서 표준 encoder의 성능에서 약 15% 정도 떨어집니다.
av1은 hevc대비 약 20% 좀 넘는 성능을 가지고있습니다.
그리고 아주x10 복잡한 알고리즘이 많이 들어가있습니다.
av1은 초기 개발 중에 테스트 결과를 보면 hevc보다 10배 이상 느렸습니다. (100배였던가??)
현재 표준이 마무리되고 나서 인코더 최적화 중입니다. (최적화가 다 되어도 상당히 느릴겁니다.)
av1 표준모델이 개발을 위한 구조를 가지고 있고 이것저것 코드가 추가됬다 빠지고 하다 보니 상당히 비효율적입니다.
그래서 VideoLAN에서 디코더를 새로 만들고 있다고 얼마전에 메일이 왔던건 봤는데
인코더도 있군요. 디코더 정보는 여기서 볼 수 있습니다.
https://code.videolan.org/videolan/dav1d
개발 시작한지 얼마 안되었으니 최적화까지 시간을 가지고 기다려보면 좋을것 같습니다.
https://hevc.hhi.fraunhofer.de/
x265가 아직도 표준 코덱에 비해 성능이 뒤처져 있나요? 많이 개선된 것 같은데 말이죠.
최대한 성능 유지하면서 속도 내게 만든게 x265인데 기본이 워낙느리다보니 많이 깎아서 만들었습니다
기본적인 성능차이가 있어보이네요
HEVC는 NVENC와 같은 하드웨어 인코더 지원은 물론이고 벌써 모바일 디바이스들에도 하드웨어 인코딩 / 디코딩 지원이 들어가 있는 상황이라 어느정도 점유율을 서서히 늘어가고 있는데다가, 차세대 이미지 컨테이너인 HEIF(HEIC)에서도 HEVC에 의존성을 가진 상황이라 비디오 뿐만 아니라 이미지 시장에서도 수요가 있을 것 같아보이거든요. 반면에 AV1은 아직도 갈길이 멀어보여서 VPX 전철을 그대로 밟을까봐 솔직히 좀 우려스러워요 ㅜㅜ
Live Photo가 아직까지는 HEIF Still Image + H264 Video 두 파일로 이루어진 구조를 쓰고 있는데, 곧 단일 HEIF 파일에 이미지랑 비디오 스트림 둘 다 밀어넣지 않을까 생각이 들고요.
WebP는 내부적으로 VP8/VP8X 기반인데, 비 구글 플랫폼들에서 VPX 지원이 거의 전무한 수준이라 WebP는 결국 포기하고 AVIF로 가지 않을까 생각합니다.
이유는 모르겠지만 표준화 막바지에 갑자기 합류하더라구요
이것도 cabac입니다.
av1은 엔비디아 인텔이 함께 하드웨어 고려해서 만든 코덱입니다.
이거군요. 2020년까지 표준안 확정이 목표라니 아직은 관심 안 둬도 될라나요? ㅎㅎ
그나저나 HEVC보다 10배 더 복잡하다니 뭔가 으스스한데요?