IP kameraları rtsp ile görüntüleyin. RTSP video gözetimi

Bazı verilere göre bugüne kadar dünya yüz milyonlarca Video gözetimi için IP kameralar. Ancak, hepsinden çok, video oynatmadaki gecikme kritiktir. Video gözetimi, kural olarak, "statik" olarak gerçekleşir - akış, depoya kaydedilir ve hareket için analiz edilebilir. Video gözetimi için işini iyi yapan birçok yazılım ve donanım çözümü geliştirilmiştir.

Bu yazımızda biraz farklı bir uygulamaya bakacağız. IP kameralar, yani gerektiğinde çevrimiçi yayınlarda kullanım düşük iletişim gecikmesi

Öncelikle web kameraları ve IP kameralar ile ilgili terminolojideki olası bir yanlış anlaşılmayı giderelim.

Web kamerası kendi işlemcisi ve ağ arayüzü olmayan bir video yakalama cihazıdır. Web kamerası, ağ kartı ve işlemcisi olan bir bilgisayara, akıllı telefona veya başka bir cihaza bağlanmayı gerektirir.

IP kamera yakalanan videoyu sıkıştırmak ve ağa göndermek için kendi ağ kartına ve işlemcisine sahip bağımsız bir cihazdır. Böylece IP kamera, ağa tam olarak bağlanan ve başka bir cihaza bağlanmasına gerek olmayan, doğrudan ağa yayın yapabilen bağımsız bir mini bilgisayardır.

Düşük gecikme süresi(düşük gecikme), IP kameralar ve çevrimiçi yayınlar için oldukça nadir bir gereksinimdir. Örneğin, video akışının kaynağı bu akışın izleyicileriyle aktif olarak etkileşime giriyorsa, düşük gecikmeyle çalışma ihtiyacı ortaya çıkar.

Çoğu zaman, oyun kullanım durumlarında düşük gecikme gerekir. Örnekler şunları içerir: gerçek zamanlı video müzayedesi, canlı krupiye video kumarhanesi, bir sunucu ile etkileşimli çevrimiçi TV programı, bir quadcopter'in uzaktan kumandası vb.

İş yerinde canlı bir çevrimiçi kumarhane satıcısı.

Sıradan bir RTSP IP kamera, kural olarak videoyu sıkıştırır. H.264 codec bileşenidir ve iki veri taşıma modunda çalışabilir: serpiştirilmiş Ve serpiştirilmemiş.

mod serpiştirilmiş en popüler ve kullanışlı, çünkü bu modda, video verileri kameraya ağ bağlantısı dahilinde TCP protokolü aracılığıyla iletilir. Bir IP kameradan serpiştirilmişe dağıtmak için, kameranın bir RTSP portunu (örneğin 554) açıp dışarıya iletmeniz yeterlidir. Oynatıcının yalnızca kameraya TCP aracılığıyla bağlanması ve bu bağlantının içindeki akışı alması gerekir.

Kameranın ikinci çalışma modu serpiştirilmemiş. Bu durumda, bağlantı protokol kullanılarak kurulur. RTSP/TCP ve protokole göre trafik zaten ayrı gidiyor RTP/UDP oluşturulan TCP kanalının dışında.

mod serpiştirilmemiş protokolü kullandığı için videoyu minimum gecikmeyle yayınlamak için daha uygundur RTP/UDP, ancak aynı zamanda oyuncu arkadaysa daha sorunludur NAT.

Bir oynatıcının NAT arkasında bulunan IP kamerasına bağlanırken, oynatıcının ses ve video trafiğini almak için hangi harici IP adreslerini ve bağlantı noktalarını kullanabileceğini bilmesi gerekir. Bu bağlantı noktaları, bir RTSP bağlantısı kurulduğunda kameraya gönderilen SDP yapılandırması metninde belirtilir. NAT doğru bir şekilde açıldıysa ve doğru IP adresleri ve bağlantı noktaları tanımlandıysa, her şey çalışacaktır.

Bu nedenle, kameradan minimum gecikmeyle video çekmek için kullanmanız gerekir. araya girmez modu ve UDP üzerinden video trafiği alın.

Tarayıcılar doğrudan RTSP/UDP protokol yığınını desteklemez, ancak gömülü teknoloji protokol yığınını destekler WebRTC.

Tarayıcı ve kamera teknolojileri çok benzer, özellikle SRTPşifreli RTP. Ancak tarayıcılara doğru dağıtım için bir IP kameranın WebRTC yığını için kısmi desteğe ihtiyacı olacaktır.

Bu uyumsuzluğu ortadan kaldırmak için, IP kameranın protokolleri ile tarayıcının protokolleri arasında bir köprü olacak bir ara geçiş sunucusu gereklidir.

Sunucu, akışı IP kameradan kendisine alır. RTP/UDP ve WebRTC aracılığıyla bağlı tarayıcılara verir.

WebRTC teknolojisi protokole göre çalışır UDP ve böylece yönde düşük gecikme sağlar Sunucu > Tarayıcı. IP kamera protokol üzerinde de çalışır RTP/UDP ve yönde düşük gecikme sağlar Kamera > Sunucu.

Kamera, sınırlı kaynaklar ve bant genişliği nedeniyle sınırlı sayıda akış verebilir. Bir ara sunucu kullanmak, yayını bir IP kameradan çok sayıda izleyiciye ölçeklendirmenize olanak tanır.

Öte yandan, sunucuyu kullanırken iki iletişim ayağı etkinleştirilir:
1) İzleyiciler ve sunucu arasında
2) Sunucu ve kamera arasında
Böyle bir topolojinin bir dizi "özelliği" veya "tuzağı" vardır. Bunları aşağıda listeliyoruz.

Tuzak #1 - Codec'ler

Kullanılan codec'ler düşük gecikme süresine engel olabilir ve genel sistem performansının düşmesine neden olabilir.

Örneğin, kamera H.264'te 720p video akışı veriyorsa ve yalnızca VP8'i destekleyen bir Android akıllı telefona bir Chrome tarayıcı bağlıysa.

Kod dönüştürme etkinleştirildiğinde, bağlı IP kameraların her biri için kodu çözen bir kod dönüştürme oturumu oluşturulmalıdır. H.264 ve kodlar VP8. Bu durumda, 16 çekirdekli çift işlemcili bir sunucu, fiziksel çekirdek başına yaklaşık 1 kamera hesaplamasıyla yalnızca 10-15 IP kameraya hizmet verebilecektir.

Bu nedenle, sunucu kapasiteleri planlanan sayıda kameranın kod çevrimine izin vermiyorsa, kod çevriminden kaçınılmalıdır. Örneğin, yalnızca H.264 desteğine sahip tarayıcılara hizmet verin ve geri kalanını H.264 codec desteğinin olduğu iOS veya Android için yerel bir mobil uygulama kullanmasını sunun.

Bir mobil tarayıcıda kod çevrimini atlamak için bir seçenek olarak şunları kullanabilirsiniz: HLS. Ancak HTTP akışı hiç de düşük gecikme süresine sahip değildir ve şu anda etkileşimli akış için kullanılamaz.

Tuzak #2 - Kamera bit hızı ve kaybı

UDP protokolü, gecikmeyle başa çıkmaya yardımcı olur, ancak video paket kaybına izin verir. Bu nedenle, düşük gecikme süresine rağmen, kamera ile sunucu arasındaki büyük ağ kayıplarında resim bozulabilir.

Kayıpları ortadan kaldırmak için, kamera tarafından oluşturulan video akışının, kamera ile sunucu arasında tahsis edilen bant genişliğine uyan bir bit hızına sahip olduğundan emin olmanız gerekir.

Tuzak #3 - İzleyici bit hızı ve kaybı

Sunucuya bağlanan her yayın izleyicisinin de belirli bir indirme bant genişliği vardır.

IP kamera, izleyici kanalının yeteneklerini aşan bir akış gönderirse (örneğin, kamera 1 Mb/sn ve izleyici yalnızca kabul edebilir 500 kb/sn), o zaman bu kanalda büyük kayıplar ve sonuç olarak video frizleri veya güçlü eserler olacaktır.

Bu durumda, üç seçenek vardır:

1. Video akışını her izleyici için gerekli bit hızında ayrı ayrı kodlayın.
2. Akışları her bağlı kişi için değil, bir grup izleyici için kodlayın.
3. Çeşitli çözünürlüklerde ve bit hızlarında kameradan akışları önceden hazırlayın.

İlk seçenek 10-15 bağlı izleyiciyle zaten CPU kaynaklarını tüketeceğinden, her izleyici için kod çevrimi uygun değildir. Bununla birlikte, bu seçeneğin maksimum CPU yükü ile maksimum esneklik sağladığına dikkat edilmelidir. Onlar. bu idealdir, örneğin, coğrafi olarak dağıtılmış yalnızca 10 kişiye akış yapıyorsanız, her biri dinamik bir bit hızı alır ve her birinin minimum bir gecikmeye ihtiyacı vardır.

İkinci seçenek kod dönüştürme gruplarını kullanarak sunucu CPU'su üzerindeki yükü azaltmaktır. Sunucu, bit hızına göre birkaç grup oluşturur, örneğin iki:

• 200 Kb/sn
• 1 Mb/sn

İzleyici yeterli bant genişliğine sahip değilse, video akışını rahatça alabileceği gruba geçer. Bu nedenle, kod dönüştürme oturumlarının sayısı ilk durumda olduğu gibi izleyici sayısına eşit değildir, ancak kod dönüştürme grupları varsa sabit bir sayıdır, örneğin 2 iki.

Üçüncü seçenek sunucu tarafında çapraz kodlamanın tamamen reddedilmesini ve çeşitli çözünürlüklerde ve bit hızlarında önceden hazırlanmış video akışlarının kullanılmasını içerir. Bu durumda kamera, farklı çözünürlüklerde ve bit hızlarında iki veya üç akış çıkışı verecek şekilde yapılandırılır ve izleyiciler, bant genişliklerine bağlı olarak bu akışlar arasında geçiş yapar.

Bu durumda, sunucudaki kod çevrimi yükü ortadan kalkar ve kameranın kendisine kayar, çünkü kamera artık bir yerine iki veya daha fazla akışı kodlamak zorunda kalıyor.

Sonuç olarak, izleyicilerin bant genişliğini ayarlamak için üç seçeneği değerlendirdik. Bir kod dönüştürme oturumunun 1 sunucu çekirdeği aldığını varsayarsak, aşağıdaki CPU yükü tablosunu elde ederiz:

Tablo, kod dönüştürme yükünü kameraya kaydırabileceğimizi veya kod dönüştürmeyi sunucuya aktarabileceğimizi göstermektedir. 2. ve 3. seçenekler en uygun gibi görünüyor.

RTSP'yi WebRTC olarak test etme

Neler olup bittiğine dair gerçek resmi ortaya çıkarmak için bazı testler yapmanın zamanı geldi. Gerçek bir IP kamera alıp yayın gecikmesini ölçmek için test edelim.

Test için eski bir IP kamera alalım D-link DCS-2103 destek ile RTSP ve kodekler H.264 ve G.711.

Kamera, diğer yararlı cihazlar ve kablolarla birlikte bir dolapta uzun süre yattığı için onu göndermek zorunda kaldım. Sıfırla kameranın arkasındaki düğmeyi 10 saniye basılı tutarak.

Ağa bağlandıktan sonra kameradaki yeşil ışık yandı ve yönlendirici yerel ağda 192.168.1.37 IP adresine sahip başka bir cihaz gördü.

Kameranın web arayüzüne gidiyoruz ve kodekleri ve çözünürlüğü test için ayarlıyoruz:

Ardından, ağ ayarlarına gidin ve kameranın RTSP adresini bulun. Bu durumda, RTSP adresi canlı1.sdp, yani Kamera şu adreste mevcuttur: rtsp://192.168.1.37/live1.sdp

Kamera erişilebilirliği ile kolayca kontrol edilebilir VLC oynatıcı. Medya - Ağ Akışını Açın.

Kameranın çalışmasını ve RTSP üzerinden video vermesini sağladık.

Test için sunucu olarak Web Çağrı Sunucusu 5'i kullanacağız. Bu, destekli bir akış sunucusudur RTSP ve WebRTC protokoller. IP kameraya şu şekilde bağlanacaktır: RTSP ve video akışını alın. Akışı şuna göre daha fazla dağıtın: WebRTC.

Kurulumdan sonra, sunucuyu RTSP moduna geçirmeniz gerekir. serpiştirilmemiş yukarıda tartıştığımız. Bu ayar eklenerek yapılabilir.

rtsp_interleaved_mode=yanlış
Bu ayar, flashphoner.properties yapılandırmasına eklenir ve sunucunun yeniden başlatılmasını gerektirir:

Hizmet web arama sunucusu yeniden başlatılıyor
Böylece interleaved olmayan şemaya göre çalışan, IP kameradan paketleri UDP üzerinden alan ve ardından WebRTC (UDP) üzerinden dağıtan bir sunucumuz oldu.

Test sunucusu, Frankfurt veri merkezinde bulunan bir VPS sunucusunda yer almaktadır, 2 çekirdeğe ve 2 gigabayt RAM'e sahiptir.

Kamera yerel ağda 192.168.1.37 adresinde bulunur.

Bu nedenle, yapmamız gereken ilk şey, gelenler için 554 numaralı bağlantı noktasını 192.168.1.37'ye iletmektir. TCP/RTSP sunucunun IP kameramıza bağlanabilmesi için bağlantılar. Bunu yapmak için yönlendirici ayarlarında yalnızca bir kural ekleyin:

Kural, yönlendiriciye gelen tüm trafiği 554 numaralı bağlantı noktasından 37 numaralı IP adresine yönlendirmesini söyler.

Dost bir NAT'ınız varsa ve harici IP adresini biliyorsanız, sunucu ile test etmeye başlayabilirsiniz.

Google Chrome tarayıcısındaki standart demo oynatıcı şöyle görünür:

Bir RTSP akışını oynatmaya başlamak için, adresini alana girmeniz yeterlidir. Aktarım.
Bu durumda akış adresi: rtsp://ip-cam/live1.sdp
Burada ip kamera bu, kameranızın harici IP adresidir. Sunucu bu adresle bağlantı kurmaya çalışacaktır.

VLC ve WebRTC gecikme testi

IP kamerayı yapılandırdıktan ve test ettikten sonra VLC, sunucuyu kurun ve test edin RTSP dağıtım ile sunucu üzerinden akış WebRTC, sonunda gecikmeleri karşılaştırabiliriz.

Bunu yapmak için, monitör ekranında saniyenin kesirlerini gösterecek bir zamanlayıcı kullanacağız. Zamanlayıcıyı açın ve video akışını aynı anda oynatın. yerel olarak VLC ve bir uzak sunucu aracılığıyla Firefox tarayıcısında.

sunucuya ping at 100ms.
Yerel olarak pingleme 1ms.

İlk zamanlayıcı testi şöyle görünür:
Siyah bir arka plan üzerinde, sıfır gecikmeyi gösteren orijinal zamanlayıcı bulunur. Sol VLC, sağda Firefox alma WebRTC uzak bir sunucudan akış.

	Sıfır	VLC	Firefox, WCS
Zaman	50.559	49.791	50.238
gecikme ms	0	768	321

Bu testte, bir gecikme görüyoruz VLC gecikmenin iki katı Firefox + Web Çağrı Sunucusu, VLC'deki videonun yerel ağda oynatılmasına ve Firefox'ta görüntülenen videonun Almanya'daki bir veri merkezindeki bir sunucudan geçmesine ve geri dönmesine rağmen. Bu tutarsızlık, VLC'nin TCP (interleaved mode) üzerinden çalıştığı ve düzgün video oynatımı için bazı ek arabellekler içerdiği gerçeğinden kaynaklanıyor olabilir.

Gecikme değerlerini yakalamak için birkaç çekim yaptık.

RTSP (Gerçek Zamanlı Akış Protokolü) bir video akışını kontrol etmek için basit bir dizi temel komut içeren gerçek zamanlı bir akış protokolüdür.

Bir video konferansta RTSP kaynaklarını ve IP kameraları bağlama

RTSP protokolü, herhangi bir TrueConf kullanıcısının, uzak nesneleri izlemek için bu protokolü kullanarak yayın yapan IP video kameralara ve diğer medya içerik kaynaklarına bağlanmasına izin verir. Ayrıca, kullanıcı bir video konferans sırasında görüntüleri yayınlamak için bu tür kameralara bağlanabilir.

RTSP protokolünün desteği sayesinde, TrueConf Server kullanıcıları sadece IP kameralara bağlanmakla kalmaz, aynı zamanda RTSP oynatıcılara ve medya sunucularına video konferans yayınlayabilir. RTSP yayınları hakkında daha fazlasını okuyun.

IP kameraları TrueConf yazılım çözümleriyle kullanmanın avantajları

• Bir ofis veya endüstriyel atölyeye bir IP kamera kurarak ve istediğiniz zaman ona bağlanarak şirketinizin üretim sürecini izleyebilirsiniz.
• Uzaktaki nesnelerin 24 saat izlenmesini sağlayabilirsiniz. Örneğin, tatile gidiyorsanız ve dairenizi gözetimsiz bırakmak istemiyorsanız, oraya bir veya daha fazla IP kamera kurun. TrueConf istemci uygulaması yüklü PC'nizden bu kameralardan birini arayarak, istediğiniz zaman dairenize bağlanabilir ve orada gerçek zamanlı olarak neler olduğunu görebilirsiniz.
• Windows, Linux ve macOS için TrueConf istemci uygulamaları, tüm kullanıcılara video gözetimi sırasında herhangi bir olayı kaydedebileceğiniz ve bunların belgesel kanıtlarını alabileceğiniz video konferansları kaydetme yeteneği sağlar.

Video yayınlarının rahat izlenmesi veya kişisel bilgisayarınızdaki multimedya oynatıcı yazılımı kullanılarak yapılandırılabilir. Bugün, en popüler VLC Media Player'lardan birinde Dahua Technology ağ ekipmanı için bir RTSP akışının nasıl kurulacağına bakacağız.

RTSP (Gerçek Zamanlı Akış Protokolü - gerçek zamanlı akış protokolü), kullanıcının bir köprü ve bir multimedya oynatıcı (bizim durumumuzda VLC Media Player) kullanarak bir multimedya veri akışını (ses ve video) uzaktan oynatmasına izin veren bir protokoldür.

Bir video akışı ayarlamanız gerekirse, aşağıdaki adımları kullanın:

1. Her şeyden önce, resmi web sitesinde ücretsiz olarak bulunan VLC Media Player'ı indirip yüklemeniz gerekir.
2. Medya (Medya) - Açık Ağ Akışı (Açık URL) menü öğesine tıklayın.
3. Bilgi istemi satırına RTSP ağ adresini girin.
4. Video görüntüsü ekranda göründüğünde oynat düğmesine basın.

Bağlantı şifre çözme RTSP

Örnek:

rtsp:// :@:/cam/realmonitor?channel= &alt tür=

Nerede :

: Kullanıcı adı (giriş).

: şifre.

: Ağ kamerasının IP adresi.

: Port 554 varsayılan olarak ayarlanmıştır, bu değer göz ardı edilebilir.

: Kanal numarası. Numaralandırma 1'den başlar.

: akış türü. Anlam Ana iş parçacığı 0'dır, İkincil iş parçacığı 1, 1'dir, İkincil iş parçacığı 2, 2'dir. Örneğin, İkinci iş parçacığı numarası 1 için referans şöyle olacaktır:

rtsp://yönetici: [e-posta korumalı]:554/cam/realmonitor?channel=1&subtype=1

Dahua Technology IP video kameralar, TCP ve UDP veri aktarım protokollerini destekler. 554 numaralı bağlantı noktası değiştirilmişse, kamera ayarlarının (web arayüzü) ilgili alanında değiştirin.

Bir RTSP akışı kurarken herhangi bir sorunla karşılaşırsanız, lütfen uygun bölüme bakın.