FFmpegSource 활용 이전 포스팅에서도 언급했듯이, DGDecNV를 보내주고 FFmpegSource를 활용을 검토중이다. 만약 Big Navi를 장착하게 되면 기존 환경으로는 영상 품질 비교가 제대로 이루어지기 힘든 상황. ffmpeg nvenc의 cq 옵션 예전 포스팅에서 언급한 내용인데, ffmpeg/nvenc에서 공식적으로 얘기하는 품질 지정 옵션은 cq이다. ffmpeg -i input.avs -c:v h264_nvenc -preset slow -cq 22 -an out.mp4 하지만, 당시에는 그 옵션은 정상적으로 동작하지 않았다. 대신, 아래와 같은 옵션을 적용해야 되었다. ffmpeg -i input.avs -c:v h264_nvenc -preset slow -rc constqp -g..
영상의 품질을 정량적으로 표현하는 것은 쉬운 일이 아니다. 일단, 단순하게 사진/동영상 하나를 두고 품질을 표현하는 건 불가능하다. 품질을 정량적으로 표현하려면 두 개의 사진/동영상을 두고 차이를 통해 이를 계산해야 한다. 이걸 표현하는 방식은 PSNR, PSNR-HVS, PSNR-HVS-M, SSIM 등등이 있는데, 역시 가장 널리 사용되는 건 PSNR. 그런데, PSNR은 단순히 신호 대 잡음비를 계산하기 때문에 영상 품질을 측정할 때 한계가 있다. 그래서 이를 보완하기 위해 PSNR-HVS 등의 방식이 나오기도 한 것이다. 이 중 SSIM은 구조적 유사성을 계산하는 방식이다. 이 방식은 PSNR과 아예 다른 접근방식을 사용하며, 왜곡도를 측정할 수 있다. 이 값들을 제대로 직접 계산하려면 복잡한 지..
2017/10/01 - H.264 vs HEVC 변환 추가시험 결과 이전 포스트 이후 그 결과를 사용해서 H.264(CRF=23) 및 HEVC(CRF=24)로 인코딩 해본 결과 화질이 좀 이상하다는 것을 느꼈다.H.264 CRF의 기본값인 23으로 인코딩했을 때 지글거림이 살짝 눈에 띈 것이다. 이에 따라 절반 정도의 크기에 유사한 화질을 보여준 HEVC CRF=24 역시 권장값으로 쓰는 것도 한번 더 생각해보게 됐다. 이제 2-passes 인코딩은 별 의미가 없다는 것으로 판단하고, CRF 값을 좀 더 세분화해서 테스트를 해봤다. H.264 CRF=23을 기준으로 봤을 때, HEVC에서 CRF=24를 권장으로 하기엔 뭔가 좀 아쉬운 면이 있다.HEVC에서 CRF=22를 적용하면 H.264 CRF=23에..
2017/09/30 - H.264 vs HEVC 변환 시험 결과 이전 포스트에서 했던 H.264과 HEVC 변환 시험의 결과에서 뭔가 부족한 느낌이 있어 조금 더 시험해봤다.애초에 목표가 HEVC가 괜찮은 방식인지 확인하는 것과 적절한 HEVC의 목표치가 무엇인지 확인하는 것인데, 목표치를 성급하게 결론낸 것. HEVC에 대해서 CRF를 22, 28 외에도 24, 25로 설정한 뒤에 같은 측정을 해봤다. 요지는 HEVC에서 CRF를 24 또는 25 중 어떤 값으로 설정하는 것이 더 합리적인가를 보는 것… 우선 MPEG2 클립에 대한 테스트 결과는 아래와 같다.24로 설정했을 땐 H.264(CRF=23)에 비해 절반 정도의 파일 크기에 PSNR은 0.5 정도밖에 차이 나지 않는다.25로 설정했을 땐 조금 ..
iOS 11이 9월 20일에 공식적으로 공개됨으로써 이제 아이폰에서 공식적으로 HEVC를 지원하게 되었다.이에 따라 이 포맷이 과연 알려진 것만큼의 높은 압축효율을 보여주는지, 인코딩 시간은 어느 정도 소요되는지 확인해보고 싶어졌다. 테스트 항목은 대략 이 정도로 제한했다. - 소스 비디오: MPEG2 BluRay, H.264 영화, H.264 애니메이션 각 2분 이내- 1 패스(CRF 지정)와 2 패스(비트레이트 지정) 모두 수행- 원본과의 PSNR 비교 1 패스 CRF는 ffmpeg에 적용되는 x264/x265의 기본값들을 적용했고, 비트레이트는 적절하게 3가지 값을 적용했다. MPEG2 클립을 변환한 결과는 아래와 같다.우선 눈에 띄는 것은 1 패스와 2 패스 간에 유의미한 경향상 차이는 보이지 않..
2015/04/05 - jpeg#1 : 같은 이미지를 jpeg로 반복 저장하면 정말로 박살나는가? 지난 포스팅에 이어지는 글이자, 위 트윗들 보고 어이 없어서 쓰는 포스팅. 물론, 위의 트윗들은 아래 트윗의 답글 중 일부다. 저 트윗을 쓴 분의 얘기는 그러니까… 1. 윈도우의 jpeg encoder는 DCT 변환 테이블을 잘못 만들었다고 추정함 2. C언어는 math.h의 오류로 sin/cos 함수는 오차가 꽤 나올 수 있음 대략 이렇게 정리될 수 있고, 요약하면 MS의 프로그래머들은 등신이라 저런 오류가 실제로 발생한다는 얘기다. 정말 저런 결과를 보여주는지 확인하기 위해 앞의 포스팅과 같은 기능을 하는 프로그램을 C#으로 만들었다. 이 프로그램은 이전의 프로그램과 사실상 동일한 기능을 한다. 딱 한 ..
발단은 한 줄의 트윗이었다.jpeg로 반복 저장을 600회하면 원래 없던 붉은 점이 가득 끼며 화질이 열화되는 것을 넘어 박살이 난다는 얘기다…이 트윗에 대한 답글로 온갖 이론이 난무하고, 결국 MS의 jpeg 인코더가 범인이라는 아무런 근거 없는 결론(?)이 났다. 근데, 근본적으로 생각해봤다.jpeg는 이미지를 저장할 때 코사인을 기반으로 하는 DCT 변환을 하고, 고주파 성분을 제거하는 방식으로 손실압축을 한다.즉, jpeg에서 화질의 열화는 있는 성분이 사라지는 것이지, 없던 게 태어나는 게 아니다.좀 쉽게 표현하면 날카로움이 사라지고, 흐릿해지며, 두리뭉실해지는 것이다. 반복 저장을 하면 화질이 열화되는 건 당연한데, 결코 저런 방식일 수가 없는 것이다. 이론은 이론일 뿐이고, 과연 얼마나 손상..
VCi의 핵심 프로그램인 ffmpeg에 적용한 옵션들이 적절한지를 확인해보기로 했다.현재 선택 가능한 옵션이 너무 많다는 생각이 들었기 때문이다. 비디오와 오디오를 구분해서 인코딩 시험을 해봤다.소스는 [다크 나이트 라이즈]의 어떤 장면… 1. 비디오 비디오 시험의 초점은 세 가지이다. a. 2-passes slow / fast / very fast / ultra fast 는 정말로 성능과 품질의 차이가 있는가b. 1-pass default의 성능과 품질은 다른 것과 비교해서 어떠한가?c. 현재 VCi 배포본에 포함된 0.11.1과 최신 버전인 git-498e1c6(2013.1.4)의 차이는 있는가 동일한 소스에 대해 인코딩해본 결과 아래와 같은 결과가 나왔다.old는 0.11.1을, new는 git-4..