Mediapipe Framework Concepts - Synchronization

Synchronization

Scheduling mechanics

MeidaPipe 그래프에서의 데이터 처리는 CalculatorBase 하위 클래스들로 정의된 내부의 처리 노드들 내에서 발생합니다. 스케쥴링 시스템은 각 calculator를 실행해야 하는 시기를 결정합니다.

각 그래프는 적어도 하나의 스케쥴러 큐를 갖고 있습니다. 각 스케쥴러 큐는 정확히 하나의 실행기가 있습니다. 노드는 대기열(실행자)에 정적으로 할당됩니다. 기본적으로 하나의 큐가 있으며, 실행자는 시스템 기능에 따라 여러 스레드가 있는 스레드 풀(미리 스레드들을 생성해 놓고 작업 큐에 작업이 들어올 시 미리 생성한 스레드에 작업을 할당하는 디자인 패턴.)입니다.

각 노드에는 not ready, ready, running 스케쥴링 상태가 있습니다. 준비 기능은 노드를 실행할 준비가 되었는지 여부를 결정합니다. 이 함수는 그래프 초기화 시, 노드 실행이 완료될 때마다, 노드 입력 상태가 변경될 때마다 호출됩니다.

사용되는 준비 기능은 노드 유형에 따라 다릅니다. 스트림 입력이 없는 노드를 소스 노드라고 합니다. 소스 노드는 프레임워크에 더 이상 출력할 데이터가 없다고 말할 때까지 항상 실행할 준비가 되어 있으며 이 시점에서 닫힙니다.

소스가 아닌 노드는 처리할 입력이 있고 해당 입력이 노드 입력 정책에 의해 설정된 조건에 따라 유효한 입력 세트를 형성하는 경우 준비가 됩니다. 대부분 노드는 기본 입력 정책을 사용하나 일부 노드는 다른 정책을 지정합니다.

노드가 준비되면 해당 스케쥴러 큐에 태스크가 추가되는데 이것이 우선순위 큐입니다. 우선 순위 기능은 현재 고정되어 있으며 그래프 노드의 정적 속성과 토폴로지 정렬을 고려합니다. 예를 들어, 그래프 출력 쪽에 가까운 노드는 우선 순위가 더 높고 소스 노드는 우선 순위가 가장 낮습니다.

각 큐는 Calculator 코드를 호출해 작업을 실제로 실행하는 책임이 있는 실행자에 의해 제공됩니다. 다른 실행기를 제공하고 구성할 수 있습니다. 이는 실행 자원 사용을 사용자 정의하는 데 사용할 수 있습니다. 우선 순위가 낮은 스레드에서 특정 노드를 실행합니다.

---

Timestamp Synchronization

MediaPipe 그래프 실행은 분산(탈중앙화)되어 있습니다. 글로벌 시계가 없고, 다른 노드가 동시에 다른 타임스탬프 데이터를 처리할 수 있습니다. 이것은 파이프라이닝을 통해 더 높은 처리량을 허용하게 됩니다.

그러나 시간 정보는 많은 perception workflows에서 매우 중요합니다. 여러 입력 스트림을 수신하는 노드는 일반적으로 어떤 방식으로든 이를 조정해야 합니다. 예를 들어, object detector가 프레임으로부터 boundary 상자 리스트를 출력할 수 있으며, 이 정보는 원래 프레임과 함께 처리해야 하는 렌더링 노드에 제공될 수 있습니다.

그러므로 MediaPipe 프레임워크 주요 책임 중 하나는 노드에 대한 입력 동기화를 제공하는 것입니다. 프레임워크 mechanics 측면에서 타임스탬프의 주 역할은 동기화 키 역할을 하는 것입니다.

더 나아가 MediaPipe는 많은 시나리오(테스트, 시뮬레이션, batch processing 등)에서 중요한 결정론적 작업을 지원하도록 설계되었으며, 그래프 작성자는 실시간 제약 조건을 충족하는 데 필요한 결정론을 완화할 수 있습니다.

동기화 및 결정론의 두 가지 목표는 몇 가지 설계 선택 기초가 됩니다. 특히, 주어진 스트림으로 푸시된 패킷에는 단조롭게 증가하는 타임스탬프가 있어야 합니다.이는 많은 노드에 대해 유용한 가정일 뿐 아니라 동기화 논리에 의존하기도 합니다. 각 스트림에는 스트림 새 패킷에 허용되는 가장 낮은 타임스탬프인 타임스탬프 경계가 있습니다. 타임스탬프가 T인 패킷이 도착하면 경계는 자동으로 T+1로 진행해 단조로운 요구 사항을 반영합니다. 이를 통해 프레임워크는 타임스탬프가 T보다 낮은 패킷이 더 이상 도착하지 않는다는 것을 확실히 알 수 있습니다.

---

Input policies

동기화는 노드에서 지정한 입력 정책을 사용해 각 노드에서 로컬로 처리됩니다.

DefaultInputStreamHandler에 의해 정의된 기본 입력 정책은 다음을 보장해 입력의 결정적 동기화를 제공합니다.

• 동일한 타임스탬프를 가진 패킷이 여러 입력 스트림에 제공되면 실시간으로 도착 순서에 관계 없이 항상 함께 처리됩니다.
• 입력 세트는 타임스탬프 오름차순으로 처리됩니다.
• 패킷이 삭제되지 않으며 처리가 완전히 결정적입니다.
• 노드는 위가 보장됨에 따라 가능한 한 빨리 데이터를 처리할 준비가 됩니다.

참고 : 이의 중요한 결과는 Calculator가 패킷을 출력할 때 항상 현재 입력 타임스탬프를 사용하는 경우 출력이 본질적으로 단조롭게 증가하는 타임스탬프 요구 사항을 준수한다는 것입니다.

경고 : 반면에 모든 스트림에 대해 입력 패킷을 항상 사용할 수 있단 보장은 없습니다.

작동 방식을 설명하려면 확정된 타임스탬프 정의를 소개해야 합니다. 우리는 스트림 타임스탬프가 타임스탬프 경계보다 낮으면 확정된다고 말합니다. 즉, 해당 타임스탬프 입력 상태가 취소 불가능하게 알려지면 타임스탬프가 스트림에 대해 결정됩니다. 즉, 패킷이 있거나 해당 타임스탬프가 있는 패킷이 도착하지 않을 것이라는 확신이 있습니다.

참고 : 이러한 이유로 MediaPipe는 스트림 생산자가 명시적으로 마지막 패킷이 의미하는 것보다 더 멀리, 즉, 더 엄격한 경계를 제공하기 위해 더 멀리 타임스탬프 경계를 진행하도록 허용합니다. 이를 통해 다운스트림 노드가 입력을 더 빨리 해결할 수 있습니다.

타임스탬프는 각 스트림에 대해 정산되는 경우 여러 스트림에 걸쳐 정산됩니다. 또한 타임스탬프가 확정되면 이전 모든 타임스탬프도 확정된단 의미입니다. 따라서 확정된 타임스탬프는 오름차순으로 결정적으로 처리될 수 있습니다.

이 정의가 주어지면 기본 입력 정책이 있는 Calculator는 모든 입력 스트림에 걸쳐 정산되고, 적어도 하나의 입력 스트림에 패킷을 포함하는 타임스탬프가 있는 경우 준비가 된 것입니다. 입력 정책은 확정된 타임스탬프에 대해 사용 가능한 모든 패킷을 계산기에 대한 단일 입력 세트로 제공합니다.

이 결정적 동작 결과 중 하나는 여러 입력 스트림이 있는 노드의 경우 타임스탬프가 해결될 때까지 이론적으로 무제한 대기가 있을 수 있으며 그동안 무제한 수의 패킷이 버퍼링될 수 있다는 것입니다.

따라서 사용자 지정 입력 정책도 제공합니다. 예를 들어 SyncSetInputStreamHandler에 의해 정의된 다른 동기화 세트의 입력을 분할하거나, 동기화를 모두 피하고 ImmediateInputStreamHandler에 의해 정의된 입력이 도착하는 즉시 처리합니다.

---

Flow control

두 가지 main flow control mechanisms이 있습니다.

1. backpressure mechanism

스트림에 버퍼링된 패킷이 CalculatorGraphConfig::max_queue_size에 의해 정의된 제한에 도달할 때 업스트림 노드 실행을 제한합니다. 이 메커니즘은 결정적 동작을 유지하고 필요할 때 구성된 제한을 완화하는 교착 상태 방지 시스템을 포함합니다.

2. 실시간 제약 조건에 따라 패킷을 삭제할 수 있는 특수 노드 삽입

FlowLimiterCalculator에 정의되어 있으며, 일반적으로 사용자 지정 입력 정책에 사용됩니다. 예를 들어, 공통 패턴은 최종 출력에서 흐름 제어 노드로 루프백 연결과 함께 하위 그래프 입력에 흐름 제어 노드를 배치합니다. 따라서 흐름 제어 노드는 다운스트림 그래프에서 처리 중인 타임스탬프 수를 추적하고 이 수가 제한에 도달하면 패킷을 삭제할 수 있습니다. 패킷이 업스트림으로 삭제되기 때문에 타임스탬프를 부분적으로 처리한 다음 중간 단계 사이에서 패킷을 삭제함으로써 발생하는 작업 낭비를 피할 수 있습니다.

이 Calculator 기반 접근 방식을 통해 그래프 작성자는 패킷을 삭제할 수 있는 위치를 제어할 수 있으며 리소스 제약 조건에 따라 그래프 동작을 유연히 조정하고 사용자 지정을 할 수 있습니다.