기술 · 실용 가이드
“moov atom not found”: MP4 복구 전에 복사본부터 확인하세요
다른 복사본, 마무리되지 않은 일반 MP4와 전문 재구축이 필요한 파일을 구분하자. faststart는 인덱스를 옮기며 읽지 못하는 녹화를 복구하지 않는다.
FFmpeg가 “moov atom not found”를 보고하면 원본을 보존하고 별도 작업 복사본부터 점검한 뒤 복구를 시도하자. 실제 열린 파일, 예상 바이트 수와 녹화 마무리 여부를 확인한다. 오류만으로 손상 원인은 알 수 없다.
큰 파일이면 완전하다고 믿거나 모든 크기 차이를 잘림으로 보고 재패키징을 복구로 취급하는 것이 함정이다. 판단을 구분하고 일반 도구가 입력을 읽지 못할 때의 중단 조건을 제공한다.
손실 진단 전에 파일과 복사본 확인
원본 위치, 정확한 이름, 녹화 장치와 모드, 예상 길이 및 실패 전 상황을 기록한다. 이전 재생 가능 복사본과 같은 장치의 정상 녹화도 보존하자. 저장 장치가 읽기 오류나 연결 끊김을 보이면 반복 전체 스캔을 멈추고 영상 실험보다 먼저 저장 매체 복구 도움을 받자.
각 일반 파일의 정수 바이트 수를 확인한다. Python 문서의 `os.stat(path).st_size`는 바이트이며 화면의 반올림 크기와 다르다. 435,000,000,000을1,073,741,824로 나누면 약405.13GiB다. 435GB와405GiB는 같은 양일 수 있지만 이 계산이 무결성을 증명하지 않는다. 동일 단위와 알려진 복사본을 비교하자.
마무리와 재생 배치 변경 구분
현재 OBS 형식 가이드는 마무리가 필요한 일반 MP4/MOV와 중단 내구성을 개선하는 분할·하이브리드 형식을 구분한다. 확장자만으로 녹화 모드를 알 수 없다. 일반 MP4 녹화 중 충돌은 가능한 이유지만 이전에 재생됐다면 마무리 실패로 단정하지 말고 복사본과 저장 매체를 넓게 조사하자.
FFmpeg MOV/MP4 분할 문서는 일반 메타데이터가 한곳에 모이고 분할 파일은 패킷 그룹과 그 정보를 함께 보존한다고 설명한다. faststart는 두 번째 처리에서 인덱스를 앞으로 옮기는 재생 배치 기능으로 누락된 샘플 정보를 생성하지 않는다. 실패하는 입력에 반복 추가해 결국 복구될 것이라 생각하지 말자.
한 번의 입력 검사로 분기 선택
정상 로컬 저장소의 작업 복사본에 `ffprobe -v error -show_format -show_streams "WORKING_COPY.mp4"`를 실행하고 인용된 이름을 실제 경로로 바꾼다. 전체 오류와 버전을 보관하자. 형식과 스트림을 읽는 경우는 moov 오류에서 멈추는 경우와 다르다. 길이·트랙·재생을 확인한 뒤 호환 재패키징을 선택하고 원본을 덮어쓰지 말자.
본지는 격리된1초 MP4를 생성해 유효한 최상위 moov 박스를 제거했다. ffprobe는 잘린 복사본을 열지 못했고 stream copy에 faststart를 더해도 입력 단계에서 실패했다. 좁은 예제는 입력과 출력 옵션의 구분만 검증하며 독자 영상의 재구축 가능성을 판단하지 않는다. 스트림 목록이나 몇 초 재생도 녹화 전체 보존 증거가 아니다.
참조 영상 복구는 별도 작업
untrunc 원본 README는 정상 참조 녹화, 가능하면 같은 카메라를 요구하며 성공을 보장하지 않는다. 보존 후 평가할 옵션으로 아무 파일의 moov를 복사하면 복구된다는 약속이 아니다. 호환성·녹화 설정·출력 확인이 필요하다. 본지는 독자 파일에서 untrunc를 시험하지 않았고 유료 복구 서비스를 보증하지 않는다.
예상 길이, 필요한 영상·음성 트랙, 여러 중간 지점과 마지막 녹화 사건을 확인한 뒤 결과를 채택하고 그전까지 원본을 보존하자. 입력을 읽지 못하고 적합한 참조도 없거나 출력에서 중요 내용이 빠졌다면 증거를 영상 복구 전문가에게 남긴다. 다음 녹화에서는 지원 분할·하이브리드·MKV와 사용할 편집기를 시험하자. 형식 선택은 예방으로 이미 손실된 데이터 복구가 아니다.
