Problem: Glass-to-Glass Gecikme Neden Kritiktir?
Tarımsal ilaçlama robotundan tele-operasyona kadar pek çok sistemde kamera görüntüsü ile aktüatör tepkisi arasındaki gecikme operasyonel verimliliği doğrudan etkiler. Ölçülen baseline: 180ms gecikme ile robot, 3 frame önceki görüntüye göre karar veriyordu.
Donanım ve Yazılım Ortamı
| Bileşen | Detay |
|---|---|
| Platform | NVIDIA Jetson Orin NX 16GB |
| JetPack | 6.2 (L4T 36.4.3) |
| Kamera | Sony IMX678 4K — MIPI CSI-2 x4 |
| ISP Output | NV12 (4-lane @ 2.5Gbps) |
| GStreamer | 1.22 (NVMM destekli) |
| Model | YOLOv8n — TensorRT INT8 |
| Ölçüm | GstShark tracer + donanım timestamp karşılaştırması |
Baseline: Neden 180ms?
İlk pipeline yapısı:
gst-launch-1.0 \
nvarguscamerasrc ! \
nvvidconv ! \
x264enc tune=zerolatency ! \
rtph264pay ! \
udpsink host=192.168.1.100 port=5000
Sorunlar:
- x264enc yazılım encoder → CPU yükü %78, encode latency 48ms
- nvarguscamerasrc → ISP pipeline ek 35ms ekliyor
- nvvidconv dönüşümleri CPU üzerinden gidiyor, DMA atlanıyor
Latency Budget: Önce / Sonra
| Aşama | Önce | Sonra |
|---|---|---|
| Kamera → ISP çıkışı | 35ms | 12ms |
| Format dönüşümü (nvvidconv) | 18ms | 2ms (DMA) |
| Encode (x264enc → nvv4l2h264enc) | 48ms | 8ms |
| RTP paketleme | 4ms | 4ms |
| Ağ (loopback test) | 2ms | 2ms |
| Decode (software) | 38ms | 18ms |
| Render | 35ms | 16ms |
| Toplam Glass-to-Glass | 180ms | 62ms |
Optimizasyon 1: NVENC Hardware Encoder
gst-launch-1.0 \
nvarguscamerasrc eeMode=0 ! \
nvvidconv flip-method=0 ! \
'video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080' ! \
nvv4l2h264enc \
maxperf-enable=true \
insert-sps-pps=true \
iframeinterval=30 \
bitrate=8000000 \
preset-level=1 ! \
rtph264pay config-interval=-1 ! \
udpsink host=192.168.1.100 port=5000 sync=false async=false
Kritik parametreler:
maxperf-enable=true— NVENC encoder'ı düşük gecikme moduna alırinsert-sps-pps=true— her frame'de SPS/PPS gönderir; decoder yeniden senkronize olabilirsync=false— sink timestamp senkronizasyonunu kapat (buffer bloat önlenir)config-interval=-1— SPS/PPS every keyframe
Optimizasyon 2: Zero-Copy NVMM Buffer
nvvidconv + memory:NVMM kombinasyonu verinin CPU'ya kopyalanmadan GPU belleğinde kalmasını sağlar:
# Kötü: CPU copy
nvarguscamerasrc ! nvvidconv ! video/x-raw, format=BGRx ! ...
# İyi: Zero-copy NVMM
nvarguscamerasrc ! nvvidconv ! 'video/x-raw(memory:NVMM), format=NV12' ! nvv4l2h264enc ...
NVMM pipeline'ında CPU encode yükü %78 → %12'ye düşer.
Optimizasyon 3: ISP Bypass (Düşük Latency Gerektiğinde)
Latency hedefi <50ms ise nvarguscamerasrc ISP pipeline'ı atla:
gst-launch-1.0 \
v4l2src device=/dev/video0 ! \
'video/x-raw, format=UYVY, width=1920, height=1080, framerate=60/1' ! \
nvvidconv ! \
'video/x-raw(memory:NVMM), format=NV12' ! \
nvv4l2h264enc maxperf-enable=true insert-sps-pps=true ! \
rtph264pay ! \
udpsink host=192.168.1.100 port=5000 sync=false
ISP bypass ile kamera → encode süresi 53ms → 22ms'ye iner, ancak otomatik beyaz dengesi ve lens düzeltmesi devre dışı kalır.
GstShark ile Pipeline Profili
GST_DEBUG="GST_TRACER:7" \
GST_TRACERS="latency;queuelevel;framerate" \
gst-launch-1.0 [pipeline]
# Çıktı analizi
python3 gstshark-plot.py --type latency --output latency_trace.png
Sonuçlar (10.000 frame, 2.7 dakika)
| Metrik | Önce | Sonra | Delta |
|---|---|---|---|
| Glass-to-Glass (ortalama) | 180ms | 62ms | −66% |
| Glass-to-Glass (P99) | 243ms | 84ms | −65% |
| Encode Latency | 48ms | 8ms | −83% |
| CPU Encode Yükü | %78 | %12 | −66 puan |
| Throughput | 23fps | 60fps | +161% |
Tekrarlanabilirlik Notları
- Test: loopback (encode → decode → render aynı cihaz, loopback via GStreamer)
- JetPack 6.2 zorunludur; JetPack 5.x'te nvv4l2h264enc parametreleri farklıdır
- nvarguscamerasrc eeMode=0: AE kapalı, sabit exposure — değişken ISP latency önlenir
İlgili Kaynaklar
Video pipeline gecikmeniz >100ms ise Mimari Denetim Talebi sayfasından bize ulaşın.