MainConcept의 HEVC 인코더가 3.0으로 업데이트 되었다. 기존 2.0에 비해서 HDR-10을 좀 더 잘 지원하는 등의 업데이트가 있었지만, 내가 궁금한 건 인코더 자체의 성능. 다양한 테스트를 돌려본 결과 2.2에 비해 8bpp 영상은 압축률이 향상됨을 확인할 수 있었다. 지금도 VMAF 기준으로는 HEVC 영역에서 최고의 용량 대비 품질을 달성했는데, 이걸 더 끌어올렸다... 10bpp 영상은 2.2와 비교해서 거의 달라진 점이 없다. 실제 파일의 크기가 조금 달라진 걸 보면 기존 코드를 그대로 둔 건 아니지만 8bpp처럼 가시적인 차이는 보이지 않는듯. 역시 돈 들인 값을 하는 MainConcept 인코더인 것이다...
이전 글에서 간단히 썼듯이, VMAF는 넷플릭스가 개발한 비디오 품질 측정 기준이다. 기존에 PSNR/SSIM을 통해 비교해봤던 비디오 인코더들을 VMAF로 비교해보기로 했다. 하는 김에 기존의 비디오 소스인 [Sintel]과는 다른 소스를 사용해보기로 했다. CG만을 사용한 비디오와 실사 영화는 아무래도 다른 특성이 나타나는 것 같기도 하고. 언제나 그렇듯 이러한 테스트는 변인을 통제하고 일부 인자만 바꿔서 계속 반복해 수행하는 게 기본. 이번에도 수많은 테스트를 수행했고, 각 세트마다 엑셀의 시트 하나에 다 저장했다. H.264 언제나 그렇듯 테스트의 시작은 x264를 비롯한 H.264. 그런데 처음부터 눈에 띄는 특성들이 보인다. 일단 4060Ti의 H.264 인코더가 x264보다 용량 대비 품질이..
비디오의 품질을 측정하는 기준엔 PSNR, PSNR-HVS, PSNR-HVS-M, SSIM 등 많은 방식이 있다. 두 영상의 각각 픽셀의 표준편차를 통해 신호 대 잡음비를 계산하는 PSNR이나 구조적 유사성을 계산하는 SSIM 등이 많이 사용되지만, 사람이 눈으로 보는 결과와는 여전히 차이가 있다. 몇년 전에 넷플릭스에서 이러한 문제를 해결할 수 있는 VMAF라는 기준을 개발했다. 핵심 아이디어는 간단(?)하다. 많은 사람들이 직접 비교한 이미지 품질의 평균을 기준으로 삼은 뒤 정량적 측정치에 가중치를 부여해 더해서 유사한 결과가 나오는 모델을 만든 것. 이게 말이야 쉽지 쉬운 일도 아니거니와 그 결과를 통해 최적의 인코딩을 수행한 결과를 전 세계의 사용자들에게 평가를 받게 되는 것이다. 이 방식이 발표..
윈도우 환경에서 프로그램을 만들다보면 긴 이름을 제대로 인식하지 못하는 경우를 종종 마주칠 수 있다. 물론, 대부분의 경우는 그럭저럭 우회가 가능하다. 특정 버전 이전의 윈도우에서는 레지스트리에 값을 기록하고, 파일명 앞에 \\?\를 붙이는 것으로서 해결이 가능하다. 하지만, 좀 더 복잡한 상황이 되면 얘기가 달라진다. Shell Path Handling Function들의 경우 관련 구조체에 MAX_PATH로 정의되어있는 값들이 있다. 예컨데, 아래와 같은 구조체가 이미 정의되어있기 때문에 파일 탐색 등에서는 근본적인 해결이 쉽지 않다. typedef struct _WIN32_FIND_DATAW { DWORD dwFileAttributes; FILETIME ftCreationTime; FILETIME ..
RTX 40 계열에 대한 시장의 비난이 크다. 그야말로 탑 오브 탑인 RTX 4090을 제외하면 RTX 30 계열에 비해 장점은 별로 없는데 가격은 미친듯이 비싸기 때문이다. 심지어 메모리 버스폭마저 동일 라인업 기준으로 좁아져서 비난받지 않으면 오히려 이상할 지경이다. 전성비가 높다는 점을 제외하면 큰 장점이 없다... 그런데, 게임 성능은 게임 성능이고... 비디오 인코딩 성능이 궁금해졌다. 인텔 Arc도 돌려본 마당에 RTX 40을 안 돌려볼 수 없고... H.264 이제 nvdia도 경험이 충분히 쌓인 것 같다. 인텔® QSV 수준의 인코딩 수준을 보여준다. 높은 용량 대비 화질을 목표로 하는 경우라도 더 이상 x264로 인코딩할 필요가 없을 것 같다. RTX 40 계열 및 인텔® QSV의 용량 ..
약 1년 전에 인텔은 SVT-AV1 인코더를 공개했고, 여기서도 개략적인 성능을 테스트했었다. 그리고, 이번에 Arc A750을 구입한 뒤 AV1에 대한 성능을 비교했었다. 그런데, 이 과정에서 예상하지 못했던 문제가 하나 발생했었다. 바로 SVT-AV1 인코더를 업데이트한 뒤 인코딩이 제대로 되지 않았다는 것. gitlab의 설명에도, 프로그램 자체의 도움말에도 아무런 특이한 점은 없었지만, 아무튼 변환은 되지 않았다. 옵션을 적용하는 방법이 뭔가 바뀌었는데, 바뀐 부분을 적용하거나 말거나 그냥 실패... 좌충우돌 끝에 확인한 건 SvtAv1EncApp.exe는 포기해야 되고, ffmpeg.exe 빌드 중에서 full version을 사용해야 한다는 것. Essential version은 인코딩은 되지..
지난 포스팅에서 얘기했듯이 인텔® Arc 라인업의 HEVC 인코딩 성능은 대단히 훌륭하다. 그 글 말미에서 얘기한 대로 AV1 인코딩 성능을 HEVC 인코딩과 동일한 방식으로 확인해봤다. 우선 인코딩 속도를 확인해봤다. 인코딩 속도는 아래 표와 같다. 인텔® QSV를 사용해서 인코딩하면 AV1 역시 HEVC에 버금가는 인코딩 속도를 보여준다. AV1의 인코딩 테스트는 같은 조건에서 HEVC 인코딩한 결과와 비교하는 방식으로 진행했다. 우선, HEVC 인코딩 결과물의 용량 대비 화질은 아래와 같다. 이 그래프는 x265, MainConcept plugin, QSV 등으로 인코딩한 결과에 대해 용량 대비 SSIM을 정리한 결과이다. 용량 대비 품질이 가장 높은 것들과 가장 낮은 것을 아래에 표기했는데, 사실..
인텔의 야심작(?) Arc는 A750과 A770 두 가지 모델이 출시되었다. 상위 모델인 A770이 겨우 RTX3060과의 경쟁제품인 안습의 상황이지만, 궁금함을 참지 못하고 지르고야 말았다. 게임을 거의 하지 않아 약간이라도 더 저렴한 제품인 A750을 구매했다. 박스 포장은 깔끔하다. 기본적으로 글카 자체가 예쁘게 나왔기 때문에 박스를 열었을 때 일단 좀 있어보인다. 그리고 대망의 글카 본체. 설치 이 카드는 집 세컨 PC에 설치하는 것을 최종 목적으로 고려했다. 이 PC에는 문제(?)가 하나 있는데, 예전에 MBR 파티션으로 포맷해놓은 드라이브를 계속 사용해오고 있었던 것. 언젠간 포맷할 거란 생각만 하면서 그냥 써오고 있었는데, 드디어 벽에 부딪혔다. 인텔 홈페이지에도 명시되어 있듯이, UEFI/..
유니코드에서는 한글은 물론이고, 다양한 언어의 다양한 기능을 폭넓게 제공하고 있다. 그리고, 언제나 그렇듯 종종 과유불급 상황이 벌어지곤 한다. 한글과 같은 비영어권 문자는 물론이고, 심지어 영어권 문자 영역에서도 이런 현상을 볼 수 있다. 유니코드에서 U+0085는 NEL(Next Line)으로 정의되어 있다. 이게 뭐냐면... EBCDIC 코드에서 기원한 New Line으로... 그냥 CR/LF와 비슷한 것이다... 그리고, U+00A0은 NBSP(No-Break Space)로 정의되어 있다. SAMI 자막에서 흔히 볼 수 있는 가 바로 이 문자를 의미한다. 적어도 자막으로 한정해서 보면, 사실 이 문자들은 쓸 일이 없다. NBSP가 SAMI에서 사용되는 건 SAMI가 HTML에 기반했기 때문이지 N..
SRT나 ASS 등 다양한 자막 포맷이 있지만, 여전히 우리나라에서 널리 사용되는 자막 포맷은 SAMI이다. 태생적인 기능의 한계나 형식의 불명확함 등의 약점에도 불구하고, 워낙에 널리 사용되어 온 포맷이다. The Speaker SAMI 0000 text Le narrateur Texte SAMI 0000 SAMI 1000 text Texte SAMI 1000 SAMI 2000 text Texte SAMI 2000 SAMI 3000 text Texte SAMI 3000 SAMI 포맷은 이제 나온지 25년이 되어가는(1998년 6월 25일에 첫 공개) 포맷이다. MS가 공개한 이 포맷은 아래에서 볼 수 있듯이 HTML에 여러모로 기반을 두었다. 이러다보니, 규격에는 명시되어 있지 않지만, 코드 페이지로 ..
0. 들어가기 앞서 현재 사실상의 동영상 표준 코덱인 H.264와 HEVC는 유료인데다, 라이센스도 복잡하다. 개인이 사용할 때야 아무 문제 없지만, 상용 제품을 만들게 되면 여기부턴 쉽지 않다. 이에 따라 차기 코덱을 자유 라이센스 환경에서 오픈소스로 만들자는 움직임이 있었고, 그래서 만들어진 코덱이 AV1이다. 인텔, 애플, 모질라, 넷플릭스 등등 수많은 회사들이 모여 AOM을 결성하였으며, 스펙은 '18년 6월 25일에 1.0.0이 발표되었다. 그간 libaom을 포함한 인코더들이 있었지만, 인코딩 시간이 너무 오래 걸려 대중화에는 무리가 있어왔다. 그러다, 며칠 전('22.4.22) 인텔이 SVT-AV1 인코더 1.0을 정식으로 공개하였다. 이에 따라 SVT-AV1의 인코딩 성능과 영상 품질이 어..
이미지 파일 포맷에는 Exif와 ICC Profile을 비롯한 각종 메타 데이터가 포함되어 있다. 이는 여전히 전통의 강호인 JPEG 뿐만 아니라, WebP, HEIF 등등까지 거의 모든 포맷에 해당된다. 심지어 그동안 Exif를 지원하지 않던 PNG도 1.2(2017년 7월)부터 이를 지원하기 시작했다. 나온지 무척 오래 된 규격이라 이 바닥 엔지니어라면 누구나 손쉽고 정확하게 다룰 수 있는 규격... 이기는 개뿔... 실제로 데이터를 만나보면 결코 이게 쉽지가 않다. Exif WebP 이미지에 포함된 Exif 데이터는 다음과 같은 형식으로 저장되어야 한다. WebP 파일에서 Exif 데이터는 EXIF 문자열 뒤에 Exif 영역의 길이가 4바이트 Little endian으로 저장된다. Exif 데이터는..
비디오 영상처리와 인코딩은 온갖 삽질의 끝없는 반복으로 이루어진다. 그리고 그 중엔 모르는 사람이 보면 도저히 이해를 할 수 없는 작업들이 넘쳐난다. VirtualDub2를 이용하면 무압축 RGB 포맷의 AVI 동영상을 만들 수 있다. YUV 변환 따윈 전혀 하지 않은 그야말로 무식한 RGB raw 데이터가 저장된 비디오 파일을 손쉽게 만들 수 있는 것이다. 물론 이런 파일은 대부분의 사용자들에겐 파일 크기만 무식하게 크지 아무 쓸모도 없다. 하지만, 이 바닥에서 일을 하다보면 반드시 이런 파일을 만들어야 할 때가 틀림 없이 나타난다. 각설하고, VirtualDub로 이 작업을 하면 문제가 하나 있는데, 많은 입력 파일을 배치 처리하기가 어렵다는 것이다. 물론 배치 처리 기능이 있긴 한데, 결국 일일이 ..
처음 구매했을 때는 꽤 삽질이 있었지만, 이후 대단히 만족했던 MainConcept의 HEVC 인코더가 2.0으로 업데이트 됐다. 재빠르게 업데이트한 뒤에 릴리즈 노트를 읽어보니 뭔가 변화가 있었다. 일단 MainConcept의 SDK 버전이 12.x에서 13.1로 업데이트 되었다. 이 부분은 13.x의 업데이트 내역이 공개되어있지 않아 그러려니 하지만, 뭐가 달라져도 달라졌겠지... 중요한 것은 인자가 하나 바뀌었다는 것이다. 그래서 똑같이 바꾼 뒤에 인코딩을 해보니... 실패했다... 또 다시 시작이다 싶어서 다양한 테스트를 돌려보고, 오류 리포트를 준비하고 있었다. 그러다 뭔가 쌔한 느낌에 인코딩 확장자를 mkv에서 mp4로 바꿔보니 아무 문제 없이 잘 인코딩된다. 결론은 HEVC Encoder P..
JPEG 포맷은 표준안이 나온지 30년이 되어가지만, 여전히 널리 사용되는 포맷이다. 심지어, 차세대 JPEG을 표방하는 코덱이 좀 나왔었는데, 다 나가떨어질 때까지 JPEG는 버티고 있다. 물론, 영상을 전문으로 하시는 분들께는 그냥 한물 간 포맷이겠지만, 현실세계에선 그렇지 않다. JPEG는 압축률이 꽤 뛰어나다는 장점이 있지만, artifacts라 흔히 통칭되는 노이즈가 가장 큰 약점이다. 그리고, 나온지 오래된 포맷답게 이 artifacts를 없애는 방법들이 꽤 검토되었고, 대표적으로 다음 두 가지 방식이 있다. 1. 이미지 자체에서 artifacts로 인식되는 영역 제거 가장 손쉽게 접근한 방식은 파일을 읽은 뒤에 각 픽셀을 인접 픽셀들과 비교하는 것이다. Paint.NET의 플러그인 중 하나인..
아주 오래 전에 썼던 간단한 글에서도 비슷한 소재를 다뤘는데, 단순히 컴파일하는 것에 그쳤었다. 좀 다양한 라이브러리의 적용은 Zeranoe님이 다 알아서 해주셨고... 참고로, AAC 인코더는 여전히 최종 보스 솔루션이 존재하지 않으며, 선택지마다 조금씩 다른 특성이 있다는 점도 생각해야 한다. 1. 전체적인 품질은 iTunes가 가장 훌륭하다는데, 모두가 쓸 수 있는 건 아님 2. Nero AAC 인코더는 2010년으로 개발 및 수정보완이 완전히 중단됨 3. 원조 맛집 Fraunhofer FDK AAC는 오픈 소스이나 내가 임의로 실행파일을 배포할 수는 없음 iTunes의 품질이 가장 좋다는 평이 지배적이지만, 외국 포럼들을 다니다 보면 libfdk가 좋다는 평도 보인다. 나는 이중 1, 2번을 그동..
ffmpeg은 그야말로 만능 비디오/오디오 처리 도구다. 수많은 프로젝트들이 ffmpeg을 사용해서 만들어졌으며, 소스가 공개되어 다양한 커스텀 버전도 존재한다. 오히려 너무 기능이 방대해서 오히려 불편을 겪을 때가 있을 정도다. 예를 들면, MainConcept의 HEVC 인코더는 ffmpeg 플러그인 형태로 배포 되는데, 이게 순정품(?)과 꽤 차이가 있다. 커스텀 버전의 ffmpeg을 사용해야만 인코딩을 할 수 있는데, 이게 순정품(?)의 기능 중 없는 게 있다. AVS 입력이 완벽하지 않기도 하고, 정확히 어떤 모듈까지 사용됐는지 일일이 찾기도 번거롭다. 이런 경우는 누구의 잘못도 아니지만, 여튼 사용하는 입장에서 불편한 건 사실이다. 이럴 때 손쉽게 쓸 수 있는 방법은 ffmpeg 두 버전 간에..
구매한지 3개월만에 드디어 정상동작을 확인한 MainConcept HEVC 인코더를 테스트해봤다. 테스트는 이전에 했던 테스트들과 동일한 조건에서 수행하여 결과물의 품질을 비교했으며... 이전에 데모버전의 테스트를 위해 만든 인코더의 기능을 좀 보강해서 진행했다. MC의 인코딩을 위해선 따로 컴파일한 FFmpeg이 필요한데, 이 버전이 일부 avs는 잘 읽지 못하는 문제가 발견됐다. 이를 위해 아예 FFmpeg을 직접 컴파일할 수도 있었지만, 귀차니즘으로 그냥 FFmpeg들을 파이프로 연결하도록 보강. 1. color range x264/x265는 기본적으로 full range를 사용하지 않고 limited range(16-235)로 인코딩한다. 동일선상에 놓고 비교하기 위해 limited range 옵..
처음 MainConcept HEVC 인코더를 구매했던 것이 2월 15일이었으니, 무려 3개월의 시간이 흘렀다. 그동안 원격접속으로도 원인을 추적하고, 새 버전을 두 번 다운받았지만, 제대로 실행되지 않는 문제는 여전했다. 그러다 드디어 3개월만에 모든 문제를 수정했다는 메일을 받았다. 마음을 가다듬고 기존의 모든 플러그인을 죄다 제거한 뒤에 PC를 리부팅하고 다시 설치를 시작했다. 설치 과정에서 나오는 PC 보호 경고 메시지는 반갑기까지 하다. 먼저 확인해본 것은 인증 모듈이 잘 동작하는지 여부. Error: 0이 드디어 표시됨으로써 인증 관련 문제가 없다는 점을 확인했다. 바야흐로 테스트 인코딩... 잘 된다. 이제부터 본격 인코딩 효율이나 동작속도 등을 테스트할 예정.
제품을 구매하고, 한달 넘게 기다리고 있는데, 드디어 반가운 메일이 왔다. 플러그인의 새 버전을 다운받으라고 하는 것 기쁜 마음으로 다운로드 링크를 클릭하니 반가운 글자들이 보인다. 그런데, 이게 뭥미? User name, Password? 아무리 생각해도 계정 같은 걸 만들었던 기억이 없는데... 그래도 혹시나 몰라 예의를 갖춰 메일로 물어봤다. 그러자 돌아온 기계가 쓴 거라 해도 믿을 것 같는 답장. 1. 구매했을 때 받은 메일 봐 2. 그리고 지난 버전 다운받는 링크 알랴줌 혹시나 내가 뭔갈 놓쳤나 싶어 바로 그 메일을 뒤져봤지만, 당연히 계정 정보 같은 건 없다. MainConcept 쪽의 시스템은, 다운링크는 주되, 별도의 인증 프로그램으로 인증받는 구조이다. 메일로 설명하니 드디어 뭔가를 보내..
한달 전쯤 MainConcept 사의 HEVC 인코더를 구매하는 것을 검토했었다. 언제 나올지도 알 수 없고, 인코더 성능을 확신할 수도 없는 Big Navi보다 이 쪽이 더 현실적인 선택이기 때문이었다. 테스트 결과는 상당히 만족스러웠다. 인코딩 속도는 HW 인코더와 x264의 중간 정도였는데, 화질은 x265에 상당히 근접하는 수준을 달성했다. 그리하여 Big Navi를 포기하고, MainConcept HEVC 인코더를 구매한 뒤, 당근을 통해 RTX2070으로 업그레이드했다. 송장(Invoice)을 받고 자세히 읽어보니 회사가 다름 아닌 독일 아헨에 위치해있다. 이렇게 반가울데가! 하지만, 언제나 현실은 냉혹한 것... 정식 버전으로 업그레이드를 하고 나니 인코딩이 되지 않는다[..........]..
이전 포스팅(AMD의 RX 6700은 언제쯤 나올 것인가)에서도 언급했듯이 몇달간 AMD의 RX 6700을 기다리고 있었다. RTX30 시리즈의 NVENC는 이전 버전과 동일했기 때문에 아무런 메리트가 없기 때문이었다. 그런데, MainConcept의 HEVC 인코더 데모 버전을 돌려본 뒤 생각이 바뀌었다. 관련 포스팅: MainConcept HEVC 인코더는 쓸만할까? (부제: Big Navi 사지 말까?) 이 인코더는 CPU+GPU Hybrid 인코딩을 지원하는데, 성능과 품질 모두 만족스러운 수준이 나왔다. 문제는 이 인코더는 AMD의 GPU는 지원하지 않는다는 점. 고심 끝에 RTX 3060을 노리고 공개일 새벽부터 열심히 뛰어들었지만, 결국 구매에 실패하고야 말았다. 구매까지 갔다가 입금하려니 ..
엔비디아의 GeForce30 시리즈에 탑재된 NVENC는 20 시리즈의 그것과 동일하다. 하지만, AMD의 Big Navi에 탑재된 VCN은 기존 버전에 비해 향상되었다고 해서 기대하고 있었다. 그런데, 글카의 가격을 생각했을 때 이 업글이 합리적인지 다시 한번 판단해보기로 했다. 대안으로 고민해본 대상은 MainConcept의 HEVC 인코더 FFmpeg 플러그인. MainConcept 사는 SDK, FFmpeg 플러그인 등등 다양한 방식의 인코더를 판매한다. 가장 중요한 기능은 QSV나 NVENC를 활용한 SW+HW 하이브리드 인코딩. 이 중 나에게 딱 맞는 놈은 FFmpeg 플러그인이다. 적절한지 여부를 판단하는 방식은 언제나와 동일하다. 영상 하나를 다양하게 인코딩해본 뒤 SSIM을 계산해보는 것..
nvidia에서 '20년 중순에 출시한 RTX 30 시리즈는 엄청난 성능에도 불구하고 비디오 인코더는 변화가 없었다. 심지어 가격이 이전 모델인 20과 유사한 수준이라 구매욕을 자극했지만, NVENC가 동일해서 구매하지 않았다. 이후 경쟁사인 AMD에서 출시한 RX 6000 시리즈는 이전 모델에 비해 비디오 인코더(VCN)가 업데이트 되었다. 4K에서 fps가 증가한 것 외엔 정보를 찾기 어렵고, MSU의 HW 인코딩 테스트에선 AMD 제품이 대상에서 빠져있다. 그렇지만, 그간의 행보로 보아 추가적인 향상이 있을 것으로 기대된다. 하지만, 현재 출시된 RX 6800 등은 너무 비싸서 엄두가 나지 않고 루머가 돌고 있는 RX 6700을 기다리고 있다. 올해 CES에서 발표할 것이란 얘기도 있고, 3월 말에..
지난 포스팅에서 언급했듯이, 비디오 인코딩 품질 비교 기준, FFmpeg/nvenc 옵션 등이 수정됐다. 이에 따라 변경된 기준들을 정확히 반영할 수 있는 옵션값을 다시 찾아야 했다. 이전 테스트와 같은 소스에서 테스트를 다시 한 번 진행해봤다. 큰 틀에서의 기준은 이전과 동일하다. FFmpeg의 가이드에서 얘기하는 무손실 조건 등에 가장 근접한 옵션을 찾는 것. The range of the CRF scale is 0–51, where 0 is lossless, 23 is the default, and 51 is worst quality possible. A lower value generally leads to higher quality, and a subjectively sane range is 1..
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..
DGDecNV DGDecNV: AVC/HEVC/MPG/VC1 Decoder and Frame Server 내가 영상을 처리할 때 주로 쓰는 환경은 DGDecNV + AVISynth다. 이 중 DGDecNV는 Donald Graft가 만든 유료 프로그램으로, nVidia의 GPU를 활용해 비디오를 읽어준다. 비디오를 프레임 단위로 처리하기 때문에 AVISynth로 원하는 구간에 대해서만 효과를 넣는 것도 가능하다. 유료지만 15$밖에 하지 않는 저렴한 가격은 덤이다. nVidia의 GPU만 지원하는 게 단점이지만, 어차피 지금 GPU는 nVidia가 지배하기 때문에 별 영향도 없다. 무엇보다도 이 프로그램의 장점은 비디오 파일을 프레임 단위로 정확하게 읽을 수 있다는 점이다. DGIndexNV로 비디오 파..
영상의 품질을 정량적으로 표현하는 것은 쉬운 일이 아니다. 일단, 단순하게 사진/동영상 하나를 두고 품질을 표현하는 건 불가능하다. 품질을 정량적으로 표현하려면 두 개의 사진/동영상을 두고 차이를 통해 이를 계산해야 한다. 이걸 표현하는 방식은 PSNR, PSNR-HVS, PSNR-HVS-M, SSIM 등등이 있는데, 역시 가장 널리 사용되는 건 PSNR. 그런데, PSNR은 단순히 신호 대 잡음비를 계산하기 때문에 영상 품질을 측정할 때 한계가 있다. 그래서 이를 보완하기 위해 PSNR-HVS 등의 방식이 나오기도 한 것이다. 이 중 SSIM은 구조적 유사성을 계산하는 방식이다. 이 방식은 PSNR과 아예 다른 접근방식을 사용하며, 왜곡도를 측정할 수 있다. 이 값들을 제대로 직접 계산하려면 복잡한 지..
얼마전 HEIF 변환 프로그램인 iTrans HEIF를 3.03으로 업데이트 하면서 GPAC를 다운그레이드 했었다. 정확한 원인을 찾지는 못했지만, 뭔가 변환 중에 문제가 발생하는 건 확실했기 때문이었다. 현상을 제대로 파악하기 위해, 시간을 들여서 mp4box를 버전별로 테스트를 해보기로 했다. 오류 현상 식별 테스트 조건과 목표는 다음과 같이 구성했다. 1. 아이폰으로 촬영한 HEIF 파일들을 변환하면서 문제 추적 2. 공식 사이트에서 다운받은 버전과 직접 컴파일한 버전을 모두 테스트 3. 목표는 깃헙에 공개된 릴리즈 번호를 기준으로 문제가 발생한 첫 릴리즈를 찾는 것 일단, 모든 mp4box가 사진들의 정보를 이상 없이 읽어냈다. 문제가 발생하는 HEIF에서도 아래와 같이 정보를 제대로 읽는다. m..
FFmpeg은 그야말로 거의 모든 미디어 파일을 변환하는데 사용 가능한 만능 도구이다. 그리고, 이를 윈도우에서 쉽게 활용할 수 있도록 Zeranoe라는 분이 정기적으로 릴리즈 버전을 공개해왔다. 원한다면 직접 컴파일할 수도 있고, 컴파일을 지원하는 도구들도 있지만, 쉬운 일이 아니다... 그런데, 얼마 전 Zeranoe가 배포를 중단하고, 자신의 사이트를 폐쇄하겠다는 공지를 했다. Zeranoe @Zeranoe ·9월 1일 http://ffmpeg.zeranoe.com will close on Sep 18, 2020, and all builds will be removed. If you're using Zeranoe @FFmpeg Builds in your product, please ensure th..
