AI 생성 영상 검수 자동화: ffprobe·전체 디코드·시각 검사를 나누기

영상과 오디오를 검사하는 과정을 표현한 생성형 개념 이미지다. 실제 프로그램 화면이 아니다.

생성형 영상 서비스에서 완료 표시가 떴다고 편집이나 게시 단계로 바로 넘기면 문제가 생길 수 있다. 요청한 길이와 해상도, 실제 내려받은 파일의 속성이 같은지는 별도로 확인해야 한다. 메타데이터 검사, 전체 디코딩 검사, 화면·소리 검수를 서로 다른 단계로 두면 자동화가 어디까지 확인했는지 분명해진다.

이 글은 특정 서비스의 오류율을 측정한 글이 아니다. 공개 도구인 FFmpeg로 독립적인 2초 테스트 파일을 만들고 기본 검사를 실행한 결과와, 운영 파이프라인에 적용할 제안을 정리한다.

1. 요청값과 측정값을 따로 보관한다

작업 기록에 duration: 60만 남기면 그것이 요청한 길이인지 측정한 길이인지 알기 어렵다. 요청 조건과 산출물 측정값을 나눠 저장하는 편이 좋다.

예를 들어 요청 해상도는 1920×1080인데 실제 파일이 1280×720이면 자동 게시를 멈추고 확인 대상으로 보낸다. 업스케일만 해놓고 원래부터 1080p였다고 기록하면 안 된다.

검사 기준은 출력 용도에 맞춰 정한다. 길이 오차 허용치, 최소 해상도, 오디오 필요 여부는 서비스마다 다르다. 아래 예제의 2초·640×360 조건은 재현용 테스트 조건이며 추천 제작 규격이 아니다.

2. ffprobe로 파일을 구조화해서 읽는다

다음 명령은 FFmpeg 7.1.5 환경에서 실제 실행했다. 기존 미디어 대신 테스트 패턴과 440Hz 신호를 사용하므로 개인 영상이나 음원을 올릴 필요가 없다. libx264와 AAC 인코더가 있는 빌드가 필요하다.

-show_entries로 필요한 항목을 고르고 JSON으로 받으면 사람이 읽는 로그 문자열을 파싱하지 않아도 된다. 컨테이너 정보인 format과 개별 트랙인 streams를 구분한다. ffprobe 공식 문서

실제 결과는 다음과 같았다.

• 컨테이너 길이: 2.000000초

• 영상: H.264, 640×360, 평균 프레임률 24/1

• 오디오: AAC, 48,000Hz, 1채널

• 두 트랙의 시작 시각과 길이: 각각 0초, 2초

실제 파일에서는 트랙 길이가 없거나 컨테이너 길이와 다를 수 있다. 값을 읽지 못했을 때 0으로 간주해 통과시키지 않는다. 평균 프레임률도 문자열 분수로 받으며, 그 값 하나로 모든 프레임 간격이 일정하다고 단정하지 않는다.

3. 메타데이터 다음에는 끝까지 디코딩한다

파일 앞부분을 읽는 데 성공해도 뒷부분에 문제가 있을 수 있다. 다음은 첫 영상·첫 오디오 트랙을 전체 처리하는 검사다.

null 출력은 결과 미디어 파일을 만들지 않는 테스트용 출력이다. -c copy를 붙이지 않아야 디코딩 단계를 건너뛰지 않는다. FFmpeg null muxer 문서

로컬 테스트에서는 종료 코드 0이고 오류 출력이 없었다. 설치된 ffmpeg -h full에서 -xerror의 오류 시 종료 옵션도 확인했다. 이것은 해당 파일이 이 명령과 빌드에서 처리됐다는 뜻이다. 모든 플레이어와의 호환성이나 영상 내용의 정확성을 보장하지 않는다.

이 예제는 오디오가 필수인 파일을 가정한다. 무음 영상이 허용되는 파이프라인이라면 메타데이터 검사에서 그 정책을 먼저 정하고 매핑을 조정한다. 트랙이 여러 개라면 검사할 트랙을 모두 열거한다. 검사에 실패했다고 원본을 덮어써서 자동 복구하지 말고 원본과 로그를 남긴다.

4. 정지 프레임 검사와 연속 재생을 구분한다

다음 명령은 초당 두 장을 추출한다. 위 2초 테스트에서는 이미지 4장이 만들어졌다.

프레임 샘플은 자막 잘림이나 큰 형태 변화의 위치를 찾는 데 유용하다. 하지만 샘플 사이에 생긴 짧은 오류는 놓칠 수 있다. fps 필터 문서

생성형 영상에는 다음과 같은 별도 확인이 필요하다. 이는 자동 판정 도구의 보장 범위가 아니라, 이 글에서 제안하는 수동 검수 항목이다.

• 얼굴·손·의상·물체의 형태가 샷 안에서 갑자기 바뀌지 않는가.

• 물체를 잡거나 건네는 동작이 공간적으로 이어지는가.

• 장면 전환 전후의 위치와 방향이 의도와 맞는가.

• 자막이 안전 영역 안에 있고 실제 발음과 맞는가.

• 소리를 직접 들었을 때 누락·잡음·부자연스러운 끊김이 없는가.

의심 구간은 프레임 간격을 좁혀 보고 정상 속도로도 재생한다. 전체를 연속 재생하지 않았다면 “전체 시청 완료”가 아니라 “표본 프레임 확인”으로 기록한다. 오디오 트랙이 존재한다는 사실과 내용을 들었다는 사실도 다르다.

5. 게시 조건은 확인된 항목으로만 만든다

운영 기록에는 기술 검사와 내용 검사의 상태를 따로 둔다. 예를 들면 다음과 같다.

위 JSON은 설계 예시다. 실제 서비스에 연결하거나 게시를 실행한 결과가 아니다. 수동 검수가 필요한 작업에서는 기술 검사 두 개가 통과해도 게시를 허용하지 않는 정책을 사용할 수 있다.

중요한 것은 검사 수를 늘리는 것보다 어떤 사실을 확인했고 무엇은 확인하지 못했는지 보존하는 것이다. 생성 요청, 다운로드 파일, 편집 출력, 게시 대상으로 넘어가는 단계마다 같은 기준을 적용하면 잘못된 완료 판정을 줄일 수 있다.

검증 범위

공식 FFmpeg 문서와 로컬 FFmpeg 7.1.5 도움말을 확인했다. 합성 테스트 파일 생성, ffprobe JSON 조회, 전체 디코딩, 초당 두 장 추출은 실제 실행했다. 특정 AI 서비스의 품질·성능 벤치마크나 실제 운영 파일의 전수 검수 결과는 포함하지 않았다.