Bazı haberlere göre bugün yüz milyonlarca Video gözetimi için IP kameralar. Ancak video oynatımındaki gecikme hepsi için kritik değildir. Video gözetimi tipik olarak "statik" olarak gerçekleşir; akış depolamaya kaydedilir ve hareket açısından analiz edilebilir. Video gözetimi için geliştirilmiş, işini iyi yapan birçok yazılım ve donanım çözümü bulunmaktadır.
Bu yazıda biraz farklı bir uygulamaya bakacağız. IP kameralar yani online yayınlarda ihtiyaç duyulan yerlerde başvuru düşük iletişim gecikmesi.
Öncelikle web kameraları ve IP kameralarla ilgili terminolojideki olası yanlış anlaşılmaları giderelim.
Web kamerası kendi işlemcisi ve ağ arayüzü olmayan bir video yakalama cihazıdır. Web kamerası bir bilgisayara, akıllı telefona veya ağ kartı ve işlemcisi olan başka bir cihaza bağlantı 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. Yani IP kamera, ağa tam olarak bağlanan ve başka bir cihaza bağlantı gerektirmeyen, doğrudan ağa yayın yapabilen otonom 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ğının bu akışı görüntüleyenlerle aktif olarak etkileşime girmesi durumunda düşük gecikmeyle çalışma ihtiyacı ortaya çıkar.
Çoğu zaman oyun kullanım durumlarında düşük gecikmeye ihtiyaç duyulur. Bu tür örnekler şunları içerir: gerçek zamanlı bir video müzayedesi, canlı dağıtıcılı bir video kumarhanesi, sunuculu etkileşimli bir çevrimiçi TV programı, bir quadcopter'ın uzaktan kontrolü vb.
Canlı online casino satıcısı iş başında.
Normal bir RTSP IP kamera genellikle video akışı sağlar H.264 codec bileşenidir ve iki veri taşıma modunda çalışabilir: aralıklı Ve aralıksız.
Mod aralıklı en popüler ve kullanışlı çünkü Bu modda video verileri, ağ bağlantısı dahilinde kameraya TCP aracılığıyla iletilir. Bir IP kameradan aralıklıya dağıtım yapmak için kameranın bir RTSP portunu (örneğin 554) dışarıya açmanız/iletmeniz yeterlidir. Oynatıcı kameraya yalnızca TCP aracılığıyla bağlanabilir ve bu bağlantı dahilinde akışı alabilir.
İkinci kamera çalışma modu aralıksız. Bu durumda bağlantı protokol kullanılarak kurulur. RTSP/TCP ve trafik protokole göre ayrı ayrı gidiyor RTP/UDP oluşturulan TCP kanalının dışında.
Mod aralıksız minimum gecikmeyle video yayınlamak için daha uygundur, çünkü RTP/UDP, ancak aynı zamanda oyuncunun arkada olması daha sorunludur NAT.
NAT arkasındaki bir oynatıcının 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 açıldıysa ve doğru IP adresleri ve bağlantı noktaları belirlendiyse her şey işe yarayacaktır.
Bu nedenle, kameradan videoyu minimum gecikmeyle almak için şunu kullanmanız gerekir: aralıksız modunu etkinleştirin ve UDP aracılığıyla video trafiğini alın.
Tarayıcılar RTSP/UDP protokol yığınını doğrudan desteklemez ancak yerleşik teknoloji protokol yığınını destekler WebRTC.
Tarayıcı ve kamera teknolojileri çok benzer, özellikle SRTPşifrelenmiş RTP. Ancak tarayıcılara doğru dağıtım için IP kameranın WebRTC yığınına yönelik kısmi desteğe ihtiyacı olacaktır.
Bu uyumsuzluğu ortadan kaldırmak için IP kamera protokolleri ile tarayıcı protokolleri arasında köprü görevi görecek bir ara röle sunucusuna ihtiyaç vardır.
Sunucu, akışı IP kameradan devralır. RTP/UDP ve WebRTC aracılığıyla bağlı tarayıcılara gönderir.
WebRTC teknolojisi protokole göre çalışır UDP ve böylece yönde düşük gecikme sağlar Sunucu > Tarayıcı. IP kamera aynı zamanda protokolü kullanarak da ç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ışın çıktısını verebilir. Bir ara sunucu kullanmak, yayını bir IP kameradan çok sayıda izleyiciye ölçeklendirmenize olanak tanır.
Öte yandan, bir sunucu kullanıldığında iki iletişim ayağı etkinleştirilir:
1) İzleyiciler ve sunucu arasında
2) Sunucu ve kamera arasında
Bu topolojinin bir takım "özellikleri" veya "tuzakları" vardır. Bunları aşağıda listeliyoruz.
Tuzak #1 - Codec'ler
Kullanılan codec'ler düşük gecikme performansına engel olabilir ve genel sistem performansını düşürebilir.Örneğin, kamera H.264 formatında 720p video akışı çıkarıyorsa ve Android akıllı telefondaki yalnızca VP8 desteğine sahip bir Chrome tarayıcı bağlıysa.
Kod dönüştürme etkinleştirildiğinde, kodu çözen bağlı IP kameraların her biri için 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 oranında yalnızca 10-15 IP kameraya hizmet verebilecektir.
Bu nedenle, sunucu kapasitesi planlanan sayıda kameranın kod dönüştürmesine izin vermiyorsa, kod dönüştürmeden kaçınılmalıdır. Örneğin, yalnızca H.264'ü destekleyen tarayıcılara hizmet verin ve diğerlerine iOS veya Android için H.264 codec bileşenini destekleyen yerel bir mobil uygulama kullanmalarını önerin.
Mobil tarayıcıda kod dönüştürmeyi atlama seçeneği olarak şunları kullanabilirsiniz: H.L.S.. Ancak HTTP akışının gecikme süresi hiç de düşük değil ve şu anda etkileşimli yayınlar için kullanılamıyor.
Tuzak #2 - Kamera bit hızı ve kaybı
UDP protokolü gecikmeyle başa çıkmaya yardımcı olur ancak video paketlerinin kaybına da izin verir. Bu nedenle gecikme süresi düşük olmasına rağmen kamera ile sunucu arasındaki ağda büyük kayıplar olması durumunda resim zarar görebilir.
Kayıpları ortadan kaldırmak için kamera tarafından oluşturulan video akışının, kamera ile sunucu arasındaki özel bant genişliğine uygun bir bit hızına sahip olduğundan emin olmanız gerekir.
Tuzak #3 - İzleyicinin bit hızı ve kayıpları
Sunucuya bağlanan her yayın görüntüleyicinin de İndirme konusunda belirli bir bant genişliği vardır.IP kamera, izleyicinin kanalının yeteneklerini aşan bir akış gönderirse (örneğin, kamera 1 Mb/sn ve izleyici yalnızca kabul edebilir 500 Kbps), o zaman bu kanalda büyük kayıplar olacak ve bunun sonucunda videoda donmalar veya güçlü eserler meydana gelecektir.
Bu durumda üç seçenek vardır:
- Video akışını her izleyici için gereken bit hızında ayrı ayrı kodlayın.
- Akışların kodunu her bağlı kişi için değil, bir grup izleyici için dönüştürün.
- Çeşitli çözünürlüklerde ve bit hızlarında kamera akışlarını önceden hazırlayın.
İ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 Kbps
- 1 Mb/sn
Üçüncü seçenek sunucu tarafında kod dönüştürmenin 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ük ve bit hızlarına sahip iki veya üç akışın çıktısını alacak ş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 dönüştürme yükü ortadan kalkar ve kameranın kendisine kaydırılır, çünkü Kamera artık yalnızca bir akış yerine iki veya daha fazla akışı kodlamak zorunda kalıyor.
Sonuç olarak izleyicilerin bant genişliğine uyum sağlamak için üç seçeneği değerlendirdik. Bir kod dönüştürme oturumunun 1 sunucu çekirdeğini kapladığı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. Seçenek 2 ve 3 en uygunu gibi görünüyor.
RTSP'yi WebRTC olarak test etme
Olan bitenin gerçek resmini belirlemek için birkaç test yapmanın zamanı geldi. Gerçek bir IP kamera alalım ve yayın gecikmesini ölçmek için test yapalım.Test için eski bir IP kamerayı alalım D-link DCS-2103 destek ile RTSP ve codec'ler H.264 ve G.711.
Kamera diğer kullanışlı cihazlar ve kablolarla birlikte uzun süre dolapta kaldığı 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ü.
Kamera web arayüzüne gidiyoruz ve test için codec'leri ve çözünürlüğü 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
Kameranın kullanılabilirliği kullanılarak kolayca kontrol edilebilir. VLC oynatıcı. Medya - Ağ Akışını açın.
Kameranın çalıştığından ve RTSP üzerinden video aktardığından emin olduk.
Test için sunucu olarak Web Call Server 5'i kullanacağız. Bu, desteği olan bir akış sunucusudur RTSP ve WebRTC protokoller. IP kameraya bağlanacak RTSP ve video akışını alın. Ardından akışı dağıtın WebRTC.
Kurulumdan sonra sunucuyu RTSP moduna geçirmeniz gerekir aralıksız yukarıda tartıştığımız şey. Bu, bir 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 çağrısı sunucusunun yeniden başlatılması
Böylece, serpiştirilmemiş şemaya göre çalışan, IP kameradan paketleri UDP aracılığıyla alan ve ardından bunları WebRTC (UDP) aracılığıyla dağıtan bir sunucumuz var.
Test sunucusu, Frankfurt veri merkezinde bulunan bir VPS sunucusu üzerinde yer almakta olup, 2 çekirdeğe ve 2 gigabayt RAM'e sahiptir.
Kamera 192.168.1.37 adresindeki yerel ağda bulunmaktadır.
Bu nedenle yapmamız gereken ilk şey gelenler için 554 portunu 192.168.1.37 adresine iletmektir. TCP/RTSP Sunucunun IP kameramızla bağlantı kurabilmesi için bağlantılar. Bunu yapmak için yönlendirici ayarlarına yalnızca bir kural ekleyin:
Kural, yönlendiriciye gelen tüm trafiği bağlantı noktası 554'e ve IP adresini 37'ye yönlendirmesini söyler.
Kullanışlı bir NAT'ınız varsa ve harici IP adresini biliyorsanız, sunucuyla test etmeye başlayabilirsiniz.
Google Chrome tarayıcısındaki standart demo oynatıcı şuna benzer:
Bir RTSP akışını oynatmaya başlamak için alana adresini 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 adrese bağlantı kurmaya çalışacaktır.
Gecikme testi VLC ve WebRTC karşılaştırması
IP kamerayı yapılandırıp test ettikten sonra VLC, sunucuyu yapılandırdı ve test etti 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 uzak bir sunucu aracılığıyla Firefox tarayıcısında.
Sunucuya ping at 100 ms.
Yerel olarak pingle 1 ms.
Bir zamanlayıcı kullanan ilk test şuna benzer:
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 |
Gecikme değerlerini kaydetmek için birkaç fotoğraf çektik.
Sıklıkla şu soru ortaya çıkıyor: Uyumluluk listesinde yoksa bir IP kamera bir NVR'ye nasıl bağlanır?
İki seçenek var ONVIF ve RTSP
ONVIF protokolüyle başlayalım (Açık Ağ Video Arayüzü Forumu)
ONVIF, tüm cihazların farklı üreticilere ait olması durumunda IP kameraların, NVR'lerin ve yazılımların ortak çalışması için genel kabul görmüş bir protokoldür. ONVIF, insanların uluslararası iletişimi için İngilizce diliyle karşılaştırılabilir.
Bağlı cihazların ONVIF'i desteklediğinden emin olun; bazı cihazlarda ONVIF varsayılan olarak devre dışı bırakılabilir.
Veya ONVIF yetkilendirmesi devre dışı bırakılabilir; bu, kullanıcı adı/şifrenin her zaman varsayılan olarak olacağı anlamına gelir
WEB için kullanıcı adı/şifreden bağımsız olarak 
Ayrıca bazı cihazların kullandığını da belirtmekte fayda var.ONVIF protokolü aracılığıyla çalıştırma için ayrı bağlantı noktası
Bazı durumlarda ONVIF şifresi WEB erişim şifresinden farklı olabilir.
ONVIF aracılığıyla bağlanıldığında neler kullanılabilir?
Cihaz keşfi
Video aktarımı
Ses verilerinin alınması ve iletilmesi
PTZ kamera kontrolü
Video analizi (hareket algılama gibi)
Bu parametreler ONVIF protokolü sürümlerinin uyumluluğuna bağlıdır. Bazı durumlarda bazı parametreler kullanılamıyor veya düzgün çalışmıyor.
K ve ONVIF'i kullanma
SNR ve Dahua kayıt cihazlarında ONVIF protokolü Uzak Cihaz sekmesinin Üretici satırında bulunur
Cihazın bağlanacağı kanalı seçin
Üretici sekmesinden seçin ONVIF
Belirt IP adresi cihazlar
RTSP bağlantı noktası varsayılan olarak kalır
Kamera kullanımı ONVIF bağlantı noktası 8080
(2017'den beri yeni ONVIF modellerinde Alpha ve Mira serileri için bağlantı noktası 80 olarak değiştirildi)
OMNY kameralar Temel kullanmak ONVIF bağlantı noktası 80, kayıt şirketinde bir HTTP bağlantı noktası olarak belirtilir
İsim
Şifre cihaz parametrelerine göre
Uzak kanal varsayılan 1'dir. Cihaz çok kanallı ise kanal numarası belirtilir.
Kod Çözücü Arabelleği— zaman değerini gösteren video akışının ara belleğe alınması
Sunucu tipiburada TCP,UDP Programı seçeneği var
TCP- Gönderici ve alıcı arasında bağlantı kurar, tüm verilerin alıcıya değişmeden ve istenilen sırayla ulaşmasını sağlar, ayrıca iletim hızını da düzenler.
TCP'den farklı olarak UDP bir ön bağlantı kurmaz, bunun yerine yalnızca veri aktarmaya başlar. UDP, verilerin alınıp alınmadığını izlemez ve kayıp ya da hata durumunda verileri kopyalamaz.
UDP, TCP'den daha az güvenilirdir. Ancak diğer yandan kayıp paketlerin yeniden iletilmemesi nedeniyle akışların daha hızlı iletilmesini sağlar.
Takvim— otomatik tip tespiti.
Dahua'da bağlı cihazlar böyle görünüyor
Yeşil durum, kaydedicinin ve kameranın başarıyla bağlandığı anlamına gelir
Kırmızı durum bağlantı sorunları olduğu anlamına gelir. Örneğin bağlantı noktası hatalı.
İkinci bağlantı yöntemi ise RTSP(Gerçek Zamanlı Yayın Protokolü) 
RTSPbir video akışını kontrol etmeye yönelik komutları açıklayan gerçek zamanlı bir akış protokolü.
Bu komutları kullanarak video akışı kaynaktan alıcıya yayınlanır.
örneğin bir IP kameradan bir DVR'ye veya sunucuya.
RTSP aracılığıyla bağlanırken neler kullanılabilir?
Video aktarımı
Ses verilerinin alınması ve iletilmesi
AvantajBu aktarım protokolü sürüm uyumluluğu gerektirmemesidir.
Bugün RTSP neredeyse tüm IP kameralar ve NVR'ler tarafından desteklenmektedir
Kusurlar Protokol, video ve ses verilerinin iletimi dışında başka hiçbir şeyin mevcut olmamasıdır.
Bir kamera bağlama örneğine bakalım ve RTSP'yi kullanma
.jpg)
RTSP Uzak Cihaz sekmesinde, Üretici satırında bulunur, SNR ve Dahua kaydedicide şu şekilde sunulur:Genel
Cihazın bağlanacağı kanalı seçin
URL Adresi- buraya kameranın gönderdiği sorgu dizesini giriyoruz temel RTSP akışı yüksek çözünürlük.
Ekstra URL - Burada kameranın gönderdiği sorgu dizesini girin ek olarak RTSP akışı düşük çözünürlük.
Örnek istek:
rtsp://172.16.31.61/1 ana akış
rtsp://172.16.31.61/2 ek akış
Neden ek bir konuya ihtiyacınız var?
Çoklu resim kaydediciye bağlı yerel bir monitörde, kaydedici kaynakları kaydetmek için ek bir iş parçacığı kullanır. Örneğin 16 pencereli küçük resimlerde Full HD çözünürlüğün kodunu çözmeye hiç gerek yok, D1 yeterli. Peki, 1/4/8 pencere açtıysanız bu durumda ana akışın kodu yüksek çözünürlükte çözülür.
İsimcihaz parametrelerine göre
Şifre cihaz parametrelerine göre
Kod Çözücü Arabelleğizaman değerini gösteren video akışının ara belleğe alınması
Sunucu tipi- TCP, UDP, Program (ONVIF protokolüne benzer)
Bu makalede aşağıdakiler gibi en sık sorulan soruların yanıtları verilmektedir:
IP kamera NVR ile uyumlu mu?
Ve eğer uyumluysa, nasıl bağlanılır!?
Bir IP kameradan çevrimiçi yayın yapma sorununu çözmek genel olarak WebRTC kullanımını gerektirmez. Kameranın kendisi bir sunucudur, bir IP adresine sahiptir ve video içeriğini dağıtmak için doğrudan yönlendiriciye bağlanabilir. Peki neden WebRTC teknolojisini kullanmalısınız?
Bunun en az iki nedeni var:
1. Ethernet yayınının izleyici sayısı arttıkça önce kanal kalınlığının eksikliği, ardından kameranın kendi kaynakları hissedilecektir.
2. Yukarıda belirtildiği gibi IP kamera bir sunucudur. Ancak videoyu masaüstü tarayıcıya göndermek için hangi protokolleri kullanabilir? Mobil cihaz? Büyük olasılıkla bu, video karelerinin veya JPEG görüntülerinin HTTP aracılığıyla iletildiği HTTP akışı olacaktır. HTTP akışı, bildiğiniz gibi, gerçek zamanlı video akışı için tamamen uygun değildir, ancak akış etkileşiminin ve gecikmenin özellikle önemli olmadığı İsteğe Bağlı videoda kendini iyi kanıtlamıştır. Aslında, bir film izliyorsanız, filmi başka biriyle aynı anda izlemiyorsanız, birkaç saniyelik bir gecikme durumu daha da kötüleştirmeyecektir. "Oh hayır! Jack onu öldürdü! - Alice, trajik sondan 10 saniye önce Bob'la sohbette spoiler yazıyor.”
Veya RTSP/RTP ve H.264 olacaktır, bu durumda tarayıcıya VLC veya QuickTime gibi bir video oynatıcı eklentisinin yüklenmesi gerekir. Böyle bir eklenti, tıpkı oynatıcının kendisi gibi video yakalayacak ve oynatacaktır. Ancak ek destek/eklenti yüklemeden gerçek tarayıcı tabanlı akışa ihtiyacımız var.
Öncelikle bu cihazın tarayıcıya tam olarak ne gönderdiğini öğrenmek için IP kameranın anlık görüntüsünü alalım. Test konusu D-Link DCS 7010L kamera olacaktır:
Aşağıda kamerayı kurma ve yapılandırma hakkında daha fazla bilgi edinebilirsiniz, ancak burada yalnızca video akışı için ne kullandığına bakacağız. Web arayüzü üzerinden kamera yönetici paneline girdiğimizde şöyle bir şey görüyoruz (manzara için özür dileriz):
Resim tüm tarayıcılarda açılıyor ve yaklaşık saniyede bir kez eşit şekilde donuyor. Yayını izlediğimiz kameranın ve dizüstü bilgisayarın aynı yönlendiriciye bağlı olduğunu düşünürsek her şeyin düzgün ve güzel olması gerekir ama durum böyle değil. HTTP'ye benziyor. Tahminlerimizi doğrulamak için Wireshark'ı başlatalım:
Burada 1514 bayt uzunluğunda bir TCP parçaları dizisi görüyoruz
Ve alınan JPEG'in uzunluğuyla birlikte son bir HTTP 200 OK:
Bu tür bir yayına ihtiyacımız yok. Düzgün değil, HTTP isteklerini geriyor. Kamera saniyede bu tür kaç isteği karşılayabilir? 10 seyirci veya daha erken bir tarihte kameranın güvenli bir şekilde büküleceğine veya ciddi şekilde arızalanmaya başlayacağına ve slaytlar üreteceğine inanmak için nedenler var.
Kamera yönetici panelinin HTML sayfasına bakarsanız şu ilginç kodu göreceksiniz:
If(tarayıcı_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //çünkü ipv6 rtsp'yi desteklemez. var Host = g_netip; aksi halde var host = g_host; o+=""; //uyarı(o); DW(o); )
RTSP/RTP, videonun düzgün oynatılması için tam olarak ihtiyacınız olan şeydir. Ancak bu tarayıcıda çalışacak mı? - HAYIR. Ancak QuickTime eklentisini yüklerseniz her şey işe yarayacaktır. Ancak tamamen tarayıcı tabanlı yayın yapıyoruz.
Burada ayrıca Wowza gibi uygun bir sunucu aracılığıyla RTSP, RTP, H.264'ten dönüştürülmüş bir RTMP akışını alabilen Flash Player'dan da bahsedebiliriz. Ancak Flash Player, bildiğiniz gibi, VLC veya QuickTime ile kıyaslanamayacak kadar daha popüler olmasına rağmen aynı zamanda bir tarayıcı eklentisidir.
Bu durumda, aynı RTSP/RTP yeniden akışını test edeceğiz, ancak WebRTC uyumlu bir tarayıcı, herhangi bir ek tarayıcı eklentisi veya başka destek olmadan oynatma cihazı olarak kullanılacaktır. Akışı IP kameradan alıp WebRTC'yi destekleyen tarayıcıları kullanan isteğe bağlı sayıda kullanıcıya İnternet'e gönderecek bir aktarma sunucusu kuracağız.
Bir IP kameranın bağlanması
Yukarıda belirtildiği gibi test için basit bir D-Link DCS-7010L IP kamera seçildi. Buradaki temel seçim kriteri cihazın RTSP protokolünü desteklemesiydi, çünkü sunucumuz kameradan gelen video akışını bu sayede alacaktır.Birlikte verilen yama kablosunu kullanarak kamerayı yönlendiriciye bağlarız. Gücü açtıktan ve yönlendiriciye bağlandıktan sonra kamera DHCP aracılığıyla bir IP adresi aldı, bizim durumumuzda 192.168.1.34 idi (Yönlendirici ayarlarına giderseniz DCS 7010L cihazının bağlı olduğunu göreceksiniz - işte bu kadar) ). Kamerayı test etme zamanı geldi.
Kamera yöneticisi web arayüzüne ulaşmak için 192.168.1.34 tarayıcısında belirtilen IP adresini açın. Varsayılan olarak şifre yoktur.
Gördüğünüz gibi kameradan gelen video yönetici panelinde doğru bir şekilde yayınlanıyor. Aynı zamanda periyodik sallanma da fark edilir. WebRTC'yi kullanarak bunu düzelteceğiz.
Kamera kurulumu
Öncelikle kamera ayarlarında kimlik doğrulamayı devre dışı bırakıyoruz - testin bir parçası olarak akışı soran herkese vereceğiz. Bunu yapmak için kamera web arayüzündeki ayarlara gidin Kurulum - Ağ ve seçenek değerini ayarlayın Devre Dışı Bırakılacak Kimlik Doğrulaması.Burada ayrıca RTSP protokol portunun değerini de kontrol ediyoruz, varsayılan olarak 554'tür. İletilen videonun formatı, kullanılan profile göre belirlenir. Kamerada bunlardan en fazla üç tanesini ayarlayabilirsiniz, biz ilkini kullanacağız, live1.sdp - varsayılan olarak video için H.264 ve ses için G.711 kullanacak şekilde yapılandırılmıştır. Gerekirse bölümdeki ayarları değiştirebilirsiniz. Kurulum – Ses ve Video.
Artık kameranın çalışmasını RTSP aracılığıyla kontrol edebilirsiniz. VLC Player'ı açın (RTSP'yi destekleyen herhangi bir oynatıcıyı kullanabilirsiniz - QuickTime, Windows Media Player, RealPlayer, vb.) ve URL Aç iletişim kutusunda kameranın RTSP adresini ayarlayın: rtsp://192.168.1.34/live1.sdp
Neyse, her şey olması gerektiği gibi çalışıyor. Kamera, oynatıcıdaki video akışını RTSP protokolü aracılığıyla düzenli olarak yeniden üretir.
Bu arada, akış oldukça sorunsuz ve bozulma olmadan oynatılıyor. Aynısını WebRTC'den de bekliyoruz.
Sunucu kurulumu
Böylece kamera kurulur, masaüstü oynatıcılarla test edilir ve sunucu üzerinden yayına hazır hale gelir. Whatismyip.com'u kullanarak kameranın harici IP adresini belirliyoruz. Bizim durumumuzda 178.51.142.223 idi. Geriye kalan tek şey, yönlendiriciye 554 numaralı bağlantı noktasından RTSP aracılığıyla erişirken gelen isteklerin IP kameraya iletileceğini söylemektir.Yönlendiriciye uygun ayarları girin...
...ve telnet kullanarak harici IP adresini ve RTSP bağlantı noktasını kontrol edin:
Telnet 178.51.142.223 554
Bu porttan yanıt geldiğinden emin olduktan sonra WebRTC sunucusunu kurmaya geçiyoruz.
Barındırma işleminden Amazon EC2 üzerindeki Centos 64 bit üzerindeki bir sanal sunucu sorumlu olacak.
Performans sorunlarını önlemek için tek VCPU'lu m3.medium örneğini seçtik:
Evet evet Linode ve DigitalOcean da var ama bu durumda Amazon'u denemek istedim.
İleriye baktığımda, Amazon EC2 kontrol panelinde birkaç kural (ileri bağlantı noktaları) eklemeniz gerektiğini yazacağım, bunlar olmadan örnek çalışmayacaktır. Bunlar WebRTC (SRTP, RTCP, ICE) trafiğine yönelik bağlantı noktaları ve RTSP/RTP trafiğine yönelik bağlantı noktalarıdır. Eğer denerseniz, Amazon'un kurallarının gelen trafik için benzer bir şeye sahip olması gerekir:
Bu arada, DigitalOcean ile her şey daha basit olacak, güvenlik duvarındaki bu bağlantı noktalarını açmanız veya ikincisini kapatmanız yeterli. DO bulut sunucularının çalıştırılmasındaki en son deneyime göre, hala statik bir IP adresi veriyorlar ve NAT'larla uğraşmıyorlar, bu da Amazon'da olduğu gibi bağlantı noktası yönlendirmeye gerek olmadığı anlamına geliyor.
RTSP/RTP akışını WebRTC'ye aktaran sunucu yazılımı olarak Flashphoner'ın WebRTC Medya ve Yayın Sunucusunu kullanacağız. Akış sunucusu, RTSP/RTP akışını Flash'a aktarabilen Wowza'ya çok benzer. Tek fark, bu akışın Flash'a değil WebRTC'ye gönderilmesidir. Onlar. dürüst DTLS, tarayıcı ile sunucu arasında geçiş yapacak, bir SRTP oturumu kurulacak ve VP8'de kodlanan akış izleyiciye gidecek.
Kurulum için SSH erişimine ihtiyacımız olacak.
Spoylerin altında yürütülen komutların ayrıntılı bir açıklaması bulunmaktadır
1. Sunucu kurulum arşivini indirdi:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Genişletilmiş:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Yüklendi:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Kurulum işlemi sırasında sunucunun harici IP adresini girdik: 54.186.112.111 ve dahili 172.31.20.65 (Özel IP ile aynı).
4. Sunucuyu başlattık:
$service web çağrısı sunucusu başlangıcı
5. Günlükleri kontrol ettim:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Sunucunun başlatıldığından ve çalışmaya hazır olduğundan emin olun:
$ps yardımcı | grep Flashphoner
7. Apache'yi kurduk ve başlattık:
$yum httpd'yi yükle
$hizmet httpd başlangıcı
8. Web dosyalarını indirdim ve bunları standart Apache klasörüne /var/www/html'ye yerleştirdim
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$zip webrtc_media_client.zip
9. Sunucunun IP adresini flashphoner.xml yapılandırmasına girin:
10. Güvenlik duvarını durdurdu.
$service iptables durağı
Teorik olarak, 10. madde yerine gerekli tüm bağlantı noktalarını ve güvenlik duvarı kurallarını ayarlamak doğru olacaktır, ancak test amacıyla güvenlik duvarını devre dışı bırakmaya karar verdik.
Sunucu Ayarlama
WebRTC yayınımızın yapısının şu şekilde olduğunu hatırlayalım:
Bu diyagramın ana unsurlarını zaten belirledik; geriye kalan tek şey etkileşimlerin "oklarını" oluşturmaktır.
Tarayıcı ile WebRTC sunucusu arasındaki bağlantı Github'da bulunan web istemcisi tarafından sağlanır:. Bir dizi JS, CSS ve HTML dosyası basitçe içine atılır /var/www/html kurulum aşamasında (spoiler altındaki yukarıdaki 9. noktaya bakın).
Tarayıcı ile sunucu arasındaki etkileşim, flashphoner.xml XML yapılandırma dosyasında yapılandırılır. Web istemcisinin HTML5 Websockets aracılığıyla WebRTC sunucusuna bağlanabilmesi için sunucunun IP adresini girmeniz gerekir (yukarıdaki 9. nokta).
Sunucu kurulumu burada sona ermektedir; çalışmasını kontrol edebilirsiniz:
Tarayıcıda index.html web istemci sayfasını açın (bunun için Apache aynı Amazon sunucusuna şu komutla kuruldu: yum -y httpd'yi yükle):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Burada webrtc-ipcam.ddns.net harici IP adresimize bağlanan dinamik DNS sunucusu noip.com aracılığıyla elde edilen ücretsiz bir alan adıdır. Yönlendiriciye, NAT ağ adresi çeviri kurallarına uygun olarak RTSP isteklerini 192.168.1.34'e yönlendirmesini söyledik (ayrıca yukarıya bakın).
Parametre id=rtsp://webrtc-ipcam.ddns.net/live1.sdp oynatılacak akışın URL'sini belirtir. WebRTC sunucusu, kameradan akışlar isteyecek, bunları işleyecek ve WebRTC aracılığıyla oynatılmak üzere tarayıcıya gönderecektir. Belki yönlendiriciniz DDNS'yi destekliyordur. Değilse, IP kameranın kendisi böyle bir desteğe sahiptir:
Yönlendiricinin kendisinde DDNS desteği şu şekilde görünür:
Artık test etmeye ve sonuçları değerlendirmeye başlayabilirsiniz.
Test yapmak
Bağlantıyı tarayıcıda açtıktan sonra, IP kameraya video akışını alması için istek gönderen WebRTC sunucusuna bağlantı kurulur. Tüm süreç birkaç saniye sürer.
Bu sırada, tarayıcı ile sunucu arasında websocket'ler aracılığıyla bir bağlantı kurulur, ardından sunucu RTSP aracılığıyla IP kamerayı ister, RTP aracılığıyla H.264 akışını alır ve bunu VP8 / SRTP'ye dönüştürür; bu da sonuçta WebRTC tarayıcısını oynatır.
Videonun alt kısmında, başka bir tarayıcıdan veya sekmeden görüntülenmek üzere kopyalanıp açılabilen video akışının URL'si görüntülenir.
Bunun gerçekten WebRTC olduğundan emin oluyoruz.
Ya aldatılırsak ve IP kameradan gelen video tekrar HTTP üzerinden aktarılırsa? Resme boş boş bakmayalım ama gerçekte ne tür bir trafik aldığımızı kontrol edelim. Elbette Wireshark'ı ve hata ayıklama konsolunu Chrome'da tekrar başlatıyoruz. Chrome tarayıcı konsolunda aşağıdakileri görebiliriz:
Bu sefer hiçbir şey yanıp sönmüyor ve HTTP üzerinden iletilen hiçbir görüntü görünmüyor. Bu sefer tek gördüğümüz Websocket çerçeveleri ve bunların çoğu Websocket oturumunu sürdürmek için kullanılan ping/pong türleri. İlginç çerçeveler: connect, hazırRtspSession ve onReadyToPlay - sunucuyla bağlantının kurulma sırası budur: önce bir Websocket bağlantısı ve ardından oynatma için bir akış isteği.
İşte gösterdiği şey chrome://webrtc-dahili
Grafiklere göre IP kameradan 1Mbps bit hızına sahibiz. Ayrıca giden trafik de var, büyük olasılıkla bunlar RTCP ve ICE paketleridir. Amazon sunucusuna RTT yaklaşık 300 milisaniyedir.
Şimdi Wireshark’a bakalım, sunucunun IP adresinden UDP trafiğini net bir şekilde görebilirsiniz. Aşağıdaki resimde paketler 1468 bayttır. Bu WebRTC'dir. Daha doğrusu tarayıcı ekranında gözlemleyebileceğimiz VP8 video karelerini taşıyan SRTP paketleri. Buna ek olarak, STUN istekleri gözden kaçıyor (resimdeki en düşük paket) - bu, WebRTC ICE'nin bağlantıyı dikkatlice kontrol etmesidir.
Ayrıca video oynatma için nispeten düşük gecikme süresine (veri merkezine ping yaklaşık 250 ms idi) dikkat etmek önemlidir. WebRTC, SRTP/UDP üzerinden çalışır ve sonuçta bu, HTTP, RTMP ve diğer TCP benzeri akış yöntemlerinden farklı olarak paketleri teslim etmenin en hızlı yoludur. Onlar. Gözle görülebilen gecikme, RTT + ara belleğe alma, kod çözme ve tarayıcı tarafından oynatma süresi olmalıdır. Görsel olarak bu durumda durum budur - göz neredeyse gecikmeyi görmez, 500 milisaniyeden azdır.
Bir sonraki test diğer izleyicileri birbirine bağlamaktır. 10 Chrome penceresi açmayı başardım ve her birinde bir resim görünüyordu. Aynı zamanda Chrome'un kendisi de biraz donuklaşmaya başladı. Başka bir bilgisayarda 11. pencereyi açarken oynatma sorunsuz kaldı.
Mobil cihazlarda WebRTC hakkında
Bildiğiniz gibi WebRTC, Android platformunda Chrome ve Firefox tarayıcıları tarafından desteklenmektedir.Yayınımızın orada gösterilip gösterilmeyeceğini kontrol edelim:
Resim bir HTC telefonu gösteriyor; Firefox tarayıcısı kameradan gelen videoyu gösteriyor. Oynatma akıcılığı açısından masaüstünden hiçbir fark yoktur.
Çözüm
Sonuç olarak, minimum çabayla bir IP kameradan çeşitli tarayıcılara WebRTC çevrimiçi yayını başlatmayı başardık. Tefle dans etmeye ya da roket bilimine gerek yoktu; yalnızca temel Linux ve SSH konsolu bilgisi yeterliydi.Yayının kalitesi kabul edilebilir düzeydeydi ve oynatma gecikmesi gözle görülmeyecek kadar yüksekti.
Özetlemek gerekirse, tarayıcı tabanlı WebRTC yayınlarının var olma hakkına sahip olduğunu söyleyebiliriz çünkü bizim durumumuzda WebRTC artık bir koltuk değneği veya eklenti değil, tarayıcıda video oynatmak için gerçek bir platformdur.
WebRTC'nin neden yaygın bir şekilde benimsendiğini görmüyoruz?
Belki de asıl engel codec eksikliğidir. WebRTC topluluğu ve satıcıları çaba göstermeli ve H.264 codec bileşenini WebRTC'ye dahil etmelidir. VP8'e karşı söylenecek bir şey yok ama neden H.264 ile çalışan milyonlarca uyumlu cihaz ve yazılımdan vazgeçesiniz ki? Patentler, böyle patentler...İkinci sırada tarayıcılarda tam destek yoktur. Örneğin IE ve Safari ile soru açık kalıyor ve orada başka bir akış türüne geçmeniz veya webrtc4all gibi bir eklenti kullanmanız gerekecek.
Dolayısıyla gelecekte akışların kodlanması ve dönüştürülmesine gerek kalmayacağı ve çoğu tarayıcının akışları çeşitli cihazlardan doğrudan oynatabileceği daha ilginç çözümler görmeyi umuyoruz.
Video yayınlarının rahatça görüntülenmesi veya kişisel bilgisayarınızdaki multimedya oynatıcı yazılımı kullanılarak yapılandırılabilir. Bugün, en popüler oynatıcılardan biri olan VLC Media Player'da Dahua Technology ağ ekipmanı için bir RTSP akışının nasıl yapılandırılacağına bakacağız.
RTSP (Gerçek Zamanlı Akış Protokolü), kullanıcının bir hiper bağlantı ve bir multimedya oynatıcı (bizim durumumuzda VLC Media Player) kullanarak bir multimedya veri akışını (ses ve video) uzaktan oynatmasına olanak tanıyan bir protokoldür.
Bir video akışını yapılandırmanız gerekiyorsa aşağıdaki adımları kullanın:
- Öncelikle resmi web sitesinde ücretsiz olarak bulunan VLC Media Player'ı indirip yüklemeniz gerekiyor.
- Medya - Ağ Akışını Aç (URL'yi Aç) menü öğesine tıklayın.
- Bilgi istemi satırına RTSP ağ adresini girin.
- Video görüntüsü ekranda göründüğünde oynat düğmesine basın.
Bağlantının açıklaması RTSP
Örnek:
rtsp:// :@:/cam/realmonitor?kanal= &alttür=
Nerede :
rtsp://yönetici: [e-posta korumalı]:554/cam/realmonitor?kanal=1&alttür=1
Dahua Teknolojisi IP video kameraları, TCP ve UDP veri aktarım protokollerini destekler. Bağlantı noktası 554 değiştirildiyse bunu video kamera ayarlarının (web arayüzü) ilgili alanında değiştirin.
RTSP akışını ayarlarken herhangi bir sorunla karşılaşırsanız lütfen uygun bölüme bakın.
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ü.
Video konferanslarda 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 olanak tanır. Kullanıcı ayrıca bir video konferans sırasında görüntü yayınlamak için bu tür kameralara da bağlanabilir.
RTSP protokol desteği sayesinde TrueConf Server kullanıcıları yalnızca IP kameralara bağlanmakla kalmıyor, aynı zamanda RTSP oynatıcılara ve medya sunucularına video konferans yayını da yapabiliyor. RTSP yayınları hakkında daha fazlasını okuyun.
IP kameraları TrueConf yazılım çözümleriyle kullanmanın faydaları
- Bir ofis veya endüstriyel atölyeye bir IP kamera kurup istediğiniz zaman ona bağlanarak şirketinizin üretim sürecini kontrol edebileceksiniz.
- Uzaktaki nesneleri günün her saatinde izleyebilirsiniz. Örneğin tatile gidiyorsanız ve dairenizi başıboş bırakmak istemiyorsanız, oraya bir veya daha fazla IP kamera kurmanız yeterlidir. TrueConf istemci uygulamasının yüklü olduğu bilgisayarınızdan bu kameralardan birine çağrı yaparak istediğiniz zaman dairenize bağlanabilir ve orada neler olduğunu gerçek zamanlı olarak görebilirsiniz.
- Windows, Linux ve macOS için TrueConf istemci uygulamalarında, tüm kullanıcılar video konferanslarını kaydetme olanağına erişebilir; bu sayede video gözetimi sırasında herhangi bir olayı kaydedebilir ve bunların belgesel kanıtlarını alabilirsiniz.
