사례 1 - 타임코드가 어긋났을 때

#증상

프록시에서 지정한 구간(in/out)을 원본에 적용하면 몇 프레임 또는 몇 초 어긋난다.
1시간 지점 근처의 구간에서만 오차가 약 3.6초로 커진다.
원본에서는 타임코드가 01:00:00:00부터인데 프록시에서는 00:00:00:00부터 시작한다.

#원인 1: 드롭 프레임(DF)과 논드롭(NDF)의 혼동

1장에서 설명한 대로 29.97fps 소재의 타임코드는 DF와 NDF가 있고, 같은 숫자라도 가리키는 프레임이 다릅니다. 두 방식으로 같은 숫자를 해석했을 때의 프레임 번호 차이를 계산했습니다.

00:59:58;00 (DF)  = 프레임 107,832
00:59:58:00 (NDF) = 프레임 107,940     → 차이 108 프레임
01:00:00;00 (DF)  = 프레임 107,892
01:00:00:00 (NDF) = 프레임 108,000     → 차이 108 프레임

108프레임 = 약 3.6초입니다. 시스템 중간 어딘가에서 구분자(; → :)가 바뀌거나, DF 여부를 모르고 NDF로 계산하면 1시간 근처에서 이 크기의 오차가 생깁니다. 오차가 시간에 비례해서 커지는 패턴이면 DF/NDF 문제를 먼저 의심하세요(0분 근처는 오차가 거의 없음).

확인: MediaInfo의 Time code of first frame(구분자 확인), FFprobe의 tag:timecode를 봅니다. 구분자가 ;이면 DF입니다.

대책

타임코드를 문자열로만 저장하지 말고 DF 여부(boolean)와 프레임레이트를 함께 저장한다.
프레임 번호 ↔ 타임코드 변환은 하나의 검증된 함수(1장의 정수 연산)만 쓴다.
단위 테스트 경계값: 00:00:59;29 → 00:01:00;02, 00:09:59;29 → 00:10:00;00, 1시간이 프레임 107,892인지 확인.

#원인 2: 프록시에 시작 타임코드가 없다

원본이 00:59:58;00부터 시작하는 ProRes MOV를 H.264 MP4로 변환했습니다.

ffmpeg -i prores.mov -c:v libx264 -pix_fmt yuv420p -c:a aac proxy_tc.mp4
ffprobe -v error -show_entries stream=index,codec_type:stream_tags=timecode -of compact proxy_tc.mp4

stream|index=0|codec_type=video|tag:timecode=00:59:58;00
stream|index=1|codec_type=audio
stream|index=2|codec_type=data|tag:timecode=00:59:58;00

이번 테스트 환경(2026년 2월 빌드 FFmpeg)에서는 재인코딩만으로도 타임코드가 MP4에 유지되었습니다. 그러나 이것은 FFmpeg 버전과 옵션, 입력 파일의 구조에 따라 달라질 수 있는 동작입니다. 타임코드가 유지되는지를 프록시 생성 후마다 검증하세요. 유지되지 않는 경우를 대비해 두 가지를 해둡니다.

시작 타임코드를 DB에 별도로 저장한다(파일 의존을 줄임).
필요하면 변환 시 명시적으로 지정한다.

ffmpeg -i prores.mov -c:v libx264 -pix_fmt yuv420p -c:a aac -timecode "00:59:58;00" proxy_tc3.mp4

위 명령의 결과에서도 비디오 스트림과 data 스트림 모두 00:59:58;00이 기록되었습니다.

#원인 3: -map 0으로 타임코드 스트림까지 넣으려는 경우

오디오 누락을 피하려고 -map 0을 쓰면(4장) 타임코드 같은 데이터 스트림도 함께 매핑됩니다.

ffmpeg -i prores.mov -c:v libx264 -pix_fmt yuv420p -c:a aac -map 0 proxy_tc2.mp4

[mp4] Could not find tag for codec none in stream #2, codec not currently supported in container
Could not write header (incorrect codec parameters ?): Invalid argument
Nothing was written into output file, because at least one of its streams received no packets.

데이터 스트림(tmcd)을 MP4에 복사할 수 없어 변환이 실패했고, 결과 파일은 (불완전한 채로 남았다면) moov atom not found로 읽히지 않았습니다. 해결은 필요한 스트림만 명시하는 것입니다.

-map 0:v:0 -map 0:a            # 비디오 1개 + 모든 오디오 (데이터 스트림 제외)
# 또는
-map 0 -map -0:d               # 전체에서 데이터 스트림만 제외

타임코드는 -map이 아니라 위의 -timecode 옵션이나 DB로 따로 다룹니다.

#점검 순서

원본과 프록시의 시작 타임코드, DF 여부, 프레임레이트를 각각 분석 도구로 읽는다(3장).
구간 계산에 쓴 프레임레이트가 분수(30000/1001)인지, 29.97 같은 근사값인지 확인한다.
오차가 일정한가, 시간에 비례하는가를 본다. 일정하면 시작 타임코드 오프셋 문제, 비례하면 프레임레이트/DF 문제.
프록시의 프레임 수가 원본과 같은지 확인한다(VFR 변환이나 프레임 드롭이 있었다면 달라짐).
재현한 뒤 회귀 테스트로 보관한다.

오차 패턴	의심
모든 구간에서 정확히 N프레임 일정	시작 타임코드 오프셋(프록시가 0부터 시작)
시간이 갈수록 커짐(1시간에 약 3.6초)	DF/NDF 혼동, 29.97를 30으로 계산
분 경계에서 1~2프레임 점프	DF 건너뜀 규칙 구현 오류(1800번이 `;02`이어야 함)
중간에서 갑자기 차이 발생	프레임 드롭, VFR, 편성 전환으로 인한 타임코드 불연속

현업 경험 · 첫 프레임, 프레임레이트 변환, DF/NDF 변환에서 겪은 문제

MXF의 origin 값. MXF에는 트랙의 시작과 타임라인의 기준점 사이의 관계를 나타내는 origin이라는 개념이 있습니다. 경험한 파일 중에는 이 값 때문에 재생이 첫 I 프레임이 아니라 중간의 B/P 프레임부터 시작하는 것처럼 동작하는 경우가 있었고, 어떤 파일은 이 값 대신 타임코드의 시작 값으로 처리되어 있기도 했습니다(파일을 만든 장비에 따라 달랐습니다). 트랜스코딩할 때 이런 값을 확인해서 앞부분을 잘라 내고 처리해야, NLE에서 보이는 첫 프레임이 원본과 같아졌습니다. (롱 GOP에서는 첫 표시 프레임을 디코딩하는 데 앞쪽의 참조 프레임이 필요할 수 있으므로, 구현할 때는 그 프레임을 먼저 제거하지 않도록 주의해야 합니다.)

가변 프레임레이트를 고정으로 바꿀 때. 가장 큰 문제는 가변 프레임레이트(VFR) 영상을 고정 프레임레이트로 변환해서 관리해야 하는 부분이었습니다. 변환 뒤에 프레임 개수와 길이가 달라져서, "정확히 변환되었다"의 기준이 모호했습니다.

DF와 NDF 사이의 변환. DF가 있는 영상과 없는 영상, 또는 DF와 NDF를 서로 바꿔야 할 때는 시간을 맞추느라 프레임이 복사되어 채워졌습니다. 그 결과 같은 프레임이 두 번 출력되어, 재생할 때 순간적으로 멈추거나 렉이 걸린 것처럼 보였습니다. 이 문제 때문에 나중에는 AI 프레임 보간 기술로 처리하기도 했습니다. 참고로 타임코드 표기만 바꾸는 것(DF↔NDF 재표기)은 영상 프레임을 복제하지 않습니다. 이 사례처럼 프레임이 복제되었다면, 시간을 맞추기 위한 프레임레이트 변환이 함께 적용된 경우입니다.

확인 방법. 대부분 NLE에서 프레임 단위로 재생하면서 확인하거나 재생하며 눈으로 확인해야 했고, 보는 사람에 따라 판단이 달랐습니다. (재현 가능한 비교 기준과 프레임 수·길이 검증은 이 장의 앞뒤 글과 3장 4편 참고)

#정리

오차의 형태(일정/비례/점프)가 원인을 알려 줍니다.
DF와 NDF는 1시간에 약 108프레임(3.6초) 차이가 나므로, 타임코드는 항상 DF 여부와 함께 다룹니다.
변환 후에는 타임코드 보존을 검증하고, -map 0은 데이터 스트림 때문에 실패할 수 있습니다.