
## 개요

영상 플레이어를 개발하면서 타임스탬프를 비교할 일이 생겼다. 현재 재생 시점과 저장된 타임스탬프가 같은지 판별해야 했는데, `===`로 비교하면 거의 항상 불일치했다. `Math.round()`를 써도 경계에서 어긋났다.

이 글은 왜 웹 비디오에서 타임스탬프 비교가 근본적으로 어려운지, 그리고 어떻게 우회했는지를 정리한다.

## video.currentTime

HTML5 Video API에서 현재 재생 위치를 가져오는 방법은 `video.currentTime`이다. 이 값은 초 단위의 `IEEE 754` 부동소수점(double)이다.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/currentTime

```javascript
console.log(video.currentTime);
// 3.456789123456789
```

비디오 컨테이너(MP4 등) 내부에서는 시간을 정수 기반으로 표현한다. 소수점을 쓰면 오차가 생기니까, "1초를 N칸으로 쪼개고 몇 번째 칸인지"를 정수 쌍으로 저장하는 방식이다. MP4에서는 이걸 `TimeValue / TimeScale`이라고 부른다.

- **TimeScale**: 1초를 몇 칸으로 쪼갤지 정하는 단위다. MP4에서는 주로 90000을 사용하는데, MPEG-2 Transport Stream(방송 표준)의 90kHz 클럭에서 온 관례다. 이 값이 24fps/25fps/30fps의 공배수라서 어떤 프레임레이트(fps, 초당 프레임 수)든 나누어떨어진다.
- **TimeValue**: 그 칸에서 몇 번째 위치인지를 나타내는 정수다.

예를 들어 25fps 비디오의 13번 프레임은 `13/25 = 0.52`초에 시작한다. 이걸 MP4 내부에서는 `0.52 × 90000 = 46800`으로 변환해서 정수 쌍 `(46800, 90000)`으로 저장한다. `46800/90000 = 0.52`로 오차 없이 복원할 수 있다.

문제는 브라우저가 이 정수 기반 타임스탬프를 JavaScript에 노출할 때 초 단위 `double`로 변환한다는 점이다. 이 변환 과정에서 정밀도가 깎인다.

## 부동소수점이 프레임 비교를 망치는 과정

WebKit 버그 리포트(#52697)에 구체적인 사례가 기록되어 있다. WebKit은 Safari의 브라우저 엔진이지만, 이 문제는 WebKit에 국한되지 않고 부동소수점을 사용하는 모든 브라우저에서 동일하게 발생한다.

![WebKit Bug 52697 - Frame accurate seeking isn't always accurate](/images/posts/video-frame-precision-epsilon/01-webkit-bug-52697.webp)

25fps 비디오의 13번 프레임 시작 시간은 `46800/90000`이다. 이 값을 배정밀도(double)로 표현하면 `0.52000000000000002`가 되지만, 브라우저 내부 엔진이 이를 단정밀도(float)로 처리할 경우 `0.5199999809265137`이 된다.

이 두 값으로 프레임의 TimeValue를 역산하면

$$
\frac{13}{25} \times 90000 = 46799.999...
$$

$$
\lfloor 46799.999 \rfloor = 46799
$$

가 된다. 프레임은 연속적인 시간 범위를 차지하기 때문에, 특정 시점이 몇 번째 프레임인지 알려면 내림(floor)을 해야 한다. 프레임 13은 TimeValue 46800에서 시작하는데, 부동소수점 오차로 46799가 되면서 프레임 12의 범위에 속하게 된다. 결과적으로 봤을 때 한 프레임이 밀리게 된다.

## 정수 기반 API 부재

W3C Media & Entertainment Interest Group에서도 이 문제를 논의했다. 프레임 단위 탐색이 필요한 실제 사용 사례를 모아서 브라우저 벤더들에게 API 개선을 요구하자는 취지로 열린 이슈인데, 2018년에 열리고 아직까지 Open 상태다.

https://github.com/w3c/media-and-entertainment/issues/4

![W3C - Frame accurate seeking of HTML5 MediaElement](/images/posts/video-frame-precision-epsilon/02-w3c-frame-accurate-seeking.webp)

해당 이슈에서 지적된 이유는 여러 가지다.

첫째, 브라우저 JavaScript API에서 비디오의 실제 프레임레이트를 얻을 방법이 없다. `<video>` 요소에는 fps를 반환하는 속성이 없다. 이슈 본문에서도 "the framerate of the video, which is not exposed to Web applications"라고 지적하고 있다. VFR(Variable Frame Rate) 영상이라면 프레임마다 duration이 다르기 때문에 단일 fps 값 자체가 무의미하다.

![W3C 이슈 댓글 - currentTime만으로는 현재 프레임을 특정할 수 없다](/images/posts/video-frame-precision-epsilon/03-w3c-daiz-comment.webp)

이 이슈에서는 `currentFrameTime`이라는 새 속성을 추가해 현재 표시된 프레임의 정확한 시간을 반환하자는 제안도 있었지만, 이 속성은 추가되지 않았다.

둘째, JavaScript와 비디오 렌더링은 서로 다른 스레드에서 실행된다. `requestVideoFrameCallback` API 문서에서도

![requestVideoFrameCallback - 메인 스레드와 컴포지터 스레드 분리](/images/posts/video-frame-precision-epsilon/04-rvfc-compositor-thread.webp)

라고 설명하고 있다. `currentTime`을 읽는 시점과 실제로 화면에 그려진 프레임이 일치한다는 보장이 없다.

https://web.dev/articles/requestvideoframecallback-rvfc

## GOP(Group of Pictures) 구조가 만드는 추가 제약

YouTube IFrame API처럼 서버에서 영상을 스트리밍으로 받아 재생하는 환경에서는, 부동소수점 오차와 별개로 비디오 압축 구조 자체가 프레임 정밀 탐색을 어렵게 만든다.

GOP는 영상 프레임들을 묶는 압축 단위다. 매 프레임을 통째로 저장하면 용량이 너무 크기 때문에, 하나의 완전한 이미지(I-frame)를 기준으로 나머지 프레임은 차이만 저장하는 방식으로 압축한다. 비디오 프레임은 세 가지 유형으로 나뉜다.

| 프레임 유형 | 설명                                                                                              |
| ----------- | ------------------------------------------------------------------------------------------------- |
| I-frame     | 내부(intra)만으로 완성되는 프레임, 다른 프레임 참조 없이 독립적으로 디코딩할 수 있다.             |
| P-frame     | 이전 프레임을 예측(predicted)해서 바뀐 부분만 저장한다. 이전 I/P-frame이 있어야 디코딩할 수 있다. |
| B-frame     | 앞뒤 프레임을 양방향(bi-directional)으로 참조해서 차이만 저장한다.                                |

영상에서 특정 시점으로 탐색(seek)하면, 브라우저가 바로 그 프레임을 보여줄 수 있을 것 같지만 그렇지 않다. 해당 시점의 프레임이 P-frame이나 B-frame이라면, 차이 데이터만 있기 때문에 기준이 되는 I-frame을 먼저 찾아야 한다. 가장 가까운 I-frame까지 돌아간 뒤, 거기서부터 원하는 시점까지의 프레임을 순서대로 디코딩해야 한다.

I-frame은 보통 60-120 프레임(30fps 기준 2-4초)마다 존재한다. 스트리밍 환경에서는 용량을 줄이기 위해 I-frame 간격을 더 길게 잡는 경향이 있어서, 프레임 정확 탐색은 더욱 어려워진다.

## epsilon 비교로 우회

프레임 단위 정확한 비교가 불가능하다면, "충분히 가까우면 같다"고 판단하는 방식으로 우회할 수 있다. epsilon(ε)은 수학에서 아주 작은 양을 뜻하는데, 두 값의 차이가 이 ε보다 작으면 같다고 간주하는 비교 방식을 epsilon 비교라고 한다.

```javascript
// 정확한 비교 — 거의 항상 false
if (currentTime === targetTime) { ... }

// epsilon 비교
const EPSILON = 0.1; // 초
if (Math.abs(currentTime - targetTime) < EPSILON) {
  // 허용 오차 내면 같은 프레임으로 판단
}
```

너무 작으면 같은 프레임인데도 다르다고 판정하고, 너무 크면 다른 프레임을 같다고 판정하기 때문에 epsilon 값을 어떻게 정할 것인가가 중요하다. 여기서는 0.1초를 epsilon으로 설정했다. 60fps 기준으로 6프레임에 해당하는 넉넉한 값이다. 이 값을 선택한 근거는 다음과 같다.

```typescript
const isSameTimestamp = Math.abs(currentTimeInSeconds - timeInSeconds) < 0.1;
```

이 epsilon은 같은 타임스탬프의 중복 클릭을 판별하고, 반복 seek를 방지하는 데 사용했다. "방금 한 동작을 또 하는 건지"를 체크하는 용도이기 때문에 0.1초는 적절한 값이라 생각했다. 반면 이 값을 프레임 단위(1/60 = 0.0167초)로 줄이면 부동소수점 오차와 YouTube API의 `setInterval` 폴링 간격(250ms) 때문에 오탐이 빈번하게 발생한다.

그래서 중복 seek 방지에도 같은 epsilon을 적용했다.

```typescript
// 0.1초 이내의 seek 요청은 무시
if (lastSeekTarget !== null && Math.abs(time - lastSeekTarget) < 0.1) {
  return;
}
```

YouTube IFrame API는 `seekTo()` 호출 후 실제로 해당 시점에 도달하기까지 지연이 있다. 그 사이에 같은 위치로 반복 seek가 발생하면 플레이어가 불안정해진다. epsilon 범위 내의 요청을 무시함으로써 이 문제를 방지했다.

## 근본적 한계

epsilon 비교는 우회책이지 완벽한 해결책은 아니다. 웹 비디오에서 프레임 단위 100% 정확도는 현재 브라우저 아키텍처에서 달성할 수 없다.

`requestVideoFrameCallback` API는 비디오가 새 프레임을 그릴 때마다 콜백을 실행해주는 API다. 이 콜백에서 제공하는 `metadata.mediaTime`은 `currentTime`보다 정밀도가 높다. `currentTime`이 오디오 재생 시계를 기준으로 시간을 반환하는 반면, `mediaTime`은 실제 프레임의 원본 타임스탬프(PTS)를 직접 가져오기 때문이다.

하지만 이것도 여전히 float 기반이다. 그리고 프레임은 컴포지터 스레드에서 그려지기 때문에, JavaScript에서 콜백을 받는 시점과 실제 화면에 프레임이 나타나는 시점 사이에 1 vsync(약 16ms) 정도의 차이가 존재한다.

결국 웹 비디오 환경에서 타임스탬프를 비교해야 한다면, 정확한 일치가 아니라 "어디까지 허용할 것인가"를 용도에 맞게 결정해야 한다. 중복 클릭 판별과 반복 seek 방지라는 용도에서 0.1초는 충분히 합리적인 선택이었다.

## 참고 자료

- [WebKit Bug #52697: Frame accurate seeking isn't always accurate](https://bugs.webkit.org/show_bug.cgi?id=52697)
- [W3C Media & Entertainment Issue #4: Frame accurate seeking](https://github.com/w3c/media-and-entertainment/issues/4)
- [Dolby OptiView: Frame Accurate Seeking](https://optiview.dolby.com/docs/theoplayer/knowledge-base/playback/frame-accurate-seeking/)
- [web.dev: requestVideoFrameCallback](https://web.dev/articles/requestvideoframecallback-rvfc)
- [AWS: GOPs Explained](https://aws.amazon.com/blogs/media/part-1-back-to-basics-gops-explained/)


currentTime, 부동소수점, epsilon 비교

웹 비디오에서 프레임 단위 정밀도의 한계


## 들어가며

촬영한 이미지를 합성하고, 영상을 서버에 전송하는 과정이 필요했다. 브라우저에서 이미지와 영상을 어떻게 처리했는지, 그리고 포맷을 선택하면서 부딪힌 문제를 정리한다.

## 브라우저에서 이미지를 처리해야 했던 이유

촬영한 사진 4장을 하나의 이미지로 합성하고, 프레임 배경을 씌우고, QR코드를 올리는 작업이 필요했다. 이 과정을 서버에서 처리하면 원본 4장을 모두 업로드한 뒤 합성 결과를 다시 받아야 한다. 여러 사용자가 동시에 촬영하면 업로드 대기 시간이 길어졌고, 사용자가 결과를 받기까지 체감이 느려지는 문제로 이어졌다.

브라우저의 Canvas API를 사용하면 이미지 합성을 클라이언트에서 직접 처리할 수 있다. 서버 왕복 없이 촬영 직후 바로 결과물을 만들 수 있다는 점이 이 환경에 적합했다.

## Canvas API로 이미지 처리하기

### canvas.toBlob()과 canvas.toDataURL()

브라우저에서 이미지를 Canvas로 처리한 결과를 내보내는 네이티브 API는 두 가지다.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL

둘 다 canvas에 그린 내용을 원하는 포맷으로 인코딩하지만 반환 형태가 다르다.

- `toDataURL()`은 Base64 인코딩된 문자열을 동기적으로 반환한다.
  - Base64는 바이너리를 텍스트로 변환하기 때문에 원본 대비 약 33% 크기가 증가한다.
  - 중간 처리 단계에서 이미지를 문자열로 다룰 때 유용하다.
- `toBlob()`은 바이너리 Blob을 비동기 콜백으로 반환한다.
  - 바이너리 그대로 다루기 때문에 크기 증가가 없고, File 객체로 변환하기도 간편하다.
  - 서버에 전송할 최종 파일을 만들 때 적합하다.

실제로는 두 API를 용도에 따라 섞어 사용했다. 좌우반전이나 4컷 합성처럼 중간 단계에서는 `toDataURL()`로 이미지를 문자열로 넘기고, 서버에 업로드할 최종 파일을 만들 때는 `toBlob()`을 사용했다.

### 이미지 합성 흐름

`drawImage()`는 canvas 위에 이미지를 그리는 Canvas 2D API 메서드다. 4컷 합성은 이 메서드를 호출하는 순서를 조절하는 것만으로 해결했다.

```typescript
// 4장의 사진을 각 위치에 배치
for (const [index, photo] of photos.entries()) {
  const img = await loadImage(photo);
  ctx.drawImage(img, positions[index].left, positions[index].top, photoWidth, photoHeight);
}

// 프레임 배경을 위에 덮어씌우기
const bg = await loadImage(backgroundImage);
ctx.drawImage(bg, 0, 0, baseWidth, baseHeight);
```

Canvas는 나중에 그린 것이 위에 온다. 사진 4장을 먼저 깔고, 프레임 배경을 그 위에 덮으면 프레임의 투명 영역을 통해 아래의 사진이 보이는 구조가 된다. 합성이 끝나면 `canvas.toDataURL("image/png", 1.0)`으로 결과를 뽑아낸다.

`devicePixelRatio`(DPR, 디스플레이의 물리 픽셀과 CSS 픽셀의 비율)를 곱해 canvas 해상도를 높이는 시도도 했다. DPR이 2인 화면에서 canvas 내부 픽셀 수를 2배로 늘리면 이론적으로 더 선명한 이미지를 얻을 수 있다. 하지만 고해상도 캔버스에 저해상도 이미지를 크게 그리는 것뿐이었기 때문에 실제 인쇄 결과는 달라지지 않았다. 코드로 할 수 있는 조치는 다 했지만, 원본 해상도의 한계는 소프트웨어로 넘을 수 없었다.

### 리사이징

촬영된 이미지의 해상도가 목표 크기와 다른 경우 리사이징이 필요하다. 단순히 크기를 줄이면 이미지가 찌그러질 수 있기 때문에, 비율을 유지하면서 중앙 크롭하는 방식을 사용했다.

```typescript
// 원본과 목표의 가로/세로 비율을 비교하여 크롭 방향을 결정
const imgRatio = img.width / img.height;
const targetRatio = targetWidth / targetHeight;

if (imgRatio > targetRatio) {
  // 원본이 목표보다 가로가 넓으면 좌우를 자른다
  sw = img.height * targetRatio;
  sx = (img.width - sw) / 2;
} else {
  // 원본이 목표보다 세로가 높으면 상하를 자른다
  sh = img.width / targetRatio;
  sy = (img.height - sh) / 2;
}

ctx.drawImage(img, sx, sy, sw, sh, 0, 0, targetWidth, targetHeight);
```

`drawImage`의 9개 인자 버전은 원본에서 잘라낼 영역과 canvas에 그릴 영역을 각각 지정한다. `sx`, `sy`는 원본에서 잘라내기 시작할 좌표, `sw`, `sh`는 잘라낼 영역의 크기다. 비율 비교로 어느 방향을 잘라야 하는지 판단한 뒤, 중앙을 기준으로 크롭하여 이미지가 찌그러지지 않도록 했다.

## WASM 기반 FFmpeg 라이브러리로 영상 압축하기

### 브라우저에서 ffmpeg를 실행하는 방법

브라우저에서 영상을 다루는 네이티브 API로 `MediaRecorder`가 있다. 웹캠 스트림을 실시간으로 녹화할 때 사용하며, `videoBitsPerSecond` 옵션으로 비트레이트 힌트를 줄 수 있다. 하지만 이 값은 브라우저가 정확히 지키는 것이 보장되지 않고, 코덱도 브라우저가 지원하는 것만 선택할 수 있다. 무엇보다 `MediaRecorder`는 녹화 시점에 동작하는 API라서, **이미 녹화된 영상을 다시 압축하는 용도로는 쓸 수 없다**.

`@ffmpeg/ffmpeg`는 C로 작성된 ffmpeg를 WebAssembly(WASM, 브라우저에서 네이티브에 가까운 속도로 실행되는 바이너리 포맷)로 컴파일해 브라우저에서 실행할 수 있게 만든 패키지다. 실제 파일시스템 대신 메모리(Emscripten FS)를 사용한다는 점만 다르고, ffmpeg 명령어를 그대로 쓸 수 있다.

### 구현

```typescript
const ffmpeg = createFFmpeg({ log: false });

async function compressVideo(file: File): Promise<File> {
  if (!ffmpeg.isLoaded()) await ffmpeg.load();

  ffmpeg.FS("writeFile", file.name, await fetchFile(file));
  await ffmpeg.run("-i", file.name, "-c:v", "libvpx", "-b:v", "1M", "-c:a", "libvorbis", "output.webm");
  const data = ffmpeg.FS("readFile", "output.webm");

  // 메모리 누수 방지
  ffmpeg.FS("unlink", file.name);
  ffmpeg.FS("unlink", "output.webm");

  return new File([data.buffer], "output.webm", { type: "video/webm" });
}
```

### 프로덕션에 적용하지 못한 이유

영상 압축 로직은 구현까지 완료했지만, 실제 서비스에 적용하지는 못했다. 2주라는 짧은 외주 기간 안에 결과물을 내야 했고, 같은 날 다양한 기능들을 통합해서 구현하는 상황이었다. 원본 그대로 올려도 동작은 했기 때문에, 압축 연결보다 다음 기능 구현이 우선순위에서 앞섰다. 결과적으로 압축 유틸은 만들어둔 채로 다시 돌아오지 못했다.

## 정리

- Canvas API의 `toBlob()`과 `toDataURL()`은 용도에 따라 사용처가 다르다. 중간 처리에는 `toDataURL()`, 최종 파일 생성에는 `toBlob()`이 적합하다.
- `drawImage()`의 호출 순서로 이미지 합성을 구현했다. Canvas는 나중에 그린 것이 위에 오는 특성을 이용해 사진 위에 프레임을 덮는 구조를 만들었다.
- 이미지 리사이징 시 비율을 유지하면서 중앙 크롭하는 방식으로 찌그러짐을 방지했다.
- `@ffmpeg/ffmpeg` WASM으로 브라우저 영상 압축을 구현했지만, 제한된 일정 안에서 우선순위가 밀려 프로덕션에 적용하지 못했다.

## 참고 자료

- [HTMLCanvasElement.toBlob() - MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob)
- [HTMLCanvasElement.toDataURL() - MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL)
- [@ffmpeg/ffmpeg - npm](https://www.npmjs.com/package/@ffmpeg/ffmpeg)
- [WebP - Google Developers](https://developers.google.com/speed/webp)


Browser

2025

웹 비디오에서 프레임 단위 정밀도의 한계

네컷사진 이미지를 브라우저에서 처리한 과정