소프트웨어 마스터링 관점에서 H.264 비디오 코덱의 효율성

x264 10비트 인코더가 컴파일된 ffmpeg (64비트)로 인코딩을 했고 24분 동영상에 대략 8시간 정도 걸렸습니다. 피인코딩 대상은 웨이블릿 변환 알고리즘을 사용하는 모션 JPEG2000 코덱으로 500Mbps로 인코딩된 영상입니다. 그리고 업로드 원본을 서버에 저장한 뒤에 재인코딩을 염두해야하는 유튜브의 특성상 시간적 압축을 사용할 경우 (Inter-Coding) 블럭 현상이 나타날 가능성이 높아서 공간적 압축 (Intra-Coding; I-Frame Only; No P-Fremes and No B-Frames; GOP: N=1)만 진행하였고 이를 H.264 4:4:4 Predictive Intra (YUV 4:4:4 10비트, GOP: N=1) 프로파일로 인코딩하였습니다.

General
Unique ID                      : 177299470427735291600000470290746328193 (0x8562A2CBCA0D7E81AE3DC75E32204481)
Complete name                  : C:\BF4_FTR_YouTube-48_H-178_EN-XX_KR-AL_20_2K_OFR_20160521-220232_APP_SMPTE_OV.mkv
Format                         : Matroska
Format version                 : Version 4 / Version 2
File size                      : 48.0 GiB
Duration                       : 23mn 59s
Overall bit rate mode          : Constant
Overall bit rate               : 287 Mbps
Encoded date                   : UTC 2016-05-27 22:57:43
Writing application            : mkvmerge v9.0.1 ('Obstacles') 64bit
Writing library                : libebml v1.3.3 + libmatroska v1.4.4

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High 4:4:4 Predictive Intra@L5.1
Format settings, CABAC         : Yes
Format settings, GOP           : N=1
Codec ID                       : V_MPEG4/ISO/AVC
Duration                       : 23mn 59s
Bit rate mode                  : Constant
Bit rate                       : 281 Mbps
Nominal bit rate               : 360 Mbps / 360 Mbps
Width                          : 2 560 pixels
Height                         : 1 440 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Constant
Frame rate                     : 48.000 fps
Color space                    : YUV
Chroma subsampling             : 4:4:4
Bit depth                      : 10 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 1.586
Stream size                    : 47.0 GiB (98%)
Writing library                : x264 core 148 r2638 7599210
Encoding settings              : cabac=1 / ref=1 / deblock=1:-1:1 / analyse=0x3:0x133 / me=tesa / subme=9 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=0 / me_range=64 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=1 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=4 / threads=8 / lookahead_threads=8 / sliced_threads=1 / slices=8 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=1 / keyint_min=1 / scenecut=1 / intra_refresh=0 / rc_lookahead=0 / rc=cbr / mbtree=0 / bitrate=360000 / ratetol=0.1 / qcomp=0.00 / qpmin=1 / qpmax=81 / qpstep=2 / vbv_maxrate=360000 / vbv_bufsize=7500 / nal_hrd=cbr / filler=1 / ip_ratio=1.40 / aq=3:1.00
Language                       : Korean
Default                        : Yes
Forced                         : No
Color range                    : Limited
Color primaries                : BT.2020
Transfer characteristics       : BT.2020
Matrix coefficients            : BT.2020 non-constant

Audio
ID                             : 2
Format                         : PCM
Codec ID                       : A_PCM/FLOAT/IEEE
Duration                       : 23mn 59s
Bit rate mode                  : Constant
Bit rate                       : 6 144 Kbps
Channel(s)                     : 2 channels
Sampling rate                  : 96.0 KHz
Frame rate                     : 32.001 fps (3000 spf)
Bit depth                      : 32 bits
Stream size                    : 1.03 GiB (2%)
Language                       : English
Default                        : Yes
Forced                         : No

웨이블릿 기반 코덱을 H.264라는 DCT 기반 코덱으로 인코딩 했을 때의 SSIM과 PSNR 수치입니다. 크로마 서브샘플지 않고 RGB 4:4:4 색공간을 YUV 4:4:4로만 변환하였고 시간적 압축을 쓰지 않는 인트라 코딩을 할 경우 H.264의 평균 PSNR은 무려 50dB을 넘어가고 전역 PSNR은 49dB에 육박하네요. SSIM 수치는 무려 25dB에 육박하는군요. 마스터링의 관점에서 H.264는 아직 쓸만한 코덱이라는 점이 놀랍고 최근에 소니가 왜 H.264를 기반으로 한 XAVC 솔루션을 자사 카메라에 사용하고 있는지를 알게해줍니다.

[libx264 @ 00000199a67700a0] frame I:69081 Avg QP:19.53  size:937500  PSNR Mean Y:51.57 U:52.23 V:52.61 Avg:51.91 Global:49.37
[libx264 @ 00000199a67700a0] mb I  I16..4:  1.1% 83.0% 15.9%
[libx264 @ 00000199a67700a0] 8x8 transform intra:83.0%
[libx264 @ 00000199a67700a0] coded y,u,v intra: 99.1% 74.2% 68.9%
[libx264 @ 00000199a67700a0] i16 v,h,dc,p: 16% 45% 33%  7%
[libx264 @ 00000199a67700a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 16% 10%  8% 11%  9% 12% 10% 15%
[libx264 @ 00000199a67700a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 20%  4%  8% 11%  9% 12%  8% 14%
[libx264 @ 00000199a67700a0] SSIM Mean Y:0.9967389 (24.866db)
[libx264 @ 00000199a67700a0] PSNR Mean Y:51.569 U:52.232 V:52.609 Avg:51.909 Global:49.373 kb/s:360000.00

아무리 인터넷 스트리밍 동영상에 시간적 압축을 통해서 블럭 현상 (깍두기 현상)을 심하게 보이면서 천덕꾸러기 취급을 받는 H.264도 이렇게 시간적 압축을 사용하지 않고 약간의 대역폭 절감만 거친 마스터링 원본을 만들 때에는 상당히 화질 보존이 좋은 듯합니다. 그래서 소니가 H.264 코덱을 바탕으로 자사 미러리스 카메라와 시네마 카메라에 XAVC 솔루션을 쓰는 듯합니다. XAVC 중에서 인트라 방식이 XAVC-I (또는 XAVC Intra)인데 MPEG2에 비해서도 저장 화질이 좋아졌죠. 물론 소니 카메라들은 아직까지 YUV 4:4:4를 안쓰고 H.264에 High 4:2:2 프로파일 또는 High 4:2:2 Intra 프로파일을 통해서 YUV 4:2:2 색상을 저장하는 듯합니다.

여기서 I프레임은 모든 픽셀 정보를 누락없이 갖고있고 화질은 JPEG 이미지 수준인 하나의 프레임입니다. P프레임은 투명 바탕 (픽셀 정보가 전혀 없는 배경)에 이전 I프레임과 다음 I프레임 간의 차이점을 부분적인 유효 픽셀로 나타낸 프레임으로 I프레임과는 달리 온전한 픽셀 정보를 갖고있지 않고 부분적인 픽셀 정보를 갖고 있습니다. B프레임은 I프레임과 I프레임, 또는 I프레임과 P프레임 간의 차이를 이미지가 아닌 벡터 정보로 표현한 프레임으로 I프레임과 P프레임보다 상당한 용량 절감이 가능합니다.

시중에 블루레이 동영상 원본, 인터넷 스트리밍 미디어, 토렌트에 떠도는 릴리즈 원본 등 최종 배포본은 용량이 큰 I프레임의 사용을 줄이고 용량이 적은 P프레임과 B프레임의 사용을 극대화하여 대역폭을 줄이는 방식을 사용하고 있습니다. 하지만 이러한 방식은 재인코딩을 염두해두지 않고 대역폭의 절약을 목표로 인코딩되었으므로 이러한 소스를 대상으로 재인코딩을 거치게 되면 P프레임과 B프레임의 화질 문제로 인해 블럭 현상이 발생하게 되는 것입니다.

현재 미국의 ATSC 표준을 준수하는 우리나라의 지상파 방송은 용량 대비 화질이 매우 떨어지는 구식의 MPEG-2 코덱으로 송출되고 있습니다. 가뜩이나 한국의 채널 대역폭은 CBR 20Mbps 밖에 안되는 열약한 수준에서 ATSC 표준에 압축률이 높은 H.264 코덱도 사용할 수 있다고 기재되어 있음에도 하위호환을 위해 MPEG-2 코덱을 아직도 사용하고 있습니다. 거기에 스카이라이프, IPTV 통신사, 케이블TV 업체들이 중간에 H.264 코덱으로 더 낮은 대역폭으로 재압축을 거쳐서 송출하고 있으니 실제로 시청자들이 보는 방송의 화질은 매우 떨어질 수 밖에 없습니다. 아무리 H.264 코덱이라고 해도 지상파 송출 원본 자체부터 CBR 20Mpbs라는 제한된 대역폭에 맞추기 위해 P프레임과 B프레임을 과도하게 많이 사용한 시간적 압축 소스이므로 재압축의 결과물은 정말로 형편없는 수준이 되는겁니다.

이제 지상파 3사가 4K 방송은 압축률이 뛰어난 H.265 (HEVC) 코덱을 바탕으로 대역폭이 기존에 비해 50% 더 높아진 CBR 30Mbps에 맞춰서 송출을 한다고는 하나 중간 서비스 회사에 의한 재압축은 결국 피할 수 없는 현실이고 이로 인한 열화된 화질은 결국 시청자들에게 돌아가는 것이죠. 설상 중간 서비스 회사가 화질 열화를 줄이기 위하여 HEVC 코덱을 사용한다고 하더라도 시각적인 화질 열화는 분명히 발생합니다. B프레임과 P프레임의 효율적인 배분을 극대화하여 최종 배포본의 대역폭을 50% 절감시킨 VP9 코덱과 HEVC 코덱이 나오긴 했지만 B프레임과 P프레임의 고질적인 문제를 해결할 수는 없습니다.

유튜브의 동영상 스트리밍도 또한 마찬가지 입니다. 특히 유튜브는 최대 128GB까지의 단일 업로드 소스를 지원하고 있으며 업로드 원본을 서버 내에 업로더에 의한 삭제 요청 전까지 영구 소장하고 있고 업로드 원본을 복사하여 해상도 별, 비디오 코덱 별 스트리밍 동영상을 인코딩하는 자동화 시스템을 갖추고 있습니다. 이런 상황에서는 시중의 방식으로 P프레임과 B프레임을 많이 사용한 동영상을 업로드하면 유튜브에 의해 재인코딩 된 스트리밍 동영상은 I프레임만 사용된 업로드 동영상을 재인코딩한 동영상 대비 상당한 화질 열화를 겪게 됩니다.

물론 I프레임만 사용하는 동영상도 결국 무압축이나 무손실 압축이 아닌 이상에는 계속해서 우려먹으면 JPEG 압축 알고리즘의 특성 상 화질 열화는 보일 수 밖에 없지만 그렇다고 용량이 방대한 무압축 원본으로 작업하기에는 용량이 부담스럽죠.