# SDK 기본 경로와 약1 FPS 원인 범위

| 항목 | 결과 |
| --- | --- |
| 기본 경로 | 같은 image/plan/preprocess/custom processor + 공식 retrieve |
| 입력 | 합성 live 1920x1080, 15 FPS; RTSP Decode 없음 |
| 워밍업 / 측정 | 첫 결과 이후5초 / 15초 |
| 실제 mux/preprocess/infer/sink | 각각225 Frame, 약15 FPS |
| mux→preprocess / preprocess→infer / infer→sink | 평균1.77 / 23.87 / 1.94ms |
| SDK Stop 반환 / wait thread 종료 | 0.427 / 8.203ms |
| GPU | 4565→5361→4565MiB |
| 실험 | 모델load1, 기본1, RTP대조0, 실패0 |
| 실제 서비스 | 변경0; healthy, 기존 stopped 상태 보존 |

## 핵심 결함

Contextra의 `BufferRetriever.consume()`는 정상 Frame을 처리해도0을 반환한다.
SDK 계약은 처리한 buffer 수를 반환하며 정상 예제는1이다.
설치 SDK 공개 함수의 ELF 정적 분석에서 반환0이면1초 `nanosleep`이 실행됨을 확인했다.
재시도0도 최초1초 대기는 거친다. 이것은 약1 FPS의 매우 강한 설명이다.

이번 빠른 기본은 공식 예제대로1을 반환한다. 입력과 callback 등 여러 차이가 있으므로
0→1만 바꾼 production 인과 실험이나 실제 서비스10 FPS PASS라고 표현하지 않는다.
Production 수정/build/배포는 요청 경계에 따라 수행하지 않았다.

다음 최소 작업: 정상 소비1 반환·Stop/stale 의도적 폐기·실패 분기를 SDK 계약에 맞게 교정하고,
실제 SDK 반환값 회귀와 제한 서비스 FPS/cleanup을 확인한다. RTP/pool/모델 변경은 우선하지 않는다.

RTP 비교는 합성→RTSP를 단일조건으로 볼 수 없고, 구체적인 소비자 결함을 먼저 찾았으므로 생략했다.
RTP 자체 부하/RTSP Decode/서비스 callback 전체 비용과 수정 후 성능은 미확정이다.
`summary.json`은 전체 측정/한계, `summary.csv`는 숫자 요약이다.