AEGLOSLAB 엔비디아 기술 스택

제9부 로보틱스

9.5 DeepStream — 비디오 분석 파이프라인

9.5.1 이 장에서 배우는 것 / 선수 지식

9.1~9.4에서 Jetson 플랫폼·소프트웨어·운영을 봤다. 이제 그 대표 응용 — 비디오 분석 — 을 DeepStream으로 구축한다. 다중 카메라에서 디코딩 → 추론 → 추적 → 분석 → 출력을 GPU 가속 파이프라인으로 — 스마트시티·산업 비전·리테일·로봇 인지의 비디오 AI. 데이터센터에서도 같은 SDK(8.3 연속).

핵심 통찰: 비디오 분석의 효율은 "데이터를 GPU에 유지하며 멀티스트림을 배칭" 하는 데 있다(3.8·8.5·5.1). 카메라 스트림을 하드웨어 디코딩하고, 여러 스트림을 한 배치로 묶어 추론하고, 추적·분석까지 전 파이프라인을 GPU에서 실행해 CPU 병목·복사를 없앤다. DeepStream은 이를 GStreamer 기반 GPU 가속 플러그인으로 제공해, 바닥부터 작성하지 않고 다중 카메라 실시간 분석을 구축하게 한다.

배우는 것:

  • DeepStream이 무엇인가 — GPU 가속 비디오 분석 파이프라인 SDK(GStreamer 기반).
  • 파이프라인 단계 — 디코딩·스트림 muxer(배칭)·nvinfer(추론)·nvtracker(추적)·분석·OSD/출력.
  • 데이터 GPU 유지·멀티스트림 배칭 — 효율의 핵심(3.8·5.1·8.5).
  • 메타데이터 — 검출·추적 결과를 버퍼에 붙여 흐름.
  • 엣지·데이터센터 — 같은 SDK(Jetson·GPU), 로봇 인지·IVA.
  • 파이프라인 구성(config) 워크스루.

선수 지식: 3.8(GPU 데이터 파이프라인·전처리·DALI — 데이터센터판)·8.5(VPI/PVA·데이터 GPU 유지)·8.2(비디오 디코더·ISP)·5.2(TensorRT 추론)·8.4(DLA)·5.1(배칭)·9.1(Jetson 엣지). VPI는 9.6, Isaac은 9.7. 환경은 Jetson·DeepStream.

정직: DeepStream·GStreamer 플러그인·config는 버전 의존이다 — 이 장은 파이프라인 아키텍처·데이터 GPU 유지·멀티스트림 배칭의 원리를 가르치고 구체 플러그인·config는 "확인 필요". GStreamer 경험이 있으면 친숙하다.

9.5.2 DeepStream — GStreamer 기반 GPU 가속

DeepStream은 비디오 분석 파이프라인을 GPU로 가속하는 SDK다 — GStreamer(표준 미디어 프레임워크) 위의 GPU 가속 플러그인 집합:

DeepStream: GStreamer에 'GPU 가속 플러그인'을 추가 GStreamer: 미디어 파이프라인 프레임워크 (요소element를 연결한 파이프라인) 소스 → 디코딩 → 변환 → ... → 출력 (요소들의 그래프) nvv4l2decoder: 하드웨어 비디오 디코딩(8.2) nvstreammux: 멀티스트림 배칭 nvinfer: TensorRT 추론(5.2, GPU/ DLA) nvtracker: 객체 추적 nvdsosd: 온스크린 디스플레이(메타 시각화)

바닥부터 작성하지 않고, GPU 가속 비디오 분석을 플러그인으로 구성한다.

핵심: DeepStream은 "GStreamer의 표준 파이프라인 + NVIDIA GPU 가속 플러그인" 이다 — 디코딩·추론·추적·OSD를 GPU 가속 요소로 연결해 다중 카메라 실시간 분석을 구축. GStreamer를 알면 친숙하고, DeepStream이 GPU·TensorRT·하드웨어 디코더(8.2)를 플러그인으로 노출.

9.5.3 파이프라인 단계

DeepStream 비디오 분석 파이프라인(개념):

카메라/RTSP/파일 (N 스트림) nvv4l2decoder: 하드웨어 비디오 디코딩 (8.2 비디오 엔진, N 스트림) nvstreammux: 멀티스트림 배칭 N 스트림을 한 배치로 묶음(5.1) nvinfer(1차): 검출 DNN (TensorRT, GPU/DLA, 5.2· 91) — 배치 추론 nvtracker: 객체 추적 — 프레임 간 ID·궤적 nvinfer(2차): 분류/속성 (캐스케이드, 검출된 객체 분류) 분석: ROI·라인 크로싱·카운팅 (메타데이터 기반) nvdsosd: OSD + 출력: RTSP 스트림·메시지(Kafka 이벤트)·녹화

각 단계:

  • 디코딩: RTSP·파일·카메라를 하드웨어 비디오 디코더(8.2 비디오 엔진)로 — 다중 스트림을 CPU 부담 없이 디코딩.
  • 스트림 muxer(nvstreammux): 여러 스트림을 한 배치로 묶음 — 핵심 효율(9.5.4). N개 카메라 프레임을 batch로.
  • 1차 추론(nvinfer): 배치된 프레임에 검출 DNN을 TensorRT로(GPU/DLA, 5.2·8.4) — 배치 추론으로 GPU 채움(5.1). (대안: nvinferserver는 같은 자리에서 Triton(5.11~5.14)을 추론 백엔드로 써 — TensorRT 외 프레임워크·앙상블·원격 모델 서빙이 필요할 때. 기본은 nvinfer(TensorRT 직결, 오버헤드 최소)가 더 경량이다.)
  • 추적(nvtracker): 검출된 객체를 프레임 간 추적(ID·궤적) — "이 사람이 어디로 이동".
  • 2차 추론: 검출된 객체를 분류/속성(캐스케이드) — 예: 차량 검출 후 색·종류 분류.
  • 분석: 관심 영역(ROI)·라인 크로싱·카운팅 등 — 메타데이터 기반 비즈니스 로직.
  • OSD·출력: 결과를 영상에 그리기(OSD)·스트림 출력(RTSP)·이벤트 메시지(Kafka, 메시지 브로커)·녹화.

핵심: DeepStream 파이프라인은 디코딩→배칭→추론→추적→분석→출력 을 GPU 가속 요소로 연결한다 — 다중 카메라를 실시간으로. 각 단계가 GPU·하드웨어 엔진(8.2·8.4)을 쓰고, 메타데이터가 흘러 분석으로.

9.5.4 데이터 GPU 유지·멀티스트림 배칭

DeepStream 효율의 두 원리(3.8·8.5·5.1):

① 데이터 GPU 유지(zero-copy) 디코딩(GPU 비디오 엔진) → 추론(GPU) → 추적(GPU) → OSD(GPU) 전 파이프라인이 'GPU 메모리에서' 흐름 → CPU 복사· 왕복 없음(3.8·8.5) → CPU 병목 제거, 대역·지연 절약(엣지 전력도, 9.4 통합 메모리) ② 멀티스트림 배칭(nvstreammux) N개 카메라 프레임을 '한 배치'로 묶어 한 번에 추론 (5.1) → GPU를 채워(메모리 바운드 완화) 다중 스트림을 효율적으로 → 카메라 1대씩 추론하면 GPU 못 채움 → 배칭으로 처리량↑
  • 데이터 GPU 유지: 3.8(데이터센터 GPU 파이프라인)·8.5(VPI 데이터 지역성)의 정신 — 디코딩부터 출력까지 GPU 메모리에서, CPU 왕복·복사 없음. 비디오는 데이터가 커(8.1) 복사가 비용이 크므로 결정적. 엣지의 통합 메모리(9.4)와도 맞물려.
  • 멀티스트림 배칭: nvstreammux가 여러 카메라를 한 배치로 → nvinfer가 배치 추론(5.1). 카메라 1대씩이면 GPU를 못 채워(작은 배치, 메모리 바운드) 비효율 — 배칭으로 GPU를 채워 처리량↑.

핵심: DeepStream이 다중 카메라 실시간 분석을 효율적으로 하는 비결은 데이터를 GPU에 유지(복사 없음) + 멀티스트림 배칭(GPU 채움) 이다 — 3.8·5.1·8.5에서 배운 원리가 비디오 파이프라인에. 이것이 없으면(CPU 복사·스트림별 추론) GPU가 유휴 상태이고 CPU가 병목.

9.5.5 메타데이터·구성

메타데이터: DeepStream은 버퍼(프레임)에 메타데이터(검출·추적·속성)를 붙여 파이프라인을 흐른다:

하위 요소가 읽어 처리 프로브 probe 로 접근 프레임 버퍼 + 메타데이터 메타데이터 검출(nvinfer): 객체 박스·클래스·신뢰도 추적(nvtracker): 객체 ID·궤적 속성(2차 nvinfer): 색·종류 등 분석·OSD·출력 커스텀 로직(카운팅·알림)

구성(config) 기반: DeepStream 파이프라인은 config 파일로 정의하는 경우가 많다(코드 대신):

   config 예(개념 — 키·형식 버전 의존):
     [source0] uri=rtsp://... type=camera     # 소스(여러 개)
     [streammux] batch-size=N width=... height=...  # 배칭
     [primary-gie] config=detector.txt model=detector.plan  # 1차 추론(TensorRT)
     [tracker] ll-config=tracker.yml          # 추적
     [secondary-gie] ...                       # 2차 추론
     [sink0] type=RTSP/file/msgbroker          # 출력
   → config로 소스·배치·모델·추적·출력을 선언, 코드 최소

견해: DeepStream은 메타데이터가 흐르는 GStreamer 파이프라인 + config 선언으로 — 검출·추적·속성이 버퍼에 붙어 분석·출력으로 흐르고, config로 소스·모델·출력을 선언한다. 커스텀 분석은 프로브로 메타데이터에 접근. 바닥부터 GStreamer를 작성하지 않고 config·플러그인으로 빠르게 구축.

9.5.6 엣지·데이터센터·로봇

DeepStream은 Jetson(엣지)과 데이터센터 GPU 둘 다에서 같은 SDK(8.3):

엣지(Jetson, 9.1) 로봇·현장 카메라 — 적은 스트림·전력 제약(9.4) 예: 로봇 인지(다중 카메라)· 스마트 카메라·산업 검사 데이터센터(GPU) 많은 스트림 — 스마트시티· 중앙 비디오 분석(IVA) 예: 수십~수백 카메라를 GPU 서버에서 같은 DeepStream SDK·TensorRT·플러그인(8.3 연속)
  • 로봇 인지(제9부 맥락): 로봇의 다중 카메라를 DeepStream으로 검출·추적 — 로봇 비전의 비디오 AI. Isaac(9.7)과 함께 로보틱스 인지.
  • IVA(Intelligent Video Analytics): 스마트시티·리테일·산업의 중앙 비디오 분석 레퍼런스 — 데이터센터에서 많은 스트림.
  • 연속: 엣지에서 개발한 파이프라인을 데이터센터로(또는 반대), 같은 SDK·모델(TensorRT 타깃 재빌드 5.2).

핵심: DeepStream은 엣지(로봇·현장)와 데이터센터(중앙 IVA) 를 같은 SDK로 — 로봇 다중 카메라 인지부터 스마트시티 수백 카메라까지. 엣지는 전력·스트림 수가 제약(9.4), 데이터센터는 규모. 모델은 타깃별 TensorRT 빌드(5.2·9.2).

9.5.7 중간 점검 (체크포인트)

  • [ ] DeepStream이 GStreamer 기반 GPU 가속 비디오 분석 SDK임과 플러그인(디코딩·muxer·nvinfer·nvtracker·OSD)을 안다.
  • [ ] 파이프라인 단계(디코딩→배칭→추론→추적→분석→출력)와 각 단계의 GPU 가속을 설명한다.
  • [ ] 데이터 GPU 유지(복사 없음)·멀티스트림 배칭(GPU 채움) 이 효율의 핵심임을 안다(3.8·5.1·8.5).
  • [ ] 메타데이터(검출·추적·속성)가 버퍼에 붙어 흐르고 config로 구성됨을 안다.
  • [ ] DeepStream이 엣지(로봇)·데이터센터(IVA) 같은 SDK로 동작함을 안다(8.3).

증상→의심: 다중 카메라인데 GPU 못 채움·처리량 낮음 → 스트림별 추론(배칭 없음) → nvstreammux 배칭(5.1). CPU 병목 → 데이터 GPU 유지 안 됨·CPU 복사 → GPU 파이프라인(3.8·8.5). 디코딩이 CPU → 하드웨어 디코더(8.2). 추론 느림 → TensorRT·DLA 미사용 → nvinfer·DLA(5.2·8.4). 객체 ID가 프레임마다 바뀜 → 추적 없음 → nvtracker. 엣지 전력 초과 → 스트림 수·전력 모드(9.4). 모델 안 됨 → TensorRT 엔진 타깃(5.2·9.2).

9.5.8 트레이드오프·대안

결정트레이드오프
DeepStream vs 커스텀 GStreamer/OpenCVGPU 가속·통합·배칭 vs 자유·노동·비효율
멀티스트림 배칭 vs 스트림별GPU 채움·처리량 vs 단순·비효율
엣지 vs 데이터센터현장·저지연·전력 vs 규모·중앙(8.3)
GPU vs DLA 추론유연 vs 효율(8.4, 엣지 전력)
config vs 코드빠름·선언 vs 자유·커스텀

견해: 다중 카메라 실시간 비디오 분석은 DeepStream이 정석이다 — GStreamer 기반에 GPU 가속·배칭·TensorRT·하드웨어 디코더를 통합해, 바닥부터 OpenCV·커스텀으로 작성하는 것보다 효율·빠르다. 멀티스트림 배칭·데이터 GPU 유지가 핵심(3.8·5.1·8.5). 엣지(로봇·전력 제약 9.4)는 DLA 오프로드(8.4)·스트림 수 관리, 데이터센터는 규모. config로 빠르게, 커스텀은 프로브로.

비엔비디아 정직: 비디오 분석 파이프라인은 OpenCV·GStreamer·다른 프레임워크로도 가능하나, GPU 전 파이프라인 가속·멀티스트림 배칭·TensorRT 통합은 DeepStream의 강점. GStreamer 표준 위라 친숙하고 커스텀 플러그인도. 단순 단일 스트림·간단 처리는 OpenCV가 충분할 수 있으니, 다중 스트림·실시간·GPU 효율이 필요한지로 판단. config·플러그인은 버전 의존.

9.5.9 흔한 함정

  • 스트림별 추론(배칭 없음). 카메라 1대씩 추론하면 GPU 못 채움(작은 배치·메모리 바운드) → nvstreammux로 멀티스트림 배칭(5.1).
  • CPU 복사로 파이프라인 깸. 디코딩·전처리·추론 사이 CPU 복사면 GPU 이점 상실 → 데이터 GPU 유지(3.8·8.5).
  • CPU 디코딩. 비디오 디코딩을 CPU로 하면 다중 스트림에서 병목 → 하드웨어 디코더(8.2).
  • 추론이 TensorRT 아님. 일반 추론은 느림 → nvinfer(TensorRT, 5.2)·DLA(8.4).
  • 추적 누락. 검출만 하면 프레임 간 객체 추적·궤적 없음 → nvtracker.
  • 엣지 전력·스트림 초과. Jetson에 너무 많은 스트림·높은 모드 → 스트림 수·전력 모드·DLA(9.4·8.4).
  • 모델 엔진 타깃. TensorRT 엔진은 GPU·버전 종속(5.2·9.2) → 타깃 빌드.
  • config·플러그인 버전 불문. DeepStream·GStreamer가 버전 의존 — 확인.

9.5.10 연습문제

연습 1 (효율 원리). DeepStream이 다중 카메라 비디오 분석을 효율적으로 하는 두 핵심 원리를 3.8·5.1·8.5와 연결해 설명하라.

정답

두 원리: ① 데이터 GPU 유지(zero-copy) — 디코딩(GPU 하드웨어 비디오 엔진 8.2) → 전처리 → 추론(GPU/DLA) → 추적 → OSD까지 전 파이프라인이 GPU 메모리에서 흐른다. CPU로의 복사·왕복이 없어 CPU 병목·대역·지연을 제거. 3.8(데이터센터 GPU 데이터 파이프라인·DALI)·8.5(VPI 데이터 지역성)의 정신 — 비디오는 데이터가 커(8.1) 복사가 비용이 크므로 GPU 유지가 결정적, 엣지 통합 메모리(9.4)와도 맞물림. CPU 복사가 한 군데라도 끼면 GPU 파이프라인 이점이 깨짐. ② 멀티스트림 배칭(nvstreammux) — N개 카메라 프레임을 한 배치로 묶어 한 번에 추론(nvinfer, 5.1). 카메라 1대씩 추론하면 작은 배치(batch=1)라 GPU(SM·텐서코어)를 못 채워 메모리 바운드·비효율(5.1.4). 여러 스트림을 배치로 묶으면 GPU를 채워 처리량↑ — 5.1의 배칭이 비디오에. 연결: 3.8(GPU 데이터 파이프라인·복사 제거)·8.5(데이터 GPU 유지)가 ①, 5.1(배칭으로 GPU 채움)이 ②. 둘이 합쳐 다중 카메라를 실시간으로 효율적으로 — 데이터를 GPU에 유지하며 스트림을 배치로. 이것이 없으면(CPU 복사·스트림별 추론) GPU가 유휴 상태이고 CPU가 병목, 다중 스트림 실시간 불가. DeepStream이 이 원리를 GStreamer 플러그인으로 구현해 바닥부터 작성하지 않게 함.

연습 2 (파이프라인). DeepStream으로 주차장 다중 카메라에서 차량을 검출·추적·카운팅하는 파이프라인을 단계로 설계하고 각 단계의 플러그인·가속을 제시하라.

정답

파이프라인: ① 소스/디코딩 — 주차장 카메라들(RTSP) → nvv4l2decoder로 하드웨어 비디오 디코딩(8.2 비디오 엔진), CPU 부담 없이 다중 스트림. ② 배칭 — nvstreammux로 N개 카메라 프레임을 한 배치로 묶음(5.1). ③ 1차 추론(검출) — nvinfer로 차량 검출 DNN을 TensorRT(5.2)로 배치 추론, 엣지면 DLA 오프로드(8.4, 전력 효율). 검출 박스·신뢰도 메타데이터. ④ 추적 — nvtracker로 차량을 프레임 간 추적(ID·궤적) — "이 차가 어디로". 카운팅에 필수(같은 차를 중복 안 세게). ⑤ (선택) 2차 추론 — 검출된 차량을 분류(색·종류, 캐스케이드 nvinfer). ⑥ 분석(카운팅) — ROI·라인 크로싱 로직: 주차장 입구 라인을 넘는 차량 ID를 세서 입출차 카운트(메타데이터 기반, 프로브로 커스텀 로직). 추적 ID로 중복 방지. ⑦ 출력 — nvdsosd로 영상에 박스·ID·카운트 표시, RTSP 스트림 출력·이벤트 메시지(Kafka, msgbroker) 로 입출차 알림·녹화. 가속: 디코딩(하드웨어 8.2)·추론(TensorRT/DLA 5.2·8.4)·전 파이프라인 GPU 유지(복사 없음 3.8·8.5)·멀티스트림 배칭(5.1). config로 소스·배치·모델·추적·출력 선언, 커스텀 카운팅은 프로브로 메타데이터 접근. 엣지(Jetson)면 전력·스트림 수 관리(9.4), 데이터센터면 많은 스트림. 핵심: 검출(무엇)+추적(같은 객체)+분석(카운팅) — 추적이 없으면 프레임마다 다시 세어 중복. 데이터 GPU 유지·배칭으로 다중 카메라 실시간.

연습 3 (배칭). 8대 카메라를 DeepStream으로 분석하는데 GPU 활용률이 낮고 처리량이 안 나온다. 원인과 해결을 설명하라.

정답

원인: 멀티스트림 배칭이 안 됨 — 8대 카메라를 각각 따로(스트림별, batch=1) 추론하면, 각 추론이 작은 배치라 GPU(SM·텐서코어)를 못 채워 메모리 바운드·저활용(5.1.4). GPU가 한 프레임을 처리하는 데 작은 배치라 비효율, 8대를 순차로 실행하면 처리량 부족. (또는 CPU 복사·CPU 디코딩이 병목일 수도.) 진단: nvstreammux의 batch-size가 스트림 수에 맞는지, GPU 활용률(tegrastats/jtop 9.4·7.3), 디코딩이 하드웨어인지(8.2), 데이터가 GPU에 유지되는지(CPU 복사 없는지). 해결: ① nvstreammux로 8 스트림을 한 배치로 — batch-size를 8(또는 적절히)로 설정해 8대 프레임을 묶어 nvinfer가 배치 추론(GPU 채움, 5.1) → 활용률·처리량↑. 카메라 1대씩이 아니라 8대를 한 번에. ② 데이터 GPU 유지 — 디코딩(하드웨어)→muxer→nvinfer가 GPU 메모리에서 복사 없이(3.8·8.5), CPU 복사가 있으면 제거. ③ TensorRT·DLA — nvinfer가 TensorRT(5.2), 엣지면 DLA 오프로드(8.4). ④ 엣지 전력(Jetson) — 전력 모드·스트림 수가 맞는지(9.4), throttle 아닌지. 핵심: 멀티스트림을 배치로 묶어 GPU를 채우는 것이 다중 카메라 효율의 핵심(5.1) — 스트림별 추론은 GPU를 유휴 상태로 만든다. nvstreammux가 그 배칭을 하고, 데이터 GPU 유지가 받친다. 8대를 한 배치로 묶으면 GPU 활용률·처리량이 크게 오름.

연습 4 (엣지 vs 데이터센터). 같은 DeepStream 비디오 분석을 로봇(Jetson 엣지)과 스마트시티(데이터센터 GPU)에 배포할 때 고려가 어떻게 다른가?

정답

로봇(Jetson 엣지): ① 전력·열 제약(9.4·8.1) — 적은 전력 예산이라 스트림 수가 제한되고, DLA 오프로드(8.4)로 추론 효율, 전력 모드(nvpmodel)·throttle 관리. ② 적은 스트림 — 로봇의 카메라 몇 대(다중이되 데이터센터보다 적음). ③ 저지연·자율 — 로봇 인지는 실시간 제어에 연결(8.1), 클라우드 왕복 없이 엣지에서. ④ 통합 메모리(9.4) — CPU·GPU 공유, zero-copy 유리. ⑤ arm64·JetPack(9.2~9.3) — Jetson 타깃 TensorRT 엔진(5.2). 스마트시티(데이터센터 GPU): ① 규모 — 수십~수백 카메라를 GPU 서버에서, 배칭으로 대량 처리(5.1). ② 전력 여유 — 데이터센터라 전력·냉각 풍부, 고성능 GPU. ③ 중앙 IVA — 중앙에서 많은 스트림 분석·이벤트(스마트시티·리테일). ④ x86 GPU — 데이터센터 GPU 타깃 엔진. ⑤ 스케일아웃(제7부) — k8s·다중 GPU로 스트림 수평 확장(6.8·7.2). 공통: 같은 DeepStream SDK·TensorRT·플러그인(8.3 연속) — 파이프라인을 엣지·데이터센터에 재사용(모델은 타깃별 TensorRT 빌드 5.2·9.2). 차이 요약: 엣지 = 전력·스트림 제약·DLA·저지연·자율·통합메모리·arm64, 데이터센터 = 규모·전력 여유·중앙·스케일아웃·x86. 같은 SDK로 두 곳을 — 엣지는 로봇 인지(9.7 Isaac과), 데이터센터는 IVA. 데이터센터-엣지 연속(8.3)이 비디오 분석에도 — 한 번 만든 파이프라인을 양쪽에.

연습 5 (DeepStream vs 커스텀). 다중 카메라 실시간 분석에 DeepStream과 OpenCV/커스텀 GStreamer 중 무엇을 권하고, 단일 간단 처리는?

정답

다중 카메라 실시간 분석 → DeepStream: ① GPU 전 파이프라인 가속 — 디코딩(하드웨어 8.2)·추론(TensorRT/DLA 5.2·8.4)·추적·OSD가 GPU 가속 플러그인, 데이터 GPU 유지(3.8·8.5). ② 멀티스트림 배칭(nvstreammux) — 여러 카메라를 한 배치로 묶어 GPU 채움(5.1) — 커스텀으로 작성하기 어려운 핵심 효율. ③ 통합·config — 소스·모델·추적·출력을 config로 선언, 바닥부터 작성하지 않음. ④ 검증된 추적·분석 — nvtracker·메타데이터. OpenCV/커스텀으로 다중 카메라 실시간 분석을 구성하면 GPU 가속·배칭·하드웨어 디코딩을 직접 구현해야 해 노동·비효율·병목(CPU). 단일 간단 처리 → OpenCV가 충분할 수 있음: ① 단일 스트림·간단 처리(리사이즈·간단 검출)면 OpenCV가 익숙·단순·충분 — 멀티스트림 배칭·GPU 파이프라인의 복잡함이 불필요. ② 프로토타입·실험·비실시간. ③ 단 OpenCV도 GPU 모듈·TensorRT 연동은 가능하나 통합·배칭은 DeepStream만 못함. 판단 기준: 다중 스트림·실시간·GPU 효율·생산 = DeepStream, 단일·간단·프로토타입 = OpenCV. 스트림 수·실시간성·GPU 효율·생산 여부로. GStreamer 경험이 있으면 DeepStream이 친숙(GStreamer 위). DeepStream의 실질적 가치는 "다중 카메라를 GPU에서 효율적으로 실시간" — 그것이 필요하면 DeepStream, 아니면 단순 도구. 둘 다 모델은 TensorRT(5.2)로 가속 가능.

9.5.11 요약 · 다음 장

  • DeepStream은 GStreamer 기반 GPU 가속 비디오 분석 SDK — 디코딩·배칭·추론·추적·분석·출력을 GPU 가속 플러그인(nvv4l2decoder·nvstreammux·nvinfer·nvtracker·nvdsosd)으로 연결해 다중 카메라 실시간 분석.
  • 파이프라인: 디코딩(하드웨어 8.2) → muxer(멀티스트림 배칭) → nvinfer(TensorRT/DLA 5.2·8.4) → nvtracker(추적) → 분석 → OSD/출력(RTSP·Kafka).
  • 효율의 두 핵심: 데이터 GPU 유지(복사 없음, 3.8·8.5)·멀티스트림 배칭(GPU 채움, 5.1) — 스트림별·CPU 복사면 비효율.
  • 메타데이터(검출·추적·속성)가 버퍼에 붙어 흐르고, config로 선언·프로브로 커스텀. 엣지(로봇·전력 제약 9.4·DLA)·데이터센터(규모 IVA) 같은 SDK(8.3).
  • 정직: DeepStream·플러그인·config는 버전 의존(GStreamer 위), 다중 스트림·실시간·GPU 효율이 필요하면 DeepStream·단순은 OpenCV.

다음 장: 9.6 VPI — 비전 가속. DeepStream이 비디오 파이프라인을 다뤘으니, 그 안팎의 클래식 비전 가속 — VPI(Vision Programming Interface) 로 스테레오·특징·필터·보정을 여러 엔진(GPU·PVA·CPU)에서 가속하는 법을 본다(8.5 자율주행판의 로보틱스 실습). 로봇 비전 전처리·SLAM 전단의 토대.