핵심은 프레임마다가 아니라 카드 한 장당 한 번만 묻는 것

계산해 보면

프레임마다가 아니라 카드 한 장당 한 번

초당 15프레임(이 프로젝트가 검증한 프레임 레이트의 상한)으로 한 시간 방송을 하면서 서로 다른 카드 약 100장을 렌즈 앞에 보여 준다고 합시다. 정확히 같은 영상을 분석하는 두 가지 방법:

호출이 약 540배 줄어듭니다. 이 차이는 숫자 놀음이 아니라 설계 그 자체입니다. 카드를 가만히 들고 있어도 횟수는 늘지 않습니다. 카메라를 더 빠르게 돌려도 횟수는 늘지 않습니다. 호출 횟수를 결정하는 것은 방송한 시간이 아니라 보여 준 카드의 수입니다.

원칙

코드가 잊어서는 안 되는 것

1. 프레임마다가 아니라 카드 한 장당 한 번

   모든 설계 결정은 여기서 출발합니다. 로컬에서 계산할 수 있는 신호라면, 머신 밖으로 나가는 단 한 번의 호출보다 먼저 실행됩니다.

2. 판단 로직의 사본은 하나뿐

   언제 호출할지는 정확히 하나의 모듈에만 있습니다. 드라이버, 전송 계층, UI에 흩어져 세 사람이 세 가지 방식으로 바꿀 수 있는 상태가 아니라, 한자리에서 읽어 내릴 수 있는 파일 하나입니다.

3. 드라이버는 얇게 유지합니다

   스케줄링, 로깅, I/O는 드라이버의 몫이고, 무엇을 새 카드로 볼지는 엔진의 몫입니다. 프레임이 들어오는 방식을 바꿔도 호출이 나가는 시점이 슬그머니 달라지는 일은 없습니다.

4. 프레임 루프를 막는 것은 없습니다

   디코딩, 감지, HTTP, 디스크 I/O는 모두 루프 밖에서 돌아갑니다. 식별이 느리면 프레임 하나가 떨어질 뿐, 방송의 지연 시간이 계속 쌓이는 일은 절대 없습니다.

5. 공급자 종속 없음, 저희 자신을 포함해서

   식별 호출은 작은 인터페이스 뒤에 있는 교체 가능한 단계 하나입니다. 완전히 다른 곳으로 향하게 해도 모든 게이트, 스로틀, 캐시는 그대로 동작합니다.

6. 기본이 셀프호스팅

   여러분의 하드웨어, 여러분의 키, 여러분의 영상. 클라이언트 측 모드에서는 방송을 여러분의 Ximilar 계정에 저장하기로 직접 선택하지 않는 한, 머신 밖으로 나가는 것은 서로 다른 카드 한 장당 크롭 한 장뿐입니다.

소스와 기여

읽고, 실행하고, 패치를 보내세요