OpenCV 비디오 처리

TL;DR

• 비디오는 파일이 아니라 프레임 스트림이다.
• 실시간 처리의 핵심 제약은 FPS·지연·드롭이다.
• VideoCapture는 “열기–루프–해제”의 수명 관리가 전부다.
• 성능 문제의 80%는 루프 구조와 해상도에서 발생한다.
• GUI 의존을 끊고 헤드리스 전략을 준비해야 한다.
• 탐지/추적 품질은 알고리즘보다 비디오 파이프라인 안정성에 더 크게 좌우된다.

---

1. 핵심 개념: 비디오 = 프레임 스트림

비디오는 연속된 이미지의 집합이다. 중요한 점은 시간 제약이다.

• 입력은 frame(t)의 스트림
• 출력은 지연 없이 처리된 결과
• 제약 요소:
  • FPS 유지
  • 누적 지연(latency) 방지
  • 프레임 드롭 관리

👉 이미지 처리와 달리, 완벽한 처리보다 제때 처리가 중요하다.

---

2. 개념 지도 (Concept Map)

OpenCV 비디오 처리
├─ 입력
│  ├─ VideoCapture (file / camera)
│  └─ codec / format
├─ 루프
│  ├─ frame read
│  ├─ processing
│  └─ rendering / output
├─ 성능
│  ├─ FPS
│  ├─ latency
│  └─ frame drop
└─ 환경
   ├─ GUI 가능
   └─ Headless (server/notebook)

---

3. 왜 비디오 처리가 어려운가

이미지 파이프라인은 “한 장”이 기준이다. 비디오는 루프 전체의 안정성이 기준이다.

• 한 프레임이 느리면 → 전체 지연
• 메모리 해제가 안 되면 → 누수
• GUI 의존하면 → 서버에서 즉시 실패

👉 따라서 루프 설계가 알고리즘보다 먼저다.

---

4. VideoCapture 핵심 사용 패턴

불변 규칙

1. 열었으면 반드시 닫는다
2. read() 실패는 정상 상황이다
3. 루프 안에서 무거운 작업 금지

---

5. 안정적인 비디오 루프 템플릿 (파일 입력)

import cv2
import time

def stable_video_loop(video_path):
    """
    입력: video file path
    출력: None
    목적: 안정적인 프레임 루프 구조 예시
    """
    cap = cv2.VideoCapture(video_path)
    if not cap.isOpened():
        raise RuntimeError("VideoCapture open failed")

    fps_counter = []
    prev_time = time.time()

    while True:
        ret, frame = cap.read()
        if not ret:
            break  # 정상 종료 조건

        # --- 최소 처리 ---
        frame = cv2.resize(frame, (640, 360))
        gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)

        # FPS 계산 (렌더 없이도 측정)
        now = time.time()
        fps = 1.0 / (now - prev_time)
        prev_time = now
        fps_counter.append(fps)

        # 오버레이 (선택)
        cv2.putText(
            frame, f"FPS: {fps:.1f}",
            (10, 30), cv2.FONT_HERSHEY_SIMPLEX,
            0.8, (0, 255, 0), 2
        )

        # GUI 환경에서만 사용
        if cv2.waitKey(1) & 0xFF == 27:
            break

    cap.release()
    cv2.destroyAllWindows()
    print("Avg FPS:", sum(fps_counter) / len(fps_counter))

결과 해석 포인트

• resize를 가장 먼저 적용 → 성능 안정
• FPS 측정은 렌더와 분리 가능
• ret == False는 예외가 아니다

---

6. 프레임 오버레이와 최소 처리 원칙

• 텍스트/도형은 디버깅 도구
• 최종 성능 측정 시에는 제거
• 컬러 → 그레이 변환은 가장 싼 연산

---

7. 성능 체크리스트 (어디서 느려지는가)

1. 해상도가 불필요하게 큼
2. 루프 안에서 I/O 수행
3. Python for-loop 중첩
4. 매 프레임 메모리 재할당
5. GUI 렌더링 병목
6. 불필요한 color conversion
7. frame copy 남발
8. FPS 측정 자체가 병목

---

8. 실무 이슈와 회피 전략

코덱 / 포맷

• 파일 열림 ≠ 프레임 디코딩 성공
• ret=False 반복 시 코덱 문제 의심

GUI 불가 환경 (서버/노트북)

• imshow 제거
• 중간 결과는 파일로 저장
• 수치 로그(FPS, frame index)로 검증

프레임 스킵 / 샘플링 (개념)

• 모든 프레임을 처리할 필요 없음
• N frame마다 처리 전략
• 추적/탐지에서 초기화 vs 유지 분리

---

9. 흔한 실수 / 디버깅 체크리스트

1. release() 누락
2. ret 체크 안 함
3. 해상도 고정 안 함
4. 루프 안에서 모델 로딩
5. GUI 의존 코드 서버 배포
6. FPS 측정 위치 오류
7. 프레임 드롭을 버그로 오인
8. 파일 끝 처리 미흡
9. VideoCapture 재사용
10. 성능 테스트 없이 알고리즘 탓

---

10. 왜 비디오 파이프라인이 탐지/추적 품질을 좌우하는가

• 탐지는 초기 정확도
• 추적은 연속성

• 파이프라인이 불안정하면:

  • 탐지 빈도 감소
  • 추적 드리프트 증가
  • 모델 성능과 무관한 실패 발생

👉 좋은 추적은 좋은 프레임 입력에서 시작된다.

---

섹션 요약

• 비디오는 알고리즘 문제가 아니라 시스템 문제다.
• 프레임 루프 안정성 없이는 어떤 CV도 신뢰할 수 없다.
• 이 구조가 다음 단계(탐지/추적)의 전제다.

---

다음 글 / 다음 학습

➡️ 다음 글: 전통적 객체 탐지와 추적: 알고리즘 선택 기준

비디오 파이프라인 위에서 탐지와 추적이 어떻게 결합되는지를 다룬다.

---

• 참고: OpenCV 및 딥러닝 을 이용한 Computer Vision 파이썬