gif_box 비디오를 GIF로 변환 star

GIF는 왜 "압축된 비디오"가 아니라 개별 프레임으로 만들어지는가

애니메이션 GIF는 MP4처럼 비디오를 압축한 버전이 아닙니다 — 근본적으로 훨씬 오래된 다른 형식입니다: 각각 자체의 작은 256색 팔레트를 가진 완전한 정지 이미지들의 시퀀스가, 프레임마다 지정된 지연 시간을 두고 차례로 재생되는 방식입니다. 이 256색 제한은 GIF 형식이 만들어진 1987년의 산물입니다. 당시에는 8비트(256값) 색상 인덱싱이 그 시대 하드웨어가 감당할 수 있는 실질적 한계였고, 그 이후로 한 번도 바뀌지 않았습니다 — 사진 콘텐츠의 GIF에서 비디오 형식에서는 결코 볼 수 없는 밴딩이나 디더링이 자주 눈에 띄는 이유가 바로 이것이며, 이 도구가 각 프레임을 두 단계 과정을 거쳐 변환하는 이유이기도 합니다: 색상 양자화(프레임의 실제 색상을 분석해 이를 가장 잘 대표하는 256가지 색을 고르는 것)에 이어 팔레트 매핑(각 픽셀을 그 축소된 팔레트에서 가장 가까운 색으로 다시 할당하는 것)을 수행합니다.

브라우저에서 비디오 파일의 프레임을 추출하는 데는 단순한 "다음 프레임 읽기" API를 쓸 수 없습니다. 브라우저는 임의의 비디오 파일에 대해 그런 API를 제공하지 않기 때문입니다. 대신 이 도구는 표준적인 우회 방법을 사용합니다: 비디오 요소의 currentTime을 특정 타임스탬프로 설정하고, 브라우저의 seeked 이벤트를 기다려 정확히 그 프레임이 실제로 디코딩되고 렌더링되었음을 확인한 뒤, 그 단일 비디오 프레임을 캔버스에 그리고 픽셀을 다시 읽어들입니다. 선택한 프레임 속도에 따라 결정된 균등한 간격의 타임스탬프마다 출력 프레임당 이 작업을 한 번씩 수행하는 것은 실시간 재생보다 느리지만, 추출된 각 프레임이 대충 찍은 스냅샷이 아니라 정확하다는 것을 보장합니다.

프레임 속도와 GIF 파일 크기는 비디오 압축에서는 볼 수 없는 방식으로 직접적인 상충 관계에 있습니다: 모든 프레임이 거의 완전한 이미지이기 때문에(바뀐 부분만 저장하는 비디오의 프레임 간 예측과 달리), 프레임 속도를 두 배로 하면 파일 크기도 대략 두 배가 됩니다 — 이 도구가 실용적인 범위를 의도적으로 적당한 프레임 속도로 제한하고 대신 픽셀 크기를 줄일 수 있게 하는 이유가 여기에 있습니다. 10fps에서 폭 360px인 GIF는 같은 클립을 640px, 20fps로 만든 것보다 훨씬 작으며, 흔히 10배 이상 차이 납니다.

좋은 결과를 위한 설정 고르기

• 8~12fps의 짧은 클립(2~5초)은 적당한 크기의 부드러운 GIF를 만듭니다. 더 긴 클립이나 더 높은 프레임 속도는 위에서 설명한 프레임당 팔레트 제한 때문에 파일 크기를 빠르게 키웁니다.
• 넓은 단색 영역을 가진 콘텐츠(화면 녹화, 단순한 애니메이션, 만화)는 사진이나 매우 세밀한 영상보다 GIF로 훨씬 잘 압축됩니다. 단순한 팔레트에서 256색을 양자화하면 완전한 사진 그러데이션에서 256색을 양자화할 때보다 손실이 훨씬 적기 때문입니다.
• 모든 과정은 로컬에서 이루어집니다: 비디오 파일은 브라우저의 비디오 요소가 직접 읽으며 기기를 벗어나지 않고, 인코딩도 전적으로 JavaScript에서 실행됩니다.
• 프레임 추출 단계(탐색 + 대기 + 그리기)는 본질적으로 실시간 비디오 재생보다 느리므로, 더 긴 클립이나 더 높은 프레임 속도는 요청된 총 프레임 수에 비례해 GIF가 준비되기까지 눈에 띄게 더 많은 처리 시간이 걸립니다.