--- title: "Mevcut kameralarla görüntü analitiği: RTSP akışından olaya giden zincir" author: "Abdulaziz Akyol" author_url: https://www.abdulazizakyol.com/hakkimda/ url: https://www.abdulazizakyol.com/blog/mevcut-kameralarla-goruntu-analitigi-rtsp-den-olaya/ language: tr published: 2026-09-14 categories: ["Görüntü işleme", "Yapay zekâ"] tags: ["RTSP", "ONVIF", "GPU", "nesne takibi", "kural motoru", "H.265"] translation: https://www.abdulazizakyol.com/en/blog/video-analytics-on-existing-cameras-from-rtsp-to-events/ description: "Mevcut IP kameralarla gerçek zamanlı analitik: RTSP akışı, GPU'da kare çözme, tespit ve takip, kural motoru ve olay çıkışından oluşan beş halkalık zincir." --- # Mevcut kameralarla görüntü analitiği: RTSP akışından olaya giden zincir Yazar: [Abdulaziz Akyol](https://www.abdulazizakyol.com/hakkimda/) · 2026-09-14 ## Öne çıkanlar - Mevcut kameralarla görüntü analitiği beş halkalık bir zincirdir: RTSP ile akışı almak, kareyi GPU'da çözmek, tespit ve takip, kural motoru ve olay/metrik çıkışı; ONVIF uyumlu, H.264 ya da H.265 çıkan bir IP kamera bunun için yeterlidir. - H.264/H.265 çözme işi CPU'ya bırakılırsa sunucu 3–4 kamerada tıkanır; GPU'nun donanım kod çözücüsü (NVDEC) kullanıldığında 25 fps'te tek GPU sunucuda 8–16 kamera işlenebilir. - 1080p giriş ve TensorRT ile derlenmiş modelle kare başına tespit süresi 40 milisaniyenin altındadır; çoklu nesne takibi olmadan aynı kişi 30 karede 30 kez sayılır. - Kural motoru modelden ayrı tutulur; alan poligonu, eşik süresi ve mesafe sınırı arayüzden değişir, model yeniden eğitilmeden çalışmaya devam eder. - 16 kamera × 4 Mbps = 64 Mbps sürekli trafik ürettiği için işleme sahada yapılır; görüntü tesisten çıkmaz, buluta yalnızca olay ve metrik gider. Müşteriye ilk sorduğumuz şey kamera markası değil, kameranın ne verdiği. ONVIF uyumlu, H.264 ya da H.265 çıkan bir IP kamera varsa işin yüzde doksanı hazır demektir. Beş yıldır kurduğumuz sistemlerin tamamı bu varsayımla çalışıyor: yeni kamera satmıyoruz, mevcut kameranın görüntüsünü karar veren bir şeye çeviriyoruz. ## RTSP'den olaya zincirin beş halkası Zincir beş halkadan oluşuyor. Her halkanın kendine ait bir darboğazı var ve projelerde sorun çıkan yer genellikle tahmin edilen yer değil. ### 1. Akışı almak Kameradan RTSP ile akış çekiyoruz. Burada iki pratik karar var: ana akış mı, alt akış mı; TCP mi, UDP mi. Ana akış 1080p ve üstü, alt akış genelde 640×360 ya da 704×576. Kişi sayma ve alan ihlali gibi işler alt akışla rahat çalışıyor, plaka ve KKD tespiti ana akışı istiyor. UDP daha az gecikme verir ama paket kaybında kare bozulur; fabrika ağlarında hep TCP kullanıyoruz, gecikme farkı birkaç yüz milisaniyeyi geçmiyor ve bozuk kare problemi ortadan kalkıyor. Sahada en çok vakit yediren konu NVR'ın kendisi. Bazı NVR'lar kameraya doğrudan erişimi kapatıyor, akışı NVR üzerinden almak zorunda kalıyorsunuz. NVR'ın RTSP sunucusu 8 kamerayı aynı anda verirken kanal başına düşürülmüş bir bit hızı uyguluyorsa görüntü kalitesi düşüyor. Bunu keşifte ölçmeden teklif vermiyoruz artık. ### 2. Kareyi çözmek H.264/H.265 çözme işini CPU'ya bırakırsanız sunucu 3–4 kamerada tıkanır. Çözmeyi GPU'nun donanım kod çözücüsüne (NVDEC) veriyoruz. 25 fps'te 8–16 kamera tek GPU sunucuda işlenebiliyor; sayı kameranın çözünürlüğüne ve kaç modelin aynı anda koştuğuna bağlı. Bu aralığı tekliflerde de aynen yazıyoruz, "sınırsız kamera" diye bir şey yok. Her kareyi işlemek gerekmiyor. Kişi sayma için saniyede 8–10 kare yeter, düşme algılama 15 kare ister, forklift yakınlaşması 20 karenin altına inmemeli. Kare atlama oranı kamera başına ayarlanır; bu ayar GPU bütçesini doğrudan belirler. ### 3. Tespit ve takip Tespit tarafında CNN tabanlı tek aşamalı modeller kullanıyoruz, YOLO ailesi sahada en az sürprizi çıkaran mimari oldu. Kare başına tespit süresi 40 milisaniyenin altında; bu sayı 1080p giriş ve TensorRT ile derlenmiş model için geçerli. Model ne kadar iyi olursa olsun, takip olmadan sayım yapılamaz: aynı kişi 30 karede 30 kez sayılır. Çoklu nesne takibi (ByteTrack benzeri) her tespite bir kimlik verir, kimlik bir çizgiyi geçtiğinde sayım gerçekleşir. Takipte iki klasik hata var. Kimlik değişimi: iki kişi çakışıp ayrıldığında kimlikler yer değiştirir. Kimlik kaybı: kişi bir sütunun arkasına girip 2 saniye sonra çıktığında yeni kimlik alır ve çift sayılır. İkisinin de çaresi model değil, kamera yerleşimi. Bu konuyu [ayrı bir yazıda](https://www.abdulazizakyol.com/blog/kisi-sayma-dogrulugunu-yuzde-96-ya-cikarmak-saha-kalibrasyonu/) anlatacağım; kısaca, kamera tavanda ve tepeden bakıyorsa problemlerin çoğu kendiliğinden çözülüyor. ### 4. Kural motoru Tespit edilen nesne tek başına hiçbir şey ifade etmez. "İnsan var" bilgisini olaya çeviren şey uzamsal ve zamansal kurallar. Uzamsal kural: bu poligonun içinde. Zamansal kural: 10 saniyeden uzun süredir. İkisini birleştirince "kısıtlı alanda 10 saniyeden fazla kalan kişi" olayı çıkıyor. Kuyruk uzunluğu, bekleme süresi, forklift ile yaya arasındaki mesafe, baretsiz geçen operatör; hepsi aynı motorun farklı kural setleri. Kural motorunu modelden ayrı tutmanın nedeni basit: müşteri kuralı değiştirmek istediğinde model yeniden eğitilmesin. Alan poligonu, eşik süresi, mesafe sınırı arayüzden değişiyor, model hiç dokunulmadan çalışmaya devam ediyor. ### 5. Olay ve metrik çıkışı Çıkış iki türlü. Olay: anlık, tekil, genellikle bir alarm ya da bildirim (webhook, e-posta, [MQTT](https://www.abdulazizakyol.com/blog/iot-ve-kamera-analitigini-birlestirmek-mqtt-olay-tabanli-mimari/)). Metrik: toplanmış, zaman serisi, dashboard ve BI araçları için (JSON, CSV, REST API). Perakende müşterisi metriği ister, İSG müşterisi olayı. Üretim müşterisi ikisini birden ister ve MES ile konuşmasını bekler. Olay şemasını ilk günden sabitlemek gerekiyor. Bizim şemada her olayda kamera kimliği, zaman damgası, olay tipi, güven skoru, ilgili kare (isteğe bağlı, KVKK ayarına göre) ve kural kimliği var. Bu şema değişmediği sürece müşteri tarafındaki entegrasyon da bozulmuyor. ## Nerede sorun çıkıyor - **Ağ, model değil.** Projelerin yarısında ilk hafta ağ anahtarı, VLAN ve NVR ayarlarıyla geçiyor. Kamera ağı ile sunucunun aynı segmentte olmaması başlı başına iş. - **Gece görüntüsü.** IR moduna geçen kamera siyah-beyaz verir, gündüz verisiyle eğitilmiş model gece düşer. Gece verisi eğitim setine eklenmeden kabul testi yapılmaz. - **Saat.** Kamera, NVR ve sunucu farklı saatlerdeyse olayları POS ya da MES kaydıyla eşleştiremezsiniz. NTP zorunlu. - **Bant genişliği.** 16 kamera × 4 Mbps = 64 Mbps sürekli trafik. Mağazanın 20 Mbps hattı üzerinden buluta göndermeye çalışan projeler ilk ay ölüyor. Bu yüzden [işlemeyi sahada yapıyoruz](https://www.abdulazizakyol.com/blog/edge-mi-bulut-mu-goruntu-isleme-projelerinde-isleme-yeri/); buluta yalnızca olay ve metrik çıkıyor. Bu zincirin tamamı bir GPU sunucuda, mağazanın ya da fabrikanın içinde çalışıyor. Görüntü dışarı çıkmıyor. Çıkan şey "saat 14:32'de 3 numaralı kasada kuyruk 6 kişiyi geçti" gibi bir satır. Kameranın kaydetmeyi bırakıp karar vermeye başlaması dediğimiz şey tam olarak bu. ## Sık sorulan sorular ### RTSP akışı için TCP mi UDP mi kullanılmalı? UDP daha az gecikme verir ama paket kaybında kare bozulur. Fabrika ağlarında TCP kullanıyoruz; gecikme farkı birkaç yüz milisaniyeyi geçmiyor ve bozuk kare sorunu ortadan kalkıyor. ### Görüntü analitiğinde ana akış mı alt akış mı kullanılmalı? Ana akış 1080p ve üstü, alt akış genelde 640×360 ya da 704×576 çözünürlüktedir. Kişi sayma ve alan ihlali gibi işler alt akışla rahat çalışır; plaka ve KKD tespiti ana akışı ister. ### Tek bir GPU sunucu kaç kamerayı işleyebilir? Kare çözme GPU'nun donanım kod çözücüsüne (NVDEC) verildiğinde 25 fps'te tek GPU sunucuda 8–16 kamera işlenebilir. Sayı kameranın çözünürlüğüne ve aynı anda kaç modelin koştuğuna bağlıdır; çözme CPU'ya bırakılırsa sunucu 3–4 kamerada tıkanır. ### Kişi sayma, düşme algılama ve forklift yakınlaşması için saniyede kaç kare gerekir? Kişi sayma için saniyede 8–10 kare yeterlidir, düşme algılama 15 kare ister, forklift yakınlaşması 20 karenin altına inmemelidir. Kare atlama oranı kamera başına ayarlanır ve GPU bütçesini doğrudan belirler. ## Kaynaklar 1. [RFC 2326: Real Time Streaming Protocol (RTSP)](https://www.rfc-editor.org/rfc/rfc2326) 2. [ONVIF: IP tabanlı güvenlik ürünleri için açık arayüz standardı](https://www.onvif.org/) 3. [NVIDIA Video Codec SDK (NVDEC/NVENC)](https://developer.nvidia.com/video-codec-sdk) --- Abdulaziz Akyol, CX Teknoloji'nin (yapay zekâ, görüntü işleme ve IoT) kurucusudur. Asıl sürüm: https://www.abdulazizakyol.com/blog/mevcut-kameralarla-goruntu-analitigi-rtsp-den-olaya/